[TransWarp] Requirements for the future peak.messaging package

[Ulrich Eck]

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

It'll take us at least two month to get to the storage details when
whe start refactoring NLL .. we'll see


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


Our application consists of several distributed components (storage-manager,
workflowservice, utilities, gui) that need to play nicely together in
realtime (most important for the later planed GUI implementation)

If you want .. it's ORB-like.. It's sufficient to have SpaceRacks that 
support
realtime-messages when objects are added.

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

Ok .. what about:

SpaceRacks get an optional Interface for
notification, which is quite simple (e.g. subscribe/unsubscribe, onMessage)
and provide hooks to support the message-generation when a new Item
is added.

i will evaluate the possibilties to realtime-messaging within our
own project.


cheers

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