All this talk of computing as a fungible utility is very nifty but it wouldn't be the first 'sounds great, adds nothing' technology to come down the pike (repeat after me – "I mostly just need XML and HTTP."). So as I embark on my new job of helping to figure out BEA's utility computing strategy I want to make sure that there is some value in "them thar hills". Which means that before I worry about what utility computing is or what it should do I want to first know what the problem is.
Articles about SOA, the Web, Utility Computing, etc.
The official schema namespace for WSDL 1.1 is http://schemas.xmlsoap.org/wsdl/. But, and here is the fun part, the schema for that namespace given in the official W3C WSDL 1.1 note and the schema for that namespace given at the actual XML namespace URL are different. But wait, it gets better. Not only are the two schemas different, they aren't even compatible with each other! I'll give the gory details below but the bottom line is that there exist two incompatible versions of the WSDL 1.1 schema, one in the W3C note and one at the actual XML namespace URL which use the same XML namespace and the same element names. Just to add to the fun the WS-I has officially approved the schema at the actual namespace URL in contradiction to the schema in the W3C WSDL 1.1 note. So now implementers get to pick which industry body they favor since they have competing, incompatible, definitions for the WSDL 1.1 schema. I suppose errors like this make it more understandable why versioning in Web Services is such a disaster.
In a previous article I explained why XML Schema 1.0 is incapable of implementing the XML ignore rule and why this means that validating multiple versions of the same document is impossible using XML Schema in the general case. In this article I look at RelaxNG and show why it can handle multiple version validation without a hitch. I then discuss how to use RelaxNG in the real world, including with Web Services and conclude that the time has come for the XML and especially Web Services community to transition from XML Schema 1.0 to RelaxNG.
Writing a XML Schema is a challenge but as the first part of this document explains, writing a V2 schema that can accept V1 documents is in most cases impossible if you use XML Schema 1.0. In other words, if you want to write a backwards compatible schema you probably won't be able to do it using XML Schema 1.0. In an ideal world we would take the lessons learned from XML Schema and use them to start over, probably with RelaxNG. But until we can move over to a new standard we need a way to enable backwards compatible schemas to be written in XML Schema 1.0. Therefore the second part of this document explains how to use the XML Ignore Rule in conjunction with XML Schema 1.0 in order to create a validator that enables one to write backwards compatible schemas. The XML Ignore Rule can be best summarized as "if you don't recognize it, ignore it."
Below I walk through the issues an implementer faces in moving from V1 to V2 of a Web Service application. I am limiting my investigation to a sub-set of Web Service applications, a N:1 Service. That is, a Web Service application with many clients (N) for which there is only one instance of the Web Service application itself (1).
Some important best practices for using XML Schema. Read More
I just finished reviewing a chapter in an upcoming computer science textbook on Web Services. The authors made a heroic effort to give the reader a solid grounding in Web Services including HTTP, SOAP, WSDL, BPEL, WS-TX, WS-CO, UDDI, etc. all in 60 or so pages. In terms of information density, the result was the book equivalent of depleted uranium. To make matters worse many of the specifications they were describing had already changed since the time they wrote the chapter and will surely change even more before they publish. Which got me to thinking about the book I would want to read about Web Services Protocols.
If I were XML king for a day and could make any change I wanted to XML it would be to add length encoding. Length encoding would provide an order of magnitude better performance in handling XML messages, make XML proxies practical and finally rid us of MIME.