Until now, our discussion of enterprise messaging has been somewhat abstract. This section attempts to give some real-world scenarios to provide you with a better idea of the types of problems that enterprise messaging systems can solve.
Service-Oriented Architecture (SOA) describes an architecture style that defines business services that are abstracted from the corresponding enterprise service implementations. SOA has given rise to a new breed of middleware known as an Enterprise Service Bus, or ESB. In the early days of SOA, most ESBs were implemented as message brokers, whereby components within the messaging layer were used to perform some sort of intelligent routing or message transformation before delivering the message. These earlier message brokers have evolved into sophisticated commercial and open source ESB products that use messaging at their core. Although some ESB products support a traditional non-JMS HTTP transport, most enterprise-wide production implementations still leverage messaging as the protocol for communication.
Messaging is an excellent means of building the abstraction layer within SOA needed to fully abstract a business service from its underlying implementation. Through messaging, the business service does not need to be concerned about where the corresponding implementation service is, what language it is written in, what platform it is deployed in, or even the name of the implementation service. Messaging also provides the scalability needed within an SOA environment, and also provides a robust level of monitoring and control for requests coming into and out of an ESB. Almost all of the commercial and open source ESB products available today support JMS messaging as a communication protocol—the notable exception being the Microsoft line of messaging products (e.g., BizTalk and MSMQ).
The increased interest and use of SOA in the industry has in turn given rise to increased interest and usage of messaging solutions in general. Although full-blown SOA implementations are continuing to evolve, many companies are tuning to messaging solutions as a step toward SOA.
Event-Driven Architecture (EDA) is an architecture style that is built on the premise that the orchestration of processes and events is dynamic and very complex, and therefore not feasible to control or implement through a central orchestration component. When an action takes place in a system, that process sends an event to the entire system stating that an action took place (an event). That event may then kick off other processes, which in turn may kick off additional processes, all decoupled from each other.
Some good examples of EDA include the insurance domain and the defined benefits domain. Both of these industry domains are driven by events that happen in the system. For example, something as simple as changing your address can affect many aspects of the insurance domain, including policies, quotes, and customer records. In this case, the driving event in the insurance application is an address change. However, it is not the responsibility of the address change module to know everything that needs to happen as a result of that event. Therefore, the address change module sends an event message letting the system know that an address has changed. The quoting system will pick up that event and adjust any outstanding quotes that may be present for that customer. Simultaneously, the policy system will pick up the change address event and adjust the rates and policies for that customer.
Another example of EDA is within the defined benefits domain. Getting married or changing jobs triggers events in the system that qualify you for certain changes to your health and retirement benefits. Many of these systems use EDA to avoid using a large, complex, and unmaintainable central processing engine to control all of the actions associated with a particular “qualifying event.”
Messaging is the foundation for systems based on an Event-Driven Architecture. Events are typically implemented as empty payload messages containing some information about the event in the header of the message, although some pass the application data as part of the event. Not surprisingly, most architectures based on EDA leverage the pub/sub model as a means of broadcasting the events within a system.
Most companies, through a combination of mergers, acquisitions, migrations, or bad decisions, have a myriad of heterogeneous platforms, products, and languages supporting the business. Integrating these platforms can be a challenging task, particularly with standards continually changing and evolving. Messaging plays a key role in being able to make these heterogeneous platforms communicate with one another, whether it be Java EE and Microsoft .NET, Java EE and CICS, or Java EE and Tuxedo C++.
Although platforms such as Java can utilize the JMS API, other platforms such as .NET or C++ cannot (for obvious reasons). Many messaging vendors, both commercial and open source, support both the JMS API and a native API. These providers typically have a built-in messaging bridge that allows the provider to be able to convert a JMS message into an internal message and vice versa. Some platforms, such as .NET, may require an external messaging bridge to convert a JMS message into an MSMQ message (depending on the messaging provider you are using). For example, ActiveMQ provides a messaging bridge for converting MSMQ to JMS (and vice versa). This lower-level platform integration has given rise to a broader scope of integration, known as Enterprise Application Integration.
Most mature organizations have both legacy and new applications that are implemented independently and cannot interoperate. In many cases, organizations have a strong desire to integrate these applications so that they can share information and cooperate in larger enterprise-wide operations. The integration of these applications is generally called Enterprise Application Integration (EAI).
A variety of vendor and home-grown solutions are used for EAI, but enterprise messaging systems are central to most of them. Enterprise messaging systems allow stovepipe applications (consisting of heterogeneous products, technologies, and components) to communicate events and to exchange data while remaining physically independent. Data and events can be exchanged in the form of messages via topics or queues, which provide an abstraction that decouples participating applications.
As an example, a messaging system might be used to integrate an Internet order processing system with an Enterprise Resource Planning (ERP) system like SAP. The Internet system uses JMS to deliver business data about new orders to a topic. An ERP gateway application, which accesses a SAP application via its native API, can subscribe to the order topic. As new orders are broadcast to the topic, the gateway receives the orders and enters them into the SAP application.
Historically, businesses exchanged data using Electronic Data Interchange (EDI) systems. Data was exchanged using rigid, fixed formats over proprietary Value-Added Networks (VANs). Cost of entry was high and data was usually exchanged in batch processes—not as real-time business events.
The Internet, XML, and modern messaging systems have radically changed how businesses exchange data and interact in what is now called Business-to-Business (B2B). The use of messaging systems is central to modern B2B solutions because it allows organizations to cooperate without requiring them to tightly integrate their business systems. In addition, it lowers the barriers to entry since finer-grained participation is possible. Businesses can join in B2B and disengage depending on the queues and topics with which they interact.
A manufacturer, for example, can set up a topic for broadcasting requests for bids on raw materials. Suppliers can subscribe to the topic and respond by producing messages back to the manufacturer’s queue. Suppliers can be added and removed at will, and new topics and queues for different types of inventory and raw materials can be used to partition the systems appropriately.
These days many companies are geographically dispersed. Brick-and-mortar, click-and-mortar, and dot-coms all face problems associated with geographic dispersion of enterprise systems. Inventory systems in remote warehouses need to communicate with centralized back-office ERP systems at corporate headquarters. Sensitive employee data that is administered locally at each subsidiary needs to be synchronized with the main office. JMS messaging systems can ensure the safe and secure exchange of data across a geographically distributed business.
Auction sites, stock quote services, and securities exchanges all have to push data out to huge populations of recipients in a one-to-many fashion. In many cases, the broadcast of information needs to be selectively routed and filtered on a per-recipient basis. While the outgoing information needs to be delivered in a one-to-many fashion, often the response to such information needs to be sent back to the broadcaster. This is another situation in which enterprise messaging is extremely useful, since pub/sub can be used to distribute the messages and p2p can be used for responses.
Choices in reliability of delivery are key in these situations. In the case of broadcasting stock quotes, for example, absolutely guaranteeing the delivery of information may not be critical, since another broadcast of the same ticker symbol will likely happen in another short interval of time. In the case where a trader is responding to a price quote with a buy order, however, it is crucial that the response is returned in a guaranteed fashion. In this case, you mix reliability of messaging so that the pub/sub distribution is fast but unreliable, while the use of p2p for buying orders from traders is very reliable. JMS and enterprise messaging provide these varying degrees of reliability for both the pub/sub and p2p models.
In JMS, pub/sub topics and p2p queues are centrally administered and are referred to as JMS administered objects. Your application does not need to know the network location of topics or queues to communicate with other applications; it just uses topic and queue objects as identifiers. Using topics and queues provides JMS applications with a certain level of location transparency and flexibility that makes it possible to add and remove participants in an enterprise system.
For example, a system administrator can dynamically add subscribers to specific topics on an as-needed basis. A common scenario might be if you discover a need to add an audit-trail mechanism for certain messages and not others. Figure 1-8 shows you how to plug in a specialized auditing and logging JMS client whose only job is to track specific messages, just by subscribing to the topics you are interested in.
The ability to add and remove producers and consumers allows enterprise systems to dynamically alter the routing and re-routing of messages in an already deployed environment.
As another example, we can build on the EAI scenario discussed previously. In this case, a gateway accepts incoming purchase orders, converts them to the format appropriate for a legacy ERP system, and calls into the ERP system for processing (see Figure 1-9).
In Figure 1-8, other JMS applications (A and B) also subscribe to the purchase order topic and do their own independent processing. Application A might be a legacy application in the company, while application B may be another company’s business system, representing a B2B integration.
Using JMS, it’s fairly easy to add and remove applications from this process. For example, if purchase orders need to be processed from two different sources, such as an Internet-based system and a legacy EDI system, you can simply add the legacy purchase order system to the mix (see Figure 1-10).
What is interesting about this example is that the ERP gateway is unaware that it is receiving purchase order messages from two completely different sources. The legacy EDI system may be an older in-house system or it could be the main system for a business partner or a recently acquired subsidiary. In addition, the legacy EDI system would have been added dynamically without requiring the shutdown and retooling of the entire system. Enterprise messaging systems make this kind of flexibility possible, and JMS allows Java clients to access many different messaging systems using the same Java programming model.
Get Java Message Service, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
