Happy New Year to you as well! This is a very interesting use case. I could give you an answer based on the current Tuscany implementation, or I could give you an answer based on what the spec guarantees. I'll do the latter as this is the best way to ensure that the code you write will continue to work on future releases of Tuscany.
The guaranteed approach would be to have a second client for the same service and have both clients force the same globally unique conversationID to be used when invoking the service. If the service is defined as having a callback, there's no way to avoid passing in a callback reference from the second client's invocation. However, the service can save away the original callback reference when it is first invoked by the original client, and can then use this callback reference to make the callback when it is invoked the second time (ignoring the callback reference passed with the second invocation). Here's the entire sequence of steps: 1) Conversational client calls a SCA Service Operation, specifying an explicit application-generated globally unique conversationID. This invocation will also pass an implicit callback reference to the original client. 2) SCA Service gets its callback reference (from the RequestContext) and saves it in its conversational state. The @Callback injection annotation should not be used. 3) SCA Service then makes a non-blocking call to the non-SCA operation, passing out the unique conversationID. This can be obtained via RequestContext.getServiceReference().getConversation().getConversationID() 4) non-SCA operation does its processing, then invokes a second SCA client passing the unique conversationID. 5) This second SCA client invokes the same SCA Service as in step 1, specifying the unique conversationID so that the same service component instance is used as in step 2. This invocation will also pass an implicit callback reference to the second client that is not useful and should be ignored by the SCA Service. 6) The SCA Service retrieves the callback reference that was saved in its conversational state in step 2, and uses this callback reference to return the updates to the original conversational client. Some notes on the above: a. Currently this would work in Tuscany even if step 5 invoked a different SCA Service in the same SCA Component. However, I can't find words in the spec that guarantee this. b. Currently this would work in Tuscany even if step 1 used a system- generated conversationID. However, I can't find words in the spec that guarantee this. Simon Dave Sowerby wrote:
Hi All, Seasons Greetings :) I've got a conversational service and it's client and it's all working great. However I'd like to extend this service to make a call to a non-SCA asynchronous application and I'm not sure as to how I should make the call back from the non-SCA application back into the SCA "world". Just to make sure this is all clear, the flow I'd like to achieve is: 1) Conversational client calls a SCA Service Operation. 2) SCA Service then makes a non-blocking call to the non-SCA operation. 3) non-SCA operation processes and notifies the originating Service conversation-instance of updates. 4) Any updates are returned to the original conversational client. Obviously the problem here is calling back into the originating conversation-instance from the non-sca application. Looking through the various specifications from osoa I can't see any suggested solutions to this, though I'm trying to ascertain if any of the following would work: o invoke a second client (such as a Servlet) and force the conversationID with no callback reference (to maintain the original client callback reference). o implement a second service through one component without callback and once again force the conversationID to hopefully find the originating service conversation-instance. Are either of these recommended solutions, or is there a more appropriate means of doing this? I'd like to find a solution that would continue to work between Tuscany releases. Any help would be greatly appreciated. Cheers, Dave.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
