Simon Laws wrote:
The difference as I understand it is that only very selected parts
of the invocation context would be exposed to application code
(i.e., what's available via the SCA API plus whatever the handlers
choose to make available), but the entire contents of the
Tuscany-defined generic context (all message headers for example)
would be exposed.
Simon
I agree that a component implementation should get at only that data
that is allowed access to by the SCA API.
I would argue that interceptors on the message chain should have
access to any context that they require to do their processing. I
would be very happy if an API were used to provide that to them.
Currently the API is provided by the Message object. However we are
finding that this is not good enough as we need to, for example, get
at the service context in reference processing.
Getting access to the service context during reference processing might
be possible if we defer the point where the Message object gets switched
in the thread context. However I'm not keen to see the inbound Message
used as a read-write communication vehicle between application code and
downstream reference interceptors/handlers.
If there were a context that allowed interceptors to add information
that other interceptors could later retrieve on a thread by thread
basis I think that would do the job. I think you are arguing that the
Thread storage/manipulation should be hidden behind and API which is
OK by me. This API may be different from the API used to expose
context to implementation implementers.
What I'm not clear on from your comment is what context you would hide
from down-stream interceptors. It seems unnecessary to populate a
context with information that subsequent processing can't read.
Simon
I'm not suggesting that any context would be hidden from interceptors.
My concern is to limit what application code can access. The paths of
communication are:
1) service handler ----> component implementation
2) component implementation ----> reference interceptor/handler
For 1), the service handler would have full access to the inbound
Message and would use that to create a specialized "data transfer"
object that would be accessible to the component implementation by
injection.
For 2), the component implementation could modify the same
"data transfer" object and this object would be accessible to the
reference interceptors/handlers. If we defer the point where the
Message object gets switched, the reference interceptors/handlers
would also have access to the inbound Message (as well as to the
under-construction outbound Message) if they need it.
I'm using the term "data transfer" rather than "context" as the
latter term is somewhat overloaded and potentially confusing.
Simon
