14 June 2005
The World Wide Web Consortium (W3C) defines Web Services as a "standard means of interoperating between different software applications." Well, that is pretty cool. If only we, the industry, could do that.
Some really bright guys at HP, Steve Loughran and Edmund Smith, recently authored an article entitled "Rethinking the Java SOAP Stack." Basically, they suggest, with quite sound evidence, that the current Web service stacks have failed to realize what Web services set out to do in the first place, that is, interoperate. Many current Web service stacks (emphasis on SOAP) take this great idea of Service Oriented Architecture and bastardize it by applying classic middleware approaches.
Steve and Edmund do a great job at depicting how we are currently experiencing an impedance mismatch from message (documents) to objects much like we see in the relational database to object mapping world. In short, these really great, flexible technologies like XML and XML Schema are shoved onto OOP. Since XSD and WSDL are at the very least mildly unpleasant to write by hand, the Web service stacks try to help us by making assumptions about document to object mapping. As a result, we as programmers are spared the details of schema and WSDL; however, the framework just serialized a definition of some platform specific data type:-) Now, that won't be very pleasant in another world.
So, Steve and Edmund accurately point out that what we are left with is a brittle, constrictive approach (much like RMI, Remoting, etc) to some great open, interoperable standards. How did that happen?
Enter Alpine. The HP crew suggest a lightweight SOAP stack that is only a SOAP stack. By delegating the mapping to the user application, the framework imposes no blanket assumptions about mapping. The caveat, we have more work to do with XML. But, at least, in theory, Alpine will get closer to that interoperable thing that Web services are supposed to do.
Okay, so now some questions:
Why are objects so hard to map to? Impedance. Are our modern-day programming languages in need of some rethinking (in particular, message documents and relational models sort of throw a wrench into OOP when a mapping paradigm is used)? Are SOA concepts creeping into OOP? How could we express SOA better in a high-level language like Java or C#? I mean annotations (and attributes) are great; but, are they really the answer to making services easier to deal with? Personally, I think Steve and Edmund are right; we should suck it up and do contract-first development and work with message objects until there is a better form of expression for services. But, what and when will that form of expression be?
Thanks Steve and Edmund; I look forward to hearing more about Alpine!