| Messaging enables a loosely coupled environment in which an application doesn't need to know the intimate details of how to reach and interface with other applications. In choosing a type of communication infrastructure, it is important to consider the tradeoffs between loosely coupled and tightly coupled interfaces, and asynchronous and synchronous interaction modes. 5.1.1 Remote Procedure Call (RPC)-Style Programming Remote Procedure Call (RPC)-style programming has had reasonable adoption in the industry for a number of years. Technologies that predominantly use RPC-style communication include Common Object Request Broker Architecture (CORBA), Remote Method Invocation (RMI), DCOM, ActiveX, Sun-RPC, Java API for XML-RPC (JAX-RPC), and Simple Object Access Protocol (SOAP[1]) v1.0 and v1.1. [1] SOAP 1.2 has moved to support asynchronous message-based exchange as well as synchronous RPC.
About RPC Programming In RPC-style programming, an object and its methods (or a procedure and its parameters) are "remoted" such that an invocation of a procedure or method can happen across a network separation. An application uses a local proxy, commonly referred to as a "stub," that mimics the interface of the remote object and its methods. The application making the procedure calls is known as a "client," and the remote implementation is referred to as a "server" or "service." The client executes what looks like a local method invocation or procedure call, which is actually getting "marshaled" across the wire to the remote implementation. Likewise, the return values and output parameters are marshaled back to the caller. |
RPC-style interfaces have the advantages of a programming model where remote procedures are exposed in a way that mimics the underlying object architecture of the applications concerned, allowing a developer to make "normal"-looking method calls in the native language. RPC-style communications tend to be synchronous in nature. By design, RPC-style programming mimics the serial thread of execution that a "normal" nondistributed application would use, where each statement is executed in sequence. A distributed synchronous RPC call provides the luxury of an immediate response indicating whether an operation was successful. However, in a distributed system, there are additional failure scenarios that a nondistributed program does not have to deal with. When performing a synchronous operation across multiple processes, the success of one RPC call depends on the success of all the downstream RPC calls that are part of the same synchronous request/response cycle. This makes the whole invocation an all-or-nothing proposition. If one operation is unable to complete for any reason, all other dependent operations will fail with it (Figure 5-1). If one of the processes is not available, the application initiating the request must somehow make note of the failure, try it again later, or take some other course of action e.g., inform a human that they are simply out of luck and must try back later. To compensate for this, error handling and recovery logic must be built into every application that makes use of RPC-style programming. Figure 5-2. Synchronous RPC-based interactions consist of multiple point-to-point integrations that intrinsically depend on each other 
5.1.2 Tightly Coupled Interfaces In a tightly coupled RPC environment, each application needs to know the intimate details of how every other application wants to be communicated with the number of methods it exposes and the details of the parameters that each method accepts. As the number of applications and services increases, the number of interfaces that need to be created and maintained quickly becomes unwieldy. An interface represents the public methods that are exposed by a remote service or a remote object. If the number of interfaces of each object is exactly one, the number of connection points represents the number of interfaces. In practice, the number of interfaces on an individual object or service is more than one. A simple formula that is often used for estimating the number of interfaces between applications is n(n-1)/2. If the number of applications is 5 (n=5), as in Figure 5-2, the number of interfaces is 10. That doesn't sound too bad, does it? But if the number of applications is 13, as in Figure 5-3, the number of interfaces is 78. And if the number of applications is 100, the number of interfaces between them becomes 4,950. This formula makes two assumptions that you need to consider when factoring in your own potential situation. First, it assumes that each application endpoint has only one interface, and second, it assumes that every application needs to interact directly with every other application. Figure 5-3. The conservative formula for calculating the minimum number of application interfaces is n(n-1)/2 
Figure 5-4. The number of tightly coupled point-to-point interfaces between applications can quickly become unwieldy 
In practice, each application will have much more than one interface, and not every applications will need to interface directly with every other application. For example, if each application has an average of four RPC-style interfaces, and each of your 100 applications needs to communicate with only 50% of the other applications, your total number of interfaces will be 200 * 199 / 2 = 19,900. If we were to use the statistics cited in Chapter 2 and assume only 15% of the 100 applications were actually connected to each other, that would be 60 * 59 / 2 = 1770 interfaces. Still, that's a lot of interfaces to create and maintain over time. 5.1.3 Loosely Coupled Interactions Asynchronous messaging allows each communication operation between two processes to be a self-contained, standalone unit of work. Each participant in a multistep business process flow need only be concerned with ensuring that it can send a message to the messaging system (Figure 5-4). The higher-level ESB built on top of the messaging system will get the data to the places that it needs to get to, in the target data format that it needs to be in. Asynchronous request/response patterns are also possible, as discussed later in this chapter. The application initiating the conversation need only be concerned with initiating the "request," knowing that it will eventually receive a "response" asynchronously. In a complex interaction across multiple processes and services, the response may not even go to the original requestor. Each response may actually be a new message being sent to a forwarding address. This is the basis of what has become known as itinerary-based routing in an ESB. 5.1.4 Loosely Coupled Interfaces Asynchronous interactions are a key design pattern in loosely coupled interfaces. In an environment where multiple applications and services need to interact with each other, it is not practical that every application be required to know the details of every other application's myriad method calls and parameters. An asynchronous message should be an autonomous unit of work that carries data and context around with it from place to place. It is up to each application or service that processes the message to look into its contents to get the data that it needs and to act upon that data. Figure 5-5. Asynchronous message-based interfaces are much more loosely coupled and manageable 
In contrast to the n(n-1)/2 problem of tightly coupled RPC, using loosely coupled messaging reduces the number of interfaces to something more linear, where the number of interfaces is exactly the number of connection points. This view can also be a bit skewed in that all applications across an enterprise do not share exactly the same data. However, many applications can share common business messages even if they operate on different parts of it. A business message can carry enough information that it can be accessed, shared, manipulated, and updated by many different kinds of applications across an enterprise. For example, a purchase order document can contain the name and address of a buyer. The address could be divided into two distinct addresses for billing purposes and for shipping purposes. The invoicing applications will focus more on the billing address, while the shipping logistics application will focus more on the shipping address. A purchase order document can also contain individual line-item data for goods purchased, which can be used by the inventory and fulfillment applications. This document can be encapsulated in an XML message and passed around between all these applications as a single message. Does this mean that messages are bigger than they need to be? Perhaps. However, performance and throughput in a reliable messaging system are by and large governed by the number, not the size, of messages traveling through the system. The size of the messages certainly matters, but it is a secondary issue. In Chapter 6 we will explore how an ESB can help reduce the excess processing overhead that is caused by the verbosity of XML data. Arguments regarding the N-squared versus N-linear formulas can be a bit subjective at times, but they are grounded in reality. Your mileage will certainly vary. The bottom line is that loosely coupled message-based interfaces significantly reduce the number of distinct interfaces that need to be created between applications and services. 5.1.5 N-Squared Data Formats: It's Really About the Data Transformations Perhaps what's equally important is how the N-squared formula can also be applied to the number of data transformations that need to occur between applications in a system consisting of multiple point-to-point integrations. If every point-to-point link between every application has exactly one data transformation, the numbers are just as daunting as the numbers of point-to-point interfaces. In contrast, the generic data exchange architecture approach using a canonical XML format, as described in Chapter 4, allows a more linear ratio between the number of applications and the number of data transformations that need to be created and maintained. Applications that are plugged into the bus don't need to know how other applications represent data. Each application needs to be concerned only with how it converts to and from the canonical format. 5.1.6 Get on the Bus The combination of loosely coupled interfaces and asynchronous interactions is a key concept of bus terminology. Think of hardware bus architecture, such as a PC motherboard, with multiple slots that any type of compatible card can be plugged into. The use of the term "bus" in ESB is analogous to that. There is a standard way that you plug into the bus, and whatever is being plugged into the bus is not concerned with how it communicates with anything else on the bus. Everything on the bus is accessible by anything else on the bus. If you are the owner of a service or an application domain, you need only be concerned with three operations: plugging into the bus, posting data to the bus, and receiving data from the bus. The bus then gets the data to the applications in the target data formats. 5.1.7 Loosely Coupled Web Services Standards It's not only ESB proponents who recognize the need for loosely coupled interfaces. The many groups that are defining web services standards have recognized that loosely coupled asynchronous processing is a more appropriate model for describing interfaces and interactions between applications and services. For example, SOAP 1.2 and WSDL 2.0 have removed all dependencies on RPC-style invocations that were once heavily ingrained in their respective invocation models. The specifications still support it, but they don't promote it as the recommended means of interaction. Web service-based process modeling and choreography efforts such as WS-BPEL and WS-Choreography are also based on a loosely coupled asynchronous exchange of information. In the Java community, even JAX-RPC, the Java specification for performing RPC-style invocations, has decided to adopt asynchronous processing as a goal for Version 2.0 of the JAX-RPC specification. |
