• Sidebar: WSE 2.0 Highlights New Programming Model
• Sidebar: Lifecycle of a Web Services Specification
• Chart: Status of Major Web Services Specifications

A new developer toolkit from Microsoft and a recent interoperability demonstration with IBM show that the IT giants are continuing to make progress on Web services protocols. Agreements on these protocols promise to simplify application integration across vendor platforms, and the security and reliability gaps in the initial versions of these protocols are gradually being filled. However, Web services protocols are still not complete, and companies using early versions of the protocols through Microsoft's toolkits should be prepared for future compatibility problems.

Web Services Architecture Developing Slowly

Microsoft and IBM have demonstrated a set of Web services, built on both Microsoft Windows and IBM WebSphere, that successfully communicate using some advanced security and reliability capabilities. Although many vendors have successfully demonstrated interoperability via the Simple Object Access Protocol (SOAP)—the basic Web services protocol—IBM and Microsoft demonstrated additional technologies that Microsoft now refers to as the Web Services Architecture (WSA). First introduced under the name Global XML Web Services Architecture but rechristened, WSA aims to make Web services a viable architecture that can be used to integrate applications across platforms and across the Internet. Both IBM and Microsoft agree that cross-platform, cross-organization integration requires the following capabilities (which are lacking in the minimal SOAP protocol):

• Security—the ability to make certain guarantees about the origin, contents, and authenticity of a message
• Transactions—the ability to ensure the integrity of underlying databases, even when accessed by multiple Web services
• Coordination—the ability to describe how control and data flow among Web services
• Reliable messaging—the ability to guarantee that a message is actually received by the intended recipient.

Most of these functions are very familiar to IT planners—they are the same problems faced by managers deploying internal mission-critical applications for the past 20 years and must be solved once again as they move their application architectures to Web services.

The Sept. 17 interoperability demonstration showed some of these capabilities, based on Web services protocols delivered in a blizzard of specifications over the last two years. Some of these specifications have worked their way into developer toolkits but other than the most basic Web service specifications (such as SOAP), none are yet supported in Microsoft’s mainline OSs, developer tools, or server applications. (For a chart showing the purpose and status of some currently proposed specifications, see "Status of Major Web Services Specifications".)

New Way of Working

The demonstration with IBM shows Microsoft's adoption of a different approach to standards, one that is forcing the company to coordinate and develop with partners more frequently and earlier than in the past. This has implications both for partners and for early adopters of Web services.

In the past, Microsoft could afford to develop software largely in a vacuum, defining its own specifications, following its own schedule, and then announcing a fait accompli. In the process, the company either ignored interoperability with other OSs or left it up to third parties. When Microsoft developed its Component Object Model (COM) and Distributed COM (DCOM), for example, it did so largely by itself and relied on third parties (such as Software AG) to provide Unix implementations (which in many cases were never delivered).

Because interoperability among vendors is a fundamental tenet of Web services, however, Microsoft has no choice but to draft specifications of protocols well in advance of implementation and host workshops at which customers and partners can give feedback. If Web services devolve into a set of incompatible implementations, developers and IT organizations will balk and Microsoft will fail in its efforts to sell Windows Server 2003 as an application server and Web services platform. (For more information on how a Web services protocol moves through these stages, see the sidebar "Life Cycle of a Web Services Specification".)

The new approach to specifications benefits customers and partners, in that they can begin training key architects and developers earlier and give feedback on the specifications while there is still time for changes to be made. However, IT planners hoping to build systems on the protocols should be wary: this openness also means that the inevitable missteps that accompany any software design project will be more visible than in the past. Some protocols may undergo substantial, incompatible changes or even be dropped altogether between the initial announcement and availability in products such as Windows and Visual Studio.

WSE 2.0 Previews Changes to Come

Some of the new Web services technology has been recently made available in Microsoft's Web Services Enhancements (WSE) Technology Preview 2.0, a toolkit for advanced developers looking to get early access to important Web services protocols. WSE 2.0 supports several key Web services protocols, including the following:

WS-Security provides message encryption and defines how security tokens (such as X.509 certificates and Kerberos tickets) should be encoded and attached to SOAP messages.

WS-Trust allows developers to create Web services that issue security tokens, thereby allowing organizations to establish trust relationships with business partners and avoid the difficulties of maintaining credential information for employees of the partner company.

WS-Policy allows a Web service to describe its service requirements and capabilities. For example, a Web service using WS-Policy can inform clients that it requires messages to be encrypted.

Not only does WSE 2.0 support new Web services protocols, it can now be used from within stand-alone executables and Windows services, in addition to ASP.NET applications.

Finally, WSE 2.0 introduces a new programming model which is different from that used in the initial release of Visual Studio .NET and the .NET Framework, but which is better suited for developing Web services that use the emerging WSA specifications. (For details on this new programming model, see the sidebar "WSE 2.0 Highlights New Programming Model".)

Customers considering WSE should be aware that although Microsoft offers support through Product Support Services, each release is supported for only three years. In addition, the company makes no guarantees regarding version-to-version compatibility (indeed, WSE 2.0 includes several incompatible changes from the previous version). Microsoft takes this position regarding compatibility for several reasons:

• Many of the protocols implemented by WSE are not yet complete and are still undergoing development
• Microsoft wants to use WSE to get feedback from developers before committing to a final API in Visual Studio and its server products.

Measuring Progress

Although the progress made by Microsoft and its partners is considerable, much work remains to be done before the vast majority of IT planners can begin to take advantage of the improvements being made to Web services. First and foremost, the protocols and specifications being developed must find their way into commercial products that customers can purchase and deploy, and those products must demonstrate a high level of interoperability.

The joint IBM-Microsoft demonstration showed that it is possible for a sophisticated set of Web services to successfully interoperate across Windows and Linux, but the demonstration was more a proof-of-concept than a product demonstration. No commercial products are yet capable of performing the functions shown, and many of the protocols used have not been finalized or adopted by standards bodies.

The ultimate proof that Web services have reached their potential will be when the same demonstration can be done using off-the-shelf versions of BEA’s WebLogic, IBM’s WebSphere, and Microsoft’s Windows and BizTalk Server.

Resources

Microsoft’s Web Services Developer Center is at msdn.microsoft.com/webservices.

A joint IBM-Microsoft white paper titled "Secure, Reliable, Transacted Web Services: Architecture and Composition" outlines the major pieces of WSA and can be found at msdn.microsoft.com/library/en-us/dnwebsrv/html/wsoverview.asp.

A list of upcoming Web services workshops can be found at msdn.microsoft.com/webservices/community/workshops/default.aspx.

Details of specific WSA specifications are now available. The WS-Coordination specification is at msdn.microsoft.com/ws/2003/09/wscoor. The WS-AtomicTransaction specification is at msdn.microsoft.com/ws/2003/09/wsat. The specification for WS-ReliableMessaging is at msdn.microsoft.com/ws/2003/03/ws-reliablemessaging.