See inline.
Simon
Raymond Feng wrote:
Hi,
There are a set of states associated with
CallableReference/ServiceReference such as the callbackID,
conversationID and callbackObject. We need to flow them in the Message
so that the target service can have the correct correlations. At this
moment, we have some of fields on the Message and I thought maybe it's
better to follow the CallableReference as a whole. Another reason is
that the RequestContext has a few methods to retrieve the
ServiceReference, CallbackReference and Callback object.
This works on the reference binding side for marshalling onto the wire
but not on the service binding side for unmarshalling from the wire
into the Message. See point 5 of my comments in TUSCANY-1591.
I agree with your comments that it's not very nice to have
CallableReference directly on the Message as accessors. Moving forward,
we probably need to define headers for the Message interface so that we
can flow extra context data without poluting the Message interface.
>
Its makes sense to put everything that is Java-specific (currently
callback ID, conversation ID, conversation sequence and callbackObject)
into a separate header. It would also be good to separate out the
processing of these things from the core invocation framework into
Java-specific interceptors.
There are already some use cases such as:
* Pass some information from one interceptor to another one, for
example, the DataBindingInterceptor can tell the PassByValueInvoker to
skip the copy.
* Carry binding-specific context in the Message, for example, SOAP
headers for binding.ws or JMS properties for binding.jms.
Thanks,
Raymond
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, September 03, 2007 7:03 PM
Subject: What is Message.set/getCallableReference used for?
Could somebody help me understand what
Message.set/getCallableReference is used for?
If I comment it then some callback test cases start to fail, but I
don't really understand why we need to store a CallableReference in
the message, and its relationship with the from and to
EndpointReferences, which can already host callback endpoints.
Also CallableReference is specific to Java (if I understand correctly
it takes a Java business interface) so if it's really used and needed
I'm not sure about how it's used for callbacks typed by WSDL or other
interface definition languages.
There are a number of implementation classes for Java-specific APIs
that6 are currently in core/context:
CallableReferenceImpl
ComponentContextImpl
ConversationImpl
RequestContextImpl
ServiceReferenceImpl
Having these classes in core causes problems when trying to fully
implement their spec semantics, because some of these semantics need
Java-specific code. The example that I am struggling with at the
moment is ServiceReferenceImpl.setCallback() which can take either
an instance of a Java implementation class or a service reference.
If the former is passed, ServiceReferenceImpl should check to make
sure it implements the callback interface and is Serializable (see
section 1.6.7.5 of the Java Annotations and APIs spec). This is not
possible without using Java-specific code, but I don't want to make
the core module dependent on the implementation-java-runtime module.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]