Dear Rich

 

You're welcome. Let me take a moment to emphasize what I think is the biggest problem with your whitepaper. In your response, you restate the aim of the paper ("to help you make the best choices when deciding how to build distributed systems today on the Microsoft platform") and then you go on to say that guidance about how to actually go about designing distributed systems is beyond the scope of the paper. I simply can't fathom how you propose to help people make the best choices in deciding how to build a system if you don't address how to design said system. Would it make sense to write an article to help people make the best choices when making fudge without including any recipes? Would you talk about how it's important to use chocolate, sugar, and butter without describing the relative portions to use? You could even describe how the molecular nature of peanut butter affects the consistency of fudge, but how useful is that without a recipe? To extend this analogy close to the breaking point, Microsoft may just be the store that sells the ingredients, but your success is directly dependent on whether or not people like me can cook up some tasty fudge.

 

Understanding our difference of opinion about that allows me to answer your final question. Your paper is neither full of worthless trash nor will it help the reader decide when and where to apply which technology when building their system. Your article is full of accurate information without the necessary context for your readers to put it to full use. My original response to your whitepaper was my attempt to provide the appropriate context that would allow people to successfully use Microsoft's technologies to build distributed applications. To return to my analogy, my original response to your article was my attempt to provide a recipe for some tasty fudge. I take your point that I wasn't entirely clear about my recipe. This is due, in large part, to two different factors. First, I devised my response to follow the structure of your article and supply my guidance as an alternative to yours. In retrospect, I see this was a mistake. In the end, it obscured some of the points that I was trying to make. Second, designing distributed systems is harder than making fudge and I really have two goals. I want to describe my favorite recipe for building distributed systems and how Indigo makes it more difficult to build systems they way I want.

 

Now, to respond to a few particulars in your response. You say that I appear to assume that you favor RPC style communication. Actually, I'll state that outright.  When I use the term RPC,  I mean exactly that: Remote Procedure Call. Of the approximately 4200 words in your article, 90% of them are spent talking about RPC-style technologies (.NET Remoting, DCOM, ASMX, and Indigo) and 10% talking about messaging-style technologies (which I define pretty broadly by including MSMQ, BizTalk, SQL Server Service Broker, SQL Server Notification Services, and HIS). You clearly state that distributed component technologies are a powerful way to build tightly coupled portions of your application. This is, at the very least, a partial endorsement of distributed objects. I strongly disagree with this, by the way. Let me be clear that I am quite cognizant that it is certainly possible to build powerful systems using distributed component technology. I've done it a few times myself, but there is a more excellent way.

 

Let me clearly articulate my alternative to distributed object technology and RPC-style programming models. I explicitly reject your formulation of the messaging-style approach. Message-based programming models need not be concerned with the low-level details of transports or the processing of XML streams. Once again, you trot out the old canard that message-oriented programming is not as productive as RPC-style programming. I would argue that for most business programmers, message-oriented programming is far more productive than the traditional OO approach. Message-oriented analysis and design focuses a few simple constructs: Messages, services, and events. It is very straight forward to map distributed business processes to these constructs in a way that never worked well with RPC. Here is *precisely* the opportunity that I think the Indigo team missed. At the heart of the internal model of Indigo is a very powerful concept of a message. Unfortunately, this conceptual model is never exposed to developers and architects directly. You can only manipulate it indirectly, either through low-level XML processing or by applying a set of opaque attributes to a .NET type. Clearly, for interoperability reasons, the wire format for this message will be XML and the structure must be expressed in terms of XML Schema (despite its complexity). But I see no reason I shouldn't be able to work with this message in the .NET programming language of my choice. The Indigo team has already built the infrastructure to make the transformation. All they need to do is to expose it to developers instead of hiding it behind those attributes or forcing us to grovel in the angle brackets.

 

Once we have a way of dealing directly with messages, we need a straightforward way of connecting the initiators of message exchanges with the responders. For the sake of simplicity, I'll call the initiator the Message Sender and the responder the Message Receiver, even though in many cases both sides send and receive messages. We normally think of the Message Receiver as a service and the Message Sender as the caller. The Message Sender and Message Receiver need to agree on at least the following things:

 

 

 

I think anybody who's worked with the System.Messaging API can imagine a pretty straightforward API for these programming primitives. Instead of being limited to the MSMQ proprietary protocol and infrastructure, this API could be layered on top of all the interoperable goodness of the Indigo infrastructure.

 

Finally, I want to point out that Rich and I agree on a lot more than we disagree. Developers should spend their time building business apps, not infrastructure, for all the reasons Rich lays out in his post. Building a messaging infrastructure is devilishly hard and it is best left to experts like those who work for Microsoft. The only major point of disagreement is how to best expose that to application developers. I'm not even asking that the Indigo team throw out their RPC-style interface because I know that despite all the accumulated experience of the last 15 years of distributed application building, some folks still want to do that. All I'm really asking for is an alternative high-level API that allows me to map asynchronous messaging-based business processes directly on to the asynchronous messaging-based infrastructure in Indigo.

 

John

 

P.S. I liked the first version of your post better, but I understand why you edited it. Since we're both going to be in Los Angeles for the PDC, let's get together and share a cold beverage. This is an instance where I think synchronous communication might really be useful. Especially since I suspect we both would prefer an ESB from these guys to one from those guys.