dev@ws-test-harness.java.net

Re: Updated the harness to support the sts

From: Bobby Bissett - Javasoft <Robert.Bissett_at_Sun.COM>
Date: Mon, 02 Oct 2006 12:45:40 -0400

>
> Yes. I thought one of the points of MEX is its transport independence.
> So I think it's unfortunate if our MEX implementation doesn't take
> advantage of that.

As I mentioned somewhere in the thread (likely buried by now), one part
of mex is *not* transport independent, so at some point I have to use
http. There is a "location" element in a mex response that is defined as
pointing to a document that can be retrieved with an HTTP GET call.

>
> I thought a natural implementation of MEX would use the JAX-WS runtime
> as the transport mechanism, hence it would automatically gets the
> transport independence from there.

The mex code works a lot like wsimport code, which doesn't use the
jax-ws runtime to retrieve the data. It's just getting a document from a
server, so the code is very streamlined. In the future, I'd like to plug
into jax-ws better, but for now it just doesn't work that way. Creating
a pipeline at tool time just to get a wsdl file seems like more work
than we need, though it would certainly make testing easier. ;)

One approach to writing the mex client code would have been to use
Dispatch (I think this is what you're suggesting) to send the mex
request, but that seems like overkill to me. The request message is
always known, so I can just stream it into the http connection. I also
need to be able to send with soap 1.1 and soap 1.2 requests, which would
mean having two sets of jax-ws objects to call instead of just creating
two strings.

> [...]
> If I remember correctly, Bobby had another requirement that he needed to
> deploy a servlet that he uses to emulate a bogus response.

Yep, that's the way the tests were written. If we start using the
runtime transports at tool time, then your suggestion of just having a
pipe the sends the responses would work. Or a jax-ws handler could
probably do it, but there are two pesky details. One is the
http-dependent part of the mex spec, and the other is that I need to be
able to deploy a service that will not answer ?wsdl requests in order to
make sure wsimport isn't succeeding to get the metadata when mex is broken.

Thanks,
Bobby