Good summary :-). I like the context driven approach. In addition to what you listed, I propose a few more:
* TUSCANY_CONTEXT: The context for the whole Tuscany runtime in the JVM (can be seen as the replacement for NodeFactory). It provides accesses to the ExtensionPointRegistry (in turn Extension Points and Extensions). * NODE_CONTEXT: The context for a given Tuscany node (can be seen as the replacement for CompositeContext) On the application side, we could have things like: * DOMAIN_CONTEXT (to access the domain registry) * COMPONENT_CONTEXT (as well as BINDING_CONTEXT, IMPLEMENTATION_CONTEXT?) * REQUEST_CONTEXT (to access the security context, thread, MESSAGE) Also there should be a hierarchy of the context objects, for example, the NODE_CONTEXT should have a pointer to the TUSCANY_CONTEXT. Thanks, Raymond ________________________________________________________________ Raymond Feng rf...@apache.org Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Jul 12, 2011, at 9:31 AM, Simon Laws wrote: > 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
