|
[obligatory boring disclaimer, sorry -- everything I say here is my personal opinion, not the WS Arch WG's ... others, possibly a majority, may well disagree.]
Kendall says "it's not clear that coherence and compliance are sufficient or necessary conditions of interoperability." I'm on a mission to remove most assertions about interoperability from the WSA document, because "archictures" don't interoperate, actual implementations of specs for programming interfaces and data formats interoperate. The objective of WSA is IMHO more to prevent architectural incoherence -- COM and CORBA being the most salient example. That is, the industry doesn't need another situation where "if you want to use my application-level component, you need to use my transaction component, my reliable messaging component, my security component, my SOAP implementation, etc."
That's not to say that there should be the One True Industry Standard reliable messaging spec, transaction handling spec, security spec, etc., but that one might reasonably hope that -- if the industry can agree on the basic "reference architecture" for how all these things fit together, one can get a SOAP implementation from Microsoft, a reliable messaging intermediary from BEA, a security component from Sun .... and use it all to access your Software AG enterprise infrastructure. Actually *getting* there requires more than the conceptual coherence, it requires real interoperable specs for WS-Security, one or more reliable messaging specs (there are a bunch of proposals out there), as well as the basic SOAP/WSDL/XML interoperability profiles that WS-I develops.
Finally, I'd like to address a point the Sean McGrath makes (
http://seanmcgrath.blogspot.com/2003_06_15_seanmcgrath_archive.html#200441002 )in linking to Kendall's article: 'It appears to me that the WS-Arch uses the term "interoperablity" to mean that a programmer can write against a software interrupt spec. ...
API interoperability has basically nothing to do with data interoperability.'
I respectfully suggest that the issue of APIs/RPCs is a red herring with respect to the WS Architecture [though not, of course, with respect to today's IDEs that let you expose your C# class as a 'web service' more or less blindly ]. Think of all this in the context of an architecture where the basic unit is a "service" and the only thing the consumer of a service needs to know about it is the format of the message that invokes the service, the format of the response, and the "message exchange pattern" of the interaction between them. Those messages can -- in principle, if not in the constraints of the WSA document -- be raw XML [or YAML, or whatever] rather than SOAP, and might be described by DAML-S rather than or in addition to WSDL. Whether some "wizard" [see Uche Ogbuji's wonderful rant http://www.adtmag.com/article.asp?id=7213] makes it easy for unsophisticated programmers to generate those messages is tangential to the WS architecture. Interoperability in the REAL web services world *is* ultimately about messages, state, and data -- not APIs. Pay no attention to the Wizard behind the curtain and the Marketing Executives from Oz that blather on about new paradigms and next big things and "Just Do It Our Way (tm) and all will be fine".
|
Previous Message
