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 > "http://www.w3.org/2002/06/soap/mep/soap-response/"; 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-) [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0000.html MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. [EMAIL PROTECTED] http://www.markbaker.ca http://www.idokorro.com
