webMethods and Intelligent Business Operations 10.2 | Administering Mediator | Mediator | WS-Addressing Processing in Mediator
 
WS-Addressing Processing in Mediator
 
Implementation of WS-Addressing in CentraSite
WS-Addressing for Mediator
Implementation of WS-Addressing in Mediator
Mediator supports passing of the Web Services Addressing (WS-Addressing) from the client to the native service without any modifications.
WS-Addressing is a specification of transport-neutral mechanism 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 related 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 can be the same as the HTTP request's URL.
An example of To header is:
<wsa:To> http://host/Service1</wsa:To>
*Source endpoint (From)
This is the endpoint of the service that sent 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.
An example of From header is:
<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.
An example of ReplyTo header is:
<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. An example of FaultTo header is:
<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).
An example of Action header is:
<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.
An example of MessageID header is:
<wsa:MessageID>uuid:098765</wsa:MessageID>
*Relationship to previous messages (a pair of URIs) (RelatesTo)
RelatesTo is 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.
An example of RelatesTo header is:
<wsa:RelatesTo RelationshipType="wsa:Response">uuid:098765</wsa:RelatesTo>

Copyright © 2015- 2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release