SOA in an Offline World

There is a discussion on Linked-In entitled SOA in an Offline World. The discussion has a technical focus: What kind of technology architecture to use with unreliable or intermittent network communications. There are some design patterns that may support intermittent connection, such as decoupling and asynchronous communications, and these patterns may be appropriate in a range of situations including military and medical.

A broader architectural question is whether we can use layering to hide these technical issues from the business-facing services in the layers above. In an ideal world, we would have a disruption-tolerant service platform, and the core business services and applications can then operate as if we had perfect and permanent connectivity.

In the 1990s, Peter Deutsch and James Gosling identified Eight Fallacies of Distributed Computing - invalid assumptions that inexperienced designers make when designing distributed systems. See Arnon Rotem Gal-Oz and Paul Vincent (TIBCO). These include the assumption of perfect and permanent connectivity.

By the way, Tim Bass questions whether anyone nowadays suffers from these fallacies. I think he's got a point, but perhaps the problem here is in the word "fallacy". If you ask a designer if he believes connectivity is going to be perfect, he will almost certainly say no. But if you inspect his designs, however, you may well find that he has failed to allow adequately for imperfect connectivity. Not so much a failure of belief as a failure of attention.

So the important question here is - can we compensate for the imperfections of distributed systems by having a really clever architecture, supported by really clever technology, so that the applications can operate as if we didn't have any of the problems of distribution at all? Some people may well believe that to be possible, either now or in the foreseeable future.

I don't think it's so easy. I have long argued that SOA needs to embrace three-valued logic. If this is done properly, it would make the whole architecture disruption-tolerant, not just the underlying layers. We also need to understand how disruption-tolerance affects the behaviour of the whole business-facing system. Not just technology then.