Peter,
We are in the process of refactoring the JAX-WS code to address this
issue and some other issues. The refactored JAX-WS will be much more
pluggable, especially in the transport area. It is also significantly
faster. The refactored JAX-WS will not make it into Java 6 but will be
available standalone and part of glassfish. I cannot give any dates for
it at this time.
Peter Hendry wrote:
> Looking through the source for JAX-WS I am surprised to find that the
> runtime is specifically tied to HTTP in a number of places (many
> places you would expect it to be transport independent). The most
> obvious place is the requirement that the message context contain
> various Servlet specific properties, but the EPTFactory also supports
> only SOAP HTTP in a hard-coded fashion.
>
> As JAX-WS is heading to be included in JDK 1.6 I am surprised to find
> such a limited implementation. How are JMS and other transports to be
> supported (not necessarily by Sun) as extensions to the JDK 1.6
> runtime? If this is to make the JDK compete with .NET then this is a
> serious limitation is it not? At a minimum it should be possible to
> plug in a JMS transport as that is part of any J2EE platform.
>
> I am curious to know whether there are a) any plans to remove the
> explicit dependencies on HTTP before inclusion in JDK 1.6 and b)
> whether the places that such dependencies exist may become pluggable
> by the time JDK 1.6 is release with the JAX-WS runtime?
>
> Other technologies such as JBI (into which JAX-WS may be plugged) and
> other vendor implementations (including our own) of Java web service
> SOAP stacks are generally transport independent allowing third-party
> transport implementations to be easily added. What is the logic behind
> only supporting HTTP and providing no pluggability of transports? The
> fact that only the HTTP binding is specified by the SOAP specification
> is not a justification as the SOAP specification is also open to the
> addition of other transport bindings.
>
> Note that I have no problem with Sun only providing an HTTP transport
> implementation, the problem is with the creep of the HTTP transport
> code into the core runtime classes/APIs making the addition of other
> transports difficult or impossible.
>
> Pete
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>