If you want service-oriented architecture, don’t use RPC

Maintaining some Java RMI code recently I’ve been getting a feeling that something is wrong. Last year when I was working with WCF on Justgiving’s SOA setup I had the same feeling.

As a programmer I find that I make technical decisions based on varying mixtures of gut feeling, anecdotal evidence, experience and rationality. All of those motivations are interesting in their own way (if you’re interested in the study of decision making I’d recommend Gary Klein’s book Sources of Power), but the one I like the most is gut feeling.

It’s sometimes hard to explain why I get a gut feeling, but in the case of RMI I know exactly why. It’s because it ties both sides of an interface to the same technology.

The whole point of an interface is that each side doesn’t need to know anything about the other side, other than what directly affects the transaction between them. Adding constraints beyond that transaction seems inherently wrong to me.

When I worked at Moreover, one of the things that I liked most about their architecture was that they could build and replace any component with one built with a completely different technology to the rest of the system. They had a loosely-coupled architecture with clear, open, interfaces, and minimum dependency. Conventional RPC technologies such as RMI and WCF just can’t do that.

An interesting addendum to that point is Thrift (thanks Dimi) which is a cross-language RPC system looked after by Apache. I’ve got a gut feeling about that too, but that’s another post.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: