Reliable messaging

THE HTTP PROTOCOL is both the greatest strength and the Achilles’ heel of the Web services movement. Yes, it’s wonderful that SOAP (Simple Object Access Protocol) messages can go everywhere they are needed, but the HTTP, SOAP, WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration) stack doesn’t address a slew of issues crucial to the effective deployment of Internet software, such as reliable messaging, single sign-on, and disconnected use.

Kenamea’s Application Network is a suite of server-side and client-side technologies that collectively layer secure, transactional, and event-driven communications on top of HTTP, yielding a communications platform for reliable and highly interactive Internet applications.

The Application Network is powered by the Kenamea Message Switch — a Java-based server that was first made available in July 2001 as a Kenamea-hosted service. And now in the new 1.2 release, the Application Network becomes a product you can deploy on Solaris or Windows 2000.

Opening the gates

The Message Switch is only the coordinating router in what is effectively a peer-to-peer network of clients and/or servers. Clients access the Switch by way of the Kenamea Desktop Connector, a gateway that opens an authenticated, persistent, and SSL (Secure Sockets Layer)-secured HTTP connection to the switch.

But the Desktop Connector is much more than just a gateway. It also guarantees that all messages sent to the network will be delivered exactly once. Because messages sent while disconnected are queued for later delivery, the Connector confers offline capability on applications built for the Kenamea platform. Moreover, because the Connector multiplexes all such applications onto a single connection, it conserves both client-side and switch-side resources. Finally, the Connector packages all this functionality for use by either thin-client Windows applications, such as those built on Internet Explorer-style DHTML (Dynamic HTML), or fat-client applications, such as those based on COM (Component Object Model).

A Kenamea DHTML Application typically runs in a Kenamea-supplied container that uses IE components, although it can also run directly in IE. Its elements are familiar to most Web developers: JavaScript and DHTML. At the core of every DHTML app are three JavaScript constructs that tie in to the messaging substrate. A SendMessage function delivers messages to the network, while an OnMessage function reacts to messages inbound from the network, which the Connector arranges to deliver as JavaScript events. Finally, a SubscribeToTopic function call registers the application to receive events from the Application Network.

To see how these pieces work together, you can download the Connector and try out the dispatcher example at . This app simulates a fleet of bike messengers. Inbound messages, which place packages in the delivery queue and report on the location and status of deliveries in progress, are mapped to a real-time display. In effect, the app’s DOM (Document Object Model) is made directly sensitive to network events. The same app can inject events into the network by assigning idle couriers to waiting tasks. It’s a dramatic illustration of what JavaScript and DHTML can do when unfettered by a stateless, client-pull, page-refresh model.

Each DHTML app is delivered as a single file with an .htk extension. This payload, which typically includes HTML, JavaScript, and image files, is not much heftier than a typical Web page but is delivered just once.

From then on, until the app is revised, the Connector uses these resources without making any changes to them — possibly even while offline. The app can read and write local files within the sandbox defined by its subdirectory and by a dictionary of stored values.

Building a Kenamea-style network

We encountered no difficulties installing the Kenamea Switch on our Windows 2000 server. As a switch administrator, you’re in control of Kenamea’s powerful single sign-on feature. You define a population of users, a set of application IDs, and a set of publish-and-subscribe topics; you also manage the associated ACLs (access control lists). Users logged in to the Switch only have access to the applications and topics that you grant.

Developers use the Application Workbench to package up the pieces of a DHTML application into an .htk file and publish the app to the Switch. Once deployed to a population of users, the app can function in a distributed, peer-to-peer manner.

An intriguing example of this model is Picster, a Napster-like app for sharing images. Picster clients run a query for images by sending messages to a Switch-managed application name space, which is essentially a channel they can also monitor. A client who reports an instance of the desired file name sends it as a Kenamea message.

The same principles apply to COM-based apps. Users can also deploy a purely browserbased variant that acquires its Kenamea connectivity by loading JavaScript on the fly. The downside, however, is that this flavor requires extra server-side support — in the form of a servlet container such as Tomcat — and lacks the robust queueing and transactional features of the other two.

The messaging system that makes it easy to write a sophisticated app such as Picster is also available for more conventional client/server integration. The tools available for this purpose include the Java Connector — a Java API to the switch, which supports commit and rollback semantics for use with other transactional systems — and a set of adapters for JMS (Java Messaging Service), EJB (Enterprise JavaBeans), and Web-server-based applications.

Unfortunately, Kenamea’s back-end integration kit is not nearly as polished as its client integration kit. A welter of subdirectories, XML configuration files, Java “classpath” declarations, and special-purpose adapters is not atypical. A toolkit that shields enterprise integrators from these details would be a welcome enhancement in a future release.

Does Kenamea really deliver a Web services solution? Not if you define Web services to include SOAP and WSDL, which Kenamea does not yet support. But if your definition broadly embraces any approach to networked software that builds on Internet protocols and standards, then Kenamea clearly qualifies. What’s more, the solution pushes the envelope with a next-generation communications layer whose properties will likely, in a few years, seem as inevitable as XML-via-HTTP does today.

Source: www.infoworld.com