Classification: UNCLASSIFIED Caveats: NONE Response follows - liked the ">" prefix styling.
Gang > -----Original Message----- > From: Simon Nash [mailto:[email protected]] > Sent: Friday, February 04, 2011 10:40 AM > To: [email protected] > 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:[email protected]] > > Sent: Friday, February 04, 2011 6:17 AM > > To: [email protected] > > 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
