In response ... Dear John
Dear John [edited]
Thank you so very much for taking the time to
read the whitepaper I recently published to MSDN laying out Microsoft’s prescriptive guidance on how to most appropriately use our current distributed systems technologies when building distributed services today.
I’m sorry that you found the paper so woefully lacking and that you feel the guidance presented is so horribly misleading to application developers the world over.
Permit me a moment to ruminate on the stated aim of the paper: “to help you make the best choices when deciding how to build distributed systems today on the Microsoft platform”. The primary goals of the paper were to help:
- Those who are confused by the plethora of technologies available today on Microsoft’s distributed systems platform understand where and when each technology in our stack is most (generally) appropriate
- Those who are concerned about Microsoft’s commitment to our current technologies and how we are evolving our distributed systems technology platform moving forward into the new world of
Indigo Windows Communication Foundation (WCF) and beyond
The paper never states explicitly, or proposes to provide, guidance on best practices for how to actually go about designing distributed systems – that is beyond the scope of the paper. Also, this paper does not argue the pros and cons of message-based vs. RPC-style distributed systems technologies – something I know you feel strongly about:
You appear to assume that I promote the use of RPC-style distributed component technologies. This confuses me because as I clearly state, before the end of the second page of the paper, that “while distributed component technologies are a very powerful way to construct tightly coupled portions of your systems, they are not the most appropriate technologies to use when building distributed systems that must be interoperable and able to be quickly adapted to changes in the business requirements”.
From my analysis of your post, we’re in agreement, no?
I think what you’re trying to state is your enormous dislike of what you call “RPC-style” programming interfaces for distributed systems. You appear to greatly dislike the notion of developers writing code that requests actions on a remote service using the oft used nonclemature:
ResultType ServiceName.Action([ParameterType value1] [, ParameterType value2] … [, ParameterType valuen])
However, you do not articulate clearly your preferred approach. Instead, you berate me, and the Indigo WCF team, and allude to your own preference for the notion of explicitly forming messages containing data requesting work to be done and (optionally) processing responses asynchronously. And who would we be to argue with you? This is precisely what TCP, UDP, RPC, DCOM, SOAP, MSMQ, MQSeries, RMI, JAX-*, IPX, Telex, Morse Code, etc., have all been doing for years. If you would prefer to continue coding at the transport or messaging level, then neither I, nor any of my Indigo WCF compatriots will stand in your way. However, we will point out that message-oriented programming is rarely as productive and consistent as using coding constructs that have stood the test of time and proven to be a very effective way to describe how any given piece of code interacts with objects and services around it.
So, let me synthesize an alternative for you: If we were able to construct a technology which would make it explicit to developers that they are acting against a remote service whilst enabling them to continue with the form of coding that they enjoy today – be it via method calls or via message passing, then I think that would be a winner, no? This is Indigo WCF – a technology which lets you send messages or invoke methods across different transports, encoded, secured and made reliable via practically any transport you want. What *precisely* are we missing here? Have you attempted to build a messaging-based app with Indigo yet? Did you manage to get it to work? What difficulties, *specifically* did you find? Did you submit your experience via the Indigo newsgroup so that the team had a chance to make changes to Indigo to support your scenarios?
I am also very interested in how you managed to synthesize the guidance point “Use WSE when MSMQ is not available” from my paper. WSE and MSMQ are orthogonal technologies. As I am sure you understand, WSE provides developers tactical implementation of several WS-* protocols whereas MSMQ provides async, persistent message-queueing capabilities using Microsoft’s MSMQ communications infrastructure. Please enlighten us with a clear description of how you would build an interoperable, general-purpose, consistent programming interface using WSE and MSMQ.
I think you’ve muddied your critique of the paper with your own agenda. You later comment on the fact that WSE has “a really nice message-oriented programming model and an excellent extensibility mechanism”. Yes, WSE2 does. As can .NET Remoting if you want it to. The point, however, is that if you build your system on top of your custom WSE2 or .NET Remoting based messaging infrastructure, you’re going to end up with a proprietary messaging stack of your own devising, which will not be easily interoperable with across platforms and technologies and you’ll have a much harder time moving from onto
Indigo WCF in the future. Also, there are some significant performance implications of doing this which will make themselves evident as you begin to test such a messaging substrate compared to using, for example,
Indigo. Oh, and in WSE3, the chances are that you’re going to have to significantly re-work your custom plumbing. Are you planning on publishing this sound, reliable, extensible, interoperable communication framework you seem to keen to espouse? I look forward to seeing the fruits of your labor!
We in the
Indigo WCF team, believe (based upon years of gathered experience and feedback from our customers) that developers should spend as much time writing their business apps as possible, rather than creating their own custom messaging infrastructures. Building a messaging layer that is performant, secure, interoperable and extensible might seem like a good idea at the beginning, but such custom plumbing infrastructure quickly reveals its demons when only slightly provoked. Getting it right is a very, very costly and complex process which adds significant and often unnecessary cost to most projects.
You point out that when I say “Keep Objects and Components Inside Your Services” that this is good advice, but that I contradict myself later. Where?
Finally, you state in the first paragraph of your critique that the whitepaper is, in fact, "accurate". And yet you class it as worthless trash that should be ignored. I have to admit, I must be dumb as a post as I am now very confused – either:
- The paper is full of worthless trash and should be ignored
- The paper contains clear, consistent, accurate information that will help the reader decide when and where to apply which technology when building their system
Which is it?
So, in closing John, please reveal to us your manifesto for how distributed systems should ideally be designed and built. Please do so succinctly and unambiguously. Please provide examples of what your app and service code should look like under your view of the world.
I look forward to your considered response.
Rich.
