Java Reference
In-Depth Information
You all also know what a façade is, serving to abstract away the functionality of other components in
an abbreviated interface to provide courser functionality. You might use a façade to build an interface
oriented around vacation planning that in turn abstracts away the minutiae of using a car rental, hotel
reservation, and airline reservation system.
You build a gateway, on the other hand, to provide an interface for your system that insulates clients
from the middleware or messaging in your system, so that they're not dependent on JMS or Spring
Integration APIs, for example. A gateway allows you to express compile time constraints on the inputs
and outputs of your system.
There are several reasons why you might want to do this. First, it's cleaner. If you have the latitude
to insist that clients comply with an interface, this is a good way to provide that interface. Your use of
middleware can be an implementation detail. Perhaps your architectures messaging middleware can be
to exploit the performance increases had by leveraging asynchronous messaging, but you didn't intend
for those performance gains to come at the cost of a precise, explicit external facing interface.
This feature—the capability to hide messaging behind a POJO interface—is very interesting and has
been the focus of several other projects. Lingo, a project from that is no longer under
active development, had such a feature that was specific to JMS and JCA. Since then, the developers have
moved on to work on Apache Camel.
In this recipe, you'll explore Spring Integration's core support for messaging gateways, and explore
its support for message exchange patterns. Then you'll see how to completely remove implementation
details from the client-facing interface.
The most fundamental support for gateways comes from the Spring Integration class
SimpleMessagingGateway . The class provides the ability to specify a channel on which requests
should be sent and a channel on which responses are expected. Finally, the channel on which replies
are sent can be specified. This gives you the ability to express in-out, and in-only patterns on top of
your existing messaging systems. This class supports working in terms of payloads, isolating you from
the gory details of the messages being sent and received. This is already one level of abstraction. You
could, conceivably, use the SimpleMessagingGateway and Spring Integration's concept of channels to
interface with file systems, JMS, e-mail, or any other system and deal simply with payloads and
channels. There are implementations already provided for you to support some of these common
endpoints such as web services and JMS.
Let's look at using a generic messaging gateway. In this example, you'll send messages to a service-
activator and then receive the response. You manually interface with the SimpleMessageGateway so that
you can see how convenient it is.
package com.apress.springenterpriserecipes.springintegration;
import org.springframework.integration.core.MessageChannel;
import org.springframework.integration.gateway.SimpleMessagingGateway;
public class SimpleMessagingGatewayExample {
public static void main(String[] args) {
ClassPathXmlApplicationContext ctx =
new ClassPathXmlApplicationContext("solution042.xml");
MessageChannel request = (MessageChannel) ctx.getBean("request");
MessageChannel response = (MessageChannel) ctx.getBean("response");
SimpleMessagingGateway msgGateway = new SimpleMessagingGateway();
Search WWH ::

Custom Search