Web Services Security and More: The Global XML Web Services Architecture (GXA), Page 4
Referral Statements: WS-Referral
The WS-Referral specification defines the mechanisms by which the message paths specified in WS-Routing can be dynamically discovered. More specifically, it defines mechanisms by which a Web service can insert, delete, and query routing entries in a SOAP router. The WS-Referral specification was released in October 2001 by Microsoft.
The basic unit of WS-Referral is a referral statement, which is an XML-based structure for describing a routing entry along with a set of conditions under which the statement is satisfied. A referral statement contains five parts—among them are:
- A set of SOAP actors for which a statement is intended
- A set of conditions that have to be met for a statement to be satisfied
- A set of SOAP routers that a statement is referring to as part of the delegation
WS-Referral defines a referral statement using a "for-if-go" grammar; that is, "for" the following set of actors, "if" the following conditions are satisfied, then "go" to these SOAP routers.
XML Example: Referral Statement
An example of a referral statement is as follows:
<r:ref> <r:for> <r:prefix>soap://a.org</r:prefix> </r:for> <r:i> <r:ttl>43200000</r:ttl> </r:if> <r:go> <r:via>soap://b.org</r:via> </r:go> <r:refId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</r:refId> </r:ref>
In the above example, the <r:prefix> element means that any SOAP node beginning with the contained URI is considered to be a match for the referral. The <r:ttl> element denotes "time to live"—that is, it sets a "time to live" limit on the availability of a referral. The value of this element above (43200000) is the number of milliseconds, which equates to 12 hours. Therefore, the entire statement would be read as follows: "for all SOAP nodes that begin with the URI soap://a.org, if this referral is less than 12 hours old, then go to soap://b.org".
This referral could be used on future messages to include a <r:fwd> element in the SOAP header (as described in the WS-Routing specification), such as the following:
<wsrp:fwd> <wsrp:via>soap://b.org</wsrp:via> </wsrp:fwd>
A SOAP router can explicitly request one or more WS-Referral statements from another SOAP router by sending it a WS-Referral query. This may be done to request new information, or perhaps update inadequate routing information in order to reach a given SOAP router in a message path.
XML Example: WS-Referral Query
The following is an example of a WS-Referral query that requests referral information for all SOAP nodes that begin with the URI soap://a.org:
<r:query> <r:for> <r:prefix>soap://a.org</r:prefix> </r:for> </r:query>
A referral statement would then be sent in the response.
The WS-Referral specification can be found at http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-referral.asp.
Transactional Properties: WS-Transaction
If you've ever made a stock trade online, you know how disconcerting it could be if you're presented with an error in the middle of your trade execution. However, if the online trade is designed with transactional properties in mind (which it should be!), it will be ensured that the trade was either carried through fully, or not at all. Transactional properties of Web services are the focus of the WS-Transaction specification. The WS-Transaction specification was released in August 2002 by Microsoft, IBM, and BEA Systems.
WS-Transaction defines two coordination types that essentially characterize transactions as either "fine-grained" or "course-grained" transactions. Atomic transactions are transactions that are used to coordinate activities having a short duration and executed within limited trust domains; they are more "fine-grained" in nature. Such transactions are called "atomic" because they have an "all or nothing" property (in other words, the transaction must either be completely executed, or not executed at all, as in our stock trade scenario above). In contrast, business activities are used to coordinate activities that are long in duration and that may apply business logic to handle business exceptions; they are more "coarse-grained" in nature. Because of the long duration of business activities, data resources cannot be locked as with atomic transactions—rather, actions are applied immediately and are permanent. A Web services application can include both atomic transactions and business activities, and developers can use either or both of these coordination types when building applications that require consistent agreement on the outcome of distributed activities.
Each activity in a transaction is coordinated by a Web service that is aptly called a coordinator or coordination service. As we will see shortly, each participant in an activity registers with the coordinator of that activity through what is known as a registration service.
Each coordination type discussed above can have multiple coordination protocols, each of which is intended to coordinate a different role that a Web service plays in the activity. Each participant in an activity registers for the coordination protocol that is most appropriate for its particular role in the activity. Some examples of atomic transaction coordination protocols are:
- Completion: One participant (generally the application that created the transaction) registers for the completion protocol, so it can tell the coordinator either to try to commit the transaction or force a rollback.
- 2PC (2 Phase Commit): A participant such as a resource manager (ex: database) registers for this, so that the coordinator can manage a commit-abort decision across all the resource managers (2-phase commit).
- Phase Zero: The coordinator notifies a participant just before a 2PC protocol begins; this would allow an application that caches data (for example) to write outstanding updates to a database prior to the execution of the 2PC protocol.
In order to link the various activities participating in a transaction, messages between parties carry a coordination context. Once a coordination context is acquired by an application, it is sent by whatever appropriate means to another application.
XML Example: Coordination Context
The following is an example of a coordination context supporting a transaction service:
<S:Header> . . . <wscoor:CoordinationContext> <wsu:Identifier>http://abc.com</wsu:Identifier> <wsu:Expires>2002-08-31T13:20:00-05:00</wsu:Expires> <wscoor:CoordinationType> http://schemas.xmlsoap.org/ws/2002/08/wstx </wscoor:CoordinationType> <wscoor:RegistrationService> <wsu:Address> http://xyzregistrationservice.com </wsu:Address> </wscoor:RegistrationService> </wscoor:CoordinationContext> . . . </S:Header>
In the above example, the
The coordinator of a transaction aggregates the following services:
- Activation Service: Allows a coordination context to be created, through a CreateCoordinationContext operation.
- Registration Service: Allows a Web service to register to participate in a coordination protocol, through a Register operation.
- Coordination Protocol Services: A set of coordination protocol services for each coordination type supported by the coordinator.
The following is an abbreviated example of WS-Transaction in action—it contains only the highlights of a transaction process, and does not include some "standard" of the back-and-forth negotiation processes that take between the participants (such as acknowledgments). It will involve three applications:
- App1: A "user-facing" application; will initiate the transaction
- App2: An application that caches data
- App3: A resource manager
The process is as follows:
- App1 sends a CreateCoordinationContext message to its local activation service, to create an atomic transaction
- App1 receives from its local activation service a coordination context containing the following items (along with other information):
- A transaction identifier that uniquely identifies the transaction
- A coordinator port reference for the activity coordinator
- App1 registers with the coordinator for the Completion protocol
- App1 sends a message to App2 containing the coordination context
- Because App2 is an application that caches data, it registers with the coordinator for the Phase Zero protocol
- App2 sends a message to App3 containing the coordination context
- Because App3 is a resource manager, it registers with the coordinator for the 2PC protocol
At this point, the coordinator knows all of the transaction participants and what coordination protocols they expect to use. From this point on, the actions of each of the participating applications will be coordinated by the coordinator based on interactions between the coordinator and the various participants.
The following is a list of the remaining specifications that currently comprise GXA:
|WS-Coordination||Defines Coordination Types used in WS-Transaction||ws-coordination|
|WS-Inspection||Defines a Web Services Inspection Language for inspecting a Web site for available services||ws-inspection.asp|
|WS-Secure Conversation||Defines mechanisms for establishing security context using session keys, derived keys, and per-message keys||ws-secure-conversation/|
|DIME (Direct Internet Message Encapsulation)||Defines a binary packaging format for SOAP messages with attachments||draft-nielsen-dime-02.txt|
|WS-Attachments||Defines how DIME packaging can be used to provide the attachment capabilities needed by Web services||draft-nielsen-dime-soap-01.txt|
|WS-ReliableMessaging||Provides a protocol for guaranteeing that messages are delivered, properly ordered, and received without duplication||wsrmspecindex.asp|
|WS-Addressing||Provides transport-neutral mechanisms to address Web services and messages||ws-addressing.asp|
In this article, we have discussed the Global XML Web Services Architecture (GXA). GXA is poised to play a major role in advancing the adoption of Web services through its robust specification of mechanisms for Web services such as security, policy, coordination, federation, and routing. More specifications will be forthcoming for areas such as privacy, federation, and authorization.
About the Author
Joseph Chiusano is a Senior Consultant with Booz Allen Hamilton. His technology background includes such diverse areas as systems architecture, relational database applications design and development, operating system development, and XML consulting. Mr. Chiusano possesses in-depth knowledge in many aspects of XML and XML-related technologies, including Web services, XML schemas, digital security, XML registries, and XML vocabularies.