Exposing a remote API through Remote Procedure Calls

Remote Procedure Calls (RPC) is an integration style that tries to hide the fact that dif- ferent services are running on different systems. The method invocation is serialized over the network to the service provider, where the service is invoked. The return value is then serialized and sent back to the invoker. This involves proxies and export- ers (in Spring) or stubs and skeletons (in EJB).

RPC would presumably allow architects to design scalable applications without developers having to worry about the differences between local and remote invoca- tions. The problem with this approach is that certain details about remoting can’t

41

Summary

safely be hidden or ignored. Assuming that RPC can hide these details will lead to sim- plistic solutions and leaky abstractions. Dealing with problems properly will violate the loose coupling we’ve come to enjoy.

RPC requires that parameters and return values of a service are serializable, which means they can be translated into an intermediate format that can be transmitted over the wire. From case to case, this can be achieved in different ways, such as through Java serialization or using XML marshalling through mechanisms such as Java Architecture for XML Binding (JAXB). This not only restricts the types that can be sent, it also requires that the application code deal with serialization or marshalling errors.

We’re probably not the first to tell you, but it’s worth mentioning again that the network isn’t reliable. You can assume that a local method invocation returns within a certain (reasonable) time with the return value or an exception, but with a network connection in the mix, this can take much longer, and worse, it’s much less predict- able. The trickiest part is that the service that’s invoked can return successfully, but the invoker doesn’t get the response. Assuming you don’t need to account for this is usually a bad idea.

Finally, serializing arguments and return values harms interoperability. Sending a representation of some Serializable to an application written in Perl is wishful thinking at best. The need to know about the method name and argument order is questionable. Once this is understood, it’s not such a big leap to look for an interoper- able representation and a way to decouple the integration concerns from the method signatures on both sides. This is one of the goals of messaging, our final integration style and the one that’s the general focus of Spring Integration.

2.3.4 Exchanging messages

Messaging is an integration style based on exchanging encapsulated data packets (messages) between components (endpoints) through connections (channels). As described at www.enterpriseintegrationpatterns.com, the packets should be small, and they should be shared frequently, reliably, immediately, and asynchronously. Poten- tially this resolves many of the problems of encapsulation and error handling associ- ated with the previous three integration styles. It also provides an easy way to deal with sharing both data and functionality, and overall it’s the most recommended integra- tion style when you have a choice.

Message exchanging is the core paradigm of Spring Integration, and we discuss in detail in chapters 3 and 4 the concepts behind the integration style and how they’re applied in the framework.

2.4

Summary

This chapter explained the fundamental concepts that stand behind enterprise appli- cation integration. We provided applicable samples from the framework, and in the rest of the book, you’ll see them at work.

42 CHAPTER 2 Enterprise integration fundamentals

First, we discussed coupling as a way to measure how many assumptions two inde- pendent systems make about each other. You saw how important it is to minimize cou- pling to allow the components to evolve independently. There are multiple forms of coupling, but the most important ones are type-level and temporal coupling. Depen- dency injection helps you deal with type-level coupling, and using a message passing approach instead of direct calls (either local or remote) helps you deal with temporal coupling.

We presented a detailed overview of the differences between synchronous and asynchronous communication and its implications in coupling, system complexity, and performance. You saw how Spring Integration helps separate the logical design of the system from the dynamic behavior at runtime (whether interaction should be syn- chronous or asynchronous).

Finally, you got an overview of the four application integration paradigms and their respective strengths and weaknesses. Spring Integration is generally focused on messaging, but it provides support for using the other three types as well.

We introduced Spring Integration from a high level in the first chapter. Then we zoomed in on the fundamental concepts at the root of messaging in chapter 2. In chapter 3, we look in detail at the parts of Spring Integration that enable messaging, starting with messages and channels.

Part 2

Messaging

P

art 2 explains how Spring Integration provides extended messaging capabil- ities to Spring applications. It covers key concepts such as messages, channels, endpoints, routing, filtering, and splitting and aggregating messages.

With Spring Integration, messages are exchanged through channels between designated endpoints of application components as well as external systems. Also, based on enterprise integration patterns, it offers features that enable rout- ing and filtering of messages based on message headers or content.

Chapter 3 introduces messages and channels, describes the types of channels available and how they work, and demonstrates channel customizations such as dispatchers for multiple message handlers and interceptors for message moni- toring and filtering.

Chapter 4 describes the details of endpoints and how they work as a founda- tion for higher-level components. Endpoints contain business logic or integra- tion components such as routers, splitters, or aggregators.

Chapter 5 explores the separation of business and integration concerns and additional features such as transformers, service activators, gateways, and chaining. Chapter 6 investigates techniques for routing and filtering messages, and implementing more complex nonsequential message flows.

Chapter 7 addresses techniques for splitting messages into parts and aggre- gating messages into composites, as well as reordering messages and other ways to customize aggregations.

45

In document Spring Integration in Action (Page 71-76)