Mailing-List: contact tuscany-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tuscany-dev@ws.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <477B917B.3030406@hursley.ibm.com>
Date: Wed, 02 Jan 2008 13:28:27 +0000
From: Simon Nash <nash@hursley.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: tuscany-dev@ws.apache.org
Subject: Re: Conversation from a non-SCA application
References: <baf02b8e0712310543l507f63c3u8685084361451802@mail.gmail.com>
In-Reply-To: <baf02b8e0712310543l507f63c3u8685084361451802@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org