Are application servers (with EJBs) the only way to communicate between a client and a Java EE server?
Imagine a Java client / server ERP application serving up to 100 concurrent users, both web and swing clients. For persistence, we can use the Persistence and Hibernate APIs. But when it comes to client / server communication, do we really have an alternative to using AS with EJB to reduce the cost of remote communication programming?
It seems like a very heavy decision to throw away the EJB and the app server just to get rid of things. There is also a standard way to use RMI, but who wants to code everything yourself nowadays ...
I know you will get a lot of features for free from AS in addition to the remote part. And maybe this is the way. But are there any other (low coding cost) alternatives to AS for client / server communication for an enterprise application?
source to share
Personally, I think Seam is the ultimate solution to a problem that I don't have, but there are many options aside, and most of them use Spring:
- RMI ;
- Hessian (binary HTTP protocol);
- HTTP Invokers (Java serialization over HTTP)
- Web services ; or
- Even JMS .
The advantage of HTTP based remote access methods is that they easily plug into Spring security models. Plus, you get access to things like interceptors.
source to share
You can use lightweight frameworks. Spring has a number of options in this section.
If you ask me one word for both, I will suggest two. Seam or Spring. I like Seam myself, but for easy removal, Spring has more viable solutions and support. Again, if your AS is JBoss, consider Seam .
source to share
The application server is a rather heavy decision. Depending on your requirements, I'll try to make sure you can run a simple servlet container (like Tomcat). I find it much easier with Spring -remoting instead of full EJB. Spring -remoting provides an abstraction for the remote transfer method used. Hessian has a good reputation as a light protocol.
Having some kind of server structure (AS or Servlet container) is good as you don't have to think the same about all low level issues (connection establishment, threads, ...).
source to share