[PEAK] Content-based routing via generic functions
Phillip J. Eby
pje at telecommunity.com
Thu Jul 22 19:15:48 EDT 2004
This is mostly a note to myself on a future application of generic
functions... content-based routing ala Elvin.
Specifically, imagine a messaging server that allows clients to subscribe
to messages based on a set of criteria, e.g. as specified by a short Python
expression. If such a system were based on simply evaluating each
subscriber's criteria, routing performance (ignoring I/O) degrades linearly
with the number of subscribers, regardless of message applicability. But,
with the generic function engine, all criteria are evaluated at most once
per message, and routing performance degradation should be sub-linear.
Such a messenging server could use a variety of protocols to receive or
send messages, including Jabber XML streams, XML-RPC, POP/SMTP, or any of
the various Python messaging protocols such as PB or Pyro.
In effect, each "subscription" can be treated as a "method" to be added to
the generic function. The actual method would probably be a method on an
event source used to create the subscription, with an events.Task
monitoring the event source and sending the events over the wire once
received. By using a simple method combiner that just invokes all of the
applicable methods, all the subscriptions that a given message applies to
can be fired.
Interestingly, this "messaging server" itself doesn't have to have any
I/O-specificness to it. It's probably more appropriate to just call it a
"message router". This means you could just use it in-process for various
purposes, or create one and allow multiple simultaneous external protocols
to use it. For example, one might have both Jabber and Pyro clients
sending or receiving messages through the same "router".
Of course, for this to work, there'd have to be a few minor additions to
the current generic function framework. Primarily we'd need a way to
remove methods from a generic function. Also, a message router that was to
be used in an event driven system probably wouldn't want to actually fire
all the subscriber events upon receipt of a message, but would instead
schedule them to be fired in subsequent iterations of the event loop, in
order to maximize responsiveness. But neither of these things is any big deal.
Also, if you were going to use Python expressions as your subscription
filters, you would need to use something like Zope 3 security proxies to
avoid arbitrary code execution. Or, more likely, just use a different
expression parser to construct the Signature objects, one that's limited to
the functionality your system wants to offer.
Last, but not least, if there were a way to verify whether a generic
function has any methods that apply to a given signature, then we could
also have a "quench" capability similar to that of Elvin. That is, if you
have a set of connected message routers, you can avoid inter-router traffic
for messages that don't meet any criteria at the target router. For that
matter, you can also avoid even *generating* messages that nobody cares about.
This seems also like an interesting extension for logging, performance
measurements, system monitoring, and other enterprise metrics. That is,
those systems also potentially have need for such event routing.
More information about the PEAK
mailing list