SOA Governance and API Management : Administering Mediator : Introduction : WS-Addressing Processing in Mediator
WS-Addressing Processing in Mediator
 
Implementation of WS-Addressing in CentraSite
WS-Addressing Scenarios for Mediator
Implementation of WS-Addressing in Mediator
Mediator passes WS-Addressing from the client to the native service without changes. Using Mediator, clients can send WS-Addressing information to native services, as described in this section.
What is WS-Addressing?
WS-Addressing or Web Services Addressing is a specification of transport-neutral mechanisms that allow Web services to communicate addressing information. It essentially consists of two parts: Message References and Message Information Headers.
*Message References
An Endpoint Reference (EPR) is an XML structure encapsulating information useful for addressing a message to a Web service. It includes the destination address of the message, any additional parameters (called reference parameters) necessary to route the message to the destination, and optional metadata (such as WSDL or WS-Policy) about the service.
*Message Information Headers
Message Information Headers communicate addressing information relating to the delivery of a message to a Web service. The following properties are used in the message headers:
*Message destination URI (To)
This URL is the same as the HTTP request's URL, but it is not required to be. Sample To header:
<wsa:To> http://host/Service1</wsa:To>
*Source endpoint (From)
This is the endpoint of the service that dispatched this message (EPR). From is an EPR of the message's sender. If the message's receiver needs to send a message back to the endpoint that sent the message, then it must use this EPR. It may be an Acknowledgement that needs to be sent back to the sender. Sample From header:
<wsa:From>
<wsa:Address> http://client/myClient</wsa:Address>
</wsa:From>
*Reply endpoint (ReplyTo)
This is the endpoint to which reply messages must be dispatched (EPR) any response from the Web service must be sent to the ReplyTo EPR. Because From and ReplyTo can be two distinct EPRs, the message's sender might not be the endpoint that is meant to receive the response. Sample ReplyTo header:
<wsa:ReplyTo>
<wsa:Address> http://client/myReceiver</wsa:Address>
</wsa:ReplyTo>
*Fault endpoint (FaultTo)
This is the endpoint to which fault messages must be dispatched (EPR). If the response to a message is a SOAP fault, the fault must be sent to the EPR in the FaultTo header. Sample FaultTo header:
<wsa:FaultTo>
<wsa:Address>http://client/FaultCatcher</wsa:Address>
</wsa:FaultTo>
*Action
This is an action value indicating the semantics of the message URI (may assist with routing the message). Sample Action header:
<wsa:Action> http://host/Operation1</wsa:Action>
*Unique message ID URI (MessageID)
The MessageID header is nothing more than a URI that uniquely identifies a message. Sample MessageID header:
<wsa:MessageID>uuid:098765</wsa:MessageID>
*Relationship to previous messages (a pair of URIs) (RelatesTo)
RelatesTo will typically be used on response messages to indicate that it is related to a previously known message and to define that relationship. The following sample RelatesTo header indicates that this is a Response message for a previously known Request message whose MessageID was uuid:098765. This header is critical in an asynchronous messaging scenario because the response message's receiver must be able to associate it with the original request message. Sample RelatesTo header:
<wsa:RelatesTo RelationshipType="wsa:Response">uuid:098765</wsa:RelatesTo>
Copyright © 2015- 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback