JMS: A Solution in Search of a Problem? (cont'd)
A Quick Intro to JMS
It turns out JMS is designed to achieve all these goals in an enterprise system. The name doesn't connote its general usefulness at all, which is probably one reason so many Java enterprise developers are confused about JMS's purpose.
Just keep this definition in mind: JMS is an API for asynchronous, transacted message production, distribution, and delivery.
Through the API, your application produces messages, then hands them to the JMS service agent resident in your own process. The service distributes the message among its various agents within each process. Once JMS copies a message to its agent within a remote consumer process, the message is delivered to the process's code through a listener interface.
In its heart-of-hearts, JMS is just a way to get data from A to B. Your code in process A produces the data, and JMS gets it all the way to your code in process B. The same thing can be achieved with straight TCP communications, Morse code, or ocean-bound messages in bottles. So JMS is the standardization of a relatively simple, widely accepted concept. In this respect, JMS is unlike the much more complex and new concepts standardized by Sun's EJB and Jini standards.
To put it in perspective, JMS is similar to MSMQ in that it is a communications mechanism. It does not compare with such technologies as EJB, Jini, CORBA, ORB (component-based application logic), etc., which all are all higher-level pieces with narrower foci.
