Indigo has a Simple Messaging Model?

John,

Interesting... I'd think that Steve was also refering to the use of the Message class to mean "messaging only" and not imply an object model, though I'm not sure about it. I do think that your assertion that building proxies that look like RPC is probably not the best thing :)

That said, am I the only one that's scared (or rather, saddened) by Steve's assertion in a past comment on your blog that "WCF is the programming model for MSMQ moving forward" (see http://pluralsight.com/blogs/johncj/archive/2005/08/04/13855.aspx#14072). System.Messaging is a a pretty sweet API, imho, and one that is indeed fairly message oriented, fwiw (I also fail to see how you could get the most out of MSMQ just by using WCF, but I haven't looked too deep on it)

Ok I'm starting to understand a little bit more about what you feel is so difficult about RPC semantics in business apps. It is your belief that service orientation can only be done when clients and services are not bound together in any way. In your mind there has to be something in the middle smart enough to know where to take the request and put it. Couldn't you design things this way through the use of intermediaries and the message object? I guess what you're saying is that's really not easy and it's not really being focused on through most of the materials available with the Beta 1 bits.

So I'll bet your thinking, great he finally gets it. Well not completely, I think what's interesting is that we've taken this idea of "service orientation" and allowed it to consume the concept of distribution of application components. If Indigo/WCF is truly the unification of distributed programming models then isn't there a RPC model that would leverage proprietary transports and more of a messaging type model that is meant to enable the "service-oriented" enterprise?

In your post above you even reference "service-orientation" when talking about a set of principals that are being presented to developers. My question is, what are those principals exactly? How is it that a specific implementation technology could in any way be preserving "service-oriented" principals? It is my belief that "service-orientation" is a design and implementation strategy that allows an enterprise to expose core business application building blocks that can stand the test of time (aka code reuse for the web generation).

Now I will admit to feeling somewhat out of my league when you begin discussing RPC stylings creating mass conflict in a "service-oriented" world. I think there are a ton of things that lead to chaos in a "service-oriented" world (versioning, testing, boundary definition, autonomy, management/administration, etc...). RPC stylings is the least of my concern as a developer who is trying to get my head around how it is we design these freaking things.

With that said, your last post that gave a listing of the 5 things you loved about Indigo explained your reason for being so consistent with your message. I respect that and sincerely hope you get what you're looking for. I personally still feel quite satisfied with the versioning enhancements delivered in the programming model that will allow me to eliminate most of the tight coupling I deal with today in first genreation web services.

Tomas,

Yes, I share your apprehensions about MSMQ and Indigo (as well as your appreciation for System.Messaging).

Tom,

I'm working on explaining in more detail my view of SOA. I will say this now. When you build a distributed application there is always something between a service and its callers, i.e. the network. One of my major beefs with the Indigo team is whether or not it is a good idea to allow developers to pretend that the network isn't there. The design goal of RPC is to allow a remote call to look exactly like a local call. I think that is a serious mistake.

I think more people need to read "A Note on Distributed Computing" by Jim Waldo (and the other folks) at Sun. I think if there's ever a short treatise on the fallacies of "pretending that the network isn't there" that's the one.

Sun made an attempt with the Jini technology to bring service orientation (before it became a buzz word) and the network more to the front in software systems based on the lessons learned from the past. However, I've been wondering over the last couple of years if they didn't listen to themselves entirely. Jini (at least the implementation that is commonly used) still is heavily reliant on RMI which in essence is primarily a RPC-like model. It feels like they came so close to doing it right, but still came up a little short.

John, from reading your posts it appears Indigo is falling into the same trap. All the pieces are there for a proper message-based service-oriented design, but they still want to pretend the network is not there -- that developers can think in terms of services as objects. That right there flies in the face of over twenty years of hard knocks.

I can at least say I have youth on my side to claim I didn't know better. ;) I'm just now gaining an appreciation of messaging APIs. What I don't get is why there's this idea that messaging APIs are "harder" for developers to understand than RPC driven models. I've had the pleasure to teach RPC models (Java RMI, .NET remoting, COM+, ASP.NET web services) to developers and I can say first hand that they're no piece of cake for developers to pick up beyond "Hello, World". When I hear the word "proxies" come up with regards to services, I keep hearing the robot from Lost in Space -- "Danger, Danger Will Robinson!"

Ladies and gentlemen, let's just make something very clear here. Nobody here in the WCF team wants to make developers think that the network isn't there. However, we can't keep pushing it into developers' faces every time they need to do something that might touch a wire.

What most of you are referring to as RPC is not, in fact, anything to do with RPC, but a coding construct which is clean and efficient and doesn't tie one's code to the transport implementation itself. Now, before anyone misunderstands me, I'm not saying that by using EnterpriseServices or ASMX that you're not coupled to a transport, but the fact is that you can convert code that says component.DoSomething(data) from ES to ASMX pretty quickly and easily. Now imagine the amount of work to convert code that talks native DCOM to a SOAP based messaging stack. By using Service.Action([Parameters]), you're essentially opting to decouple your implementation from your platform's. Service.Action([Parameters]) is still an effective way to call actions on a service, and yes, this doesn't force into developers' faces that the service being called is remote ... however, the

FooProxy foo = new FooProxy(fooBinding);

call does ... that way, the developer knows that what is being created is a proxy, not a local "object".

Will this stop people building chatty apps? No. Should we stop people building chatty apps? Meybe ... but then we'd eliminate a whole host of apps where chattiness is absolutely necessary (airline booking), banking, etc.

To close - the network is always there. What network, however, is not always clear at development time - at deployment time, it might be Named Pipes, UDP, TCP, HTTP, WAN, Internet, etc. Decoupling developers from having to know what transport (security and reliability) capabilities are configured under their services whilst giving them cues that they're not dealing with local objects is, to me at least, a good compromise, no?

Rich.

James says:
"Sun made an attempt with the Jini technology to bring service orientation (before it became a buzz word) and the network more to the front in software systems based on the lessons learned from the past. However, I've been wondering over the last couple of years if they didn't listen to themselves entirely. Jini (at least the implementation that is commonly used) still is heavily reliant on RMI which in essence is primarily a RPC-like model. It feels like they came so close to doing it right, but still came up a little short"

In their defense, the RMI implementation was the default implementation, not the only possible implementation. The RMI implementation was the default because it was easy. I have never heard of anyone implementing a non-default implementation (but I feel sure someone did.)

The end result is that the default implementation is generally the only implementation...Will Indigo suffer from the same fate? Way to early for me to tell. I am sure others have opinions though...