On 10/1/07, ant elder <[EMAIL PROTECTED]> wrote: > > 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 > Oops, well spotted, it should have been as you suggest...
<binding.ws requires="transport.jms"/> It doesn't do any harm adding the WSDL but it works without although currently I don't expect the WSDL definition model has the correct JMS entries in it, i.e. I haven't written the code to make that happen. Interesting question here about which piece of configuration wins. I guess that if you have gone to the trouble to specify the WSDL over and above the intent the WSDL should win. Regards Simon
