email article printer friendly more resources

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.