It seems harder than the EJB case because REST services don't have a
one-to-one mapping to arbitrary Java interfaces whereas EJB services
do. We could try to do something similar to what the old 1.x
binding.atom does but I don't think that works very well and we should
try to do something better for in Tuscany 2.x. I think there's two
types of scenarios we should look at supporting:
1) developing new REST services as part of an SCA application
2) exposing existing SCA services as REST endpoints
For (1), chances are if you're a Java programmer you'll want to use
JAX-RS, its a good API that people like and if you do any searching to
learn about Java and REST these days most doc is about JAX-RS. So it
would be good to support that and have it just work the way people are
expecting. Thats the approach I was suggesting in the earlier email
with adding support for SCA annotations in JAX-RS resources.
For (2), we need a way to take an arbitrary service and map each
operation to one of the REST operations (GET, POST, PUT, DELETE) and
configure its HTTP endpoint. That sounds like binding.http and using
the new wireformat and operation selectors that are available in the
latest OASIS specs. We may be able to come up with some pre-canned
wireformat and operation selectors that can do everything needed just
from SCDL configuration but i suspect a lot of the time that wont be
enough and there will need to be a way to call out to some user
provided code to do the mapping, eg something like:
<binding.http>
<wireformat.json>
<operationselector.custom class="some.UserClass"/>
</binding.http>
How does that sound?
...ant
On Mon, Mar 22, 2010 at 3:53 PM, Raymond Feng <[email protected]> wrote:
> Hi,
>
> It is quite similar as implementation.ejb/binding.ejb. In such cases, the
> framework is a combination of business logic and communication protocol.
> Maybe we can deal with JAX-RS as follows:
>
> 1) Create an implementation type for JAX-RS applications.
> 2) We'll build a component type with services that are configured with
> binding.http to represent the resources exposed by the JAX-RS application.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <[email protected]>
> Sent: Saturday, March 20, 2010 5:49 AM
> To: <[email protected]>
> Subject: Re: JAX-RS as REST binding
>
>> On Fri, Mar 19, 2010 at 8:55 PM, Albert Tsang <[email protected]>
>> wrote:
>>>
>>> Hi All,
>>>
>>> I was reading through last year’s email threads on implementing JAX-RS
>>> support. It looks like a developer from a customer company had gone down
>>> their own implementation route of supporting bolt-ing on Jersey and
>>> putting
>>> an interceptor in place to refer REST interface requests to Jersey’s
>>> servlet
>>> as a handler. Has anyone made any headway on implementing a REST binding
>>> following JAX-RS? This would be extremely valuable and the rest of the
>>> Web
>>> 2.0 space. We’re looking to head into this direction and want to
>>> leverage
>>> anything that’s out there already, thanks!
>>>
>>> -a-
>>
>> Nothing has been done in Tuscany yet for JAX-RS integration yet. One
>> reason for that is its quite hard to see how to map from JAX-RS to an
>> SCA binding or implementation type that would work in a protocol
>> neutral way, eg a binding.jaxrs that would work with any SCA
>> implementation or a implementation.jaxrs that would work with any SCA
>> binding.
>>
>> An alternative approach to a new binding or implementation type could
>> be to give JAX-RS resources support for using SCA annotations. That
>> seems like it would be more straight forward than a JAX-RS binding or
>> implementation type and its a similar approach to whats in the SCA JEE
>> spec. There's an example of what that could look like is at
>> https://svn.apache.org/repos/asf/tuscany/collaboration/wink-helloworld-sca
>> which is the Apache Wink helloworld example updated to use an SCA
>> reference in the HelloWorld resource. That sample doesn't actually
>> work yet as Wink didn't have a hook point for the resource creation
>> that Tuscany could use, they did say though that they could quite
>> easily add one. Would this approach be of any use for you?
>>
>> ...ant
>
>
