[erlang-questions] design pattern question for messaging

[Miles Fidelman]

Ryan Brown wrote:
> Two more cents. I work on the same system as Rich and I can see a 
> hybrid approach here being a very nice way to go. You could use rabbit 
> (or really any MQ of your choice) for persistence with one queue per 
> step in the process. Your application would then just listen to 
> messages from each queue, spin a process to handle it and enqueue it 
> in the next step. As Jesper mentioned, this could all be tracked 
> nicely via an fsm.
>
> Miles, do you feel like your questions have been answered for this 
> thread? I know it has spawned some creative thoughts on my end!
>
>
Well... partially - as you say, spawned some thoughts.  Also looked at 
Rabbit and exchanged some email with one of its designers, who I 
conveniently happen to know.

The thing is, I'm thinking of things that are a lot longer-lived, and 
larger, than MQ messages - think email messages with attachments that 
are getting routed around, worked on, held while waiting for events, 
worked on some more, moved around some more, archived, etc. Best analogy 
is the way forms and documents move through an organization.

What I'm coming to realize is that maybe a document store - CouchDB 
comes to mind - might be the best thing to use to hold queues; using 
it's replication mechanisms for resiliency.

Then again, part of me is thinking that each document should just be its 
process.  And what I'm really looking for is a conceptual and 
computational model that combines Erlang-like actors, with 
Smalltalk-style objects (which is really what Alan Kay had in mind 
before all the Smalltalk implementation came out single-threaded). 
Massively concurrent Smalltalk could be a really sweet environment.

By way of context:  I've been working on a family of applications that 
involve large groups working on shared and linked documents (business 
plans, proposals, military mission plans - that kind of thing) - with a 
distributed versioning approach (i.e., git for documents rather than CVS 
or Sharepoint).  Workflow is much like the way we do paper - documents 
get copies, distributed, handed off from one person to the next, merged, 
split up, etc.  Changes, and approvals for changes will be through 
publish subscribe.

I keep coming back to wishing for an environment where the basic "unit 
of computation" has both actor-like properties and object-like 
properties.  Long term persistence, data encapsulation, plus 
message-passing concurrency.  Erlang seems to be the best starting point 
that I've found.

Cheers,

Miles





-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra