Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of eoghan.glynn@iona.com
 designates 12.170.54.180 as permitted sender)
Message-ID: <488F1CE3.7040500@iona.com>
Date: Tue, 29 Jul 2008 14:36:35 +0100
From: Eoghan Glynn <eoghan.glynn@iona.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: users@cxf.apache.org
CC: jaspreet@huawei.com
Subject: Re: Queries regarding WS-Addressing
References: <001201c8e70b$5d31f230$4217120a@china.huawei.com>
In-Reply-To: <001201c8e70b$5d31f230$4217120a@china.huawei.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"

harbhanu wrote:
> Hi,
>=20
> I have couple of queries related to implementation of WS-Addressing in CX=
F=2E
>=20
> =20
>=20
> 1>     How is the target service identified in CXF, with/without
> WS-Addressing?=20
>=20
> Is the value of "To" header block is always expected to be the address on
> which service is hosted=20


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

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

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

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

For HTTP, this is the Request-URI in the Request-Line. So the first line=20
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=20
implicit in the target JMS destination (i.e. the queue or topic that the=20
JMS message is sent to), in FTP its encoded in the intermediate filename=20
AFAIK.

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

This allows the logic to be consistent across the WSA-enabled and=20
WSA-disabled scenarios. It also means we can determine the dispatch path=20
*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=20
>=20
> 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=2Eg. I could publish two endpoints on "http://localhost:9000/foo/bar"=20
and "http://localhost:9000/sna/fu" respectively. HTTP requests on the=20
former would include a Request-URI of "/foo/bar", whereas the latter=20
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=20
are various rules and conventions around the naming the of the root=20
element in the <SOAP:Body> that determine the method invoked.

In the RESTful case, the method is inferred from the combination of the=20
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.
>=20
> In CXF where/how can one specify, incase response is expected on some oth=
er
> 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=20
back-channel of the incoming connection)
- any URI with the same URI scheme as the target endpoint (which gives=20
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=20
"DecoupledEndpoint" attribute of the <http:client> policy. See=20
samples/ws_addressing/client.xml for an example usage.

Cheers,
Eoghan


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