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 SOA or message passing styles are only for computing in the large. But 'inproc' is the wrong term. We should be talking about interproc. Service Oriented is not just useful for 'obviously' distributed systems. It's 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 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. 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....
Previous Topic
