You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/10/01 12:15:02 UTC
Binding-ws transport intents
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
Re: Binding-ws transport intents
Posted by Simon Laws <si...@googlemail.com>.
Thanks for the comprehensive response Mike. Sorry I'm a little tardy in
getting back to this. Have been heads down trying to solve some issues in
the build.
Simon
On 10/2/07, Mike Edwards <mi...@gmail.com> wrote:
>
> 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.
Right. I just picked one as an education for me and to get this discussion
going.
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/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>
> >
>
> 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"
Oops. That was a cut and past error on my part from the security sample.
> <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.
Just a stepping stone to WS-Policy. I used what has currently implemented
for the security policies. I have seen a subsequent post from Venkat saying
that he is looking at ws-policy.
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).
They are in the default namespace currently as there are elements that match
the Axis2 configuration mechanism. You are picking up here on my question
about using this structure. I used it as it aready existed but I don;t think
this is the way to go utimately. I envisage having a policy structure that
is specific to the business of describing the JMS transport rather than
being specific to the way that Axi2 is configured.
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).
Yep. It shouldn't be localhost. We do need to be able to configure the
explicit location of the JNDI provider or provide a way as this bootstraps
the JMS discovery mechanism.
> 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 ...."/>
Ah, ok. I have forgotten about that. There seems to be many interrelated
bits on information so I need to go back and work out what they are all for.
>
> > - 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 is the point about the Axis2 specific structure in the policy and I'm
saying that it we are going to use it they having it in a modules called
policy-security does't sounds like the right place for it. On the other hand
I think we should move away from this Axis2 specific form. See my next
point.
> - 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.
In this particular case it comes down to whether we want the Axis2 binding
to just apply the policy directly to its configuration or whether we are
happy for it to interpret a more use friendly policy and then apply to
result to its configuration. As it stands with these policies you have to
get them correct as though you are writing Axis2 configuration files.
>
> > - 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.
Needs investigation.
>
> > 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.
Ok.
>
> > Regards
> >
> > Simon
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Binding-ws transport intents
Posted by Mike Edwards <mi...@gmail.com>.
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/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>
>
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding-ws transport intents
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
Simon Laws wrote:
>>
> 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.
The binding.ws spec basically says that the WSDL wins if it is present.
>
> Regards
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding-ws transport intents
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
ant elder wrote:
> On 10/1/07, Simon Laws <si...@googlemail.com> wrote:
> <snip>
>
> 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.
>
>
> I agree wsdl should win, that would be consistent with the other
> binding.wsfunction, for example. if wsdlElement points to a wsdl port
> then that port
> location wins over the binding.ws uri attribute location. Actually, I'd go
> further and say it should be flagged as an error if you specify requires="
> transport.jms" and point at a wsdl binding which uses an http transport.
>
+1
This is a direct conflict. In fact, you would really be unable to
satisfy the intent if the WSDL indicated SOAP/JMS, so an error is the
right course of action.
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding-ws transport intents
Posted by Simon Laws <si...@googlemail.com>.
On 10/1/07, ant elder <an...@apache.org> wrote:
>
> On 10/1/07, Simon Laws <si...@googlemail.com> wrote:
> <snip>
>
> 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.
>
>
> I agree wsdl should win, that would be consistent with the other
> binding.wsfunction, for example. if wsdlElement points to a wsdl port
> then that port
> location wins over the binding.ws uri attribute location. Actually, I'd go
> further and say it should be flagged as an error if you specify requires="
> transport.jms" and point at a wsdl binding which uses an http transport.
+1, There are three ways to specify transport information now, uri, wsdl,
intent/policy. So three ways to get it wrong or at least create
inconsistency. Pointing out such problems must be a good thing. At the
moment the various inputs are resolved to the final uri (computeActualUri)
and are stored in the wsBinding During this process we should trap whether
the inputs are inconsistent
I imagine this is going to be a general problem with SCA artifacts where
they can be configured through the SCDL or through intents/policies.
...ant
>
Re: Binding-ws transport intents
Posted by ant elder <an...@apache.org>.
On 10/1/07, Simon Laws <si...@googlemail.com> wrote:
<snip>
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.
I agree wsdl should win, that would be consistent with the other
binding.wsfunction, for example. if wsdlElement points to a wsdl port
then that port
location wins over the binding.ws uri attribute location. Actually, I'd go
further and say it should be flagged as an error if you specify requires="
transport.jms" and point at a wsdl binding which uses an http transport.
...ant
Re: Binding-ws transport intents
Posted by Simon Laws <si...@googlemail.com>.
On 10/1/07, ant elder <an...@gmail.com> wrote:
>
> On 10/1/07, Simon Laws <si...@googlemail.com> 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>
> >
> > 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
Re: Binding-ws transport intents
Posted by Mike Edwards <mi...@gmail.com>.
Folks
ant elder wrote:
>
> 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?
It depends what the WSDL is being used for. If the WSDL does define the
binding to JMS, then sure, the WSDL takes precedence.
Your example is the "pure" case where the interface definition comes
from the implementation and the WSDL is auto-generated by the runtime.
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Binding-ws transport intents
Posted by ant elder <an...@gmail.com>.
On 10/1/07, Simon Laws <si...@googlemail.com> 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>
>
> 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
Re: Binding-ws transport intents
Posted by Simon Laws <si...@googlemail.com>.
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 <fo...@gmail.com> 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 <si...@googlemail.com> 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
> >
>
Re: Binding-ws transport intents
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Simon,
I have tried to answer from whatever I know of polices. Hope it helps. :)
Thanks
- Venkat
On 10/1/07, Simon Laws <si...@googlemail.com> 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.
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.
- 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.xml file
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.
- 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 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
>