[TransWarp] Requirements for the future peak.messaging package

[Ulrich Eck]

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 ..
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 ??

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

  We will need the storage module working at least with ldap.
  We will use Pyro for DistributedObject-Access and want to
  integrate pyro-nameserver with peak.naming.


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

 - 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.


>
> 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 ??

For the Implementation there are 3 different solutions at this time:

 - use DistributedObject system (Pyro, Fnorb [soap,xmlrpc], ...)
   Need to write a ServerImplementation and Clients

 - use existing Messaging-Implementation (jabber, spread, [MQ-Series], ...)
   need serialization-method that can be transported through
   the messaging server (for jabber one could use xmlpickle for example)
   need to write the Client-Wrapper

 - you talked about a file-based system that you have ..


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.

Will we end up with JMS-Api ??
Do we need to support both: Point-To-Point and Publish/Subscribe Messaging ?
What's about Threading / synchronous access/delivery?


> 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.

How stable is the persistence/transaction api ??
Have you tried it with ZODB4? .. i have not yet completly understood
how peak.storage integrates with ZODB4.


Ulrich Eck
------------------------------------------------------------------------
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
fon:   +49-8121-4747-11
fax:   +49-8121-4747-77
email: ueck at net-labs.de
http://www.net-labs.de