> > Well, on the client side, it is our job to do whatever triggers the > > generation of the response, receive it, and then hand it up to the > > user in whatever form they like (i.e. SOAPEnvelope for doc/lit, > > perhaps a deserialized Object for RPC). In the current case, "what > > triggers the generation of the response" is an HTTP GET of > some URL. > > I'm trying to get you to think outside the box. What you describe is > very client/server. On a OneWay call, our job is to issue > the request > and nothing more. I therefore think it would be reasonable to define > ResponseOnly MEP as response only, and nothing before.
Except that SOAPResponse doesn't say "a response appears out of thin air", it defines "the exchange of a non-SOAP message acting as a request followed by a SOAP message acting as a response." [1]. > > On the server side, it's our job to dispatch a GET of some HTTP URL > > into a Java method call. We're going to need to decide exactly how > > to do that. I think this is really going to be the tricky part. > > 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. +1 --Glen [1] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#bindinfdesc2
