Stretch Your Web Services With GXA
Global XML Web Services Architecture (GXA) uses SOAP's flexibility to provide enhanced support for message routing, transactions, and security.
by Marc Mercuri

January 2003 Issue

For this solution: XML, SOAP

XML Web services are a great mechanism for enabling single, stateless request/response operations. However, you can hit a brick wall when requirements for your Web service interactions become more complex. At that point you realize there's a void between using the out-of-the box functionality Simple Object Access Protocol (SOAP) provides and having services that can manage security and authentication, handle multipart transactions, and route your Web service requests dynamically.

Global XML Web Services Architecture (GXA) is a collection of infrastructure protocols built on top of SOAP to address these issues. GXA encompasses several specifications (see the sidebar, "Get an Overview of the GXA Specifications"). Each one focuses on resolving a particular type of functionality, such as security, routing, or transactions. The specifications are designed to be composable, meaning you can use any combination of them that's appropriate to satisfy your business requirements.

Before GXA became available, companies that employed Web services built custom mechanisms to support requirements for digital message signing, dynamic message-routing paths, or transactions. These homegrown solutions required a fair amount of time from internal resources to devise a mechanism, create it, then implement it. These models rarely made their way outside the organizations that created them, resulting in multiple incompatible implementations. GXA eliminates this resource drain. The GXA specifications were created by some of the major players in the arena, including Microsoft, BEA, and IBM.

GXA is implemented as a plug-in to SOAP messages and is built on top of the SOAP specification, so it inherits all the benefits of SOAP. It's XML-based, representing data as text encased in a descriptive, hierarchical tagging structure. GXA's platform neutrality offers additional benefits because the solutions you build are universal across operating systems and device types—Windows desktops; Windows, Unix, or Linux servers; or even PDAs. This platform neutrality also enables you to implement solutions across your enterprise that are compatible with your partners' and end customers' systems.

GXA also inherits the benefit of transport neutrality from SOAP. Although HTTP is the transport most Web services use today, it's not a requirement. Knowing this is particularly important when you introduce Web services that require dynamic routing. Traditionally, Web services have sent messages directly from the caller to the Web service and back again. GXA introduces a specification that allows dynamic routing of a message. So, instead of two points in the interaction, there might now be four. For example, your message can go from point A to point B over HTTP, from point B to point C over SMTP, then from point C to point D using HTTP again.

GXA capitalizes on SOAP's ability to include additional content in a message. The GXA specifications define schemas you reference and use directly within the message, usually in the message header.

Now I'll take you on a tour of GXA's individual specifications (see Resources). WS-Routing specifies the syntax for routing a message from a start point to an end point along a designated path. The ability to specify that the message follow a particular, ordered path involving multiple points distinguishes WS-Routing from the traditional Web services mechanism.

Specify the Message Path
You place the routing information directly within the SOAP message header. The routing information for the message lies inside the path element (see Table 1). So, for example, the message proceeds to the end point along this path: mmercuri@gaz.com -> pointB.com -> pointC.com -> www.fawcette.com.

The points between the start point and the end point are intermediaries. Intermediaries move the message forward toward its final destination. An intermediary can insert additional intermediaries into the path if appropriate. This is powerful because it enables dynamic routing of a message. The specification dictates certain rules for inserting additional intermediaries along the message path. You should add intermediaries only for administrative reasons or if the intermediary uses a value-added service. Also, you must take special care when inserting additional intermediaries to avoid an infinite routing loop.

WS-Routing also specifies the means used to specify the message's return route. To understand the concept better, examine it in the context of another set of messages you're familiar with—e-mail. John Smith sends you an e-mail at yourname@yourcorp.com, but you're on vacation, so your e-mail server forwards the message to yourname@yourhomeemail.com automatically. You're traveling, so you set your home e-mail address to forward messages to you at yourname@your2waypager.com.

John Smith, the message's originator, is concerned only that you receive his message. He doesn't care how the message is routed, and he doesn't need to know about the internal systems whose business rules tell them how to forward the message dynamically. If you reply to the message, you'll send a response to John Smith, but along a different path. Instead of routing it back through your home e-mail server, then through your corporate e-mail server, you reply directly to JohnSmith@hiscompany.com.

The e-mail scenario also helps clarify another GXA specification—WS-Referral. John Smith's message went through several e-mail servers—first the office's, then home's, then the two-way pager's e-mail server—by being sent to each server and forwarded on to the next. The time the forwarding involves might be acceptable for e-mail, but it might be unacceptable for sending an entire Web service message along that route.

Perhaps it would be better if John Smith's e-mail server could query the corporate e-mail server, and it could respond that the message should be routed directly to your two-way pager. And when your corporate e-mail server sends its response, it would be beneficial to let John Smith's e-mail server know exactly how long it should send messages to you on your two-way pager. WS-Referral defines how to do precisely this for SOAP messages. The specification outlines how to define business rules that can be used for SOAP routers and includes the syntax for SOAP routers to register with and query one another (see Table 2).

Make a Referral Statement
A referral statement is a business rule that defines where the message path for a specific Uniform Resource Identifier (URI) or a URI prefix should be referred. A referral statement is essentially an if…then statement you apply against the values in the for element. Here's an example of a referral statement:

<r:ref 
                xmlns:http://
                schemas.xmlsoap.org/
        ws/2001/10/referral>
        <r:for>

        <r:prefix>soap://
        www.fawcette.com</
                r:prefix>
        </r:for>
        <r:if/>
        <r:go>

        <r:via>soap://www.pointx.com</r:via>
        </r:go>
        <refID>mid:3161972MM@gaz.com
        </refID>
</r:ref>

The preceding statement specifies that any requests for URIs prefixed by www.fawcette.com should be referred to www.pointx.com.

You'd have performance problems if each request included a referral statement, because successful Web services will receive a significant number of requests. That's why it makes sense to cache referral statements. WS-Referral provides a means to define a time after which a referral statement is considered "stale." In the e-mail scenario, the referral to your two-way pager would be stale the day you returned from vacation. WS-Referral also provides a way to specify that a statement invalidates a previous referral statement. WS-Referral can be particularly important for situations in which your Web service requires functions such as load balancing, because it lets you detour message requests to alternative locations for processing during peak activity times.

Support for transactions is critical for many programmatic operations. WS-Transaction is a GXA specification that describes coordination types for two flavors of transactions—an Atomic Transaction (AT) and a Business Activity (BA). ATs can register several types of communication protocols, and require that the outcome be "all or nothing," which means every step in the transaction must be successful. If any step fails, all steps completed up to that point are rolled back. A transaction is labeled successful when all parties involved in the transaction agree it's successful.

A useful analogy is a transaction in which you transfer funds from your savings account to your checking account. If the server processing the transfer goes offline after the funds have been removed from the savings account and before they're deposited to the checking account—and this isn't part of an AT—your funds disappear. For this reason, funds transfers are always part of an AT. The first step of the transaction would be rolled back, and the funds would still be in your savings account. ATs tie up resources involved in the transaction, such as memory usage and database locks, because they must be able to roll back.

You use a BA to coordinate activities that are longer in duration than ATs. It's unrealistic to maintain memory usage, database locks, and so on in a BA, primarily because of the extended period of time the BA might take to complete. This is particularly true when your transactions involve partners and third parties.

All actions in a BA are applied immediately because BAs usually take longer periods of time and can take place over a number of domains. In an online purchase, for example, the transaction initiates when you begin your order and completes when you receive the product. At a minimum, your transaction involves the retailer, at least one supplier, a shipper, a credit card-authorizing company, and you (the customer). This transaction could take anywhere from one day to several weeks to complete, and doesn't warrant tying up all parties' resources throughout that period.

Business Activities Alert Participants
Rather than perform a rollback when a step fails, a BA generates a fault message the participants in the transaction can react to. In the online-purchase example, a number of faults could occur that would invalidate the transaction: The item might be out of stock at the retailer, a supplier could have discontinued a product, the purchase might exceed your credit limit, you might decide to cancel the order, or the shipper could lose the package. In any of these cases, the other parties should receive a fault message indicating that the transaction should be invalidated. The retailer would cancel the order, the credit card authorizer would refund any charges to your credit card, and so on.

WS-Security is a core GXA specification that answers two common security concerns. It ensures a message's content isn't modified en route to the server and that only messages with appropriate security credentials get processed. Prior to GXA, discussions of SOAP service security covered how to deliver your Web service over Secure Sockets Layer (SSL). SSL solves only part of the equation—it encrypts the channel between the calling application and the Web service you use for transport. This keeps the content of your requests and responses secure from the outside world, but it doesn't provide a mechanism to ensure the calling application has the proper credentials.

SSL's security is analogous to receiving a phone call from an unidentified person who asks questions you'd expect from your banker. No one else can listen to the conversation, but you provide the requested information without validating that the caller is your banker. SSL only encrypts a message so no one else can read it; it doesn't confirm the sender's identity. WS-Security provides a protocol to authenticate the sender; you place it directly within the SOAP message, ensuring it'll remain secure even when routed through several intermediaries.

My discussion of WS-Transaction used the example of moving funds from your savings account to your checking account. If the message to add the funds to your checking account isn't secured, it could be intercepted and modified to direct the funds transfer to a malicious third party's account.

You specify the security content in the message header. WS-Security uses security tokens to make claims. A claim is a statement the client makes that asserts identifying information about the client—the client name, identity, a key, a group, privileges, and so on. Immediately under the Security element is a security token in the UserName element.

In addition to a standard security token, WS-Security also supports Signed Security Tokens. An authority (for example, a Kerberos ticket or X.509 certificate) endorses a Signed Security Token cryptographically. You use a BinarySecurityToken element to place a Signed Security Token in a document. Using a signed token is preferable, but a username token might be acceptable instead if other server-based access controls are in place.

WS-Security's features are high on many Web service developers' wish lists, and Microsoft has taken note. Its recently unveiled Web Services Development Kit (WSDK) makes signing your messages with Security Tokens or Signed Security Tokens straightforward.

The GXA specifications are clear and flexible, providing protocols for the types of functionality and interactions enterprise-class Web services require. Their built-in extensibility, along with backing by industry heavyweights such as IBM and Microsoft, give them staying power. GXA warrants your close attention when you plan your company's Web services strategy.

About the Author
Marc Mercuri is the vice president of applications development for Gazelle Systems Inc. He has architected, managed, and developed projects for the CRM, financial, educational, hospitality, entertainment, medical, point of sale (POS), and publishing industries. Reach Marc at .