It Has Channels, and It’s Not Mars
Spring Integration in Action
One newer member of the Spring family, Spring Integration, provides easy to use implementations of common integration patterns. This article taken from Spring Integration in Action, offers an overview of Spring Integration’s message transport conduits, their individual characteristics, and how you can get the most of your application by using the right kind of channel for the job.
Messages don't achieve anything sitting all by themselves. In order to do something useful and pass along the information they're packaging, they need to travel from one component to another and, for this, we need channels, which are well-defined conduits for transporting messages across the system.
To use a letter analogy, the sender creates a letter and hands it off to the mailing system by depositing it into a well-known location, which is the mailbox. From there on, the letter is completely under the control of the mailing system, which delivers it to various waypoints, until it reaches the recipient. The most that the sender can expect is another reply—but, otherwise, who routes the message and who the physical recipient of the letter is (if, for example, the letter is addressed to an organization rather than a person) are things that are not known to it. From a logical standpoint, the channel is very much like a mailbox—a place where certain components, called Producers, deposit messages that are later on processed by other components, called Consumers. This way, Producers and Consumers are decoupled from each other and are only concerned about what kinds of messages they can send and receive, respectively.
One distinctive trait of Spring Integration, which differentiates it among other enterprise integration frameworks, is the emphasis that the channels play in defining the enterprise integration strategy. They're not just plain information transfer components, but they play an active role in defining the overall application behavior. The business processing takes place in the endpoints, but you just have to alter the channel configuration to completely change the application's runtime characteristics.
So, you'll see channels presented from a logical perspective, but you'll also get an overview of the various channel implementations provided by the framework, their individual characteristics, and how you can get the most of your application by using the right kind of channel for the job.
Using channels to move messages
To connect the producers and consumers configured within the application we use a channel. All channels within Spring Integration implement the MessageChannel interface shown below, which defines standard methods for the sending of messages. Note, however, that it provides no methods to allow the receipt of messages.
The reason for this is that the message channels provided by Spring Integration fall into two distinct categories that primarily differ with regard to the mechanism for handing the message over to the next endpoint.
Do you have any message for me?
PollableChannels as defined by the interface shown below require the receiver or the framework acting on behalf of the receiver to carry out a periodic check to see if messages are available on the channel. This approach has the advantage that the consumer can process messages at a time of their choosing. The approach can also have downsides, creating a tradeoff between longer poll periods, which create latency in the processing of a message, and computation overhead from more frequent polls that find no messages.
I’ll let you know when I’ve got something
The alternative offered by Spring Integration is the SubscribableChannel interface, which is implemented by channels that take responsibility for notifying subscribers when a message is available. In most cases, however, the JOJO consumer code will remain unaware of the capabilities of the channel from which messages are received since the framework will take responsibility for subscribing or polling, as appropriate.
While it is important to understand the implications of whether a channel pushes out messages or is periodically polled, in most cases the framework will take on the concern of connecting a consumer to a channel, alleviating the complications of defining the appropriate consumer types. To put it plainly, your job is to select the appropriate channel type, and the framework will select the appropriate consumer type (polling or event driven).
The right channel for the job
Spring Integration offers a number of different channel implementations and since is an interface you are also free MessageChannel to provide your own implementations. The type of channel selected will have significant implications for your application, including transactional boundaries, latency, and overall throughput. This section will walk you through the factors to consider and a practical scenario of selecting appropriate channels. In the configuration, we will use the namespace but we will also discuss which concrete channel implementation will be instantiated by the framework.
In our flight-booking Internet application, a booking confirmation results in a number of actions. Foremost in the mind of many businesses is the need to get paid, so making sure that we can charge the provided credit card is a high priority. We will also want to update the number of available seats to ensure we don't overbook the flight. The system will also be required to send a confirmation email with details of the booking and additional information on the check in process. In addition to a website, our Internet booking application exposes a REST interface to allow third-party integration for flight comparison sites and resellers. Since most of the airline's premium customers come through the airline's own website, any design should allow us to prioritise bookings originating from there over third-party integration requests in order to ensure that the airline's direct customers experience a responsive website even in times of high load.