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> > > 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? > > - 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 > > - 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? > > - 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 >
Cool. Is it really necessary to use policy intents when there's an existing wsdl document, i.e. when binding.ws uses a wsdlElement pointing to a wsdl binding? There's already ways of using soap/jms with wsdl so instead of: <binding.ws wsdlElement=" http://helloworld#wsdl.binding(HelloWorldSoapJmsBinding)" requires=" transport.jms"/> it would more likely be : <binding.ws requires="transport.jms"/> Right? ...ant
