« You'll shut me down with a push of your button? | Main | Crypto-Gram has an RSS feed »

Interprocess SOA

So. Here's a quote:

1. Processes have 'share nothing' semantics. This is obvious since they are imagined to run on physically separated machines.
2. Message passing is the only way to pass data between processes. Again since nothing is shared this is the only means possible to exchange data.
3. Isolation implies that message passing is asynchronous. If process communication is synchronous then a sodware error in the receiver of a message could indefinitely block the sender of the message destroying the property of isolation.
4. Since nothing is shared, everything necessary to perform a distributed computation must be copied. Since nothing is shared, and the only way to communicate between processes is by message passing, then we will never know if our messages arrive (remember we said that message passing is inherently unreliable.) The only way to know if a message has been correctly sent is to send a confirmation message back. - Joe Armstrong (Making reliable distributed systems in the presence of software errors) [pdf]

That greatly impressed me when I read it first. Not because of SOA or REST or any of that stuff. But because it's a quote about the archictectural constraints of a programming language - Erlang. It still impresses me - Joe Armstrong's PhD is a tour de force, required reading for those of us working on top of virtual machines and networks.

I've been following the discussion going on between Steve Loughran, Ted Neward and Patrick Logan regarding the granularity of the SOA model. The conversation has gotten around to Erlang:

Patrick Logan implies that the solution to having an SOA model inproc is Erlang. I shall have a look at this. I was debating looking at learning a new language, as I am finding Java dev too, slow, these days, even with a refactoring IDE. I was trying to decide between Python and Ruby though :) - Steve Loughran

I come firmly down on the inproc SOA side. I would find it hard to believe anyone could read Armstrong's thesis and decide that the message passing style is only for computing in the large. But we should be talking about interproc. mesage passing seems suitable for any system with interprocess communications that needs to be flexible, robust and scale. Joe Armstrong describes Erlang as a concurrent pure message passing language *, which sounds like some of the core constraints of an SOA, or at least a good start.

Java is getting there. Isolates (JSR-121) when they arrive (1.6), will offer some of the constraints needed to build decent inter-process systems on the JVM. Plus the sadly underused JavaSpaces has shown us how to really design a protocol/service oriented API. The Jini folks have been banging the services drum for years. There is also the E language, one the first languages built on the JVM. Finally the 1060 net kernel stuff is a REST/URI oriented approach and supplied as a jarfile.

* Which might be characterized as Smalltalk on steroids. There's a lot of confusion around what is meant by 'message passing' in Smalltalk. Conceptually I think Smalltalkers are talking about message queue type messaging and in some cases asynchrony, but physically I understand Smalltalk works like Java or C++, i.e. it's jumptables, and pointers all the way down. Hence the confusion, but I trust someone will correct me if I'm wrong about this.

April 18, 2004 04:05 PM


Isaac Gouy
(April 20, 2004 05:02 AM #)

"characterized as Smalltalk on steroids"

That's probably more confusing than helpful - it underplays the importance of Erlangs process isolation. (And Erlang is a single-assignment functional programming language, with extensive use of pattern matching.)

No there really isn't much confusion around what is meant by message passing in Smalltalk ;-) Although you might be interested in the old work on Actor languages in Smalltalk http://citeseer.ist.psu.edu/briot89actalk.html

Jon Hanna
(April 20, 2004 10:36 AM #)

Interesting. RPC models arguably take something that works well on a local system (I actually like COM on a local system, though perhaps I am insane) and tries to make it work on a distributed system. This seems to be taking something that works on a distributed system and showing that it can work well on a local system.

Not sure I like having message confirmation as high up as it appears to be (I've only glanced at the links you give here). This would seem to be like using UDP rather than TCP for transport, with the inherent headaches - great to have as an option, but I want to be able to have reliability for free as well.

(April 20, 2004 05:21 PM #)

actually one part of your quote there that impressed me was the phrase "sodware errors" which is something I seem to encounter quite often.

(April 20, 2004 06:13 PM #)

"sodware errors"
Typography with ligatures -> Typography without ligatures.

Post a comment

(you may use HTML tags for style)

Remember Me?

Trackback Pings

TrackBack URL for this entry: