The initial approach at performing async callbacks over axis2 was to use an 
axis2 operation client with a callback object on the client side and an async 
in-out receiver on the server side. This would then not require the client to 
set up a listener to get its callbacks. In effect this represents a first 
increment where we support the async SCA callback invocation patter over a sync 
ws mep. Other increments can come later, including using a full bi-directional 
mep that requires setting up the client as a web service as well.
However, in retrospect, this approach has a couple of limitations.
In particular:
1- There would need to be an association between request operation and callback 
operation. Otherwise, an indication of what callback operation is being invoked 
would need to flow with the message. This would require either a non-interop 
element in the message, or for the client to receive its callback as a separate 
invocation.
2- A scdl bi-directional interface does not have a direct mapping in plain 
wsdl. We could use the partnerLink bpel extension for wsdl, but that would 
probably assume one-way operations on port types.

To handle these limitations, the current approach assumes (as proposed in an 
earlier note) that the callback interface has a single method. In addition, the 
wsdl in use needs to define the forward method as in-out and a separate port 
type to specify the callback interface.

At the moment there are some problems getting the component on the server side 
to get invoked. If and when that gets resolved, we'll need to decide whether 
the current approach is something we are ok with including in the release.

Reply via email to