How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)?  
Author Message
John Portnov





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

Tom/Vihang/All WWF Gurus,

Can someone please provide an example of how to host WWF 3.0 workflows as a webservice, instead of using IIS (ASP.NET) to call and host XOML only workflows

Tom has provided examples of ASP.NET hosting and calling XOML only workflows (using tracking and persistence). I need to do the same with a centralized web service. The labs provided with WWF 3.0 are very similar to WWF 2.0 labs. I cannot find any examples that offer samples on how to host workflow runtime services via a webservice that can be consumed by one or more websites (on one or more webservers).

MS suggests using a centralized webservice to host workflow runtime services, instead of using IIS. Unfortunately I did not find any code examples (I am using WWF 3.0).

Any help would be appreciated.

Thanks in advance,

John Portnov




Software Development for Windows Vista12  
 
 
smc750





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

Dino Esposito wrote a great article on exposing a workflow as a web service in the April issue of MSDN.

http://msdn.microsoft.com/winfx/technologies/workflow/default.aspx pull=/msdnmag/issues/06/04/cuttingedge/default.aspx

smc750



 
 
John Portnov





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

Smc750,

I am not trying to "expose a workflow as a Web service and invoke a Web service from a workflow" (which is what Dino's article talks about).

I need to host the workflow runtime services (which are used by workflows) in a separate web service. This is different than what the article talks about.

Sincerely,

John Portnov



 
 
Serge Luca





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

John,

what about storing the workflowRuntime in the HttpApplication object of a standard web service

This can be achieved in global.asax or by creating an HttpModule

Serge

 
 
John Portnov





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

Serge,

The question is not just how/where to store the workflow runtime webservice, but also where to store the other associated workflow services (including ExternalDataExchange, etc.) and where to add workflow event delegates.

Tom/Jon/Vihang/WWF Gurus,

Tom created an example that uses ASP.NET with XOML only workflows that implements sql tracking and persistence (with the same connectionstring).  Can someone please modify Tom's example to host the workflow runtime services and event delegates as a web service

I need to be able to have a web server farm that uses workflow runtime in a centralized place.  This way the ASP.NET (IIS) is not hosting the workflow runtime (regardless whether it is in global.asax or httpModule) and its relevant services and workflow events.

If ASP.NET is the correct way to host the workflow runtime and you should do it for each web server in a web server farm, then I am asking the wrong question (but my Manager came from TechEd and told me that MS WWF gurus said that a centralized web service is the correct way to host workflow runtime service and all its relevant code).  I need a sample to get started.  So far I have Tom's examples using ASP.NET and XOML tracking and persistence in a single ASP.NET website.

I look forward to hearing from you soon.

 

Sincerely,

John Portnov



 
 
John Portnov





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

Serge,

How would I declare delegates for workflow events that could be persisted for each workflow I need a code sample that would remove the workflow code from the website (I need to host workflow separately from the web server farm; and also raise workflow events separately).

John P.



 
 
Tom Lake





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

If your manager got the idea that Microsoft was suggesting that hosting your workflow in a centralized web service was the best way to go I am sorry but that it not true.  It might be depending on your environment / scenario but is not best for all.  Hosting your workflow as a web service gives you the flexibility of being able to call into the workflow from anywhere that you can make a web service call.  Using a web service will not work with xoml only workflows since the workflow needs to be compiled.

Please use WF as an abbreviation for Windows Workflow Foundation, not WWF.



 
 
John Portnov





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

Tom/WF Gurus,

If I want to separate web server farm from Workflows hosting (using WF 3.0), what is the best way to do it

I am confused by the comment "you cannot do it because XOML workflows need to be compiled".

I look forward to hearing from you soon.

Sincerely,

John P.



 
 
Tom Lake





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

If I want to separate web server farm from Workflows hosting (using WF 3.0), what is the best way to do it

What do you mean by “separate web server farm from Workflows hosting” The best choice for hosting the workflow runtime is really dependent on the scenario. Can you describe yours

I am confused by the comment "you cannot do it because XOML workflows need to be compiled".

A workflow that is published as a web service must be compiled so you can not use a xoml only workflow that does not contain the x:Class attribute. I thought your first post was asking about using a xoml only workflow hosted in a web service. After re-reading I realize that wasn't what you were asking.



 
 
John Portnov





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

Tom,

My question was how to "host WWF 3.0 workflows (not workflow) as a webservice". 

Let me clarify my question: Currently we have a website that is very similar to your ASP.NET website that calls XOML only workflows.  We are going to have high usage of workflow processing and need to architect for the future.  If we can separate IIS hosting from workflow hosting, we will not have to recycle IIS everytime we need to restart the WorkflowRuntime service; and we will be able to scale many websites using one workflow runtime service.  In order to be able to scale multiple websites with a dedicated workflow runtime environment, we need to move the workflow calling code into a webservice (According to Matt Winkler at TechEd).  Is there a better way

Let me know if you need more clarification.

 

Sincerely,

John Portnov



 
 
Matt Winkler -- MSFT





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

This has also been posted here as an article on my blog.


John,


Good discussion, I’m going to be posting this to my blog to get some wider exposure and comment for this important topic!

First, let me try to clear things up.  Tom is right above, there is no "one best way" to host the workflow runtime, that's really the beauty of the model, you can host it in a windows forms app, or you can scale it up and out to a clustered setting.

That being said, let's look at some of the hosting options we have available to us in a web application, some of the reasons you'd pick one over the other, as well as some of the issues you will face in implementation.  I'll try to rank these in some order of increasing complexity of implementation.  I also try to look at the implication of having declarative (XAML-only) workflows in each scenario.

Workflows inline to ASP.NET

This is somewhat the "simplest" model, and it is what you see in many of the samples surrounding ASP.NET hosting of workflows and using the ManualWorkflowSchedulerService.  In this case, you create a workflow runtime and store it in the same appdomain (and IIS instance) of your application.  You typically start and stop the runtime in the app_start / end events, although you could expose administrative functions to reset the runtime, although I'd be interested in why you'd want to do that.  If you needed multiple runtimes you can host them in the same appdomain in basically the same way, just store them with different application variable keys.  Again, I'm not sure what scenario would neccessitate different runtimes in the asp.net process, so please let me know what you're thinking about doing here. 

Now, if you do this with the SQL persistence service, this will allow scaling out to a farmed environment, thus having multiple runtime instances correlating to each box in the farm.  I'd be careful about how much work you're doing in the workflow, I would think you would want to return relatively quickly to the web page to allow rendering.  In the declarative case, this could be tricky if you are enabling editing of your workflows because you wouldn't want to place a "getManagerApproval" activity in the middle of a workflow that only takes place between postback-to-render.

Long running workflows hosted inside ASP.NET

In this case, the lifetime of the workflow is extended beyond postback-to-render to enable the web application interacting with workflow throughout the life of a process, which may span multiple pages.  Many of the samples showing page flow are examples of this.  The implementation is very similar to the above, except instead of a page starting a workflow, you are really sending in an event to a waiting activity and either waiting for the next "pause", or sending a one-way message and continuing with rendering the page.  One issue to watch out for here is taking up a number of threads in IIS if you are not using the ManualWorkflowSchedulerService.  There are some runtime properties that allow you to set the maximum number of threads.  You'd want to look at this relative to the number of threads you are allowing IIS to make sure that your web pages still get served.  Many of these scenarios cause people to start looking outside of the ASP.NET app to host the business logic (think of the tier approach, where you really separate this into a distinct business process tier).  Which leads to the next case:

Long Running Workflows Exposed as Web Services Generated by Visual Studio

This is what happens when you click "Publish as a web service" on an existing workflow.  Due to the way this process works, the web service has to be created against a compiled workflow, which means the web service can't be executing a dynamic, declarative version on the fly.  The runtime is still hosted in IIS, but it will be within a different application than your ASP.NET application for management and portability.  If you need to provide the workflow with any services, you will need to do this via the config file, but in this way, you can plug in any of the runtime services that you need. Again, this doesn't address the scenario of XAML-only workflows, but by incorporating multiple web service input and outputs, you can create a centralized workflow runtime (or a set of them in a farmed environment) that multiple applications can interact with over the course of the lifetime of the workflow. 

This is a model to consider when you have
? Multiple applications that interact with a running workflow
? Need to separate (for management, perf, etc) the workflow from your presentation layer

This model won't work, and you'll need to consider one of the following two if:
? Need to execute declarative workflows
? Need very fine grained control over the web service exposure (incorporating WSE / WCF, specific WSDL / XSD implementations, etc)

Long running workflows exposed as a Web Service You Create

This solves two of the problems above, handling declarative workflows and fine grained control over the web service implementation, at the expense of not being able to click and generate the web service facade for you.  The way to implement this would be to take Tom's sample of XAML-only workflow being executed from an ASP.NET application, and place that into an ASMX web service project.  Instead of handling a button click on a web form, you'll expose a WebMethod that gathers whatever parameters you need, interacts with the runtime that will again be hosted the same way (within an application level variable for instance), and executes the workflow.  Your workflow would not need to have the web service activities in it, rather it could simply have a HandleExternalEvent or some other activity waiting on a message.

This gives you some flexibility in having some methods that execute an entire workflow, and others that simply inject a message.  It would be here where you could also handle the XAML activation needed for the XAML-only scenario.  This has an advantage over the previous approach in that it truly de-couples the web service (the choice of messaging implementation) from the business process (the workflow).  Again, this is going to come at the cost of having to write a little bit of web service code.  I've written a note to try to write this up as a sample in the next day or two.  This also leads into the next approach in the line of de-coupling the workflow from the messaging implementation.

Long Running Workflows Hosted in a Windows Service

You are also welcome to use a Windows service as a host for the workflow runtime and your workflows.  Some people like this because it provides additional / different flexibility in management.  The trick is to then expose the workflow communication points through the Windows service, which you can do in whatever means you see fit (MSMQ, socket-based communication, other message passing).  If you look at our expense reporting sample, you see two applications communicating with a workflow living in a third application via WCF.  in this case WF is hosted within a console app, but that could be wrapped in a Windows service.  Using the SqlPersistenceService will still give you the ability to execute in a farm, but you'll probably need some mechanism to handle load balancing and message routing (this is why IIS is a convenient hosting mechanism, you can get a lot of that "for free" in IIS).

This comes at the expense that it is one of the more complicated development scenarios, but one that definitely enables the use of long running workflows in scenarios where IIS is not appropriate or possible, such as in a long running client side workflow.  This also may fit the scenario when you want to allow maximum throughput on your web app, so all you do is drop a message in a queue (relatively inexpensive) and  go on with processing your page.

The Windows service approach is what a number of people are doing who want to expose portions of the workflow via WCF endpoints.  There was a presentation given at TechEd that talks about how this scenario is going to improve down the road with future versions of WF, so look for that when the sessions are available.

Finally, the End!

In short, you’ve got a whole lot of options available to you when you chose where to host the workflow runtime and execute your workflows.  I hope this shows some of the options you have available, why you might chose them, how to start going about implementing them, and also some things to look out for.  Let me know if I missed something or if you have any questions.

Matt



 
 
John Portnov





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

Matt,

Thanks for the WF info.

We have XOML only State workflows (mostly mutliple events and long-running workflows). We start a workflow and post the next event to the grid (where the user clicks on the button of the event) which the user interacts with to continue working with the workflow. It would be ideal to de-couple the websites from the Workflow runtime service.

I do not want to use SQLPersistence service to manage multiple workflow runtimes (with locking). I will try to use one workflow runtime service in a centralized environment, regardless how many webservers have our website in a webserver farm (we do not have a web server farm yet).

The options are: separate custom webservice, windows service, or console app to manage workflow runtime. I am not clear about the specific implementations when thinking about our situation (we are going to have high concurrency and high usage of XOML only state workflows-most of which will be long-running workflows with more than one event).

If I choose the webservice option, I also need to generate event delegates for WorkflowCompleted, workflowTerminated events. It is not as simple as just loading XOML only workflows and running them. A webservice call will not persist to/listen for a workflowCompleted event implementation. A windows service may be a better option, but I need to be able to call into it from the website from one or more webservers. I am not sure how the console application could fit into our environment.

Now that you know more about our environment, do you have any suggestions about de-coupling our workflow processing (for XOML only WF 3.0 State workflows) and using only one instance of the Workflow runtime to manage all the workflows (while being able to declare WorkflowCompleted events and listening to their callbacks for each XOML workflow). The webpage postbacks when implementing the delegate for WorkflowCompleted event (this will not work in a webservice context).

We are using SQL2005, Windows 2003 Server, VS.NET 2005, WF 3.0 XOML only workflows in our ASP.NET environment (IIS 6.0).

We are trying to plan our architecture for the future and need to do it right.

I look forward to hearing from you soon.

Sincerely,

John Portnov



 
 
Matt Winkler -- MSFT





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

We have XOML only State workflows (mostly mutliple events and long-running workflows). We start a workflow and post the next event to the grid (where the user clicks on the button of the event) which the user interacts with to continue working with the workflow. It would be ideal to de-couple the websites from the Workflow runtime service.

I do not want to use SQLPersistence service to manage multiple workflow runtimes (with locking). I will try to use one workflow runtime service in a centralized environment, regardless how many webservers have our website in a webserver farm (we do not have a web server farm yet).

If you have multiple servers in a webfarm, you are going to have an instance of the runtime on each server, otherwise there will only be one server doing any work. This would be fine if you are using a webfarm for redundancy, but not for scaling out. The SQLPersistence service does not manage multiple runtimes in the classic sense of managing, rather, it is built in a fashion that will function if multiple runtimes are using the same database to store persistence information. This does give you the ability to scale out with relatively minor hassles though, if you start with only one box.

The options are: separate custom webservice, windows service, or console app to manage workflow runtime. I am not clear about the specific implementations when thinking about our situation (we are going to have high concurrency and high usage of XOML only state workflows-most of which will be long-running workflows with more than one event).

If I choose the webservice option, I also need to generate event delegates for WorkflowCompleted, workflowTerminated events. It is not as simple as just loading XOML only workflows and running them. A webservice call will not persist to/listen for a workflowCompleted event implementation. A windows service may be a better option, but I need to be able to call into it from the website from one or more webservers. I am not sure how the console application could fit into our environment.

The console application is simply the way it is implemented in that example. You could very easily take the code from that and put it into a windows service, but I don't think I'd recommend to anyone to have a highly available workflow service hosted in a console app, a service (web or Windows) gives you the managability there that you'd have to write for yourself. Since most of your workflows are long running and you want to wire up events, you can still handle that within your service / web service. When you start up the runtime is where you are attaching to your events and those will be called within the context of the hosting process. So, the workflow completed event is going to be called in whichever host hold the runtime that is executing when the workflow completes. You would need to build up some form of messaging back to a client application if you are hosting these in a remote service and need to wait for the results of the event. Some examples that come to mind range from simple (a record in a database that the client is looking for) to complex (using a bi-directional WCF channel to send messages back, which may not be appropriate with an ASP.NET client) to the in-between (placing a record in an MSMQ that the client is looking for). You can only listen for the callbacks within the process that is hosting the WF runtime, but from there you could send a message back to a client.

Now that you know more about our environment, do you have any suggestions about de-coupling our workflow processing (for XOML only WF 3.0 State workflows) and using only one instance of the Workflow runtime to manage all the workflows (while being able to declare WorkflowCompleted events and listening to their callbacks for each XOML workflow). The webpage postbacks when implementing the delegate for WorkflowCompleted event (this will not work in a webservice context).

We are using SQL2005, Windows 2003 Server, VS.NET 2005, WF 3.0 XOML only workflows in our ASP.NET environment (IIS 6.0).

To me, it sounds like you are looking for the following:

  • Scalability / farmed workflow servers
  • XAML only workflows
  • Called from a web app

The two choices that seem most appropriate to me are developing a custom web service facade to interface with an IIS hosted workflow runtime, or developing a Windows service to host the runtime and exposing some form of communication interface for the ASP.NET app to call. A mix of these two approaches would be to have a custom web service that communicates to a Windows service that is hosting the runtime. In terms of getting callbacks to the client, you can either have a web service not return until the "work" is complete (waiting for an event or some such thing) and then pass data back to the client in the return value of the web service, or you could have some communication channel back to the client in order to get messages to process (a queue, a database) later on.

Again, a lot of this depends upon the nature of the workflows, the hosting requirements as well as the communication patterns required (one-way, two-way synchronous, two-way asynchronous) used to solve the business problem. From what you've described, either of the above choices should enable you to have a scalable solution that leverages XAML only, declaritive workflows that your web apps (as well as smart clients, mobile apps) will be able to use.



 
 
John Portnov





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

Matt,

"When you start up the runtime is where you are attaching to your events and those will be called within the context of the hosting process. " as you mentioned is a problem.

If I am raising two events (each in a different state,  in an XAML only workflow) and need to listen to a WorkflowCompleted event, how would I implement this with a centralized webservice and windows service   I would have to declare the event delegates (WorkflowCompleted, WorkflowTerminated) each time I call the webservice for the same instance of XAML workflow (and for each event - because I do not know whether the XAML workflow may require more or less events before Completed or Terminated event needs to be called).  Note that the webservice would have to be generic for XAML only state workflows (one workflow may have 2 events, another may have 6 events - It would be nice to declare the event delegates only once and have them persist between webservice calls for the same instance of an XAML workflow GUID).

When using the webservice, can I use the global.aspx the same as in the website to manage the Workflow runtime service

Can you please provide a simple code example to help me get an idea and start this design

BTW:

"In terms of getting callbacks to the client, you can either have a web service not return until the "work" is complete (waiting for an event or some such thing) and then pass data back to the client in the return value of the web service, or you could have some communication channel back to the client in order to get messages to process (a queue, a database) later on.   "

I cannot do what you said above because I need to make a call for each event in different states to the webservice from the webserver.  Thus, I do not know when to listen for the WorkflowCompleted event.  Also, one of the output parameters in the WorkflowCompleted event is a ComponentOne report object.  I am not sure about the best way to return this object to the website from the webservice (assuming I am able to correctly intercept WorkflowCompleted and WorkflowTerminated events).   Any ideas

 

Thanks in advance,

John Portnov

 



 
 
Matt Winkler -- MSFT





PostPosted: Windows Workflow Foundation, How do you host WWF 3.0 as a webservice (instead of using ASP.NET as a host)? Top

If I am raising two events (each in a different state, in an XAML only workflow) and need to listen to a WorkflowCompleted event, how would I implement this with a centralized webservice and windows service I would have to declare the event delegates (WorkflowCompleted, WorkflowTerminated) each time I call the webservice for the same instance of XAML workflow (and for each event - because I do not know whether the XAML workflow may require more or less events before Completed or Terminated event needs to be called). Note that the webservice would have to be generic for XAML only state workflows (one workflow may have 2 events, another may have 6 events - It would be nice to declare the event delegates only once and have them persist between webservice calls for the same instance of an XAML workflow GUID).

When using the webservice, can I use the global.aspx the same as in the website to manage the Workflow runtime service

You can use the global.asax in order to manage the runtime, exactly the same way you would with an ASP.NET page. This is also where I would attach to the WorkflowCompleted event and use that to capture the information into you are looking for into some shared store (application level variable, database, etc). This keeps your code to raise the events clean. If you are not satisfied with that appraoch and need to have every web service call potentially return "Workflow is done", you can check the state of the workflow after you call RunWorkflow on the manual scheduler service in order to see if the workflow has completed (although you would miss the ability to attach onto the workflow completed event). In that case, you could implement the workflowcompleted handler in the global.asax, store off what you need somewhere (application level variable) and then when you check the workflow state in your webmethod and find it to be completed, get that information and return it. You may wish to consider deleting it from the application level variable as that will keep growing over time.

I cannot do what you said above because I need to make a call for each event in different states to the webservice from the webserver. Thus, I do not know when to listen for the WorkflowCompleted event. Also, one of the output parameters in the WorkflowCompleted event is a ComponentOne report object. I am not sure about the best way to return this object to the website from the webservice (assuming I am able to correctly intercept WorkflowCompleted and WorkflowTerminated events). Any ideas

You listen to the workflow completed event in the same process that hosts your runtime. See the note above about storing results from the WorkflowCompletedEventArgs somewhere your code can get to it.

In terms of a sample, I have put one together that modifies Tom's example, hosts the XAML Activation within a web service, and then we interact with the web service from a Windows Forms client. In the code for my WorkflowCompleted event in global.asax, I write the guid of the completed workflow to an Application level list. My client app queries the web service to return that list in order to see what things have been completed.

http://wf.netfx3.com/files/folders/technology/entry3980.aspx

Let me know if that helps.