[PEAK] Junction [was Re: Interfacing Peak with Twisted]

[John Landahl]

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.

- John