Introduction
In a weblog post I shared my frustration that the Whitehorse team had a different understanding of SOA than Pat Helland in his talk, Envisioning the Service-Oriented Enterprise at the 2003 PDC. The comment was made only having the benefit of flipping through the slides of the talk. In my search to design an ASMX app that can be moved to the Indigo framework, I decided to sit through the online session, preparing to be enlightened. I was, but not in the way that I expected.
Not All SOA’s are Equal
Pat's talk did not concern all SOA architectures but a particular subset. This subset I might term Commercial OLTP Services. He dubs them Enterprise Business Services. Pat’s definition of Business Services in the talk is surprisingly mechanistic. He describes them as:
That’s rather all-encompassing. I think a more objective perspective sees his architecture addressing services that are coarse-grained, in general, and commercial, in particular, where those services perform some sort of transaction processing. Regardless of the precise definition, it is clear that the focus is on enterprise class services that “shouldn’t lose their way.” That is to say, they are services where conversations should not get confused.
Signal to Noise
A key focus of the architecture he presented was that over the internet messages get lost. This is the key reason why the RPC paradigm falls down for inter or intra-enterprise communication. His solution sounds strikingly like a suggestion that one should use a datagram protocol and define one’s own ACK/NAK protocol on top of it. The question arises, which he was neither asked nor answered: why isn’t this a problem solved by TCP, which guarantees sequential packet delivery? Another way to ask this question is how is enterprise messaging different than network packet delivery?
An obvious answer to the question is that packets work at the transport level, and, thus, have no interest in the meaning of their payload, whereas messages work at the application level where the payload is all-important. More precisely
-
A packet is a block of arbitrary data, which may be part of a sequence of data blocks, that is communicated between two endpoints.
-
A message is a transactioned unit of information, which may be part of a complex flow of information units, that is communicated between two endpoints.
All messages imply semantic communication, i.e., the communication of an idea, not just bits. From the perspective of Pat Helland’s Busines Services, messages are part a semantic conversation between endpoints. Note that this conversation may not only be a two-way request/response conversation, the thrust of his talk, but an even more complex multi-message, multi-way conversation, to which he only alluded.
I believe it is the semantics of messaging that dictate that the specific mechanics of the architecture Helland presents is necessary. Some may find it pedantic for Pat to so casually dismiss a Business Service that does not have a database backing store. However, the conflicting dictates of (1) the need for non-confused communication endpoints and (2) the reality of noisy communications channels that prescribe that message reception be Atomic, Consistent, Isolated, and Durable.
What is Noise?
It is interesting to consider the concept of noisy communications as it relates to the application layer. At the physical, link, network and transport layers, protocols are well defined, broadly accepted and infrequently changed. At the application layer, however, what is being communicated and how they are communicated can be in constant flux, the problem set is infinite. This is why some say that the Semantic Web is doomed to failure. That aside, at the application layer, the problem of clear communications is not only the problem of signal-to-noise over the communications channel, but also one of confusion by the communicators themselves.
While this problem was not addressed in Pat Helland’s talk, Don Box often speaks of the latency between programmers as the main reason Microsoft has moved beyond the ORPC paradigm of CORBA and DCOM to SOA paradigm of MessageBus (Indigo). It is this causticly high potential of confusion on the part of the communicators, especially in the course of code-maintenance over time that causes RPC-based services to crumble.
SOE and ASMX
So we want our new applications to follow SOA. However, while long on terminology and higher-order mechanics, Pat Helland’s Service Oriented Enterprise presentation was glaringly short on any practical advice for building SOA applications with today’s technologies. Indeed, I have yet to find a clear example of an SOA implementation using ASMX. We are left to extrapolate on our own. So I’ll do just that.
Being told so many times that SOA is an asynchronous architecture and not RPC, I was surprised to hear Pat advocate the use of a request/response protocol. To my mind, Pat was not so focused on asynchrony as he was on how to get ACID message capture at the end points. This is very good, because request/response is isomorphic to RPC. Indeed, ASMX WebMethods are directly translated into a request and response SOAP message pair by the ASMX plumbing. Moreover, this is not just a feature of WebMethods – any .NET method can be turned into a pair of messages by either being a member of a ContextObject subclass or the target of MulticastDelegate.BeginInvoke call. We can do SOA today.
Not Omnipotent, Idempotent
Good, WebMethod does not preclude SOA. But the question remains, how do I implement SOA with WebMethods? The answer lies in Pat’s description of immutability, stability, versions, and idempotence. Whatever application communication protocol you wish to cook up, make sure that the messages that implement the protocol are idempotent and that you uniquely identify the conversation of which they are a part. To me it means that every method must contain a GUID for both the method call and the conversation. I suggest a signature such as the following:
[WebMethod]
void Foo(Guid conversationId, Guid messageId, …)
{
…
}
The ASMX architecture allows asynchronous communication between the end-points while preserving the request/response protocol that WebMethod implies. Armed with this method signature and by following the plumbing rules that Pat Helland explains in his presentation, I believe that you can build, today, the SOA architecture that Microsoft envisions.
A very thought provoking news
article on why XML will and should gain momentum over previous binary formats.
Bob Wyman used the term
Software Engineer. I've always shuddered at the term after my year in the J2EE world. I'm a
Software Developer, thank you very much. I prefer the Microsoft environment where I use the tools, not where the tools use me.
I know, everyone uses InstallShield, Wise, or another installer product. But I still dream that one day commercial apps can be deployed from a VS.NET deployment project where I can use a real language to make my setup scripts. To further the cause, I share a
KB article that describes how to work around a bug that messes up the target in program shortcuts.
If you are designing a new application, I would consider carefully the new Aero look and feel. The user experience guidelines database application archetype uses IUI but does not have the Money '98 flat look. With the the degrees of freedom that XAML allows you, do not expect the Money look to be in favor in Longhorn '06 time frame. It's possible that Microsoft may throw us a curve ball, but even the revamped Hotmail is trending toward the gradient fill tabs across the top, etc. IUI. Note that there are eight years difference between '98 and '06. Don't date your application even before it gets out the door.
- There are enough demo apps to get a decent gist of the look and feel at the page level.
- Consider moving to Infragistics or another major controls vendor that can help you move to that look and feel at the control level in the future for your WinForms app.