Windows Workflow... Foundation (WF) is a Microsoft technology for defining, executing, and managing workflows. This technology was first released in November 2006 as a part of .NET Framework 3.0.
Workflows, like traditional programs, allow you to coordinate work but have some important differences.
Workflows can handle long running work by persisting to a durable store, such as a database, when idle and loading again once there is work to do
An instance of a workflow can be modified dynamically while running in the event that new conditions require the workflow to behave differently than it did when it was created
Workflows are a declarative way of writing programs by linking together pre-defined activities rather than an imperative programming model of writing lines of code
Workflows allow you to declare business rules that are separated from your code making it easier for you to modify them in the future
Workflows support different styles of systems with sequential and state machine workflows
Authoring Workflows
A new XML-based language called XAML is commonly used for declaring the structure of a workflow. However, the workflow may also be expressed in code using any .NET-targeted language (VB.NET, C#, C++/CLI, etc.).
WF provides .NET developers with the ability to separate the logic of their application from the underlying execution components, thus providing a clearer, more manageable representation of the application. This approach lends credence to the growing process-driven application methodology which aims to separate an application's logical flow from its executable components at an enterprise level.
Workflows comprise 'activities'. Developers can write their own domain-specific activities and then use them in workflows. WF also provides a set of general-purpose 'activities' that cover several control flow constructs.
Windows Workflow Foundation is supported by a companion set of extensions to Visual Studio 2005. These extensions contain a visual workflow designer which allows users to design workflows, a visual debugger which enables the users to debug the workflow designed, and a project system which enables the user to compile their workflows inside Visual Studio 2005. In Visual Studio 2008 WF functionality is included.
Moving data through Workflows
Activities that require or provide data can use properties to expose them, and enable the Workflow author to bind them to the containing workflow by declaring 'dependencies'.
Hosting Workflows
The .NET Framework 3.0 "workflow runtime" provides common facilities for running and managing the workflows and can be hosted in any CLR application domain, be it a Windows Service, a Console, GUI or Web Application.
--------------------------------------------------------------------------------
The host can provide services like serialization for the runtime to use when needed. It can also hook up to workflow instance's events such as their becoming idle or stopping.
Communicating with Workflows
WF provides several ways to communicate with a running instance of a Workflow:
A Windows Communication Foundation approach to workflow communication was added in .NET Framework 3.5. Workflows which include a ReceiveActivity expose a selected interface method as a WCF service. This could allow external code to, for example, make a Web Services call to a running workflow instance. WF provides infrastructure to ensure that if a WCF call is made to a workflow instance that is idle (i.e. waiting for some external event like a WCF call or a timer event), then the instance will be loaded from storage into memory so that the message can be delivered. Workflows which include a SendActivity are, in turn, able to call external services via WCF.
When a workflow instance is created, the host application can provide information in Dictionary objects. Similarly, the Workflow can pass the results of the workflow to the Host application through a Dictionary Object.
The Workflow foundation also allows the Workflow to update the Host application of the progress of the workflow. This is done by raising events in the Workflow to which the host application will subscribe.
Types of Workflows
Using the WF foundation, three different types of Workflow can be created:
Sequential Workflow (Typically Flow Chart based, progresses from one stage to next and does not step back)
State Machine Workflow (Progress from 'State' to 'State', these workflows are more complex and return to a previous point if required)
Rules-driven Workflow (Implemented based on Sequential/StateMachine workflow. The rules dictate the progress of the workflow)
Products Using Workflow Foundation
Microsoft Office SharePoint Server from the 2007 release. Versions prior to 2007 did not use WF.
Microsoft Speech Server from the 2007 release. Versions prior to 2007 did not use WF.
Microsoft Dynamics CRM from the 4.0 release. Versions prior to 4.0 did not use WF.
Microsoft BizTalk from the 2006 release. Versions prior to 2006 did not use WF.
WF Related project types in Visual Studio 2008
empty workflow project
sequential workflow library
sharepoint 2007 state machine workflow
state machine workflow library
sequential workflow console application
sharepoint 2007 sequential workflow
state machine workflow console application
workflow activity library
Tuesday, December 30, 2008
JavaScript tips to accelerate a slow Web app
For a basic JavaScript app, you probably don't need to worry about performance. But if you're writing a non-trivial JavaScript Web app, it might be an issue. We've got four simple tricks to help squeeze a little extra speed out of your JavaScript.
Got a quick-and-dirty Web application? Then a quick-and-dirty script will probably be fine. Small apps don’t strain resources, and so they generally execute quickly even if they’re not particularly well written. But if the app isn’t quick and dirty, then dirty scripting means the app certainly won’t be quick. Your JavaScript is probably fine, whether the app is simple or complex. But by using these four simple tricks, you can make it better still.
Tip #1: Cache your JavaScript if it is used by multiple pagesIf the same script code is going to be used in multiple pages, you can make the app more efficient by caching the code. By caching it in the browser, you pay a modest price up front by requiring the browser to download the code the first time. But you’ll recoup it many times over through the decreased load time.It’s easy to do. Tag the script in your app with
, and specify the file containing the script with the src attribute:
Once the browser pulls in the code, it will appear in the app just as if it had been hard-coded in. In addition to being efficient across multiple pages, it’s useful across multiple apps and multiple servers: Since the URL of the script code can reference it anywhere, on any server, you can import JavaScript code into one app or many from remote servers, if you like. You can even (if you ever had a good reason to do it) piece together an app with JavaScript code from multiple servers, in real time.
Tip #2: Accumulate HTML in string variablesWhen you write a large amount of content to a page, you may be building the page content element by element as it loads, using document.write( ). This works fine, but cranking out HTML this way is I/O-intensive.An alternative is to confine yourself to a single use of document.write( ). Instead of generating the HTML in pieces, assemble it in a string. When it’s all loaded into a string variable, use document.write( ) once to put it to the page.
Tip #3: Do large array lookups as string searchesPlowing through an array is always a cycle drain. Why? Because in addition to the repetitive evaluation, you have the overhead of the control structure you’ve set up to loop through the array. You’re better off using the built-in mechanics.An array in JavaScript is also an object in JavaScript. Great news for you: Because you know the keyfield(s) for the array you’re searching, and the relative position of the field holding the data you’re searching for, you can search the array as an object, by first defining as an object property the unique (keyfield) portion of each array row. If the actual data found in this keyfield isn’t necessarily unique, then hedge your bet by combining it with some other field that will make it so. Then you can build a temp table once, at page load, that marks the relative positions of your unique entries, and jump straight to it as a reference point to grab the data. Overall, you’ll net a significant savings in processing cycles.
Tip #4: Avoid inefficient commands in recursive codeAt face value, this tip is common sense that pretty much goes without saying. But are you aware of what JavaScript functions are inefficient? Some of them might surprise you. For instance, the Document Object Model’s various methods and functions are marvelous efficiency tools, but can gum up your application considerably if used in the wrong place.If you’re doing a tree search, for instance, to retrieve an element in a child node, you should avoid using a DOM method itself (to identify the element) in the loop-control logic; the overhead you’ll suffer is a killer. Why? Because when a method is invoked, it is evaluated, and that costs cycles and is completely unnecessary. Instead, invoke the method once and load the ID of the element you’re seeking into a local variable.Another killer function is eval( ). It’s useful for converting a text object ID into an actual object reference. The problem is that it’s a cycle hog, and it’s most often used to do wholesale mass references to page elements when there are lots and lots of them and their names really aren’t important. But don’t go there; you’ll bring your app to its knees.Instead, try using DOM’s native features for identifying elements—that is, instead of creating object referents by assigning arbitrary names and making them real with eval( ), go with the names that already exist (in DOM; which DOM expression you’d use for this depends on the type of element you’re trying to name). Note that this use of DOM document expressions differs from the example above. Each reference is distinctly useful, creating an authentic object reference, as opposed to repetitively invoking a method when it needs to be invoked only once.
Got a quick-and-dirty Web application? Then a quick-and-dirty script will probably be fine. Small apps don’t strain resources, and so they generally execute quickly even if they’re not particularly well written. But if the app isn’t quick and dirty, then dirty scripting means the app certainly won’t be quick. Your JavaScript is probably fine, whether the app is simple or complex. But by using these four simple tricks, you can make it better still.
Tip #1: Cache your JavaScript if it is used by multiple pagesIf the same script code is going to be used in multiple pages, you can make the app more efficient by caching the code. By caching it in the browser, you pay a modest price up front by requiring the browser to download the code the first time. But you’ll recoup it many times over through the decreased load time.It’s easy to do. Tag the script in your app with
, and specify the file containing the script with the src attribute:
Once the browser pulls in the code, it will appear in the app just as if it had been hard-coded in. In addition to being efficient across multiple pages, it’s useful across multiple apps and multiple servers: Since the URL of the script code can reference it anywhere, on any server, you can import JavaScript code into one app or many from remote servers, if you like. You can even (if you ever had a good reason to do it) piece together an app with JavaScript code from multiple servers, in real time.
Tip #2: Accumulate HTML in string variablesWhen you write a large amount of content to a page, you may be building the page content element by element as it loads, using document.write( ). This works fine, but cranking out HTML this way is I/O-intensive.An alternative is to confine yourself to a single use of document.write( ). Instead of generating the HTML in pieces, assemble it in a string. When it’s all loaded into a string variable, use document.write( ) once to put it to the page.
Tip #3: Do large array lookups as string searchesPlowing through an array is always a cycle drain. Why? Because in addition to the repetitive evaluation, you have the overhead of the control structure you’ve set up to loop through the array. You’re better off using the built-in mechanics.An array in JavaScript is also an object in JavaScript. Great news for you: Because you know the keyfield(s) for the array you’re searching, and the relative position of the field holding the data you’re searching for, you can search the array as an object, by first defining as an object property the unique (keyfield) portion of each array row. If the actual data found in this keyfield isn’t necessarily unique, then hedge your bet by combining it with some other field that will make it so. Then you can build a temp table once, at page load, that marks the relative positions of your unique entries, and jump straight to it as a reference point to grab the data. Overall, you’ll net a significant savings in processing cycles.
Tip #4: Avoid inefficient commands in recursive codeAt face value, this tip is common sense that pretty much goes without saying. But are you aware of what JavaScript functions are inefficient? Some of them might surprise you. For instance, the Document Object Model’s various methods and functions are marvelous efficiency tools, but can gum up your application considerably if used in the wrong place.If you’re doing a tree search, for instance, to retrieve an element in a child node, you should avoid using a DOM method itself (to identify the element) in the loop-control logic; the overhead you’ll suffer is a killer. Why? Because when a method is invoked, it is evaluated, and that costs cycles and is completely unnecessary. Instead, invoke the method once and load the ID of the element you’re seeking into a local variable.Another killer function is eval( ). It’s useful for converting a text object ID into an actual object reference. The problem is that it’s a cycle hog, and it’s most often used to do wholesale mass references to page elements when there are lots and lots of them and their names really aren’t important. But don’t go there; you’ll bring your app to its knees.Instead, try using DOM’s native features for identifying elements—that is, instead of creating object referents by assigning arbitrary names and making them real with eval( ), go with the names that already exist (in DOM; which DOM expression you’d use for this depends on the type of element you’re trying to name). Note that this use of DOM document expressions differs from the example above. Each reference is distinctly useful, creating an authentic object reference, as opposed to repetitively invoking a method when it needs to be invoked only once.
Subscribe to:
Posts (Atom)