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, 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
RSS Feed