Internet appliances differ from many embedded products because Internet appliances require connectivity. But it takes more than network hardware and TCP/IP stacks to make a successful Internet appliance. Application connectivity provided by software frameworks is the key.
Service location and identification standards like Jini and Universal Plug and Play (UPNP) are needed to automate connections between Internet appliances. Gateways are needed to provide firewall and management support (see the figure). Data exchange using standardized formats like Extended Markup Language (XML) is needed for cross-platform and cross-vendor support.
These new protocols and frameworks are quickly moving into Internet appliances. Putting a Web server or a Web browser on a device is only the first step in the evolution and provides a limited interaction between devices. A device having only Web-page support will seem trivial in a year or two.
There also is some confusion about what an Internet appliance is. Internet appliances include client-oriented devices such as Web pads, cell phones, and even PCs. Internet-appliance servers tend to provide information or perform a service.
Part of the problem is that only some Internet appliances are strictly clients or servers. Most run a collection of applications that provide or use services. For example, an MP3 storage device with a hard disk may receive streaming audio from the Internet and store it on the hard disk so it can be streamed to an MP3 player or portable unit. The MP3 storage device may be configured remotely, in which case it provides a remote configuration service.
Remote configuration and service location is the reason for Jini and UPNP. Jini is part of Sun's collection of Java specifications. The Universal Plug and Play Forum handles UPNP, which also is part of Microsoft's .NET architecture. Both provide a mechanism for a device to locate devices and services when the device is connected to the network or Internet. Jini goes a step further and locates services. It also can start services on remote devices (see "Service Identification And Location," p. 76).
Operating-system and framework developers are just starting to deliver features like Jini and UPNP. One reason for the slow incorporation of these features is that they are useful only when multiple devices are employed. This includes at least one device that serves as a coordinator.
Typically, a gateway serves as a coordinator. A gateway also can act as a buffer between a standards-based interface and a set of devices where communication is through a proprietary protocol. The Open Systems Gateway Initiative (OSGi) is a Java-based architecture that can fill its void.
OSGi gateways can service any type of device, but they often are used to service small 8- and 16-bit devices that have minimal computing power or memory resources. Such devices were never considered for Internet-appliance designs, but this has proven to be incorrect. This class of processor obviously cannot outperform a 32- or 64-bit solution, but the smaller processors cannot be beat for price.
Products like Rabbit Semiconductors' RCM 2100 series, Microchip Technology's PIC series, and ZiLOG's eZ80 Webserver not only come with TCP/IP support, they also can run TCP/IP-based applications like a Web server or Telnet client (see "TCP/IP For 8- And 16-Bit Devices," p. 78). Products like Ubicom's IP2000 family of Internet processors are specifically designed as a single-chip solution for Internet appliances, including gateways.
Application functionality tends to be limited but more than sufficient for a variety of environments. For example, the number of concurrent sessions a smaller processor can support tends to be low. A single session may be the limit. This is of little consequence if a device will only be controlled using a single session.
Eight- and 16-bit solutions make a lot of sense for controlling or monitoring a limited number of peripherals or peripherals that do not require high-performance applications. These less-powerful processors also can be more economical for modem-based connections.
One area where 8- and 16-bit solutions tend to fall short is security. Encryption algorithms are computationally expensive. Adding hardware encryption support to a design often brings the bill of materials (BOM) in line with or above higher-performance processor solutions. This is where 32- and 64-bit processors are needed.