« Wrong, wrong, wrong, and again: Wrong! | Main | About Indigo, typed and untyped messages, and right or wrong »
18.02.05
Clemens Vasters on my "Wrong" post ;-)
Clemens Vasters comments on my answer to his post:
“Everyone writing DCOM apps must write and understand MIDL and NDR. Everyone writing CORBA apps must understand IIOP on a protocol level. Everyone who codes in C must understand x86 assembly. Correct?”
No, that’s not correct. There is a very, very important difference. The difference is about “logical” and “physical” protocols. or even better between contracts/interfaces and hard-wire protocols. On the other hand Clemens Vasters is right. Every model is passed through a transformation chain until it reaches “its final destination”. C is an abstraction of x86 assembly which in turn is an abstraction of “1001101001001…”. The trick is to decide when further transformation are of no importance to the developer.
Let’s take his example of CORBA and IIOP. Is IIOP important to the developer. No! Oh, I can hear your screams. I know about “IIOP Complete” by William Ruh et. al. This is surely a book worth reading. But I would like to reduce the required knowledge level to that of an application developer. Then, is IDL important to the CORBA developer? Well, yes and no. It is certainly helpful to know about IDL but IDL and C++, Java, and Smalltalk interfaces share a common paradigm: objects and OOP. Therefore the contract described by a C++ class is equivalent to the IDL contract.
Now, here’s my concrete answer: SOA is a paradigm based on messages/documents passed between participants. This is something completely different than invoking methods on a remote object by an RPC call. Indigo’s implementation first programming model resembles RPC calls. This may be applicable in certain contexts. And sometimes it is certainly preferable. But when SOAs are concerned stick to messages and documents, please. There is an Indigo contract first programming model. Use it by all means. But do care about the message-based SOA programming model, even if it is a little bit more, hm …, clumsy.
Maybe this has been a misunderstanding? Indigo has it all. Indigo rocks (when put to correct use) :-)!
Posted by Hartmut Wilms at 18.02.05 13:48
Comments
You haven’t seen enough of Indigo to make that “looks like RPC” assessment.
Posted by: Clemens Vasters at 18.02.05 13:53
You are certainly right about me haven’t seen enough of Indigo.
My point is that when dealing with services which may be called by platforms or technologies you might never even have heard of, you should know about the contract and its vocabulary, syntax and semantics. Nothing should “hide” the programming paradigm.
O.K. I will stick to the things I know about. Today VS.NET (and almost all other tools in the Java or .NET world) hide the “SOA complexity” from the developer by providing a transformation from OOP interfaces to web services. Messages or better their content (document) are serialized to objects. This helps the developer when accessing the content through an OO interface. But it doesn’t help to understand the message-based nature of SOA. SOA demands certain ways of dealing with interactions. Don’t hide these facts!
When reading Don Box’s blog entries I understood that Indigo provides both, an “untyped” message-oriented programming model AND a, well, “OO typed” programming model. Again, I don’t want to condemn the latter, it will have its uses, but the message-based model suits the message-based SOA better.
Right?
Posted by: Hartmut Wilms at 18.02.05 14:18
Message doesn’t and should not mean “untyped thing”. Actually, the contract mandate tells us the contrary. If you have a contract, tooling can use that contract to serialize and deserialize into typed object graphs. Reversely, if you have types, you can create contract.
All programs you write that communicate with messages have a certain degree of typing if they shall be useful. If you are speaking against serialization (“OO typed”) in general, you are speaking against productivity. The job of the tools is to make sure that the serialization format easily interops, can be properly versioned, etc. That’s what my demand is from Indigo and any other tool.
It is infinitely easier to write an XSD expression that cannot be mapped to any existing programming language than doing the reverse.
Also: the vast majority of developers out there simply can’t read (and have no interest in) XSD or WSDL. You might dismiss that with “they should”, but in the end, most of the programs that you will have to interop with will be written by people who ignore what you consider the “contract details”. You must be begging for tools that don’t let them make stupid mistakes.
And once the ignorant folks no longer can make mistakes, you can happily use the same tools and go have a good time with friends instead of hacking up WSDL at night.
And, by the way and because you cite him; Don and I agree completely on that matter.
Posted by: Clemens Vasters at 18.02.05 15:41
I think we actually agree on many things concerning web service development and SOA, although one could get another impression.
I wrote another blog entry to clarify my position: http://www.innoq.com/blog/hw/2005/02/18/aboutindigotypedanduntypedmessagesandrightor_wrong.html
I’m sure that Don Box and you agree on that matter. I was disturbed by the impression that you completey (and maybe in all cases) want to hide the concrete contract. However, I rather agree with Tim Ewald and Aaron Skonnard on that specific contract matter. After all I’m still doing a lot of Java and interop stuff …
Posted by: Hartmut Wilms at 18.02.05 21:24