On Fri, Mar 26, 2010 at 7:35 AM, ant elder <[email protected]> wrote: > This approach makes more sense to me as its pretty much the same as > the initial suggestion ;) I'm not sure that we really need an > implementation.jaxrs though as there is already implementation.web > which works for all the other JEE web resources like Servlets, JSPs, > JSF components etc so why shouldn't JAX-RS resources just be included > in that? Perhaps we could support both > implementation.web/implementation.jaxrs if thats going to make > everyone happy. > > ...ant > > On Fri, Mar 26, 2010 at 12:34 AM, Raymond Feng <[email protected]> wrote: >> Hi, >> >> Since you brought up JMS, I think the JAX-RS application is more like a >> "MDB" for http. It will be bound to HTTP but it doesn't provide RPC style >> services for other components to consume directly (without going through a >> http client). >> >> Maybe we should start with an implementation type implementation.jaxrs. The >> component type won't have any services. When the component is started, we >> register the application (via a Servlet from the JAX-RS server such as >> Apache Wink) to the ServletHost. Once it's working, we can explore other >> possibilities such as: >> >> * Allowing SCA annotations (especially @Reference/@Property) to be used with >> JAX-RS classes so that they can talk to other services (SCA or non-SCA). >> * Building a RESTful client story so that SCA components can talk to RESTful >> services. >> >> If we like this approach, I can start to produce a prototype based on Apache >> wink. >> >> Thanks, >> Raymond >> -------------------------------------------------- >> From: "Simon Laws" <[email protected]> >> Sent: Thursday, March 25, 2010 10:12 AM >> To: <[email protected]> >> Subject: Re: JAX-RS as REST binding >> >>> On Thu, Mar 25, 2010 at 4:42 PM, Raymond Feng <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> Do we really want to allow arbitrary SCA services to be exposed to be >>>> RESTful? REST (resource-oriented) is quite different from RPC >>>> (operation-oriented). IMO, the component has to be designed following the >>>> RESTful style where we might have a few different options: >>>> >>>> * Use an interface that is compatible with the Collection pattern >>>> * Use JAX-WS annotations to customize the mapping >>>> >>>> Thanks, >>>> Raymond >>> >>> Good question. >>> >>> In SCA JMS land, for example, you can use an interface that includes >>> just onMessage() if you want to get close to the binding protocol or >>> you can use some arbitrary interface and map to it. >>> >>> Now REST is slightly different as there are get/put etc. semantics >>> involved. . I'm not keen on creating more work than absolutely >>> necessary but maybe a way to answer this is to ask what if we did >>> allow an arbitrary interface. What rules would that interface have to >>> obey in order to operate in a RESTfull way? >>> >>> The default answer is I guess the rules/configuration that JAX-RS >>> describes. Which means the binding has to do quite a bit of work to >>> fill in the blanks in terms of the kind of features that JAXRS would >>> provide. >>> >>> Simon >> >> >
I'm starting to warm to this approach. It gives us support for the programming model with a minimum of effort in the first instance. I think, given the discussion, It seems sensible to experiment with the programming model in the context of implementation.web and see how we feel about any additions/changes that might be needed once we better understand it. The client side is certainly very interesting. One of the things we lack is good tools for retrieving HTTP based resources. There are lots of applications that make use of this kind of feature and, in particular, combine it with other distinct services to filter, process and analyze the results. Good sample material. Simon
