[TransWarp] Requirements for the future peak.messaging package

[Phillip J. Eby]

At 05:52 PM 10/4/02 +0200, Ulrich Eck wrote:
>Hi Phillip,
>
>we are about to start refactoring our app to use peak
>instead of transwarp. as far as i cann see, you're
>close to a release-candidate with peak now ..

Somewhat.  The 0.5 release series will be when binding, naming, and config 
are both API-stable and documented in the tutorial.  That could be as much 
as 1-2 months away, however.


>the storage-module looks promising as well.
>
>- Do you have some sample code / interpreter session that
>  demonstrates the basic usage of your new storage-api ??

Only what you saw in the recent commit message.  For testing, I used a 
connection class that looked like this:

class MyConnection(storage.ManagedConnection):

     def _open(self):
         return gadfly.gadfly('test','/tmp')

So, rolling your own connector isn't difficult.  Similarly, for LDAP if you 
have _open() return an LDAP connection object, it should work (but I 
haven't tested it yet).  The LDAP stuff doesn't offer any methods besides 
search currently, though.  It wouldn't take much to add it to the cursor 
class, I don't think, I just haven't got around to it yet.

Please note that I haven't finished integrating transactions and managed 
connections.  SQL managed connections, for example, don't yet call 
db.commit()/db.rollback(), or issue a "begin tran" during the joinTxn() 
message.  You should add code to do this in your subclass if you want your 
connection to be properly transacted.

Also, please note that I haven't written any unit tests for anything in the 
storage subpackage; I've tested a lot of things by hand just for 
proof-of-concept, but I wouldn't feel comfortable yet that the transaction 
class, for example, works perfectly.  And I haven't tried Racks yet at all, 
I need to get ZODB4 persistence integrated before they'll be able to do much.


>- Do you think, that it is a good time to start migration to peak now ?

It depends.  I'm about to do some overhauling work in the naming and config 
packages, to allow for configuration "properties", and adapting the naming 
system's schema registry mechanisms to use those properties.  I don't know 
yet how much it will impact code that implements a naming service, but I 
don't expect much impact to *using* naming services.  Given that, and the 
incomplete nature of the storage package, I don't know that there's enough 
there for you yet.


>One major Design Issue now is the Messaging System.
>
>I've read through JMS and JavaSpaces API-Docs. As you mentioned
>earlier, Java-like-Spaces would solve most problems, but to implement
>them in a sensefull way, Messaging (at least Point-To-Point-Messaging)
>is needed.
>
>I made a simple prototype with Pyro and ZODB3 without any usage of
>peak/transwarp, just to explore the Spaces-World.
>
>These are my thoughts on building a JavaSpaces-like api/impl for peak:
>(our projects requirements ..)
>
>- Good (Realtime)Message System is needed
>   It makes no sense to poll Spaces

This is somewhat in conflict with our design goals for PEAK; we don't 
really intend to do this sort of realtime-oriented messaging, and I don't 
really have any plans to create a specific API for it in PEAK.  I consider 
it a "nice to have" at best.  The reason is that for immediate messaging, 
XML-RPC or other web service APIs are usually sufficient, unless you have a 
complex multi-way interaction.  But if you have such a complex interaction, 
it usually needs transactionality or persistence of some kind in order to 
avoid messing anything up.  At that point, it makes sense to use a "Space" 
to manage the interaction.

But, nothing says you can't implement a "Space" that is based on something 
like Spread or Pyro, to create a distributed space or a messaging 
server.  And "polling" is relative, if you're using something like Twisted 
or asyncore to manage communications.  Also, queue-based messaging offers 
many performance and scalability benefits that "realtime" messaging doesn't.



>- Entries are serialized objects with Metadata (interfaces, properties)
>   Serialization could be done with pickle/xmlpickle/xml.marshal
>
>- Templates for Entry-Queries match on:
>     1. Interface (w/Inheritance)
>     2. key/value pairs of known properties
>        (I used kjDicts for that in my prototype)
>
>- Security is important but not needed in the first place.
>   This can be done through transport-security now.
>
>- The JavaSpaces-Api is clean and short .. and could be used.
>
>
>So .. we need messaging first.
>
>We need to specify a common api for peak that fits most needs ..
>The JMS-Api is very loaded, but flexible in many ways. Right now
>I start with this api and try to simply it as far as possible,
>without loosing many of the neat features.

I'd like to stick with a Spaces-oriented approach.  My thought is that we 
will have SpaceRacks, which add a few extra public methods: put, take, 
query, or something like that.  SpaceRacks will have the same back-end 
implementation methods as regular Racks, with the addition of a "lock 
manager".  The job of the lock manager is to co-ordinate between front ends 
about the contents of the back end.  The back end can be any persistence 
mechanism accessible by the racks, e.g. SQL, LDAP, filesystem, shared 
memory, whatever.  So it's transacted by the usual means.  The lock manager 
is just used to "lock" objects that are "taken" or "put" during a 
transaction, until the transaction commits.  When locks are "released", 
other processes can then "see" the objects that have been added to or 
removed from the space.

I've written a prototype lock manager using Spread that could be used for 
this purpose.  Theoretically, it could also be re-written to exchange the 
actual pickled data, not just locks.  The basic algorithms wouldn't change 
much.  Anyway, the "point-to-point" messaging in that case would be by 
simply using groups of only two participants.

So you see, I'm not really sure there's going to *be* a peak.messaging 
package, as such.  There just might be some communications tools for 
peak.storage.  For the kinds of application messaging Ty and I have to deal 
with, we'd much rather have our message queues backed by an SQL server or 
the file system, than flitting around over TCP/IP with no transactional or 
persistent backing.  And we don't want to have to write complex 
transactional protocol handlers of our own, either!


>>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.
>
>Will you be able to work on the Requirements in detail and the Interface
>for peak.messaging in near future ??

Realistically?  No.  :(  But you don't have to have an API from me to 
extend Racks with communication functionality, or to use another messaging 
system in conjunction with PEAK.


>For the Implementation there are 3 different solutions at this time:
>
>...
>
>It would be nice if we find an api for messaging that could be
>used for all of the above implementations without the need of change.

I do believe that it's possible, using the SpaceRacks idea I described 
above, to have a common API over all back-end implementations.  I'm not 
sure it's suitable to your purposes, however, which I'm not entirely clear 
on.  What are you actually trying to *send* in these messages?  Could you 
describe that part for me?  If you're doing ORB-like things, I don't think 
what I'm describing is suitable, and you shouldn't even try to align what 
you're doing with PEAK concepts of co-ordination and messaging.


>How stable is the persistence/transaction api ??

It has no unit tests yet.  You be the judge.  :)


>Have you tried it with ZODB4? .. i have not yet completly understood
>how peak.storage integrates with ZODB4.

It doesn't integrate much.  I just plan to use the cPersistence 
implementation as a base class for persistent objects.  I've dropped ZODB4 
transaction integration as a YAGNI for now, as my proof of concept showed 
that it's possible in principle to "dumb down" the PEAK transaction 
messages to the subset that ZODB4 can understand.  But I don't actually 
*need* that integration.