dev@jax-ws.java.net

Re: SOAP/TCP transport?

From: Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_Sun.COM>
Date: Tue, 24 Oct 2006 16:53:51 -0700

Paul Sandoz wrote:
> Kohsuke Kawaguchi wrote:
>> I liked the following better:
>>
>> <service name="TestService">
>> <port name="TestServicePort" binding="tns:TestServiceBinding">
>> <soap:address
>> location="tcp://localhost:5774/WSpex-tcp/TestService"/>
>> </port>
>> </service>
>>
>> I thought the above is enough to hook up the transport. Why is the
>> additional policy declaration needed?
>>
>
> If a service supports both the HTTP transport and the TCP transport then
> we wanted the the client to automatically select the most optimal and
> appropriate transport without the developer having to make any changes
> to their code. (same for FI, when clients and services know each others
> capabilities they can automatically, when configured to do so, choose
> the optimal route.)
>
> The two port model (two ports, one using TCP and one using HTTP, with
> the same port type) makes this tricky to do given the current JAX-WS
> client API (it is possible but i felt we would not be conforming to the
> JSR i.e. returning a port that is not the one requested).

I see. When you only have:

     <binding name="AddNumbersBinding" type="tns:AddNumbersPortType">
       <soap:binding
         transport="http://schemas.xmlsoap.org/soap/http"
         style="document" />
       <ns:OptimizedTCPTransport
xmlns:ns="http://java.sun.com/xml/ns/wsit/2006/09/policy/soaptcp/service"
          enabled="true"/>/

how do you figure out what TCP port to connect to?


> We definitely would like to go the route of the two port model in the
> future for WSIT if the JAX-WS client APIs can be massaged or interpreted
> creatively :-)
>
> IIRC the two port model can be supported now, and that could be the
> approach for none WSIT use.

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.

-- 
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi_at_sun.com