Mort Gets the Message

Aach!! I knew it! He's a witch. Burn Him!!!

Well said John.

Finally...someone says it with eloquence belying his Mortness.
I truly can't believe that all the wonderful people on the Indigo team can fundamentally miss the mark as they seem intent on doing.
Maybe more and more of these posts will encourage the WCF team to take a long inward look...

I'm still completely confused by the specifics of your complaints.

In Indigo, Mort writes VB or C# methods that process documents. Mort implements those methods on classes because that's how you implement code in the CLR. But this isn't "object-oriented". Mort does not get an instance of a service, Mort cannot marshal references to service instances, Mort does not have an instance of the service on the client, etc.

Also unlike "oo", Mort can design an Indigo contract that asynchronously processes an incoming purchase order document and returns an asynchronous status message after processing is complete. The client views this as a fire-and-forget asynchronous send and then a document passed later to an event-handler Mort provides for the purpose.

If a service is implemented synchronously, Mort can still make an asynchronous call to the service and then process the response message when it returns, using the CLR async programming model.

What do you mean, in particular, when you say you don't want your document sends to look like a method call? How do you do anything in the CLR without calling a method? Do you want all the method calls to be "Send(document)"? Do you dislike "ProcessPurchaseOrder(document)"?

As compared to Biztalk, Indigo lets you process documents with VB or C# code intead of BPEL: is that what you're calling "an OO facade"? I imagine that in the long run, you'll be able to run orchestrations directly in the CLR and trigger CLR code (Indigo service implementations?) in Biztalk. I can see this as a natural consequence of the creation of a "Connected Systems Group" out of the Biztalk and Indigo teams.

Do you dislike the event-handler-like way you process incoming messages on the "client" side?

Indigo has not made many tools public, yet, so I can't figure out what you mean by "being stuck with the output of your tool". Mort has three choices if they want to do translations between public and application contracts. They can put Biztalk in front of an Indigo service; they can use the standard tools to design translations and then insert them into the Indigo pipeline; or they can build public services that use VB or C# to translate documents into the application contract. None of these options is more or less Mort-ish; each has their place.

Are you unhappy with Indigo because it is possible to make request-reply calls? From our point of view, there's a time and place for request-response (the Amazon shopping cart, the eBay bid processor, the mail program, the ATM processing system, airline reservation systems, helper-classes in middle tier scenarios, etc). We worked hard to replace MSMQ, ASMX, Remoting, and ES with a single programming model: we want to get away from making people decide which product they want to use, letting them focus instead on deciding which pattern they want to use. We believe that n-tier, queue, and pub-sub are all optimal patterns in their place: we have tried to provide support for each.

As you probably tell, I believe I'm still missing your point. I can tell you're unhappy, but other than rhetorical flourishes (which you're good at ;), I can't make any specific sense of your complaints when held up to the reality of Indigo.

Steve,

Have you considered everything you wrote?

"Also unlike "oo", Mort can design an Indigo contract that asynchronously processes an incoming purchase order document and returns an asynchronous status message after processing is complete. The client views this as a fire-and-forget asynchronous send and then a document passed later to an event-handler Mort provides for the purpose."

Do you think Morts can actually comprehand and use that?

I've seen a lot of MS technologies being abused over time (specifically MSMQ).

The fact is that Indigo with its "do everything through us approach" will eventually limit us.
Morts won't be able to do things quickly and nicely because it DOES take some knowledge to understand and do what needs to be done correctly.

You can eat the pie and keep it whole. Generic stuff are harder to eat for most people. Just look at a lot of VB.NET programs. It clearly shows that most people moving from VB6 to VB.NET write what people usually refer to as "VB6.NET" code because .NET is generalized and not specific enough like most of the VB6 code they used to write. Becase they CAN create an ADO object instead of using ADO.NET they use it in NEW code.

And don't let me start about serialization. ByRef, ByValue whatever. Its NOT that simple.
Heck, its not even that simple if you chose to implement ISerializable and you serialize a graph...

On another note, I personally like the fact that I can customize Indigo as much as I can but that's becasue this is the level I usually work with (implementing the underlying stuff).
Its an infrastructure that cannot compete the Mortness of Access and the likes. That's a fact.

Perhaps there is room for a wrapping API that will make that even cleaner and more understandable for most people.

Something that cannot be interpeted into other meanings.

Yes, I considered everything I wrote here. ;) One difficult thing about responding to this post, for me, is that its raising a large number of points simultaneously. Not all of them are the arguments of a Mort. Im trying to respond relatively broadly, and so I dont always speak to the supported Mort-center of the argument.

I believe programmers like the one that John is styling himself to be will not need to understand the CLR asynchronous programming model. They will simply use the center of Indigo. They will build one-way contracts; they will send around documents as message; they will have a simple experience. We try to design the product so that Mort finds best-practice by using the most immediately accessible parts of the system, and so Elvis and Einstein can do what they want.

For each message-Mort like John, there is also a method-Mort who balks at the degree of decoupled message-oriented ideas baked into Indigo. I want to throw exceptions to my caller transparently! I want to share types! I want service instance references! Indigo needs to attend to those scenarios, too. We recognize that there is no one true way to build distributed apps (see, for instance, the books by Fowler and Hohpe ;) ). There is no one true Mort.

In the same way that there's a value in a single CLR that supports different languages aimed at different use cases, so I believe theres a value in a single Indigo that supports different messaging patterns aimed at different use cases. If you constrain the platform so that it only does typed messaging, then you need a different platform component oriented around each pattern. Weve been down that path. It doesnt work. In the future, well look to tools to make it as easy for Mort to build services as it is for them to build WinForms today. Thats our strategy: a general-purpose platform for power, and then tools for ease of use.

One of the reasons why this is a difficult conversation for me is that it deals with generic complaints rather than specific ones. Were still in a place where we can change Indigo to better suit user requirements. It would be useful for me to make the conversation concrete and critique a simple piece of Indigo code processing a single document off of a queue, to see where it doesnt meet the Mort bar as envisioned here.

Hi Steve,

I do agree with you that this is a more "theoretical" disscusion and I do wish I had additional things to add to the more practical things (I have seen Indigo and I don't have anything specific to add on top of what was already disscussed in various forums).

I think the main practical point John is trying to pass here (and if not, at least I understand it from here) is that there IS a need for tools (like you said) to help Morts.

The main problem with tools is that they make things more complex (even if they are nice little add-ins to the great new extensibility model in VS.NET 2005).

So either these tools will add a seamingless experience that no one will know what is going behind, or they will just make Mort's life more difficult.

I suppose code generating tools will be the weapon of choice and the area in Indigo that needs to be addressed is how easily more than trivial scenarios can be code generated using tools.