[TransWarp] Requirements for the future peak.messaging package

[Phillip J. Eby]

At 01:52 PM 8/6/02 +0200, Ulrich Eck wrote:

>>Nope; just exploring the territory at this point.  I'd like to have fewer
>>objects to manage than JMS does to accomplish these things, but it's not
>>yet clear if we will.
>
>like you mentioned in your mail, specifying interfaces would help to start 
>working
>on these issues ...

Yep.  Don't know if I have the bandwidth to do anything in depth on it at 
the moment; a lot of times I just write up these requirements or design 
notes to have a semi-permanent record of my thoughts at the time.  That was 
definitely the case for peak.messaging, which isn't targeted for as near a 
term of implementation as say, persistence and database interfaces are.


>>One thought that has occurred to me, is that it may be better to
>>implement a transactional, Linda-style tuplespace (or Jini-style
>>"JavaSpace") API instead of a messaging API as such.  Everything I've
>>laid out as requirements can be cleanly accomplished within that concept,
>>and our existing implementations of filesystem-and SQL-based queues could
>>be extended to such an API in a straightforward manner.  But the model
>>allows for much more powerful distributed/multi-process algorithms than a
>>pure "messaging" model does.
>
>I just had a look at the JavaSpaces Docs and find it an interesting 
>alternative
>to our Messaging Model.
>
>Due to it's "simple" nature it could be implemented in python very well.
>(Thinking of ZODB + Pyro + Interfaces +
>Logic for locking, searching and notification... for a prototype)
>
>What do you think needs to be done, to be able to specify a global 
>structure and
>interfaces to implement such a _____Space with python and peak ??

Well, as with JNDI, I'd probably look at the Java API docs, and try to 
figure out what parts could be taken out.  In the case of JavaSpaces I 
don't think there's a lot to take out.  JavaSpaces was built "up" from the 
Linda concept, and is not really a J2EE API; technically it's in the "Jini" 
sphere of technologies.

JavaSpaces basically just adds objects and transactions to Gelernter's 
"Linda" language.  My thought is that adding this to PEAK would probably be 
done by a specialized interface available on Racks to "put" or "take" 
objects.  Or perhaps they should be called "Spaces" in that event.  The 
actual internal implementation would likely be just adding a lock manager 
and local queue for transient objects, to an existing PEAK persistence 
mapping to a DB or something else.

Of course, this implies that the PEAK persistence machinery needs to exist, 
first.  :)  So I'm not going to put a lot of effort into designing, at this 
stage, what the "spaces" extensions would look like, since it's likely to 
change as the persistence and transaction API's evolve.