What's Next for Web Services: GXA and Beyond
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The core technologies of Web services—SOAP, WSDL, and (to a lesser degree) UDDI—are certainly useful today. Yet nobody could argue that they're fully mature. Much remains to be done, and it's a safe bet that, one way or another, additional features will find their way into the world of Web services. For this technology family to become as significant as it promises to be, however, these additions need to be done in a way that all vendors support.
Adding features isn't as simple as it sounds. Web services are a rapidly moving area, one with lots of commercial potential. In other words, big vendors believe that big dollars are at stake. Reaching agreement in this environment won't be easy.
For the leading example, think about SOAP. This very simple protocol allows anybody to add arbitrary headers to any message. Flexibility is admirable, especially in the early days of a technology. Yet if TCP had taken such a loose approach to packet definition, there would be no such thing as the Internet today. Achieving effective, full-featured interoperability among different vendor's SOAP implementations requires agreement on how at least some of these extra headers should look.
Toward this end, Microsoft in late 2001 announced its Global XML Web Services Architecture (GXA). The GXA specifications define a set of SOAP headers for addressing common problems. These headers, and thus the services they provide, can be combined as needed for a specific application. The GXA specs currently define headers in four areas:
WS-Security: Provides a way to pass security credentials, such as the identity of the client, and to indicate which options (if any) are being used to provide integrity and confidentiality for a SOAP message. An integrity service allows the message's receiver to be certain that the message wasn't modified in transit, while a confidentiality service typically encrypts a message so it can't be read in transit.
WS-License: Provides a standard way to identify common kinds of credentials, which are referred to as licenses. Among the supported options are Kerberos tickets and X.509 certificates, each of which relies on strong cryptographic techniques to allow the receiver to verify a client's identity. WS-License is typically used together with WS-Security because it defines a concrete way to represent important security information.
WS-Routing: Defines header information that can be used to route messages across intermediate SOAP nodes. Note that this routing happens at the application level, so it's distinct from the service network routers provide.
WS-Referral: Defines header information that allows configuring SOAP implementations to correctly route SOAP messages. Unlike WS-Routing, which is used to specify what path a particular SOAP message should take, WS-Referral allows configuring of the SOAP systems themselves to correctly route messages.
These four specifications were all created solely by Microsoft. More recently, Microsoft and IBM have worked together to create WS-Inspection. Unlike the technologies just defined, WS-Inspection doesn't define new SOAP headers. Instead, it specifies a standard XML-based format for describing which Web services are available at a particular location. These so-called inspection documents provide a simpler alternative to UDDI, although one that offers fewer features.
Defining standard solutions to common problems is important. There are other enhancements that can also make Web services technology more effective, however. One of these is a mapping of SOAP directly to TCP, an option known as Direct Internet Message Encapsulation (DIME). Doing this allows better performance than sending SOAP messages over HTTP. Other forthcoming enhancements to this technology family will likely include a language for defining multiple Web services interactions and a way to guarantee reliable delivery of SOAP messages. More additions are sure to come as Web services continue to work their way into the fabric of modern computing.
It will be interesting to see how these vendor-defined specifications are transformed into standards. Microsoft has indicated that the GXA specs will be submitted to relevant standards bodies, such as the Worldwide Web Consortium (W3C). Exactly how this will happen, or when the process will complete isn't yet clear. Once implementations appear, vendors are reluctant to change. Anybody who lived through the browser wars, with Microsoft and Netscape each adding its own features in advance of the W3C standards for HTML, can't help but shudder at the prospect of repeating the experience.
It's a good sign that the two major players in Web services, IBM and Microsoft, are working together. It could be that agreement between these two is all that's really required, and everyone else will end up falling behind. That is exactly what happened with the first round of Web services technologies, and the result wasn't bad at all. An even better sign is the recent formation of the Web Services Interoperability (WS-1) group, with nearly every major vendor on board. As long as implementations from different vendors work together, however it happens, the rush to Web services isn't going to stop.