If I understand the question:

Perhaps you've already seen this on the CXF documentation pages:
http://cxf.apache.org/docs/jax-rs-and-jax-ws.html     This does work as we
had tried this in POC.  In fact, we when you browse the "services" page
after deployment and startup, there are the 2 sections displayed - one with
info about the JAX-WS service (list of methods on left and WSDL link and
namespace info on right).  Then below that section on the same page is the
JAX-RS  endpoint information with a link to the WADL

Assuming the @WebMethod annotations and @Path annotations applied to the
same method (CXF supports this - having both types of annotations on the
same method).

Class-level annotation:

@Path("/bookservice")
@WebService(serviceName = "BookOrderManagerService", portName =
"BookOrderManagerServicePort", endpointInterface =
"com.acme.book.webservices.BookOrderManagerService")
@HandlerChain(file = "handler-chain.xml")
public class BookOrderManagerWS implements BookOrderManagerService  {



Method-level annotation:


    @GET
   @Produces( { MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
   @Path("/{bookID}")
   @WebMethod
   public Book getBook(@PathParam("bookID") @WebParam(name = "bookID")
String bookID) throws ServiceException {


The endpoint can service both styles of calls.  Since the logic INSIDE the
method should be delegating to the business layer service and DAO classes
which have nothing to the do with the "web service" part itself and simply
are creating the objects and/or graph of objects (Lists, etc), it can be an
effective way to share/reuse such logic and serve the result back as either
SOAP or JSON.  And in either case, the consuming client would be relying on
either simply getting the deserialized SOAP message into an object
(JAX-WS/JAXB) or in the case of JAX-RS, either the raw JSON or an object
result that is created by JAXB/JSON deserialization provided by something
like the Jackson framework.

The question is, if you're certain the objects (XSDs) and method signatures
can stay in sync - it's a decent way to go.  If at some point, you expect
the SOAP based (JAX-WS) interface to have to change ... while the REST
(JAX-RS) would not - you likely may want to keep them separate.

You also have to consider that testing/deploying changes to something like
this (where you alter one behavior without intending to affect the other),
can add risk to breaking logic that is bundled together this way. Adversely
affecting both - ie: you made changes to the JAX-WS  part only, and
inadvertently introduced something that breaks the JAX-RS part .

My 2 cents.

Mark

On Sat, Mar 9, 2013 at 3:28 AM, srinivas thallapalli <
[email protected]> wrote:

> Hello,
>
> Is it good practice to make the same service as both JAX-WS and RESTful?
>
> Thanks
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/JAX-WS-and-RESTful-for-same-service-tp5724330.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>

Reply via email to