Home > Blogs
This topic came up in a WCF training session (i.e. ObjectSharp's WCF course) I am currently delivering so I wanted to post a few references on the subject here:
The first is "Designing Extensible, Versionable XML Formats" by Dare Obasanjo
http://www.xml.com/pub/a/2004/07/21/design.html?page=1
The second, slightly more academic treatment is "Extensibility, XML Vocabularies, and XML Schema", by David Orchard, an extensibility guru who has much to say on the topic:
http://www.xml.com/pub/a/2004/10/27/extend.html
And then finally a series of writings by Tim Ewald which are chock full of extremely powerful Versioning advice:
First his "Services and the Versioning Problem" article in the MS Architecture Journal:
http://msdn2.microsoft.com/en-us/arcjournal/bb245674.aspx
And then a series of blog entries:
http://pluralsight.com/blogs/tewald/archive/2006/04/14/21733.aspx
http://pluralsight.com/blogs/tewald/archive/2006/04/25/22704.aspx
http://pluralsight.com/blogs/tewald/archive/2006/05/05/22961.aspx
http://pluralsight.com/blogs/tewald/archive/2006/05/05/22963.aspx
I have been doing some Windows Workflow (WF) consulting with a customer lately and I was talking to a developer who had just been thrown onto the project and was struggling with WF, not feeling that he had a solid grasp of the paradigm. No one was more surprised than me when I was able to help him so easily by simply pointing out that WF is an instance of the “Command Processor Pattern”. Because it seemed to help him so much I thought it might be worth sharing here.
Before I get to this however, I just want to state for the record how important I believe the Gang of Four (GoF) Design Patterns book is. I always assume, sometimes incorrectly, that every developer has intimate knowledge of the GoF Design Patterns book. I believe reading it is a right-of-passage for every developer, and I would always steer people towards the original book, as opposed to “knock-offs” that try to “translate it” to another programming language. If you haven’t read it, stop everything and read it!
The Command Pattern
In case you can’t recall it, the authors state the following as the intent of the “Command Pattern”:
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations
However, I think the essence of it is well captured in the structure diagram:
The Command Processor Pattern
After the GoF authors, the POSA1 authors expanded on the Command Pattern by writing up what they called the Command Processor Pattern, a pattern that built on the Command Pattern to show how easy it is to use it to do things like undo/redo functionality etc. Again, for the sake of brevity, I will only show a single UML class diagram that I think conveys the essence of the pattern:
Compounding Command
Later, two of the GoF authors wrote a paper called “Compounding Command” in which they showed how some of the other GoF patterns can be combined with Command in interesting and powerful ways, which I’ll summarize here by once again showing a single UML diagram that I think captures it quite well:
Finally, WF as an Instance of the Command Processor Pattern
Now, mapping these ideas to WF is, I think, as easy as first of all making the following connection:
Activity à Command
WorkflowRuntime à CommandProcessor
Armed with these mappings, then showing the structural relationship of some of the key classes in WF shows very clearly how it can be conceptualized as the “Command Processor Pattern”:
The Value of Patterns
As a final comment: the GoF authors state explicitly that they weren’t doing anything new but rather placing well thought out names to reusable design nuggets that people had been using for years already. The real value in that was evident in the interaction I had this week with that developer: once he thought of WF in the context of the Command Pattern he immediately understood what I was talking about because the pattern name was part of our "shared developer lexicon".
I recently found out that the abstract I submitted for DevTeach, held in Toronto May 12-16, 2008 was accepted. I am very excited about it, both about presenting and attending because I think it is shaping up to be an excellent conference. My talk, called ``The Convergence of SOA, REST and BPM``, is in the Architecture Track (See here http://www.devteach.com/Session.aspx#91 for all the talks in this track).
I`ll try to blog more about what to expect from the talk as I figure it out better myself, but suffice it to say that these 3 pillars of contemporary software architecture are finally coming together for me, at least enough for me to want to talk about it with others :)
I am in the process of writing a new course for ObjectSharp on Windows Workflow Foundation (WF). More details about the course can be found here: http://www.objectsharp.com/training/coursedetail.aspx?id=1145. For even more information, contact our Training Manager, Julie James, at 416-216-4603 (or 1-877-So-Sharp) ext. 1 or via email at Training@objectsharp.com.
Taken along with the existing WCF course http://www.objectsharp.com/training/CourseDetail.aspx?id=1135, students will be given a hands-on guide to building a successful Service-Oriented Architecture (SOA) using the .NET 3.5 platform.
This saturday (March 1st) I will be giving a talk entitled "SOA Using WCF & WF" at the Toronto Code camp 2008. The site is here http://torontocodecamp.net/. My talk is in the .NET Framework track and the schedule for this track can be found at: http://torontocodecamp.net/Sessions/NETFramework/tabid/64/Default.aspx. The abstract for the talk is:
"In the world of SOA it is useful to classify your services into two types: Business Activity Services and Resource (or sometimes Entity) Services. In this demo-centric session we’ll look at how Windows Communication Foundation (WCF) and Windows Workflow (WF) can be used within this classification system. More specifically we’ll look at how WF is an ideal choice to use “inside the boundary” of your Activity Services to carry out the long-running work the service represents."
It looks like there are lots of good sessions so I hope to see you there.
The Visual Studio team at Microsoft is saying (see here http://blogs.msdn.com/somasegar/archive/2007/10/17/f-a-functional-programming-language.aspx for instance) they'll work closely with Microsoft Research to build support for F# into VS. Back in my University days I did a fair bit of ML so this will be like re-uniting with an old friend 
.
Last Saturday I gave a presentation at the "Okdevberfest" Code camp (http://www.okdevberfest.com/) held at the University of Waterloo. The slides as well as the sample code I covered can be found in the attachment above.
Cheers to Dave Totzke and his fellow organizers for putting together an excellent code camp.
A while back I gave a presentation at one of ObjectSharp's SMART events on "Bridging SOA & BPM" (http://www.objectsharp.com/ttdinvitation/invite070510.htm). The slides for the presentation can be found here: http://www.objectsharp.com/cs/files/folders/68276/download.aspx. One of the things I thought about saying during that presentation was that the question of whether to approach an enterprise architecture from a "services first" (i.e. SOA) perspective or from a "business processes first" (i.e. BPM) perspective is analogous to the question of whether one should approach application design from an "object-oriented perspective" or a "procedural perspective".
Now, before I elaborate on that, I'll just say that I chose to leave it out of the presentation because I view it as something that could be easily misunderstood. In saying this I am not saying that SOA is anything like OO. In fact, in my experience, the single greatest impediment to successful SOA adoption is getting people to let go of the OO mindset they have developed over the past 20 to 30 years. To be successful at SOA you have to "let go of your objects" and think more in terms of (business) documents and document exchanges. Many of the web service development tools have contibuted to this problem by making it so easy to turn your objects into services simply through the annotation of the appropriate attributes. Services should be thought of as having well-defined boundaries and, as such, stepping across those boundaries should never be taken as "lightly" as a call on an object residing in the same address space as the caller. Instead, invoking a service should be viewed more like what happens when you apply for a passport: you send off a self-contained application form (or document) and it is processed asynchronously by the receiving service. This notion of self-containment is important and is often lacking; i.e. each document in an exchange must contain the complete context for the request to be processed.
Furthermore, objects typically have an interesting life-cycle whereas services don't; think of services as simply being out there on the network receiving request messages, processing them, and sending out response messages or request messages to other services. The individual handling of a given request may have an interesting life-cycle but not the service itself.
Returning to my analogy, the key point that I am trying to make is that when looking at how things get done inside an enterprise, one can view it from a process-oriented perspective (which is analogous to looking at the software system from a procedural perspective) or they can view their assets as a set of self-contained resources and/or processes that systematically structures the various business capabilities the business can provide (which is analogous to viewing the software system from an object perspective).
Using documents as the input/output of self-contained business processes/capabilities goes hand in hand with organizing those business capabilities into discrete, felxible, self-contained (i.e. autonomous) "business services". In this view of things, the internal logic of the business process is hidden, or encapsulated if you will, and the only visible "interface" to the business service/process is the documents that can be exchanged and how those document exchanges are choreographed. That is, from a SOA perspective, internal process (or orchestration) logic should be hidden inside a service boundary and the emphasis instead must be placed on the documents being exchanged, their hopefully standardized syntax or format, their shared meaning, and the "business protocols" governing how they are exchanged.
After a two year stint at Amazon, Pat Helland is back at Microsoft: http://blogs.msdn.com/pathelland/archive/2007/05/14/i-m-glad-to-be-back.aspx.
I consider this to be great news, both for Microsoft and for those of us that appreciate whenever he shares his thoughts (via papers, presentations, blogging, metaphors, songs, etc...) with the developer community, something he is pledging to do more of now that he is back at the Big House.
I am going to be giving a talk at the next ObjectSharp SMaRT (Software Management Round-table) event called "Bridging Service-Oriented Architecture & Business Process Management". If you are interested in either of these two disciplines, or in particular in how they are related, then please join us for this upcoming breakfast event. More information about the event can be found here:
http://objectsharp.com/ttdinvitation/invite070510.htm.