Hi Simon, I have tried to answer from whatever I know of polices. Hope it helps. :)
Thanks - Venkat On 10/1/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > The new SOAP/JMS transport option in binding-ws-axis provided by Dinesh > motivated me to go and look at how this new option (soap/jms) might be > selected using the policy framework. This all started a while back with > this > thread ( > http://www.mail-archive.com/[email protected]/msg20657.html). > By way of a little education in the policy framework I've just looked at > the > server side of things at the moment and have a few questions of those who > know policy better than I do.... > > I created a definitions.xml file with the following... > > <sca:intent name="transport.jms"> > <sca:description> > A JMS transport is required > </sca:description> > </sca:intent> > > <sca:policySet name="wsJMSTransportPolicy" > provides="transport.jms" > appliesTo="sca:binding.ws"> > <tuscany:wsConfigParam> > <parameter name="TuscanyQueueConnectionFactory"> > <parameter name="java.naming.factory.initial"> > org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter> > <parameter name="java.naming.provider.url > ">tcp://localhost:61616</parameter> > <parameter > name="transport.jms.ConnectionFactoryJNDIName > ">QueueConnectionFactory</parameter> > > </parameter> > </tuscany:wsConfigParam> > </sca:policySet> > > I plumbed this into the Axis2ServiceProvider as an alternative to > providing > this information via the binding.ws uri attibute so you can specify the > following... > > <component name="HelloWorldServiceComponent"> > <implementation.java class="helloworld.HelloWorldImpl" /> > <service name="HelloWorldService"> > <interface.wsdl interface=" > http://helloworld#wsdl.interface(HelloWorld)" /> > <binding.ws wsdlElement=" > http://helloworld#wsdl.binding(HelloWorldSoapJmsBinding)" requires=" > transport.jms"/> > </service> > </component> Before I go over to the questions just want to stress that this particular PolicyStructure has been put in place for those things that can be fed into the axis2 configuration as config params. If soap/jms is something that can go in as config params then this could be used and all that you'd need to do is set up a policyset that describes the parameter. Quetions... > > - How does an SCA artifact, binding-ws in this case, advertise what > intents > and policy sets can validly be specified. Is the intention that it is > inferred through the policy set appliesTo attribute? Yes you are right. For intents there is a 'constrains' attirbute that specifies the bindings / implementation that can use the specified intent and for policysets its the 'appliesTo' attribute which does this. These are the two which we use to validate if an intent or policyset is really applicable to a binding or implementation. - I used the policy-scurity Axis2ConfigParamPolicy to structure the policy > here. This is more generally useful that security. It raises the question > about where we put policy implementations. > Each in a separate module > In one big module (possibly with separate package names) > With the SCA artifact implementation to which they belong > Somewhere else I am not sure if I understand 'policy implementations'. If you mean where we put the policyset definitions the answer is - in the definitions.xml file and every SCA Domain is supposed to be having a definitions.xml file. If you are asking about the infrastructural piece that picks up the policy specifications and brings about the desired effects - such as encrypting the messages or authenticating requests etc. then I'd say it depends on where this can apply or where it could be plugged-in and invoked. For example to effect ws-security in our Axis2 ws binding we use the Rampart module which straps on to Axis2 and hence its all a part of the axis2 binding module. If there is something that could work with all bindings I would imagine that would probably get to be a module in our runtime itself. - This policy is very specific to Axis2. Well the information is general but > the parameters are structured as they are because this is the way that > Axis > reads configuration parameters. In the end though I didn't end up pushing > them directly into Axis 2 so, in theory, they could be structured > differently. It would be interesting to look at more general alternatives, > e.g. ws-policy. Are there any examples in the codebase yet? No :( at the present moment but you will soon see something. Just now we have bindings enabled for policies and I want to wrap that up for implementations as well which is what I am doing currently. After this, I plan to look at bringing in ws-policy and thats not far away. :) - I was originally going to drive the processing from the required intents > on the binding but they don't appear to be preserved in the model. Is this > intentional? > > I haven't looked at the reference side of this yet. > > The non SCA client relies on the service location in the wsdl having the > appropriate JMS configuration so the WSDL needs to be generated taking > intents into account. > > In the case of an SCA client in the same domain I'm assuming we would > expect the specification of a policy intent to be sufficient so that this > can be part of the reference/service matching process. Currently I name > the JMS queue after the service name so the minimum information is the > contract, the reference target and the policy set. > > Regards > > Simon >
