What kind of Host Application to use?
hi
I didn't really get behind this whole thing of persistence, and host application. Therefore I have following question:
We are developing a asp.net web application, where order can be made. After defining the order, the workflow should be triggered, and is used to control certain sla (service level agreement) times, in which certain actions should take place. For example: After 8 hours the order is checked if it was given clearance, or after another amount of time the order is checked if it achieved a certain status.
My question: What kind of host application for the workflow should I use? I know this is quite a common application, but I didnt really get the point.
I would appreciate any links, comments or hints.
thx
Answers
- Following on to Matt's post above, you can check out the expense reporting application which hosts the workflow inside a WCF service. It's currently set up as a console app, but you could convert it to a Windows service pretty easily. You wouldn't host the workflow inside your ASP.NET application, but you would use the ASP.NET ordering application to start the workflow by calling into the service. In the sample, a Windows application calls the service, but you can do the same thing from a web application.
You can get that sample here:
http://www.windowsworkflow.net/default.aspx?tabindex=4&tabid=49 Host the runtime in the windows service, and not in the ASP.NET application. Use remoting or services to communicate between the two. See the other post on this thread for a link to an example of using WCF to communicate between a client application and "remote" host for the workflow runtime.
Matt
All Replies
If you use ASP.Net, you need to use the persistence service to make sure your workflow instance doesn't get lost with a process recycle. You also have to take into consideration that while the workflow instance will be reloaded when the timer is up, you need to write some code to actually execute it using the RunWorkflow method of the manualworkflowscheduler. You might try registering for the workflowloaded event on the runtime on application start and then put some logic in the event handler to run the workflow if a delay has elapsed.
Matt
The point in using the persistence service is evident to me. This way I can save the actual workflow to the database, and reload it. What kind of instance does the evaluation of the timer, when the asp.net website is down?
In your post you say, that I need to write some code for executing it, after a reload from the database. Which I could do by registring for the workflowLoaded event on the runtime application start. Did I get that right?
I thought about following: What about a Windows Forms Application which runs on the server, where the web app is hosted. If someone on the web app makes a order, the windows forms app starts a workflow for this particular order, and manages it. In case of shutdown it needs to reload the workflows using the persistence service. Also I would have an app in which you can see the status of all running workflows (when they were started, how long they are idle, ....) What do you think?
The persistence service itself is checking the database for timers. So if you host in ASP.NET and your application is not running, nothing is checking until the app comes back up.
You are right, you can register for the workflow loaded event which will let you know when a workflow has been loaded from the persistence store.
I would not create a windows forms app on the server, but you could create a windows service that exposes an interface via remoting or web services. You could have one service interface to interact and start the workflow or raise events to it and another interface that allows a remote or local winform app to query for all the details you would like to have. The service gives you the benefits of being able to have your workflow runtime loaded at startup and have control over starting and stopping it from the services admin tool. It also allows you to run as a particular identity.
The real issue is that when you run workflows in ASP.NET, you typically use the ManualWorkflowScheduler service because you want to use the app thread for running workflows. With a Windows service, you generally use the DefaultWorkflowSchedulerService which runs things asynchronously. You'll need to keep this in mind as you develop your local services, the service interface for your workflow host, and the application itself.
Matt
So you say, that I need to bring my web application up again, in order to continue the workflow. This is a problem...
I need following:
- There is a asp.net website where orders are made.
- After the order is submitted, the workflow starts.
- The first thing to do, is clearance of the order by human intervention, using the asp.net website.
- Then there are several escalations to check for the order. e.g. if a order does not reach a previously defined state in a user defined amount of time, emails are sent to the according persons, and the workflow goes on.
- Then after the order has been completely configurated, and reached the internal closed status the workflow end.
This means that the Workflow has to run, even if the webapplication is down. Do you have any suggestions, how to host the runtime for such a scenario?
Are there more examples for hosting the runtime engine in an asp.net application? And are these capable of more than just printing out "Hello World"?
Thanks
- Following on to Matt's post above, you can check out the expense reporting application which hosts the workflow inside a WCF service. It's currently set up as a console app, but you could convert it to a Windows service pretty easily. You wouldn't host the workflow inside your ASP.NET application, but you would use the ASP.NET ordering application to start the workflow by calling into the service. In the sample, a Windows application calls the service, but you can do the same thing from a web application.
You can get that sample here:
http://www.windowsworkflow.net/default.aspx?tabindex=4&tabid=49 Host the runtime in the windows service, and not in the ASP.NET application. Use remoting or services to communicate between the two. See the other post on this thread for a link to an example of using WCF to communicate between a client application and "remote" host for the workflow runtime.
Matt
Thanks guys for your quick and helpful reply. I try to get my basic application setup working today. Hopefully.
I'll write some if I got problems or if I get it working.
Does anyone has good examples/tutorials on creating such a service. I am new to this topic, and therefore would appreciate having a bit of a guidline.
But to make that clear, you guys would suggest following:
- Host Application: Windows Communication Foundation Service hosting the WorkflowRuntime; starting and managing the workflows, as well as persistence and so on
- Client Application: Asp.net Ordering Web Application
- Communication between them: WCF
Are there also some good informations about the communication between the host and the client?
Is it a bad idea to host the workflow runtime engine in a console or windows forms application, for using it in my app (as described above)?
Thanks
The expense reporting application shows a good example of using WCF to host your workflow runtime seperate from the client application.
There is a ton of information about WCF on the web. Check out MSDN and www.windowscommunication.net for examples and articles.
I think it is a bad idea to host the workflow service in a windows forms or console application on a server. Workflow works really well in those hosts if they are on a client and being interacted with. Neither of these works well on an unattended server. You want a windows service for that. with .NET these services are not any harder to write than a console application, just a bit harder to debug sometimes. In the case of workflow, it shouldn't be an issue.
Matt
- Matt,
Using this architecture, is it true to say that the relationship then becomes client to host to runtime? Which means that communications between workflow and client apps becomes somewhat problematic. Can you use ExternalDataExchange in this case? ExternalDataExchange usually communicates with the host, doesn't it? Communication with the host becomes different, but not necessarily problematic. You can wrap local communications (externaldataexchange) with WCF or remoting. The differences include:
1) Having to manage/map from WCF requests to workflow events. Not usually to hard as you can have your request type be part of the event arguments and simply wrap it up and pass it in. You have to manage the workflow instance ID which you have a number of options for doing, including putting it right in the request message as is done on the expense reporting application.
2) Having to communicate from the server to the client. This area provides for a few options. You can update some common data store (in memory or persistent) and have the client poll that (or use sql dependencies in sql 2005). You can also use duplex contracts in WCF to call back to the client, or have the client host a service as well that you call from the runtime host.
There are other options depending on your workflow and architecture choices. In the future there will be WCF activities that might make some of this easier, but we'll have to wait a while for those.
Matt
I try to understand the ExpenseReporting example (please correct me if I'm wrong):
There are 8 projects in the solution:
- ExpenseActivities: The Custom Activities library
- ExpenseApplication: Windows Forms app, communicating with the Host
- ExpenseContracts: The Business Logic layer
- ExpenseHost: The Host for the Workflow Runtime
- ExpenseLocalServices
- ExpenseWorkflows: The Workflow itself
- IndigoUtil
- ManagerApplication: Windows Forms app, communicating with the Host
Could someone explain the communication in this example. There are 2 interfaces, one in the ExpenseContracts project called "IExpenseService.cs", and the other one in the ExpenseLocalServices project called "IExpenseLocalService.cs".
Why are there 2 interfaces? Where is the difference between them? Is there any particular reason why "IExpenseService.cs" is in the ExpenseContracts project? What is the IndigoUtil project used for?
I could use some help on that please.
-------------------------------------------
I thought about my application, and think that I will implement a Windows Service as a host for the workflow runtime environment. This service will be able to communicate with a website, using some communication method (which I dont know by now).
There are also projects for the custom activities library and the workflows itself.
I'll start off trying to implement this service and get the runtime running. Afterwards I start building activities and workflows. Hope I works...
Thanks
One set of interfaces is for the WCF service contract, while one is for the local WF services. there is then an implementation of each. The local services provide the connectivity to the workflow, while the WCF services perform the routing logic and call the local services to raise events to the workflow.
the IndigoUtil project has a WCF extension that gets executed at startup and shutdown of the WCF service host. This makes sure the WF runtime is running and available. Then the WCF service code can access the instance of the runtime through this extension.
Matt
Hi Matt
Thanks for explaining. But I still have some trouble understanding.
The IndigoUtil is a WCF extension. It allows me to access the instance of the runtime. Also it starts and stops the runtime on start or stop. I think I understood that.
But the 2 interfaces are still somewhat unclear to me. I try to develop an application using such interfaces, but I dont really know where to start, or what to implement. It confuses me. Maybe you could give me a little step by step explanation on what I have to do to communicate between:
- WorkflowHost: Windows Service
- Workflow
- WorkflowClient: ASP.NET Application
I need these 3 to communicate with each other. But I just dont know where to start, or what to use for.
Thank you
There are two levels of communication here, and therefore two different sets of interfaces. There is communication between your asp.net application and the host for your workflow runtime. This is happening via WCF. In the expense report example, the ExpenseContracts project represents the interfaces and types used for this communication between the client and the workflow host.
The second level of communication is between the host and the workflow. The classes and interfaces for this can be found in the ExpenseLocalServices project. These follow the same pattern you will see in the other examples around local communication using the ExternalDataExchange and ExternalDataEventArgs.
The real meat is in the implementation of the WCF interfaces which is found in the ExpenseService class, in the ExpenseLocalServices project (this is a bit confusing I know, and this could probably be put elsewhere to make it more clear). This class implements the interfaces for the communication with the client and then "maps" those requests onto the appropriate methods of the local service in order to interact with the workflow. In some cases, it simply uses the local service to lookup values or lists of expense reports and does not have to interact with the workflow at all. This shows how your host can augment the behavior of your workflow when needed.
So, the flow looks something like this:
Client application -> WCF -> ExpenseService -> Expense Local Service -> Workflow
I hope this helps, but if not, keep posting and I'll keep replying.
Matt
I have now used plain remoting for communication. the asp.net web application just needs to call 3 to 4 methods from the host, which dont really result in a return value. they rather result in a change in the underlying database, which is surely also available to the asp.net application.
I hope this works out, when the workflow gets more sophisticated.
Today I tried to get the tracking and the persistence service (both out of the box services) running. Each one on its own works fine, but both together dont work....
Maybe someone has a quick idea, or wants to share an expirience on that.
Client -> WCF -> WCF Service hosted in Windows Service (probably using ServiceHost to host your WCF service type). This gets setup like any other service as if you were just calling the service to do the work for you. The client doesn't need to know there is a Workflow behind it.
Within WCF service code, use the Local Service to raise events to the workflow. The IExtension<ServiceHostBase> that is used in the expense report example is a nice way to manage the workflow runtime so that it is tied to the WCF service host and available to your service code.
That example application is really a pretty good example of one way you can do this. I'd set some breakpoints in the code and walk through it to see how the communication flows.
Matt
Hi Matt. Do you know any doc/article/blog about IExtension<ServiceHostBase> interface showing why or when should be used? I search about the docs, and couldn´t fine anything except the member declarations of the interface.
Thanks in advance...PD: Or at least what it's the name given when you use that Interface, example: WCF Host extensions or something like that.
Marcos
Marcos,
I don't know of any specific documentation on that item. Essentially, the IExtenstion<> interface allows you to extend any class that implements the IExtensibleObject<> interface. IExtensibleObject<> has one property that provides access to all of the extensions on the object.
IExtension<> lets you hook into the item you are extending by using the Attach method which is called when the runtime sets up the environment (basically, when servicehost.open is called).
This is a general extensibility feature of WCF and can be used with a variety of objects including some channels, contexts (instance and operation) and some peer related classes as well.
Matt
jamba8,
Try adding the SharedConnectionWorkflowTransaction service to your runtime and configuring it and the two other services (tracking and persistence) with the same connection string. I assume you have both services pointing to the same database.
Matt
Great Matt, now get it. It was a little difficult, but i get it :-P
ThanksMarcos,
I just posted in the WCF Sample Gallery a helper class - WorkflowInvoker. Here is the link:
http://windowscommunication.net/ControlGallery/ControlDetail.aspx?Control=2278&tabindex=2
Roman
Great Roman. I will try it right away...
Thanks
MarcosIs there a more detailed MSDN article/white paper that explains how the client applications communicate with the host appplication, the workflow runtime and the workflow activites in the Expense Reporting sample?


