AppFabric lands in VBUG (Bracknell)

Hot on the heels of my previous talk on AppFabric at SBUG, I will be reprising the talk, but with more of a Workflow Services slant at VBUG in Bracknell on Feb 15th 2010.

A big thanks to all who attended the SBUG talk and cool to see the large Avanade contingent comprising many familiar faces  🙂 . It was an interesting conversation on BizTalk and AppFabric. I will be posting more content on those topics here soon. I’ve sent the slides to Mike Stephenson and they should be available on the SBUG site soon.

I hope to be able to do more of a hands on demo of Workflow Services at the VBUG event (but that depends on Windows Virtual PC behaving properly). Still, it should be a good evening. Again, lots of known folk at VBUG and hope to see a good crowd.

MockingBird – The Roadmap

I’m really chuffed to have not one but 3 new team members on board the MockingBird project. Welcome to Shen Chauhan, my MCS colleague and WPF whizz-kid, Bram Veldhoen and Cormac O’Brien.

So, whats cooking for MockingBird in 2010 ? I have a veritable laundry list of features for the next release(s) but here’s the broad themes we are working towards.

(1) WCF : The first is the port to WCF which is long overdue and Bram has been hard at work in getting this off the ground so I expect to have something to announce soon. We will be implementing a message interceptor / router with a generic contract and from there leverage the simulation framework that is currently available with (hopefully) minimal changes. The challenge will be in the area of bindings since most teams customize bindings heavily so the service will need to support custom bindings.

(2) REST, XML/Http etc: Here we are looking at moving beyond just SOAP based services to plain XML/Http services and even REST based services. Cormac had come across some non SOAP services recently for which he had to manually code a mock, so we will be looking to incorporate such functionality here.  REST is an area that I haven’t paid much attention too so i see  a crash course in REST around the corner. If you have experience with REST and are keen to see support for this in MockingBird and can contribute in some way, do drop me a line.

(3) Generic ‘Action’ processing: For processing requests and building responses, there needs to be a more generic approach. Currently there is support for running an XPATH query on the request and returning a response based on the result of the XPath expression., But this is only one solution. What if we wanted to do a custom evaluation of the request where XPath is not enough? Further for the response, what if we wanted something more dynamic than just pointing to a specific response file? for example, Cormac suggested we dynamically execute an XSLT against the request. So, for this we need to look at the system executing a supplied “IAction” (IRequestAction, IResponseAction) and behaving accordingly. Unity and MEF should help here.

(4) Dynamic Mocking With BizUnit: This would be an API (+ a BizUnit step) which reduces the amount of upfront configuration needed. I envisage being able to say “For this endpoint, at the next request, return “X” response (and extend it to say, “do that for the next 10 calls or forever etc). We should then be able to “assert” that the system did indeed send the response. This would require surfacing the configuration file management code so that a config file could be written on the fly by the API/ Test step.

(5) .NET 4, AppFabric and Workflow Service: This is probably a longer term (MockingBird v3) where I am considering implementing the handler as a dynamic workflow service and using XAML. Now with this approach all the header parsing, IAction components etc would all  become custom workflow activities and it would be possible to dynamically compose specialized handlers on the fly. The message interceptor component would move to the official WCF Router.

So these are the big ticket items. For all of them I would appreciate your feedback as to what would give you the most value. We would also welcome more participation and contribution of ideas/code.  Looking forwad to your feedback.

Speaking on AppFabric @ SBUG

I’m delighted to be delivering my first presentation for the UK SOA/BPM User Group next week on the topic of Windows Server AppFabric (formerly code-named “Dublin”). The link to register is here and the page will be updated with the abstract shortly.

The tight integration between WCF and WF 4.0  and the hosting support in AppFabric is looking very promising now and will definitely provide a good platform for solutions which dont require BizTalk and, where BizTalk is already available, can work well alongside and integrate with it.   We’ll look at some scenarios where there may be overlap and how to approach the solution in such cases. Sure there will be some good discussions !

I know Yossi will be there 🙂 . Looking forward to catching up with some of the other UK / London gang as well.

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?