Simon Nash wrote:
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]
We're getting close to our 1.0 release and I think it's time to clean up
some of the SPIs, remove what's not really indispensable, and try to
avoid inconsistencies in last minute improvements and bug fixes.
I've reviewed some of this code and here's what I think needs to happen:
- Implementations of the org.osoa.sca Java API should move out of core
to the implementation-java-runtime module, as suggested - if I
understood correctly - by Simon as well
- Message.callableReference should be removed, as it's carrying
duplicate info
- EndpointReference should reference parameters, similar to the "evil"
WS-addressing, but simpler and more light weight, with just 3 fields:
- callbackID
- conversationID
- callbackObject
3 fields will be better than a big Map here as I'd hate to see a new Map
created for each invocation :)
- Message.correlationID should be removed as its semantics is not clear
and it won't be necessary anymore if callbackID gets carried in the
endpoint reference
- A new Message.replyTo endpoint reference field should be added as the
"replyTo" endpoint can be different from the "from" endpoint and
callback information should be carried in that new replyTo endpoint
reference.
Hopefully this won't generate long debates. If there's too many
questions or if what I'm proposing here is not clear, I'll post some
code implementing this. It'll be more concrete this way.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
