Who wants to make a middleware
Added 31 Jul 2008
What is JMS? Java Message
Services, JMS, is Sun's standard API for message queuing systems. Message queuing systems form the front-line interface
between businesses (B2B) and for Enterprise Application Integration (EAI). As such, message queuing systems are
often called "middleware" because they operate in the middle -- between other systems and between enterprises.
Introduction. For general introductory articles see: Where do you go for JMS by JMS advocate Alexandra Barrett, MessageQ.com. Alexandra has several other articles that provide a framework for discussing JMS. Her article Taking a peek at JMS on MessageQ.com explains some of the wide applicability that JMS has.
Advantages. JMS offers a number of advantages over older Message queuing systems. First, JMS has two message protocols: point to point and pub/sub instead of only one, as many earlier middleware systems did. Additionally, JMS also doesn't care whether you use a wire or wireless protocol, and provide different levels of message delivery assurance as well. For some informative illustration of these advantages see the Information Week article, Java Messaging Ensures Data Delivery, November 1999, by... you guessed it -- Alexandra Barrett. Alexandra provides some history of messaging systems in MQSeries, Meet JMS also on MessageQ.com.
How did Sun set JMS up as such a powerful solution? You will note on the JMS home page that that Sun gives a great deal of credit to JMS vendors. But, to fullly appreciate JMS architecture from Sun's perspective take a look at two SunWorld articles: Understanding Java messaging and JMS Oct 1999, and Enterprise application integration -- message broker style, Aug 1999 both by IT Architect columnist Frank Teti. These two articles also explain the milieu of B2B, EAI and messaging into which JMS has now entered.
What JMS and message queuing does. JMS operates as a message "pipleline" between two points (point-to-point) or as a publish subscribe system. Keys to JMS operation are that it runs asynchronously, provides standard message formats, yet is capable of handling persistent transaction quality messages. JMS uses formats based on XML and is capable of talking with both local and remote databases and business applications.
Persisting Messages. To qualify as a JMS compatible system, the vendor needs to provide an option for making messages persistent within the pipeline. But exactly how they achieve this is up to the vendor. Vendors can and do use an RDBMS, an ODBMS, or even flat files. The choice of which RDBMS is used, the performance and optimization of RDBMS usage, and the format of data within the pipe of course also depend on the vendor. For these reasons it is worth while examining several possible message queing systems before deciding on one in particular.
Architecture You can also look at JMS in terms of it's role within J2EE and the back office where JMS can add auditability. JMS also allows asynchronous processing within the office as shown in this sample article from Components Strategies Online. For an example server architectural overview, take a look at this diagram from XMLBlaster. However, JMS systems also can be "server-free" messagers. Softwired's Message Bus and embedded versions of iBus are examples.
Can JMS connect all the dots in dot com? No. It may be getting easier all the time, but not yet, and, at least, not without a little help. ERPs and legacy applications often require interfaces to connect with JMS or other message queue software. Additionally, interfacing to some systems can requires a special set of business rules to drive the process. Some JMS message queue vendors like NEON provide specialized adaptors, connectors, development kits, and business rule engines that pull specific ERP systems into the message queing world.
Additional Background The jGuru JMS FAQ is an excellent technical resource. For more overview and technical material see: Progress SonicMQ Whitepapers page,
The XML Blaster white paper and FAQ, the Fiorano Development Center page and Fiorano JMS Core Programming Issues FAQ.
Before you begin. JMS is/can be vendor dependent. Your JMS program will need to refer to a vendor's implementation library. So to run tutorials and examples from one JMS product using a different product, you will need to change at least the import statements.
Introduction. For general introductory articles see: Where do you go for JMS by JMS advocate Alexandra Barrett, MessageQ.com. Alexandra has several other articles that provide a framework for discussing JMS. Her article Taking a peek at JMS on MessageQ.com explains some of the wide applicability that JMS has.
Advantages. JMS offers a number of advantages over older Message queuing systems. First, JMS has two message protocols: point to point and pub/sub instead of only one, as many earlier middleware systems did. Additionally, JMS also doesn't care whether you use a wire or wireless protocol, and provide different levels of message delivery assurance as well. For some informative illustration of these advantages see the Information Week article, Java Messaging Ensures Data Delivery, November 1999, by... you guessed it -- Alexandra Barrett. Alexandra provides some history of messaging systems in MQSeries, Meet JMS also on MessageQ.com.
How did Sun set JMS up as such a powerful solution? You will note on the JMS home page that that Sun gives a great deal of credit to JMS vendors. But, to fullly appreciate JMS architecture from Sun's perspective take a look at two SunWorld articles: Understanding Java messaging and JMS Oct 1999, and Enterprise application integration -- message broker style, Aug 1999 both by IT Architect columnist Frank Teti. These two articles also explain the milieu of B2B, EAI and messaging into which JMS has now entered.
What JMS and message queuing does. JMS operates as a message "pipleline" between two points (point-to-point) or as a publish subscribe system. Keys to JMS operation are that it runs asynchronously, provides standard message formats, yet is capable of handling persistent transaction quality messages. JMS uses formats based on XML and is capable of talking with both local and remote databases and business applications.
Persisting Messages. To qualify as a JMS compatible system, the vendor needs to provide an option for making messages persistent within the pipeline. But exactly how they achieve this is up to the vendor. Vendors can and do use an RDBMS, an ODBMS, or even flat files. The choice of which RDBMS is used, the performance and optimization of RDBMS usage, and the format of data within the pipe of course also depend on the vendor. For these reasons it is worth while examining several possible message queing systems before deciding on one in particular.
Architecture You can also look at JMS in terms of it's role within J2EE and the back office where JMS can add auditability. JMS also allows asynchronous processing within the office as shown in this sample article from Components Strategies Online. For an example server architectural overview, take a look at this diagram from XMLBlaster. However, JMS systems also can be "server-free" messagers. Softwired's Message Bus and embedded versions of iBus are examples.
Can JMS connect all the dots in dot com? No. It may be getting easier all the time, but not yet, and, at least, not without a little help. ERPs and legacy applications often require interfaces to connect with JMS or other message queue software. Additionally, interfacing to some systems can requires a special set of business rules to drive the process. Some JMS message queue vendors like NEON provide specialized adaptors, connectors, development kits, and business rule engines that pull specific ERP systems into the message queing world.
Additional Background The jGuru JMS FAQ is an excellent technical resource. For more overview and technical material see: Progress SonicMQ Whitepapers page,
The XML Blaster white paper and FAQ, the Fiorano Development Center page and Fiorano JMS Core Programming Issues FAQ.
Before you begin. JMS is/can be vendor dependent. Your JMS program will need to refer to a vendor's implementation library. So to run tutorials and examples from one JMS product using a different product, you will need to change at least the import statements.