[erlang-questions] Dynamically dispatching encoded messages to functions

Ben Hood 0x6e6562@REDACTED
Thu Oct 4 23:07:01 CEST 2007


Hi,

I'm trying to implement a generalized message handling mechanism for
messages that are send to AMQP subscribers and would like some advice
about a clean Erlang way to achieve this.

An AMQP subscriber receives messages in the following pattern:

{content, Properties, Payload}

whereby both terms are opaque binaries that must get decoded to Erlang terms.

I have functions that would decode these binaries and re-encode a
response, but I don't want to put that plumbing into modules that
implement business logic.

The function I have decodes the payload into a [ FunctionName |
Arguments ] head/tail, so that I can dynamically dispatch the
arguments to a specific function.

Ideally I would like to implement specific business logic in a
transport agnostic fashion, for example I write simple gen_server
behaviours that are not coupled with the AMQP plumbing.

I have thought of a few approaches to this problem:

1. Decode the payload in a generalized gen_event instance and look up
the target module and function

a) using a apply(M,F,A) pattern
b) or creating Funs that are keyed on the FunctionName parameter.

2. Create a gen_server template as an include, so that the plumbing
code and non-business logic specific callbacks do not need to be
repeated.

3. Implement all entry points to every business function in the same
module and use one gen_server instance to handle the communication
plumbing.

4. Just repeat myself in every business specific gen_server instance,
minimizing this by extracting as much plumbing into some external
module.

Each approach has it's pro's and con's:

1. Neat, but the dynamic dispatch may be expensive.

2. No repetitive source code, but having statically linked functions
(although quick) may prove to be a maintenance problem (I think, maybe
because of code reloading)

3. Easy to implement but this becomes very monolithic very quickly and
the gen_server state is a kitchen sink.

4. Seems least intrusive of all but I think there will be a degree of
code repetition here, especially for the function signatures.

Does anybody have any experience or known of any examples where this
type of problem is solved in Erlang, or am I completely missing the
point?

Thx,

Ben



More information about the erlang-questions mailing list