On Fri, Jul 15, 2011 at 11:36 AM, Mike Edwards <mike.edwards.inglen...@gmail.com> wrote: >> >> PS Next I think we should look at context information being passed from >> the application code to the >> code involved in a reference invocation... >> > Folks, > > OK, time to delve into this piece of function. > > The basic capability of both ComponentContext and RequestContext is to > supply information to an implementation when it is invoked. This could > include information passed from the Binding implementation to the > application (as discussed in the previous email). > > However, there is another piece of function which is nowhere described in > the SCA specifications - and that is the need for the implementation to be > able to convey information to the runtime - and specifically the Binding > implementation - when invoking a reference. > > This capability has been discussed on the Tuscany list in the past - notably > by some users. Examples include providing Authentication context for the > call - where the credentials may depend upon the Authentication of the > caller of the service (either passed striaght through, or created on the fly > by the application). > > The question is - how can this be done? > > One possibility is to use the RequestContext structure to carry the > information - or rather the extended form of TuscanyRequestContext, where we > can envisage making the setting of extended context values available to the > application: > > void setExtendedContext<T>( String contextName, <T> ); > > Obviously to be useful, there must be some set of "well known" contextName > values which the application code and the binding code can use. > > However, the principle is simple enough - the application sets up values in > the TuscanyRequestContext ahead of the invocation of some reference - and > the TuscanyRequestContext is available to the runtime code which implements > the reference, including the Binding code. > > One interesting question here is how to handle application threads which > were not used to invoke a service - eg a thread from a pool created & > managed by the application code. At present, such a thread would have no > context associated with it - to enable such threads to pass context to > references, there is a need for an API to allow a TuscanyRequestContext to > be created for such a thread. However, this is perhaps reaching too far at > the moment, given that we have not yet agreed the basic function. > > > Thoughts? > > Yours, Mike. > >
Commenting on the last two posts. Generally I prefer the strong typing of context and the ability to have that type injected into an implementation. I do though accept that there is no API alternative to injection for anything other than RequestContext or derivatives. In the derivative case the app writer would be still be expected to cast to TuscanyRequestContext which isn't so elegant but will work. So I think we need a combination of the changes outlined in this thread so far. 1/ Update the infrastructure to allow other types besides ComponentContext and RequestContext to be injected. We have the option here of allowing any type, just types that extend RequestContext or just TuscanyRequestContext. 2/ Provide a suitable mechanism on Message to carry the extra context so that interceptors can retrieve and populate it. I've suggested one but on consideration would maybe extend that to separate context that could be accessed by the application from context that can't 3/ Provide a mechanism for propagating the context forward from the implementation to the reference chain. As I commented before I don't think the focus of this should be which Message object is stored in thread context but how the service context is copied to or referenced from the reference context. The user may or may not want the reference context set up that way. We may adopt that default but they must be able to influence it either via the implementation or via an interceptor. We do need to decide whether TuscanyRequestContext.get/setExtendedContext() is the only way of expressing context extensions. Nothing in the above 3 steps forces us one way or the other. If we do adopt get/setExtendedContext() we need to decide how the index values are described. This could be as simple as documentation. re. "handling application threads which were not used to invoke a service" I agree that this is a separate issue. If the user is creating separate threads then maybe we should give TuscanyRequestContext the ability to attach or clone itself to the new thread once the user has caused it to be created. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
