Mark Baker wrote: > You guys are losing me. OK, I will try to speak in one syl a ble words this time. [*]
> A developer has to know that a GET is being performed, the same way > they have to know that any method is being invoked, because it has > meaning specific to the task they're trying to accomplish. For some set of developers and some set of tasks, true. > Sam's suggestion to punt the retrieval of the response is fine from > this POV, but I wonder what developers would think of it, and I'm not > sure it would technically be conformant to the spec (though maybe the > spec needs fixing). This innuendo I find deeply disturbing. One thing I feel very strongly about is that SOAP is a wire level protocol, nothing more, nothing less. I could chose to implement the soap12-part2/#soapresmep in Perl CGI as a series of print statements and as long as the bits that flow across the wire match the specification, I'm golden. As for what developers will think of this - in my mind, there won't be mass adoption until there are WSDL bindings to all of this, but only time will tell. > Glen's getSOAPResponse() method is confusing to me, because there > already exists a way to invoke methods on objects, setOperationName(). > Why would having two ways of doing the same thing be desirable? And if > you're going to create a different way, why not reuse an existing one, > like java.net.URLConnection.getContent() (modulo those awful java.net > HTTP issues)? I believe that you are mixing meta levels. The setOperation name is a way to modify the name of the root element of the soap body. It's name may be unfortunate, as it presupposes a presumes a purpose for that element, but such a bias is explainable given that the name of that method was defined in a specification named "JAX RPC". However, merely because the method may be inappropriately named does not justify hijacking it for another purpose. As far as reusing URLConnection, there is no question that that class or something like it will get used. The question we are trying to explore is to what level should HTTP, and the Java interfaces thereof, be exposed to the developer. Should this be encapsulated by a transport level or directly manipulated by the developer? The three basic approaches I have seen discussed so far in this thread can be loosely described as: 1) Expose the HTTP classes directly. 2) Expose the HTTP semantics directly, via new names on the existing SOAP classes. 3) Encapsulate the HTTP semantics and expose the underlying concepts in a protocol neutral fashion. > I understand that this a very different way of thinking of SOAP, i.e. > not as a layer, but that's what the Web Method feature is for; exposing > HTTP, through SOAP, to the developer. I just want to note that at some point, many developer don't want to think in terms of HTTP or SOAP, but rather in terms like getQuantityInStock(PartNumber="123"). > > MB - Sam Ruby [*] Mark appears to have a sense of humor. Let's test that assertion.
