I am trying to create two workflow hosts. One on a server and another on a client. I am currently trying to use remoting based on the expense report smaple included with wwf. The problem I get is trying to add an event listener on the client for events that happen ont he remote object. What I would like to happen is when the workflow on the server ends, it calls a method on the service. That method would raise an event that would start a workflow hosted on the client. What is the best way to build the service SHould I use remoting, or some other method
WCF to communicate with Workflow
adb444
I would consider several items before deciding how to approach this:
1) Will there ever be multiple clients that want to know when the server workflow completes, and will they use different local workflow to respond to that
2) What happs when the network between the client and the server goes down on you or is flaky like a dial up line
3) What happens when the server crashes (power outage for example) and then restarts the workflow at some later time
4) Does the client only need to run its workflow if it is up when the server completes Is it more about management or business logic on the client side
Some of the approaches I would use rather than remoting in general, but would be dependent on the answers to the above:
1) I would have the server based workflow provide the notification that the workflow has completed as its last step in the processing.
2) This notification could be to an ESB type notification system, or to an MSMQ type message queue. Unless the client is just monitoring the server there should be a persistent record of the completion and the notification should happen regardless of any failures.
3) The starting of the client workflow should be transactional so that when it is sucessfully started is when the notification is recorded as completed.
Basically we assume that all business actions should not depend on live processes, but on persistent transactional chains of events. That means that if you use listeners they should be in the same process as the source of the event and should only serve to enter the persistent event into the system for transactional processing.
Corridriver
So with the goal of haveing a reliable system above all else, are you recommending I use a form of web service And not remoting
dave dave
Thanks Michael,
I would like to add an additional point for your list such as a type of client. Based on the client type and its host process (smart device, desktop, web service, web page, console, windows service, etc), the properly notification model (delivery) should be considered. Basically, there are two kinds of models:
- Push model, where a notification message is pushing forward to the next workflow process. This event driven pattern is suitable for applications where an event sink can be tightly coupled with the client, for instances: the client is behind the web service (event sink), windows form + event sink, etc.
- Pulling model, where a client is polling a publisher for event. Typically example is a web application, where back-end finished a business async workflow and front-end needs to update a web page. Another example is a load balancer, where a subscriber (client) wants to decide when the workflow has to be started.
Combining the above models we can use advantages both models to get a better performance, for instance, web application, where a back-end async workflow will push a notification message to the front-end MSMQ queue. Polling this local queue for event can be avoided a polling of the back-end workflow status. I described some mechanisms of the notifications in my article [1] written for WSE3.0, but it can be used for any implementations.
Also, I would like to point to the WS-Eventing spec and incoming its extension WS-EventNotification. These specs enable building a logical notification model in the workflow driven applications and with a small extension we can get a dynamically endpoint binding for delivery.
Thanks
Roman
[1] http://www.codeproject.com/useritems/soapmsmq_wse3.asp
jamie r
The answers to those thigns are:
1. YES
2. This is runningn in one HOME at a time on a gigabit network. If the client goes down it is not important for it to recieve the events. When it comes back on line it needs to reconnect to the server.
3. When the server goes down, the entire state of system will return to default, which is loaded out of SQL.
I really need to get that part working in order to convice my company this technology is worth using. I have them complated sold and I am prototyping some basic stuff. I have made a lot of progress but this has been the most difficult for me. Based on the answers to the questiosn are there any samples or documents that show how to do what you are describing