By Greg DeMichillie [bio]
Posted: Sep. 23, 2002

• Sidebar: Prerelease Toolkit Supports Security, Attachments
• Illustration: Global XML Web Services Architecture
• Sidebar: WS-Transaction Specification Released

Microsoft’s Global XML Web Services Architecture (GXA) has debuted in a new SDK the company has made available to developers. GXA is a set of technologies that aims to make Web services appropriate for application integration across platforms and over the Internet. GXA is in its formative stages; there is no definitive list of what problems it will address, and it's not clear whether Microsoft and IBM (the other major Web services player) will agree on how to solve those problems. Nevertheless, software developers whose products must interoperate with Microsoft’s and companies who design IT solutions that depend on Microsoft's platform will want to track GXA developments closely.

Microsoft's first cut at GXA is available in a new prerelease toolkit, the Web Services Development Kit (WSDK). For more information on the WSDK, see the sidebar "Prerelease Toolkit Supports Security, Attachments".

Origins and Goals of GXA

GXA is intended to enable Web services to integrate applications that cross organizational boundaries and involve different operating systems and infrastructures. A Web service is a piece of application logic (such as an inventory tracking system) that is accessible using standard Internet protocols (such as Simple Object Access Protocol [SOAP] and Hypertext Transfer Protocol [HTTP]).

When organizations use Web services for their internal applications, they are able to take advantage of their existing (and consistent) set of infrastructure components, such as transaction monitors or message queues. But in order to be used successfully between organizations with different platforms, operating systems, and developer tools, Web services must re-address many of these same issues and reinvent some well-known and well-understood technologies but do so in a way that guarantees interoperability between systems and organizations. GXA is Microsoft's prescription for what problems must be solved, and how to solve them. For more information on Web services, see "Vendors Face Web Services Gap" on page 11 of the Apr. 2002 Update, and the July 2001 Research Report, "Understanding .NET."

The origins of GXA can be traced to a paper jointly developed by IBM and Microsoft and submitted to an Apr. 2001 World Wide Web Consortium (W3C) workshop on Web services. The paper, entitled "Web Services Framework," defined specific functions that must be addressed if Web services are to support application-to-application integration between organizations with different management, infrastructure, and trust domains. Some of the building blocks identified by the paper include the following:

• Security—the ability to make certain guarantees about the origin and contents 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 and define the flow of data between multiple Web services
• Reliable messaging—the ability to guarantee that a message is actually received by its intended recipient
• Routing and referral—the ability to specify the route for a message
• Attachments—the ability to include binary data (in addition to text) in a message.

Many of these building blocks will sound familiar to corporate IT managers—they are the same problems faced by managers trying to build reliable and secure internal applications for the past 20 years.

Since the original paper was published, Microsoft has been developing protocols to address many of the functional areas for Web services, sometimes working with partners such as IBM, BEA, and others and sometimes working independently. According to Senior Vice President Eric Rudder, GXA is "Microsoft’s brand name for an implementation" of these protocols and specifications.

Security, Transactions Lead Architectural Components

The protocols and specifications that make up GXA all build upon the common foundation of Web services technologies, such as SOAP and the Web Services Description Language (WSDL). For a visual illustration of this architecture, see "Global XML Web Services Architecture".

Security

Security is crucial to any broad commercial adoption of Web services. Almost all applications require some aspect of security, including the following:

• Encryption—preventing messages from being read by unauthorized parties
• Authentication—ensuring that the identify of a message’s sender can be verified
• Digital signature—ensuring that a message has not been tampered with from that time it is sent until it is received.

WS-Security is a specification, jointly developed by Microsoft, IBM, and VeriSign, that describes how these key security concepts can be implemented in Web services and is available in the prerelease WSDK.

WS-Security describes how security tokens (such as authentication credentials and information on a sender’s group memberships) are associated with a message. Although WS-Security does not require any specific type of token, it does describe how to encode two common types of security credentials: X.509 certificates (the type of digital certificates used for digital signatures and encryption by public certificate authorities such as VeriSign) and Kerberos tickets (used in Windows and many other operating systems for authentication).

In addition to attaching credentials, users of Web services need a way to encrypt the contents of a message and to digitally sign the message to ensure against tampering. These functions are described by two W3C specifications: XML-Encrypt and XML-Signature, respectively. WS-Security describes how to apply these functions to encrypt and digitally sign SOAP messages.

Transactions

Transactions are a key requirement for almost all line-of-business applications. In order to process a customer order, for example, a retail organization might use several Web services, each of which needs to update a database: a credit authorization provided by a bank (which reduces the customer’s available credit), an internal inventory component (which reduces the quantify item that is in stock), and perhaps an outsourced fulfillment component (which records that the item needs to be shipped). Each of these updates must be coordinated to ensure that the application functions properly.

A transaction is a method of coordinating a set of database changes to ensure the integrity and consistency of the underlying data. Using the previous example, if the credit authorization fails, the retail operation does not want to ship the item; if the item is not available in stock, the customer does not want to be charged.

WS-Transaction is a specification, jointly developed by Microsoft, IBM, and BEA, that describes how Web services work together to perform transactions, although no implementation has yet been made available. For more information on WS-Transaction, see the sidebar "WS-Transaction Specification Released".

Coordination

Coordination languages allow developers to describe complex processes that involve coordinating between multiple Web services and defining the flow of data between them. Microsoft and IBM each defined their own language for coordination: XLANG and Web Services Flow Language (WSFL), respectively. Microsoft’s own BizTalk server, for example, uses XLANG to facilitate business-to-business e-commerce and manage end-to-end interactions associated with receiving, validating, transforming, processing, and transmitting business data between applications. (For more information on BizTalk and XLANG, see "BizTalk Server 2000 Orchestrates Business Interaction" on page 3 of the Mar. 2001 Update.) The two companies, along with BEA, have developed a unified specification with the mellifluous-sounding name of Business Process Execution Language for Web Services (BPEL4WS).

While Microsoft and IBM both support BPEL4WS, it is not yet supported in any products and other vendors are taking different approaches. Sun Microsystems, in partnership with SAP, developed the Web Services Choreography Interface (WSCI), and Oracle has asked the W3C to step in to develop standards.

Reliable Messaging

Many application scenarios require some guarantees that a message will be delivered, even if one party in the communication is temporarily unavailable. A shopping application, for example, must be able to guarantee that a shipping request is eventually received by the warehouse even if the warehouse application is temporarily offline.

Most corporate IT planners already use queuing products such as Microsoft Message Queuing (MSMQ) or IBM’s MQ Series to implement these capabilities in their internal applications. But these products do not interoperate across platforms or through firewalls (without specialized gateways), are not standardized, and are not transport independent.

While both IBM and Microsoft recognize the need to address reliable messaging, no specifications have been released yet. However, Microsoft has implemented its own concept, the SOAP Reliable Message protocol, in the latest release of MSMQ. (For further details, see "COM+, MSMQ Boost Windows as Application Server" in the Oct. 2002 Update.)

Routing and Referral

The concept of routing refers to how a message is sent from one party to another, possibly through one or more intermediaries. For example, a Web services message from one financial institution to another might be required to go through an intermediary that logs the information in order to comply with a government regulation.

WS-Routing is a specification developed by Microsoft that describes how a message can specify what route is taken. WS-Referral builds on WS-Routing and defines a way for servers to dynamically discover which intermediaries are present and which routes are available between them. This would allow (for example) a new server hosting Web services to locate the proxy server an organization uses to control Web services traffic that crosses its firewall. WS-Referral might also be used to enable Web services routers to perform load balancing by switching among servers, depending on which ones have recently sent the router a referral indicating that they are available.

Both WS-Routing and WS-Referral are supported in the WSDK.

Binary Attachments

Web services, because they are based on SOAP and XML, are fundamentally text-based technologies. While most of the data that users might want to send (such as customer names, addresses, order information) are easily represented as text, some information (such as audio and video) is normally represented as binary information and must be translated to a text format (via a process known as Base64 encoding) before being sent via SOAP and then translated back to binary format on the receiving end. This transformation increases the processing time for the sender and the receiver as well as increasing the size of the SOAP message itself.

If binary data could be attached to the SOAP message, the additional processing could be avoided and the message size could be significantly reduced. A media company or library, for example, might choose to make its stock of photographs available to subscribers via Web services and would want to be able to transmit those photographs as quickly and efficiently as possible. Microsoft has developed Direct Internet Message Encapsulation (DIME) and WS-Attachments, a set of specifications that describes how to encapsulate binary data into a message and how to attach those binary messages to a SOAP message, respectively, and some demonstrations by Microsoft have shown DIME and WS-Attachments to more than double the number of images per second that can be transmitted via Web services.

Although both WS-Attachments and DIME are supported in the WSDK and have been submitted to the Internet Engineering Task Force (IETF) for possible standardization, they were developed by Microsoft alone. Other organizations, such as IBM and OASIS, have not joined in supporting WS-Attachments and DIME and are pursuing alternate approaches.

What's Coming, What to Watch For

For the moment, GXA remains more of an idea rather than a reality that companies can build systems on. To get to reality, Microsoft and its partners will have to complete the specifications, get them adopted by standards bodies, and incorporate them into products. Microsoft’s ability to get other vendors to support these protocols (most notably IBM) will ultimately determine whether that succeeds or fails.

From Ideas to Code

While the GXA specifications are likely to be of interest to third-party developers, most corporate developers will become interested once the protocols are implemented in actual Microsoft server products and tools. Implementation will come in several stages. Here's what to watch for over the next 12 to 18 months.

Development of draft specifications. Microsoft (along with its partners in case of jointly developed specifications) plans to develop draft specifications of all the major GXA pieces and make them available for comment on its Web site. These preliminary specifications are aimed primarily at other software vendors who want to build products that interoperate with Microsoft’s products rather than at corporate IT managers. Such software vendors need to examine these specifications at an early stage in order to plan future releases of their products while corporate IT planners need only be aware that a specification is being developed and will typically be more interested once the specification is implemented in commercial products.

Submissions to standards body. Once a draft specification is released, it is expected to be submitted to a standards body. The developers of each specification (usually Microsoft and one or more of its partners, such as IBM) decide on a case-by-case basis where to submit each specification. Some are being handled by the Organization for the Advancement of Structured Information Systems (OASIS)—an organization of software vendors, consultants, and IT organizations originally formed to promote Standard Generalized Markup Language (SGML) interoperability but now focused on XML—while others are being submitted to the W3C.

Prerelease toolkit. Microsoft usually releases prerelease developer toolkits for emerging technologies (such as Web services) long before these technologies are fully integrated into the company’s operating system, server, or developer products. It does so for several reasons:

• To get its technology to market more quickly than if it were to wait until the full Visual Studio tools could be upgraded
• To allow leading-edge developers (some would say "bleeding-edge") to begin to use Microsoft technologies and to establish itself as a leader in the minds of this community.

While these toolkits do allow developers to get an early look at important technologies, they have serious limitations that make them unsuitable for application deployment: they are usually provided as-is with no customer support; they typically have little or no integration with Microsoft’s rapid-application-development tools, such as Visual Basic; and the APIs they offer are likely to be modified between the prerelease toolkit and their incorporation into Microsoft’s full product line.

Availability in products and tools. The final stage is when a technology is incorporated directly into Microsoft’s product line. For Web services technologies, such as GXA, this means support for protocols directly from Visual Studio (Microsoft’s flagship developer product) as well as from the company’s server products, such as SQL Server, Internet Information Server (IIS), and Windows .NET Server itself. In any case, full support for the GXA protocols is unlikely to happen before the next major release of Visual Studio (code-named Whidbey), which is not expected until late 2003. For more information on future releases of Visual Studio, see "Visual Studio Roadmap" in the Oct. 2002 Update.

IBM Relationship Key to Success

In order for Web services to be successful, the problems identified in the original W3C paper must be addressed in a way that enables Web services running on different operating systems and application servers to interoperate. That will require the two largest and most vocal proponents of Web services—Microsoft and IBM—to work together to establish the necessary industry standards. In some areas, this level of cooperation is already visible. The WS-Security and WS-Transaction specifications, for example, were jointly developed by Microsoft and IBM (along with others). In other areas, such as reliable messaging and binary attachments, cooperation has been lacking and the two companies appear to be moving in different directions. If Web services standards degenerate into the kind of industry bickering that plagued some previous distributed technologies (such as the fighting between COM and CORBA proponents), then true interoperability will be difficult to achieve and Web services will fail to live up to the promise that both Microsoft and IBM have envisioned.

Resources

The original IBM and Microsoft paper submitted to the W3C is available at www.w3.org/2001/03/WSWS-popa/paper51.

The Web Services Development Kit (WSDK) which supports WS-Security, WS-Routing, and WS-Attachments can be downloaded from msdn.microsoft.com/webservices/building/wsdk/default.asp.

Links to all the available GXA specifications can be found at msdn.microsoft.com/library/en-us/dnglobspec/html/wsspecsover.asp.

The Web Services Interoperability Organization’s (WS-I) Web site is at www.ws-i.org.