One implementation that I had been postponing was Sun's RI, i.e., jersey. Trying to save 'hopefully' the best for last ;-). The name of the implementation has a part of the Boss's town of birth after all! Born in the USA! I am not born in the USA, but love it as much as my own country and is my home away from home! Moving on...
As before, I tweaked the simple Order Web Service example to use jersey.
- Support for a Client API to communicate with Rest Resources.
- Very Easy Spring integration.
- Sun's RI, i.e., from the source
- Support for exceptions
- Very good support for JSON Media Type
- Maven
- Good set of examples
- Automatic WADL generator
- IOC
- Embedded deployment using Grizzly
- Filters on client and server side
- Utilities for working with URI
JSONJAXBContext.JSON_NOTATION. One can quite easily change the same to use Jettison or Badgerfish convention.I was easily able to enable JSON representation for my Product resource by defining the Product data transfer objects with JAXB annotations, adding a @Produces("application/json") in the ProuductsResource class and ensuring that I have the jersey-json jar in my build.
ProductDTO.java
@XmlType(name = "product")
@XmlRootElement(name = "product")
public class ProductDTO implements Serializable {
....
}
ProductListDTO.java
@XmlRootElement(name = "productList")
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "products", propOrder = {"productDTOs"})
public class ProductListDTO implements Iterable<ProductDTO> {
....
}
ProductsResource.java
@GET @Produces("application/json")
public ProductListDTO getProducts() {
...
}
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>${jersey-version}</version>
</dependency>
There is an excellent tutorial, Configuring JSON for RESTful Web Services in Jersey 1.0 by Jakub Podlesak that you can read more about.
To support Spring integration, the web applications deployment descriptor has been modified to use the Jersey Spring Servlet. All the Spring managed beans defined by the @Component, @Service, @Resource annotations are automatically wired.
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<servlet>
<servlet-name>JerseySpring</servlet-name>
<servlet-class>com.sun.jersey.spi.spring.container.servlet.SpringServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
On the Client Side, I was pleasantly surprised by the ease in which I could invoke REST calls. As mentioned in my RESTEasy blog, jax-rs has no requirements for a client side specifications. However, those implementations that do provide one will be the ones to gain more adoption IMO. The jersey implementation provides a DSL like implementation to talk to the services. Very "VERBY", if there is no word in the dictionary like "VERBY", I stake my claim on the same :-). I modified the client from the RESTEasy implementation of the Order Service to use Jersey Client support as follows :
public class OrderClientImpl implements OrderClient {
private final WebResource resource;
/**
* @param uri Server Uri
*/
public OrderClientImpl(String uri) {
ClientConfig cc = new DefaultClientConfig();
// Include the properties provider
Client delegate = Client.create(cc);
// Note that the Resource has been created here
resource = delegate.resource(uri).path("order");
}
public OrderDTO createOrder(OrderDTO orderDTO) throws IOException {
return resource.accept(MediaType.APPLICATION_XML).type(MediaType.APPLICATION_XML)
.post(OrderDTO.class, orderDTO);
}
public void deleteOrder(Long orderId) throws OrderException {
resource.path(orderId.toString()).type(MediaType.APPLICATION_XML).delete();
}
public OrderDTO getOrder(Long orderId) throws OrderNotFoundException, IOException {
try {
return resource.path(orderId.toString())
.type("application/xml").accept("application/xml").get(OrderDTO.class);
} catch (UniformInterfaceException e) {
if (e.getResponse().getStatus() == Status.NOT_FOUND.getStatusCode()) {
throw new OrderNotFoundException(e.getResponse().getEntity(String.class));
}
throw new RuntimeException(e);
}
}
public void updateOrder(OrderDTO orderDTO, Long id) {
resource.path(id.toString()).type("application/xml").put(orderDTO);
}
}
As you can see from the above the use of the Jersey client API is rather straight forward and intuitive. One point to note is that Jersey provides a Exception framework for easily handling common exception cases like 404 etc. There are some classes that enable this support, com.sun.jersey.api.NotFoundException and com.sun.jersey.api.WebApplicationException that one can use. As I did not want to tie my data transfer object maven project to jersey in particular, I did not use jersey exceptions but instead stuck with my custom Exception Provider.
Running the Example:
The Example can be downloaded from HERE.
This example has been developed using maven 2.0.9 and jdk1.6.X. Unzip the project using your favorite zip tool, and from the root level execute a "mvn install". Doing so will execute a complete build and run some integration tests. One interesting thing to try is to start the jetty container from the webapp project using "mvn jetty:run" and then access the jersey generated WADL from http://localhost:9090/SpringTest-webapp/application.wadl
Now that you have the WADL, you should be able to use tools like SOAPUI or poster-extension (a Firefox plugin) to test your RESTful services as well.
It would be interesting to see how wadl2java and the maven plugin provided there in can be used to create a separate client project to talk to the web services.
The jersey web site has pretty good documentation about using jax-rs. It is not thorough but getting there. There are a good set of examples that one can download and try as well. It is my understanding that NetBeans has good tooling support for jersey as well.
So now that I have tried Restlet, different jax-rs implementations and jax-ws what would be my direction if I were to take a decision on what to use for my SOA project? Some food for my next blog :-)
Again, if the example fails to run, ping me...Enjoy!
2 comments:
You have a great series of JAX-RS posts. Thanks a lot!
I'd like to add one java/json library (in my opinion it is the best :) ) gson http://code.google.com/p/google-gson/
Kaspar thanks much. I was not aware of gson. Looks interesting.
Post a Comment