My G+ Profile
« September 2011 | Main | November 2011 »
October 31, 2011
A Database is Like a Phone that Doesn't Ring
I love this video of Vivek Ranadiv, CEO of Tibco because he does such a great job explaining why events matter:
Here's the quote I love best:
"They [IBM] use a data base and it's like a phone that doesn't ring. If something happens, it goes into the data base, but nobody else knows that something just happened. You have to keep asking questions. You have to find the information. With Tibco, the information finds you. The phone rings. Huge difference. It's all about innovation and it's all about knowing your customer."
A phone that doesn't ring is a great image. That's what most APIs are like. With most APIs being deployed today, you have to go ask the question. For some things that's fine, but not for real-time or near real-time data. We developed the Evented API spec so the phones could start ringing.
10:34 AM | Comments () | Recommend This | Print This
October 26, 2011
Semantic Translation in Event Systems
![[]](http://farm2.static.flickr.com/1184/730430624_8b483cf1e4_m.jpg "[]")
The title to this post probably makes it sound much more grandiose than it is. Still there's an important kernel here I don't want to lose, so I'll write it in my exocortex.
Suppose I've got an evented expense report application that automatically enters information from my travel in an expense report. The app wants to know when I've arrived at my destination or when I've arrived home, so it can book those transactions.
The problem is that my smartphone isn't signalling an "arrived at SFO" event; it's sending a "location SFO" event. The idea of arriving is specific to the context of traveling from one airport to another. So, a "location SFO" event only equals an "arrived at SFO" event if I was known to have been on a plane. For example, my if travel itinerary shows that I was scheduled to be on a flight from SLC to SFO, it's a pretty good bet that I'm arriving at SFO, not departing or merely dropping someone off.
The expense report app needs to work in concert with a travel app that knows the context of what I'm doing and translates events like "location SFO" to "arriving SFO" when I've just gotten off a plane or to "departing SFO" when I'm scheduled to board a plane shortly. Here's how we might express this in KRL pseudocode:
rule arriving {
select when mobile location
pre {
airport_code = event:attr("airport");
//find line with this airport as destination
flight =
itinerary.pick("$..line[?(@.destination eq airport_code)]";
}
if(flight{"depart_time"} < time:now()) then noop();
fired {
raise event arriving with airport = airport_code
}
}
There's a few holes here. Production code would need to be more complicated in calculating if this event is really an arrival, taking into account things like arriving and departing on the same day, late flights, and so on. (Not to mention I've made the code easier to read by using < for time comparison.) Nevertheless, the idea of using a rule like this to perform semantic translation for events should be clear.
You might be curious about the noop() action in the rule. Rules used for event abstraction almost always have a null action since we want their effect (raising an event) not their action. If rules like this become commonplace, we may need to allow actionless rules in KRL.
This use of context to perform semantic translations of events is something I've only recently come to appreciate. I know it's not in the Live Web book anywhere. I'll have to see how to get it in there...
7:53 PM | Comments () | Recommend This | Print This
October 18, 2011
What Personal Event Networks Do
I put together a slideshow that gives our thinking on personal event networks and how they related to current trends around mobile and social.
11:09 AM | Comments () | Recommend This | Print This
October 17, 2011
Occupy Something
My friend, Jim Harper, has an excellent post on where the Tea Party and Occupy Wall Street crowds have common ground that is anchored by this Venn diagram from James Sinclair:
This is a perfect reflection of something I thought over the last few weeks: the Occupy Wall Street crowd have good intentions, but are looking to government to fix the problem. The Tea Party (at least the grass roots people I know) have good ideas about limited government, but often miss the corporate-government complex (often called "corporatism") that is the root of the issue.
To that end, I'd like to point the #OWS crowd and the Tea Party crowd at the "change Congress" movement--now called Root Strikers. I think that changing the system to reduce the corrupting influence of corporate money in politics and government is the route to salvation.
That said, I think the Root Strikers are prone to left leaning and class struggle terminology that will turn off the right-leaning people that could and should be their allies. Of course, the Tea Party is suffused with ultra-right dogma. But there is common ground. The issue is too big and important to let disagreements over other issues drive us apart.
12:37 PM | Comments () | Recommend This | Print This
October 10, 2011
App Pushers and Enforcers
Lately, I've noticed a phenomenon that is extremely unhealthy, not mention annoying: companies more or less forcing you to use their mobile app instead of their Web site. It's bad enough when they're just pushing them at you every time you visit their site, requiring an extra click to get past the "download our mobile app!" splash page. Some sites just give you a crappy, watered-down mobile experience with no way to get to the "real" site .
But what I'm thinking of is more insidious. When a company pays good money to create a mobile app they don't want to also pay for a mobile version of their site. Consequently, you're stuck with the Hobson's choice of downloading an app you're rarely use or trying to muddle through with a site that is hard to navigate on a mobile device.
The temptation to "have an app" is big. Having an app says you're hip. You've arrived. You get this whole mobile world! And better yet, the app pushers will tell you, your brand is now on the phone--24x7--where the user will see it every time they use their phone. And, of course, once you've invested money in an app, you don't want to pay money to fix your Web site too. So you throw up a splash screen pushing your app.
This Balkanization of the Web into apps is evil on many levels. Let's face it, no one wants a mobile app for every Web site they visit--or even those they visit occasionally. Consequently customers suffer from poor user experiences and businesses miss out on transactions by introducing friction.
The answer for most businesses is that they don't need an app. They need a good mobile version of their site. I don't know of a study that compares the business effectiveness of mobile apps vs. good mobile sites, but I'd like to see one. Unless, I'm completely missing something, I'd bet that a good mobile site is more effective in terms of driving real business.
10:13 AM | Comments () | Recommend This | Print This
October 5, 2011
The Evented API Specification
![[]](http://farm1.static.flickr.com/70/398522252_67b1f1d4cb_m.jpg "[]")
Over the last few weeks, I've been blogging a lot about the benefit of evented systems:
- On Hierarchies and Networks
- A Facebook of Things
- Personal Event Networks: Building the Internet of Things
The underlying message of each of these articles is that events work better for building networks of products and services (what we have called "mashups") than request-response-style systems. Event-based programming styles fit the dynamic nature of the interactions we want to have online. Event-based systems work on "this happened" where request-response-style systems work on "do this." The former better supports the looser coupling we'll need to build huge networks of products and services.
Fine, you say, but until more companies build events into their APIs, I'm stuck using their old-school request-response API. More to the point, if everyone does it differently, coding up a system that can use all those events in a loosely coupled way will be impossible.
To that end, Sam Curren and I have developed the Evented API specification. The spec says how event generators and consumers should operate and, as a result, how they interoperate. All interactions are over HTTP to make the spec as flexible as possible. You can use any language to generate and consume events. We've tried to design the spec so that it is easy to implement--particularly for event generators. We'd like every existing API to signal events when appropriate. Here are a few examples:
- Withings - the Withings people really ought to generate an event when a new data point gets added to my data.
- Endomondo - wouldn't it be cool if Endomondo published an event at the start and stop of a ride or run? I could do more than Tweet my exercise, I could use it to drive other programs.
- Flickr - Flickr ought to publish an event whenever my collection is updated. Now other programs know when to come grab a new picture. Photography workflow ensues.
- Foursquare - send events when you check in so that check-ins can drive other programs around the Web.
- Airlines - send events about delays, ticket purchases, and so on so services like TripIt can more easily mash up with them and guide my trips.
- Banks - Mint! Just stop the screen scraping already.
- Fitness data - don't even get us started...
I could go on. There are literally thousands of APIs that have useful information to tell us without our having to ask first. We are stuck in a state of affairs that is the legacy of where we've been (the Web), not where we need to go.
Adding an event generator to an existing service is trivial. Every modern programming language has a way to make HTTP requests and that's all that's necessary. I think many services could add events in a few days of programming time.
If you're familiar with Webhooks, you might ask "how's it different from a webhook?" Webhooks are used for both events and RPCs, and (intentionally) lack constraint on how they are used. Evented APIs are only used for transferring events, and the API allows for a generalized way of transferring events with a common format. The Event API spec fits within the Webhook model and thus any event consumer in the Evented API space has implemented a Webhook. Event generators are calling Webhooks.
If you visit the Evented API site, you'll find an example event generator and event consumer so you can visualize how event subscription, generation, and consumption work. Visit the consumer and create a event signal URL, cut and paste it into the event generator, and start playing.
The Evented API spec is separate from Kynetx. We support it (or will, very shortly), but the Evented API spec is designed to be independent. No proprietary technology is needed to generate or consume events using the spec. Evented APIs is for everyone--not just Kynetx customers and partners. Help get the word out!
9:20 AM | Comments () | Recommend This | Print This
October 3, 2011
Personal Event Networks: Building the Internet of Things
The Internet of Things keeps coming up in conversations. I think when Marc Benioff talks about social products and services, for example, he's talking about the Internet of Things. Because of the particular arc that the development of the Internet has followed, using "social" to describe connected products and services makes marketing sense.
This talk by Wim Elfrink is also talking about the Internet of Things. Wim does an excellent job of painting a picture of what a completely connected world looks like.
(BTW, if you'd rather listen to Wim's talk, IT Conversations has Wim's talk as well.)
The Internet of Things is close. Your car has had processors in it for a long time. Many cars--thanks to teathering with a mobile phone--are online. The same goes for a host of other products. My Tivo, for example, is online and I control it with a little app on my iPhone. More products could be online if someone knew what value that would provide.
The chief obstacle to getting more things online is that no one is quite sure how to get them to interact with each other, although we've got some ideas. Certainly APIs will play a role. Beyond that it gets fuzzy. Consequently what we see are connected products--like my Tivo--that have an app and not much else. For my Tivo, remote programmabilty is enough added value that an app makes sense. But do you want an app for your refrigerator? Or your toilet? Today's connected products look like the picture below:
In this drawing, the Toyota car and the TomTom GPS are both online and they each have an app that you can install on your phone. But beyond that, it's kind of boring. How do the GPS and the car interact with each other? They don't. They're online, but they're not "networked." They're not really "social" because they're not cooperating or communicating with each other.
What's more, even if we conceive of each having an API, we're missing some of the most important interactions if they have to be queried before they take part in a conversation. I don't want to have to initiate all of the interactions between my products. I want them to speak up when something important happens.
Social products need to be networked if they're to cooperate. The following picture shows the same online products, but now they're connected to an event network.
The event network allows the car and the GPS to raise events when something of interest happens. What's more, this event network is personal, meaning that my things raise events that other things that belong to me see. Your things raise events in your event network. The apps installed on this personal event network represent my intentions and interests, choreographing the interactions among the products and services I own.
The apps from the car manufacturer and the GPS manufacturer are still available, but so are other apps that third party developers have created, like a "travel app." This app, for example, sees me researching routes on the GPS for a trip I'm going to take and reminds me to plug my electric car in because it needs juice. Note that I'm not using the app to plan the trip, I'm using the product--the GPS--but the app sees the events from the GPS and the car and links them together. This is an important distinction because the product, naturally, is the locus of my activity. Rather than forcing the user to interact through a phone interface in a video game-like virtual world, I merely use products as they were intended. The UX is the natural interactions I have with things in my life.
An Internet of Things will happen if there's sufficient value. In this model, there's value for customers and sellers. The customer sees more value in products that cooperate than in products that are merely online. On the product side, the seller now has a product that is a platform on which other developers can build applications. Most products are not interesting enough in themselves to represent a viable platform that can attract significant developer interest. Consequently they miss out on the benefits of having others create valuable add-ons. But products in an network of other cooperating products represent a rich ecosystem that will excite developer imaginations.
An Internet of Things--social products and services--will have as profound an effect on our lives as the changes of the preceding 15 years. I believe that personalized event-driven programming models are a key part of the architecture that makes them real. Events make active participants of formerly passive APIs and make social products a reality.
Related: