Douglas Leite wrote:
Thanks Luciano.
The SCA Java Annotation spec also says about the usage of a
RequestContext object annotated with @Context annotation. In that case I
can use the getServiceReference().getCallbackID() methods to retrieve
the ID of the Callback interface.
/@Context
protected RequestContext requestContext;
void receiveMethod() {}
/
/Object refParams = requestContext.getServiceReference().getCallbackID();
. . .
/
/}
/
This works in SCA 1.0 (Tuscany 1.x) but not in SCA 1.1 (Tuscany 2.0)
because the callback ID feature has been removed by OASIS. There was a
lot of debate in the OASIS Java TC about this and the conclusion eventually
was that the application should take care of this correlation between
request and callback messages if it needs it. It was felt that this
approach is preferable to making SCA calllbacks more complex by requiring
the SCA runtime to provide a callback ID for every bidirectional interaction.
Simon
On Tue, Jan 12, 2010 at 4:46 PM, Luciano Resende <[email protected]
<mailto:[email protected]>> wrote:
On Thu, Jan 7, 2010 at 10:37 AM, Douglas Leite <[email protected]
<mailto:[email protected]>> wrote:
> Hi,
>
> I would like to know if the Tuscany SCA framework provides
something that
> allows me to identify which oneWay method invocation a callback
operation is
> associated with.
>
> Suppose that a ClientComponent invokes consecutively an oneWay
method from a
> ServerComponent 3 times. The client method ends their execution
up before
> the arrival of the messages through callback. Then, when the callback
> messages arrive, how can I determine which of the 3 invocations
method the
> callback is associated with? Can I trust the message delivery order?
>
I believe this would depend on the @Scope of your service, below is
what the 1.1 spec says in the 7.2.2 section (Callback Instance
Management):
Instance management for callback requests received by the client of
the bidirectional service is handled in the same way as instance
management for regular service requests. If the client implementation
has STATELESS scope, the callback is dispatched using a newly
initialized instance. If the client implementation has COMPOSITE
scope, the callback is dispatched using the same shared instance that
is used to dispatch regular service requests.
As described in the section "Using Callbacks", a stateful callback can
obtain information relating to the original service request from
parameters on the callback request. Alternatively, a composite- scoped
client could store information relating to the original request as
instance data and retrieve it when the callback request is received.
These approaches could be combined by using a key passed on the
callback request (e.g., an order ID) to retrieve information that was
stored in a composite-scoped instance by the client code that made the
original request.
Also, here are some slides on this topic that might help :
http://www.slideshare.net/luckbr1975/building-asynchronous-services-with-sca
--
Luciano Resende
http://people.apache.org/~lresende
<http://people.apache.org/%7Elresende>
http://lresende.blogspot.com/
--
Douglas Siqueira Leite
Graduate student at University of Campinas (Unicamp), Brazil
