axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Baker <>
Subject Re: SOAP 1.2, GET, and Axis
Date Tue, 02 Jul 2002 02:32:26 GMT
On Mon, Jul 01, 2002 at 11:36:36AM -0400, Sam Ruby wrote:
> The light bulb is starting to flicker.  Some brainstorming to follow:

Alright, now we're cookin'!

> 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 
> "" would do the trick.

I think it should be ok to default the MEP to .../soap-response/ when
GET is specified as the Web method, since that's all SOAP 1.2 specifies.
But the developer should be able to specify a different MEP too.

Stuart Williams proposed the opposite[1] (derive the method from the
MEP), but I'm going to respond to him shortly, disagreeing strongly.

> 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.

I've done some digging, but I can't figure out what you mean here.  I
guess that's ok.

> >> 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.

Yes, that is my goal, so it's good to hear that's what you had in mind
above.  I just wouldn't call it a "relatively low level interface", but
perhaps that's simply a nomenclature issue.

> 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.

That's certainly possible.  But in my experience, GET can be quite
infectious.  WSDL-over-GET caught on like wildfire, for example.
I guess we'll see how it works for the service itself.

> 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.

In general, it's not automatable, because deciding what's a resource and
what isn't is a design decision.  But if you're up for it, I'd be
interested to see how far you could go with that. 8-)


Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.     

View raw message