RPCs versus Messaging There has been much discussion about the differences between RPCs and messaging. In fact, this whole acrimonious debate has obscured the most useful understanding about the two approaches. Message-oriented and RPC-based technologies are simply two different ways to get the job of communicating between pieces of an application done over the network. Either could fit well, depending on the application. Neither approach will always solve all problems. In fact, an RPC product could run over a message-oriented mechanism (though we're not aware of any specific products that do this). The differences are focused on the developer's use of the middleware, not on the actual transport or service functionality. Said another way, when it comes to deploying applications based on one or the other, they look quite similar. Different products within each category, on the other hand, exhibit much more differentiation from this deployment or networking perspective. Synchronous vs. Asynchronous Behavior People usually argue about how RPC's synchronous interaction is bad for networked applications. It is clear that the two styles map closely to very different programming paradigms. Specifically, RPC's synchronous, or blocking, interaction behavior is easily mapped to function-oriented request/reply applications, while message-oriented middleware's asynchronous, or non-blocking, interaction is extrememly useful for event-oriented applications. A blocking application transfers control over the network to the remote node. In the meantime, the user waits for the response and can't do anything else in that application. If the user is not using a multi-tasking operating system (16-bit Windows doesn't qualify), he or she cannot use the computer until the responce comes back. The application is blocked. Event-oriented applications don't want to pass control over the network. They just want the work to get done and answers sent back. In the meantime, the application can get other things done. It could even send out more requests to different networked servers and allow all its responses to come back individually without having to sequence them one after another. This parallelism can make more complex applications respond more quickly just by doing more than one thing at once. Given current RPC product implementations, it is no longer accurate to say that all RPC products are limited to synchronous interaction. Instead, most offer options to simulate degrees of asynchronicity (DCE threads or other simultaneous invocation options). These options however make application development more difficult since more programming must be done to handle multiple simultaneous RPCs in the application. Messaging products, in contrast, often offer synchronous behavior so that applications needing that level of responsiveness can get it. Queuing, Not Store-and-Forward Another common misconception is that message-oriented middleware products are slower because they are store-and-forward based. Certainly, some products specifically do offer any disk-based queuing that would handle disconnected users the way that e-mail store and forward works. Many products, however, are simply memory queue based and very efficient. Message-oriented solutions are not typically client/server session based. Unlike RPC and data access solutions, messaging solutions include session-like information in each message, and don't require setup and teardown mechanics. The application just sends a message. They are typically connectionless, rather than connection-oriented. This can lead to improved load characteristics. Session-based solutions, like RPC and data access products, often require too much overhead on the server to handle conversations with a large number of clients. For this reason alone, many current client/server solutions that are data access oriented are often limited to a few hundred simultaneous users. With a message-oriented solution, the server polls its memory queue for incoming requests, and can handle peak loads easily, much the same way any batch-oriented system can. All that's important is the number of transactions per second, not how many total users that represents. Because of these load handling characteristics, many enterprise-wide mission critical systems are being implemented using messaging technology today. Many message-oriented implementations specifically do not get implemented in low-bandwidth WAN or disconnected scenarios where session-oriented solutions are expensive. The SAP R3 financial applic ation suite, for example, uses a message-oriented connection between its clients (desktops) and its intermediate application processors. From the application processor to the actual database server (Oracle, Sybase, SQL Server, and so on), they use regular data access middleware. This three-tier application design has naturally gravitated to a multiple middleware implementation. Three-tier application design offers many other advantages, but the ability for the application to use multiple middlewares, each appropriate to the task and network at hand, is extremely helpful. SAP could have used any of these message-oriented middleware solutions as the middleware infrastructure for its applications, but instead developed some in house. Corporate and other third-party application developers would be well to consider buying middleware instead of building it. It's cheaper. Services, Not Only APIs Another distinction between RPC-based and message-oriented solutions is their support for other services. DCE RPC, for example, comes with directory and security services, and has the imprimateur of the standards process to help legitimize its technology. In contrast, many other RPC products (like NobleNet's EZ-RPC) do not offer extra services. Getting name and authentication services from these other products will require more work by the developer, either to support other external services or to create services of their own. Clearly, creating name and security services is too much work for most corporate developers, particularly to make them fully scalable to the enterprise. Unfortunately, the sorry state of APIs, the industry market and mind share for directory and security services means that developers often decide to do their own and end up with very limited solutions. Likewise for message-oriented products. Covia Communications Integrator does not come with built-in directory and security services while PeerLogic Pipes comes with a flexi ble dynamic name service, it still doesn't have true directory or security functionality. Many products offer a mix of services, be it RPC based or message oriented. Either approach and any product could be as little or as much as needed to match application requirements. We'll see this same contrast in higher-level abstraction products, specifically ORBs and distributed transaction monitors. Not all ORBs offer event-oriented functionality yet, though they'll have to soon to compete. IBM's DSOM, for example, still uses a request/reply model for interaction over the network. SuiteDOME, however, does offer a messaging infrastructure along with a full suite of directory and security services. TUXEDO, Novell's distributed transaction monitor, offers message-oriented functionality underneath its transaction semantics. Transarc's Encina, in contrast, offers a DCE-integrated (and RPC-based) transaction processing solution. November 15, 1995 Print This Page E-mail this URL