Dare Obasanjo takes issue with my previous blog posting:
Although Steve Vinoski's argument sounds convincing, there is one problem with it. It is actually much easier to make an uninteroperable Web service if one starts with the service contract instead of with object oriented code. The reason for this is quite simple and one I've harped on several times in the past; the impedance mismatch between XSD and objects is quite significant. There are several constructs in W3C XML Schema which simply have no counterpart in traditional object oriented languages which cause current XML Web service toolkits to barf when consuming them.
Given that I've been writing and talking about the impedance mismatch in distributed programming language mappings for awhile now, I'm afraid Dare is preaching to choir here, at least about the problem. I did, after all, help write the OMG IDL C++ Mapping, which, thanks to the ever-wonderful politics of standards, is probably the most hated language mapping ever produced. Dare's solution, however, is exactly the opposite of what I'd recommend.
An impedance mismatch always forces you to choose one side or the other as the "primary" side. Those new to the game, or those who need to get something done quick and dirty, invariably choose the programming language side, because it's more comfortable. Unfortunately, if the system they develop becomes important enough or lives long enough that it becomes used outside of its original design context, the result is pain. Always. I explained why in my previous post. Chris, Stefan, Steve, and others have also shared their sound advice on this matter.
I also talked quite a bit about the impedance mismatch problem in my "It's Just a Mapping Problem" column from Internet Computing back in the May/June 2003 issue. I also touch on the issue somewhat in my latest column, "A Time For Reflection." Good developers know and can apply a wide variety of techniques and languages so as to be able to properly avoid impedance mismatches, while the not-so-good ones try to force-fit everything into their own limited little worlds.
Judging from this article, though, Dare seems to already know about the limitations that languages can impose when used as he advocates. While I don't think the solution he talks about there is the answer, I do believe that stepping outside the realm of traditional popular programming languages is a move in the right direction.
Comments (3)
Looks like the geniuses at Microsoft are just about 15-20 years behind the state of the art - rather more than usual. Didn't OMG identify this kind of problem in the late 1980s, and propose working (if less than ideal) solutions in the early 1990s?
Posted by Tom Welsh | February 13, 2005 6:04 AM
Posted on February 13, 2005 06:04
"WSDL first" approach is surely the cleanest way to define interfaces when the emphasis is on the integration side of application development. But this is only one part of the problem, now web services are seen also a way for implementing "remoting" mechanism and programmers are tipically more used to define interfaces for their distributed components using the development languages, java interfaces for J2EE or annotated class for .NET. In my opinion a pragmatic approach should be strongly supporting the WSDL first approach, but also to support this new trend in developing application, annotated POJO. In the later case we could delegate to the tools and to the mapping standards (like the JAX-RPC Java -> WSDL) all the constraint and rules to avoid "polluting" the resulting WSDL with language idioms. For example, looking at the JAX-RPC reverse mapping from Java to WSDL it seems to me that the WSDL produced are quite clean and reasonable.
Posted by David Greco | February 18, 2005 3:05 PM
Posted on February 18, 2005 15:05
Hi David, yes, I agree that POJO is popular. However, it's just another language-first approach in a long line of language-first approaches. As I said in my blog, any time you map from POJO or anything else like it to WSDL or anything else like it, one side necessarily becomes the primary focus, and the other side loses. You simply can't map from A to B without loss, and that loss typically occurs on the non-primary side of the mapping. With the POJO approach, the POJO is obviously the focus, which implies that the XML side loses, in the sense that it winds up being less than it could be. Later, when the "pure" system needs to be integrated with something that's non-POJO, the integration winds up being way more difficult than it needs to be, because the original developers naively assumed that it would be pure POJO forever. And that's the problem with the POJO approach, or any of its similar predecessors, to the problem of distributed computing -- it attempts to make development easier and cheaper, but does so by ignoring the diversity and heterogeneity inherent in distributed computing, thereby making maintenance harder and more expensive. Such a trade-off is already well proven in software to be the wrong way to go, because maintenance is almost always a much larger piece of the equation. As I've said many many times, distributed computing is hard -- period. I do not (yet) know how to make it easier, but I'm extremely certain that POJO is not the answer.
Posted by Steve Vinoski | February 22, 2005 11:53 PM
Posted on February 22, 2005 23:53