Jon Udell: Kenamea's "Application Network"

Tangled in the Threads
Jon Udell, July 18, 2001
Kenamea's "Application Network"

Secure, reliable communications for next-generation Internet applications

Benefits include single sign-on, reliable messaging, offline applications, event-driven notification to the desktop, highly-interactive apps, encryption, and centralized access control.

Readers of this column know that I rarely use this space to focus on a new product or technology. But when the folks at Kenamea showed me what they've been working on, I couldn't resist. The Kenamea software, which CTO Bob Pasker (formerly a WebLogic cofounder) calls simply "a data communications platform," aims to solve several of the problems that plague Web-based application development. Here are some of the problems that Kenamea sees, and the solutions it proposes.

problem proposed solution

How do you achieve reliable, secure, transacted communications to the desktop -- both in realtime and also asynchronously, in a bidirectional manner, through firewalls and NATs? The Kenamea "harness" -- which comes in desktop and server flavors -- is a messaging engine that delivers these capabilities.

How can you make better use of the browser, and the developer skills associated with it? Kenamea's client-side model relies on conventional HTML/JavaScript/CSS/DHTML coding skills. The desktop component enables developers to use this skills in new ways -- to interact with a local datastore, and to exchange messages with an "application network" made up of peers and back-end services.

How do you simplify authentication in a world full of web services? Users authenticate once to the desktop component, which can then connect to a range of services. The Kenamea server, which is primarily a message switch that sits between the client and a conventional web application server, manages access control at the network level, rather than on a per-application basis.

How do you conserve network resources (sockets) in a world full of web services? The Kenamea client multiplexes all local applications through one socket. The Kenamea server does this kind of multiplexing too, and therefore -- the company asserts -- can scale dramatically.

How do you cache the web's user interface, to prevent constant reloading? The core pieces of a client app -- HTML, JavaScript, other files or images -- are cached in a local "payload" directory.

We should also be clear, right up front, about what Kenamea isn't. It's not:

A cross-platform client. Not yet, anyway. The desktop component is of the Win32 genus, and the MSIE 5 species. Of course, since the Kenamea technology is "just" about communications, it can in principle be easily ported. Pasker notes that Palm is an investor in Kenamea, and that PalmOS is a likely next target.

Free. You can, as of today, freely download and use the Desktop Runtime Kit (DRK), which is the client component that enables you to run Kenamea apps. You can also freely download and use the Desktop Developer Kit (DDK), which enables you to build client-side apps, and the Enterprise Developer Kit (EDK, available for Windows, Solaris, and Linux), which you use to Kenamea-ize server apps. With either or both of these developer kits you can build test applications that connect to a public Kenamea "application network." What you can't do for free is run real stuff against that network, or deploy your own network.

Peer-to-peer. As we'll see, you can easily build a Napster-style applications with Kenamea. But like Napster, it will rely on central coordination. Fully decentralized operation is explicitly not one of Kenamea's goals.

If you connect the dots, you'll see that Kenamea has focused clearly on a single -- albeit huge -- business opportunity. The tech crash notwithstanding, our lives are forever changed by the web. When we use our web browsers to book hotel rooms, or participate in auctions, it's hard to remember that such things were almost unimaginable as recently as 1993. But since they became possible, in 1994, not much has changed. The web's UI remains as clumsy, and its communications as unreliable, as ever.

Kenamea takes an evolutionary approach to improving the situation. To see it in action, try some of the NetButtons (Kenemea apps) available at www.kenamea.com. You only need the DRK to run them, but with the DDK also installed you'll be able to understand more clearly how they work.

A nicely representative NetButton is the chat application. There are, of course, a million of these, and while it has some nice features -- including drag-and-drop transmission of images, with inline display -- Kenamea's chat is, in and of itself, nothing special. What's interesting is the supporting architecture. Here are some key aspects:

Publish/subscribe. There are two general modes of high-level communication in Kenamea -- user-to-user, and user-to-group. Since chat needs the latter, it uses a Kenamea topic as the rendezvous for messages broadcast among a group of chatters. Once the chat topic has been published (using the Topic Manager, a DDK tool), the chat application can subscribe to it in order to receive chat messages.

Identity management. Instant messaging systems such as AIM and Jabber provide this, as a key part of the services they offer. Managing identity -- and presence -- is so compelling that Jabber, in particular, has come to be regarded as an interesting platform for a whole range of applications. Kenamea moves this capability into its network, and abstracts it from any particular application. Your Kenamea identity works in chat, but also in a banking or any other Kenamea app.

Familiar development methodology. The chat application is implemented in a way that any web developer will instantly understand. The model is very simple. A Kenamea NetButton is basically an HTML page with JavaScript. It's stored on the client's hard disk in what's called the payload directory. The JavaScript probably includes an OnMessage() handler, which reacts when a message is received from the Kenamea network, and a sendMessage() method to talk to the network. You can do a View Source to see how it's all put together.

My chat with Jeffrey

While logged into Kenamea the other night, I fired up this chat application and found another user, jeffreym, online. He turned out to be Jeffrey McManus, who is an author and now also a Kenamea product manager.

We had an interesting discussion as I poked and prodded at the software. One of my questions was how the chat application we were using might be made persistent, in the way that chat is persistent in Groove. Jeffrey made the same point that Bob Pasker had when I interviewed him a few weeks before. Kenamea is not focused on delivering the kind of fully decentralized XML object store that Groove does. But with that caveat in mind, Jeffrey directed me to a Kenamea app called Picster -- which is like Napster, but for sharing images. He grabbed my picture from my website, stored it on his disk, and then dragged it into Picster's window. This loaded a copy of the image into his local Kenamea datastore (specifically, Picster's payload directory). In my instance of Picster I then searched for the image, found it, and fetched it -- that is, transferred it to the Picster payload directory on my machine.

This was pretty cool. What really put a smile on my face, though, was what I saw when I did a View Source on Picster. Life is short, and I'm not a rocket-scientist coder, so I'm always looking for programming environments that deliver massive leverage using simple idioms at a high level of abstraction. Kenamea does, and it's probably best to just illustrate by example.

Here's Picster sending a query to the network:
function sendRequestMessage(mykeywords)
{
  // keywords are space delimited
  var messageToSend = kenamea.CreateMessage;
  messageToSend.Destination = "com.kenamea.picster";
  messageToSend.Type = "com.kenamea.picster.request";
  messageToSend.PayloadAsString = mykeywords;
  messageToSend.Priority = 1;
  messageToSend.TimeToLive = 300; // requests expire in 5 minutes
  kenamea.SendMessage(messageToSend);
}
Here's Picster responding to "peers":
function OnMessage(message)
{
  switch (message.Type)
  {
    // Got a request for an image matching the payload.
    // Send the response message if there's a match.
    case "com.kenamea.picster.request":
      if (message.Source != kenamea.UserID)
      {
        ProcessPicRequest(message.Source, message.PayloadAsString);
      }
      break;

    // Got a response to a request for an image matching my keywords.
    // The payload contains the filename|desc|keywords.
    case "com.kenamea.picster.xmlresp":
      AddToFoundList(message.Source, message.PayloadAsString);
      break;

    // Got a request for a file transfer.  Payload is the filename.
    // Send them the file!
    case "com.kenamea.picster.xfrreq":
      var thisImage = GetImageInfoFromFilename(message.PayloadAsString);

      // The file may have been removed from the collection.
      // If so, thisImage will be null--don't attempt to send.
      if (thisImage != null)
      {
        sendXfrMessage(message.Source, thisImage.filename, thisImage.desc);      
        Log('Sending file "' + thisImage.filename + '"');
      }
      else
      {
        Log('File "' + message.PayloadAsString + '" could not be sent');
      }
      break;

    // Got a file that I requested.  Payload is desc.
    case "com.kenamea.picster.xfr":
      if (message.File != null)
      {
        AddToList(message.File, message.PayloadAsString);
      }
      else
      {
        Log('Error receiving file: "' + message.PayloadAsString + '"');
      }	
      break;

    // Unexpected message type
    default:
      Log('Unexpected message type "' + message.Type + '"');
      break;
  }
}
The object model that's exposed to JavaScript by the Kenamea client is not much more complex than you see here. There are some functions for reading and writing a storedValues collection (persistent hashtable), for reading and writing the payload directory, for creating and subscribing to topics, and not a whole lot else. The UI is, admittedly, your job, and the Kenamea examples rely heavily on IE-specific DHTML. But, as Bob Pasker points out, Kenamea doesn't want to be in the UI business, it wants to be a data communications platform.

My chat with Bob
As currently packaged, the Kenamea software and its associated development methodologies marry power and simplicity in a way that should appeal strongly to a lot of mainstream web developers. This, Pasker stressed when I interviewed him, is by design.

Bob Pasker:

Our philosophy is one of integration. We're not out to invent a new desktop platform technology, or a new wireless platform, or a new backend technology. We understand that these things exist, and that the best job we can do is lower the barriers to integration.

People already have HTML/JavaScript skills, we're not going to give them Tcl. We're not going to come up with some new backend technology that says: you have to use our app server. You've got J2EE, databases, MS-COM integration, web servers, we need to provide as many kinds of integration as we can, starting from the most popular.

To get platform software built into other people's software, it has to be a developer's product. "Schoolbus selling" is what I call it when you sell someone a product and then unload a schoolbus of consultants on them. WebLogic was not that, it was a developer's product. Anybody could go to the website, wanting to experiment with server-side Java, and download the product and be trying it 5 minutes later.

What people find interesting about Kenamea, says Pasker, makes for "a Rorschak test as to where they are feeling pain." Sometimes the pain reliever is the ability to log in just once to the desktop component. Sometimes it's encryption, which Kenamea does always and automatically, keying each user individually. Sometimes it's the ability to run apps offline, which is supported by automatic message queueing and the local datastore. Sometimes it's access control, which Kenamea abstracts from applications and centralizes in the message switch. Sometimes it's scalability, which Kenamea addresses by multiplexing network connections. Sometimes it's just the ability to have more responsive and interactive web-style applications, which react and refresh in realtime.

I can certainly relate to all these pains. From what I've seen so far, Kenamea is a strong dose of the right kind of medicine.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He is the author of Practical Internet Groupware, from O'Reilly and Associates. Jon now works as an independent Web/Internet consultant. His recent BYTE.com columns are archived at http://www.byte.com/tangled/

This work is licensed under a Creative Commons License.

problem	proposed solution
How do you achieve reliable, secure, transacted communications to the desktop -- both in realtime and also asynchronously, in a bidirectional manner, through firewalls and NATs?	The Kenamea "harness" -- which comes in desktop and server flavors -- is a messaging engine that delivers these capabilities.
How can you make better use of the browser, and the developer skills associated with it?	Kenamea's client-side model relies on conventional HTML/JavaScript/CSS/DHTML coding skills. The desktop component enables developers to use this skills in new ways -- to interact with a local datastore, and to exchange messages with an "application network" made up of peers and back-end services.
How do you simplify authentication in a world full of web services?	Users authenticate once to the desktop component, which can then connect to a range of services. The Kenamea server, which is primarily a message switch that sits between the client and a conventional web application server, manages access control at the network level, rather than on a per-application basis.
How do you conserve network resources (sockets) in a world full of web services?	The Kenamea client multiplexes all local applications through one socket. The Kenamea server does this kind of multiplexing too, and therefore -- the company asserts -- can scale dramatically.
How do you cache the web's user interface, to prevent constant reloading?	The core pieces of a client app -- HTML, JavaScript, other files or images -- are cached in a local "payload" directory.