dev@jax-ws.java.net

Re: SOAP/TCP transport?

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 27 Oct 2006 14:59:55 +0200

Oleksiy Stashok wrote:
>> I wonder if it makes more sense to have such "protocol
>> negotiation/handshaking" layer that's independent from the transport
>> layer.
>>
>> I think asking every transport to do that kind of things on its own is
>> not going to be very pleasant both for the JAX-WS RI and transport
>> implementors. Such handshaking layer can do other useful things, too,
>> like fail-over, load balancing, etc.
>>
>> I suspect we might be able to use a JAX-WS RI WebServiceFeature to do
>> something like that, within the bound of the spec. Something like
>> "SelectBestTransport" feature, or something.
>
> Sounds interesting, what do you think Paul?
>

The problem with a protocol negotiation handshaking layer is what
protocol do you use to do the handshaking?

I like the idea of a client sending a HTTP request and getting a
redirect to another URI, that uses a different scheme.

We did think about this, but the issue that arose was by the time you
have encoded something it may not be possible to re-encode it if you
need to send it again. So you need to buffer just in case or more
preferably you need to swtich on the second and subsequent requests (as
is performed by FI) from transport X to transport Y. The latter is good
because it does not affect the flow of messagess, where as a resend does.

That is why we chose a declarative solution using WSDL and policy
assertions rather than a dynamic approach.

Having said that i think there may be a solution using HTTP as the
negotiation handshaking layer by using HTTP header fields. A request can
include a Accepts-Transport-Schemes header, that contains a list of URI
schemes, and a response can include one or more Transport-Endpoint
header that contains a URI to the endpoint using one of the schemes
specified by the client.

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109