Sounds like you're talking about a pattern based on a pair of correlated
oneways, or?
CXF would treat the original invocation and the corresponding callback
as two /separate/ oneway MEPs.
Whereas the wsa:replyTo is used by CXF to route the response
corresponding to a request forming part of the /same/ twoway MEP.
Cheers,
Eoghan
Callum Haig wrote:
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
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
