BTW, I think since Sun's JAX-RS representation is named after an island,
it might be a neat idea if CXF did the same.
Regards,
Glen
Am Freitag, den 07.09.2007, 03:13 -0400 schrieb Liu, Jervis:
> Hi Glen,
>
> Thanks for the input. We probably need to dig into CXF architectures and APIs
> deeper in order to understand what can be shared between “Web service CXF”
> and “REST CXF”. BTW I would use the phrase Web service CXF instead of SOAP
> CXF as CXF offered much more than just SOAP. Below are some initial thoughts
> on what CXF APIs can be reused by JAX-RS:
>
> 1.Reuse CXF front end APIs in JAX-RS: This looks good in my experimental
> implementation. Using following code snippet to start a service should appear
> familiar to any CXF users. Also it’s easy to integrate with Spring in this
> way.
>
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(BookStore.class);
> sf.setBindingId(JAXRSBindingFactory.JAXRS_BINDING_ID);
> sf.setAddress(" <http://localhost:9080/xml/>
> http://localhost:9080/xml/";);
> sf.create();
>
> Whether or not JAXRSServerFactoryBean/JAXRSServiceFactoryBean are extended
> from some common CXF frontend base classes is a matter of implementation
> details.
>
> 2.Reuse CXF DataBinding API in JAX-RS: Ideally we would like to reuse CXF
> DataBindings in JAX-RS, such as JAXB, Aegis (as well as the XMLBean and JBIX
> that hopefully will come out soon). Take our JAXB data binding implementation
> as an example, we did extend Sun’s JAXB to some extent in order to handle
> some cases that JAXB can not handle properly, such as Array, List and
> hexBinary. Reusing JAXB data binding in JAX-RS definitely sounds a saving on
> both sides. However, I haven’t figured out how to do this yet. The CXF data
> binding is WSDL-centric, it depends on the schema info from the service model
> to do the marshal/unmarshal. We could though, in JAX-RS, build up schema info
> from resource classes, then feed schema info into data bindings. Internally
> in JAX-RS EntityProvider we can make calls to databinding to do the
> read/write.
>
> 3.Reuse CXF Binding: I don’t find any concepts in JSR-311 that are equivalent
> to CXF Binding. I would say we wont need Binding stuff in JAX-RS.
>
> Jervis
>
>
> > -----Original Message-----
> > From: Glen Mazza [ mailto:[EMAIL PROTECTED]
> > Sent: 2007年9月7日 12:55
> > To: [email protected]
> > Subject: Re: [Review] Implement JSR-311 in CXF
> >
> >
> > The folks over at Sun have kept Jersey[1] separate from
> > Metro--they have
> > different codebases. This allows both Jersey and Metro to be tightly
> > fitting to the respective specifications they need to implement.
> >
> > Indeed, my past experience on Apache FOP is that the closer
> > you keep the
> > coding to the specification, the more developers you will
> > attract to the
> > project--always a good thing.
> >
> > So my feeling is that it would be good for REST CXF to be
> > coded from the
> > beginning, as if SOAP CXF did not exist, *but* for any commonality
> > between SOAP CXF and REST CXF to be factored out and shared
> > between the
> > two systems--perhaps in a commons project. Just my $0.02.
> >
> > Regards,
> > Glen
> >
> > [1] https://jersey.dev.java.net/source/browse/jersey/
> >
> >
> > Am Donnerstag, den 06.09.2007, 23:15 -0400 schrieb Liu, Jervis:
> > > Hi, I recently spent some time on implementing JSR-311 (JAX-RS: Java
> > > API for RESTful Web Services [1]) in CXF. The prototype code can be
> > > checked out from branch
> > >
> > https://svn.apache.org/repos/asf/incubator/cxf/branches/jliu. As this
> > > is still in a prototype phase, please don’t mind uncleared
> > warnings,
> > > funny hacked methods etc. Any comments or feedbacks will be highly
> > > appreciated.
> > >
> > > When I first started looking into the implementation, I
> > actually have
> > > three different design choices:
> > >
> > > The first approach is to implement JAX-RS in CXF similar to Jersey
> > > [2], using the JAX-WS Provider API as a proxy to direct request from
> > > CXF runtime to JAX-RS runtime. This might be the least intrusive
> > > approach as from the CXF runtime’s point of view, the
> > JAX-RS runtime
> > > is really just an application sitting on top of CXF. On the other
> > > hand, less intrusion means less control. Taking this approach, for
> > > example, the only information CXF runtime knows about the JAX-RS
> > > service is that it has a method exposed as invoke(T). This may gives
> > > us difficulties later on when we bring in management capabilities or
> > > introduce a service description language like WADL. Another
> > problem is
> > > a potential performance penalty. Depends on the specific JAX-WS
> > > implementation, there is always an extra time spent on transforming
> > > input stream to the T in the Provider.invoke(T).
> > >
> > > The second and the third approach are both implementing
> > JAX-RS in CXF
> > > core. What distinguished them from each other is whether or not to
> > > implement JAX-RS based on existing CXF API models. The CXF
> > API models
> > > I referred to are frontend APIs such as
> > > serviceFactoryBean/serverFactoryBean/Endpoint/EndpointInfo, Binding
> > > APIs, DataBinding APIs, Transport APIs and service model etc. As I
> > > mentioned early, the major problem with these CXF APIs is they are
> > > very WSDL-centric. To get around this, we can either
> > refactor CXF APIs
> > > so that at least the top abstract layer is suitable for both
> > > WSDL-based services and non-WSDL-based services. Or we can
> > start off a
> > > new set of APIs for non-WSDL-based services and built JAX-RS
> > > implementation on top of them. My prototype implementation
> > takes the
> > > former approach, can be briefed as below:
> > >
> > > 1. Refactored CXF APIs, so that AbstractServiceFactoryBean and
> > > AbstractEndpointFactory become the base classes that are neutral to
> > > both WSDL-based services and non-WSDL-based services. Also refactor
> > > Service interface so that it can represent both WSDL
> > service model and
> > > non-WSDL service model. The service model for JAX-RS is
> > pretty simple,
> > > it consists of resource classes and each resource class
> > consists of a
> > > set of resource methods.
> > >
> > > 2. JAXRSServiceFactoryBean extended from AbstractServiceFactoryBean,
> > > is responsible for the creation of service model, data binding etc.
> > >
> > > 3. JAXRSServerFactoryBean extended from AbstractEndpointFactory, is
> > > responsible for creating EndpointInfo, Endpoint, BindingFactory,
> > > ServerImpl etc.
> > >
> > > 4. Start a JAX-RS service would look very similar to Simple
> > or JAX-WS
> > > frontend:
> > >
> > > JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> > > sf.setResourceClasses(BookStore.class);
> > > sf.setBindingId(JAXRSBindingFactory.JAXRS_BINDING_ID);
> > > sf.setAddress(" http://localhost:9080/xml/";);
> > >
> > > sf.create();
> > >
> > > I have created a simple bookstore sample, which is located under
> > > \systests\src\test\java\org\apache\cxf\systest\jaxrs. At the moment,
> > > the JAX-RS implementation does not support sub-resource
> > locators yet,
> > > thus this service can only serve services for the following URLs:
> > >
> > > http://localhost:9080/xml/bookstore return all books
> > > http://localhost:9080/xml/bookstore/123 return book 123
> > >
> > >
> > > [1]. JSR-311 Spec: https://jsr311.dev.java.net/
> > > [2]. Jersey: https://jersey.dev.java.net/
> > >
> > > Cheers,
> > > Jervis
> > >
> > >
> > >
> > >
> > > ----------------------------
> > > IONA Technologies PLC (registered in Ireland)
> > > Registered Number: 171387
> > > Registered Address: The IONA Building, Shelbourne Road,
> > Dublin 4, Ireland
> >
>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
