Thanks for the replies Venkat, have been distracted over the last few days with a series of thorny build issues so only just getting back to this.
Simon On 10/1/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > 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/tuscany-dev@ws.apache.org/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. I understand. soap/jms params sit underneath the transport configuration elements in Axis configuration but they have the same parameter based format. Should we though have a lees Axis specific policy structure? Also this structure is currently in a security modules and I'm using it for the jms transport which sounds wrong. In due course I may separate the jms stuff out into a new module. 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. Ok, thanks - 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.xmlfile > 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. I was ust making the point that I'm using your Axis configuration policy structures and they sit in policy-security at the moment. I'm reusing them for the jms transport support and that doesn;t sound right as it has nothing to do with security - 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 have seen you later posts on this. Sounds promising. - 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 > > >
