axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@apache.org>
Subject Re: SOAP 1.2, GET, and Axis
Date Mon, 01 Jul 2002 15:36:36 GMT
Mark Baker wrote:
> 
> I understand what you're getting at, but I think you're missing the
> point of the new MEP;
> 
> http://www.w3.org/TR/soap12-part2/#soapresmep
> 
> The idea is that HTTP GET can be used to retrieve a SOAP envelope.
> So if we have a URI for a resource;
> 
> http://some-host.org/my-soap-calendar
> 
> and I do a GET on it,
> 
> GET http://some-host.org/my-soap-calendar HTTP/1.1
> Host: some-host.org
> Accept: application/soap+xml
> 
> then I could get back an XML iCalendar object encapsulated within a SOAP
> envelope.
> 
> There is no SOAP request in this case.  There is only an HTTP request,
> and a SOAP/HTTP response.  This is how we designed it to be used.
> 
> Make sense?

The light bulb is starting to flicker.  Some brainstorming to follow:

At a relatively low level on the client side, you are correct that some 
form of Call.setTargetEndpointAddress() coupled with an API which 
enables the caller to explicitly specify the MEP desired, perhaps with a 
Constant defined as a convenience to equate to the value 
"http://www.w3.org/2002/06/soap/mep/soap-response/" would do the trick.

Most of this support needed would probably go into 
org.apache.axis.transport.http.HTTPSender.

On the server side, org.apache.axis.transport.http.AxisServlet.doGet 
would need to be modified - currently it pretty much assumes that HTTP 
GET requests with a path are requests for WSDL generation.  Instead, it 
would need to put the path and method into the msgContext as properties.

Transport specific handlers could be provided to map this to SOAP 
requests.  For implementation simplicity initially, they could generate 
an equivalent SOAP message purely internally.  As GET requests are 
likely to be relativey short, this may not turn out to be overly 
expensive.  We could predefine a few - say one that takes a slash 
delimited path and separates out each part; and another that is modelled 
after HTTP GET.  The former may find greater usage in document style 
requests, the latter RPC.  In any case, those that develop their own 
services would be free to define their own.

>> Section 4.1.1 of the SOAP 1.2 spec implies that such is out of scope for
>> the SOAP specifications, and hints to WSDL as the appropriate place.  I
>> can certainly accept this, but lets go full circle and reexamine your
>> first post to this mailing list:
>>
>> > I've had a look through the archives, and haven't found any discussion
>> > about what the Axis team is thinking about doing to support the
>> > "Web Method Specification Feature"[1] of SOAP 1.2 when bound to HTTP.
>> > I'm specifically interested in GET support.
>>
>> Perhaps we should be looking to the Web Services Description Working
>> Group to provide more details first?
> 
> I don't think that's necessary.  SOAP 1.2 is independant of WSDL.

I guess that depends on what our goals are.  If we are looking at 
defining point to point requests which presume that developers are 
comfortable coding at a relatively low level interface to achieve this 
(pretty much the current web monkey developer community), then the above 
achieves this goal.

Just recognize that the same toolkits will also be providing WSDL 
tooling that will make it easier and less error prone to define the now 
more traditional HTTP POST requests.  So while the above support would 
enable HTTP GET requests, I fear that many (most?) will follow the path 
of least resistance and continue to do HTTP POST.

For this to change, we will need to find some way of providing enough 
metadata so that toolkits can automatically and correctly identify the 
resources associated with such requests as 
"updateQuantityInStock(PartNumber="123", NewQuantity="200") and 
"getQuantityInStock(PartNumber="123").  Both of these examples are from 
the SOAP 1.2 spec, part 2, section 4.1.

- Sam Ruby


Mime
View raw message