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