Archive for the ‘WF’ Category
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.
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.
I recently downloaded and installed Dev10 Beta-1 and created some images for my team. The Channel-9 video guiding us step by step through the whole process was invaluable. One thing that had me in trouble was the installation of Full Text Search in SQL 2008 (as TFS requires this feature). When i captured the ISO image (as we usually do in Virtual PC) and installed from there, the installation failed. It turns out that the installation media needed to be inside the VM. That done, the rest of the installation was fine.
Anyway, I then got hold of the VS 10 Training Kit and started with the WF labs. Got one full exercise done. The thing that impressed me most, was not actually WF itself (at this particular time), but the fact that when writing the custom activity, the instructions were to first write a test to check the output of the activity. Not only that, there is also a nod to the BDD side of things as the name of the test was “ShouldReturnExpectedGreeting” (or something along those lines) . Now , if you’ve looked at the various blogs around BDD, one of the first steps (or baby steps if you like) towards proper BDD is to start naming tests like this rather than staid old “TestGreeting” or “GreetingTest“. It may seem like a small thing (and that was my opinion when i started down this route as well), but to me, it made a lot of difference to the way I approached my tests and helped me nail the purpose of the test better , thus also keeping it concise. Aside from this it serves as a form of documentation so a quick glance over your code base (even for your own code when you look at it after a few weeks or months) will bring you or the reviewer upto speed faster than with dodgy or less meaningful names.
In keeping with this emphasis on the test first approach, there is another, older video on Channel 9, part of the same series titled “Code Focussed in VS10” which shows some of the new features that allow us to write the test first and then have the IDE generate the class stubs and method stubs from the test itself. Of course, for those devs using R# and other refactoring tools this is nothing new, but lots of developers dont use them and this is a nice addition to allow us to really write the tests first and stay within the test, fleshing out the class as we go along rather than just writing a failing stub and then switching attention to the class because, unless you are very disciplined once you start working on the class, you tend to leave the tests behind and revisit them later with the attendant refactoring of code and tests.
So, there it was a rather pleasant discovery of a development discipline in a rather unlikely area (considering how design and IDE driven WF is). I’m looking forward to the other labs and I hope this emphasis is in them as well.
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?