This semester, I'm teaching a class at BYU, CS462. We're using Opher Etzion and Peter Niblett's book Event Processing in Action as the class text. The text uses a flower shop and delivery driver scenario as the running example throughout the book. Here's a description:

The flower stores in a large city have established an agreement with local independent van drivers to deliver flowers from the city's flower stores to their destinations. When a store gets a flower delivery order, it creates a request, which is broadcasted to relevant drivers within a certain distance from the store, with the time for pick up (typically now) and the required delivery time if it is an urgent delivery. A driver is then assigned and the customer is notified that a delivery has been scheduled. The driver picks up the delivery and delivers it, and then person receiving the flowers confirms the delivery time by signing for it on the driver's mobile device. The system maintains a ranking of each individual driver based on his or her ability to deliver flowers on time. Each store has a profile that can include a constraint on the ranking of its drivers, for example a store can require its driver to have a ranking greater than 10. the profile also indicates whether the store wants the system to assign drivers automatically, or whether it wants to receive several applications and then make its own choice.

The following diagram (from the Event Processing Technical Society's site) illustrates the interactions that take place between various entities:

The example that Opher details in the book has been implemented in several event processing systems.

If you follow my blog, you'll know I have a particular view of evented systems based on distributed event processing taking place on event networks that are owned and run on behalf of particular entities. We call these personal event networks. In addition to writing a book on the subject, I've described personal event networks in various articles on this blog over the last six months:

• Foursquare and Personal Data in a Personal Event Network
• Notifications in Personal Event Networks
• A Web of Things on the Internet of Things
• Products as Avatars for a Service
• Sky: The New Kynetx Event API
• The Second PC Revolution: Personal Clouds
• Human Leverage
• Personal Event Networks, Social Products, and Value
• What Personal Event Networks Do
• The Evented API Specification
• Personal Event Networks: Building the Internet of Things
• A Facebook of Things
• Curation in the Small: Personal Event Networks and Getting Things Done
• The Trends Driving KRL and Kynetx
• Anonymous eCommerce: Building a Real 4th Party Offer Application with Kynetx
• Contextually Correlating Events: The Power of Emergent Behavior in Loosely Coupled Systems

N.B. If you're in my CS462 class, it wouldn't hurt to read them all. :)

Consequently, as we implement the flowershop example in my class, we're going to do it with a personal event network twist. The result looks something like this diagram:

In the preceding diagram, there isn't one event system that manages the interactions between the shops and the drivers. Rather, each driver has their own personal event network, each shop has their own personal event network, and the guild has one too. The interactions aren't simply events raised within a single event network, but rather events raised between the networks of each participant. I've shown some of the apps that drivers, shops, and the guilds have installed on their personal event networks, but they would each be individually managed and configured. In fact, it's reasonable to assume that different drivers or shops might use different apps for the same purpose as long as they understood the events.

The various personal event networks are linked together via event subscription. For example, a driver might subscribe to the delivery_ready event from each of the flowershops she wants to drive for. A driver who has a bad experience with a particular shop, merely unsubscribes from that shop's delivery_ready events and never sees them again. Similarly, a shop that doesn't like a particular driver can merely unsubscribe from them and no longer do business with them. I'll be posting an example soon that shows how event subscription works in a personal event network. There are lots of details to work out and this blog post isn't the place for them.

There are design choices to be made in this system. For example, there's a "direct" arrow in the diagram indicating that shop and driver personal event networks can communicate directly. But the guild may chose to intermediate the interactions. In class, we're going to be implementing the system with a direct connection first and then re-plumb the entire thing to use the guild as an intermediary. Intermediaries introduce interesting dynamics, making many things easier and increasing flexibility.

Overall, this example isn't terribly different from the fourth-party ecommerce example I wrote about last June except that example featured hardwired connections between the shopper and the merchant rulesets. In contrast, this example uses the idea of event subscription to link merchants and customers. Event subscription takes the fourth-party example from a nice little demonstration to a conception of how VRM could work in the real-world. The diagram shown above can be partitioned to illustrate this:

Together with our ideas about how notification occurs and how personal data can be managed in personal event networks, event subscription creates a powerful system for enabling a completely new kind of interaction between vendors and customers (note that in this example, the flowershop is the customer who is negotiating for and buying delivery services from the drivers).