I imagine CXF's WS-A layer would not have the ability to accommodate
the situation where an operation exposed by a service provider is
associated with one portType, and the corresponding callback operation
is associated with a different portType? Can someone confirm?
I'm interested to know because the implementation of asynchronous
calls in ws-bpel seems to require this, in that the relationship of
the BPEL process with an asynchronous service provider is modeled as a
partner link with the role of each party associated with a distinct
portType. For example:
...
xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype";
...
<plnk:partnerLinkType name="AsyncOperationPartnerLinkType">
<plnk:role name="serviceProvider" portType="tns:ServicePortType">
</plnk:role>
<plnk:role name="serviceConsumer" portType="tns:CallbackPortType">
</plnk:role>
</plnk:partnerLinkType>
Regards,
Callum.
On Wed, Aug 20, 2008 at 7:48 PM, Eoghan Glynn <[EMAIL PROTECTED]> wrote:
> Jacques Talbot wrote:
>>>
>>> "Eoghan Glynn-2" wrote
>>>>
>>>> Adrian Corcoran wrote:
>>>> Does CXF offer support option #2? via wsa for all supported transport?
>>>
>>> Its supported for HTTP.
>>
>> So, to make the link with another thread: is my understanding below
>> correct?
>>
>> contrarily to axis2 where you have to specify a wireasync boolean to
>> convince the toolkit to implement option #2, CXF infers from the fact that
>> WSA:ReplyTo is non anonymous that the
>> programmer actually wants asynchronous-on-the wire and behaves
>> accordingly, namely routing the http 202 ACK synchronously and the Reply-To
>> SOAP message
>> asynchronously
>>
>> Correct? If yes, this is smarter!
>
>
> Yes, the CXF server-side WS-A layer will automatically react to an imcoming
> non-anonymous replyTo by responding with a 202 before continueing on the
> dispatch path. The reply, when eventually ready, is then asynchronously on a
> separate server->client connection.
>
> On the client-side, if you want CXF to set up the decoupled response
> endpoint, then some configuration is required ... e.g. the following config
> fragment sets the client-side HTTP transport up to listen for incoming async
> responses on localhost:9990/decoupled:
>
> <http:conduit name="{http://tempuri.org}MyPort.http-conduit";>
> <http:client DecoupledEndpoint="http://localhost:9990/decoupled"/>
> </http:conduit>
>
> Cheers,
> Eoghan
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
