I'm OK with most of this, but I have some comments and concerns.
See inline.
Simon
Raymond Feng wrote:
+1 on the proposal. I'll give a try to refactor the Message code.
Thanks,
Raymond
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, September 05, 2007 5:43 PM
Subject: Re: What is Message.set/getCallableReference used for?
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: <[email protected]>
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
+1
- Message.callableReference should be removed, as it's carrying
duplicate info
+1
- EndpointReference should reference parameters, similar to the "evil"
WS-addressing, but simpler and more light weight, with just 3 fields:
- callbackID
- conversationID
- callbackObject
>>
I'm not convinced about putting callbackObject into EndpointReference.
The callbackObject can be one of the following:
1) a ServiceReference
2) a local Java instance that supports the callback interface
For case 1), the "From" or "replyTo" field (see my comments below)
on the wire would be used to pass the callbackObject's endpoint
instead of passing the client's callback service endpoint. The callback
would not be directed back to this client, so there is no reason to hold
this ServiceReference in this client's EndpointReference.
For case 2), this is not passed on the wire, but is retained by the
caller (for stateful callbacks only) to be used for callback invocations.
The caller needs to provide a means to correlate the callback object
instance with the conversation ID for the stateful callback's conversation.
I don't think the caller's EndpointReference needs to hold the
callbackObject or play any part in this.
3 fields will be better than a big Map here as I'd hate to see a new
Map created for each invocation :)
+1
- 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
+1
- 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.
I don't agree with this. The WS-Addressing replyTo field is used for
a reply to the forward message. The semantics of a reply (see section 3.2
of the WS-Addressing spec) are not the same as SCA callback semantics.
An SCA callback is a new message that is additional to the reply for
the original forward message. A WS-Addressing request/reply exchange
must observe the following requirements:
1. The request message must contain a MessageID element
2. The reply message must contain a RelatesTo element containing
the MessageId of the original request.
Neither of these is needed for callback purposes. SCA callbacks should
not be tied to the original message in this way.
The wsa:From element is well suited to carrying the SCA callback
endpoint information because it simply provides an endpoint to call and
does not impose any additional protocol requirements.
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?
You didn't mention conversationSequence. I'm not convinced that we
need this in the Message. Every invocation of a method of a
conversational interface is either starting or continuing a conversation
(the service knows which), except for methods marked @EndsConversation
(again, the service knows which). I don't see a use case that requires
a conversationSequence to flow in the Message.
You didn't mention messageId. Is there any reason to have this in
the Message? It's not being used currently.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
