Difference between RPC system and Enterprise Service Bus

Question

What's the difference between an RPC System, like Twitter's Finagle, and an Enterprise Service Bus, like Mule? What kind of problems are each of them good at solving?

Answer 1

I will try to answer this as a soft explanation, rather than a technical breakdown of features:

One may say that Finagle is a asynchronous messaging library that allows services to connect to one another freely (not tightly tied to architectural system integration standards) while supporting multiple protocols.

From the Finagle website:

Finagle is a network stack for the JVM that you can use to build asynchronous Remote Procedure Call (RPC) clients and servers in Java, Scala, or any JVM-hosted language. Finagle provides a rich set of protocol-independent tools.

An enterprise service bus (ESB), on the other hand, is a asynchronous messaging architecture which typically adheres to industry standards and protocols. An ESB promotes a system where message flow is controlled and routed between systems, and where servers can register their service and clients can register what messages they are interested in. The services offered by servers can be registered and versioned.

You will typically find Finagle being used somewhere between a website and backend services. But, you will typically find an ESB inside a large corporate, where it's responsible to integrating systems like finance, support, sales, etc.

Both solutions offer asynchronous messaging and buffering to various extends, but are not designed to solve the same problem. For ESB, you would probably think 'strict, enterprise', but for Finagle you would probably think 'flexible, web'.

Hope this helps

Update:

Not quite related, but if you are exploring this space, I would look at Kafka these days.

Answer 2

RPC and ESB are two architectural patterns. While RPC is usually a request-reply and synchronous in nature, an ESB works on the concept of messaging (simplified explanation) and of asynchronous in nature. ESB is the foundation for any SOA implementation. ESB enables loose coupling thus promoting true agility. A simplified example from implementation perspective is as follows:

A web service is a typical RPC. The consumer is tightly bound to the producer and any change in the contract on the producer side, will require changes on the consumer side.

In ESB, the service consumer doesn't invoke the service producer directly. It just puts the message in the bus and based on the rules (mediator), appropriate service producer will handle it. If the service consumer and service producer talk in different formats, ESB provides the facility to do the transformation (like formatting the zipcode as xxxxx-xxxx, splitting the name into first name and last name, etc.).

This is just simplified explanation. For more information, please check the following links:

Why do developers need an Enterprise Service Bus?

Enterprise Service Bus

Answer 3

Both solve completely different problems:

• An ESB is an intermediation middleware that provides message transformation and routing, protocol adaptation and other value-add operations (like orchestration, guaranteed delivery, idempotent filtering...). It sits in-between your service consumers and providers and transparently (ie without any change in consumer or provider) provides its different features.
• An RPC system provides client and server technologies for performing RPC operations.