This is a guest blog post by Dave McNamee

The Eventernet is an event architecture overlayed on the Internet, where events are published and applications process those events and take action on behalf of people. This allows for the creation of new value that was not possible under the constraints of the request architecture of the WWW.

The World Wide Web

In the beginning there was HTTP with its collection of methods. GET, POST, PUT, DELETE, etc. These methods, along with the advent of HTML (and browsers that could render HTML) allowed the World Wide Web to emerge and flourish. Suddenly the big-I Internet had a mainstream purpose.

GET and POST are the methods that get the most exercise. Billions of people are using browsers as an interface to GET documents from web servers. Of course, in the fifteen years since the explosion of the WWW, the content of those documents has become more dynamic and sophisticated, but the basic request method has remained the same, and the basic paradigm of requesting documents has not changed much until recently.

Some platforms (hegemonies?) have emerged which are attractive to developers for their functionality, user base, and comScore ratings. These platforms have extended their reach dramatically by publishing APIs. Now users are accessing functionality from these platforms through third-party interfaces rather than through requesting documents directly from the platform providers.

RESTful architectures make API consumption easier because of their fidelity to the methods of HTTP. The ascent of internet-enabled native applications on mobile platforms is adding fuel to the API fire. However, we are still stuck in a request architecture with its inherent limitations.

Why We Need the Eventernet

At this point I am reminded of a discussion that many married couples will recognize. It goes something like this:

Wife: "You didn't do X and I am angry."
Husband: "You never asked me to do X."
Wife: "I shouldn't always have to ask you to do X. You should just know."
Husband: "How am I supposed to know that you want me to do X if you don't ask me?"
Wife: "If you paid attention you would know that X needs to be done."
Husband: "Hmmph, grumble."

The hapless husband in this story is operating under the assumptions of an request architecture. He assumes that if the wife wants something done, she will request it. Unfortunately for him, in this scenario the wife is operating under the assumptions of an event architecture. She expects that the husband will observe events around him, put them into context, and synthesize them into the expected action. Life would be better for both of them if he were better at processing events!

Just like in my example, there are many events that occur in the world that, if synthesized into a desired action, would create great value to individuals and companies alike. Intrepid developers are beginning to use webhooks to message explicit events for processing by an external application, but these systems are still a closed loop: the events published are predetermined and intended for a specific application. It is impossible for the published events to be synthesized by some other system into a valuable output.

The Eventernet

Enter the Eventernet. Eventernet is a term I made up in an effort to describe this architecture. The Eventernet is comprised of a few key components: event publishers, event hubs, event processors, and client applications.

The Eventernet is built on top of HTTP and makes use of the standard methods, however, instead of GETting documents, an event publisher uses GET or POST to publish an event to an event hub (or directly to an event processor). Event processors subscribe to those events in a manner similar to Pubsubhubub and process them in a rules engine to determine the action that should be taken on behalf of individuals or other entities. The event processor transmits instructions, called directives, to client applications that benefit the individual or entity. In some cases, the event publisher may also be the intermediary between the event processor and the client application, managing both up and down communications.

There are different flavors of event publishers. Some are publicly available and are already published through APIs, such as the public tweet stream or stock market values. Others will be directly connected with individuals and are controlled by them, such as cell phone GPS data or expressed interests. Some people believe that Personal Data Exchanges will serve as the event clearinghouse for individuals. Whatever the architecture for publishing the events or data, the fact remains that they are useless unless they are processed in a way that generates value for all involved.

Kynetx and the Eventernet

The Kynetx platform includes elements of this architecture. We have event publishers, the world's only platform-agnostic event processing engine, event hubs, and client applications. We are also developing rudimentary personal data storage functionality as we await the emergence of a complete Personal Data Exchange architecture.

I believe that entirely new industries and value networks will be built upon this architecture. The world will not soon abandon the traditional request architecture of the web, but to evolve we must augment it with an event architecture.