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
– 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.
– Can communicate with Java Platform only.
– Limited Transactional Support
– 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.
– 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.