Simon,
Oh boy, I'm going to have to pick the bones out of this one...
This may take more than one email to deal with since I fear that things
could get quite lengthy.
First, how might the use of SOAP/JMS be represented in the SCA model?
There is no single "right" answer to this - certainly not at the moment,
with the SCA Bindings spec group only just having this on their agenda
and the SOAP/JMS spec only just going towards publication and
standardization.
How COULD it be done?
1) Treat SOAP/JMS as a completely separate binding, separate from
SOAP/HTTP. eg binding.soapjms
2) Treat SOAP/JMS as a variant of the binding.ws, selected by a
parameter supplied on the binding.ws element.
3) Treat SOAP/JMS as a variant of the binding.jms, selected by a
parameter on the binding.ws element
4) Treat SOAP/JMS as a variant of either or both binding.ws and
binding.jms, where the selection is done via an intent, as you are doing
in what follows.
None of these is "right". They are all possible and they have their
pros and cons.
Using a variant of binding.ws allows for the use of WSDL in a clear and
simple fashion. Use of a variant of binding.jms allows for
specification of JMS parameter values (things like Queue names, for
example).
Simon Laws 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>
This needs to declare what it attaches the intent to, using the
@constrains attribute, which is mandatory.
constrains="sca:binding"
will do, although this is an XPath expression which can get more
specific if you wish, eg "sca:binding.ws"
<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>
This is OK, assuming that the binding implementation code that you have
for binding.ws does understand those wsConfigParam elements. I note
that this is inventing a new policy language. I think it is fair to ask
why you created a new language rather than use the WS-Policy language.
I'd also like to ask which namespace the <parameter.../> elements are
coming from (I suspect I know but I'd appreciate hearing your intentions).
One thing that worries me somewhat is that namimg provider url, which
seems awfully machine-dependent, even using localhost. It assumes that
all machines using this PolicySet will have port 61616 set for this
capability. On the other hand, perhaps in a more general distributed
system, it is reasonable that there is a central authority for this
capability on a fixed network address (eg tcp://foosystem:61616).
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?
OK, I think I can answer this one straightforwardly:
There is a bindingType declaration element which goes into the
definitions.xml file. Pseudo-schema:
<bindingType type="NCName"
alwaysProvides="listOfQNames"?
mayProvide="listOfQNames"?/>
@alwaysProvides lists the set of intents that the binding always
supplies, irrespective of any configuration (eg an HTTPS binding would
always provide the "confidentiality" intent since messages are always
encrypted)
@mayProvide lists the set of intents that the binding may provide if
configured with an appropriate PolicySet
So you would say something like...
<bindingType type="binding.ws"
alwaysProvides="....."
mayProvide="transport.jms ...."/>
- 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
Umm "policy implementation" is a term that confuses me. I don't know
what you are talking about - do you mean a slice of code in the binding
implementation, or do you mean that PolicySet file up above?
PolicySets can be constructed in a number of ways:
- lots of separate ones each dealing with a particular area or domain of
policy (eg Security, Transactions, etc)
- few large ones combining a whole series of areas of policy (typically
handled using IntentMaps....)
take your pick, either is OK.
- 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?
This is where the appliesTo attribute can come into its own. It is
possible to structure PolicySets that apply to a particular
implementation of binding.ws, as long as there is some feature of that
binding that can be picked out in XML terms.
Defining something more general is probably best done through a request
to the OASIS Bindings TC, since it would necessarily be "standardized"
to apply to a range of implementations.
- 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?
Hmm, not clever - the intents are a very important part of selecting the
right policies. They will be necessary for wire matching and also for
configuring the binding.
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.
Yeah, this will give some real entertainment to the WSDL generation code.
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.
I suggest you look over the defaulting rules for the queue name as
defined in the JMS binding spec.
Regards
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
