[Haskell] What would Haskell middleware look like?

Paul Johnson paul at cogito.org.uk
Fri Jul 14 19:33:14 EDT 2006


I've noticed that many other languages have a middleware to handle 
distribution and concurrency issues.  Haskell has STM for shared-memory 
concurrency, but there is no mechanism (AFAIK) for distribution.  So 
I've been having a think about what one might look like.

The primary requirements seem to me to be:

* Transactions:

STM is great, and the concept should work for distributed computation as 
well.  So you should be able to say something like:


   atomic $ do { send message1 remote1; send message2 remote2}

Both remote1 and remote2 processes will have world-visible state 
modified by the messages, but either they both happen atomically or 
neither happens.


* Pi Calculus

I've been reading a bit about this, and I think I see the basic ideas.  
The middleware operations should have a formal semantics specified in 
the Pi calculus, on the grounds that its the best formalism currently 
available.  That way we can prove that the operations preserve desirable 
properties.

* Replication

If you want a reliable distributed system you absolutely have to have 
replicated tasks.  Haskell's strict control over side effects is a big 
strength here: the headache for reliable replication has always been 
threads doing non-deterministic stuff that gets them out of sync.  How 
does the IO monad interact with this?  Replicated threads cannot be in 
the IO monad because that doesn't guarantee determinism, but they need 
to interact with the real world somehow.

* Configuration management

Another big headache for middleware.  If you are not careful it can turn 
out that the only way to upgrade a component in the system is to upgrade 
all the components simultaneously, which is not really an option in a 
big system that has to stay up 24x7.  Component names are not the right 
place for version numbers, and you need some formal definition of upward 
compatibility.  Could XML have a place here?  It does let you do duck 
typing.  Or can we come up with something stronger?


* Serialization of circular data structures.  "show" is fine for 
non-looping structures, but what about:
 
let
   x = 1 : y
   y = 2 : x

Can we find a way of transmitting such a structure?

Thats all I can think of for now.

Paul.



More information about the Haskell mailing list