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
