Mike Edwards wrote:
Simon,
Yes, you've hit one of the parts of the Java spec that makes me least
comfortable.
The idea of sending around a reference for others to use is not
something that fills me with joy, when that reference is essentially a
reference to an instance. I feel the religious debates about
WS-Addressing coming on....
Once instances can disappear in a puff of smoke, this whole area of
function gets to be very uncomfortable. Furthermore, if you did the
passing around in the case of a callback service, who does the provider
get to talk with???
I think the callback endpoint should be part of the service reference
that is passed around. We have to support the capability to do this
for the case where setCallback() was called on the service reference,
passing a callback object that is a service reference. The receiver
of the reference may not support the callback interface itself, so
it wouldn't work in general to say that the callback target is the
receiver of the service reference.
If we do this, it would be good to allow the receiver of the service
reference to redirect callbacks to itself if it has the capability
to support them. It seems that setCallback() could be used for this
purpose, but there is a slight difficulty in how to create the
service reference that would be passed to setCallback(). It could
be a self-reference that was created by
ComponentContext.createSelfReference(myCallbackInterface)
where myCallbackInterface is the callback interface of a reference
of the component, but it's not clear that this will work given that
the callback is not a real service.
A similar issue applies to all uses of
ServiceReference.setCallback(aServiceReference)
even when service references are not being passed around. Does
aServiceReference represent a regular service (non-callback) that
supports the callback interface, or does it represent a callback
pseudo-service that was created "under the covers" for a reference
with a callback interface, or can it be either of these? The concept
of a callback pseudo-service is currently something in the Tuscany
implementation and not in the spec, but it seems that the spec needs
to clarify whether or not a callback reference can be used to create
a service reference for use in this way. And if this can be done, is
this service reference usable for regular calls or only for callbacks?
Simon
Simon Laws wrote:
Yes, I think so. From a specification point of view I was worrying about
the expected timescale of resource removal. Your assertion that it means
that the conversation cannot be reused clarifies this point.
I'm not sure I agree with the MAY in the sentence "depending on the
implementation of the comms mechanism between client and provider that
MAY
require some
additional communication to travel from the client side to the provider
side.". I can't square this away easily with the requirement of section
1.6.3 of the Java Annotations and API spec to allow for the passing of
conversational services as parameters where, if I understand it
correctly,
a third party could be holding a reference to a conversation for which
the
original client now calls Conversation.end(). Here a timeout is not good
enough and the service should be aware that the conversation has ended.
I suppose the MAY clause can be seen as being associated with whether
any references have been copied or not. If not, there are no worries.
At least the sending of a reference can in principle be detected since
it can't be used unless instantiated by some (SCA) runtime.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
