Hi Sam!
> The name of the MEP is SOAP Response. There may not have been a SOAP
> Request, the request may have been made out of band, etc. My
> point is
> that the MEP is defined to mean that we are simply to process the
> response. It is somebody else's job to handle what happens
> before this.
Well, on the client side, it is our job to do whatever triggers the generation of the
response, receive it, and then hand it up to the user in whatever form they like (i.e.
SOAPEnvelope for doc/lit, perhaps a deserialized Object for RPC). In the current
case, "what triggers the generation of the response" is an HTTP GET of some URL.
On the server side, it's our job to dispatch a GET of some HTTP URL into a Java method
call. We're going to need to decide exactly how to do that. I think this is really
going to be the tricky part.
> The org.apache.axis.client.Call class has an invoke method
> that takes a
> SOAPEnvelope as its only argument. How about we create an
> overload that
> takes an InputStream as its argument. It would then create a null
> RequestMessage, avoid calling invoke(), set the response Message from
> the input stream, and then return the SOAPEnvelope using the
> appropriate
> SerializionContext, etc.
I don't understand this at all. Could you give an example?
What about this for the client side:
SOAPEnvelope resp = call.getSOAPResponse();
...which takes no arguments (since there's really nothing but the URL at this level)
and makes clear what's happening. The default web method here would be GET, but to
maintain the orthogonality between WM and MEP, we can also allow someone to set a
property i.e. call.setProperty("SOAP12.WebMethod", "POST").
We could also have:
Object resp = call.getSOAPRPCResponse();
...to decode the response based on xsi:type info or metadata.
Later on, some WSDL tooling might map message structures into URLs in our stubs, but
again, that's another story.
Thoughts?
--Glen
