tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Laws <simonsl...@googlemail.com>
Subject Re: How to add authentication property to JMS header
Date Thu, 28 Oct 2010 15:26:14 GMT
On Wed, Oct 27, 2010 at 5:45 PM, Padraig Myers <padraig.myers@gmail.com> 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.JMSTokenAuthenticationPolicy
> 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.html



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

View raw message