cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eoghan Glynn <>
Subject Re: Queries regarding WS-Addressing
Date Tue, 29 Jul 2008 13:36:35 GMT
harbhanu wrote:
> Hi,
> I have couple of queries related to implementation of WS-Addressing in CXF.
> 1>     How is the target service identified in CXF, with/without
> WS-Addressing? 
> Is the value of "To" header block is always expected to be the address on
> which service is hosted 

The value of the wsa:To header is set on the sender side according to 
the target address of the conduit used to send the outgoing message. The 
conduit is simply the CXF abstraction for the send-side of a transport 

Unless of course the application has over-ridden the message addressing 
properties, via the request context. See the ws_addressing sample for an 
illustration of this override.

Now on the receive side, CXF does NOT enforce that the incoming wsa:To 
must identify the service endpoint.

Instead, the service endpoint is identified via the same 
transport-specific mechanism as would be the case if WS-Addressing were 
not enabled.

For HTTP, this is the Request-URI in the Request-Line. So the first line 
of a HTTP request containing an invocation would look something like:

POST /SoapContext/SoapPort HTTP/1.1<CRLF>

"/SoapContext/SoapPort" is the Request-URI in this case.

Other transports encode this information differently, e.g. in JMS its 
implicit in the target JMS destination (i.e. the queue or topic that the 
JMS message is sent to), in FTP its encoded in the intermediate filename 

So as you see, the wsa:To header is more descriptive than prescriptive, 
whereas the actual target service is identified in a transport-specific way.

This allows the logic to be consistent across the WSA-enabled and 
WSA-disabled scenarios. It also means we can determine the dispatch path 
*before* the wsa:To header is decoded, e.g. in the server-side transport.

> OR one can have more than one service hosted on the same address and the
> disambiguation being 
> done by using value of "To" header block.

By "same address", do you mean the same host and port in the target URI?

If so, that's no problem.

The disambiguation is done via the context path part of the URI.

e.g. I could publish two endpoints on "http://localhost:9000/foo/bar" 
and "http://localhost:9000/sna/fu" respectively. HTTP requests on the 
former would include a Request-URI of "/foo/bar", whereas the latter 
would be "/sna/fu".

So there's no ambiguity and the wsa:To is not used to disambiguate.

> 2> How is method invocation decided, with/ without WS-Addressing?

Depends on the binding (SOAP, XML, fixed) etc. In the SOAP case, there 
are various rules and conventions around the naming the of the root 
element in the <SOAP:Body> that determine the method invoked.

In the RESTful case, the method is inferred from the combination of the 
HTTP verb (PUT, GET, POST, DELETE etc.) and Request-URI.

> 3> Going by the WS-Addressing the response for a request should be sent
> using the value of "ReplyTo" header block.
> In CXF where/how can one specify, incase response is expected on some other
> transport/address.

The wsa:ReplyTo must be one of the following:
- the none URI (for oneway)
- the anonymous URI (to indicate the response should be sent on the 
back-channel of the incoming connection)
- any URI with the same URI scheme as the target endpoint (which gives 
what we call a decoupled response channel in CXF).

So a different address is possible, but not a different transport.

In the HTTP case, this decoupled address is configured via the 
"DecoupledEndpoint" attribute of the <http:client> policy. See 
samples/ws_addressing/client.xml for an example usage.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

View raw message