From: Jeff Bone (jbone@jump.net)
Date: Mon Aug 21 2000 - 11:12:42 PDT
Random thought-walk prompted by various threads.
I've pounded on the IDL->XML mapping issue numerous times in various forums with
limited traction, mostly I assume because of the large cultural discontinuity
between those two worlds. Still, I really believe it's an important issue. With
a standard way of doing that, standard RPC semantics and transport, and an
interface query capability we'd have a huge technological capability that would
be both (a) quite simple and (b) quite powerful. I call the result XORBA, the
XML Object Request Broker Architecture.
But communicating components ala CORBA is only a first step. There's a whole
class of loosely-coupled (in terms of space, time, and interfaces) distributed
apps that need a higher-level set of abstractions. Being a long-term Linda fan,
I'm a huge advocate of "generative communications." A simple set of abstractions
/ operations over XORBA gets you a long way: a notion of a named "communication
space," i.e a web page with simple operations for inserting, associatively
querying / reading, and removing XML objects from said space plus a few ancillary
operations related to leasing and parameterizable semantics on a per-space basis,
and voila you've got something really interesting. Let's call it XELDA, the XML
Extensible Linda-like Distribution Architecture. Move over Jini / Javaspaces,
here's the real deal.
Furthermore, you could take a few cues from Plan 9's "plumbing" architecture and
use triggers on insert to semantically rewrite incoming objects / queries based
on their content; this gives you a further level of language-driven configurable
decoupling that abstracts away from peer A having to know peer B's particular
message format in order to communicate.
One of the big problems -w- Linda is that, as a simplifying assumption, it
imposes a particular set of semantics on tuple spaces. To wit, tuples are
retained indefinitely until explicitly removed; there is no partial order
imposed on tuple matching based on time of insert; and objects that can identify
a tuple are free to remove it, potentially forever. These three things conspire
to create distributed garbage and unreliable ordered communication patterns over
time. Systems like Cogent Research's Linda-based UNIX-like OS back in the late
80s imposed ordered communication to great effect; systems like Javaspaces deal
with the distributed garbage problem via Leasing. My contention is that, in
order to insure flexibility, these semantic "option sets" should be determined,
standardized, and made configurable on a per-space basis.
One option that I've never seen implemented but which is particularly useful in
the context of presence is something I call "antileasing." It's long been my
contention that presence is most easily thought of as a generative system, where
clients asserting presence are in essence inserting tuples into a tuplespace.
Leasing takes care of the problem of (eventually) de-asserting presence when a
client fails or goes offline; but the problem remains that you need some simple
semantic mechanism for ensuring that nobody else can de-assert presence by
removing your tuple from the space. Rather than create some totally gnarly
security system, "antileasing" takes care of this. An antilease is something
that is specified by the client on insertion of a tuple into a space; it says,
basically, "nobody but me is allowed to remove this tuple from the space for
longer than X." If someone *does* remove the tuple for longer than X, the system
itself re-inserts the removed tuple after the antilease expires. With something
like that, you basically have all the semantics you need to do buddy lists and
instant messaging w/o some gnarly app-specific state machine and protocol.
Just some random thoughts, $0.02,
jb
This archive was generated by hypermail 2b29 : Mon Aug 21 2000 - 11:16:48 PDT