You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2011/07/12 18:31:51 UTC
Invocation/Application Context (again)
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
Re: Invocation/Application Context (again)
Posted by Simon Nash <na...@apache.org>.
Raymond Feng wrote:
> I prefer to have strongly-typed context extensions. JAX-RS has the
> similar mechanism to allow custom context to be injected via @Context.
> The context can be resolved via:
>
> *http://jsr311.java.net/nonav/javadoc/javax/ws/rs/ext/ContextResolver.html*
> *
> *
+1 for this, if we can find a convenient and intuitive API for the user.
See the long thread at [1] for my views on the advantages of a strongly-typed
context over a generic Tuscany context.
Simon
[1] http://mail-archives.apache.org/mod_mbox/tuscany-dev/201102.mbox/%3C4D50625A.7080206@apache.org%3E
> *Thanks,*
> *Raymond
> *
> /________________________________________________________________
> Raymond Feng
> rfeng@apache.org <ma...@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 15, 2011, at 5:38 AM, Simon Laws wrote:
>
>> On Fri, Jul 15, 2011 at 12:42 PM, Mike Edwards
>> <mike.edwards.inglenook@gmail.com
>> <ma...@gmail.com>> wrote:
>>> On 15/07/2011 12:08, Simon Laws wrote:
>>>>
>>>> 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.
>>>>
>>> Well, I suppose we could envisage an annotation like
>>> @TuscanyRequestContext
>>> that would signal injection of a TuscanyRequestContext which would
>>> then not
>>> need any cast - but of course my concern is that any such code would only
>>> work with Tuscany and would not work with any other SCA runtime, which is
>>> the flip side of the concern.
>>
>> I was thinking more of allowing the following as a Tuscany specific
>> extension. Of course you need to be in Tuscany to use
>> TuscanyRequestContex but that's true of a cast also.
>>
>> @Context
>> TuscanyRequestContext myRequestContext.
>>
>>>
>>> In terms of "strong typing of context" I would be concerned about a
>>> scheme
>>> in which each potential atom of context was separately injected -
>>> this would
>>> get out of hand very quickly I think. I suppose one scheme is to treat
>>> context like a set of Properties to be injected, where the property names
>>> are simple strings (of the type I'm advocating for getContext()),
>>> with the
>>> implication that each field/setter would be annotated like
>>> @TuscanyRequestContext( "foo" ) - and with the assumption that the
>>> type of
>>> the field/method had better match the implied type of that context
>>> property
>>> (which must be defined by the runtime, not by the application).
>>
>> I'm slightly uneasy about that as it requires the Tuscany specific
>> annotations. I have considered the following but maybe that's just as
>> complex. WDYT?
>>
>> @Context
>> RequestContext requestContext;
>>
>> @Context
>> TuscanyRequestContext requestContext;
>>
>> @Context
>> MyContextUnrelatedToRequestContext myContextReference1;
>>
>> public void someServiceOperation(){
>> ContextValue value1 =
>> myContextReference1.getSomeValueFromTheContext();
>> ContextValue value2 =
>> requestContext.getExtendedContext(MyContextUnrelatedToRequestContext.class.getName()).getSomeValueFromTheContext();
>>
>> // I would expect value1 and value2 to be the same object.
>> }
>>
>>>
>>> I agree that the best we get for the set of names for context atoms is
>>> simply documentation - what would be good is a catalog that aims to
>>> promote
>>> the maximum amount of commonality, especially between Bindings, where
>>> I hope
>>> that header fields, for example, could use the same names and types for a
>>> wide range of binding types. This is really a matter of trying to get
>>> developers of binding implementations to use common context fields as
>>> far as
>>> possible.
>>>
>>> Of course, once you head down the headers road, then there could be a
>>> desire
>>> to reflect any and all headers into the application - something I don't
>>> think is a great idea - if it matters that much to the application it
>>> should
>>> be part of the service signature in 99.99% of cases.
>>
>> +1
>>
>>>
>>>
>>> Yours, Mike.
>>>
>>
>> Simon
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org <http://tuscany.apache.org>
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>> <http://tuscanyinaction.com>
>
Re: Invocation/Application Context (again)
Posted by Raymond Feng <en...@gmail.com>.
IMO, the @Context annotation allows an SCA Java component to receive injection of some contexts which cannot be modeled as a regular @Reference. In my use cases, I would like to be able to do something like:
@Context
private ServletContext servletContext; // My component is running as part of the web application
@Context
private ApplicationContext appContext; // My component needs to access some Spring information
@Context
private JAXBContext jaxbContext; // My component needs to do JAXB marshaling
The strong-typed context is clearly better than weakly-typed one from Java programming perspective. It also make the runtime easily to understand the requirements for specific context injection and implement context providers to support it.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@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 15, 2011, at 11:45 AM, Mike Edwards wrote:
> Raymond,
>
> Can you explain why you prefer strobgly types context extensions?
>
> Why is this JAX-RS mechanism a good thing?
>
> Can you paint a picture of what this would look like:
>
> a) for the application components
> b) for the runtime/binding components
>
>
> Yours, Mike.
>
> On 15/07/2011 17:35, Raymond Feng wrote:
>> I prefer to have strongly-typed context extensions. JAX-RS has the similar mechanism to allow custom
>> context to be injected via @Context. The context can be resolved via:
>>
>> *http://jsr311.java.net/nonav/javadoc/javax/ws/rs/ext/ContextResolver.html*
>> *
>> *
>> *Thanks,*
>> *Raymond
>> *
>
Re: Invocation/Application Context (again)
Posted by Mike Edwards <mi...@gmail.com>.
Raymond,
Can you explain why you prefer strobgly types context extensions?
Why is this JAX-RS mechanism a good thing?
Can you paint a picture of what this would look like:
a) for the application components
b) for the runtime/binding components
Yours, Mike.
On 15/07/2011 17:35, Raymond Feng wrote:
> I prefer to have strongly-typed context extensions. JAX-RS has the similar mechanism to allow custom
> context to be injected via @Context. The context can be resolved via:
>
> *http://jsr311.java.net/nonav/javadoc/javax/ws/rs/ext/ContextResolver.html*
> *
> *
> *Thanks,*
> *Raymond
> *
Re: Invocation/Application Context (again)
Posted by Raymond Feng <en...@gmail.com>.
I prefer to have strongly-typed context extensions. JAX-RS has the similar mechanism to allow custom context to be injected via @Context. The context can be resolved via:
http://jsr311.java.net/nonav/javadoc/javax/ws/rs/ext/ContextResolver.html
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@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 15, 2011, at 5:38 AM, Simon Laws wrote:
> On Fri, Jul 15, 2011 at 12:42 PM, Mike Edwards
> <mi...@gmail.com> wrote:
>> On 15/07/2011 12:08, Simon Laws wrote:
>>>
>>> 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.
>>>
>> Well, I suppose we could envisage an annotation like @TuscanyRequestContext
>> that would signal injection of a TuscanyRequestContext which would then not
>> need any cast - but of course my concern is that any such code would only
>> work with Tuscany and would not work with any other SCA runtime, which is
>> the flip side of the concern.
>
> I was thinking more of allowing the following as a Tuscany specific
> extension. Of course you need to be in Tuscany to use
> TuscanyRequestContex but that's true of a cast also.
>
> @Context
> TuscanyRequestContext myRequestContext.
>
>>
>> In terms of "strong typing of context" I would be concerned about a scheme
>> in which each potential atom of context was separately injected - this would
>> get out of hand very quickly I think. I suppose one scheme is to treat
>> context like a set of Properties to be injected, where the property names
>> are simple strings (of the type I'm advocating for getContext()), with the
>> implication that each field/setter would be annotated like
>> @TuscanyRequestContext( "foo" ) - and with the assumption that the type of
>> the field/method had better match the implied type of that context property
>> (which must be defined by the runtime, not by the application).
>
> I'm slightly uneasy about that as it requires the Tuscany specific
> annotations. I have considered the following but maybe that's just as
> complex. WDYT?
>
> @Context
> RequestContext requestContext;
>
> @Context
> TuscanyRequestContext requestContext;
>
> @Context
> MyContextUnrelatedToRequestContext myContextReference1;
>
> public void someServiceOperation(){
> ContextValue value1 = myContextReference1.getSomeValueFromTheContext();
> ContextValue value2 =
> requestContext.getExtendedContext(MyContextUnrelatedToRequestContext.class.getName()).getSomeValueFromTheContext();
>
> // I would expect value1 and value2 to be the same object.
> }
>
>>
>> I agree that the best we get for the set of names for context atoms is
>> simply documentation - what would be good is a catalog that aims to promote
>> the maximum amount of commonality, especially between Bindings, where I hope
>> that header fields, for example, could use the same names and types for a
>> wide range of binding types. This is really a matter of trying to get
>> developers of binding implementations to use common context fields as far as
>> possible.
>>
>> Of course, once you head down the headers road, then there could be a desire
>> to reflect any and all headers into the application - something I don't
>> think is a great idea - if it matters that much to the application it should
>> be part of the service signature in 99.99% of cases.
>
> +1
>
>>
>>
>> Yours, Mike.
>>
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Invocation/Application Context (again)
Posted by Simon Nash <na...@apache.org>.
Simon Laws wrote:
> On Fri, Jul 15, 2011 at 12:42 PM, Mike Edwards
> <mi...@gmail.com> wrote:
>> On 15/07/2011 12:08, Simon Laws wrote:
>>> 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.
>>>
>> Well, I suppose we could envisage an annotation like @TuscanyRequestContext
>> that would signal injection of a TuscanyRequestContext which would then not
>> need any cast - but of course my concern is that any such code would only
>> work with Tuscany and would not work with any other SCA runtime, which is
>> the flip side of the concern.
>
> I was thinking more of allowing the following as a Tuscany specific
> extension. Of course you need to be in Tuscany to use
> TuscanyRequestContex but that's true of a cast also.
>
With the subclass/cast approach, it's possible to write code that will run
on non-Tuscany runtimes, though not taking advantage of the Tuscany-specific
functionality in that case. Something like the following:
public class MyComponentImpl ....
@Context
RequestContext myRequestContext;
....
try {
Class trc = MyComponentImpl.class.getClassLoader().loadClass("org.apache.tuscany.sca.TuscanyRequestContext");
if (trc.isAssignableFrom(myRequestContext.getClass()) {
// Tuscany-specific code, using reflection to access the TuscanyRequestContext object
}
} catch(ClassNotFoundException e) {
}
This may or may not be useful, but I thought it's worth mentioning the possibility :-)
Simon
> @Context
> TuscanyRequestContext myRequestContext.
>
>> In terms of "strong typing of context" I would be concerned about a scheme
>> in which each potential atom of context was separately injected - this would
>> get out of hand very quickly I think. I suppose one scheme is to treat
>> context like a set of Properties to be injected, where the property names
>> are simple strings (of the type I'm advocating for getContext()), with the
>> implication that each field/setter would be annotated like
>> @TuscanyRequestContext( "foo" ) - and with the assumption that the type of
>> the field/method had better match the implied type of that context property
>> (which must be defined by the runtime, not by the application).
>
> I'm slightly uneasy about that as it requires the Tuscany specific
> annotations. I have considered the following but maybe that's just as
> complex. WDYT?
>
> @Context
> RequestContext requestContext;
>
> @Context
> TuscanyRequestContext requestContext;
>
> @Context
> MyContextUnrelatedToRequestContext myContextReference1;
>
> public void someServiceOperation(){
> ContextValue value1 = myContextReference1.getSomeValueFromTheContext();
> ContextValue value2 =
> requestContext.getExtendedContext(MyContextUnrelatedToRequestContext.class.getName()).getSomeValueFromTheContext();
>
> // I would expect value1 and value2 to be the same object.
> }
>
>> I agree that the best we get for the set of names for context atoms is
>> simply documentation - what would be good is a catalog that aims to promote
>> the maximum amount of commonality, especially between Bindings, where I hope
>> that header fields, for example, could use the same names and types for a
>> wide range of binding types. This is really a matter of trying to get
>> developers of binding implementations to use common context fields as far as
>> possible.
>>
>> Of course, once you head down the headers road, then there could be a desire
>> to reflect any and all headers into the application - something I don't
>> think is a great idea - if it matters that much to the application it should
>> be part of the service signature in 99.99% of cases.
>
> +1
>
>>
>> Yours, Mike.
>>
>
> Simon
>
Re: Invocation/Application Context (again)
Posted by Mike Edwards <mi...@gmail.com>.
Simon,
Commentary inline...
On 15/07/2011 13:38, Simon Laws wrote:
> On Fri, Jul 15, 2011 at 12:42 PM, Mike Edwards
> <mi...@gmail.com> wrote:
>> On 15/07/2011 12:08, Simon Laws wrote:
>>>
>>> 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.
>>>
>> Well, I suppose we could envisage an annotation like @TuscanyRequestContext
>> that would signal injection of a TuscanyRequestContext which would then not
>> need any cast - but of course my concern is that any such code would only
>> work with Tuscany and would not work with any other SCA runtime, which is
>> the flip side of the concern.
>
> I was thinking more of allowing the following as a Tuscany specific
> extension. Of course you need to be in Tuscany to use
> TuscanyRequestContex but that's true of a cast also.
>
> @Context
> TuscanyRequestContext myRequestContext.
>
>>
>> In terms of "strong typing of context" I would be concerned about a scheme
>> in which each potential atom of context was separately injected - this would
>> get out of hand very quickly I think. I suppose one scheme is to treat
>> context like a set of Properties to be injected, where the property names
>> are simple strings (of the type I'm advocating for getContext()), with the
>> implication that each field/setter would be annotated like
>> @TuscanyRequestContext( "foo" ) - and with the assumption that the type of
>> the field/method had better match the implied type of that context property
>> (which must be defined by the runtime, not by the application).
>
> I'm slightly uneasy about that as it requires the Tuscany specific
> annotations. I have considered the following but maybe that's just as
> complex. WDYT?
>
> @Context
> RequestContext requestContext;
>
> @Context
> TuscanyRequestContext requestContext;
>
> @Context
> MyContextUnrelatedToRequestContext myContextReference1;
One thing I don't like at all about this is that context is tied to a type - so every new piece of
context requires a new type. I suspect that much context will be much simpler than that and a
simple name -> value lookup is far preferable - and the value type will often turn out to be
something simple like a String.
>
> public void someServiceOperation(){
> ContextValue value1 = myContextReference1.getSomeValueFromTheContext();
> ContextValue value2 =
> requestContext.getExtendedContext(MyContextUnrelatedToRequestContext.class.getName()).getSomeValueFromTheContext();
>
> // I would expect value1 and value2 to be the same object.
> }
I can agree with the principle while disagreeing with the notion of doing a lookup based on a type
in that way. Way more complex than it needs to be, for no particular gain in capability. Simple
name lookup works well for the 80% case.
>
>>
>> I agree that the best we get for the set of names for context atoms is
>> simply documentation - what would be good is a catalog that aims to promote
>> the maximum amount of commonality, especially between Bindings, where I hope
>> that header fields, for example, could use the same names and types for a
>> wide range of binding types. This is really a matter of trying to get
>> developers of binding implementations to use common context fields as far as
>> possible.
>>
>> Of course, once you head down the headers road, then there could be a desire
>> to reflect any and all headers into the application - something I don't
>> think is a great idea - if it matters that much to the application it should
>> be part of the service signature in 99.99% of cases.
>
> +1
>
>>
>>
>> Yours, Mike.
>>
>
> Simon
>
Re: Invocation/Application Context (again)
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jul 15, 2011 at 12:42 PM, Mike Edwards
<mi...@gmail.com> wrote:
> On 15/07/2011 12:08, Simon Laws wrote:
>>
>> 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.
>>
> Well, I suppose we could envisage an annotation like @TuscanyRequestContext
> that would signal injection of a TuscanyRequestContext which would then not
> need any cast - but of course my concern is that any such code would only
> work with Tuscany and would not work with any other SCA runtime, which is
> the flip side of the concern.
I was thinking more of allowing the following as a Tuscany specific
extension. Of course you need to be in Tuscany to use
TuscanyRequestContex but that's true of a cast also.
@Context
TuscanyRequestContext myRequestContext.
>
> In terms of "strong typing of context" I would be concerned about a scheme
> in which each potential atom of context was separately injected - this would
> get out of hand very quickly I think. I suppose one scheme is to treat
> context like a set of Properties to be injected, where the property names
> are simple strings (of the type I'm advocating for getContext()), with the
> implication that each field/setter would be annotated like
> @TuscanyRequestContext( "foo" ) - and with the assumption that the type of
> the field/method had better match the implied type of that context property
> (which must be defined by the runtime, not by the application).
I'm slightly uneasy about that as it requires the Tuscany specific
annotations. I have considered the following but maybe that's just as
complex. WDYT?
@Context
RequestContext requestContext;
@Context
TuscanyRequestContext requestContext;
@Context
MyContextUnrelatedToRequestContext myContextReference1;
public void someServiceOperation(){
ContextValue value1 = myContextReference1.getSomeValueFromTheContext();
ContextValue value2 =
requestContext.getExtendedContext(MyContextUnrelatedToRequestContext.class.getName()).getSomeValueFromTheContext();
// I would expect value1 and value2 to be the same object.
}
>
> I agree that the best we get for the set of names for context atoms is
> simply documentation - what would be good is a catalog that aims to promote
> the maximum amount of commonality, especially between Bindings, where I hope
> that header fields, for example, could use the same names and types for a
> wide range of binding types. This is really a matter of trying to get
> developers of binding implementations to use common context fields as far as
> possible.
>
> Of course, once you head down the headers road, then there could be a desire
> to reflect any and all headers into the application - something I don't
> think is a great idea - if it matters that much to the application it should
> be part of the service signature in 99.99% of cases.
+1
>
>
> Yours, Mike.
>
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Invocation/Application Context (again)
Posted by Mike Edwards <mi...@gmail.com>.
On 15/07/2011 12:08, Simon Laws wrote:
>
> 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.
>
Well, I suppose we could envisage an annotation like @TuscanyRequestContext that would signal
injection of a TuscanyRequestContext which would then not need any cast - but of course my concern
is that any such code would only work with Tuscany and would not work with any other SCA runtime,
which is the flip side of the concern.
In terms of "strong typing of context" I would be concerned about a scheme in which each potential
atom of context was separately injected - this would get out of hand very quickly I think. I
suppose one scheme is to treat context like a set of Properties to be injected, where the property
names are simple strings (of the type I'm advocating for getContext()), with the implication that
each field/setter would be annotated like @TuscanyRequestContext( "foo" ) - and with the assumption
that the type of the field/method had better match the implied type of that context property (which
must be defined by the runtime, not by the application).
I agree that the best we get for the set of names for context atoms is simply documentation - what
would be good is a catalog that aims to promote the maximum amount of commonality, especially
between Bindings, where I hope that header fields, for example, could use the same names and types
for a wide range of binding types. This is really a matter of trying to get developers of binding
implementations to use common context fields as far as possible.
Of course, once you head down the headers road, then there could be a desire to reflect any and all
headers into the application - something I don't think is a great idea - if it matters that much to
the application it should be part of the service signature in 99.99% of cases.
Yours, Mike.
Re: Invocation/Application Context (again)
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jul 15, 2011 at 11:36 AM, Mike Edwards
<mi...@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
Re: Invocation/Application Context (again)
Posted by Mike Edwards <mi...@gmail.com>.
>
> 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.
Re: Invocation/Application Context (again)
Posted by Mike Edwards <mi...@gmail.com>.
On 13/07/2011 16:37, Simon Laws wrote:
> Yes, it's a shame we don't pass round a TuscanyContext rather than the
> ExtensionPointRegistry when we configure extension factories. We could
> look to do that but that's possibly a little orthogonal to how we pass
> context along the invocation chain. Although having said that if the
> providers did have access to a more complete context picture they
> could of course prime a message with a reference to that context at
> little extra cost. I was hinting at needing to add a context extension
> point so maybe that is a simple way through this. I.e. define a
> context base class and have context factories and structures
> registered against it, e.g.
>
> Static context:
>
> o.a.t.s.context.ContextFactory ->
> o.a.t.s.context.TuscanyContextFactory;context=o.a.t.s.context.TuscanyContext
> // for anything that doesn't change at runtime we could add the
> context object to the registry also
>
> Dynamic context:
>
> o.a.t.s.context.ContextFactory ->
> o.a.t.s.context.RequestContextFactory;context=o.a.t.s.context.RequestContext
> o.a.t.s.context.ContextFactory ->
> o.a.t.s.context.MyPolicyContextFactory;context=o.a.t.s.context.MyPolicyContext
>
> For the @Context visitor we could then look at the type of the
> injected context and compare against registered context types before
> creating and injector (currently it only allows
> Compoent/RequestContext)
>
> For the Message we could then adjust the interface to be something like
>
> Map<String, Object> getHeaders(); // retains this to hold message
> protocol headers. Any existing code that uses it remains the same
> <T> T getContext(Class<T> contextClass); // replaces getBindingContext()
>
> Hence when you need a particular context you do something like:
>
> MyPolicyContext context = message.getContext(MyPolicyContext.class);
>
> That should allows us include context extensibly in support of passing
> policy driven context to component implementations. If subsequently we
> want to connect context into a hierarchy that's great.
>
> Regards
>
> Simon
Folks,
I'd like to break this down into simple steps which address specific issues and functions, rather
than considering some grand scheme. Small steps that each provide value.
The first thing I'd like to consider is the way in which Context is passed to the application code -
and in particular where binding implementation / interceptor extensions can use the Context
mechanism to pass (arbitrary) data to the application code - and vice-versa.
Currently, there are 2 pieces of Context available to an application:
- ComponentContext
- RequestContext
These can be retrieved either via injection controlled by @ComponentContext and @RequestContext, or
via the API with explicit get..() calls.
Of these two, perhaps the most important is the RequestContext, although the principles can apply
equally to ComponentContext.
My thinking is that when requested to supply RequestContext to the application, that Tuscany
supplies not the formal OASIS-defined RequestContext, but a subclass - "TuscanyRequestContext".
I think that the simplest approach to TuscanyRequestContext that is still general is to add a single
map-style method to get additional context information, based on the use of a key that is a string:
Object getExtendedContext( String contextName );
...for code within Tuscany there would be an equivalent setter method:
void setExtendedContext( String contextName, Object );
If we prefer something more typesafe, we can use Generic versions of these methods:
<T> getExtendedContext<T>( String contextName ); (etc)
What I prefer about this approach is that it is still possible to write application code that is
portable through the use of instanceof - avoiding the need for the application to have things like
Tuscany annotations in the code.
Yours, Mike.
PS Next I think we should look at context information being passed from the application code to the
code involved in a reference invocation...
Re: Invocation/Application Context (again)
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jul 12, 2011 at 5:56 PM, Raymond Feng <en...@gmail.com> wrote:
> 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
> rfeng@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
> ________________________________________________________________
Yes, it's a shame we don't pass round a TuscanyContext rather than the
ExtensionPointRegistry when we configure extension factories. We could
look to do that but that's possibly a little orthogonal to how we pass
context along the invocation chain. Although having said that if the
providers did have access to a more complete context picture they
could of course prime a message with a reference to that context at
little extra cost. I was hinting at needing to add a context extension
point so maybe that is a simple way through this. I.e. define a
context base class and have context factories and structures
registered against it, e.g.
Static context:
o.a.t.s.context.ContextFactory ->
o.a.t.s.context.TuscanyContextFactory;context=o.a.t.s.context.TuscanyContext
// for anything that doesn't change at runtime we could add the
context object to the registry also
Dynamic context:
o.a.t.s.context.ContextFactory ->
o.a.t.s.context.RequestContextFactory;context=o.a.t.s.context.RequestContext
o.a.t.s.context.ContextFactory ->
o.a.t.s.context.MyPolicyContextFactory;context=o.a.t.s.context.MyPolicyContext
For the @Context visitor we could then look at the type of the
injected context and compare against registered context types before
creating and injector (currently it only allows
Compoent/RequestContext)
For the Message we could then adjust the interface to be something like
Map<String, Object> getHeaders(); // retains this to hold message
protocol headers. Any existing code that uses it remains the same
<T> T getContext(Class<T> contextClass); // replaces getBindingContext()
Hence when you need a particular context you do something like:
MyPolicyContext context = message.getContext(MyPolicyContext.class);
That should allows us include context extensibly in support of passing
policy driven context to component implementations. If subsequently we
want to connect context into a hierarchy that's great.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Invocation/Application Context (again)
Posted by Raymond Feng <en...@gmail.com>.
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
rfeng@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