Workflow Services & Application Protocols
Its taken some time (and a lot of procrastination) but I’ve finally decided to properly get into WF and WCF and as a Biztalk guy, one of the things that most interests me is Workflow Services. I’ve known the basics of all of this for a long time but never dived into it, so i started sort of working backwards and chose Workflow Services as my starting point (no use in trying to learn the old Data Exchange mechanisms of WF V1 now really). I picked up some nice videos from Channel 9 and some from the VS2008 Training Kit.
I soon got into the video titled Building WCF Services with WF and within 2 minutes ran into something that disturbed me so much I had to write this immediately. When talking about the advantage of writing WCF services with WF, Pravin says that one of the pros is that “Application Protocol is enforced” and goes on to give an example where if we had a service where there was an AddPurchaseOrder and also a CreateCustomer, we (as service implementors) might expect that the Customer would be created first before the Purchase Order. But the client would not know this by looking at the WSDL. So we set up a flow in the WF and expose these methods at some point and if the client calls them out of sequence we can throw exceptions etc.
I dont know about you, but IMO, this would not be good service design. Let me try to explain. First of all I wouldnt mix two widely different documents in the same service unless this was merely a ‘composite’ which internally invoked the CustomerService and the PurchaseOrderManagement service. Even if it was a composite, the contract specified by this composite should allow the client to give the customer info (or a pre-existing ID) along with the other PO info all together and then communicate with the Customer and POMgmt to create the customer or update an existing record and then pass stuff between them all through well defined messages. Those backend services are still valid on their own and can accept messages being sent directly to them from other clients but the composite is providing some extra functionality. Now if the whole process was rather long running and there was state to be maintained in between calls to those backend services then we can make use of low level persistence services in the framework so we could dehydrate the composite while waiting for responses. But I would not make the composite service so ‘stateful’ that it exposed two or more methods as entry points and insisted that they be called in a sequence. (its a completely different matter if you are implementing a convoy in Biztalk where you may have multiple receive shapes which are linked together by correlation. Here we are talking about different ‘method calls’). Theres no service provided here just a wrapped collection of methods.
Just creating a few classes (whether declaratively implemented or handcoded) and exposing them over the wire doesnt make them business services. It worries me that devs are going to be throwing together some simple classes , fitting WCF endpoints on top of them and saying “Look, we have SOA” (and worse still, with all the designers, the claim would be “we have model driven SOA”.) This is like going back to the ‘bad’ old days where people thought they had webservices just because they could stick [WebMethod] attributes on function calls. Let me re-iterate my point, a collection of visually designed classes that can listen on the wire is not model driven SOA. Its just that – a collection of classes, nothing more, nothing less.
So, back to the ‘protocol’ business. Sometime ago there was a lot of talk of web service choreography and a choreography description language to specify a sequence of ordered message exchanges. If the ‘composite’ service (discussed above) was implementing something like this, it would make sense. It shouldnt expose two random entry points and force a sequence of invocation. And if the composite was not providing any other value other than just stringing together two calls why not just make the contract of the ‘second’ service explicit (for instance , require a CustomerNumber or something) that makes it apparent that Customers should exist first and then we could do away with the composite altogether.
But theres nothing wrong with the Workflow Services as such (at least nothing thats immediately apparent considering im just getting into them.. flaws may surface in a few days). It seems like WF and WCF were made for each other and this is a good way of linking the two. I just dont buy the ‘application protocol enforcement’ claim.
What do you think? What ways would you choose to implement sequencing? Does anyone else use the workflow services to enforce sequence?