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.
Here is the link to all the presentations from the Microsoft SOA and Business Process Conference 2007 that was held in Redmond from October 29th to November 2nd.
Steve Sfartz, architect evangelist at Microsoft France, mentions that access is available until 11/21/2007.
Both the slide deck and sample code I covered at my presentation at Okdevberfest Code Camp
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.
Slides from "Bridging SOA & BPM" SMART Event.
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.