Introduction


Messaging has been adopted across the industry to achieve reliable asynchronous communication. If a company is already using some sort of Message Oriented Middleware (MOM), the messaging semantic and its benefits may be fairly familiar. A MOM decouples the sender from the receiver of the message and, at the same time, provides a robust data transport mechanism. The main interoperability constraint with various MOM solutions is that the messaging semantics of the middleware is tied to a specific format such as the Java Messaging Service, Microsoft Message Queue, or WS-Reliable Messaging. For instance, Java Message-Driven Beans enables the Java EE application to send and receive JMS-based messages. What happens if this Java EE application has to consume messages from MSMQ as a way to integrate with the .NET application domain? Message-driven beans cannot handle MSMQ messages out of the box. This is true for the opposite scenarioa .NET application handling JMS-based messages. This becomes a major limitation when building a reliable asynchronous environment.

To enable asynchronous message transfer across Java EE and .NET, the following five strategies can be employed:

  1. Bridging Strategy for the application integration across MSMQ and a JMS provider

  2. .NET Adapter Strategy to connect a Java application to MSMQ or a .NET application to a JMS provider, thus achieving interoperability with a single message queue

  3. Web Services Messaging Strategy to send SOAP messages over a JMS or MSMQ messaging middleware

  4. Internet E-Mail Strategy for exchanging SOAP messages over the SMTP protocol

  5. Enterprise Service Bus Strategy to streamline asynchronous collaboration of heterogeneous applications

This chapter on the whole provides insight into determining an optimal messaging strategy for building Service Oriented Architecture (SOA) to asynchronously connect Java EE and .NET applications.

The sample code for individual strategies is based on the WS-I Supply Chain Management Replenish Stock use case, [SCMArchitecture], slightly modified to leverage messaging middleware. Figure 9-1 outlines the high-level components of this use case that includes Warehouse, WarehouseCallback, and Manufacturer applications. These applications are deployed as part of the Java EE Retailer and the .NET Manufacturing systems that are integrated by means of messaging middleware.

Figure 9-1. Replenish Stock use case deployment diagram


In the diagram, the Warehouse service sends a message in the form of an XML Purchase Order document to messaging middleware. The messaging middleware persists and sends a request to the Manufacturer service. Once the order is processed by the service, an Invoice message is sent to the messaging middleware to further send it to the WarehouseCallback service. Before delving further into the design and implementation of this use case, following is a brief discussion about messaging fundamentals. (If you are already familiar with implementation details of messaging under Java and .NET, you can skip this part to read about interoperability strategies.)

Messaging Fundamentals

When designing application integration with messaging, consider what type of integration best suits the company's needs. There are three main ways to arrange inter-application communication. These are discussed in the following sections.

Fire-and-Forget

When using this messaging pattern, a message is sent with no acknowledgement or guaranteed delivery requirements. It's pretty straightforwardthe message is simply fired out and forgotten. This is not typically used when the system requires message integrity and delivery. It may be used for broadcasting messages where each individual message isn't necessarily important. An example of this might be a time and sales notification of trades in the stock market. Losing one or two individual messages isn't crucial to the overall consumer of the messagethey're just interested in the general trend.

Publish-Subscribe

This mechanism is useful when an event has to be sent to multiple recipients. A sender tags each message with a topic name to be published. For example, the Replenish Order use case might require communication with multiple manufacturing systems. In this case, publish-subscribe would be an optimal solution. A Warehouse could publish a request on a topic, StockOrder, to multiple manufacturers, which asynchronously processes the request and responds back with individual Invoices. Each of the manufacturers would have to subscribe to the StockOrder topic to receive messages. Benefits of the publish-subscribe mechanics include loose coupling between producer(s) and consumer(s) of a message.

Point-to-Point

The main difference with the point-to-point as opposed to the publish-subscribe mechanism is that only one receiver can consume a message in the queue. A message queue, for example, StockOrder, is created to persist incoming messages before sending them to the receiver. In this case, a main detraction is needed for all senders to know about all receivers.

Regardless of whether one's experience is based on .NET or Java, it is useful to learn how to implement asynchronous integration with messaging under both platforms. Thus this discussion starts with an overview of messaging under Java and .NET as background for the following topic of integration strategies.




Java EE and. Net Interoperability(c) Integration Strategies, Patterns, and Best Practices
Java EE and .NET Interoperability: Integration Strategies, Patterns, and Best Practices
ISBN: 0131472232
EAN: 2147483647
Year: N/A
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net