To help you better understand the ideas behind ActiveMQ, it’s important to have some background and history on enterprise messaging in general. After discussing enterprise messaging, you’ll be prepared for a brief introduction to JMS followed by some small examples of its use. The purpose of this chapter is to briefly review enterprise messaging and the JMS specification.
Introduction to enterprise messaging:
Most systems like those mentioned previously were built using mainframe computers and many still use them today. So how can these applications work in such a reliable manner? To answer this and other questions, let’s briefly explore some of the history behind such solutions and how enterprise messaging was born.
Starting in the 1960s, large organizations invested in mainframes for critical applications to facilitate functions such as data processing, financial processing, statistical analysis, and much more. Mainframes provided appreciable benefits including high availability, redundancy, reliability and scalability, upgradability without service interruption, and many other critical features required by business. Although these systems were extremely powerful, access to such systems was restricted, as input options were few. Also, interconnectivity among systems hadn’t yet been invented, meaning that parallel processing wasn’t yet possible.
Figure 2.1 shows a diagram demonstrating how terminals connect to a mainframe. In the 1970s, users began to access mainframes through terminals, which dramatically expanded the use of these systems by allowing thousands of concurrent users. It was during this period that computer networks were invented and connectivity among mainframes themselves now became possible. By the 1980s, not only were graphical terminals available, but PCs were also invented and terminal emulation software quickly became common. Interconnectivity became even more important because applications needing access to the mainframe were being developed to run on PCs and workstations. Figure 2.2 shows these various types of connectivity to the mainframe. Note how this expanded connectivity introduced additional platforms and protocols, posing a new set of problems to be addressed.
Connecting a source system and a target system wasn’t easy since each data format, each piece of hardware, and each protocol required a different type of adapter. As the list of adapters grew, so did the versions of each, causing them to become difficult to maintain. Soon the effort required to maintain the adapters outweighed that of the systems themselves. This is where enterprise messaging entered the picture.
The purpose of enterprise messaging was to transfer data among disparate systems by sending messages from one system to another. There have been numerous technologies for various forms of messaging through the years, including the following list:
What’s message-oriented middleware?
Message-oriented middleware (MOM) is best described as a category of software for communication in an asynchronous, loosely-coupled, reliable, scalable, and secure manner among distributed applications or systems. MOMs were an important concept in the distributed computing world. They allowed application-to-application communication using APIs provided by each vendor, and began to deal with many issues in the distributed system space.
The overall idea behind a MOM is that it acts as a message mediator between message senders and message receivers. This mediation provides a whole new level of loose coupling. Figure 2.3 demonstrates how a MOM is used to mediate connectivity and messaging not only between each application and the mainframe but also from application to application.
At a high level, messages are a unit of business information that’s sent from one application to another via the MOM. Applications send and receive messages via the MOM using what are known as destinations. Messages are addressed to and delivered to receivers that connect or subscribe to the destinations. This is the mechanism that allows for loose coupling between senders and receivers, as there’s no requirement for each to be connected to the MOM at the same time for sending and receiving messages. Senders know nothing about receivers and receivers know nothing about senders. This is known as asynchronous messaging.
MOMs added welcome additional features to enterprise messaging that weren’t previously possible when systems were tightly coupled—features such as message persistence, robust communication over slow or unreliable connections, complex message routing, message transformation, and much more. Message persistence helps to mitigate slow or unreliable connections made by senders and receivers; or in a situation where a receiver simply fails, it won’t affect the state of the sender. Complex message routing opens up a huge number of possibilities, including delivering a single message to many receivers, message routing based on properties or the content of a message, and so forth. Message transformation allows two applications that don’t handle the same message format to now communicate via a custom message format that’s transformed on the fly.
Additionally, many MOMs on the market today provide support for a diverse set of protocols for connectivity. Some commonly supported protocols include HTTP/S, multicast, SSL, TCP/IP, UDP, and more. Some vendors even provide support for multiple languages, further lowering the barrier to using MOMs in a wide variety of environments. ActiveMQ provides exactly these types of features and more.
What’s the Java Message Service?
The Java Message Service (JMS) moved beyond vender-centric MOM APIs to provide an API for enterprise messaging. JMS aims to provide a standardized API to send and receive messages using the Java programming language in a vendor-neutral manner. The JMS API minimizes the amount of enterprise messaging knowledge a Java programmer is required to possess in order to develop complex messaging applications, while still maintaining a certain amount of portability across JMS provider implementations.
JMS isn’t itself a MOM. It’s an API that abstracts the interaction between messaging clients and MOMs in the same manner that JDBC abstracts communication with relational databases. Figure 2.4 shows at a high level how JMS provides an API used by messaging clients to interact with MOM-specific JMS providers, which handle interaction with the vendor-specific MOM. The JMS API lowers the barrier to creating enterprise messaging applications. It also eases the portability to other JMS providers.
Originally created by Sun in conjunction with a group of companies from the enterprise messaging industry, the first version of the JMS spec was released in 1998. The latest release was in 2002 and offered some necessary improvements. The JMS 1.1 release unified the two sets of APIs for working with the two messaging domains, so working with both messaging domains now only requires a single common API. This was a dramatic change that improved the APIs. Backward compatibility with the old APIs is still supported.
In standardizing the API, JMS formally defined many concepts and artifacts from the world of messaging:
- JMS client
- Non-JMS client
- JMS producer
- JMS consumer
- JMS provider
- JMS message
- JMS domains
- Administered objects
- Connection factory
- Destination
Besides these concepts, others are also important. The next few sections will dive deeper into these concepts and focus on describing these building blocks of JMS.
沒有留言:
張貼留言