Develop Reference

Pros and Cons of JAX-RS, Playframework scala (REST backend), Web Api

First am not sure if this question fits here well. However couldn't think of a better place to get help. I've been tasked to list the Pros and Cons of each of these {JAX-RS, Playframework scala, MS Web Api}. I've done some research but couldn't conclude as I've not used all three to great extent. Have used playframework to create simple REST app. Have read the Web Api tutorials but have not implemented anything. Did research on JAX-RS but haven't implemented anything either. Also most of our developers are familiar with C# and introductory Java. I am more inclined towards playframework due to Scala,Akka,no server restart and scalability etc but not clear about the cons. One thing am sure is JAX-RS is standard Java EE and Web Api is standard MS stuff. Below are some of the app requirements:
Purely REST backend.
Proper authentication and authorization.
Online secure payment {Paypal etc}
Single front-end for both mobile and desktop
{angular/backbone/knockout..}
Allow users to subscribe as companies or part of companies.
Be able to connect to different databases without App restart.
Code maintenance and readability. Other members should be able to pickup without hassle.
Scalability

This is a partial answer because I worked only with playframwork 2.0 and JAX-RS.
Playframework is a MVC framework, you can use it to create some REST services but it's not focused on this kind of applications, so at least in version 2.0 it wasn't easy to add complex behavior like interceptors, etc. and you should manage authentication by yourself, I don't know if this has been improved in most recent versions of play framework.
JAX-RS is a specification to create REST services, there are several implementations like
Jersey, RESTeasy, Restlet between others. So JAX-RS implementations are built specifically to provide REST services in java. Most implementations have support to several authentications mechanism like OAuth, etc.
In my experience, JAX-RS is better to provide RESTful web services, and the code generated is in general more maintainable than the code generated in playframework, also playframework has a lot of things that maybe you don't need to use, but it will be loaded in memory when you start the server anyway. Akka it's a cool technology, but you can use it if you want it in any JAX-RS implementation.
If you want to build REST services using Scala, you could try Scalatra http://www.scalatra.org/
If you prefer java, take a look at http://dropwizard.io/, it's an embedded server that has Jersey (An implementation of JAX-RS) and a lot of cool things to provide RESTful web services, like metrics, etc, also it's easy to learn. If your team doesn't have an advanced java knowledge, this is a good option.
Playframework is great if you want an easy to learn MVC, specially for non java programmers but definitively it's not the right tool to build RESTful webservices based applications in my experience.

Are asynchronous RESTful web services possible?

Reading RESTful documentation, it does not seem like it is possible to implement an asynchronous instance, but someone may know better on SO.
What I mean here is I would like to execute service requests asynchronously:
#Path("/helloworld", asyncSupported=true)
public class MyHelloWorldService {
...
}
I know asyncSupported is not defined in #Path, but I am looking for something similar to #WebServlet. Then, I would like to use AsyncContext instances (or anything equivalent).
Is this possible?

RestEasy has some support1 for it - using a custom annotation called #Suspend.
See here:
http://docs.jboss.org/resteasy/docs/2.2.1.GA/userguide/html/Asynchronous_HTTP_Request_Processing.html
There is also a framework/library on top of Jersey called Atmosphere however that might be overkill for your usecase as its focus appears to be on long-polling client/server web applications ( e.g. chats - https://github.com/Atmosphere/atmosphere )
[1] The CDI scope for your request will be lost in in the thread that actually executes the logic. See the RESTEasy-682 issue for more information. This is a problem that hasn't been solved by any REST frameworks that I know of at this moment[March 2014].

It's apparently possible with CXF and Jetty Continuations but that only appears to be possible with Jetty 6; they've been changed in Jetty 7 to something that's in the Servlet 3.0 spec and I don't know if that's supported by CXF. Moreover, Jetty Continuations seem to be a bit of a messy API, with a lot of manual stuff so I don't know how easy it is to convert the code.
Still, somewhat possible it seems. With a following breeze and when God wills it.

Restful spesification is still at early ages of its life. But this problem should be considered as 2 part. Client and Server.
Client:
For the client side recent changes at last year became mature enough. And recently a non blocking client from based on Jeanfrancois Arcand was implemented and pushed to repository. There is an explanation here.
Server:
For the server side, it is still immature. The adoption of the new servlet specification is quite slow and as a developer I am expecting JSR 339 to address these issues as well. And this is also addressed at the JSR spec clearly with these sentences.
JAX-RS 1.1 defines a synchronous request response model on the server
side. This JSR will specify a simple asynchronous request processing
model such that a response can be returned asynchronous to the
request. Servlet 3.0 can be leveraged to enable such support but
implementations may choose to use other container-specific APIs
instead.
However there are other alternatives too. Projects such as Jetty are addressing such kind of problems elegant as in this example. I can only suggest you to consider other alternatives as the community is growing.

Now you can make Asynchoronous RESTful calls using JAX-RS 2.0 API which is part of the recently released Java EE 7.0
http://www.slideshare.net/reza_rahman/jaxrs2?ref=

Check out Pubsubhubbub found here for an example of a REST-based asynchronous protocol. It is based on the Atom Syndication format and is a lot simplier than WS-* pub/sub mechanisms.

You may also want to try Spring Webflux which is async and reactive at the same time. However, this is not a JAX-RS implementation from Java EE.

When to use Spring Integration vs. Camel?

As a seasoned Spring user I was assuming that Spring Integration would make the most sense in a recent project requiring some (JMS) messaging capabilities (more details). After some days working with Spring Integration it still feels like a lot of configuration overhead given the amount of channels you have to configure to bring some request-response (listening on different JMS queues) communications in place.
Therefore I was looking for some background information how Camel is different from Spring Integration, but it seems like information out there are pretty spare, I found:
http://java.dzone.com/articles/spring-integration-and-apache (Very neutral comparison between implementing a real-world integration scenario in Spring Integration vs. Camel, from December 2009)
http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Comparing Camel with other solutions, October 2009)
http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, October 2008)
Question is: what experiences did you make on using the one stack over the other? In which scenarios would you recommend Camel were Spring Integration lacks support? Where do you see pros and cons of each? Any advise from real-world projects are highly appreciated.

We choose Camel over Spring-Integration because the fluent API is really nice. We actually use it in Spring projects and use Spring to configure part of it. The programming API's are clear and there is a large set of sensible components.
We did a small scale shootout and basically at that time for our requirement Camel won. We use it mainly to transfer internal datafiles to/from external parties which usually requires format conversions sending it using ftp/sftp/... or attaching it to an email and sending it out.
We found the edit-compile-debug cycle reduced. Using groovy to experiment setting up routes are added bonuses.
Spring-Integration is a great product too, and I am quite sure it would satisfy our needs too.

I only recommend Spring Integration if you already have got a Spring project and you have just to add some "basic" integration using File, FTP, JMS, JDBC, and so on.
Apache Camel has two main advantages:
Many, many more technologies are supported.
Besides, a (good) XML DSL, there are fluent APIs for Java, Groovy and Scala.
Because Apache Camel has very good integration with Spring, I would even use it instead of Spring Integration in most Spring projects.
If you need more details, you can read my experiences in my blog post: Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel?

I have recently conducted a Camel vs Spring Integration shoot-out with the aim to integrate Apache Kafka. Despite being an avid Spring developer, I sadly found my suspicion with Spring's ever-growing Project stack confirmed: Spring is awesome as IOC-Container to serve as glue for other framework, but it fails at providing viable alternatives to those frameworks. There might be exceptions to this, namely everything to do with MVC, where Spring came from and where it does a great job, but other attempts to provide new functionality on top of container features fall short for three reasons and the SI Kafka use case confirms all of them:
Introduction of a long-winded difficult to use DSL for XML-configuration.
Pages of xml-configuration code to get all framework components wired-up.
Missing resources to provide functionality on par with dedicated frameworks.
Now, back to the results of my shoot-out: most importantly I am impressed by Camels overall concept of routes between endpoints. Kafka seamlessly integrates with this concept and three lines of configuration are enough to get everything up-and-running. Problems encountered during the process are neatly addressed by ample documentation from the project team as well as a lot of questions on Stackoverflow. Last but not least, there is a comprehensive integration into Spring that leaves no wishes unfulfilled.
With SI on the contrary, the documentation for the Kafka integration is quite intense and still fails to explain clearly how to integrate Kafka. The integration of Kafka is pressed into the SI-way of doing things, which adds extra complexity. Other documentation, e.g. on Stackoverflow is also less plentiful and less helpful than for Camel.
My conclusion: cobbler stick to your trade - use Spring as a container and Camel as system integration framework.

It really depends on what you want to do. If you need to extend something to build your own messaging solution Spring Integration has the better programming model. If you need something that supports many protocols without custom code, Camel is ahead of Spring Integration.
Having a small scale shootout is a very good idea, just make sure you're trying to do the type of things that you'd typically be doing in the project.
--disclaimer: I'm a Spring Integration committer

Most comparisons of Camel and SI that I've seen don't take the following into account:
1.) The effect that Spring Boot has had on developer productivity for Spring Integration
2.) The effect of Spring XD has had on making Spring Integration applications available with no code compilation - also Spring XD sources and sinks are simply Spring Integration channel adapters, when you're looking to extend Spring XD.
3.) The effect of Spring XD has had on making unifying Spring Integration, Spring Batch, Spring Data (+Hadoop!) in one stack, effectively bringing batch and stream processing, HDFS/Apache Hadoop support, and much more to Spring Integration.
4.) The effect of the soon-to-be-released Spring Integration 4.0 Java DSL https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference
For your consideration,
/Pieter (disclaimer I work at Pivotal)

We are using Spring Integration for our application and now considering to move to Apache Camel as we encountered lots of issues with Spring Integration framework. Here are couple of issues.
The CachingConnectionFactory which Spring provides opens 1000's of idle connections in IBM MQ and there is no guarantee that these connections are reused. And still these connections will stay open forever which creates troubles on the MQ side. Had to restart the application every week in lower environments just to refresh the connections. Apache Camel also provides Caching and the connections seems to go up/down based on the load.
Spring doesn't provide mappers for QoS parameters. Even if you enable QoS, the delivery mode and expiration/timetolive properties will get lost (I am going to raise a JIRA issue for this). Apache Camel handles this and QoS parameters are sent to upstream applications and not dropping it.
I am right now working on issues with handling the exceptions and transactions with Apache Camel which Spring seemed to handle better with AOP.

Apache Camel is a very good framework and very complete too. But if your application uses spring, my personal advice is to use Spring Integration.
Spring Integration is the integration EIP complaint framework of Spring-Source ecosystem. It has excellent integration with the ecosystem: Spring boot, Batch, XD; even the core uses same abstraction starting from Spring Framework 4. Some of the messaging abstraction were moved in the framework, as proof that the basic messaging abstraction of Spring Integration is very strong. Now Spring framework for instance use the messaging abstraction for Spring Web, web socket support.
Another good thing in a Spring application with Spring integration respect to use Apache Camel is that with Spring integration, you can use only one Application Context. Remember that the Camel Context is a Spring context. if you have the chance of use a new Spring version, I suggest to use Spring Integration Java DSL for configuration. I use it on my new projects, and it feels more readable and clear. I hope that this reflection can help you for the your evaluations.

Actually, I would say FTP has graduated its incubation period. You can do a simple search on SI forums/JIRA to see what new features were implemented and bugs that were fixed. From various chatter it seems like there is already some production usage out of it, so I would suggest to give it a second look and of course communicate your concerns to us via
http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT
Cheers
Oleg
Disclaimer: I am Spring Integration committer

One reason to use Camel over Spring Integration is when you need a more featureful EIP set. Spring Integration doesn't provide abstractions over things such as ThreadPool.
Camel does provide additional constructs for this simplifying some of the aspects of working with concurrent code:
http://camel.apache.org/camel-23-threadpool-configuration.html
If you have no need for this sort of thing and just want to connect file, JMS, FTP endpoints etc... then just use Spring Integration.

Camel act as middleware for application where one can perform data modeling, transformation of message values and choreography of messages.

If your current application is in Spring and require features which are supported by Spring Integration of EIP then Spring Integration is the best option else require more third party supports/protocols/file formats etc

Lightweight REST library for Java

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,

What OSS project should I look at if I need to do Spring friendly WorkFlow?

We need to add WorkFlow to our Spring managed application. Does anyone have any useful experience in using any of the myriad of OSS Work Flow solutions? Which one is best? Which one integrates with Spring best? Which ones should we avoid?

If you only need some simple process orchestration, Spring's own Web Flow, despite its name can serve as a orchestration task manager. If you need to preserve state for several days then you will need to become an 'early adopter' of one of the open-source projects. You may want to look at Eclipse's BPEL project.
My hunch is that once a clearer picture of the BPEL/BPM/Workflow space emerges you will see Spring provide an abstraction layer the same way they have for JDBC, Transactions, ORM frameworks etc...

Like Brian said if you're doing anything of great complexity you might look at using BPEL.
There are a number of open source BPEL engines, one that comes to mind is Apache Orchestration Director Engine

I second Spring Web Flow. Depending on how complex the process is, Web Flow is great for managing various states and I've found that it's pretty easy to pick up and there's a good amount of documentation out there for it.

ActiveVOS is by far the best BPEL engine in my opinion. Download the evaluation version and give it a go. JBoss have even adopted their open source offering.

We're looking at Drools/Guvnor, possibly integrated with jBPM (as in this presentation), to add a workflow engine to our Spring/Java EE app, but we're still in the very early phases of trying it out.