Re: Regarding AMQP Messaging paradigm and pattern in E-Lang

>
> In Capability based systems (OCAP), the management of capability is through
> explicit exchange of reference - the Granovetter diagram. This defines a
> point-to-point interaction model. In the world of messaging, this
> point-to-point seems to be one case of the possible many. Further, it is now
> becoming important that the messages are delivered not on a destination
> specification but on a pattern based specification of the destination. This
> allows for time independence of message creation and delivery.
>

In my dissertation<http://soft.vub.ac.be/~tvcutsem/publications/assets/phd_tom_van_cutsem.pdf>,
I explored exactly this relationship between object-oriented programming
versus publish/subscribe-style interaction (cf. sections 3.4 and 7.2). I
refer to the relevant differences between the two styles as the
"object-event impedance mismatch". To overcome this impedance mismatch, I
proposed "ambient references": object references that can designate an
abstract set of objects, and that support both point-to-point and
one-to-many messaging with objects in this set. Ambient references were
developed not in E, but in AmbientTalk (a language largely influenced by E,
employing essentially the same event loop concurrency model).

I didn't solve the security issues, however. In section 4.7 I explicitly
describe AmbientTalk's shortcomings w.r.t. security, in particular w.r.t.
it's service discovery mechanism (cf. p90). Because AmbientTalk was designed
for ad hoc networks (networks without infrastructure), we could not rely
upon a third party to act as an introducer between mutually suspicious
distributed objects. Essentially, objects discover each other directly via
an interface type, but any object has the ability to define or refer to such
interfaces. Hence, once an object allows itself to be discovered through
service discovery, any object can discover it.

Perhaps in a more traditional distributed system, where one can rely upon a
trusted third party to act as an introducer, one can do a better job. I'm
going to sketch a rough example of what I'm thinking about,
comments/improvements are welcomed. Say the introducer defines the following
'channel' abstraction:

def [ publisher, subscriber ] := makeChannel();

The publisher can be used to publish services:
publisher<-publish(myservice);

and the subscriber used to discover services:
subscriber<-subscribe(callback);

with the understanding that publishing a service through a publisher
notifies the callbacks registered through the corresponding subscriber.

The introducer can now hand out the publisher and subscriber 'facet' of this
channel to different parties, who can now perform 'anonymous'
publish/subscribe interactions. According to OCAP rules, only objects that
were explicitly passed the corresponding publisher and subscriber facets can
use the channel. However, the amount of trust that each participant can put
in objects passed through the channel seems inherently limited to the amount
of trust they can place in the introducer: it is this party that has full
control over who gets to talk on the channel, by delegating the
publisher/subscriber facets in an appropriate way.

Cheers,
Tom

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang