EJB vs Web Services vs JMS


In Today’s world distributed applications has become the backbone of many businesses. They have removed the barriers of communication in terms of data exchange, information availability etc.

The major player have been introduced on Sun Java Implementation and accepted widely in many bigger enterprise level applications.

In this post I will try to highlight few of the things which we should keep in mind while choosing over EJB or Web Services or JMS.


EJB(will cover some basic features)
– provide developers architectural independence
– WODA (Write Once Deploy Anywhere)
– provides Distributed Transaction support
– contains only pure business logic

Weak Points
– Increase the development time.
– Sometime leads to complex implementation


JMS is a technique for loose coupling. As an example, it does not provide security or transactional binding with the target systems, but only with the message middleware. Messaging in general achieves loose coupling because:
• Message producers and consumers interact through the messaging transport (such as a message broker) in a point-to-point or publish/subscribe model.
• A technical header is usually provided independently of the business payload.

JMS is well-suited for:
• Integrating systems/components that participate in business events.
• Integrating slow responders.
• Integrating existing systems.

Weak Points:
–  Can communicate with Java Platform only.
–  Limited Transactional Support


Web Services
– They can be tightly coupled, and their deployment can be based on the use of invocation frameworks.
– They can perform either in a synchronous request/reply mode or in an asynchronous mode.
– They can be exposed by J2EE or non-J2EE providers.

Weak Points:
–  Web services use plain text protocols that use a fairly verbose method to identify data. This means that Web service requests are larger than requests encoded with a binary protocol.

–  Typically, a server sends some kind of session identification to the client when the client first accesses the server. The client then uses this identification when it makes further requests to the server. This enables the server to recall any information it has about the client. A server must usually rely on a timeout mechanism to determine that a client is no longer active. If a server doesn’t receive a request from a client after a predetermined amount of time, it assumes that the client is inactive and removes any client information it was keeping. This extra overhead means more work for Web service developers.

There are many things which we can further explore before making any final decision to pick these technologies. I have just tried to give some high level information related.

R Vashi

7 thoughts on “EJB vs Web Services vs JMS

  1. Jaizon Lubaton

    For me, I would choose GWT+Tomcat(gwt-activemq ajaxServlet)+ActiveMQ as Facade+EJB3

    With this an Enterprise system will have low latency on server and network its scalable and good performance. Its Asynchronous close to 100%. Easy integration with Legacy systems and other new disparate Systems.

    And there are other good benefits still not mentioned.

  2. c_arnoud

    Your idea is too complex to implement and rarely you can find developers think in asynchronous way. just use JMS and webservices when needed and do things in standard Java EE way.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.