Brokerage layer simplifies design

The rise of the Internet Protocol-based network as a low-cost, ubiquitous embedded networking environment has led to strong interest in networking what used to be standalone electronic devices with remote applications and other back-end systems.

The creation of this "extended Internet," where a vast number of devices and remote applications are connected and integrated with one another, will be a daunting programming challenge for developers designing embedded systems or integrating devices with applications, as well as for administrators managing the deployed systems.

The most effective way to eliminate the variation and complexity of integration is to create a new software "layer" between devices and applications. This layer simplifies, or abstracts, the views that devices and applications have of each other and provides a complete device- and context-management structure.

By design, this layer addresses integration and management issues, especially the context management that is lacking in other approaches. The model for the layer is a brokerage, or a managed group of services that accommodates large numbers of unique transactions on an ad hoc basis between members of dynamic constituencies-devices and applications, for example.

Each individual broker presents an abstraction of its members (e.g., devices) to other members (e.g., applications), giving all members a simplified, consistent way of dealing with one another. The brokerage and its internal management functions facilitate all interactions, maintain all contexts and ensure that all devices are correctly provisioned, authenticated and updated.

There are several considerations when connecting devices to the network. If the device is a legacy system, an adapter is required to provide IP connections. To help speed prototyping and pilot deployments, the best adapters to use would be commercially available products with a variety of interfaces for data and management functions. A network interface for the device will also be needed for applications and management tools so that serial commands and data, for example, can be mapped to IP network packets.

If the device is an IP network-ready system, developers should embed client software-called a microclient-within the device to maximize its Internet functionality. This is required for devices that the programmer must ensure will support device software upgrades and management services, as well as to provide automatic registration and provisioning services.

The following development steps should be considered:

• The device must be configurable remotely.

• The device must be able to connect to a server to transfer information.

• Code size must be quite small-on the order of tens of kilobytes, rather than megabytes.

• Device firmware must be upgradable remotely, rather than requiring an on-site field upgrade visit, because of cost, as well as possible hazardous or very remote environments.

• The microclient should be able to interact with device software, capture data from it and send that data back to the server, as well as accept data from the server.

• The microclient should be easy to integrate into an existing network with very little configuration, and require little or no networking knowledge or intervention.

Data translation

Once devices have been connected to the network, a framework for device communications and management must be created with high-level abstractions of devices and device data. Device data must also be adapted for remote applications, so that devices and applications can exchange information.

Some protocol translation may be needed in the server in order to understand data sent by the physical device. This operation should be done before data is sent to a device representation. In addition, the programmer must decide how to provide management information to other systems. Since management and operation of the device must be separated, a framework such as JMX can be used to describe devices as manageable entities in order to ease their adaptation to management applications.

At this stage, the developer or programmer must consider several steps:

• Trust between the server and the device must be established, regardless of which one initiates a connection.

• Server-device types of connections must be optimized, especially when there are a large number of simultaneous connections.

• Security needs to be established, through the use either of session keys or of a mechanism that will secure server-device data transmission.

• A discovery/lookup function must be created that links the device to its representation at the server level and that the server can use to acknowledge the device. This is tricky when a large number of devices are linked to the server.

• The device's correct identification must be presented to the application.

• The right model for the device must be chosen so that it and its subcomponents may be addressed correctly.

• Device abstractions must clearly separate the management interface from the operational interface.

When adapting device data to the specific requirements of remote applications, developers have two essential considerations. First, the only data and commands that should be mapped to the device are those needed for its interaction with a custom, standard or industry-specific application.

The second major consideration is the development environment. A plug-in environment, such as Java, will help speed development, and XML will make the use of third-party adapters easier and more efficient.

After ensuring manageable device-application communications, rules for interactions between them, within the established framework, must be created. It is especially important to keep these rules flexible so that many applications and many devices can exchange information.

Device-to-application adaptations should be defined with a configuration and a set of definition rules and event rules. Developers may find XML especially useful for describing the device and the application, the events (data) they exchange and the types of rules needed to operate on those events. A Java plug-in environment could also be used for defining rule sets.

When creating flexible rules, developers should consider rules for event filtering, routing, posting, aggregation and synchronization. Event-filtering rules allow data and management to be treated differently.

Many tasks must be completed in order to deal with the intricacies of variations in devices, the difficulties of getting data in and out of different applications, and the rules that control how the integration occurs. Because of the inherent variability and complexity of device integration projects, it is absolutely critical to decouple the three main steps. Without this decoupling, developers cannot take advantage of a general device integration solution. From an architectural perspective, this is conceptually analogous to the decoupling of functions in three-tier Web-system architectures.