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>
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
