Two weeks without a post... sorry about that! I've been traveling all over the place collaborating with people on the architecture for MBF process \ workflow. I'm in a hurry so I may as well post about my recent work in the process world.
We believe that a strong process architecture is critical to building a successful SOA application. SOA is about decomposing monolithic applications into finer grained services. These services interact with each other asynchronously, across potentially long durations. Something has to coordinate the work between services. That “something” is a process engine.
If you look at Microsoft's shipping products, the closest thing to a “process engine” is BizTalk. BizTalk is being used today to successfully coordinate XML messages between autonomous applications. That's great... I like BizTalk. It's being used by real people to solve real problems.
But that doesn't mean that it doesn't need some improvements to meet our future challenges. “Coordinating XML messages between applications“ isn't quite the same thing as “coordinating work between fine grained services“. My top three “wish list“ items for BizTalk in the future would be:
1. Make it hostable
Shipping versions of BizTalk always run in their own process. (In other words, BizTalk is a “Server“... not an “Engine“). That's OK if you are willing to host your service inside BizTalk. But what if you don't want to host your service inside BizTalk? For example, Indigo makes it really easy to build your own NT service (or even just a command line application for that matter) that can act as a service and receive Indigo messages. In this case I want my service to host BizTalk, not vice-versa. This “build your own service“ model doesn't work well with BizTalk today.
2. Don't require XML messages
At first glance... this seems like heresy. SOA is supposed to be heterogeneous, and XML is clearly the best choice for messages in a heterogeneous environment. I'm not questioning that point. However, what about optimizations when both the service and the service consumer happen to be homogeneous? Suppose the service and the service consumer both happen to be CLR-based applications? Indigo supports this model. The service consumer can “send“ a CLR class as a message, and a service can “receive“ a message in the form of a CLR class. The specific wire format is totally transparent. Maybe Indigo goes to XML and back, or perhaps it uses a more binary wire format as an optimization.
Current shipping versions of BizTalk don't support this model. Someone who wants to send a message to BizTalk must convert their CLR class to XML. Then once BizTalk receives the XML message, you have to convert the XML back to a CLR class.
Items #1 and #2 are especially difficult if you want to use process within a single CLR-based service. All your code is CLR-based (C# or VB.NET), and you are running in a single process (a single service). Yet to use current BizTalk you would have to constantly convert back and forth from XML just to “talk to yourself“. Further, if your service couldn't be hosted inside BizTalk, then you would also constantly be jumping across processes as well.
Cross process calls and constant XML serialization\deserialization is expensive. It's OK for very coarse grained interaction between applications (the current BizTalk usage pattern). But it won't be OK in the future if we want to use process in a very fine grained fashion.
3. Allow schedule creation via mainstream languages
This one doesn't have a direct tie to SOA, but it is important nonetheless. Schedules \ Orchestrations are created in BizTalk 2004 using a language called XLang/s. Of course, sometimes this underlying language is hidden by graphical design tools. But if the graphical orchestration designer doesn't meet your needs... you will be “coding” in XLang/s.
Now there are some good arguments for having a specialized language for process expression. Having this as an option is perfectly acceptable. However, it's the only option in BizTalk 2004. If you want to code an orchestration in BizTalk 2004, forget your C# \ VB.NET skills... you've got to either use the graphical designer or learn a new language. This seems a bit harsh.
So here is the great news.... The BizTalk team is well on their way to addressing all three of these concerns! You should definitely check out their PDC session on “BizTalk Futures”:
Streaming Audio \ Video:
As a quick summary the BizTalk team is working on creating a “BizTalk Engine” which:
1. Is hostable by any application \ service.
2. Can send \ receive messages either as XML or as serializable CLR classes. (Supports Indigo as a transport protocol).
3. Can be programmed using mainline languages (C#, VB.NET, etc...) using familiar concepts like code beside (the same model used by Avalon, MBF, and many other Microsoft products in the Whidbey \ Longhorn waves).
This is about as far as I can go without violating NDA stuff... but be sure an look through their PDC presentation. That's the most non-NDA information that you can get at this point. But I can say that I am <very> excited about BizTalk's future. These changes will enable MBF to support process at a very fine grained level, both cross service and even intra-service! And because the process is expressed in mainstream CLR languages, the same developer can reasonably code both business logic and process flows in the same language.