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/07/23 15:40:16 UTC
SOAP over JMS?
Has anyone in Tuscany made a binding that ships SOAP messages over JMS
instead of HTTP? Looking at the current code base and at the old code in the
sandbox I don't see anything.
Simon
Re: SOAP over JMS?
Posted by ant elder <an...@apache.org>.
On 7/23/07, Simon Laws <si...@googlemail.com> wrote:
>
> Has anyone in Tuscany made a binding that ships SOAP messages over JMS
> instead of HTTP? Looking at the current code base and at the old code in
> the
> sandbox I don't see anything.
>
> Simon
>
I don't know of anyone who's tried, but as Axis2 already comes with a JMS
transport there's a could chance this would just work, or at least only
require bit of tweaking to the Tuscany code and config files.
...ant
Re: SOAP over JMS?
Posted by Mike Edwards <mi...@gmail.com>.
ant elder wrote:
> Couldn't this just use the existing Axis2 facilities, the soap/jms uri
> format and be done with the scdl binding uri attribute, eg:
>
> <binding.wsuri="jms:/dynamicTopics/something.TestTopic?transport.jms.ConnectionFactoryJNDIName=TopicConnectionFactory&java.naming.factory.initial=
>
> org.apache.activemq.jndi.ActiveMQInitialContextFactory&java.naming.provider.url=tcp://localhost:61616&java.naming.security.principal=system&java.naming.security.credentials=manager"
>
> />
>
> ...ant
"Simple" that ain't ;-)
Agreed that if you get into requiring all those details, that is one way
to supply them. As Simon notes elsewhere, the JMS binding provides a
more structured way of providing all that gorp.
I was hoping for something simple, but perhaps I'm being too simplistic.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SOAP over JMS?
Posted by ant elder <an...@apache.org>.
The sca jms binding spec also supports defining all that with the uri
attribute doesn't it. The ws soap/jms uri format has been an evolving
technique used for quite a while, and there is an attempt to standardized
it, see :
http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/%3C80A43FC052CE3949A327527DCD5D6B27020FB65C@MAIL01.bedford.progress.com%3E
...ant
On 7/24/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 7/24/07, ant elder <an...@apache.org> wrote:
>
> > On 7/24/07, Mike Edwards <mi...@gmail.com> wrote:
> > >
> > > Simon Laws wrote:
> > > > Has anyone in Tuscany made a binding that ships SOAP messages over
> > JMS
> > > > instead of HTTP? Looking at the current code base and at the old
> > code in
> > > > the
> > > > sandbox I don't see anything.
> > > >
> > > > Simon
> > > >
> > >
> > > Simon,
> > >
> > > Shouldn't this be a "simple" extension of the Web services binding?
> > >
> > > The interesting question is how to indicate that a JMS transport
> > should
> > > be used instead of HTTP. The spec only allows for this to be done via
> >
> > > WSDL at the moment - not so good if you didn't want to create the WSDL
> > > yourself.
> > >
> > > How about the idea of adding an intent for the Web services binding
> > > which can be used to indicate the transport??
> > >
> > > eg:
> > >
> > >
> > > transport.http = use the HTTP transport (default)
> > > transport.jms = use the JMS transport
> > > transport.foo = use the foo transport....
> > >
> > > The Web services binding can indicate which of these intents it
> > supports
> > > - since that depends on the support being available in the Web
> > > services stack that you are using.
> >
> >
> > Couldn't this just use the existing Axis2 facilities, the soap/jms uri
> > format and be done with the scdl binding uri attribute, eg:
> >
> > <binding.wsuri=
> > "jms:/dynamicTopics/something.TestTopic?transport.jms.ConnectionFactoryJNDIName=TopicConnectionFactory&java.naming.factory.initial=
> >
> > org.apache.activemq.jndi.ActiveMQInitialContextFactory&java.naming.provider.url=tcp://localhost:61616&java.naming.security.principal=system&java.naming.security.credentials=manager"
> > />
> >
> > ...ant
>
>
> This provides a useable optional way of providing this information and a
> convenient way to start. It would seem a little odd, though, that the JMS
> binding lays all this out:
>
> * <binding.jms correlationScheme="string"?
> * initialContextFactory="xs:anyURI"?
> * jndiURL="xs:anyURI"?
> * requestConnection="QName"?
> * responseConnection="QName"?
> * operationProperties="QName"?
> * ...>
> *
> * <destination name="xs:anyURI" type="string"? create="string"?>
> * <property name="NMTOKEN" type="NMTOKEN">*
> * </destination>?
> *
> * <connectionFactory name="xs:anyURI" create="string"?>
> * <property name="NMTOKEN" type="NMTOKEN">*
> * </connectionFactory>?
> *
> * <activationSpec name="xs:anyURI" create="string"?>
> * <property name="NMTOKEN" type="NMTOKEN">*
> * </activationSpec>?
> *
> * <response>
> * <destination name="xs:anyURI" type="string"? create="string"?>
> * <property name="NMTOKEN" type="NMTOKEN">*
> * </destination>?
> *
> * <connectionFactory name="xs:anyURI" create="string"?>
> * <property name="NMTOKEN" type="NMTOKEN">*
> * </connectionFactory>?
> *
> * <activationSpec name="xs:anyURI" create="string"?>
> * <property name="NMTOKEN" type="NMTOKEN">*
> * </activationSpec>?
> * </response>?
> *
> * <resourceAdapter name="NMTOKEN">?
> * <property name="NMTOKEN" type="NMTOKEN">*
> * </resourceAdapter>?
> *
> * <headers JMSType="string"?
> * JMSCorrelationId="string"?
> * JMSDeliveryMode="string"?
> * JMSTimeToLive="int"?
> * JMSPriority="string"?>
> * <property name="NMTOKEN" type="NMTOKEN">*
> * </headers>?
> *
> * <operationProperties name="string" nativeOperation="string"?>
> * <property name="NMTOKEN" type="NMTOKEN">*
> * <headers JMSType="string"?
> * JMSCorrelationId="string"?
> * JMSDeliveryMode="string"?
> * JMSTimeToLive="int"?
> * JMSPriority="string"?>
> * <property name="NMTOKEN" type="NMTOKEN">*
> * </headers>?
> * </operationProperties>*
> * </binding.jms>
>
> if the only way to provide it for SOAP/JMS is through the URI.
>
> Simon
>
>
>
Re: SOAP over JMS?
Posted by Simon Laws <si...@googlemail.com>.
On 7/24/07, ant elder <an...@apache.org> wrote:
>
> On 7/24/07, Mike Edwards <mi...@gmail.com> wrote:
> >
> > Simon Laws wrote:
> > > Has anyone in Tuscany made a binding that ships SOAP messages over JMS
> > > instead of HTTP? Looking at the current code base and at the old code
> in
> > > the
> > > sandbox I don't see anything.
> > >
> > > Simon
> > >
> >
> > Simon,
> >
> > Shouldn't this be a "simple" extension of the Web services binding?
> >
> > The interesting question is how to indicate that a JMS transport should
> > be used instead of HTTP. The spec only allows for this to be done via
> > WSDL at the moment - not so good if you didn't want to create the WSDL
> > yourself.
> >
> > How about the idea of adding an intent for the Web services binding
> > which can be used to indicate the transport??
> >
> > eg:
> >
> >
> > transport.http = use the HTTP transport (default)
> > transport.jms = use the JMS transport
> > transport.foo = use the foo transport....
> >
> > The Web services binding can indicate which of these intents it supports
> > - since that depends on the support being available in the Web
> > services stack that you are using.
>
>
> Couldn't this just use the existing Axis2 facilities, the soap/jms uri
> format and be done with the scdl binding uri attribute, eg:
>
> <binding.wsuri=
> "jms:/dynamicTopics/something.TestTopic?transport.jms.ConnectionFactoryJNDIName=TopicConnectionFactory&java.naming.factory.initial=
>
> org.apache.activemq.jndi.ActiveMQInitialContextFactory&java.naming.provider.url=tcp://localhost:61616&java.naming.security.principal=system&java.naming.security.credentials=manager
> "
> />
>
> ...ant
This provides a useable optional way of providing this information and a
convenient way to start. It would seem a little odd, though, that the JMS
binding lays all this out:
* <binding.jms correlationScheme="string"?
* initialContextFactory="xs:anyURI"?
* jndiURL="xs:anyURI"?
* requestConnection="QName"?
* responseConnection="QName"?
* operationProperties="QName"?
* ...>
*
* <destination name="xs:anyURI" type="string"? create="string"?>
* <property name="NMTOKEN" type="NMTOKEN">*
* </destination>?
*
* <connectionFactory name="xs:anyURI" create="string"?>
* <property name="NMTOKEN" type="NMTOKEN">*
* </connectionFactory>?
*
* <activationSpec name="xs:anyURI" create="string"?>
* <property name="NMTOKEN" type="NMTOKEN">*
* </activationSpec>?
*
* <response>
* <destination name="xs:anyURI" type="string"? create="string"?>
* <property name="NMTOKEN" type="NMTOKEN">*
* </destination>?
*
* <connectionFactory name="xs:anyURI" create="string"?>
* <property name="NMTOKEN" type="NMTOKEN">*
* </connectionFactory>?
*
* <activationSpec name="xs:anyURI" create="string"?>
* <property name="NMTOKEN" type="NMTOKEN">*
* </activationSpec>?
* </response>?
*
* <resourceAdapter name="NMTOKEN">?
* <property name="NMTOKEN" type="NMTOKEN">*
* </resourceAdapter>?
*
* <headers JMSType="string"?
* JMSCorrelationId="string"?
* JMSDeliveryMode="string"?
* JMSTimeToLive="int"?
* JMSPriority="string"?>
* <property name="NMTOKEN" type="NMTOKEN">*
* </headers>?
*
* <operationProperties name="string" nativeOperation="string"?>
* <property name="NMTOKEN" type="NMTOKEN">*
* <headers JMSType="string"?
* JMSCorrelationId="string"?
* JMSDeliveryMode="string"?
* JMSTimeToLive="int"?
* JMSPriority="string"?>
* <property name="NMTOKEN" type="NMTOKEN">*
* </headers>?
* </operationProperties>*
* </binding.jms>
if the only way to provide it for SOAP/JMS is through the URI.
Simon
Re: SOAP over JMS?
Posted by ant elder <an...@apache.org>.
On 7/24/07, Mike Edwards <mi...@gmail.com> wrote:
>
> Simon Laws wrote:
> > Has anyone in Tuscany made a binding that ships SOAP messages over JMS
> > instead of HTTP? Looking at the current code base and at the old code in
> > the
> > sandbox I don't see anything.
> >
> > Simon
> >
>
> Simon,
>
> Shouldn't this be a "simple" extension of the Web services binding?
>
> The interesting question is how to indicate that a JMS transport should
> be used instead of HTTP. The spec only allows for this to be done via
> WSDL at the moment - not so good if you didn't want to create the WSDL
> yourself.
>
> How about the idea of adding an intent for the Web services binding
> which can be used to indicate the transport??
>
> eg:
>
>
> transport.http = use the HTTP transport (default)
> transport.jms = use the JMS transport
> transport.foo = use the foo transport....
>
> The Web services binding can indicate which of these intents it supports
> - since that depends on the support being available in the Web
> services stack that you are using.
Couldn't this just use the existing Axis2 facilities, the soap/jms uri
format and be done with the scdl binding uri attribute, eg:
<binding.wsuri="jms:/dynamicTopics/something.TestTopic?transport.jms.ConnectionFactoryJNDIName=TopicConnectionFactory&java.naming.factory.initial=
org.apache.activemq.jndi.ActiveMQInitialContextFactory&java.naming.provider.url=tcp://localhost:61616&java.naming.security.principal=system&java.naming.security.credentials=manager"
/>
...ant
Re: SOAP over JMS?
Posted by Simon Laws <si...@googlemail.com>.
On 7/24/07, Mike Edwards <mi...@gmail.com> wrote:
>
> Simon Laws wrote:
> <snip>
> > Ah, thanks Mike. I didn't latch onto the implication of the word intent.
> > The choice we are talking about here seems more like a concrete decision
> > than an intent. Does this match well with the, erm, intention of
> intents?
> >
> > Simon
> >
> It is one use of intents - and, in my opinion, it is a reasonable match.
> It tells the binding to apply a particular policy - the policy of
> using a specific transport.
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> So I can summarize a few things from this thread.
1/ That in this case the concensus so far is that binding-ws should have
selectable transports.
2/ There are a number of ways we can describe the selection
- intents
- uri
- child xml elements of binding.ws
3/ There are a number of ways we can describe the configuration of the
selected transport
- further parameters on the uri
- child xml elements of binding.ws
It seems to me that the uri approach is the easiest starting point (this
function also needs to be added to the MS binding so I imagine the
same/similar code applies). I'm not in a position to address this just now
(am back working on the distributed runtime) but it answers my question
about how this could be done. If there is anyone out there who fancies
having a play with some binding stuff then this is another good one to look
at.
Simon
Re: SOAP over JMS?
Posted by Simon Laws <si...@googlemail.com>.
On 7/24/07, Mike Edwards <mi...@gmail.com> wrote:
>
> Simon Laws wrote:
> <snip>
> > Ah, thanks Mike. I didn't latch onto the implication of the word intent.
> > The choice we are talking about here seems more like a concrete decision
> > than an intent. Does this match well with the, erm, intention of
> intents?
> >
> > Simon
> >
> It is one use of intents - and, in my opinion, it is a reasonable match.
> It tells the binding to apply a particular policy - the policy of
> using a specific transport.
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> So I can summarize a few things from this thread.
1/ That in this case the concensus so far is that binding-ws should have
selectable transports.
2/ There are a number of ways we can describe the selection
- intents
- uri
- child xml elements of binding.ws
3/ There are a number of ways we can describe the configuration of the
selected transport
- further parameters on the uri
- child xml elements of binding.ws
It seems to me that the uri approach is the easiest starting point (this
function also needs to be added to the MS binding so I imagine the
same/similar code applies). I'm not in a position to address this just now
(am back working on the distributed runtime) but it answers my question
about how this could be done. If there is anyone out there who fancies
having a play with some binding stuff then this is another good one to look
at.
Simon
Re: SOAP over JMS?
Posted by Mike Edwards <mi...@gmail.com>.
Simon Laws wrote:
<snip>
> Ah, thanks Mike. I didn't latch onto the implication of the word intent.
> The choice we are talking about here seems more like a concrete decision
> than an intent. Does this match well with the, erm, intention of intents?
>
> Simon
>
It is one use of intents - and, in my opinion, it is a reasonable match.
It tells the binding to apply a particular policy - the policy of
using a specific transport.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SOAP over JMS?
Posted by Simon Laws <si...@googlemail.com>.
On 7/24/07, Mike Edwards <mi...@gmail.com> wrote:
>
> Simon Laws wrote:
> > On 7/24/07, Mike Edwards <mi...@gmail.com> wrote:
> >>
> >> Simon Laws wrote:
> >> > Has anyone in Tuscany made a binding that ships SOAP messages over
> JMS
> >> > instead of HTTP? Looking at the current code base and at the old
> >> code in
> >> > the
> >> > sandbox I don't see anything.
> >> >
> >> > Simon
> >> >
> >>
> >> Simon,
> >>
> >> Shouldn't this be a "simple" extension of the Web services binding?
> >>
> >> The interesting question is how to indicate that a JMS transport should
> >> be used instead of HTTP. The spec only allows for this to be done via
> >> WSDL at the moment - not so good if you didn't want to create the WSDL
> >> yourself.
> >>
> >> How about the idea of adding an intent for the Web services binding
> >> which can be used to indicate the transport??
> >>
> >> eg:
> >>
> >>
> >> transport.http = use the HTTP transport (default)
> >> transport.jms = use the JMS transport
> >> transport.foo = use the foo transport....
> >>
> >> The Web services binding can indicate which of these intents it
> supports
> >> - since that depends on the support being available in the Web
> >> services stack that you are using.
> >>
> >> Yours, Mike.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >> So you would end up with
> >
> > <binding.ws>
> > <transport.???>
> > <some transport config>
> > </transport.???>
> > <binding.ws>
> >
> > Is that right?
> >
> Nope. That's not what I mean. Sorry but I assumed too much knowledge
> of the SCA Policy spec...
>
> What you would get is this:
>
> <binding.ws requires="transport.jms"/>
>
> or
>
> <binding.ws requires="transport.http"/>
>
> If you require specific configuration details for the given transport,
> then this would have to be supplied by additional attributes or by
> additional child elements. The URI attribute is one possible approach,
> but it can get to look very messy very quickly.
>
> Whether you need a load of configuration really depends on whether you
> are going external to the SCA Domain. If you are going external, then
> detailed config is probably necessary. However, some good sensible
> defaulting can probably give a usable service with minimal information.
> References are a different matter since the target endpoint is what it
> is.
>
> Using SOAP over HTTP should in principle simplify things to some extent
> since the message format is "known" and hence there is less
> configuration required.
>
> Hope this helps,
>
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Ah, thanks Mike. I didn't latch onto the implication of the word intent.
The choice we are talking about here seems more like a concrete decision
than an intent. Does this match well with the, erm, intention of intents?
Simon
Re: SOAP over JMS?
Posted by Mike Edwards <mi...@gmail.com>.
Simon Laws wrote:
> On 7/24/07, Mike Edwards <mi...@gmail.com> wrote:
>>
>> Simon Laws wrote:
>> > Has anyone in Tuscany made a binding that ships SOAP messages over JMS
>> > instead of HTTP? Looking at the current code base and at the old
>> code in
>> > the
>> > sandbox I don't see anything.
>> >
>> > Simon
>> >
>>
>> Simon,
>>
>> Shouldn't this be a "simple" extension of the Web services binding?
>>
>> The interesting question is how to indicate that a JMS transport should
>> be used instead of HTTP. The spec only allows for this to be done via
>> WSDL at the moment - not so good if you didn't want to create the WSDL
>> yourself.
>>
>> How about the idea of adding an intent for the Web services binding
>> which can be used to indicate the transport??
>>
>> eg:
>>
>>
>> transport.http = use the HTTP transport (default)
>> transport.jms = use the JMS transport
>> transport.foo = use the foo transport....
>>
>> The Web services binding can indicate which of these intents it supports
>> - since that depends on the support being available in the Web
>> services stack that you are using.
>>
>> Yours, Mike.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>> So you would end up with
>
> <binding.ws>
> <transport.???>
> <some transport config>
> </transport.???>
> <binding.ws>
>
> Is that right?
>
Nope. That's not what I mean. Sorry but I assumed too much knowledge
of the SCA Policy spec...
What you would get is this:
<binding.ws requires="transport.jms"/>
or
<binding.ws requires="transport.http"/>
If you require specific configuration details for the given transport,
then this would have to be supplied by additional attributes or by
additional child elements. The URI attribute is one possible approach,
but it can get to look very messy very quickly.
Whether you need a load of configuration really depends on whether you
are going external to the SCA Domain. If you are going external, then
detailed config is probably necessary. However, some good sensible
defaulting can probably give a usable service with minimal information.
References are a different matter since the target endpoint is what it is.
Using SOAP over HTTP should in principle simplify things to some extent
since the message format is "known" and hence there is less
configuration required.
Hope this helps,
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SOAP over JMS?
Posted by Simon Laws <si...@googlemail.com>.
On 7/24/07, Mike Edwards <mi...@gmail.com> wrote:
>
> Simon Laws wrote:
> > Has anyone in Tuscany made a binding that ships SOAP messages over JMS
> > instead of HTTP? Looking at the current code base and at the old code in
> > the
> > sandbox I don't see anything.
> >
> > Simon
> >
>
> Simon,
>
> Shouldn't this be a "simple" extension of the Web services binding?
>
> The interesting question is how to indicate that a JMS transport should
> be used instead of HTTP. The spec only allows for this to be done via
> WSDL at the moment - not so good if you didn't want to create the WSDL
> yourself.
>
> How about the idea of adding an intent for the Web services binding
> which can be used to indicate the transport??
>
> eg:
>
>
> transport.http = use the HTTP transport (default)
> transport.jms = use the JMS transport
> transport.foo = use the foo transport....
>
> The Web services binding can indicate which of these intents it supports
> - since that depends on the support being available in the Web
> services stack that you are using.
>
> Yours, Mike.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> So you would end up with
<binding.ws>
<transport.???>
<some transport config>
</transport.???>
<binding.ws>
Is that right?
Re: SOAP over JMS?
Posted by Mike Edwards <mi...@gmail.com>.
Simon Laws wrote:
> Has anyone in Tuscany made a binding that ships SOAP messages over JMS
> instead of HTTP? Looking at the current code base and at the old code in
> the
> sandbox I don't see anything.
>
> Simon
>
Simon,
Shouldn't this be a "simple" extension of the Web services binding?
The interesting question is how to indicate that a JMS transport should
be used instead of HTTP. The spec only allows for this to be done via
WSDL at the moment - not so good if you didn't want to create the WSDL
yourself.
How about the idea of adding an intent for the Web services binding
which can be used to indicate the transport??
eg:
transport.http = use the HTTP transport (default)
transport.jms = use the JMS transport
transport.foo = use the foo transport....
The Web services binding can indicate which of these intents it supports
- since that depends on the support being available in the Web
services stack that you are using.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SOAP over JMS?
Posted by ant elder <an...@apache.org>.
On 7/23/07, Simon Laws <si...@googlemail.com> wrote:
>
> Has anyone in Tuscany made a binding that ships SOAP messages over JMS
> instead of HTTP? Looking at the current code base and at the old code in
> the
> sandbox I don't see anything.
>
> Simon
>
I don't know of anyone who's tried, but as Axis2 already comes with a JMS
transport there's a could chance this would just work, or at least only
require bit of tweaking to the Tuscany code and config files.
...ant