Glen Daniels wrote: > > 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. > 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. - Sam Ruby
