Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE



Hi,

I'm continuing the effort to add WS-Security to Tuscany 1.6.1 using the
PolicyHandler extension framework (later to Tuscany 2.0 using Policy
interceptor framework). I have another need for a framework capability,
which is to be able to pass information/state between the application
code, which is either a WS client or WS service using the WS binding,
and the Tuscany interceptors in general or PolicyHandler in my
particular case. I've been poking around in the debugger and did not see
anything I could possibly use. Is such capability available through some
mechanism?

As an example, Axis2 service implementation (skeleton), which extends
Axis2Service, can call the static
MessageContext.getCurrentMessageContext() to obtain the current
MessageContext and add properties to it. While the Axis2 handler's
invoke() method is call with the MessageContext, where the handler can
get the properties set by the application code. Also JAX-WS framework
allows WebServiceContext to be injected into application code and from
WebServiceContext application code can obtain the SOAPMessageContext.
While SOAPMessageContext is pass into handler's method.

 

Thanks,

Gang

 


Classification: UNCLASSIFIED
Caveats: NONE

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Thanks, Simon L. To further clarify what exactly is available, from your description, am I right in saying that the SAME object of type Message, which can carry ARBITRARY headers and not just predefined Subject (because I do need to pass objects, such as SMAL assertion objects), is accessible from PolicyHandler code for both service binding and reference binding? This sounds like the component implementation code does not have to get involved. Right? If so, this does sound useful for one of my scenarios and I'll try this out. 

Further details:

1. Is the Message object the same as the one that is passed to PolicyHandler's before/afterInvoke() or it has to be obtained by calling ThreadMessageContext.getMessageContext()?

2. If it can only be obtained by call ThreadMessageContext.getMessageContext(), which is a static method, can component implementation code access it? 

3. How should I interpret your statement, "While providing a "subject" in the component implementation doesn't, in its' own right,  help propagate the context to (4) and (5)"?

Because there is a second scenario, where the component implementation code also needs to add credential or security information to the context so that the associated PolicyHandler can access. Using your picture, this looks like:

(1) component implementation -> (2) handlers -> (3) reference binding

Where (1) needs to forward some security information to (2) to be further processed and sent to (3) to be transported to the remote service. If you answer to detailed question 2. Is "Yes", then this is solved. If not, any other mechanism?


Thanks,
Gang

-----Original Message-----
From: Simon Laws [mailto:simonslaws@googlemail.com] 
Sent: Friday, February 04, 2011 9:47 AM
To: dev@tuscany.apache.org
Subject: Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

On Fri, Feb 4, 2011 at 11:17 AM, Simon Nash <na...@apache.org> wrote:
> See responses below.  I've removed older discussion to make this
> easier to follow.
>
>  Simon
>
> Yang, Gang CTR US USA wrote:
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> (cut)
>>
>> GY: The use case applies to SCA well. When a new service is developed
>> referencing other existing services. The authorization is best done in a
>> distributed fashion - the information owning service makes the
>> authorization decision based on its existing policies. This means that
>> when a client access this new service with its credential, this
>> credential (in the form of some security token, say SAML) would need to
>> be passed to the other existing services for authorization. Translated
>> to SCA view, the handler for the service WS binding needs to pass the
>> user credential to the handler for the reference WS binding. Since the
>> two handlers does not have any direct relation, this is done (in other
>> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new service
>> implementation code which connects the service (inbound from the client)
>> to the reference (outbound to other services).
>>
> In SCA there's a getSecuritySubject() method on the RequestContext API.
> This is implemented by putting a Subject header in the ThreadMessageContext.
> This header is added by the service binding handler and would be available
> to the reference binding handler.  Does this do what you need?
>
>  Simon
>

Reading the comments here I think the scenario being described is

(1) service binding.ws -> (2) handlers -> (3) component implementation
-> (4) handlers -> (6) reference binding.ws

Where credentials received at (1) or computed at (2) are required to
be propagated to (4) and (5). Simon N is right that, in 1.x, we
already look to provide access to the security subject from within the
Java component implementation (3). See the following code  from [1]
for an example.

        for (Object header :
ThreadMessageContext.getMessageContext().getHeaders()){
            if (header instanceof Subject){
                subject  = (Subject)header;
                break;
            }
        }


While providing a "subject" in the component implementation doesn't,
in its' own right,  help propagate the context to (4) and (5) this
does show that the incoming message is available in the thread context
so (4) and (5) have access to it also assuming you don't do any thread
switching in your component implementation.

[1] http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/context/RequestContextImpl.java

Regards

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Simon Laws wrote:
> On Mon, Feb 7, 2011 at 10:35 AM, Simon Nash <na...@apache.org> wrote:
>> Simon Laws wrote:
>>> On Fri, Feb 4, 2011 at 4:49 PM, Yang, Gang CTR US USA
>>> <ga...@us.army.mil> wrote:
>>> (cut)
>>>
>>> To reply to both Simon and Gangs posts...
>>>
>>> I had missed that. I don't know why we put the request message in the
>>> TMC rather than leaving it as is. It's not clear to me what's pulling
>>> the request message from there at the moment. All of the interceptors
>>> down the chain already have access to the request message part of the
>>> invoke. There must be a reason so I'll have to look more closely.
>>>
>> It's because the application code needs access to information in the
>> inbound Message object.  This includes for example the callback endpoint and
>> also the service reference returned by RequestContext.getServiceReference().
>> The Message object isn't passed in to the application code, so it can
>> only be obtained from the ThreadMessageContext.
>>
>>  Simon
>>
>>> I agree with Simon that we would have to be careful before just
>>> copying headers arbitrarily from one to another. I had thought this
>>> was the job of policy handlers on the reference side.
>>>
>>> Simon
>>>
>>
> 
> What do you mean by "the application code" here. The context switch we
> are talking about is on the reference side.
> 
> Simon
> 
OK, I understand your point now.  Interestingly I had a very similar
thought when thinking some more about the "invocation context" concept
(see my other recent post).  We could make the lifecycles of "message context"
and "invocation context" the same by deferring/avoiding the message context
switch on the reference side.  The message context switch would still be
needed on the service side.

   Simon

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

On Mon, Feb 7, 2011 at 10:35 AM, Simon Nash <na...@apache.org> wrote:
> Simon Laws wrote:
>>
>> On Fri, Feb 4, 2011 at 4:49 PM, Yang, Gang CTR US USA
>> <ga...@us.army.mil> wrote:
>
>>
>> (cut)
>>
>> To reply to both Simon and Gangs posts...
>>
>> I had missed that. I don't know why we put the request message in the
>> TMC rather than leaving it as is. It's not clear to me what's pulling
>> the request message from there at the moment. All of the interceptors
>> down the chain already have access to the request message part of the
>> invoke. There must be a reason so I'll have to look more closely.
>>
> It's because the application code needs access to information in the
> inbound Message object.  This includes for example the callback endpoint and
> also the service reference returned by RequestContext.getServiceReference().
> The Message object isn't passed in to the application code, so it can
> only be obtained from the ThreadMessageContext.
>
>  Simon
>
>> I agree with Simon that we would have to be careful before just
>> copying headers arbitrarily from one to another. I had thought this
>> was the job of policy handlers on the reference side.
>>
>> Simon
>>
>
>

What do you mean by "the application code" here. The context switch we
are talking about is on the reference side.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Simon Laws wrote:
> On Fri, Feb 4, 2011 at 4:49 PM, Yang, Gang CTR US USA
> <ga...@us.army.mil> wrote:
 >
 > (cut)
> 
> To reply to both Simon and Gangs posts...
> 
> I had missed that. I don't know why we put the request message in the
> TMC rather than leaving it as is. It's not clear to me what's pulling
> the request message from there at the moment. All of the interceptors
> down the chain already have access to the request message part of the
> invoke. There must be a reason so I'll have to look more closely.
> 
It's because the application code needs access to information in the
inbound Message object.  This includes for example the callback endpoint and
also the service reference returned by RequestContext.getServiceReference().
The Message object isn't passed in to the application code, so it can
only be obtained from the ThreadMessageContext.

   Simon

> I agree with Simon that we would have to be careful before just
> copying headers arbitrarily from one to another. I had thought this
> was the job of policy handlers on the reference side.
> 
> Simon
> 

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Response follows.

Gang

> -----Original Message-----
> From: Simon Laws [mailto:simonslaws@googlemail.com]
> Sent: Friday, February 04, 2011 12:00 PM
> To: dev@tuscany.apache.org
> Subject: Re: Can application code and interceptor/handler code in
> Tuscany communicate with each other via some context? (UNCLASSIFIED)
> 
> On Fri, Feb 4, 2011 at 4:49 PM, Yang, Gang CTR US USA
> <ga...@us.army.mil> wrote:
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> > Response follows.
> >
> > Gang
> >
> >> -----Original Message-----
> >> From: Simon Nash [mailto:nash@apache.org]
> >> Sent: Friday, February 04, 2011 10:32 AM
> >> To: dev@tuscany.apache.org
> >> Subject: Re: Can application code and interceptor/handler code in
> >> Tuscany communicate with each other via some context? (UNCLASSIFIED)
> >>
> >> Simon Laws wrote:
> >> > On Fri, Feb 4, 2011 at 11:17 AM, Simon Nash <na...@apache.org>
> wrote:
> >> >> See responses below.  I've removed older discussion to make this
> >> >> easier to follow.
> >> >>
> >> >>  Simon
> >> >>
> >> >> Yang, Gang CTR US USA wrote:
> >> >>> Classification: UNCLASSIFIED
> >> >>> Caveats: NONE
> >> >>>
> >> >>> (cut)
> >> >>>
> >> >>> GY: The use case applies to SCA well. When a new service is
> >> developed
> >> >>> referencing other existing services. The authorization is best
> > done
> >> in a
> >> >>> distributed fashion - the information owning service makes the
> >> >>> authorization decision based on its existing policies. This
> means
> >> that
> >> >>> when a client access this new service with its credential, this
> >> >>> credential (in the form of some security token, say SAML) would
> >> need to
> >> >>> be passed to the other existing services for authorization.
> >> Translated
> >> >>> to SCA view, the handler for the service WS binding needs to
> pass
> >> the
> >> >>> user credential to the handler for the reference WS binding.
> Since
> >> the
> >> >>> two handlers does not have any direct relation, this is done (in
> >> other
> >> >>> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new
> >> service
> >> >>> implementation code which connects the service (inbound from the
> >> client)
> >> >>> to the reference (outbound to other services).
> >> >>>
> >> >> In SCA there's a getSecuritySubject() method on the
> RequestContext
> >> API.
> >> >> This is implemented by putting a Subject header in the
> >> ThreadMessageContext.
> >> >> This header is added by the service binding handler and would be
> >> available
> >> >> to the reference binding handler.  Does this do what you need?
> >> >>
> >> >>  Simon
> >> >>
> >> >
> >> > Reading the comments here I think the scenario being described is
> >> >
> >> > (1) service binding.ws -> (2) handlers -> (3) component
> >> implementation
> >> > -> (4) handlers -> (6) reference binding.ws
> >> >
> >> > Where credentials received at (1) or computed at (2) are required
> to
> >> > be propagated to (4) and (5). Simon N is right that, in 1.x, we
> >> > already look to provide access to the security subject from within
> >> the
> >> > Java component implementation (3). See the following code  from
> [1]
> >> > for an example.
> >> >
> >> >         for (Object header :
> >> > ThreadMessageContext.getMessageContext().getHeaders()){
> >> >             if (header instanceof Subject){
> >> >                 subject  = (Subject)header;
> >> >                 break;
> >> >             }
> >> >         }
> >> >
> >> >
> >> > While providing a "subject" in the component implementation
> doesn't,
> >> > in its' own right,  help propagate the context to (4) and (5) this
> >> > does show that the incoming message is available in the thread
> >> context
> >> > so (4) and (5) have access to it also assuming you don't do any
> >> thread
> >> > switching in your component implementation.
> >> >
> >> > [1] http://svn.apache.org/repos/asf/tuscany/sca-java-
> >>
> >
> 1.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/contex
> >> t/RequestContextImpl.java
> >> >
> >> > Regards
> >> >
> >> > Simon
> >> >
> >> I think there's a slight problem here.  When the implementation (3)
> >> makes
> >> a request invocation, JDKInvocationHandler creates a new Message
> > object
> >> and put it in the ThreadMessageContext.  This Message object is
> >> accessible to (4) and (5) but the original Message object
> (containing
> >> the incoming JAAS Subject header) isn't.  To allow (4) and (5) to
> >> access
> >> the incoming security subject, we would need to change the
> MessageImpl
> >> constructor so that the current security subject in the
> >> ThreadMessageContext
> >> is added to the newly created MessageImpl.
> >
> > I had the feeling that they might be different Message objects when I
> > asked the detailed questions in my other response to Simon L.'s post.
> It
> > makes sense because Message is actually presenting the message and
> there
> > are two messages involved here. Can the context be enhanced to a
> general
> > one?
> >
> > Gang
> >
> >>
> >> Is it safe to make this change?  Is it correct from an SCA
> > perspective?
> >> I'm concerned that it might cause security credentials to leak out
> >> when the application isn't expecting this.
> >
> > It's true that opening up this context to the component
> implementation
> > code may cause some undesired leakage of information in this
> scenario.
> > But in the second scenario I described in my other response, the
> > component implementation does need to pass some information to the
> > handlers dynamically at runtime. One possible solution is to make the
> > information flow one way, from component implementation to handlers,
> but
> > not the reverse. We can do this only if (1)/(2) can directly
> communicate
> > with (4)/(5) w/o (3)'s involvement.
> >
> > Gang
> >
> >>
> >>    Simon
> >
> >
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> >
> >
> 
> To reply to both Simon and Gangs posts...
> 
> I had missed that. I don't know why we put the request message in the
> TMC rather than leaving it as is. It's not clear to me what's pulling
> the request message from there at the moment. All of the interceptors
> down the chain already have access to the request message part of the
> invoke. There must be a reason so I'll have to look more closely.
> 
> I agree with Simon that we would have to be careful before just
> copying headers arbitrarily from one to another. I had thought this
> was the job of policy handlers on the reference side.

I definitely agree with not copying headers arbitrarily. I'm not suggesting that because message headers are unique properties of each individual message and should not be "shared" or used to transfer states. The reason that we are even talking about message headers is due to the current implementation of the context being Message class. In my opinion, the context is a more general concept that would include all messages (inbound, and possible multiple outbounds for multiple references) plus other states. I'm not sure there's time or is even worth the effort to enhance that since 2.x is on its way. If all Message objects are available to handlers, I don't mind to do the "copying" in the handlers. I do have concerns if I add arbitrary headers to one of the message for state carrying purpose, what the Tuscany runtime/framework would do with them and side effects it would cause.

> 
> Simon
> 
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

On Fri, Feb 4, 2011 at 4:49 PM, Yang, Gang CTR US USA
<ga...@us.army.mil> wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Response follows.
>
> Gang
>
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org]
>> Sent: Friday, February 04, 2011 10:32 AM
>> To: dev@tuscany.apache.org
>> Subject: Re: Can application code and interceptor/handler code in
>> Tuscany communicate with each other via some context? (UNCLASSIFIED)
>>
>> Simon Laws wrote:
>> > On Fri, Feb 4, 2011 at 11:17 AM, Simon Nash <na...@apache.org> wrote:
>> >> See responses below.  I've removed older discussion to make this
>> >> easier to follow.
>> >>
>> >>  Simon
>> >>
>> >> Yang, Gang CTR US USA wrote:
>> >>> Classification: UNCLASSIFIED
>> >>> Caveats: NONE
>> >>>
>> >>> (cut)
>> >>>
>> >>> GY: The use case applies to SCA well. When a new service is
>> developed
>> >>> referencing other existing services. The authorization is best
> done
>> in a
>> >>> distributed fashion - the information owning service makes the
>> >>> authorization decision based on its existing policies. This means
>> that
>> >>> when a client access this new service with its credential, this
>> >>> credential (in the form of some security token, say SAML) would
>> need to
>> >>> be passed to the other existing services for authorization.
>> Translated
>> >>> to SCA view, the handler for the service WS binding needs to pass
>> the
>> >>> user credential to the handler for the reference WS binding. Since
>> the
>> >>> two handlers does not have any direct relation, this is done (in
>> other
>> >>> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new
>> service
>> >>> implementation code which connects the service (inbound from the
>> client)
>> >>> to the reference (outbound to other services).
>> >>>
>> >> In SCA there's a getSecuritySubject() method on the RequestContext
>> API.
>> >> This is implemented by putting a Subject header in the
>> ThreadMessageContext.
>> >> This header is added by the service binding handler and would be
>> available
>> >> to the reference binding handler.  Does this do what you need?
>> >>
>> >>  Simon
>> >>
>> >
>> > Reading the comments here I think the scenario being described is
>> >
>> > (1) service binding.ws -> (2) handlers -> (3) component
>> implementation
>> > -> (4) handlers -> (6) reference binding.ws
>> >
>> > Where credentials received at (1) or computed at (2) are required to
>> > be propagated to (4) and (5). Simon N is right that, in 1.x, we
>> > already look to provide access to the security subject from within
>> the
>> > Java component implementation (3). See the following code  from [1]
>> > for an example.
>> >
>> >         for (Object header :
>> > ThreadMessageContext.getMessageContext().getHeaders()){
>> >             if (header instanceof Subject){
>> >                 subject  = (Subject)header;
>> >                 break;
>> >             }
>> >         }
>> >
>> >
>> > While providing a "subject" in the component implementation doesn't,
>> > in its' own right,  help propagate the context to (4) and (5) this
>> > does show that the incoming message is available in the thread
>> context
>> > so (4) and (5) have access to it also assuming you don't do any
>> thread
>> > switching in your component implementation.
>> >
>> > [1] http://svn.apache.org/repos/asf/tuscany/sca-java-
>>
> 1.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/contex
>> t/RequestContextImpl.java
>> >
>> > Regards
>> >
>> > Simon
>> >
>> I think there's a slight problem here.  When the implementation (3)
>> makes
>> a request invocation, JDKInvocationHandler creates a new Message
> object
>> and put it in the ThreadMessageContext.  This Message object is
>> accessible to (4) and (5) but the original Message object (containing
>> the incoming JAAS Subject header) isn't.  To allow (4) and (5) to
>> access
>> the incoming security subject, we would need to change the MessageImpl
>> constructor so that the current security subject in the
>> ThreadMessageContext
>> is added to the newly created MessageImpl.
>
> I had the feeling that they might be different Message objects when I
> asked the detailed questions in my other response to Simon L.'s post. It
> makes sense because Message is actually presenting the message and there
> are two messages involved here. Can the context be enhanced to a general
> one?
>
> Gang
>
>>
>> Is it safe to make this change?  Is it correct from an SCA
> perspective?
>> I'm concerned that it might cause security credentials to leak out
>> when the application isn't expecting this.
>
> It's true that opening up this context to the component implementation
> code may cause some undesired leakage of information in this scenario.
> But in the second scenario I described in my other response, the
> component implementation does need to pass some information to the
> handlers dynamically at runtime. One possible solution is to make the
> information flow one way, from component implementation to handlers, but
> not the reverse. We can do this only if (1)/(2) can directly communicate
> with (4)/(5) w/o (3)'s involvement.
>
> Gang
>
>>
>>    Simon
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>

To reply to both Simon and Gangs posts...

I had missed that. I don't know why we put the request message in the
TMC rather than leaving it as is. It's not clear to me what's pulling
the request message from there at the moment. All of the interceptors
down the chain already have access to the request message part of the
invoke. There must be a reason so I'll have to look more closely.

I agree with Simon that we would have to be careful before just
copying headers arbitrarily from one to another. I had thought this
was the job of policy handlers on the reference side.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Response follows.

Gang

> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Friday, February 04, 2011 10:32 AM
> To: dev@tuscany.apache.org
> Subject: Re: Can application code and interceptor/handler code in
> Tuscany communicate with each other via some context? (UNCLASSIFIED)
> 
> Simon Laws wrote:
> > On Fri, Feb 4, 2011 at 11:17 AM, Simon Nash <na...@apache.org> wrote:
> >> See responses below.  I've removed older discussion to make this
> >> easier to follow.
> >>
> >>  Simon
> >>
> >> Yang, Gang CTR US USA wrote:
> >>> Classification: UNCLASSIFIED
> >>> Caveats: NONE
> >>>
> >>> (cut)
> >>>
> >>> GY: The use case applies to SCA well. When a new service is
> developed
> >>> referencing other existing services. The authorization is best
done
> in a
> >>> distributed fashion - the information owning service makes the
> >>> authorization decision based on its existing policies. This means
> that
> >>> when a client access this new service with its credential, this
> >>> credential (in the form of some security token, say SAML) would
> need to
> >>> be passed to the other existing services for authorization.
> Translated
> >>> to SCA view, the handler for the service WS binding needs to pass
> the
> >>> user credential to the handler for the reference WS binding. Since
> the
> >>> two handlers does not have any direct relation, this is done (in
> other
> >>> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new
> service
> >>> implementation code which connects the service (inbound from the
> client)
> >>> to the reference (outbound to other services).
> >>>
> >> In SCA there's a getSecuritySubject() method on the RequestContext
> API.
> >> This is implemented by putting a Subject header in the
> ThreadMessageContext.
> >> This header is added by the service binding handler and would be
> available
> >> to the reference binding handler.  Does this do what you need?
> >>
> >>  Simon
> >>
> >
> > Reading the comments here I think the scenario being described is
> >
> > (1) service binding.ws -> (2) handlers -> (3) component
> implementation
> > -> (4) handlers -> (6) reference binding.ws
> >
> > Where credentials received at (1) or computed at (2) are required to
> > be propagated to (4) and (5). Simon N is right that, in 1.x, we
> > already look to provide access to the security subject from within
> the
> > Java component implementation (3). See the following code  from [1]
> > for an example.
> >
> >         for (Object header :
> > ThreadMessageContext.getMessageContext().getHeaders()){
> >             if (header instanceof Subject){
> >                 subject  = (Subject)header;
> >                 break;
> >             }
> >         }
> >
> >
> > While providing a "subject" in the component implementation doesn't,
> > in its' own right,  help propagate the context to (4) and (5) this
> > does show that the incoming message is available in the thread
> context
> > so (4) and (5) have access to it also assuming you don't do any
> thread
> > switching in your component implementation.
> >
> > [1] http://svn.apache.org/repos/asf/tuscany/sca-java-
>
1.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/contex
> t/RequestContextImpl.java
> >
> > Regards
> >
> > Simon
> >
> I think there's a slight problem here.  When the implementation (3)
> makes
> a request invocation, JDKInvocationHandler creates a new Message
object
> and put it in the ThreadMessageContext.  This Message object is
> accessible to (4) and (5) but the original Message object (containing
> the incoming JAAS Subject header) isn't.  To allow (4) and (5) to
> access
> the incoming security subject, we would need to change the MessageImpl
> constructor so that the current security subject in the
> ThreadMessageContext
> is added to the newly created MessageImpl.

I had the feeling that they might be different Message objects when I
asked the detailed questions in my other response to Simon L.'s post. It
makes sense because Message is actually presenting the message and there
are two messages involved here. Can the context be enhanced to a general
one?

Gang

> 
> Is it safe to make this change?  Is it correct from an SCA
perspective?
> I'm concerned that it might cause security credentials to leak out
> when the application isn't expecting this.

It's true that opening up this context to the component implementation
code may cause some undesired leakage of information in this scenario.
But in the second scenario I described in my other response, the
component implementation does need to pass some information to the
handlers dynamically at runtime. One possible solution is to make the
information flow one way, from component implementation to handlers, but
not the reverse. We can do this only if (1)/(2) can directly communicate
with (4)/(5) w/o (3)'s involvement.

Gang

> 
>    Simon


Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Simon Laws wrote:
> On Fri, Feb 4, 2011 at 11:17 AM, Simon Nash <na...@apache.org> wrote:
>> See responses below.  I've removed older discussion to make this
>> easier to follow.
>>
>>  Simon
>>
>> Yang, Gang CTR US USA wrote:
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> (cut)
>>>
>>> GY: The use case applies to SCA well. When a new service is developed
>>> referencing other existing services. The authorization is best done in a
>>> distributed fashion - the information owning service makes the
>>> authorization decision based on its existing policies. This means that
>>> when a client access this new service with its credential, this
>>> credential (in the form of some security token, say SAML) would need to
>>> be passed to the other existing services for authorization. Translated
>>> to SCA view, the handler for the service WS binding needs to pass the
>>> user credential to the handler for the reference WS binding. Since the
>>> two handlers does not have any direct relation, this is done (in other
>>> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new service
>>> implementation code which connects the service (inbound from the client)
>>> to the reference (outbound to other services).
>>>
>> In SCA there's a getSecuritySubject() method on the RequestContext API.
>> This is implemented by putting a Subject header in the ThreadMessageContext.
>> This header is added by the service binding handler and would be available
>> to the reference binding handler.  Does this do what you need?
>>
>>  Simon
>>
> 
> Reading the comments here I think the scenario being described is
> 
> (1) service binding.ws -> (2) handlers -> (3) component implementation
> -> (4) handlers -> (6) reference binding.ws
> 
> Where credentials received at (1) or computed at (2) are required to
> be propagated to (4) and (5). Simon N is right that, in 1.x, we
> already look to provide access to the security subject from within the
> Java component implementation (3). See the following code  from [1]
> for an example.
> 
>         for (Object header :
> ThreadMessageContext.getMessageContext().getHeaders()){
>             if (header instanceof Subject){
>                 subject  = (Subject)header;
>                 break;
>             }
>         }
> 
> 
> While providing a "subject" in the component implementation doesn't,
> in its' own right,  help propagate the context to (4) and (5) this
> does show that the incoming message is available in the thread context
> so (4) and (5) have access to it also assuming you don't do any thread
> switching in your component implementation.
> 
> [1] http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/context/RequestContextImpl.java
> 
> Regards
> 
> Simon
> 
I think there's a slight problem here.  When the implementation (3) makes
a request invocation, JDKInvocationHandler creates a new Message object
and put it in the ThreadMessageContext.  This Message object is
accessible to (4) and (5) but the original Message object (containing
the incoming JAAS Subject header) isn't.  To allow (4) and (5) to access
the incoming security subject, we would need to change the MessageImpl
constructor so that the current security subject in the ThreadMessageContext
is added to the newly created MessageImpl.

Is it safe to make this change?  Is it correct from an SCA perspective?
I'm concerned that it might cause security credentials to leak out
when the application isn't expecting this.

   Simon

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

On Fri, Feb 4, 2011 at 11:17 AM, Simon Nash <na...@apache.org> wrote:
> See responses below.  I've removed older discussion to make this
> easier to follow.
>
>  Simon
>
> Yang, Gang CTR US USA wrote:
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> (cut)
>>
>> GY: The use case applies to SCA well. When a new service is developed
>> referencing other existing services. The authorization is best done in a
>> distributed fashion - the information owning service makes the
>> authorization decision based on its existing policies. This means that
>> when a client access this new service with its credential, this
>> credential (in the form of some security token, say SAML) would need to
>> be passed to the other existing services for authorization. Translated
>> to SCA view, the handler for the service WS binding needs to pass the
>> user credential to the handler for the reference WS binding. Since the
>> two handlers does not have any direct relation, this is done (in other
>> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new service
>> implementation code which connects the service (inbound from the client)
>> to the reference (outbound to other services).
>>
> In SCA there's a getSecuritySubject() method on the RequestContext API.
> This is implemented by putting a Subject header in the ThreadMessageContext.
> This header is added by the service binding handler and would be available
> to the reference binding handler.  Does this do what you need?
>
>  Simon
>

Reading the comments here I think the scenario being described is

(1) service binding.ws -> (2) handlers -> (3) component implementation
-> (4) handlers -> (6) reference binding.ws

Where credentials received at (1) or computed at (2) are required to
be propagated to (4) and (5). Simon N is right that, in 1.x, we
already look to provide access to the security subject from within the
Java component implementation (3). See the following code  from [1]
for an example.

        for (Object header :
ThreadMessageContext.getMessageContext().getHeaders()){
            if (header instanceof Subject){
                subject  = (Subject)header;
                break;
            }
        }


While providing a "subject" in the component implementation doesn't,
in its' own right,  help propagate the context to (4) and (5) this
does show that the incoming message is available in the thread context
so (4) and (5) have access to it also assuming you don't do any thread
switching in your component implementation.

[1] http://svn.apache.org/repos/asf/tuscany/sca-java-1.x/trunk/modules/core/src/main/java/org/apache/tuscany/sca/core/context/RequestContextImpl.java

Regards

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

On Mon, Feb 7, 2011 at 10:40 AM, Simon Nash <na...@apache.org> wrote:
> Yang, Gang CTR US USA wrote:
>>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> (cut)
>>
>> I'm not sure about using ThreadLocal in a service framework environment
>> for component implementation or even user-added handlers since I don't
>> know how the framework manages the threads.
>>
> That's a valid point.  To prevent possible problems if the framework
> switches threads, any use of ThreadLocal should be managed by the
> framework rather than by unmanaged direct calls from application code.
>
>  Simon
>
>

+1

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> (cut)
> 
> I'm not sure about using ThreadLocal in a service framework environment
> for component implementation or even user-added handlers since I don't
> know how the framework manages the threads.
> 
That's a valid point.  To prevent possible problems if the framework
switches threads, any use of ThreadLocal should be managed by the
framework rather than by unmanaged direct calls from application code.

   Simon

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Simon Laws wrote:
> ..snip
>>
>> 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.
> 
> Sounds OK, I still haven't got to the bottom of why we need the switch
> but I haven't looked at all of the end to end picture yet.
 >
We need the switch when a reference in component A invokes a service
in component B locally on the same JVM thread.  Without the switch,
component B's implementation would see the same inbound Message as
component A's implementation.

At present we do the switch in JDKInvocationHandler when component A
makes a reference invocation.  Instead, I think we could do the switch
when component B's service is dispatched.  The service dispatch always
needs to put the Message into the thread context so that it's accessible
to the service implementation code.  When B's service invocation returns
back to the dispatcher, the Message for B's service invocation would be
discarded and the Message for A's service invocation would be restored.

   Simon

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

..snip
>>
>> 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.

I think I probably agree with this. It's primarily the context that
today that gets stuffed in the message headers that we're interested
in.

>
>> 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.

OK, makes sense.

>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.

Sounds OK, I still haven't got to the bottom of why we need the switch
but I haven't looked at all of the end to end picture yet.
>
> I'm using the term "data transfer" rather than "context" as the
> latter term is somewhat overloaded and potentially confusing.

Good point.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

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

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Responses follow below.

Gang

---cut---
> To me this naming convention adds complexity and the possibility
> for problems if the convention isn't followed.  If a new type is
> defined rather than using Map<String, Object> directly, this solves
> the injection type problem, but it means that all application code
> that uses this capability must add a dependency on a Tuscany-specific
> class, which means that the component can't be run (or even loaded)
> on other SCA implementations.

Actually this is a missing piece in SCA spec in my opinion and I'm
surprised.

---cut---
> Thanks for the clarification.  If handlers want to share information,
> they can create shared context (not the same as the "application
> context")
> to do this.  I think it's undesirable to overload the purpose of the
> "application context" by also using it to share state between
handlers.
> This exposes things to the application that are intended for handler
> use
> rather than for application use, which isn't desirable IMO.

The purpose of "application context" is still sharing states. The
argument is how much policing (restriction) you want to put. I'm not
advocating for no-policing, but it has to allow doing simple things
easily. 
Trade off is the usability.

> 
>    Simon
> 
> > --- cut ---
> >
> > Gang
> >
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> >
> >
> >


Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> To make it more readable, some text is cut.
> 
> ... cut ...
>>> The drawback of this approach is that it does not abstract and
>> promote
>>> reuse. Each handler and/or component implementation is required to
>>> develop its own context object and injection extension while an
>>> abstraction, such as a map<String, Object>, could satisfy most
>> demands
>>> and be reused.
>>>
>> The "data transfer/context" objects would be developed and created by
>> handlers and used by component implementations.  There's no need for
>> any injection extensions as the Tuscany runtime would take care of
>> that.
>>
>> One problem with Map<String, Object> is that different handlers could
>> collide with each other if they happen to use the same String keys
>> for entries in the Map.  Also this type definition isn't sufficiently
>> unique to allow the type-driven Tuscany injection mechanism to
> function
>> correctly.
> 
> The key collision can be remedied by using hierarchically qualified key
> names, such as "org.apache.tuscany.axis2-binding.XXX", which makes
> collision unlikely. In my scheme, the entire application context object
> (a single one of type say ApplicationContext), which is implemented
> using Map<String, Object>, is injected into the component implementation
> and let the component implementation to get what it wants and ignore
> those it doesn't care. I don't see how it would cause injection
> difficulty.
> 
To me this naming convention adds complexity and the possibility
for problems if the convention isn't followed.  If a new type is
defined rather than using Map<String, Object> directly, this solves
the injection type problem, but it means that all application code
that uses this capability must add a dependency on a Tuscany-specific
class, which means that the component can't be run (or even loaded)
on other SCA implementations.

>>> The shared general context also promote sharing. For example, in
> JAX-
>> WS
>>> framework, certain WS-* related properties that are put in by the
>>> underlying JAX-WS framework provider or other handlers can and are
>> used
>>> in our WS-Security implementation. It promotes reuse. In some case
>> the
>>> information that are put in the context by the framework or other
>>> handlers is not obtainable by our WS-security handlers because of
> the
>>> phrases and layers differences.
>>>
>> I think this supports my reservations about a shared context.  By
>> requiring each handler to define specifically what state it makes
>> available to the application, it is always clear what information
>> will be available, based on the combination of handlers (policy sets)
>> attached to a service or reference.  If something else needs to be
>> provided, one of the existing handlers must be extended or a new
>> handler
>> must be added.
> 
> I think my original comment was a positive one - sharing and reuse are
> good and sometimes it is even necessary. Making each handler to define
> its proprietary "context" prevents sharing and reuse, which is
> undesirable. As I mentioned earlier, if the isolation is required, the
> proprietary contexts can still be defined to achieve that. But I think
> most cases, we simply want to have an existing generic context to be
> provided and use it.
> 
Thanks for the clarification.  If handlers want to share information,
they can create shared context (not the same as the "application context")
to do this.  I think it's undesirable to overload the purpose of the
"application context" by also using it to share state between handlers.
This exposes things to the application that are intended for handler use
rather than for application use, which isn't desirable IMO.

   Simon

> --- cut ---
> 
> Gang
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> 
> 
> 

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

To make it more readable, some text is cut.

... cut ...
> >
> > The drawback of this approach is that it does not abstract and
> promote
> > reuse. Each handler and/or component implementation is required to
> > develop its own context object and injection extension while an
> > abstraction, such as a map<String, Object>, could satisfy most
> demands
> > and be reused.
> >
> The "data transfer/context" objects would be developed and created by
> handlers and used by component implementations.  There's no need for
> any injection extensions as the Tuscany runtime would take care of
> that.
> 
> One problem with Map<String, Object> is that different handlers could
> collide with each other if they happen to use the same String keys
> for entries in the Map.  Also this type definition isn't sufficiently
> unique to allow the type-driven Tuscany injection mechanism to
function
> correctly.

The key collision can be remedied by using hierarchically qualified key
names, such as "org.apache.tuscany.axis2-binding.XXX", which makes
collision unlikely. In my scheme, the entire application context object
(a single one of type say ApplicationContext), which is implemented
using Map<String, Object>, is injected into the component implementation
and let the component implementation to get what it wants and ignore
those it doesn't care. I don't see how it would cause injection
difficulty.

> 
> > The shared general context also promote sharing. For example, in
JAX-
> WS
> > framework, certain WS-* related properties that are put in by the
> > underlying JAX-WS framework provider or other handlers can and are
> used
> > in our WS-Security implementation. It promotes reuse. In some case
> the
> > information that are put in the context by the framework or other
> > handlers is not obtainable by our WS-security handlers because of
the
> > phrases and layers differences.
> >
> I think this supports my reservations about a shared context.  By
> requiring each handler to define specifically what state it makes
> available to the application, it is always clear what information
> will be available, based on the combination of handlers (policy sets)
> attached to a service or reference.  If something else needs to be
> provided, one of the existing handlers must be extended or a new
> handler
> must be added.

I think my original comment was a positive one - sharing and reuse are
good and sometimes it is even necessary. Making each handler to define
its proprietary "context" prevents sharing and reuse, which is
undesirable. As I mentioned earlier, if the isolation is required, the
proprietary contexts can still be defined to achieve that. But I think
most cases, we simply want to have an existing generic context to be
provided and use it.

--- cut ---

Gang

Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> A general comment I would put here is that software design is an art and
> it will reflect different approaches depends on where your emphasizes
> are. My philosophy that lead to what I described is simplicity,
> abstraction and reuse. But I'm fine with and would appreciate any design
> that would allow me to do the WS-Security. My specific comments follow.
> 
Yes, it is an art, and email definitely isn't the best medium for
artists to communicate with each other and reach a creative meeting
of minds :-(  We are both trying our best, but it would be much
easier face-to-face over a suitable beverage :-)

My other comments are inline below.

   Simon

> Thanks,
> Gang 
> 
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org]
>> Sent: Monday, February 07, 2011 1:09 PM
>> To: dev@tuscany.apache.org
>> Subject: Re: Can application code and interceptor/handler code in
>> Tuscany communicate with each other via some context? (UNCLASSIFIED)
>>
>> See comments inline below.
>>
>>    Simon
>>
>> Yang, Gang CTR US USA wrote:
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>> Some very good discussions here.
>>>
>>> I think I agree with Simon N.'s point that the component
>> implementation
>>> should be restricted to only certain "application" level
> information.
>>> But I definitely agree with Simon L. that passing only disconnected
>> Message
>>> (the reason I said disconnected is because the service
>> interceptors/handlers
>>> are provided with different Message object than that the reference
>>> interceptors/handlers, same is true for before and after invoke) is
>> not enough.
>>> There's no need to restrict the interceptors in general. The
> "general
>> context"
>>> only promotes reuse and collaboration.
>>  >
>> With the change to "switching" that I am proposing, the reference
>> interceptors/
>> handlers would see both the inbound message to the service and the
>> outbound
>> message (under construction) for the reference invocation.  They would
>> also see
>> the application's "data transfer" object.  I think that's sufficient.
> 
> I prefer the term "context" over "data transfer". We are not overloading
> this term, in the context of our discussion, which is to share states
> among various codes during a specific invocation and message processing,
> it is referred to as "context" in other frameworks and specs. 
> 
That's fine, and we will probably end up using the term "context",
but for the present discussion I was concerned that the word "context"
could be creating different expectations because of implicit parallels
with other kinds of context, for example the contexts defined by Axis2
and JAX-WS.

>>> How does this sound, which has been modeled by some other
> frameworks,
>> such as
>>> JAX-WS, and the discussion seems to have hinted. Instead of having a
>> single
>>> context, we can have multiple, which are classified and can be
>> hierarchical.
>>> One for system level, which would includes all message contexts
>> involved in a
>>> invocation including service and possible references, inbound and
>> outbound.
>>  > This one is only accessible by interceptors and handlers.
>> A multi-level hierarchy would only be available if all invocations
> were
>> local.  For the normal remote case, the only context available would
> be
>> the inbound message for a service dispatch and the outbound message
> for
>> the current reference invocation.  I don't think we need more than
>> this.
> 
> I don't think I was suggesting remote cases although Tuscany is claimed
> to be a distributed framework. I qualified the "context" to be bound by
> a single component method invocation. This means the inbound service and
> the possible outbound references, not including the targeted services of
> the references.
> 
OK, then we have the same expectation about this.

>> For example, if method A invokes method B and then method C, I don't
>> see
>> any reason for the interceptors/handlers for C's invocation to see
>> information relating to the earlier invocation of B.
> 
> The philosophy here is to take what you need and ignore what you don't.
> Don't forget, runtime itself is also operating in the same context and
> could make use of this context object, too.
>
The runtime already has what it needs in the form of the current
inbound message and the current outbound message.  It doesn't
retain a previous outbound message after the invocation has finished,
and I don't see any reason or use case for adding this.

>>  > A second one for application level, which can be a sub-context of
>> the
>>  > system context and can also be accessed by the component
>> implementation
>>  > as well as by interceptors of course.
>>  >
>> By this I presume you mean a generic application context.  I think
> it's
>> better to require handlers/interceptors to create the specific "data
>> transfer"
>> object that they need to exchange information with the application.
>> There
>> could be multiple independently developed handlers/interceptors
>> involved in
>> an invocation and I think this approach is simpler and cleaner than
>> having
>> all the handlers/interceptors reading from and writing to the same
>> application
>> context object.  This approach also avoids the need to invent any new
>> Tuscany
>> APIs to provide access to a generic Tuscany application context.
> 
> The drawback of this approach is that it does not abstract and promote
> reuse. Each handler and/or component implementation is required to
> develop its own context object and injection extension while an
> abstraction, such as a map<String, Object>, could satisfy most demands
> and be reused. 
> 
The "data transfer/context" objects would be developed and created by
handlers and used by component implementations.  There's no need for
any injection extensions as the Tuscany runtime would take care of that.

One problem with Map<String, Object> is that different handlers could
collide with each other if they happen to use the same String keys
for entries in the Map.  Also this type definition isn't sufficiently
unique to allow the type-driven Tuscany injection mechanism to function
correctly.

> The shared general context also promote sharing. For example, in JAX-WS
> framework, certain WS-* related properties that are put in by the
> underlying JAX-WS framework provider or other handlers can and are used
> in our WS-Security implementation. It promotes reuse. In some case the
> information that are put in the context by the framework or other
> handlers is not obtainable by our WS-security handlers because of the
> phrases and layers differences.
> 
I think this supports my reservations about a shared context.  By
requiring each handler to define specifically what state it makes
available to the application, it is always clear what information
will be available, based on the combination of handlers (policy sets)
attached to a service or reference.  If something else needs to be
provided, one of the existing handlers must be extended or a new handler
must be added.

> The proprietary extension mechanism is useful an could be used if
> isolation is required.
> 
>>> Both system and application context should be invocation bound. By
>> this
>>  > I mean they include only contexts (Messages, sub-context) that are
>> related
>>  > to a single component method invocation and accessed only by those
>>  > interceptors, handlers and the component implementation
> (application
>> context
>>  > only) associated with the invocation of that component method at
> the
>> time
>>  > of invocation. This is due to the consideration of multi-threading.
>> Agreed.
>>
>>> Because the application context is injected to the component
>> implementation
>>> prior to the execution of any method invocation, the framework
> should
>> make
>>> sure that the content of the application context is made available
> to
>> the
>>> component implementation only during the execution of the component
>> method.
>>> This can be tricky because of the multi-threading. Synchronization
>> may
>>> be necessary.
>>>
>> I'm concerned by the complexity involved in this.  My suggested
>> approach
>> using "data transfer" objects avoids this issue because these are just
>> regular objects and it wouldn't matter if the application passed them
>> around.
> 
> Agree that we always need to consider the effort and if it makes sense,
> especially if we are talking about Tuscany 1.x. You guys are exports
> here and I'm only providing my opinion and would appreciate your help.
> 
Your opinions are very much appreciated.  Thanks for taking the time and
trouble to engage in these discussions and explain your perspective.

I think if we add some new mechanism then it should be available in
both Tuscany 1.x and 2.x.  I'm personally more familiar with 1.x in
terms of the implementation considerations, but others following this
discussion will be able to comment on the 2.x implications.

   Simon

>>> Another comment on the user-defined context. I have no objection to
>>  > allowing users to define their contexts and even to extend the
>> injection.
>>  > But with a generic application context to allow reuse, that
>> extension
>>  > is probably for specialized scenarios.
>> See my comments above on this.
>>
>>    Simon
> 
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> 
> 
> 

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

A general comment I would put here is that software design is an art and
it will reflect different approaches depends on where your emphasizes
are. My philosophy that lead to what I described is simplicity,
abstraction and reuse. But I'm fine with and would appreciate any design
that would allow me to do the WS-Security. My specific comments follow.

Thanks,
Gang 

> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Monday, February 07, 2011 1:09 PM
> To: dev@tuscany.apache.org
> Subject: Re: Can application code and interceptor/handler code in
> Tuscany communicate with each other via some context? (UNCLASSIFIED)
> 
> See comments inline below.
> 
>    Simon
> 
> Yang, Gang CTR US USA wrote:
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> > Some very good discussions here.
> >
> > I think I agree with Simon N.'s point that the component
> implementation
> > should be restricted to only certain "application" level
information.
> > But I definitely agree with Simon L. that passing only disconnected
> Message
> > (the reason I said disconnected is because the service
> interceptors/handlers
> > are provided with different Message object than that the reference
> > interceptors/handlers, same is true for before and after invoke) is
> not enough.
> > There's no need to restrict the interceptors in general. The
"general
> context"
> > only promotes reuse and collaboration.
>  >
> With the change to "switching" that I am proposing, the reference
> interceptors/
> handlers would see both the inbound message to the service and the
> outbound
> message (under construction) for the reference invocation.  They would
> also see
> the application's "data transfer" object.  I think that's sufficient.

I prefer the term "context" over "data transfer". We are not overloading
this term, in the context of our discussion, which is to share states
among various codes during a specific invocation and message processing,
it is referred to as "context" in other frameworks and specs. 

> 
> > How does this sound, which has been modeled by some other
frameworks,
> such as
> > JAX-WS, and the discussion seems to have hinted. Instead of having a
> single
> > context, we can have multiple, which are classified and can be
> hierarchical.
> > One for system level, which would includes all message contexts
> involved in a
> > invocation including service and possible references, inbound and
> outbound.
>  > This one is only accessible by interceptors and handlers.
> >
> A multi-level hierarchy would only be available if all invocations
were
> local.  For the normal remote case, the only context available would
be
> the inbound message for a service dispatch and the outbound message
for
> the current reference invocation.  I don't think we need more than
> this.

I don't think I was suggesting remote cases although Tuscany is claimed
to be a distributed framework. I qualified the "context" to be bound by
a single component method invocation. This means the inbound service and
the possible outbound references, not including the targeted services of
the references.

> For example, if method A invokes method B and then method C, I don't
> see
> any reason for the interceptors/handlers for C's invocation to see
> information relating to the earlier invocation of B.

The philosophy here is to take what you need and ignore what you don't.
Don't forget, runtime itself is also operating in the same context and
could make use of this context object, too.

> 
>  > A second one for application level, which can be a sub-context of
> the
>  > system context and can also be accessed by the component
> implementation
>  > as well as by interceptors of course.
>  >
> By this I presume you mean a generic application context.  I think
it's
> better to require handlers/interceptors to create the specific "data
> transfer"
> object that they need to exchange information with the application.
> There
> could be multiple independently developed handlers/interceptors
> involved in
> an invocation and I think this approach is simpler and cleaner than
> having
> all the handlers/interceptors reading from and writing to the same
> application
> context object.  This approach also avoids the need to invent any new
> Tuscany
> APIs to provide access to a generic Tuscany application context.

The drawback of this approach is that it does not abstract and promote
reuse. Each handler and/or component implementation is required to
develop its own context object and injection extension while an
abstraction, such as a map<String, Object>, could satisfy most demands
and be reused. 

The shared general context also promote sharing. For example, in JAX-WS
framework, certain WS-* related properties that are put in by the
underlying JAX-WS framework provider or other handlers can and are used
in our WS-Security implementation. It promotes reuse. In some case the
information that are put in the context by the framework or other
handlers is not obtainable by our WS-security handlers because of the
phrases and layers differences.

The proprietary extension mechanism is useful an could be used if
isolation is required.

> 
> > Both system and application context should be invocation bound. By
> this
>  > I mean they include only contexts (Messages, sub-context) that are
> related
>  > to a single component method invocation and accessed only by those
>  > interceptors, handlers and the component implementation
(application
> context
>  > only) associated with the invocation of that component method at
the
> time
>  > of invocation. This is due to the consideration of multi-threading.
> >
> Agreed.
> 
> > Because the application context is injected to the component
> implementation
> > prior to the execution of any method invocation, the framework
should
> make
> > sure that the content of the application context is made available
to
> the
> > component implementation only during the execution of the component
> method.
> > This can be tricky because of the multi-threading. Synchronization
> may
> > be necessary.
> >
> I'm concerned by the complexity involved in this.  My suggested
> approach
> using "data transfer" objects avoids this issue because these are just
> regular objects and it wouldn't matter if the application passed them
> around.

Agree that we always need to consider the effort and if it makes sense,
especially if we are talking about Tuscany 1.x. You guys are exports
here and I'm only providing my opinion and would appreciate your help.

> 
> > Another comment on the user-defined context. I have no objection to
>  > allowing users to define their contexts and even to extend the
> injection.
>  > But with a generic application context to allow reuse, that
> extension
>  > is probably for specialized scenarios.
> >
> See my comments above on this.
> 
>    Simon


Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

See comments inline below.

   Simon

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> Some very good discussions here.
> 
> I think I agree with Simon N.'s point that the component implementation
> should be restricted to only certain "application" level information.
> But I definitely agree with Simon L. that passing only disconnected Message
> (the reason I said disconnected is because the service interceptors/handlers
> are provided with different Message object than that the reference
> interceptors/handlers, same is true for before and after invoke) is not enough.
> There's no need to restrict the interceptors in general. The "general context"
> only promotes reuse and collaboration.
 >
With the change to "switching" that I am proposing, the reference interceptors/
handlers would see both the inbound message to the service and the outbound
message (under construction) for the reference invocation.  They would also see
the application's "data transfer" object.  I think that's sufficient.

> How does this sound, which has been modeled by some other frameworks, such as
> JAX-WS, and the discussion seems to have hinted. Instead of having a single
> context, we can have multiple, which are classified and can be hierarchical.
> One for system level, which would includes all message contexts involved in a
> invocation including service and possible references, inbound and outbound.
 > This one is only accessible by interceptors and handlers.
> 
A multi-level hierarchy would only be available if all invocations were
local.  For the normal remote case, the only context available would be
the inbound message for a service dispatch and the outbound message for
the current reference invocation.  I don't think we need more than this.
For example, if method A invokes method B and then method C, I don't see
any reason for the interceptors/handlers for C's invocation to see
information relating to the earlier invocation of B.

 > A second one for application level, which can be a sub-context of the
 > system context and can also be accessed by the component implementation
 > as well as by interceptors of course.
 >
By this I presume you mean a generic application context.  I think it's
better to require handlers/interceptors to create the specific "data transfer"
object that they need to exchange information with the application.  There
could be multiple independently developed handlers/interceptors involved in
an invocation and I think this approach is simpler and cleaner than having
all the handlers/interceptors reading from and writing to the same application
context object.  This approach also avoids the need to invent any new Tuscany
APIs to provide access to a generic Tuscany application context.

> Both system and application context should be invocation bound. By this
 > I mean they include only contexts (Messages, sub-context) that are related
 > to a single component method invocation and accessed only by those
 > interceptors, handlers and the component implementation (application context
 > only) associated with the invocation of that component method at the time
 > of invocation. This is due to the consideration of multi-threading.
> 
Agreed.

> Because the application context is injected to the component implementation
> prior to the execution of any method invocation, the framework should make
> sure that the content of the application context is made available to the
> component implementation only during the execution of the component method.
> This can be tricky because of the multi-threading. Synchronization may
> be necessary.
> 
I'm concerned by the complexity involved in this.  My suggested approach
using "data transfer" objects avoids this issue because these are just
regular objects and it wouldn't matter if the application passed them
around.

> Another comment on the user-defined context. I have no objection to
 > allowing users to define their contexts and even to extend the injection.
 > But with a generic application context to allow reuse, that extension
 > is probably for specialized scenarios.
>
See my comments above on this.

   Simon

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

On Mon, Feb 7, 2011 at 4:47 PM, Yang, Gang CTR US USA
<ga...@us.army.mil> wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Some very good discussions here.
>
> I think I agree with Simon N.'s point that the component implementation should be restricted to only certain "application" level information. But I definitely agree with Simon L. that passing only disconnected Message (the reason I said disconnected is because the service interceptors/handlers are provided with different Message object than that the reference interceptors/handlers, same is true for before and after invoke) is not enough. There's no need to restrict the interceptors in general. The "general context" only promotes reuse and collaboration.
>
> How does this sound, which has been modeled by some other frameworks, such as JAX-WS, and the discussion seems to have hinted. Instead of having a single context, we can have multiple, which are classified and can be hierarchical. One for system level, which would includes all message contexts involved in a invocation including service and possible references, inbound and outbound. This one is only accessible by interceptors and handlers. A second one for application level, which can be a sub-context of the system context and can also be accessed by the component implementation as well as by interceptors of course.

Sounds like the right sort of mental model to me.

>
> Both system and application context should be invocation bound. By this I mean they include only contexts (Messages, sub-context) that are related to a single component method invocation and accessed only by those interceptors, handlers and the component implementation (application context only) associated with the invocation of that component method at the time of invocation. This is due to the consideration of multi-threading.
>
> Because the application context is injected to the component implementation prior to the execution of any method invocation, the framework should make sure that the content of the application context is made available to the component implementation only during the execution of the component method. This can be tricky because of the multi-threading. Synchronization may be necessary.

Well we would have to rely on the context object to do the thread
stuff under the covers. I think this was the thrust of the other
Simon's comment on this point.

>
> Another comment on the user-defined context. I have no objection to allowing users to define their contexts and even to extend the injection. But with a generic application context to allow reuse, that extension is probably for specialized scenarios.
>
> Thanks,
> Gang
>
>> -----Original Message-----
>> From: Simon Laws [mailto:simonslaws@googlemail.com]
>> Sent: Monday, February 07, 2011 8:33 AM
>> To: dev@tuscany.apache.org
>> Subject: Re: Can application code and interceptor/handler code in
>> Tuscany communicate with each other via some context? (UNCLASSIFIED)
>>
>> >>
>> >>
>> > 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.
>>
>> 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
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>



-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Some very good discussions here.

I think I agree with Simon N.'s point that the component implementation should be restricted to only certain "application" level information. But I definitely agree with Simon L. that passing only disconnected Message (the reason I said disconnected is because the service interceptors/handlers are provided with different Message object than that the reference interceptors/handlers, same is true for before and after invoke) is not enough. There's no need to restrict the interceptors in general. The "general context" only promotes reuse and collaboration.

How does this sound, which has been modeled by some other frameworks, such as JAX-WS, and the discussion seems to have hinted. Instead of having a single context, we can have multiple, which are classified and can be hierarchical. One for system level, which would includes all message contexts involved in a invocation including service and possible references, inbound and outbound. This one is only accessible by interceptors and handlers. A second one for application level, which can be a sub-context of the system context and can also be accessed by the component implementation as well as by interceptors of course.

Both system and application context should be invocation bound. By this I mean they include only contexts (Messages, sub-context) that are related to a single component method invocation and accessed only by those interceptors, handlers and the component implementation (application context only) associated with the invocation of that component method at the time of invocation. This is due to the consideration of multi-threading. 

Because the application context is injected to the component implementation prior to the execution of any method invocation, the framework should make sure that the content of the application context is made available to the component implementation only during the execution of the component method. This can be tricky because of the multi-threading. Synchronization may be necessary.

Another comment on the user-defined context. I have no objection to allowing users to define their contexts and even to extend the injection. But with a generic application context to allow reuse, that extension is probably for specialized scenarios. 

Thanks,
Gang

> -----Original Message-----
> From: Simon Laws [mailto:simonslaws@googlemail.com]
> Sent: Monday, February 07, 2011 8:33 AM
> To: dev@tuscany.apache.org
> Subject: Re: Can application code and interceptor/handler code in
> Tuscany communicate with each other via some context? (UNCLASSIFIED)
> 
> >>
> >>
> > 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.
> 
> 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
> 
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

>>
>>
> 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.

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

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Simon Laws wrote:
> On Mon, Feb 7, 2011 at 10:26 AM, Simon Nash <na...@apache.org> wrote:
>> Simon Laws wrote:
>>> Hi Gang
>>>
>>>> I'm wondering how much work it would be to simply pass a generic context
>>>> object, which includes all the  current messages involved in the
>>>> invocation and allow get/set objects as added states, through all
>>>> interceptors/handler and also inject it into component implementation if
>>>> requested. Wouldn't it be simpler conceptually?
>>>>
>>> I think that's the conclusion that I'm coming to also so instead of
>>> (or as well as if we can't unpick it) having a ThreadMessageContext
>>> have a ThreadContext that contains service message (and reference
>>> message if required).
>>>
>>> Regards
>>>
>>> Simon
>>>
>> I'd prefer something like Raymond's proposal.  Here's how I think it
>> would work in a bit more detail:
>>
>>  1. The beforeHandler for a service invocation Foo creates an object
>>    containing information that it wants to make available to the
>>    application Foo method.  Let's suppose that this object is of
>>    type com.myappl.MyInfo.
>>
>>  2. The handler calls a Tuscany API to add the MyInfo object to the
>>    invocation context for request Foo.  The invocation context is
>>    similar to the thread message context but it has a different
>>    lifecycle (see steps 6 and 10 below).
>>
>>  3. The application code uses the @Context annotation (or possibly the
>>    JSR 250 @Resource annotation) on a field of type com.myappl.MyInfo.
>>
>>  4. When the component implementation instance is created, the Tuscany
>>    runtime injects the MyInfo object from the invocation context.
>>
>>    Note: This doesn't work for multithreaded COMPOSITE-scoped component
>>    implementations.  Support for this could be provided by allowing
>>    the injection of ThreadLocal<MyInfo> into the application code.
>>    The Foo implementation method would call get() on the injected
>>    ThreadLocal<MyInfo> object to access the MyInfo object belonging to
>>    the currently executing thread.
>>
>>  5. The application implementation's Foo method can get data from the
>>    injected MyInfo object and can also put data into the same
>>    MyInfo object.
>>
>>  6. The application implementation's Foo method makes a reference
>>    invocation Bar.  This creates a new message context for Bar but
>>    it doesn't change the invocation context.
>>
>>  7. The beforeHandler for the Bar reference invocation is called.
>>    This calls a Tuscany API to get the MyInfo object out of the
>>    Foo invocation context.  This allows the handler to access data
>>    that the application has put into the MyInfo object in step 5.
>>
>>  8. The Bar reference invocation returns and its afterHandler is called.
>>    This handler has access to the Foo invocation context and the same
>>    MyInfo object.
>>
>>  9. Eventually the Foo request completes and the afterHandler for the
>>    Foo service invocation is called.  This handler has access to
>>    the Foo invocation context and the same MyInfo object.
>>
>> 10. On completion of the afterHandler for the Foo service invocation,
>>    the MyInfo object is freed up for garbage collection.
>>
>> I think this is lot cleaner than having a Tuscany-defined generic
>> context object containing all the message contents (inbound and outbound).
>> It allows the handlers to control exactly what information is made
>> available to application code, and it doesn't require application code
>> to reference a Tuscany-specific generic context class.
>>
>>  Simon
>>
>>
> 
> How does "Tuscany-defined generic context" (by which I meant for an
> invocation/thread) differ from and "invocation context"?
> 
> Simon
> 
> 
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

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

On Mon, Feb 7, 2011 at 10:26 AM, Simon Nash <na...@apache.org> wrote:
> Simon Laws wrote:
>>
>> Hi Gang
>>
>>> I'm wondering how much work it would be to simply pass a generic context
>>> object, which includes all the  current messages involved in the
>>> invocation and allow get/set objects as added states, through all
>>> interceptors/handler and also inject it into component implementation if
>>> requested. Wouldn't it be simpler conceptually?
>>>
>>
>> I think that's the conclusion that I'm coming to also so instead of
>> (or as well as if we can't unpick it) having a ThreadMessageContext
>> have a ThreadContext that contains service message (and reference
>> message if required).
>>
>> Regards
>>
>> Simon
>>
> I'd prefer something like Raymond's proposal.  Here's how I think it
> would work in a bit more detail:
>
>  1. The beforeHandler for a service invocation Foo creates an object
>    containing information that it wants to make available to the
>    application Foo method.  Let's suppose that this object is of
>    type com.myappl.MyInfo.
>
>  2. The handler calls a Tuscany API to add the MyInfo object to the
>    invocation context for request Foo.  The invocation context is
>    similar to the thread message context but it has a different
>    lifecycle (see steps 6 and 10 below).
>
>  3. The application code uses the @Context annotation (or possibly the
>    JSR 250 @Resource annotation) on a field of type com.myappl.MyInfo.
>
>  4. When the component implementation instance is created, the Tuscany
>    runtime injects the MyInfo object from the invocation context.
>
>    Note: This doesn't work for multithreaded COMPOSITE-scoped component
>    implementations.  Support for this could be provided by allowing
>    the injection of ThreadLocal<MyInfo> into the application code.
>    The Foo implementation method would call get() on the injected
>    ThreadLocal<MyInfo> object to access the MyInfo object belonging to
>    the currently executing thread.
>
>  5. The application implementation's Foo method can get data from the
>    injected MyInfo object and can also put data into the same
>    MyInfo object.
>
>  6. The application implementation's Foo method makes a reference
>    invocation Bar.  This creates a new message context for Bar but
>    it doesn't change the invocation context.
>
>  7. The beforeHandler for the Bar reference invocation is called.
>    This calls a Tuscany API to get the MyInfo object out of the
>    Foo invocation context.  This allows the handler to access data
>    that the application has put into the MyInfo object in step 5.
>
>  8. The Bar reference invocation returns and its afterHandler is called.
>    This handler has access to the Foo invocation context and the same
>    MyInfo object.
>
>  9. Eventually the Foo request completes and the afterHandler for the
>    Foo service invocation is called.  This handler has access to
>    the Foo invocation context and the same MyInfo object.
>
> 10. On completion of the afterHandler for the Foo service invocation,
>    the MyInfo object is freed up for garbage collection.
>
> I think this is lot cleaner than having a Tuscany-defined generic
> context object containing all the message contents (inbound and outbound).
> It allows the handlers to control exactly what information is made
> available to application code, and it doesn't require application code
> to reference a Tuscany-specific generic context class.
>
>  Simon
>
>

How does "Tuscany-defined generic context" (by which I meant for an
invocation/thread) differ from and "invocation context"?

Simon


-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Simon Laws wrote:
> Hi Gang
> 
>> I'm wondering how much work it would be to simply pass a generic context
>> object, which includes all the  current messages involved in the
>> invocation and allow get/set objects as added states, through all
>> interceptors/handler and also inject it into component implementation if
>> requested. Wouldn't it be simpler conceptually?
>>
> 
> I think that's the conclusion that I'm coming to also so instead of
> (or as well as if we can't unpick it) having a ThreadMessageContext
> have a ThreadContext that contains service message (and reference
> message if required).
> 
> Regards
> 
> Simon
> 
I'd prefer something like Raymond's proposal.  Here's how I think it
would work in a bit more detail:

  1. The beforeHandler for a service invocation Foo creates an object
     containing information that it wants to make available to the
     application Foo method.  Let's suppose that this object is of
     type com.myappl.MyInfo.

  2. The handler calls a Tuscany API to add the MyInfo object to the
     invocation context for request Foo.  The invocation context is
     similar to the thread message context but it has a different
     lifecycle (see steps 6 and 10 below).

  3. The application code uses the @Context annotation (or possibly the
     JSR 250 @Resource annotation) on a field of type com.myappl.MyInfo.

  4. When the component implementation instance is created, the Tuscany
     runtime injects the MyInfo object from the invocation context.

     Note: This doesn't work for multithreaded COMPOSITE-scoped component
     implementations.  Support for this could be provided by allowing
     the injection of ThreadLocal<MyInfo> into the application code.
     The Foo implementation method would call get() on the injected
     ThreadLocal<MyInfo> object to access the MyInfo object belonging to
     the currently executing thread.

  5. The application implementation's Foo method can get data from the
     injected MyInfo object and can also put data into the same
     MyInfo object.

  6. The application implementation's Foo method makes a reference
     invocation Bar.  This creates a new message context for Bar but
     it doesn't change the invocation context.

  7. The beforeHandler for the Bar reference invocation is called.
     This calls a Tuscany API to get the MyInfo object out of the
     Foo invocation context.  This allows the handler to access data
     that the application has put into the MyInfo object in step 5.

  8. The Bar reference invocation returns and its afterHandler is called.
     This handler has access to the Foo invocation context and the same
     MyInfo object.

  9. Eventually the Foo request completes and the afterHandler for the
     Foo service invocation is called.  This handler has access to
     the Foo invocation context and the same MyInfo object.

10. On completion of the afterHandler for the Foo service invocation,
     the MyInfo object is freed up for garbage collection.

I think this is lot cleaner than having a Tuscany-defined generic
context object containing all the message contents (inbound and outbound).
It allows the handlers to control exactly what information is made
available to application code, and it doesn't require application code
to reference a Tuscany-specific generic context class.

   Simon

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

Hi Gang

>
> I'm wondering how much work it would be to simply pass a generic context
> object, which includes all the  current messages involved in the
> invocation and allow get/set objects as added states, through all
> interceptors/handler and also inject it into component implementation if
> requested. Wouldn't it be simpler conceptually?
>

I think that's the conclusion that I'm coming to also so instead of
(or as well as if we can't unpick it) having a ThreadMessageContext
have a ThreadContext that contains service message (and reference
message if required).

Regards

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Hi, Raymond,

I assume you are talking about future enhancement, which is not yet
available in 1.6.x, right? 

I can see this would allow handlers to pass information into component
implementation using Message as the vehicle with the help of the
injection extension. But how about passing information from component
implementation to the downstream handlers?

I'm wondering how much work it would be to simply pass a generic context
object, which includes all the  current messages involved in the
invocation and allow get/set objects as added states, through all
interceptors/handler and also inject it into component implementation if
requested. Wouldn't it be simpler conceptually?

Thanks,
Gang

> -----Original Message-----
> From: Raymond Feng [mailto:enjoyjava@gmail.com]
> Sent: Friday, February 04, 2011 12:42 PM
> To: dev@tuscany.apache.org
> Subject: Re: Can application code and interceptor/handler code in
> Tuscany communicate with each other via some context? (UNCLASSIFIED)
> 
> Another idea to explore:
> 
> 1) SCA already has the @Context annotation which allows the
application
> code to be injected with certain context. Tuscany could potentially
> extend that to allow pluggable contexts. This could be similar to what
> JAX-RS does.
> 
> for example:
> 
> @Context
> private MyContext myContext;
> 
> 
> 2) The policy handler can put some information into the Message header
> 3) Tuscany allows you to add extensions to the Dependency Injection
> code to inject the value into the target implementation instance.
> 
> 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 Feb 4, 2011, at 9:28 AM, Yang, Gang CTR US USA wrote:
> 
> 
> 	Classification: UNCLASSIFIED
> 	Caveats: NONE
> 
> 	Response follows.
> 
> 	Gang
> 
> 
> 
> 		-----Original Message-----
> 
> 
> 		From: Simon Nash [mailto:nash@apache.org]
> 
> 
> 		Sent: Friday, February 04, 2011 12:00 PM
> 
> 
> 		To: dev@tuscany.apache.org
> 
> 
> 		Subject: Re: Can application code and
interceptor/handler
> code in
> 
> 
> 		Tuscany communicate with each other via some context?
> (UNCLASSIFIED)
> 
> 
> 
> 		Yang, Gang CTR US USA wrote:
> 
> 
> 			Classification: UNCLASSIFIED
> 
> 
> 			Caveats: NONE
> 
> 
> 
> 			(cut)
> 
> 
> 
> 			Thanks! It's clear now. I looked up
RequestContext
> (don't know why I
> 
> 
> 			missed it earlier). It does not seem to support
> general state
> 
> 
> 			propagation - I can set/get arbitrary objects.
Can
> this be opened up
> 
> 
> 		to
> 
> 
> 			allow arbitrary object states?
> 
> 
> 
> 		Tuscany can't add any methods to this API because it's
> defined by SCA.
> 
> 
> 
> 		Tuscany could add some other API to propagate arbitrary
> state but this
> 
> 
> 		would be a major departure from the philosophy of SCA
and I
> would have
> 
> 
> 		serious reservations about this.
> 
> 
> 
> 		However, the Java ThreadLocal class should enable you to
do
> what you
> 
> 
> 		need.
> 
> 
> 		You can add an object to Java thead-local state in your
> inbound
> 
> 
> 		handler,
> 
> 
> 		access or update this object (or add more objects) in
your
> application
> 
> 
> 		code, and use the results in your outbound handler.
> 
> 
> 
> 	I'm not sure about using ThreadLocal in a service framework
> environment
> 	for component implementation or even user-added handlers since I
> don't
> 	know how the framework manages the threads.
> 
> 	Gang
> 
> 
> 
> 
> 		  Simon
> 
> 
> 
> 			Gang
> 
> 
> 
> 				  Simon
> 
> 
> 
> 					  Simon
> 
> 
> 
> 					Classification: UNCLASSIFIED
> 
> 
> 					Caveats: NONE
> 
> 
> 
> 
> 
> 
> 
> 
> 			Classification: UNCLASSIFIED
> 
> 
> 			Caveats: NONE
> 
> 
> 
> 
> 
> 
> 
> 
> 	Classification: UNCLASSIFIED
> 	Caveats: NONE
> 
> 
> 
> 


Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Raymond Feng <en...@gmail.com>]

Another idea to explore:

1) SCA already has the @Context annotation which allows the application code to be injected with certain context. Tuscany could potentially extend that to allow pluggable contexts. This could be similar to what JAX-RS does. 

for example:

@Context 
private MyContext myContext;


2) The policy handler can put some information into the Message header
3) Tuscany allows you to add extensions to the Dependency Injection code to inject the value into the target implementation instance.

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 Feb 4, 2011, at 9:28 AM, Yang, Gang CTR US USA wrote:

> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> Response follows.
> 
> Gang
> 
>> -----Original Message-----
>> From: Simon Nash [mailto:nash@apache.org]
>> Sent: Friday, February 04, 2011 12:00 PM
>> To: dev@tuscany.apache.org
>> Subject: Re: Can application code and interceptor/handler code in
>> Tuscany communicate with each other via some context? (UNCLASSIFIED)
>> 
>> Yang, Gang CTR US USA wrote:
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>> 
>>> (cut)
>>> 
>>> Thanks! It's clear now. I looked up RequestContext (don't know why I
>>> missed it earlier). It does not seem to support general state
>>> propagation - I can set/get arbitrary objects. Can this be opened up
>> to
>>> allow arbitrary object states?
>>> 
>> Tuscany can't add any methods to this API because it's defined by SCA.
>> 
>> Tuscany could add some other API to propagate arbitrary state but this
>> would be a major departure from the philosophy of SCA and I would have
>> serious reservations about this.
>> 
>> However, the Java ThreadLocal class should enable you to do what you
>> need.
>> You can add an object to Java thead-local state in your inbound
>> handler,
>> access or update this object (or add more objects) in your application
>> code, and use the results in your outbound handler.
> 
> I'm not sure about using ThreadLocal in a service framework environment
> for component implementation or even user-added handlers since I don't
> know how the framework manages the threads.
> 
> Gang
> 
>> 
>>   Simon
>> 
>>> Gang
>>> 
>>>>   Simon
>>>> 
>>>>>   Simon
>>>>> 
>>>>> Classification: UNCLASSIFIED
>>>>> Caveats: NONE
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>> 
>>> 
>>> 
>>> 
> 
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> 

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Response follows.

Gang

> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Friday, February 04, 2011 12:00 PM
> To: dev@tuscany.apache.org
> Subject: Re: Can application code and interceptor/handler code in
> Tuscany communicate with each other via some context? (UNCLASSIFIED)
> 
> Yang, Gang CTR US USA wrote:
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
>  > (cut)
> >
> > Thanks! It's clear now. I looked up RequestContext (don't know why I
> > missed it earlier). It does not seem to support general state
> > propagation - I can set/get arbitrary objects. Can this be opened up
> to
> > allow arbitrary object states?
> >
> Tuscany can't add any methods to this API because it's defined by SCA.
> 
> Tuscany could add some other API to propagate arbitrary state but this
> would be a major departure from the philosophy of SCA and I would have
> serious reservations about this.
> 
> However, the Java ThreadLocal class should enable you to do what you
> need.
> You can add an object to Java thead-local state in your inbound
> handler,
> access or update this object (or add more objects) in your application
> code, and use the results in your outbound handler.

I'm not sure about using ThreadLocal in a service framework environment
for component implementation or even user-added handlers since I don't
know how the framework manages the threads.

Gang

> 
>    Simon
> 
> > Gang
> >
> >>    Simon
> >>
> >>>    Simon
> >>>
> >>> Classification: UNCLASSIFIED
> >>> Caveats: NONE
> >>>
> >>>
> >>>
> >>>
> >
> >
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> >
> >
> >


Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Laws <si...@googlemail.com>]

>
> However, the Java ThreadLocal class should enable you to do what you need.
> You can add an object to Java thead-local state in your inbound handler,
> access or update this object (or add more objects) in your application
> code, and use the results in your outbound handler.
>
>  Simon

And maybe we need to make both service and refer message available in
this way if the reference on is really required.

Simon



-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
 > (cut)
> 
> Thanks! It's clear now. I looked up RequestContext (don't know why I
> missed it earlier). It does not seem to support general state
> propagation - I can set/get arbitrary objects. Can this be opened up to
> allow arbitrary object states?
> 
Tuscany can't add any methods to this API because it's defined by SCA.

Tuscany could add some other API to propagate arbitrary state but this
would be a major departure from the philosophy of SCA and I would have
serious reservations about this.

However, the Java ThreadLocal class should enable you to do what you need.
You can add an object to Java thead-local state in your inbound handler,
access or update this object (or add more objects) in your application
code, and use the results in your outbound handler.

   Simon

> Gang
> 
>>    Simon
>>
>>>    Simon
>>>
>>> Classification: UNCLASSIFIED
>>> Caveats: NONE
>>>
>>>
>>>
>>>
> 
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> 
> 
> 

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Response follows - liked the ">" prefix styling.

Gang

> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org]
> Sent: Friday, February 04, 2011 10:40 AM
> To: dev@tuscany.apache.org
> Subject: Re: Can application code and interceptor/handler code in
> Tuscany communicate with each other via some context? (UNCLASSIFIED)
> 
> Yang, Gang CTR US USA wrote:
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> > Response preceded by "GY:".
> >
> > Gang
> >
> > -----Original Message-----
> > From: Simon Nash [mailto:nash@apache.org]
> > Sent: Friday, February 04, 2011 6:17 AM
> > To: dev@tuscany.apache.org
> > Subject: Re: Can application code and interceptor/handler code in
> > Tuscany communicate with each other via some context? (UNCLASSIFIED)
> >
> > See responses below.  I've removed older discussion to make this
> > easier to follow.
> >
> >    Simon
> >
> > Yang, Gang CTR US USA wrote:
> >> Classification: UNCLASSIFIED
> >> Caveats: NONE
> >>
> >  > (cut)
> >> GY: The use case applies to SCA well. When a new service is
> developed
> >> referencing other existing services. The authorization is best done
> in
> > a
> >> distributed fashion - the information owning service makes the
> >> authorization decision based on its existing policies. This means
> that
> >> when a client access this new service with its credential, this
> >> credential (in the form of some security token, say SAML) would
need
> > to
> >> be passed to the other existing services for authorization.
> Translated
> >> to SCA view, the handler for the service WS binding needs to pass
> the
> >> user credential to the handler for the reference WS binding. Since
> the
> >> two handlers does not have any direct relation, this is done (in
> other
> >> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new
> service
> >> implementation code which connects the service (inbound from the
> > client)
> >> to the reference (outbound to other services).
> >>
> > In SCA there's a getSecuritySubject() method on the RequestContext
> API.
> > This is implemented by putting a Subject header in the
> > ThreadMessageContext.
> > This header is added by the service binding handler and would be
> > available
> > to the reference binding handler.  Does this do what you need?
> >
> > GY: Can you elaborate a little on this RequestContext API? I could
> not
> > find RequestContext interface/class from 1.6.1 source. I did find
> > ThreadMessageContext interface, which only deals with Message. Is
> > Message in Tuscany implementing the message context concept? How is
> it
> > accessed from PolicyHandler and from the client/service application
> > code?
> >
> The RequestContext interface is in the sca-api module.  It's defined
> by the SCA specification.  To use it, you need to add code like the
> following to your component implementation:
> 
>   @Context
>   RequestContext context.
> 
>   ....
> 
>   mySubject = context.getSecuritySubject();
> 
> In Tuscany, the RequestContextImpl class implements this SCA API.
> 
> The ThreadMessageContext is used by Tuscany to hold information
> relating to the current (inbound or outbound) invocation.  It's
> accessible to Tuscany runtime code (including policy handlers)
> and Simon L's post showed how to do this, but it shouldn't be
> used by application business logic.
> 

Thanks! It's clear now. I looked up RequestContext (don't know why I
missed it earlier). It does not seem to support general state
propagation - I can set/get arbitrary objects. Can this be opened up to
allow arbitrary object states?

Gang

>    Simon
> 
> >    Simon
> >
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> >
> >
> >
> >


Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> Response preceded by "GY:".
> 
> Gang
> 
> -----Original Message-----
> From: Simon Nash [mailto:nash@apache.org] 
> Sent: Friday, February 04, 2011 6:17 AM
> To: dev@tuscany.apache.org
> Subject: Re: Can application code and interceptor/handler code in
> Tuscany communicate with each other via some context? (UNCLASSIFIED)
> 
> See responses below.  I've removed older discussion to make this
> easier to follow.
> 
>    Simon
> 
> Yang, Gang CTR US USA wrote:
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>  > (cut)
>> GY: The use case applies to SCA well. When a new service is developed
>> referencing other existing services. The authorization is best done in
> a
>> distributed fashion - the information owning service makes the
>> authorization decision based on its existing policies. This means that
>> when a client access this new service with its credential, this
>> credential (in the form of some security token, say SAML) would need
> to
>> be passed to the other existing services for authorization. Translated
>> to SCA view, the handler for the service WS binding needs to pass the
>> user credential to the handler for the reference WS binding. Since the
>> two handlers does not have any direct relation, this is done (in other
>> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new service
>> implementation code which connects the service (inbound from the
> client)
>> to the reference (outbound to other services).
>>
> In SCA there's a getSecuritySubject() method on the RequestContext API.
> This is implemented by putting a Subject header in the
> ThreadMessageContext.
> This header is added by the service binding handler and would be
> available
> to the reference binding handler.  Does this do what you need?
> 
> GY: Can you elaborate a little on this RequestContext API? I could not
> find RequestContext interface/class from 1.6.1 source. I did find
> ThreadMessageContext interface, which only deals with Message. Is
> Message in Tuscany implementing the message context concept? How is it
> accessed from PolicyHandler and from the client/service application
> code?
> 
The RequestContext interface is in the sca-api module.  It's defined
by the SCA specification.  To use it, you need to add code like the
following to your component implementation:

  @Context
  RequestContext context.

  ....

  mySubject = context.getSecuritySubject();

In Tuscany, the RequestContextImpl class implements this SCA API.

The ThreadMessageContext is used by Tuscany to hold information
relating to the current (inbound or outbound) invocation.  It's
accessible to Tuscany runtime code (including policy handlers)
and Simon L's post showed how to do this, but it shouldn't be
used by application business logic.

   Simon

>    Simon
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> 
> 
> 

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

Response preceded by "GY:".

Gang

-----Original Message-----
From: Simon Nash [mailto:nash@apache.org] 
Sent: Friday, February 04, 2011 6:17 AM
To: dev@tuscany.apache.org
Subject: Re: Can application code and interceptor/handler code in
Tuscany communicate with each other via some context? (UNCLASSIFIED)

See responses below.  I've removed older discussion to make this
easier to follow.

   Simon

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
 > (cut)
> 
> GY: The use case applies to SCA well. When a new service is developed
> referencing other existing services. The authorization is best done in
a
> distributed fashion - the information owning service makes the
> authorization decision based on its existing policies. This means that
> when a client access this new service with its credential, this
> credential (in the form of some security token, say SAML) would need
to
> be passed to the other existing services for authorization. Translated
> to SCA view, the handler for the service WS binding needs to pass the
> user credential to the handler for the reference WS binding. Since the
> two handlers does not have any direct relation, this is done (in other
> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new service
> implementation code which connects the service (inbound from the
client)
> to the reference (outbound to other services).
> 
In SCA there's a getSecuritySubject() method on the RequestContext API.
This is implemented by putting a Subject header in the
ThreadMessageContext.
This header is added by the service binding handler and would be
available
to the reference binding handler.  Does this do what you need?

GY: Can you elaborate a little on this RequestContext API? I could not
find RequestContext interface/class from 1.6.1 source. I did find
ThreadMessageContext interface, which only deals with Message. Is
Message in Tuscany implementing the message context concept? How is it
accessed from PolicyHandler and from the client/service application
code?

   Simon

Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

See responses below.  I've removed older discussion to make this
easier to follow.

   Simon

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
 > (cut)
> 
> GY: The use case applies to SCA well. When a new service is developed
> referencing other existing services. The authorization is best done in a
> distributed fashion - the information owning service makes the
> authorization decision based on its existing policies. This means that
> when a client access this new service with its credential, this
> credential (in the form of some security token, say SAML) would need to
> be passed to the other existing services for authorization. Translated
> to SCA view, the handler for the service WS binding needs to pass the
> user credential to the handler for the reference WS binding. Since the
> two handlers does not have any direct relation, this is done (in other
> frameworks such as Axis2, JAX-WS and JAX-RPC) through the new service
> implementation code which connects the service (inbound from the client)
> to the reference (outbound to other services).
> 
In SCA there's a getSecuritySubject() method on the RequestContext API.
This is implemented by putting a Subject header in the ThreadMessageContext.
This header is added by the service binding handler and would be available
to the reference binding handler.  Does this do what you need?

   Simon

RE: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

["Yang, Gang CTR US USA" <ga...@us.army.mil>]

Classification: UNCLASSIFIED
Caveats: NONE

See the response embedded with prefix "GY:".

Gang

-----Original Message-----
From: Simon Nash [mailto:nash@apache.org] 
Sent: Thursday, February 03, 2011 4:27 PM
To: dev@tuscany.apache.org
Subject: Re: Can application code and interceptor/handler code in
Tuscany communicate with each other via some context? (UNCLASSIFIED)

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> Hi,
> 
> I'm continuing the effort to add WS-Security to Tuscany 1.6.1 using
the 
> PolicyHandler extension framework (later to Tuscany 2.0 using Policy 
> interceptor framework). I have another need for a framework
capability, 
> which is to be able to pass information/state between the application 
> code, which is either a WS client or WS service using the WS binding, 
> and the Tuscany interceptors in general or PolicyHandler in my 
> particular case. I've been poking around in the debugger and did not
see 
> anything I could possibly use. Is such capability available through
some 
> mechanism?
> 
> As an example, Axis2 service implementation (skeleton), which extends 
> Axis2Service, can call the static 
> MessageContext.getCurrentMessageContext() to obtain the current 
> MessageContext and add properties to it. While the Axis2 handler's 
> invoke() method is call with the MessageContext, where the handler can

> get the properties set by the application code. Also JAX-WS framework 
> allows WebServiceContext to be injected into application code and from

> WebServiceContext application code can obtain the SOAPMessageContext. 
> While SOAPMessageContext is pass into handler's method.
> 
At first sight this would seem to go against a key principle of SCA,
namely the separation of application business logic and infrastructure
concerns.  Can you give an example of what kind of state you need to
pass between application code and policy handlers?

GY: The use case applies to SCA well. When a new service is developed
referencing other existing services. The authorization is best done in a
distributed fashion - the information owning service makes the
authorization decision based on its existing policies. This means that
when a client access this new service with its credential, this
credential (in the form of some security token, say SAML) would need to
be passed to the other existing services for authorization. Translated
to SCA view, the handler for the service WS binding needs to pass the
user credential to the handler for the reference WS binding. Since the
two handlers does not have any direct relation, this is done (in other
frameworks such as Axis2, JAX-WS and JAX-RPC) through the new service
implementation code which connects the service (inbound from the client)
to the reference (outbound to other services).

   Simon
>  
> 
> Thanks,
> 
> Gang
> 
>  
> 
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
> 


Classification: UNCLASSIFIED
Caveats: NONE

Re: Can application code and interceptor/handler code in Tuscany communicate with each other via some context? (UNCLASSIFIED)

[Simon Nash <na...@apache.org>]

Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
> 
> Hi,
> 
> I'm continuing the effort to add WS-Security to Tuscany 1.6.1 using the 
> PolicyHandler extension framework (later to Tuscany 2.0 using Policy 
> interceptor framework). I have another need for a framework capability, 
> which is to be able to pass information/state between the application 
> code, which is either a WS client or WS service using the WS binding, 
> and the Tuscany interceptors in general or PolicyHandler in my 
> particular case. I've been poking around in the debugger and did not see 
> anything I could possibly use. Is such capability available through some 
> mechanism?
> 
> As an example, Axis2 service implementation (skeleton), which extends 
> Axis2Service, can call the static 
> MessageContext.getCurrentMessageContext() to obtain the current 
> MessageContext and add properties to it. While the Axis2 handler's 
> invoke() method is call with the MessageContext, where the handler can 
> get the properties set by the application code. Also JAX-WS framework 
> allows WebServiceContext to be injected into application code and from 
> WebServiceContext application code can obtain the SOAPMessageContext. 
> While SOAPMessageContext is pass into handler’s method.
> 
At first sight this would seem to go against a key principle of SCA,
namely the separation of application business logic and infrastructure
concerns.  Can you give an example of what kind of state you need to
pass between application code and policy handlers?

   Simon
>  
> 
> Thanks,
> 
> Gang
> 
>  
> 
> 
> Classification: UNCLASSIFIED
> Caveats: NONE
>