I'm looking to do something about TUSCANY-3855 [1] and the associated
conversation [2]. Looking through the extensive posts I draw these
conclusions.
The current situation
================
An attempt to describe what context is available to various parts of
the infrastructure. Accessible context is noted in CAPITALS.
Service Binding
Binding Wire
Binding Interceptor
SERVICE MESSAGE (headers and binding context)
Operation Wire
Operation Interceptor
SERVICE MESSAGE (headers and binding context)
Component Service
Component Implementation
@Context RequestContext
REQUEST CONTEXT (security + service info from service message)
Component Reference
JDKInvocationHandler
Operation Wire
Operation Interceptor
REFERENCE MESSAGE (headers and binding context)
Binding Wire
Binding Interceptor
REFERENCE MESSAGE (headers and binding context)
Reference Binding
Context is passed on the thread using ThreadMessageContext which takes
a Message object. It's set to the incoming message in the following
places
NonBlockingInterceptor
RuntimeInvoker
JDIInvocationHandler
There are two main drawbacks of the current solution
1/ There is no way that the application can access (selected) context
information from the incoming request, e.g. information that a policy,
or other, interceptor wishes the implementation to have access to.
Other than that information that is prescribed by the RequestContext.
2/ The service message context is not available in the reference
chain. The headers are copied from the service message context to the
reference message context but any other context is not available
downstream.
An aggregation of the proposed improvements
===================================
1/ Application context
-----------------------------
>From the various conversations [2] it seems that it would be useful to
present context in two categories:
A/ Context that the application should have access to
B/ Context that the infrastructure should have access to
Where A is a subset of B.
B itself is a mixture of information.
i) information that is/should be part of the protocol message
ii) information pertinent to the configuration/operation of the
interceptor chain
All context is currently carried by the Tuscany message structure.
Beside the body itself we store context in two places in the Message
structure
Map<String, Object> getHeaders(); // Stores Bi + possibly a bit of Bii
<T> T getBindingContext(); // Stores Bii
We could massage this so that
Headers - is just Bi)
Context - is just Bii) and supports interceptor specific context objects
ApplicationContext - is just A
Infrastructure would then add objects to Context or ApplicationContext
depending on whether the application should be able to see it or not.
My concern here is how to define the interface so there isn't a huge
amount of searching and casting going on.
We could then add some extensibility to allow @Context to be
associated with arbitrary types that the interceptor chain has added
to ApplicationContext..
2/ Passing context through component
----------------------------------------------------
Haven't looked at the details here still but the suggestion is to move
the context switch to later in the chain. My initial thought is that
I'm tempted to suggest adding a Context item that points to the
reference message instead as the switch seems to be somewhat either/or
[1] https://issues.apache.org/jira/browse/TUSCANY-3855
[2] http://www.mail-archive.com/dev@tuscany.apache.org/msg15581.html
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
