Hi Simon,
First, I am using 1.x
Thanks for the link to that page, there is some useful information in there.
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
org.apache.tuscany.sca.binding.jms.policy.authentication.token.
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 credentials
// and correct token. Here we are just putting in the token name
principal = new TokenPrincipal("DummyTokenID");
subject.getPrincipals().add(principal);
}
jmsMsg.setStringProperty(policy.getTokenName().toString(),
principal.getName());
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.
Padraig
-----Original Message-----
From: Simon Laws [mailto:[email protected]]
Sent: 28 October 2010 16:26
To: [email protected]
Subject: Re: How to add authentication property to JMS header
On Wed, Oct 27, 2010 at 5:45 PM, Padraig Myers <[email protected]>
wrote:
> Hi,
> Need some help trying to send session data between Tuscany nodes over
JMS.
> We have a system which is composed of about 15 Tuscany nodes, however
we
> 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
name
> 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
>
>
org.apache.tuscany.sca.binding.jms.policy.authentication.token.JMSTokenA
uthenticationPolicy
> Used to insert a user defined authentication property into the JMS
header.
>
> 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
is
> static and defined in the .composite file.
> Is there a way of specifying a JMS property where we can insert our
dynamic
> session data every time we send a message. If there is could you point
me
> 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.
[1]
http://tuscany.apache.org/documentation-2x/sca-java-runtime-overview.htm
l
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org Co-author of a book about
Tuscany and SCA: tuscanyinaction.com
