IMO, using HTTP/GET to access the RPC style services is just a poor-man's web service. Don't go deeper to support complex types, don't try to support POST, because that will reinvent the wheels that either WS-*, REST, or JSONRPC already handles.
If you don't like the JAX-RS annotations to provide the @name for the parameters, maybe we can just support arg0, arg1, ..., argN or being positional. Anyway, JAX-WS/JAXB seems to have the "arg" conventions. Thanks, Raymond ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Aug 28, 2010, at 12:48 AM, ant elder wrote: > On Sat, Aug 28, 2010 at 12:15 AM, Luciano Resende <[email protected]> > wrote: >> On Fri, Aug 27, 2010 at 3:45 PM, ant elder <[email protected]> wrote: >>> On Fri, Aug 27, 2010 at 11:08 PM, Luciano Resende <[email protected]> >>> wrote: >>>> On Fri, Aug 27, 2010 at 2:34 PM, ant elder <[email protected]> wrote: >>>>> On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <[email protected]> >>>>> wrote: >>>>> >>>>>> But, stepping back, >>>>> >>>>> Ok lets do that, so we've got the composite at >>>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/src/main/webapp/WEB-INF/web.composite >>>>> with component service HelloworldComponent/HelloworldService and the >>>>> service interface is: >>>>> >>>>> @Remotable >>>>> public interface HelloworldService { >>>>> String sayHello(String name); >>>>> } >>>>> >>>>> That works for bindings like sca, ws, rmi, etc, and now we want to >>>>> expose it as an http endpoint. We shouldn't need to add any >>>>> annotations or modify the service interface or impl. We need to encode >>>>> the operation name, the parameters, and perhaps the format to get the >>>>> response back in (eg xml or json perhaps). The operation name could be >>>>> part of the url, in this example theres a single string parameter so >>>>> using the url query parameters seems useful but if the parameters were >>>>> more complex you might want to use xml or json with an http post >>>>> request. >>>>> >>>> >>>> +1, if you have a good solution for mapping HTTP Verbs to Service >>>> operations without any type of configuration, or convetion as in the >>>> Collection itnerface, please feel free to share. >>>> >>> >>> This wouldn't have any mapping from http verbs to service operations, >>> its not trying to be restful just expose an sca service as an http >>> endpoint. All the service operations just use get and/or post. >>> >> >> Are you assuming this scenario in particular ? Or limiting services to >> have only one operation ? In real life examples, we usually want to >> expose existent services, which has multiple operations, in a restful >> way. In this case, how would you say that, when you are doing a HTTP >> GET, on a giving resource (or resource pattern), you want it to map to >> a given operation ? If you look in the JAX-RS specifications, you >> would see several examples of these patterns, and I'm just using >> JAX-RS as an example as the spec samples would be applicable outside >> of the scope of JAX-RS. >> > > This approach works fine with multiple service opperations: > > http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello > http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayGoodbye > http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/doSomethingElse > > Whats the problem? > > This is not REST, its not doing a get on a resource its just exposing > a service operation as an http endpoint. > >> >>>>> So that would be things like an http get >>>>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello?name=petra, >>>> >>>> The problem with this is that there isn't a good way to find the >>>> parameter name at runtime, and that's why JAX-RS created such >>>> annotations to do the map (e.g QueryParam, etc) >>>> >>> >>> The http get format is really only useful for trivial request >>> parameters so it can be simple - just use the order the parameters >>> appear in the query string, so for java method parameter mapping the >>> query parameter name could be ignored. >>> >> >> If you look into various APIs that use this pattern to leverage the >> power of HTTP GET Cache (e.g multiple google apis, flickr, etc), you >> will note that usage of GET can become complex, and I really don't >> like the idea of failing the user request because a user didn't send >> name as the second parameter... also, how would you handle arrays, >> which you don't know how many entries will be sent to the invocation ? >> > > Arrays would work fine and there are a lot of those API calls that > would work fine too. For the more complex or esoteric ones we can add > more config to the binding as you're already suggesting with extra > wireFormat/operationSelectors that could map query parameters to > operationParameters. > >>>>> or an http post >>>>> http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello >>>>> with a json or xml request body. And perhaps an accept header could >>>>> define the default for what type or response is returned eg xml or >>>>> json (or javascript too and then we wouldn't need the jsonp binding). >>>>> >>>> >>>> You mean, content-type on the post identifying that you are providing >>>> json or xml. Agree, but I think we should support both scenarios, a >>>> dynamic one and a "hard coded" one where the service will only output >>>> what is specified on the wireFormat. We probably need some >>>> enhancements on our databinding framework to better support mime >>>> types, and our rest binding does provide most of this trough the wink >>>> integration. >>>> >>> >>> Sure ok but we could start with the one wireFormat and >>> operationSelector that do all whats described above, and then later >>> add others to restrict the format to xml or json etc. So if this was >>> added to the existing rest binding then if these were called foo it >>> would be: >>> >>> <binding.rest> >>> <wireFormat.foo/> >>> <operationSelector.foo/> >>> </binding.rest> >>> >>> or if it was the http binding perhaps >>> >>> <binding.http> >>> <wireFormat.httpDefault/> >>> <operationSelector.httpDefault/> >>> </binding.foo> >>> >> >> Please take a look for some of the previous discussions on this subject >> >> http://www.mail-archive.com/[email protected]/msg11988.html >> > > I have, this is the same as i was suggesting back in those previous > discussions. > >>> and as those are default wireFormat and operationSelector that would >>> be the same as just <binding.http/> >>> >>>>> Does that all sound reasonable so far, if so we can then map that in >>>>> to what sca binding, wireformat and operationSelector elements could >>>>> look like. >>>>> >>>> >>>> Are you mostly concerned with extra extensions to these elements to >>>> provide additional configuration in a declarative fashion without >>>> requiring the pollution of the business interface with jax-rs >>>> annotations ? >>>> >>> >>> Certainly requiring the use of jaxrs annotations for it to work >>> doesn't seem right to me. >>> >> >> Well, it's not that it's required... > > Well it looks like it _is_ required presently, the current > binding.rest doesn't work with this simple helloworld service! > >> users have the option to use >> convention over configuration such as using the Collection interface, >> but I heard lots of complaints about it before, particularly when >> users were trying to reuse existing components. I believe JAX-RS >> annotations is better then Collection interface in this case (and they >> are a standard), but declarative mapping would be the ideal. >> > > Sure there are scenarios where we'll want more control and JAX-RS > gives us that, and we do already support that with > <implementation.jaxrx> and this <binding.rest>. In this example though > we're not looking to create restful endpoints, arbitrary sca services > usually are not restful so we just want a way to expose the service > operations over http. > > ...ant
