Comments inline. I removed some text to make the current discussion
easier to follow.
Simon
Raymond Feng wrote:
Please see my comments inline.
(cut)
I don't think we should directly use From to hold the callback
endpoint. We'll lost the caller's EPR if we do so and we cannot
support RequestContext.getServiceReference().
>
The caller's EPR would not be lost when we do a service invocation.
Before the invocation, it is available as the "To" EPR in the
ThreadMessageContext. The invocation puts a new ThreadMessageContext
on the stack with the "To" EPR for the service that's being invoked.
When the invocation returns, the previous ThreadMessageContext is
restored and we still have the caller's EPR in the "To" field of
the ThreadMessageContext for RequestContext.getServiceReference()
to use.
By the caller's EPR, I meant the EPR for the reference on the caller
component. There might be intents/policies associated with the reference
and some interceptors will need to access all these information. The
previous To cannot provide such data for the outbound reference.
Thanks for the explanation. I now understand what you mean by the
caller's EPR and I understand why it might be needed by the outbound
interceptors. However, I'm not sure if it's valid to consider this
as an endpoint as far as WS-Addressing is concerned. From the
WS-Addressing spec:
A Web service endpoint is a (referenceable) entity, processor, or
resource where Web service messages can be targeted.
All SCA services, including callback pseudo-services, definitely qualify
as endpoints in this sense. I'm not so sure about SCA references.
Perhaps they could be considered logical endpoints in the sense that
the reply from the forward call (HTTP POST response) comes back to the
client reference (in some sense).
This case is discussed in the WS-Addressing spec, which says that the
"anonymous" URI
http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
should be used in this case. So if we are going to represent the client
reference as the From endpoint in the WS-Addressing protocol, I think
we should send the anonymous URI as its wsa:Address and not make up some
new Tuscany-specific URI to put in this element.
Let's assume this chain:
--> Component1.Service1 ---> Component1.Reference1 --> Component2.Service1
The previous To will be "Component1.Service1" and the new From should be
"Component1.Reference1". In the application code of Component2.Service1,
I assume the RequestContext.getServiceReference() will return the
CallableReference representing Component1.Reference1.
This raises some big questions. I had expected getServiceReference()
to return a server-side reference (suitably configured with the
conversation ID, callback ID, and callback endpoint from the service
invocation) that could be used to make a local call across the
SCA binding to Component2.Service1. It would be similar to a
self-reference but with additional configuration I think this is how
it currently works. If getServiceReference() returns a CallableReference
representing Component1.Reference1, does this mean that any calls through
this CallableReference would use the client's reference binding?
For Web services, this would need all the reference binding model
information to be serialized and sent to the service side, which doesn't
seem very practical or desirable.
The same issue applies to serialization and deserialization of
ServiceReferences/CallableReferences. Does the entire client-side
reference information including its binding model get serialized and
deserialized? Whatever we do for this, we should do the same for
the above case.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
