Patterns of cooperation without vulnerability

Collaxa's Edwin Khodabakchian (whom I have interviewed -- small world -- for an InfoWorld story on web services orchestration) is writing a blog that's a nice example (along with Ray Ozzie's ) of how a tech exec can use this medium to project a persona, clarify a mission, and float ideas that may provoke useful reactions.

The path that led to my discovery of Edwin's blog (which needs an RSS feed, by the way) is typical of the serendipity and triangulation that pervade the blogosphere. I subscribe to Loosely Coupled , which today cites a great article by Adam Bosworth arguing for coarsely-granular web services that do not correspond to programming-language objects. I'd seen that article in June when it first appeared, but clicked through to Loosely Coupled anyway in case this was a sequel I hadn't seen yet, and that's how I found Edwin's blog.

Edwin today notes similarities between the E language and Collaxa's ScenarioBeans. That reminded me (in a James Burke kind of way) of a conversation with Paul Prescod about E's capability-based security :

E has no pointer arithmetic. E has no mutable statics. E has an API carefully thought out to prevent capability leaks. This would make it a capability secure language for single-processor applications. But E goes a step further. It takes the concept of a secure, unforgeable object reference and extends it to distributed objects:

- The communication links are encrypted. Third parties cannot get inside the connection.

- The objects are unfindable without a proper reference received (directly or indirectly) from the creator of the object. You must have the key to unlock the door.

- The objects are authenticated. No object can pretend to be the object you are trying to contact.


Java introduced the concept of a sandbox for its applets. The sandbox is a space in which no access to dangerous powers is available. To give greater flexibility they introduced the security manager and the ID badge architecture--if the user concludes the applet came from a "trusted source", the applet can get your ID badge and roam wantonly through your system.

A java application that runs in a sandbox is called an applet. An E emaker that embodies a full program is called a caplet. Caplets are not trapped in sandboxes. Instead, you may think of caplets as being trapped in safety deposit vaults. The caplet is started inside the vault, surrounded by hundreds of safety deposit boxes--but not one of the boxes is accessible unless and until you give the caplet a key to that particular box.


In the end, one may say that normal object programming is about patterns of computation and abstraction, whereas programming in E is about patterns of cooperation without vulnerability.

What an evocative phrase! "Patterns of cooperation without vulnerability." Selective disclosure is an aspect of it: we want to be able to identify ourselves in limited ways for specific purposes. Blogs are another aspect of it: we cooperate in this medium at a respectful distance, by mutual consent.

Former URL: