[erlang-questions] design pattern question for messaging
Wed Jul 23 22:31:08 CEST 2014
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
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.
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the erlang-questions