tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Padraig Myers" <Padraig.My...@channeladvisor.com>
Subject RE: How to add authentication property to JMS header
Date Thu, 28 Oct 2010 17:08:03 GMT
Hi Simon,
First, I am using 1.x
Thanks for the link to that page, there is some useful information in
At this stage it looks like I need to create a custom interceptor that
grabs the data from the session (that won't be problem, its stored in a
ThreadLocal singleton) and puts it into JMS properties.
Essentially the
JMSTokenAuthenticationReferencePolicyInterceptor does almost exactly
what I need, except in the section that says:
    if (principal == null){
        // should call out here to some 3rd party system to get
        // and correct token. Here we are just putting in the token name
        principal = new TokenPrincipal("DummyTokenID");

I need to replace this with code to add my session data to the
properties. Something like:
    jmsMsg.setStringProperty("USER_ID", SessionHolder.getUserId());
    jmsMsg.setStringProperty("USER_NAME", SessionHolder.getUserName());

However to do this it looks like I need to rewrite the entire extension,
including all the StAX Processor files etc.
This seems like overkill to get such a simple task done, am I missing
something whereby there is some method to call out to a simple message
processor without have to write a whole extension.


-----Original Message-----
From: Simon Laws [mailto:simonslaws@googlemail.com] 
Sent: 28 October 2010 16:26
To: user@tuscany.apache.org
Subject: Re: How to add authentication property to JMS header

On Wed, Oct 27, 2010 at 5:45 PM, Padraig Myers <padraig.myers@gmail.com>
> Hi,
> Need some help trying to send session data between Tuscany nodes over
> We have a system which is composed of about 15 Tuscany nodes, however
> need to share certain session data between all of these nodes (such as
> currently logged in user).
> Initially we were using web services and had the current user's id and
> in the headers of the web service http request.
> However, we were forced to move to JMS as the transport protocol and
are now
> trying to figure out how to share this data over JMS.
> I was looking at the binding.jms help page on you site and I saw
mention of
> Used to insert a user defined authentication property into the JMS
> However all of the code I can find in the samples and itest
directories of
> the source code show fixed properties where the value of the property
> static and defined in the .composite file.
> Is there a way of specifying a JMS property where we can insert our
> session data every time we send a message. If there is could you point
> towards an example.
> Failing that, I am open to any suggestion on possible remedies,
basically we
> just need to share session data over JMS between Tuscany nodes.
> Thanks in advance for your help,
> Padraig

Hi Padraig

Are you using the 1.x or 2.x code base. For JMS it actually doesn't
make that much different as the code bases are fairly similar however
it's useful to know.

Let me start by saying something about interceptors. At the bottom of
[1] there are some pictures (needs some words!) of the message
processing wires that are active on the reference and service side. So
we can use this to introduce new function like header processing into
the runtime. Here are some alternatives.

1/ policy.

SCA defines a policy model that allows you to state what QoS features
are required by adding intents and/or policy sets to the compositions.
After some processing this resolves to the addition of policy based
interceptors to the wires. For example, as you spotted, the
JMSTokenAuthenticationReferencePolicyInterceptor is added to the
reference side wire when the token authentication policy is added. It
currently just adds static data from the policy configuration.

2/ binding interceptors
2a/ wireFormat & operationSelection

There's an element of pluggability to some bindings, JMS being one of
them, that allows you to specify wireFormat and operationSelector
interceptors via the binding configuration. Again the implementation
is a wire interceptor.

2b/ hardcoded interceptors

The binding itself is basically made up of a set of interceptors that
do various things such as committing the message to the protocol. The
set of interceptors is defined by the reference and service providers.

Which one is appropriate depends on how you want the feature to be
configured. In all of these the operation of the interceptor, in terms
of adding dynamic header, elements relies on being able to get at the
session data itself. In your case where/how is the session data being
held at runtime? We then need to work out how and interceptor might
get hold of it.




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

View raw message