More Workflow Service Questions

In response to this post, Anderson raised the following question.

Definitely too hard and not service-oriented.  I like the idea of sending it via the headers or some other such implementation, but that would also require implementation on the other side in the form of an agreed-upon place and format of the context information or a custom binding implementation that you either distribute or have the other side of the fence reimplement.

The first time I did this I spent days working on it saying to myself "surely you don't have to do this... surely you don't have to tell the target service which *activity* you want it to talk to next".  But you do.  It makes me sad inside.

matt:  Our general goal is not to introduce more misery into the world.  At this point in time, doing duplex requires the explicit management of the context token.  We're working to make it better, so hopefully around PDC time, you will no longer be sad inside. 

One thing I've not seen implemented yet in a demo.  I really like the feature of State Machine super states and substates.  The ability to take a group of 3 states and put them in another state called "Cancellable" or some other such interrupty business function is really kickass.

Let's say you are in state "Processing" which has an event-driven that listens for the service method "FinishedProcessing".  "Processing" is also in a superstate called "Cancellable" with an event-driven that listens for "CancelProcess".  How could you implement this when you have to tell the other service about the context identifier of the target receive activity?  Do you have to send both contexts?  I fear your answer will be yes.

matt:  In that case, provided you are not listening for the same operation in two places, you can get away with grabbing the context token from either FinishedProcessing or CancelProcess and send that along.  The context token will be the same fore either of them, it will only consist of the Workflow Instance Id.  The Instance Id + the OperationName is the combination used to enqueue an inbound message, unless you've gotten clever as in the Conversations sample and told the Receive activities to create queues based on an additional conversation id. 


Also, it sounds like Anderson is delivering a talk tomorrow night in Dallas about WCF /WF integration.  If you're in the area, head on over and check it out.

Skip to main content