The ten Windows Workflow Foundation (WF) hands-on labs were updated today on Microsoft download center for your coding enjoyment!

These ten labs were initially posted when WF was new to the world and .NET 3.0 was hot off the presses. This past winter, the product management team worked with David Starr to get the labs converted to .NET 3.5 and Visual Studio 2008, make the manuals consistent, and bring the VB.NET code up par to follow the same best practices as the C# code.

Once installed, you will have the following labs installed on your machine:

• WF01: Getting Started with WF
• WF02: Creating Custom Activities with WF
• WF03: Hosting Workflows in WF
• WF04: Creating State Machine Workflows in WF
• WF05: Communicating with the Host Application for WF
• WF06: WF and Web Services
• WF07: Creating Rules Driven Workflow in WF
• WF08: Transactional Behavior in WF
• WF09: Modifying Workflow Models at Runtime with Workflow Change in WF
• WF10: Embedding the Workflow Designer for WF

About half the labs saw some significant updating and clean-up – and they should yield a greatly improved experience for the learner; we applied feedback from HOL participants who took the labs at our events and provided an evaluation. The second half of the labs were more simply migrated and cleaned up for consistency.

But wait! There’s more! :)

While we were at it, we added an eleventh lab to the mix. Because the labs were developed before the new WCF activities were introduced, we dug into the excellent Visual Studio 2008 training kit done by the DPE folks, we updated and cleaned up the lab that walked a user through using the new WCF Send and Receive activities for WF in .NET 3.5:

• WF11: Workflow Enabled Services and Other New Features in the .NET Framework 3.5

The product management team will be making three additional hands-on labs available in the near future: unit testing WF workflows (currently available on MSDN Virtual Labs), unit testing WCF services, and advanced context management in WF 3.5 (built by Matt Milner, and unveiled at TechEd 2009 North America). All three labs have scored pretty well at events, and we’re looking forward to sharing them with you for direct download.

We hope that you find these updated labs useful; and, as always, welcome your feedback and comments.

Enjoy!
- Cliff

Microsoft is pleased to announce that nominations are now being accepted for participation in the “Dublin” Technology Adoption Program (TAP). “Dublin” rounds out the existing application server capabilities in Windows by providing additional features to help organizations manage and run Windows Communication Foundation (WCF) services and Windows Workflow Foundation (WF) services built using .NET 4.

The TAP is a program designed for customers who have specific business needs to get early access to new technology and to drive their requirements into the current and future versions of the product. In return, TAP participants help Microsoft reach its quality bar across product, documentation and support services and help validate features and use cases in real world environments. Customers receive direct support by Microsoft and are able to deploy pre-release builds into production if needed.

TAP requires significant time and resource commitment, so all nominations are required to have a compelling business need, appropriate resources and executive support to join this program. Additionally, due to the cost of running such a program, there are a limited number of seats available.

Should TAP not be suitable for you, Microsoft will also be offering a public beta later in 2009, which will enable you to evaluate the technology only in development and test environments.

We are accepting nominations now and will continue to accept nominations until August when the program is scheduled to start or until capacity is exceeded. Because “Dublin” needs WCF and/or WF 4 services to manage, we want to accept organizations into the program as soon as possible so that work can commence on the service development side prior to “Dublin” availability for TAP customers in August/September.

To submit a nomination to the “Dublin” TAP:

1. Log on to http://connect.microsoft.com, register if you don’t have an account and a profile

2. Under "CONNECTION DIRECTORY" on the top menu, select the "Server" category

3. Look for "Microsoft Codename "Dublin" Programs" and select the “Apply” link next to "Codename “Dublin” Technology Adoption Program (TAP)"

4. Fill out the Dublin TAP Nomination form available from the Downloads section (on the left hand-side menu)

Hello! I am Amadeo Casas Cuadrado, Program Manager in the Connected Framework team. I would like to introduce some of the new .NET 4 features (available with .NET 4 Beta1!) that we have developed to simplify the user experience when configuring WCF services.

One of the main pain points for Windows Communication Foundation (WCF) users has traditionally been dealing with large configuration files for their services. The WCF configuration schema is complex and provides users with many hard to find features. In .NET 4, we have focused on helping WCF users configure their services. We will be shipping new WCF features in .NET 4 for this reason.

The first feature consists of removing the need for explicit per-service configuration. If you do not configure any <service> elements for your service, and your service does not define programmatically any endpoint, then a set of endpoints will be automatically added to your service, one per service base address and per contract implemented by your service. In each of these endpoints, the endpoint address will correspond to the base address, the binding will be determined by the base address scheme and the contract will be that one implemented by your service.

For instance, the following configuration snippet represents the traditional configuration that a traditional WCF developer would create. Here we see a service that has one base address and implements one contract:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <services>

      <service name="Service1">

        <host>

          <baseAddresses>

            <add baseAddress="http://localhost:8731/Service1/" />

          </baseAddresses>

        </host>

        <endpoint address=""

                  binding="basicHttpBinding"

                  contract="Library1.IService1" />

      </service>

    </services>

  </system.serviceModel>

</configuration>

 

With .NET 4, the service configuration can be simplified to the following:

 

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

</configuration>

 

Even better in this case, you could also deploy your service with no configuration file at all!

It is also possible to customize the mapping between base addresses schemes and binding types. For instance, if you need to increase the security of your service and use wsHttpBinding as the default binding for HTTP addresses, the following chunk of configuration will do the trick:

    

<protocolMapping>

  <add scheme="http" binding="wsHttpBinding" />

</protocolMapping>

 

The second feature enables the user to define default values for WCF bindings and behaviors. Those bindings, service behaviors and endpoint behaviors with no name will be applied to your services with no explicit configuration. If we take a look at the configuration generated for a WCF Service Library project in VS2008/.NET 3.5:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <services>

      <service name="Service1"

               behaviorConfiguration="Service1Behavior">

        <host>

          <baseAddresses>

            <add baseAddress="http://localhost:8731/Service1/" />

          </baseAddresses>

        </host>

        <endpoint address=""

                  binding="wsHttpBinding"

                  contract="Library1.IService1" />

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior name="Service1Behavior">

          <serviceMetadata httpGetEnabled="True" />

          <serviceDebug includeExceptionDetailInFaults="False" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

</configuration>

 

The new WCF service configuration improvements in .NET 4 allow us to greatly simplify this service configuration to look like this:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <behaviors>

      <serviceBehaviors>

        <behavior>

          <serviceMetadata httpGetEnabled="True" />

          <serviceDebug includeExceptionDetailInFaults="False" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

</configuration>

 

This is, in fact, exactly how the new VS2010/.NET 4 service configuration template will look like.

The fact that you can define defaults for bindings and behaviors is particularly useful in the WCF configuration inheritance model in .NET 4. Those bindings and behaviors that are defined in upper levels in the configuration hierarchy will be added to your services with no explicit configuration. The following diagram shows an example of how it is possible to simplify your service configuration by relying on configuration elements defined at the machine or the application level:

 

 

In this example, a default basicHttpBinding and a default serviceMetadataBehavior are defined at the machine level. At the next level of the hierarchy, a default serviceDebugBehavior is defined, which will be added to the service, as well as a default endpoint which uses the binding defined at the machine level. As a final note, in .NET 4 Beta 2 all those default service behaviors will be merged and added to the service with no explicit configuration. Stay tuned!

Finally, the third WCF configuration improvement added in .NET 4 is the standard endpoint, which will allow you to define reusable preconfigured endpoints. The main characteristic of these endpoints is that one or more of the address, binding and contract properties have a fixed value. This is particularly useful to define system endpoints that provide their own contract implementation, i.e. not defined by your service, as for instance the MEX endpoint, whose implementation is provided by WCF out of the box. Another interesting feature in the standard endpoints is the possibility of extending the service endpoint with new properties, in a similar way as it is done with the custom bindings. The standard endpoints will also allow you to define custom properties for your service endpoint.

In order to define standard endpoints, you will need to make use of the following properties in your endpoint. The first property is kind, which identifies the standard endpoint type, and must be registered in the <endpointExtensions> section. The second property is endpointConfiguration, which will match the configuration element name of the standard endpoint in the <standardEndpoints> section, used to define the new properties for the endpoint. The last property is isSystemEndpoint, which will flag the endpoint to determine whether it has a fixed contract provided by WCF out of the box or not.

For instance, the following chunk of configuration code defines an udpDiscoveryEndpoint, which has an implicit contract and defines extra properties to the endpoint:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <services>

      <service name="Service1">

        <endpoint address=""

                  binding="basicHttpBinding"

                  contract="Library1.IService1" />

        <endpoint kind="udpDiscoveryEndpoint"

                  endpointConfiguration="udpConfig" />

      </service>

    </services>

    <standardEndpoints>

      <udpDiscoveryEndpoint>

        <standardEndpoint

                  name="udpConfig"

                  multicastAddress="soap.udp://239.255.255.250:3703"

                  ... />

      </udpDiscoveryEndpoint>

    </standardEndpoints>

  </system.serviceModel>

</configuration>

 

The <endpointExtensions> section for the udpDiscoveryEndpoint will be specified in your machine.config:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <extensions>

      <endpointExtensions>

        <add name="udpDiscoveryEndpoint" type="..." />

      </endpointExtensions>

    </extensions>

  </system.serviceModel>

</configuration>

 

What is next?

These features will help you maintain a cleaner configuration model for your WCF services. Let us know what you think!

And this is not the end of it! There are cases in which you will want to have different configuration settings for your services, one for debugging and one for deployment, for instance. In this case, you still need to develop and maintain different web.config files, or to have large chunks of unpleasant commented-out settings. We are currently working on the possibility to define configuration profiles, which will act as bags of different configuration elements that will be imported by the service using that profile. More coming shortly!

As you have probably noticed, the WCF Dev Center has changed quite a bit recently. If you are a returning visitor, you may be wondering where your favorite links went.

The driving principle behind the redesign is to better cater to the different audiences that visit our page. 

In its previous format, the WCF Dev Center catered very well to the return visitor looking for fresh content.  The various content feeds on the main page made it very easy to check back periodically and see new content.

However, our usage data shows that a lot of our traffic comes from first time visitors through search engines. Our redesign is an effort to present a friendlier face to those folks, and to help them find introductory materials.

The main page now has links to three main areas:

1) Get it: This page gives simple instructions for what you need to install to use WCF.  It also gives links to additional WCF Tools that are available in the Windows SDK and how to download them.

2) Get Started: This page has a streamlined set of content that we feel is most useful for programmers just getting started with WCF.  As part of this, we are introducing a new series of “Learning WCF Tutorials”.

3) Learn More: This page is the portal into all of the available learning resources and community content.  If you miss the old site, you might want to just bookmark this page as it is now the “one-stop shop” for experienced WCF programmers.

There are also two feeds on the main page: 

1) The “WCF Highlights” area where we will make important announcements such as Beta releases, important new content, and conference events.

2) The “What’s New” feed which will be a fast moving feed combining blog entries from the WCF Team Blog, syndicated MVP blogs, and the Social Network Bookmarking.

Please let us know what you think of the new design and make suggestions for any future improvements you’d like to see.

Last week we introduced the new Workflow Tracking features in .NET 4.0.  In this post we’ll do a deep dive into tracking profiles and explain how to use them to track workflow execution in a flexible way. 

Tracking Profile Overview

Tracking profiles let you subscribe to events that are emitted by the runtime when the state of a Workflow instance changes.  Depending on your monitoring needs you may craft a profile that is very coarse, subscribing to a small set of high level state changes on a Workflow.  On the other hand you may create a very granular profile whose output is rich enough to reconstruct the execution later.  Tracking profiles can satisfy these extreme scenarios and anything in between.

Tracking profiles manifest themselves in one of two ways.  You can create tracking profiles programmatically in .NET or configure them as XML elements in the <system.serviceModel> section of a standard .NET configuration file.  This post covers configuration based profiles.  Here is an example tracking profile in .NET 4.0 Beta 1:

 

Tracking Profile Structure

Tracking profiles are structured as declarative subscriptions to events, or tracking queries that let you “query” the Workflow Runtime for specific event records.  There are a handful of query types that let you subscribe to different classes of events.  Here are the most common query types that you can try out in .NET 4.0 Beta 1:

·         WorkflowInstanceQuery – Use this to track Workflow instance lifecycle changes like Started and Completed.

·         ActivityQuery – Use this to track lifecycle changes of the activities that make up a Workflow instance.  For example, you may want to keep track of every time the “Send E-Mail” activity completes within a Workflow instance.

·         FaultPropagationQuery – Use this to track the handling of faults that occur within an activity.  This event occurs each time a FaultHandler processes a fault.

·         UserTrackingQuery – Use this to track events that you define in your code activities.  There will be a follow up to this post that shows you how to create user tracking records.

Variable Extractions

When tracking the execution of a Workflow it is often useful to extract data.  This provides additional context when consuming the tracking records post execution.  Tracking profiles make this easy.  In .NET 4.0 you can extract variables from any activity in a Workflow.  The following example activity query comes from the monitoring hands on lab that shipped with the WCF and WF samples for .NET 4.0 Beta 1.  It shows how to extract the “StockSymbol” variable whenever the “GetStockPrice” activity completes.

 

Annotations

Annotations in Workflow 4.0 let you arbitrarily tag tracking records with a value that can be configured after build time.  For example, you might want several tracking records across several Workflows to be tagged with “Data Center” == “Contoso Data Center”.  This makes it easy to find all records with this tag when querying tracking records later.  To accomplish this, you would add an annotation to a tracking query like this:

 

What’s Next

In the next post in the series, we will talk about the extensibility of Workflow tracking  in .NET 4.0.  This topic will dive into the following concepts:

·         Programmatically emit your own tracking events by creating UserTrackingRecords.

·         Programmatically consume events within the runtime by creating custom TrackingParticipants.

·         Programmatically create tracking profiles in .NET.

We feel that learning by example is one of the easiest ways to get started with Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF).  In fact, we find that we often use code samples internally to get people from different feature teams all on the same page.  Therefore, it seemed only natural to think that others outside of Microsoft would benefit from the same types of samples.  We took these existing samples, cleaned them up and added more to fill in gaps to cover as much of the product as we could.  The result was our current sample set: downloadable here and documented here.

With beta1, the product unit authored and shipped 88 new samples for WCF and WF 4.  The samples themselves have been organized by type: Basic, Scenario and Application for WF and Basic, Scenario and Extensibility for WCF.  Basic samples are samples that demonstrate basic usage of a specific feature.  Think of these samples as the hello world of each feature.  Scenario samples show the usage of a set of features used in tandem.  They show specific use cases of our product and apply basic features to demonstrate common patterns.  The extensibility section for WCF exists to conform to the 3.0 WCF sample layout in MSDN Library.  Think of these samples as demonstrating ways to extend WCF beyond its built-in feature set.  Application samples show how many patterns can be used together to provide an end-to-end solution to a common problem.

We see each type of sample fulfilling the needs of different learning and usage styles.  For example, basic samples can be used to quickly familiarize yourself with specific features.  Scenario samples can be used to see what we feel are common patterns for WF and WCF.  These were common enough patterns that several scenario samples actually started as product code that was later move to a sample for one reason or another.  Of the scenario samples, I’d like to specifically call out the WF Activity Library.  This provides a number of activities that were not built into the product but we felt to could be used in many different applications (for example, there’s a SendMail activity, a Regex activity, a For Activity, and many more).

The WCF sample set, like the product changes, are additive.  This means that most of the pre-4 WCF samples are still relevant.  However, the samples currently shipped in the download linked to above are just for new features in Beta1.  In Beta2, the samples download will also include most of these samples shipped with 3.0-3.5sp1.  The new WCF samples include, Discovery, Event Tracing for Windows, Routing services, and more.

Look them over, let us know what you think by commenting on this post and responding to the WF and WCF code sample survey.  We do take your feedback seriously.  Need help with a particular scenario but couldn’t find a sample that demonstrated a similar pattern?  Others are probably in the same boat – letting us know can help us make learning WF and WCF easier for you and others moving forward.

WF 4 ships with an activity palette that consists of many activities – some of these are control flow activities that represent the different modeling styles developers can use to model their business process. Sequence and Flowchart are a couple of modeling styles we ship in WF 4. In this post, we will present these modeling styles, learn what they are, when to use what, and highlight the main differences between them.

Sequential modeling style

A sequential workflow executes a set of contained activities in sequential order. The Sequence activity in WF 4 allows you to model workflows in the sequential modeling style. A Sequence contains a collection of activities that are scheduled in the order in which they have been added to the collection. Hence, the order of execution of the activities is predictable.

You can add any activity to a Sequence – control flow procedural constructs like ForEach, If, Switch, While, DoWhile; or parallel constructs like Parallel and ParallelForEach to model parallel execution of logic; or any other activity we provide in the WF 4 activity palette (or your own custom activity or a third party activity).

The next figure shows a Vacation Approval workflow modeled as a sequential workflow using the Sequence activity and other activities. In this workflow, we first check if the employee has enough available days, wait for his manager approval, and finally update his vacation information in the company’s HR database. The activity highlighted in the orange box (Get Manager Approval) is actually a While activity (collapsed in the main Sequence) that executes another Sequence of activities (AskForApproval) while the approvedByManager variable value is False.

Workflows modeled using the sequential modeling style are easy to understand and author. They can be used to model simple to moderately complex processes. Since procedural activities have strong parity with procedural statements in imperative programming languages, you can use this type of workflows to model almost any type of process. Sequential workflows are also a good fit to model simple processes with no human interactions (e.g. services).

As the complexity of the process increases, the workflow will become more complex. In comparison to code, with workflows, you will get the benefit of visually looking at your process and visual debugging, however, you may want to factor out the logic into re-usable custom activities to improve the readability of large workflows.

Sequential Modeling Style and Sequence Activity

Sequence is not a requirement to create workflows that use the sequential modeling style. As we will explain later in this post, any activity in WF 4 can be the root of a workflow. Therefore, we can create a workflow that does not contain a Sequence but still uses the sequential modeling style and procedural activities. In the figure below, we have a workflow that has as a ForEach as root activity that prints all the items in a list of strings with a length higher than 5.

Flowchart

Flowchart is a well known and intuitive paradigm to visually represent business processes. Business Analysts, Architects and Developers use often flowcharts as common language to express process definitions and flow of logic. 

Since the release of WF 3, customers have given us feedback about what they like and don’t like.  One common point of feedback from customers using WF3 was that “we want the simplicity of Sequence, Parallel, etc. but the flexibility of StateMachine.”  When we dug deeper to get at the scenario behind this sentiment, we found that customers have a process (or a portion of a process) that is often quite sequential in nature but which requires “loopbacks” under certain circumstances (for some customers the circumstances are “exceptional” in nature while for other customers they are “expected” but it really doesn’t matter to this discussion). The FlowChart activity is new in WF 4 and it squarely addresses this (rather large) class of scenarios.  Flowchart is a very powerful construct since it provides the simplicity of sequence plus the ability of looping back to a previous point of execution, which is quite common in real life business processes to simulate re-try of logic when handling external input.

A Flowchart contains a set of nodes and arcs.  The nodes are FlowNodes – which contain activities or special common constructs such as a 2-way decision or a multi-way switch.  The arcs describe potential execution paths through the nodes.  The WF 4 Flowchart has a single path of execution; that is, it does not support split/join semantics that would enable multiple interleaved paths of execution.

The next figure shows a simplified recruiting process modeled using a Flowchart. In this case after a résumé is received, references are checked. If references are good, the process continues, otherwise the résumé is rejected. The next step verifies that the candidate skills are a good match for the position offered. If the candidate is a good match, then she will be offered a position. If she is not a good match for this position but interesting for future opportunities, the resume is saved in a database and a rejection letter is sent. Finally, if the candidate is not a good match, she is sent a rejection letter.

Flowchart modeling style is great to represent processes that are sequential in nature (with a single path of execution), but have loops to previous states. They use a very well known approach for modeling processes (based on “boxes and arrows”) and allow representing processes in a very visual manner. Control of flow is dominated by the transitions between the nodes and by two first-class branching activities (FlowDecision and FlowSwitch). Flowchart is a good fit to model processes with human interactions (e.g. human workflows).

Using Sequence and Flowchart together

WF 3 had a notion of a root activity. Only root activities could be used as the top level activity in a WF 3 workflow. WF 4 does not have a similar restriction. There is no notion of a root activity any more. Any activity can be the root of a workflow.

Let me explain this in more detail… Activities are a unit of work in WF. Activities can be composed together into larger Activities. When an Activity is used as a top-level entry point, we call it a "Workflow", just like Main is simply another function that represents a top level entry point to CLR programs. Hence, there is nothing special about using Sequence or Flowchart as the top level activity; and they can be composed at will.

The next figure shows a Flowchart inside a Sequence. The workflow below has three activities: a composite activity that does some work, a Flowchart (highlighted in green) and finally another composite activity that does some more work.

The same can be also done in a Flowchart. The next figure shows a Flowchart that has a Sequence (highlighted in green), a FlowDecision, and then two WriteLine activities for the True and False paths of the decision.

Beyond Sequence and Flowchart

WF 4 simplified activity authoring story makes easier writing your own custom composite activities to model any control of flow approach of your choice. In future posts, we will show how to write your own custom activities and designers.

Conclusion

In this post we have presented the Sequential and Flowchart modeling styles. We learned that Sequence is used for modeling sequential behavior and that Flowchart is used to model processes with a single path of execution and loops to previous states. We also learned that Sequence and Flowchart can be combined and used together as any other existing activity.

The following table shows the main differences between Sequence and Flowchart.

Sequence	Flowchart
Order of execution is explicit, close to imperative/code	Order of execution expressed as a graph with nodes and arcs
Loopbacks are represented combining control of flow activities (e.g. While + If)	First class modeling of loopbacks
Parity with imperative / procedural	Parity with boxes and arrows diagrams
Activities are executed in sequential order	Activities are executed in the order dictated by the arrows between them
Simple process / no human interaction (e.g. services)	Complex processes / human interactions (e.g. human workflows / state machine scenarios)
The flow of the process is not visually obvious	Control of flow is visual, dominated by Boolean decisions (FlowDecision) or Switch (FlowSwitch)

By now you must be aware of the significantly enhanced Windows Workflow Foundation (WF) scheduled to be released with .Net Framework 4.0. The road to WF 4.0 and .Net Framework 4.0 Beta1 documentation for WF can give you more details. Being a member of the team responsible for the development of the WF tracking feature, I am excited to discuss the components that constitute this feature. In a nutshell, tracking is a feature to gain visibility into the execution of a workflow. The WF tracking infrastructure instruments a workflow to emit records reflecting key events during the execution. For example, when a workflow instance starts or completes tracking records are emitted. Tracking can also extract business relevant data associated with the workflow variables. For example, if the workflow represents an order processing system the order id can be extracted along with the tracking record. In general, enabling WF tracking facilitates diagnostics or business analytics over a workflow execution. For people familiar with WF tracking in .Net 3.0 the tracking components are equivalent to the tracking service in WF 3. In WF 4.0 we have improved the performance and simplified the programming model for WF tracking feature.

A high level view of the tracking infrastructure is shown below

The primary components of the tracking infrastructure are

1) Tracking records emitted from the Workflow runtime.

2) Tracking Profile to filter tracking records emitted from a workflow instance.

3) Tracking Participants that subscribe for tracking records. The tracking participants contain the logic to process the payload from the tracking records (e.g. they could choose to write to a file).

The Workflow tracking infrastructure follows the observer pattern. The workflow instance is the publisher of tracking records and subscribers of the tracking records are registered as extensions to the workflow. These extensions that subscribe to tracking records are called tracking participants. Tracking participants are extensibility points that allow a workflow developer to consume tracking records and process them. The tracking infrastructure allows the application of a filter on the outgoing tracking records such that a participant can subscribe to a subset of the records. The mechanism to apply a filter is through a tracking profile.

The workflow runtime is instrumented to emit tracking records to follow the execution of a workflow instance. The types of tracking records emitted are

· Workflow instance tracking records: Workflow instance records describe the life cycle of the workflow instance. For instance a record is emitted when the workflow starts or completes.

· Activity tracking records: Activity tracking records are emitted when a workflow activity executes. These records indicate the state of a workflow activity (i.e. an activity is scheduled, activity completes or fault is thrown).

· Bookmark resumption tracking record: A bookmark resumption record tracks any bookmark that is successfully resumed

· User tracking records. A workflow author can create custom tracking records within a custom workflow activity and emit them within the custom activity. Custom tracking records can be populated with data to be emitted along with the records.

Out of the box in WF 4.0 we provide an ETW (Event Tracing for Windows) based tracking participant. The ETW tracking participant writes the tracking records to an ETW session. The participant is configured on a workflow service by adding a tracking specific behavior in a config file. Enabling ETW tracking participant allows tracking records to be viewed in the event viewer. Details of using the ETW based tracking participant will be covered in a future post. The SDK sample for ETW based tracking is a good way to get familiar with WF tracking using the ETW based tracking participant.

In future posts we will discuss the WF tracking feature in depth. Topics covered will include tracking profiles and tracking records, ETW tracking participant, writing custom tracking participants, variable extractions and unified tracking and tracing.

Cross-posted from the Silverlight Web Services Team Blog.

Silverlight 3 Beta introduces a new way to improve the performance of web services. You have all probably used the Silverlight-enabled WCF Service item template in Visual Studio to create a WCF web service, and then used the Add Service Reference command in your Silverlight application project in order to access the web service. In SL3, the item template has undergone a small change that turns on the new binary message encoder, which significantly improves the performance of the WCF services you build. Note that this is the same binary encoder which has been available in .Net since the release of WCF, so all WCF developers will find the object model very familiar.

The best part is that this is done entirely in the service configuration file (Web.config) and does not affect the way you use the service. (Check out this post for a brief description of exactly what the change is.)

I wanted to share some data that shows exactly how noticeable this performance improvement is, and perhaps convince some of you to consider migrating your apps from SL2 to SL3.

When Silverlight applications use web services, XML-based messages (in the SOAP format) are being exchanged. In SL2, those messages were always encoded as plain text when being transmitted; you could open a HTTP traffic logger and you would be able to read the messages. However using plain text is far from being a compact encoding when sending across the wire, and far from being fast when decoding on the server side. When we use the binary encoder, the messages are encoded using a WCF binary encoding, which provides two main advantages: increased server throughput and decreased message size. 

Increased server throughput

Let’s examine the following graph (hat tip to Greg Leake of StockTrader fame for collecting this data). Here is the scenario we measure: the client sends a payload, the server receives it and sends it back to the client. Many clients are used to load the service up to its peak throughput. We run the test once using the text-based encoding and once using the new binary encoding and compare the peak throughput at the sever. We do this for 2 message sizes: in the smaller size the payload an array with 20 objects, and in the bigger one the payload is an array with 100 objects.

Some more details for the curious: The service is configured to ensure no throttling is happening, and a new instance of the service is created for every client call (known as PerCall instancing). There are ten physical clients driving load, each running many threads hitting service in tight loop (but with small 0.1 second think time between requests) using a shared channel to reduce client load. The graph measures peak throughput on the service at 100% CPU saturation. Note that in this test we did not use Silverlight clients but regular .Net clients. Since we are measuring server throughput it is not significant what the clients are.

When sending the smaller message we see a 24% increase in server throughput, and with the larger message size we see a 71% increase in server throughput. As the message complexity continues to grow, we should see even more significant gains from using the binary encoder.

What does that mean to you? If you run a service that is being used by Silverlight clients and you exchange non-trivial messages, you can support significantly more clients if the clients use SL3’s binary encoding. As usage of your service increases, that could mean being able to save on buying and deploying extra servers.

Decreased message size

Another feature of the binary encoder is that since messages sent on the wire are no longer plain-text, you will see a reduction in their average size. Let’s clarify this point: the main reason you would use the binary encoding is to increase the service throughput, as discussed in the previous section. The decrease in message size is a nice side-effect, but let’s face it: you can accomplish the same effect by turning on compression on the HTTP level.

This test was far less comprehensive than the previous one and we did it ad-hoc on my co-worker’s office machine. We took various objects inside a Silverlight control, and turned them into the same kind of SOAP messages that get sent to the service. We did this using the plain-text encoding and using binary encoding and then we compared the size of the messages in bytes. Here are our results:

The takeaway here is that the reduction of message size depends on the nature of the payload: sending large instances of system types (for example a long String) will result in a modest reduction, but the largest gains occur when complex object graphs are being encoded (for example objects with many members, or arrays).

What does this mean to you? If you run a web service and you pay your ISP for the traffic your service generates, using binary encoding will reduce the size of messages on the wire, and hopefully lower your bandwidth bills as traffic to your service increases.

Conclusion

We are confident that binary encoding is the right choice for most backend WCF service scenarios: you should never see a regression over text encoding when it comes to server throughput or message size; hopefully you will see performance gains in most cases. This is why the binary encoder is the new default in the Silverlight-enabled WCF Service item template in Visual Studio.

An important note: binary encoding is only supported by WCF services and clients, and so it is not the right choice if you aren’t using WCF end-to-end. If your service needs to be accessed by non-WCF clients, using binary encoding may not be possible. The binary AMF encoding used by Adobe Flex is similarly restricted to services that support it.

This morning, I’m pleased to announce that the team has posted four initial Windows Workflow Foundation (WF) migration guidance documents to help current WF developers evaluate the new WF programming model that is being introduced in .NET Framework 4.

The documents were written by the PM team to help describe the relationship between the existing WF technology that was introduced in .NET 3.0 (defined as the types in the System.Workflow.* namespaces; referred to in the documents as WF3 for simplicity and brevity) and the new WF technology that is being released in .NET 4 (the System.Activities.* namespaces; referred to in the documents as WF4). The team explains how to think of WF features within the two programming models, and the choices you have as a user or a potential user of workflow technology in .NET 4.

Because this is a very broad topic, we’ve broken up what was initially going to be a single paper into about eight. There is an overview document and [currently] seven papers that take the form of either higher level guidance and cookbook papers. Today’s initial release introduces the higher-level guidance documents, with the cookbooks to be released in the coming weeks.

As the documents are updated, we will be releasing them to the WF Migration Guidance download on the MS Download Center, and the accompanying source code will be posted on a WF Migration Guidance project on the MSDN Code Gallery.

The document list looks like the following:

• WF Migration Overview (Now Live!)
  Overview of the document collection and an initial starting place for the WF3 developer
• WF Migration: Best Practices for WF3 Development (Now Live!)
  How to design WF3 artifacts so they are more easily migratable to WF4
• WF Guidance: Rules (Now Live!)
  Discussion of how to bring rules-related investments forward into .NET 4
• WF Guidance: State Machine (Now Live!)
  Discussion of WF4 control flow modeling in the absence of a StateMachine activity
• WF Migration Cookbook: Custom Activities (Coming Soon)
  Examples and instructions for redesigning WF3 custom activities on WF4
• WF Migration Cookbook: Workflows (Coming Soon)
  Examples and instructions for redesigning WF3 workflows on WF4
• WF Migration Cookbook: Workflow Services (Coming Soon)
  Examples and instructions for redesigning WF3 workflow services on WF4
• WF Migration Cookbook: Advanced Custom Activities (Coming Soon)
  Examples and instructions for redesigning advanced WF3 custom activities on WF4

The papers will continue to be grown and updated as we move towards the RTM release – to address a larger number of usage scenarios, and to address any changes that happen between pre-releases. We’ve been working on the documents over the last month, and think that they provide some good initial thoughts on how to approach the technology; and we hope that you find them helpful

The team will be supporting feedback and requests for the documents and accompanying sample code in the WF 4 forum on MSDN. I’m told the feature PMs will be creating a thread for each document to make it easier to provide feedback and for the PMs to respond – we should have more information on that in the next few days.

This blog post introduces the Project and Item templates for Workflow 4.0. It also clarifies as to how the Workflow 3.0 templates are still available for users to create projects and then upgrade them to the 4.0 Framework.

We are putting in a deep though into what kind of templates do users want? Do they help users get kick started with the kind of application they typically want to create? How much setting changes the user might have to do for his applications? Is it an accurate reflection of the OM? Do we have too many/too less templates? So what do you think? What would you prefer to see/not to see? Are the names intuitive enough? Please let us know so that we can update them in time for the VS 2010 release.

Thanks,

Kushal.

 

Continuing on the theme of Workflow 4.0 blog, this blog post talks about the enhancements and features provided for debugging in Workflow 4.0.

The blog post talks specifically dwells into the seamless debugging between the Xaml view and the Designer view of the Workflows. Most of the features provided in Workflow 3.0 Debugging re still provided as well. Also, please be on the look out for the blog post as to how you can use the DebugService now public in Workflow 4.0 for creating tools like Simulators, Monitoring and Re-hosted Debugging.

Thanks,

Kushal.

WF4 beta 1 ships with a comprehensive set of activities (more than 35) that you can use to author your workflows or to create your own custom activities. This post will give you a quick tour through the activity palette and introduce you to the key characteristics of the out of the box activities.

Activities are the unit of work in a workflow program. Activities in WF4 have a signature and body. The signature of an activity is defined in terms of its public arguments. These public arguments define the data flow into and out of an activity. The body of an activity is a chunk of execution logic that may execute over multiple pulses of work. This logic can be expressed declaratively in terms of other activities or with imperative code.

Quick note: As you may have noticed, the activities in the toolbox are not sorted alphabetically. This is something that we are aware of and that will be fixed in the next Beta. For Beta1, if this bothers you, you can simply right-click in the toolbox and choose "Sort Items Alphabetically" and it will sort the items for you for easy discoverability.

Procedural

Procedural activities provide a mechanism to model sequential control flow using concepts you know from standard procedural languages like C# or VB like if, assign, while, etc. Procedural activities include the basic building blocks to represent sequential behavior, including control of flow, method invocation on CLR objects, collection manipulation, and error handling. It also covers advanced scenarios like parallel activities, transaction management, compensation, cancellation, and persistence. The table below contains all the activities in the procedural category. The words in bold in the description of each activity represent its most important arguments.

Activity	Description	Designer
Collection Management
AddToCollection<T>	Adds an Item to a Collection.
RemoveFromCollection<T>	Removes an Item from a Collection.
ClearCollection<T>	Clears a Collection, removing all items stored in it.
ExistsInCollection	Verifies if an Item exists in a Collection. If the item exists, its Result argument will yield True.
Control of Flow
If	The If activity selects a child activity for execution based on the value of a Boolean expression. If the Boolean expression Condition yields True (and “Then” activity is configured), the “Then” activity is scheduled. If the expressions yields False (and “Else” activity is set), the “Else” expression is scheduled.
DoWhile	Executes its Body until the Condition evaluates to True. The Body will be executed at least once.
ForEach / ForEach<T>	ForEach activity contains a list of Values and a Body. At runtime, the list is iterated and the body is executed for each value in the list.
Pick	The Pick Activity provides event-based control flow modeling in WF. The only valid children for a Pick activity are PickBranches. At the beginning of a Pick execution, all the Trigger activities from all its Branches are scheduled. When the first Trigger completes its corresponding Action activity is scheduled, and all other Trigger activities are canceled.
PickBranch	PickBranch represents a branch in a Pick. It consists of a Trigger and Action. PickBranch can only be added to a Pick activity.
Sequence	The Sequence activity allows for the execution of one or more Activities in order.
Switch<T>	Switch activity is similar to switch statement in C#. It contains an Expression and a set of Cases (each case has a key and an activity). After the expression is evaluated, the Switch activity looks for a Case with a key that matches the result of the expression and if found, it schedules the activity associated with that Case.
While	The While activity executes it's Body while a Boolean Condition is True.
Parallel Execution
Parallel	Parallel activity allows parallel execution of its children. It operates by scheduling each WorkflowElement in its Branches collection at the beginning of its execution.  It completes when all of its Branches complete or when its CompletionCondition property evaluates to true.
ParallelForEach /  ParallelForEach<T>	The ParallelForEach activity enumerates the elements of a collection(Values) and executes an Activity for each element of the collection, in a similar way than the ForEach activity does. The main difference is that the embedded statement is executed in a parallel fashion. Just like the Parallel Activity, ParallelForEach has a CompletionCondition, so that the ParallelForEach activity could complete early if the evaluation of the CompletionCondition returns true. The CompletionCondition is evaluated after each iteration is completed.
Error Handling
TryCatch	TryCatch activity is similar to the try..catch construct in C#: all activities in the Try block are executed and if an exception occurs, it will schedule the Catch block that best matches that exception (if no matching catch is found, the workflow is aborted). All Catch blocks are contained in a collection called Catches. TryCatch activity also has a Finally block that is executed after the Try (and any eventual Catch). A note on unhandled exceptions: TryCatch provides exception handling at the workflow level. When an unhandled exception is thrown, the workflow is aborted and therefore the Finally block won’t be executed. This behavior is consistent with C#.
Catch<T>	Represents one catch block to be used in a TryCatch activity. If an exception is thrown within a Try Element, the TryCatch will attempt to find a matching Catch element based on the type of the thrown exception. Catch<T> can only be used inside a TryCatch activity
Throw	Throw activity throws an exception within a workflow. Throw activity has an Exception property that contains the exception that will be thrown at execution time.
Utilities
Assign	The Assign activity assigns the value of its Value argument to its To argument. The types of both arguments must be compatible. This compatibility is verified at runtime.
Delay	Delay Activity, as its name suggests, will block the current workflow execution path for a Duration specified by user. After the duration expires, the workflow continues execution as expected. The duration of the delay is set using a TimeSpan.
InvokeMethod / InvokeMethod<T>	InvokeMethod is the activity that allows you to call an existing CLR instance or static method. To invoke a method all you need to do is provide the owner of the method (TargetType for static methods, TargetObject for instance methods), the MethodName, and its Parameters. InvokeMethod supports the following method invocation scenarios: · Public instance and static methods · Parameter passing by value and by reference · Support for parameter arrays · Support for generic parameters · Asynchronous method invocation
WriteLine	Writes text to the configured output console. Writing beyond the System.Console WriteLine has a TextWriter argument can be configured to write to different outputs. For example, we can configure the TextWriter property to send the text to an ASP.NET page. If the TextWriter is not set, it will be set by default to the System Console.
Advanced (Cancellation, Compensation, Transactions, and Persistence)
CancellationScope	The CancellationScope activity consists of two main parts, the Body and the CancelHandler. The body is the code path that normally executes. If the activity gets canceled, then the cancel handler is called.
CompensatableActivity	CompensableActivity is used to define a potentially long running activity with accompanying Compensation and Confirmation logic. Compensation allows the user to specify corrective action to be taken on an activity based upon activity which occurs after the successful completion of the Body of the activity.
Compensate	Compensate is used to explicitly invoke the compensation handler of a CompensableActivity.
Confirm	Confirm is used to explicitly invoke the confirmation handler of a CompensableActivity.
Persist	Persists the workflow instance. Persistence will be done using the configuration of the WorkflowInstance that is being executed (this activity doesn’t have any arguments).
TransactionScopeActivity	The TransactionScopeActivity provides the mechanism for initializing a new transaction, making the transaction handle ambient (a workflow execution property) and calling complete on the transaction once the Body of the TransactionScope activity has completed. TransactionScopeActivity supports “Requires” semantics. If there is already an ambient transaction it is used, else a new one is created. Nested transaction scopes: TransactionScopeActivity can be nested in another TransactionScopeActivity. A TransactionScopeActivity nested in another TransactionScopeActivity will use the existing transaction.

Flowchart

Flowchart is a new modeling style that we have introduced in WF4. Flowchart is a well known and intuitive paradigm to visually represent business processes. Business Analysts, Architects and Developers use often flowcharts as common language to express processes. 

Flowchart is a very powerful construct since it provides the simplicity of sequence plus the ability of looping back to a previous point of execution. All this is conveyed using a very well known conceptual paradigm that is common across several disciplines beyond computer science!

Activity	Description	Designer
Flowchart	This is the root for a Flowchart. Since Flowchart is an activity like any other, it can be composed inside any container activity. For example, we can add a Flowchart inside of a Sequence or a Flowchart inside another Flowchart. The green ball in the image at the right represents the start node of the Flowchart.
FlowDecision	FlowDecision models conditional forks within a Flowchart. It can be seen as the equivalent of the procedural If activity in the Flowchart world. This activity contains a Boolean expression Condition. If the expression evaluates to “True”, the true path is executed (otherwise, the false path is scheduled).
FlowSwitch	FlowSwitch activity selects a next node depending on the value of an expression. FlowSwitch can be seen as the equivalent of the procedural Switch activity in the Flowchart world.

Messaging

The WF4 Messaging Activities are designed to support message-oriented workflows and provide better integration of messaging into workflows. They enable workflows to send data out to other systems and receive data from other systems. These activities can be composed together and along with correlation can model many complex Message Exchange Patterns.

Activity	Description	Designer
Receive	Models one way receive of a message. It can receive data of the following types: Message, DataContract types, XmlSerializable types, and MessageContracts.
ReceiveAndSendReply	This activity template represents a correlated Receive activity and SendReply activity. By using this template you can wait for an incoming message and then send a reply to the sender. Since the Receive and the SendReply are inside a sequence, you can add any activity between them.
Send	Models one way send of a message. It can receive data of the following types: Message, DataContract types, XmlSerializable types, and MessageContracts. This activity can be used in two ways: 1. Client: this activity can be used to send a request to a service. This is equivalent to a WCF client calling a service operation. No contract inference is performed on the client side. 2. On the server side the Send activity can be used to send a reply to a previous Receive. In this case the Send and Receive activities must have the same OperationName, Action and CorrelationHandle.
SendAndReceiveReply	This activity template represents a correlated Send activity and ReceiveReply activity. By using this template you can send a message and then wait for a reply from the destination. Since the Send and the ReceiveReply activities are inside a sequence, you can add any activity between them.

PowerShell

PowerShell activities, as their name imply, allow invoking PowerShell cmdlets (commandlets) and scripts from WF programs.

Please note that while these activities are included by default in the Beta1 toolbox, they will not be available in the final RTM bits when we release. This is because .NET Framework does not allow taking a dependency on a technology that does not ship in the framework. We're working on a longer term strategy here since many customers have requested PowerShell activities. For RTM, you will find these activities in the SDK samples instead.

Activity	Description	Designer
InvokePowerShell	Invokes a PowerShell cmdlet that does not have a return value. InvokePowerShell can be used to invoke simple cmdlets and scripts. We can also pass parameters and input objects to the cmdlet. After execution, the activity provides a set of errors (if any occurred).
InvokePowerShell<T>	An activity that invokes and retrieves the resultant output from a PowerShell cmdlet. This flavor of the activity has all the same arguments than the non-generic version plus an InitializationAction. The InitializationAction is used to map the results of the execution of the cmdlet to variables in our workflows.

Migration

WF 3.x and 4.0 can exist side by side, but you can also use WF 3.x activities in WF4 workflows using the Interop activity.

Activity	Description	Designer
Interop	The Interop activity is a WF4 activity that wraps a WF3 activity (a non-abstract CLR type that derives from System.Workflow.ComponentModel.Activity) thus allowing the WF3 activity to be used in WF4 workflows.  Note that the WF3 activity can be a single leaf activity, or an entire compiled workflow (tree of activities). The Interop activity bridges the WF4 and WF3 activity execution models, facilitates data flow across the interop boundary, and enables persistence and tracking of WF3 activity instances within WF4 workflow instances. The Interop activity allows WF developers to move to the WF4 model in an incremental fashion: · Quickly experiment with WF4 using existing WF3 activity artifacts · Wrap WF3 activities the developer isn’t ready to redesign on the WF4 model · Wrap WF3 activities for which the developer doesn’t own or possess the source code (e.g. they purchased the activity from a third party)

Wrapping up

It’s been a long tour, hasn't it? And this is just the beginning! There are a lot of new exciting features in WF4 and we are eager to share them with you in future posts.

This post is an introduction to the activities that we are shipping in the activities toolbox. If you want to see these activities in action, please check our WF samples. A good starting point are the samples under the folder %SamplesRoot%\WF\Built-InActivities.

We are keenly interested in understanding your scenarios and ideas, and helping you accomplish your goals on WF4.  We’d appreciate your feedback (both positive and critical), and we look forward to continued dialogue about the activities that you would like to see in WF toolbox. We look forward to hearing from you!

Matt Winkler, a Program Manager on the Workflow designer team has kicked off the blogging frenzy with his tour of the workflow designer.

Matt walks through how you can continue to create 3.x workflows in the VS 2010 using the same familiar experience you had in 3.x. He then walks you through the experience of creating a 4.0 workflow using the new WF designer in VS 2010 and introduces concepts along the way - Arguments, Variables, a quick tour of the Activities you will find in the toolbox, Validation in the designer, expression editing, navigating through the workflow etc. I hope the post gives you a good flavor of some of the basics. Over the next few weeks and months, the team will continue to post additional content here and on MSDN going over the various pieces in more detail. Till then, happy experimenting...

 

Yes! It's time. Visual Studio 2010 and .NET Framework 4.0 Beta1 is available for general download now. Go get it here.

The Beta1 bits include significant updates to WCF and WF bits since our last CTP at the PDC last year. We're excited to share these bits with you, and we've created a few resources to help you explore:

• SDK Samples for WCF and WF: Go get them here
• Readmes for Samples: This link provides documentation of the samples you will find in the SDK
• WCF WF Training Kit: Go get it here

We're very interested in your feedback - good and bad. We've created a few forums where you can provide feedback to us. The product team will be monitoring these forums, and we hope to create a good dialog with you. In addition, this would be a great place where the community can share information among themselves on WCF and WF. 

• WF Forum
• WCF Forum

Happy developing with WCF and WF 4.0!