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. >>> 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 ? >>> 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 > 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... 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. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
