Jersey or Wink on WebSphere

Question

We are looking at which REST framework to use and where to run it.

Given an existing WebSphere (6.1.0.17) environment would you use Jersey of Wink?

Or would you recommend a different platform?

Answer 1

I have no experience in using Wink, but I can share some of my experience in using Jersey running on Websphere.

The pros... very easy to use, it took me 5 minutes to get familiarized and I'm ready writing my first hello world. Jersey does automatically generate WADL for you based on your Resources package, albeit pretty basic... but you can customize the WADL documentation yourself.

The cons... sigh, I like Jersey, but with Websphere, it almost made me cry. First (this is not related to Websphere), I'm using Spring in my project and the Jersey release I use is 1.2. The problem is that release uses Spring 2.5 whereas I'm using Spring 3.x. So, I pulled out Jersey's Spring 2.5 to use Spring 3.x. Everything works fine. However, the Jersey test framework started to fail. I'm not able to boot up the built-in Grizzly server to test my web services anymore. Second, I'm currently tied to Websphere 6.1 which uses JDK 5. I believe all Jersey releases after 1.2 are compiled with JDK 6... that means, I'm out of luck until my company upgrade to WAS 7.

It is indeed a very stable Rest framework, very easy to use... but in my case, I'm just bummed out because all existing unit tests for the web services are currently commented out because I upgraded my Spring release to 3.x. I'm sure the latest Jersey release should be using Spring 3.x by now, yet I can't use them because I'm still using JDK 5 in WAS 6.1.

So, it's up to you to decide. By the way, I'm still using Jersey 1.2 in my project running in WAS 6.1.

Answer 2

On websphere 6.x the prefered method is jersey because it is easier to implement and it supports JAX-RS 1 and 2. (Watch out for the JVM version issues, Websphere 6 might not support the latest version)

Now starting in Websphere 8.x IBM introduced Apache Wink that will actually bring dependency and classloader issues if used together with jersery (because of the same interface implementations for JAX-RS 1 and 2).

There are a lot of examples on how to overcome this issues and make it work but I don't believe is worthy and perhaps Wink will have a better performance within websphere.

Answer 3

IBM recommends to use Apache wink. In fact, IBM has his own implementation of Apache wink.

Answer 4

I vote for Wink.
The reasons:

1. It's developed by HP and IBM guys. So I believe that IBM guys tested it with Websphere.
2. Actually AFAIK Wink is built-in in the Websphere 7.*
3. Also see this video

Answer 5

As a third option why not use Spring's own RESTful features in Spring MCV. This is easy to code, test and maintain and (obviously) works for Spring right out of the box. The ease of managing code based on Spring REST is due to an architecture based on MVC, IoC and annotations. And you can choose best in class solutions to enhance your solutions such as XStream for serialization, Jackson JSON Support, and Springs own REST Template for a REST Client or unit-tests.

At its heart Spring MVC's REST features deal with REST as an Architecture not a Protocol and blends it well with other proven approaches such as IoC and MVC. When considering a framework the following REST litmus test is useful: see innoq.com/blog/st/2010/07/rest_litmus_test_for_web_frame.html.Springs approach checks more of the boxes, thanks to it's effective content delivery.

One thing all these frameworks fall down on is HATEOAS support, a way of in which the REST response contain links that correspond to all the actions that the client can currently perform from this resource. Most frameworks promises to introduce this soon, but a critical eye will be needed to understand what the best approach to this will be.

When delivering JAX-RS solutions such as Wink and Jersey, I've found more emphasis on conforming to a Java standard and less flexibility in the architecture (such as using other 3rd party packages). If conforming to JAX-RS is a requirement consider Restlets, Wink or Jersey. Otherwise, maybe it's worth considering Spring MVC's REST support.

I've deployed this kind of solution to WAS 7 without any issues or dependency conflicts.