Java Tutorial - Java Scipt :
Needs and Features Analysis
Messaging shares many common criteria for evaluation with other parts of an enterprise solution. In examining a JMS provider, we can ignore the common functionality required by the specification. Usually, any JMS-compliant solution will have strong suitability in enterprise use. In further differentiating the JMS providers, we will look at the following criteria:
· Scalability
· Performance
· Specification compliance
· Interoperability
· Reliability
· Administrative capabilities
· Ease of use/integration
· Development velocity
Scalability is a good differentiator of JMS providers. This is commonly measured in terms of the maximum volume of messages per unit time. As a practical matter, this fact is important to know, but you should also know how
scalable the JMS provider is in other terms. How many topics or queues can the JMS provider handle? This is where added features such as JORAM’s clusterizable topics can become important. Performance is always a factor in evaluating products. How much CPU time and memory resources does a JMS provider require? What is the incremental increase in resources for each additional message? Specification compliance is usually a given, but in this particular case, it is important to note which JMS providers adhere to version 1.1 of the JMS specification and which implement older versions of JMS. This is because JMS 1.1 unified the messaging domains. The main benefit from unification is that you can now use both PTP and pub/sub messaging within the same transaction. The unification also simplifies the development of client code, increases flexibility, and improves reusability because the decision to use either a PTP or pub/sub model is less binding. From a less formal point of view, specification
compliance serves as a barometer for the amount of developer activity in a project. Interoperability is a great differentiator, if only because the open source projects offer so little interoperability. Commercial offerings add value here because they often do work with preexisting MOM such as Microsoft MSMQ and Tibco Rendezvous.
It is worth noting that most vendors do offer JMScompliant interfaces. On the other hand, the open source JMS providers are focused on their implementation of the JMS API and do not feature any interoperability with vendor-specific MOM. Reliability is always important, but particularly within the scope of JMS providers. It is critical for a JMS provider to remain stable over a large volume of messages. Measuring reliability can be difficult given the velocity of open source development. For example, JBossMQ 3.0.3 was crippled by a memory leak bug that prevented long-term operation. Yet this was rapidly fixed in 3.0.4 release. The thing to keep in mind is test, test, test.
Administrative capability is fast becoming the most important criterion for enterprise systems. As complexity continues to rise, administrators are becoming overwhelmed. JMX (Java Management Extensions) has been great in increasing the visibility of enterprise systems and the entire J2EE industry to moving in that direction for administration. Beyond just a standard for administration, a good set of tools can make a huge difference in choosing one JMS provider over another. Ease of use and integration are especially important in the context of J2EE
development. JMS is one of the foundation elements for J2EE and needs to work with higher-level elements such as EJBs. A reduction in configuration and integration errors translates directly into greater productivity. This is particularly true if you plan on moving the J2EE enterprise application over to a different environment for final deployment.
