[TransWarp] Requirements for the future peak.messaging
Phillip J. Eby
pje at telecommunity.com
Fri Oct 4 14:31:21 EDT 2002
At 07:55 PM 10/4/02 +0200, Ulrich Eck wrote:
>>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
>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..
Yeah, that's definitely ORB-ish. I'm not a big believer in N-tier
distribution when inter-tier communication isn't asynchronous, with the
exception of database access or other specialized services. The thing is,
synchronous services really are more complex to engineer - or at least to
do them well. I'd rather "outsource" this sort of thing to specialists (of
the human variety).
>It's sufficient to have SpaceRacks that support
>realtime-messages when objects are added.
Um, really, the whole SpaceRack concept is oriented towards asynchronous
messaging and co-ordination, not synchronous communication. I don't think
it's what you want. For N-tier, you want an ORB; use a "real" ORB and thus
"outsource" its more complex engineering to someone else. :) Or base the
communication front-ends on Twisted or Pyro and just call PEAK objects on
the back-end. PEAK isn't going to try to be an ORB or even define ORB
interfaces; the ORBish things Ty or I need are adequately served by XML-RPC
via a Zope server, or some other ORB-like protocol-based front-end.
More information about the PEAK