Back to the Basics

The good thing about getting lost is that I found a good little Indian restaurant. I was wondering how something like that would be possible in the land of the chains – Orlando must have at least one of every restaurant chain in the world.
After me an Indian guy came in with two women, then a British couple, and then an Irish man and his son. So that would explain it…
I was there to teach the Introduction to Web Services and SOA at the OMG’s MDA, SOA, and Web Services conference.
This was a 3/4 day tutorial covering the basics of Web services technologies and SOA concepts. It is derived substantially from material from my first book, Understanding Web Services, and includes some material from my new book, Understanding SOA with Web Services.
The IONA Web services and SOA courses are technology independent, just as the books are. One advantage of working for IONA is that you don’t have to take side in things like the Java vs .NET competition.
It’s coming up on three years since the first book came out, and about five years since SOAP was submitted to W3C, which pretty much started the whole Web services thing (although it wasn’t called Web services then – all we really had was the SOAP proposal).
It’s important to stop and remember the basics from time to time. And even though I’ve been working recently more at the so called higher levels of the Web services stack in the WS-CAF technical committee at OASIS, it was good to have the chance to go over the foundational material once again.
For example, all Web services specifications are applications of XML. That means, at least in priniciple, that one should be able to work with Web services artifacts using off the shelf XML tools. It means Web services should inherit the properties and practices of the XML community. How much this really is or is not the case is worth keeping in mind as Web services progress.
Everything in Web services is an XML document. The original motivation for SOAP was as a way to use the Internet for business to business communication. Some of the original specifications, UDDI in particular, were oriented almost completely to the public Internet. Today’s UDDI suppliers are struggling to re-orient the standard toward the current application of Web services inside the firewall, and a very good question is whether or not the original specs were written too far in the other direction to be reasonably brought back.
A SOAP message is an XML document. An XML document by definition has one and only one root element. The fact that a SOAP message is an XML document presents an interesting problem when trying to use SOAP to send an existing XML document. Either you have to transform the document to add the SOAP envelope and body tags, or use SOAP with Attachments, which despite its early broad endorsement as a bridge across the political divide between Web services community and the ebXML community (each of which had different views of the starting point for the commercial use of XML over the Internet), remains controversial today – meaning not adopted by the entire Web services vendor list.
A WSDL file is an XML document. And XML documents have associated schemas. If you look inside a SOAP message or WSDL file you will see the XML namespaces that identify the version. Here for example is the SOAP 1.1 namespace URL: http://schemas.xmlsoap.org/soap/envelope/. It is a “dereferenceable” namespace, meaning if you click on it or type it into your browser address bar and do an HTTP GET on it, you will receive the SOAP schema, which is also (of course) an XML document.
An interesting relationship exists between XML document instances and types (i.e. DTDs or Schemas – DTDs of course not being valid for use in Web services specifications). A given document instance can have multiple types associated with it. This characteristic of XML derives from SGML (on which XML and its sibling HTML are based), which was purely a document processing language. The idea was that a given text might have multiple output formats — letter and A4 say, or letter and online help — and it’s easier if you can just change the “content model” (aka Schema) instead of having to edit the document every time you want to change the output format.
Does this mean for SOAP that a given message could have multiple associated schema formats? Yes, it does, since everything is XML. Does this happen much in practice? Not that I know of — but it somehow seems like it should. Then you could, for example, create all your messages in the document oriented style, using doc literal (i.e. Schema) encoding, and define one Schema for mapping the instance data into an RPC oriented object system and another for mapping the instance data into a message queue system.
SOAP and WSDL were originally designed to encompass both RPC oriented and message queuing style software systems, which today is becoming one of the benefits of ESBs. Web services are also designed to be transport independent. That’s why everything (the address, security headers, etc.) has to be put within the envelope – so the message can be delivered using whatever communication transport you want to use.
Some of these original characteristics of Web services still seem as if they are not entirely fulfilled within most current vendor implementations. It seems as if most software vendors have simply adapted Web services to their existing software environments, rather than developed new software environments capable of exploiting the full capability of XML.
As my friend Oisin Hurley likes to say, in theory, theory and practice are the same thing. In practice, however, they are not. As an industry we still have a ways to go to realize the original Web services vision.

Advertisements

Comments are closed.