XML and WS Talks at BEA World 2005

Last week, at BEA World 2005, I had a chance to hear
David Orchard talk about
WS-* standards [1], and future-proofing XML schemas
and web services [2]. I also had a chance to discuss a
few things. Both his sessions were quite informative and insightful, and
brought out a few key points. I would like to share my thoughts here.

SOAP Extensibility and REST

SOAP vs. REST is a hot topic, and there are valid points on both sides.
The

recent post by Anne Thomas Manes
summarizes the debate very well. But what makes SOAP successful is SOAP’s
extensibility model. WS stacks and intermediaries can enhance messages
without changing the application protocol (as dictated by the WSDL of the
web service). For example, you can add a SOAP addressing header or an
identity security token without changing the web service. This is a key
requirement for loose-coupling. There are several arguments about REST’s
extensibility. But extensibility models of REST and SOAP are quite
different and operate on different levels. Moreover, REST’s extensibility
is tied to HTTP, whereas SOAP does not depend on HTTP.

[On a related note, the reason for SOAP's success may be attributed to the
number of applications using it, and the number of products available on
top of SOAP and WSDL. The larger the community of users, developers, and
vendors using a technology or a product, the more successful it will be,
even when some other technology or product has some superior
qualities. Microsoft Windows (vs Linux), and Internet Explorer (vs FireFox
and Mozilla) are the best examples. Struts and Java Server Faces also fall
in this category, although some people might flame me for saying this.]

Changing the Schema

One of the approaches for versioning a schema is not to version at all.
That is to keep making compatible changes within the same schema. This is
an interesting approach, and works only if applications receiving XML from
other applications strictly follow the mustIgnore rule for processing the
XML. When a schema is modified like this, various users of the schema will
likely end up having an inconsistent view of the schema, and applications
using the schema may break if they encounter unknown elements or
attributes. Compatibility and adherence to the mustIgnore rule are key for
this approach to work. 

Extensions are for Third Parties

Extensions are for third parties. Period. The problem with extensions is
that schema owners have no control on either the data model or the
semantics of extensions. Both are completely the responsibility of the
extension owner and not the spec owner. But how can schema owner guard
against incompatible or invalid extensions, or changes that prevent future
changes to the schema? Of all the solutions discussed, I find the
following solution most useful. The solution is to wrap the extension in a
known type as shown below.

<xs:complexType name="Extension">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute>

</xs:complexType>       

The expectation is that third-parties use these extensions for
transporting data of type and semantics unknown to the schema owners. This
is the model we adopted in the WSRP 1.0 specification for third-party
extensions.

But there is a problem with extensions. Most XML APIs (including XmlBeans)
provide a very low level access to process extensions. For instance, if a
person has an extensions element, a developer
can call a getExtensions-like method to get the extensions,
but from then onwards, the developer has to use some low-level accessors
(like an XmlCursor) to process extensions. The same is the case with
extensions used in web services. Most web services toolkits generate
DOM-like accessors to process extesion elements.

Versioning and Web Services

Dave also talked about extensibility and versioning issues with web
services. In my experience, I find that web services toolkits and programming
models ignore versioning. Over the last several years, it
has gotten easier to create web services implementations either from code
(e.g. using a JWS file), or from a WSDL. These improvements help rapid development and deployment of web
services. But once you introduce versioning into the picture, these
standards have no clue. There is no @versionOf annotation for web services yet.
I admit that the problem is complex. As I
blogged earlier here, the solutions are not
pretty.

Overall, I found Dave’s sessions very useful. I strongly recommend
his papers on extensibility for anyone trying to understand schemas. There
is more to schemas than creating simple and complex types.

References

[1]

Industry Standards Overload: Making Sense of WSDL, SOAP, WS-*, and more!
(requires registration).

[2]

Future-Proof Web Services: XML Schema, WSDL and Web Service Evolution in
WebLogic 9.0 (requires registration).

Tagged as: Web Services