On Wed, Oct 27, 2010 at 5:45 PM, Padraig Myers <padraig.my...@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 Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
