The Global XML Web Service architecture (the Global XML Web services Architecture, hereinafter referred to as GXA) platform is a new term, including many new standards in the field of Web service interaction. Quite a few big companies are working behind the scenes of GXA, including Microsoft and IBM. The primary goal of GXA is to define the syntax and semantics of the new family of protocols for the specified Web services, which bring the basic functions of SOAP and XML to the next generation of compatibility. While much work has been done to create standards for Web services in the past few years, there is still a lot of work to be done. These work are made up of ways to enhance and professionalize Web services interactivity and interoperability. The purpose of GXA is to define the specifications for these infrastructure-related services, which form an abstract virtual machine for the next generation of Web services.
GXA characteristics
The practical experience of using Web services over the years shows that most applications implement repetitive tasks in a wide range of application areas. Issues such as security and message routing are common to many, though not all, distributed enterprise applications. Therefore, they are best addressed through specialized line-level protocols, rather than individual applications.
For example, when soap was first introduced in 1998, it was the first xml-based protocol for remote procedure calls. Anyone who uses a remote procedure call through the Web must learn how to write the original soap code. Soap is now viewed as a low-level driver that is abstracted from a class of specified platform classes, buried in the Web server infrastructure used for Web services. The example of this basic structure is Microsoft. NET platform in ASP.net and the Apache open source area of the axis. In both cases, you can create or use Web services using object-oriented mode instead of processing the original SOAP payload.
You now have to make your own Web services secure by writing code snippets that are similar in style over and over again. You will also be responsible for sending the SOAP message from the original sender to the final recipient, which may pass through a chain of links.
GXA attempts to define SOAP based protocols using generic and well understood syntax and semantics to address issues such as security, message routing, and so on. Companies involved in developing GXA extended infrastructure may one day embed the details of these protocols into some kind of virtual machine.
Extensions for building Applications
The official definition of GXA is a protocol platform that implements a SOAP extension for building web-based applications. This series of extensions includes Web Service security (ws-security), Web Service Routing (ws-routing), and enhanced support for transactional collaboration, reliable messaging, metadata, and more.
Ws-security is a set of standard SOAP extensions that can be used to implement data integrity and confidentiality in Web services. Its goal is to allow applications to securely exchange SOAP messages and to process encodings and certificates by consolidating special extensions in the SOAP schema.
Ws-routing is a stateless protocol for asynchronously routing SOAP messages using transport such as TCP and HTTP. The headers that make up these different protocols can be formed into a rich context for messages that may have attachments.
Ws-attachments (Web service attachment) and direct Internet Message Encapsulation (DIME, directly internet messaging encapsulation) are also included in GXA, and many of the specifications in GXA are continuing to be developed. Dime is a lightweight binary message format that can be used to encapsulate one or more of the application-defined payloads of any type and size into a single message construct. Each payload is described by a type, a length, and an optional identifier. Both URI and MIME media type constructs are supported as type identifiers.
Microsoft currently supports one for. NET Web service, and IBM supports the extension of the specified ws-security in the WebSphere SDK5.0 for Web services. Although the Ws-routing specification uses the concept of a mediator built in soap (intermediary), Microsoft and IBM have not yet supported ws-routing. GXA and security.
Over the past two years, Web services have continued to grow, calling for a comprehensive security model for Web services that is becoming more and more vocal, ws-security the norm, and taking the first step towards addressing this need.
Ws-security defines a standard set of Simple Object Access Protocol (SOAP) extensions or message headers that can be used to achieve integrity and confidentiality in Web service applications. Ws-security provides a standard mechanism for exchanging secure, signed messages in a Web service environment, and provides an important foundation layer for developers to build safer, more widely interoperable web services.
Organizations can integrate these new specifications into different tiers of their Web service applications as needed. Other recommended specifications include:
Ws-policy, Ws-trust, and Ws-privacy:ws-policy define how to express the functionality and limitations of security policies; Ws-trust describes the models used to establish direct and indirect trust relationships, including third parties and middlemen; ws-privacy Define how the Web service defines and enforces confidentiality measures.
Ws-secure conversation, Ws-federation, and ws-authorization:ws-secure conversation describes how to manage and verify message exchange between the parties, including security context exchange and building Stand and derive session key; Ws-federation describes how to manage and reconcile trust relationships in heterogeneous federated environments, including support for federated identities; Ws-authorization defines how the Web service manages authorization data and policies.