« Search Engine engine resources | Main | whimper not bang? java.net »

Kendall Clark reviews ws-arch

XML.com: A Tour of the Web Services Architecture

On the 'XML backplane':

XML, according to section 1.7 of the WSA document, is the "backplane" of a web services architecture and is "much more fundamental" than either SOAP or WSDL. That's true, if for no other reason than both SOAP and WSDL are dependent on XML.

SOAP 1.2 and WSDL are not dependent on XML, they're dependent on the XML Infoset. That's a world of difference. SOAP 1.2 was deliberately designed to be decoupled from XML via the Infoset - this allows the potential use of binary or non-xml formats in the future. I submit that's not a good thing, but anyway there's no need to argue the point about an architectural dependency on XML if there isn't one (there is a practical get-the-job done engineering dependency on XML, but that's different ;).

On the web services 'infographic':

With all due respect to the WS-Arch, that's a stew, the visual equivalent of extreme spaghetti code. While I have reduced the size of this image (so that it will fit the XML.com site better), even at its original size it has several problems. I don't intend to provide an Tufte-like analysis, but it is overcrowded, there's no obvious "path" through the information it's meant to convey, the relationships between the terms are hard to discern and to understand, and it's so visually cluttered and busy that it doesn't even suggest a coherent, balanced, well-ordered architecture.

I've been lucky enough to work with the person that drew this graph, Frank McCabe. Frank is extremely smart, and well known in agent and ontology computing circles - notably he has made large contributions to FIPA's Abstract Architcture. The FIPA AA in my opinion remains the best articulation of a service architecture, but lacks the profile or coolness bestowed by XML+Internet protocols that is attracting the big players eager to roll out a new stack.

Yes, the picture of the graph is a mess, but that's missing the point. The structure of the graph is what counts. There are two things worth noting about the structure:

  • it's acyclic
  • all arcs are labelled

An acyclic, labelled graph. In other words, this graph is tailor-made for description in KIF/RDF/OWL/DAML-S (take your pick). I have no doubt that this graph or its progeny are where the future integration web services technologies with semantic web ones will occur. Far from being a stew, it's been one of the highpoints of the arch group's work in the last few months. What needs to happen next is for the ws-arch group to stop associating the more useful semantic web work with fringe AI research and thereby denigrating the technologies that provide the very capacity they will need sooner or later - to formally describe both the elements in the web services architecture and their relationships. We already know that WSDL and UDDI aren't up to the job. No doubt Kendall will pick up on this - he's been following the semantic web closely for some time.

On REST 'integration':

Section 1.6.3 ("SOA and REST architectures") attempts a rapprochement between the advocates of REST and the advocates of RPC- or SOAP-centric web services. That is yeoman's work and the WG should be publicly commended by all interested parties for undertaking it.

It seems the arch group should be applauded for acknowledging REST. I wouldn't go so far. The lean of the arch group has been to define web services architecture as being something distinct from web architecture (check the archives). Web services architecture seems destined, by accident or design (I'm really not sure) for behind the firewall, and every now and then SOAP messages will be lobbed over the web to our business partners. Sometimes I wonder why is it called a 'web services' architecture. I think the word 'web' has caused too much confusion and strife. Why not just call it 'integration services architecture' or 'middleware services architecture'? The web's actual architecture has little to do with what's being defined here other than offering cheap carriage (not neccessarily a bad thing). The best articulations of how the web works are not-normative input to ws-arch and it's taken no small amount of badgering and advocacy to get REST on the ws-arch radar - Mark Baker in particular has taken a lot of flak for his stance.

In the final analysis ws-arch neither extends not encompasses the web - that's so much the worse for both architectures. With my engineering hat on, what concerns me is that the two technologies that have driven web services over the last few years, XML and HTTP, are being marginalized in favour of an expanded architecture that mandates infosets and protocol agnosticism, and this is counter to what I see makes for successful cost-effective solutions.

June 21, 2003 11:46 AM


Trackback Pings

TrackBack URL for this entry: