This blog post sets forth several important naming conventions for personal event networks:

1. EXP or the Event Exchange Protocol is the name of the event protocol that enables and gives rise to personal event networks. The Sky Event specification defines the current version of EXP (sky is a version identifier, the previous version was blue).
2. The cloud-based service that runs KRL rulesets that respond to events formatted using EXP is called the EXP Service.
3. An EXP Service is provided by a Kinetic Rules Engine. While we might properly refer to this as an EXP server, KRE is prefered for historical reasons. The service comprises not only a way to execute rules, but also an identity system with the means of associating rulesets, data, and event channels with a given entity.

The following discussion motivates and explains the preceding statements.

Protocols

The Internet is a creature born of protocol. Protocols are agreements among a set of parties on a sequence of operations and the format of messages that will be used to communicate for a given purpose. For example, SMTP, Simple Mail Transport Protocol is the protocol that enables email servers to exchange email messages with one another.

Distributed systems depend on protocols to function. In Protocol (PDF), Andrew Galloway says "protocols are the enemy of bureaucracy, of rigid hierarchy, and of centralization." Protocols enable ways to overpower and supplant places.

Protocols have both syntactic and semantic elements. For example, there is a specific form or syntax that the SMTP protocol prescribes for indicating the recipient of the message. The fact that it indicates the message recipient is the semantics of that particular field.

Internet protocols usually rely on other protocols. For example, actually doing email involves not just SMTP, defining how to exchange email messages, but also other protocols like DNS for name resolution, IMAP or POP for mailbox management, and MIME for specifying message content. Then there's the "envelop" protocol. For example, SMTP doesn't talk about transport, that's TCP/IP's job. TCP/IP is, for SMTP, and envelop protocol.

In my most recent post on Ways Not Places, I talked about a hypothetical e-commerce protocol:

What if there were a protocol for e-commerce? What might happen? Let me paint a picture. A few months ago, I had six spare gorilla racks that I needed to unload. I went to a place--KSL Classified--and created a listing. Then their system took over and handled the interactions in some private, known-only-to-the-developer method completely within their site. Anyone who wanted to see if there were Gorilla Racks for sale had to go to their site. #FAIL

If there were a protocol for e-commerce, I could have merely listed the racks as unwanted in the inventory system on my personal cloud (stick with me here--protocols require different infrastructure than places). People looking for racks would broadcast their intent to purchase them. The protocol would connect anyone interested in buying storage racks to me and my cloud, allowing for much of the interaction to happen automatically. All in a distributed, decentralized manner. Where'd I get this cloud? From a cloud vendor who sells clouds that understand e-commerce, messaging, to-do, and other protocols, of course.

From Phil Windley's Technometria
Referenced Mon Mar 19 2012 13:41:49 GMT-0600 (MDT)

This leads to some interesting questions like: "Where would such a protocol come from?", "How would it work?", and "How would it be adopted?" In this blog post, I'd like to paint a picture of how I see such a world unfolding.

Protocols vs APIs

Some people are rather militant about properly distinguishing APIs from protocols. I've gotten comments from people that say things like "that's a protocol, not an API!" Lately it's become fashionable to call any thing with a REST interface an "API"--even when they're more properly protocols. I think some of this is simple confusion, but it's also an attempt to make things sound easier. No company wants programmers to think their system is hard to use and protocols sound hard.

What's more, some Web APIs are pretty straightforward request-response systems where protocol sounds overly ambitious. For those interfaces, API is probably the right word. But other so-called APIs are really protocols. People have started to refer to these as "push" APIs. Twilio's API, for example is a full blown protocol as it clearly defines an agreement on sequences of operations and formats for messages with the goal of accomplishing telephony tasks using the Twilio system. Modulo intellectual property issues, one could imagine another online PBX adopting the Twilio API as a standard.

One of my goals is to get more Web APIs to send events--to become more properly protocols instead of mere request-response based APIs. My motivation is systems that are more loosely coupled and better able to act as peers in orchestrated Web interactions. Sam Curren and I have developed the Evented API specification to come up with a standard way of adding events to APIs, making them more properly protocols.

Metaprotocols

Programmers reverence protocols. We think of protocols as something given to us from on high by the Cerfs, Postels, and Berners-Lees of the world. But the truth is that programmers build protocols all the time. Sometimes these are ad hoc and other times they are built with the help of a metaprotocol.

A metaprotocol is a protocol for building or describing other protocols. You're undoubtedly familiar with some metaprotocols even if you haven't thought of them that way before. SOAP, RMI, CORBA, and JSON are all examples of metaprotocols. We often use words like framework, IDL, specification, or even just format when we're talking about metaprotocols. The page from Caucho Technology on metaprotocol taxonomy does a pretty good job of classifying various metaprotocols.

RMI, for example is a metaprotocol that defines the syntax of interactions between classes. RMI specifications are given by the Java class definition using reflection. Whenever someone uses RMI to specify the interactions between Java classes, they're defining a machine-readable protocol.

The Evented API specification also defines a metaprotocol. Events are transported over HTTP and the specification defines a format (i.e. syntax) for how events can be encoded.

Using the Evented API specification, however, requires that a developer further define the events that will be raised. By defining the event domain and type as well as the required and optional attributes for each event type, the developer creates a protocol for sending notifications. We'll see example of this below.

EXP, KRL, and Protocols

Moving beyond the general Evented API specification, we get to EXP and how it and the Kinetic Rule Language (KRL) gives rise to personal event networks. KRL is designed to build systems that support EXP.

EXP, currently defined by the Sky Event specification, is a metaprotocol. We get a protocol by defining two things:

1. Certain variables in the event signal must be defined: notably, the event domain and type along with any event attributes.
2. The return value must be specified. The return value may be empty. Usually, the preferred form is a JSON data structure, but the system is flexible enough to return other types as well.

You might think of these actions as instantiating the EXP metaprotocol to define specific protocol instance.

Any given KRL ruleset responds to a specific instance of EXP, not EXP itself. Because of the event expressions in select statements, we can calculate the specific events to which a given ruleset responds. This is called salience data. This is similar to the way that RMI uses Java classes to determine the specification for the object method interactions to which a particular Java class will respond. Similarly, we can calculate the potential return results--the directives--that a given ruleset can return.

Sometimes, events are raised by another ruleset, but often they are raised by what we refer to as "endpoints." An endpoint in the Kinetic Event Architecture is an event generator. This might be something as complicated as a browser extension or as simple as an Arduino making an HTTP POST. We've built browser extensions, mobile applications, email gateways, telephony gateways, IRC bots, and network proxies that function as endpoints.

An endpoint or ruleset that raises events in a personal event network is wasting it's time and network bandwidth unless there is an installed ruleset that understands the event protocol that the endpoint uses. That is determined by the event expressions in each rule. Further, the endpoint must be written to understand the directives that any selected rules return. Thus rulesets define a protocol to which the endpoint must adhere.

Events in EXP are Personal

The Sky event specification requires that events be raised to a specific event channel. Each event channel is associated with an entity--usually a person, but it could be anything that is uniquely identifiable.

When events are raised on a specific channel, the associated entity is calculated along with a list of rulesets that the entity has installed. The salience data for the installed rulesets is used to determine which rules should be evaluated.

Consequently, when any event is raised to the EXP service, the response depends on who the event is raised for and what rulesets they have chosen to install. EXP thus gives rise to personal event networks.

Why a Network?

I use the term network in describing personal event networks because the system I've described above gives rise to a network of event processors, the rulesets, under the control of an entity that raise events to each other as well as seeing events from endpoints (event generators) that the owner of the network has configured. (Note: only endpoints that have an event channel identifier can raise events into a personal event network.)

We have further previously shown ways that event networks can raise events to each other giving rise to federations of personal event networks. These federations animate interactions such as those that support flower deliveries or on-call teaching assistants.

This does not imply that the EXP Service itself is networked. In fact, it needn't be. Any number of independent EXP Services could be set up, each servicing one or more entities. These services wouldn't necessarily know about each other, although the personal event networks operating on them might. You and I might federate rulesets in our personal event networks without caring whether our personal event networks were operating on the same or different instances of KRE.

Wither the E-commerce Protocol?

Finally, we're ready to talk about the hypothetical e-commerce protocol I mention at the first of this post. As you've probably surmised by now, EXP is not an e-commerce protocol. Rather an e-commerce protocol could be defined in EXP using it's powers as a metaprotocol.

Right now, there's one, simple example of a event-based protocol defined in EXP, the Notification Event Protocol. This specification is far from finished, but it's been very helpful fleshing out the ideas in this post. I describe this protocol and the simple ruleset I built to process it in a blog post: Notifications in Personal Event Networks. Note that the notification specification does not, at present, specify any return value.

The flower delivery system students in my CS462 class are building defines a protocol for linking delivery drivers and vendors who need deliveries made. You can see the details in the lab descriptions if you're interested. One interesting note: return results aren't used. Rather event networks communicate with each other strictly through events as described in the lab.

Similarly, an e-commerce protocol would need to be defined in EXP. There might be multiple event domains, certainly many event types, and the attribute design would be critical. Return results might not be as important depending on how the interaction is meant to play out.

How would such a protocol gain adoption? In the usual ways: by convention, by standardization, or both. Certainly Amazon has enough weight that if they started supporting an e-commerce protocol, the rest of the market would probably accept it as convention. Even better if they or someone like them lent their support to the design and standardization of such a thing. But large merchants may not see such a protocol as being in their best interest. For example, Ebay probably has little interest in seeing ways replace places.

Conclusion

I conclude with the lead:

1. EXP or the Event Exchange Protocol is the name of the event protocol that enables and gives rise to personal event networks.
2. The cloud-based service that runs KRL rulesets that respond to events formatted using EXP is called the EXP Service.
3. EXP Service is provided by a Kinetic Rules Engine.

Drummond Reed suggested the name Event eXchange Protocol (EXP). He, along with Doc Searls, Craig Burton, Steve Fulling, Sam Curren, Ed Orcutt, and Mark Horstmieir contributed to the discussion upon which this post is based.