Simon Laws wrote:
On 7/24/07, Mike Edwards <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
