axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: SOAP 1.2, GET, and Axis
Date Wed, 03 Jul 2002 09:49:43 GMT
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 (modulo those awful
> 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 

> MB

- Sam Ruby

[*] Mark appears to have a sense of humor.  Let's test that assertion.

View raw message