[PEAK] Junction [was Re: Interfacing Peak with Twisted]
john at landahl.org
Tue Mar 15 17:44:07 EST 2005
Phillip J. Eby wrote:
> At 04:51 PM 3/4/05 -0100, Tiago Cogumbreiro wrote:
>> On Fri, 04 Mar 2005 08:41:46 -0500, Phillip J. Eby
>> <pje at telecommunity.com> wrote:
>> > You might have a look at:
>> > http://peakplace.tigris.org/source/browse/peakplace/src/junction/
>> > which was a work-in-progress by John Landahl that's basically a
>> > Twisted/PEAK messaging server. It's not nearly as simple as an
>> example, of
>> > course.
>> What does it exactly do?
> I think it's some sort of messaging bridge between Twisted and something
> else. :) Obviously, I don't know very much about it.
The basic idea of Junction was to simplify distributed programming by
providing a "message bus" above multiple messaging systems. Something
like a very rudimentary JMS but with multiple backends. In theory, this
would allow one to change the underlying communication method (Twisted's
Perspective Broker, PyRO, SOAP, XML-RPC, CORBA, etc.) without changing
any application code. It would also allow the use of mixed messaging
systems within a single application, meaning that remote objects could
be written once and accessed many different ways. In practice, the only
backend implemented was for Perspective Broker, which is all we needed
at the time.
The basic features worked pretty well, though, and Junction is still
used in the production system for which is was built. With the
publish/subscribe feature one can send simple messages into the message
bus which are then received by any interested parties. [At one point
this was being used effectively for remote logging, and I plugged in an
IRC bridge which allowed me (and others) to watch application logs on
hundreds of clients in real time. Which reminds me, IRC could be used
as another backend for some very interesting capabilities.] With the
request/respond feature one can call a method on a remote object in a
location-independent way; "requests" are sent to a named object which
could be running on another machine or even in the same application.
So the code on PeakPlace works, but is not up to date. My former
co-worker added multicasting capabilities to it recently, for example.
It could probably stand to be re-written to take advantage of generic
functions and predicate dispatch, and needs a lot more features to be
generally useful, but it does serve as a non-trivial example of
integrating PEAK and Twisted. I'm about to start working with Python
and PEAK again after a few month hiatus, and am tempted to rewrite
Junction as a way of learning the latest PEAK features, especially if
anyone is interested in any of the above.
More information about the PEAK