Sergey Shishkin

on agile software development

Remoteness Ignorance

Term

Let me coin this term for a software engineering principle of organizing communications between components in a way, independent of components’ locations (where are they deployed).

There are more general principles like Autonomy (hmm.. no wikipedia article for it?) or Loose Coupling, but I want to focus on the remoteness aspect explicitly.

Misleading Approach

Previously I always tried to hide communication infrastructure behind interfaces of my services. I thought it was Remoteness Ignorance. (The idea were the same as putting data-access code behind a repository interface to achieve Persistence Ignorance.)

It looks good for the first time: you call the same interface methods, no matter where actually the service, implementing the interface is sitting: same or another AppDomain, another process, another machine, another network. Quite remoteness-ignorant, nice.

Real World

Naïve illusions. They vanish when slow connections and partially connected clients come. Now I have to care about transport-related exceptions, timeouts and asynchronous programming model.

Problem

It means that I got my service interface polluted with those infrastructure concerns. Moreover, I have to implement the same infrastructure functionality for each service agent, even if it’s local. What I wanted was separating the domain and infrastructure concerns.

I identified the problem to be the well-known RPC communication style. RPC inherently mix domain with infrastructure.

Solution

As an alternative I tried to explore asynchronous messaging and the Message Bus pattern. In a messaging world the message represents domain knowledge while the message bus takes care of the infrastructure.

It gave me real Remoteness Ignorance because implementation details of the infrastructure (transports, queues, protocols) are well hidden behind the message bus interface (just as a repository hides data access logic).

Moreover, messaging brings other benefits valuable for Autonomy:

  • Services are only coupled to message contracts, not to each other.
  • Communications are also distributed in time now (asynchronous).
  • Services are more robust, since they make no assumptions regarding presence of their counterparts.

I plan to discuss asynchronous messaging and the Message Bus in upcoming posts here. The real implementation and some code samples will also come. So, stay tuned 😉

Advertisements

Written by Sergey Shishkin

01.08.2008 at 10:38

Posted in Uncategorized

One Response

Subscribe to comments with RSS.

  1. Hi Sergey,
    great post! I realized the problem with RPC-style handling of remote systems a few months ago and we also investigated solutions based on messaging and a message bus.
    Cheers,
    Stefan
     

    Unknown

    05.08.2008 at 14:09


Comments are closed.

%d bloggers like this: