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?
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.
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.
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.
IBM recommends to use Apache wink. In fact, IBM has his own implementation of Apache wink.
I vote for Wink.
The reasons:
It's developed by HP and IBM guys. So I believe that IBM guys tested it with Websphere.
Actually AFAIK Wink is built-in in the Websphere 7.*
Also see this video
Related
I have a very small Java codebase that I would like to expose as a REST service that responds in JSON format (to be used by a Ruby on Rails project).
I have only notions about Java web servers / web frameworks. What would be:
a. a suitable Java MVC and
b. a java server
to ease my deployment? I am interested in:
easy to build(wrap) the solution
easy to maintain / configure the server
stable (not experimental)
We use CXF extensively. It is very simple standard JAX-RS annotation based. There is a good tutorial to set it up quickly. It works with or without Spring, but easier with spring, this is my preference. The other option would be Spring REST it is very similar to Spring MVC which is very easy if you know spring already, but on the other hand it is not JAX-RS based.
you might want to give Grails a try - it:
shares some similarities with RoR
comes bundled with an application server so it's very easy to get up and running
allows very simple deployment to a Java application server (e.g. Tomcat, Jetty)
has built-in support for JSON
has recent stable releases
is under active development
http://www.restlet.org/
http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html
https://github.com/dhanji/sitebricks (my favorit)
For the server part of the problem, build your code so that it is a servlet and then deploy in a container like Tomcat or Jetty. (There are many others too, but Tomcat and Jetty work very well and are pretty easy to use.)
For the framework, I'd recommend CXF (I've had good success with it in my project) as it keeps the amount of configuration you need to write small (typically just add annotations to mark which methods are to be exposed; the annotations are standardized as JAX-RS), but many others are valid choices too.
Which is a good java REST framework?
I would like it to be deployed with Tomcat 6.
Also you can try Spring Framework 3.x.x.
You can try RESTEasy. It isn't application server dependent. (Doesn't require an AS at all).
You can also try an alternative, but you really should use a JAX-RS implementation :
Jersey
Restlet
Wink
See my answer on: RESTFul Web Development with Java EE 6:
I'd recommend you have a look at:
RESTLet
Play
Grails with the REST plugin for Grails
Jersey
RestEasy
(One question though: why specifically
do you need to be able to integrate
with Java EE?)
EDIT: In the case where you absolutely
want to use the Java EE APIs, then as
mentioned by BalusC, JAX-RS is
your solution of choice. Restlet and
Jersey both support it. I don't know
about RESTEasy, but the JAX-RS
Wikipedia page mentions it does.
AFAIK, Jersey is the JAX-RS reference implementation. I've used it several times for REST webservice servers.
Minimal configuration, wide use of Annotations
Runs in Tomcat, Grizzly, GlassFish and many others...
The best part, the Jersey Test Framework makes it really easy to completely test your service.
I've had a pretty good experience with Jersey. It's pretty easy to integrate it with Tomcat.
I have had good experiences with Restlet: http://www.restlet.org/
Here is a tutorial on running Restlet in Tomcat: http://danilogurovich.wordpress.com/2008/09/23/a-simple-restlet-demo-application/
Here's the best and easiest: http://sparkjava.com/, it works standalone. And here is how http://sparkjava.com/documentation.html#other-webserver to make it work within a server.
http://www.crnk.io/ might also be of interest. Unlike the other libraries here, it can be considered to be a native resource-oriented library and along the way offers various higher-level features like sorting, paging, inclusions, bulk-updates, etc. out-of-the-box.
Play! framework is very good, also more easier than Jersey. You can use with or without tomcat.
Has anyone done this or attempted to do this for a preexisting project?
It seems there are two options to go with here, either using the embedded EJB API basically the following class
javax.ejb.embeddable.EJBContainer
Which expects a configured glassfish v3 install to be available (application scoped resources will make this easier).
The alternative is using the embedded glassfish jar files and the embedded glassfish API
I am looking for feedback from someone who has or who is in the process of doing this, links to blogs etc with a simple EJB & test case are dime a dozen.
If you've done this with any other EJB 3.1 container feel free to share.
Did you use any particular test framework for reasons other than it been your preferred tool?
Which JPA 2.0 implementation did you use, and was there a particular reason for doing so?
If you used glassfish which of the above strategies did you use? If not then which EJB 3.1 container did you use?
If you successfully did this, was it worth the effort and would you do this again for another existing project?
It seems there are two options to go with here, either using the embedded EJB API (...) which expects a configured glassfish v3 install to be available.
No, you can also use a minimal domain inside your project.
I am looking for feedback from someone who has or who is in the process of doing this, links to blogs etc with a simple EJB & test case are dime a dozen.
I've done integration testing of EJB 3.1 and JPA on my pet project (under Maven), inspired by Unit Testing EJBs and JPA with Embeddable GlassFish. Reading it is definitely worth it.
Did you use any particular test framework for reasons other than it been your preferred tool?
Nope.
Which JPA 2.0 implementation did you use, and was there a particular reason for doing so?
I used EclipseLink (because it was available at that time).
If you used glassfish which of the above strategies did you use? If not then which EJB 3.1 container did you use?
I used the Embedded EJB API, I was planning to run my code on other Java EE 6 containers when they'll be available.
If you successfully did this, was it worth the effort and would you do this again for another existing project?
Well, I think that integration / functional testing have value and find that the Embedded EJB API is really nice for that. It was not a pain to use it even if I don't consider my sample as a real life project.
For more complex scenarios, I keep an eye on the maven-embedded-glassfish-plugin (see also this answer).
I have written a small tutorial on my blog for using embedded glassfish 3.1 for unit-testing EJBs using javax.ejb.embeddable.EJBContainer. There are some pitfalls to it, which I got around by modifying the default embedded glassfish domain and putting some properties to createEJBContainer() call.
Currently I am evaluating number of web service frameworks in Java. I need web service framework that will help me to expose some functionality of existent application running on JBoss, The application is mostly developed using Spring and POJOs (no EJBs).
What I need is a framework having following properties:
It should provide tools for automatic generation of boilerplate code and save time by eliminating repetitive tasks, for example tools generating WSDL from Java (java2wsdl), tools generating endpoints etc.
Applications should be easily deployed on existent J2EE platform (JBoss), this means that it should contain as less as possible configuration files (like axis2.xml in axis2 framework).
Also it is preferred to be able to deploy web service within .war archive of existent application. (it seems that Axis2 need a separate archive for web service app.)
It will be very cool to use a combination of POJOs and Spring.
Generally, the framework should have clean structure and design (for example Spring-WS lacks it), good documentation and whatever else characterizes a good piece of software.
It is preferred that framework incorporates some standard features like JAX-WS etc. instead of vendor specific methods.
I have briefly examined
Axis2
Apache CXF
and Sun's Metro
Spring WS
But still it is difficult to decide what to use in my case:
Axis2 seems to be so low level, it requires separate application archive and lots of configurations
Spring WS seems to be too opaque and "sophisticated for impression purposes (?)"
Apache CXF and Metro probably are two frameworks that I prefer to chose from but still
I need your opinion and experience about usage of some of them in a real-world applications.
I've used CXF's forerunner, XFire, for a while now and it's not been too bad. At the time, we migrated from Axis for two major reasons: performance and ease of development. At the time (don't know if this is true now), the performance of XFire was much better than anything out there, and with annotation-driven development, instead of having to run stub generation, it was really really easy to add new web services.
CXF seems to be more of the same but better - we haven't migrated yet due to constraints on development time as well as not having a pressing reason to do so (plus the relative lack of documentation 6-12 months ago wasn't too encouraging). Additionally I haven't really evaluated the market of late, so I can't tell you how CXF stands up to its contemporary competitors.
Regarding your points:
There is no boilerplate code to be generated, the WSDL is automatically created from the service class' annotations and published by the server.
Deployment in Tomcat was relatively simple. Just define another servlet in web.xml and map a URL pattern to this servlet.
Our web services were deployed in WAR files, I'm not sure what the alternatives are in fact but this seemed to be the default and obvious way to do it.
POJOs work fine initially; we've now moved most of the web service object creation to Spring in order to wire more complex conditional dependencies in and have had no problems with this.
Documentation was a weak point with CXF originally, though having just had a look it seems to be better now. The general design and architecture seems relatively sane; slotting in one's own filters to modify the transmission details was not very painful, and extending existing classes has generally been considered (so sensible methods are marked protected instead of private, for example).
JAX-WS is full supported in CXF.
So I'm probably a little impartial as I haven't tried the other ones, but I'll give a thumbs up to having a look at CXF. It's pretty fast, relatively simple to get going with and fairly powerful if you need to tweak it.
We have tried Metro and CXF and kept CXF because Metro includes too many dependencies like Sun's APIs in its jar files which makes it difficult to integrate in another application server than Glassfish. CXF has a cleaner packaging with explicit external dependencies.
We also failed to enable Gzip compression with Metro while it worked like a charm with CXF.
I'd go with Spring WS first and XFire second. I'm a Spring user, so I'm used to the opacity.
XFire now Apache CXF was far away easier to use than Axis. I had something done very quickly using it where Axis seemed overly complicated. I didn't look at Spring WS.
I will use CXF. It is easy to use than Axis2
I have only used the Spring WS because that is what I was told to use, but it was a pretty easy use framework. If you have to go with soemthing else I would go with XFire due to the JAX-WS support.
I'm looking for a light version of REST for a Java web application I'm developing.
I've looked at RESTlet (www.restlet.org) and the REST plugin for Struts 2, but I haven't made up my mind. I'm leaning towards RESTlet, as it seems to be lighter.
Has anyone implemented a RESTful layer without any of the the frameworks or with the frameworks?
Any performance issues that you've seen because of the new web layer?
Did the introduction of REST added unmanageable or unreasonable complexity to your project? (Some complexity is understandable, but what I mean is just plain overkilling your design just to add REST)
I'm a huge fan of JAX-RS - I think they've done a great job with that specification. I use it on a number of projects and its been a joy to work with.
JAX-RS lets you create REST resources using POJOs with simple annotations dealing with the URI mappings, HTTP methods and content negotiation all integrated nicely with dependency injection. There's no complex APIs to learn; just the core REST concepts (URIs, headers/response codes and content negotiation) are required. FWIW JAX-RS is quite Rails-ish from the controller point of view
There are a number of JAX-RS implementations out there - see this thread for a discussion.
My personal recommendation is to use Jersey as its got the biggest, most active community behind it, has the best features at the time of writing (WADL support, implicit views, spring integration, nice REST client API); though if you are using JBoss/SEAM you might find RESTeasy integrates a little better.
I'm a big fan of Restlet, but I usually use it to implement apps whose primary role is to be a RESTful web service. It sounds like you're looking to add a RESTful API to an existing application. If that's the case, JAX-RS's (or Enunciate's) annotation-based approach might be a better fit for your project.
As for Restlet, I can tell you that I've been very impressed with the developers and the community; they're very active, engaged, responsive, and committed to a stable, efficient, reliable, and effective framework. My single favorite aspect of the framework is that it is a ground-up implementation of the REST paradigm; therefore there is no impedance-mismatch between a Restlet app's external API and internal implementation. I also really like how flexible it is - it can run inside a Java application container/server such as JBoss, Tomcat, Jetty, etc, or standalone, with an embedded HTTP server library.
Well, I've used Enunciate quite a bit. It uses simple annotations to provide either REST and/or SOAP endpoints.
http://enunciate.codehaus.org
Plus, Ryan Heaton has always provided top-notch support for things, too.
You know there is a new JCP API for Accessing RESTful Services, also:
JAX-RS JCP311
https://jsr311.dev.java.net/
The open source version is called Project Jersey
I am working on a REST API for gliffy.com and we ended up rolling our own. We didn't want to have to bring in Struts 2, Spring, or any other framework. I looked at RESTLet and found it incredibly confusing and over complicated.
Apache has an implementation of the JAX-RS spec, but it is not finalized and also has some oddities to it. We're tentatively planning to open source our solution, but that's not for a few months.
Rolling your own is easy, though. The Servlet Specification gives you everything you need, and you can easily connect to a database via Hibernate (see http://www.naildrivin5.com/daveblog5000/?p=39 for how to set up JPA without using EJB3).
I found restlet to be a really elegant architecture. I'm working in the .net world so it was not an option for me, but I was able to build my own framework following the same basic principles of restlet.
I have found the conversion of our WCF contract-based SOA application to REST based one has significantly simplified the application,