Software Directory: Embedded Networking Series

July 9, 2001
Jini—Network Service Location Embedded network devices use infrastructures, like Sun's Jini, to locate network-based services. Jini thrives because most embedded devices support Java. Gateways provide a link to...
Jini—Network Service Location Embedded network devices use infrastructures, like Sun's Jini, to locate network-based services. Jini thrives because most embedded devices support Java. Gateways provide a link to embedded network devices that don't run Java.

Jini's dependence on Java is both an advantage and a disadvantage. On the positive side, Java provides a consistent execution platform for services. It also supplies access to other Java-based technologies. Examples include JavaSpaces and Java Remote Method Invocation (RMI), which are both part of Jini. On the other hand, a Java virtual machine (JVM) requires a significant amount of memory and processing power, making it unsuitable for smaller 8- and 16-bit platforms. These can still be used in a Jini environment, but they need a Java-based gateway.

Jini is designed to work with a range of devices, from portable units, such as digital cameras, personal digital assistants (PDAs), and cell phones, to gateways, printers, network-attached storage (NAS) devices, and even PCs. Jini works with most network transport protocols, although TCP/IP is the most popular. Jini can work with other technologies too, such as Bluetooth, JetSend (a service protocol for devices like printers), and Home Audio-Video interoperability (HAVi).

Jini services automatically register themselves with a Jini lookup service, so an application can use Jini to locate a service. Services use the same mechanism to utilize other services. Plus, Jini allows services to be located on the same device or network.

See associated figure

Architecture Jini devices broadcast only when trying to locate a lookup service on a locator device. Devices that provide a service register that service with a lookup server, while client applications locate a service by sending a lookup request to a lookup server. In response to a request, a client receives a service object used to invoke actions on the service provider.

Jini facilitates connections between services located on devices. For example, a Jini-enabled digital camera could download images to a Jini-enabled printer.

At least one lookup service is required, but multiple lookup services can be used. Lookup services also can implement other lookup services to locate services not registered in the local service database. This hierarchical architecture is significant because devices are part of larger networks, such as the Internet. It also is useful when clients are on the other side of a gateway or firewall and thus unable to locate a remote lookup service.

Attributes identify services. The service database stores these attributes so that clients can request a service based on a collection of them.

Jini provides more than just location services, which also separates it from other architectures, like Universal Plug and Play (UPnP). Jini supports remote invocation of services. It provides security and access control services, and it even supports complex transactions with a two-phase commit. These features are often built on top of other architectures instead of by using a consistent architecture and environment like Jini and Java.

Jini employs JavaSpaces. This technology provides distributed object access that may be employed by clients and services. Although JavaSpaces is comparable to CORBA, it requires a Java environment, as does Jini. JavaSpaces provides Jini's transaction and event support that simplifies distributed applications.

See associated figure

FEATURES
Architecture Lookup server
Expansion Hierarchical lookup services
Discovery
Lookup server
Service

Broadcast
Query lookup server
Services
Initial access
Leasing
Remote invocation
Client interaction

Via lookup service
Yes
Yes
Direct
Security Access control lists, encryption
Transactions Two-phase commit
Event support Yes
Licensing No royalties
PLATFORMS
Target applications Internet appliances, networked devices
Target CPUs Must support Java virtual machine (JVM)
NETWORKING
Protocols TCP/IP
Interprocess communication services Java Remote Method Invocation (RMI), JavaSpaces

Sun Microsystems Inc.
(800) 786-7638
www.java.sun.com

Universal Plug and Play Broadcast-based location of devices and services provides a robust, decentralized configuration environment. Universal Plug and Play (UPnP) targets local network environments where devices are added and removed arbitrarily. Its automatic configuration and recognition among devices makes it ideal for consumers.

UPnP provides the infrastructure to recognize changes in the network and to locate devices. Services are associated with devices with UPnP, whereas services are associated with attributes and potentially many devices with Jini.

UPnP has some limitations compared to a centralized hierarchical system, like Jini. For example, it can't locate devices across a firewall. UPnP keeps its design simple by not providing other features found in Jini, including remote service invocation, security, and transaction control. UPnP shouldn't be confused with Plug and Play (PnP) support that's available with PCI adapters within a PC.

UPnP depends upon standards such as IP, UDP, TCP, HTTP, XML, and SOAP. It remains to be seen whether UPnP can reside on small 8-bit processors, but gateways can support them and may also support other non-UPnP devices.

Microsoft, which started and fosters UPnP, has made it part of its .NET framework. Also, UPnP has even garnered wide support from Intel and other major network device players.

See associated figure

PLATFORMS
GENA Generic Event Notification Architecture
HTTP Hypertext Transport Protocol
HTTPU HTTP over UDP
HTTPMU HTTP over Multicast UDP
IP Internet Protocol
SOAP Simple Object Access Protocol
SSDPP Simple Service Discovery Protocol
TCP Transport Control Protocol
UDP Universal Datagram Protocol
XML Extensible Markup Language (used by SOAP)
Architecture UPnP divides network nodes into two categories: control points and devices. Control points use services of devices, which can either be simple and provide services, or else be hierarchical and have embedded devices that provide additional services. The top-level device also is called the root device. In one node, device and control-point functionality can be combined.

Devices use the Simple Service Discovery Protocol (SSDP) to announce their presence to control points after a device obtains an IP address from a Dynamic Host Control Protocol (DHCP) server. If a DHCP server isn't available, then the Auto IP support chooses an IP address from a set of reserved private addresses. The same process is used when adding a control point to a network.

The broadcast nature of UPnP eliminates a single point of failure, but broadcasts are usually limited to a local network or segment. UPnP is an excellent choice for a home or small-business environment. Care must be taken when using UPnP in a larger corporate network where broadcast traffic can affect overall network performance.

Locating a device is just the first step in using its services. Obtaining the description of the available services is the next step. This information is provided as an XML document, which can include vendor-specific information.

A control point can then control a service using SOAP. An XML document is contained in SOAP messages, and HTTP is used to exchange information between a control point and a device service.

Asynchronous device events are configured and sent to control points in the Generic Event Notification Architecture (GENA). In addition, GENA uses XML documents. Multiple control points can subscribe to an event.

UPnP's local orientation is apparent by its presentation option, allowing a control point to retrieve a Web page from a device and present it in a browser. This is typically done with a PC or other browser-equipped product.

UPnP supports versioning and extensible template definitions for describing device services. Span networks aren't part of the standard, although it's theoretically possible to access UPnP devices outside of a network by using a specially configured gateway.

FEATURES
Architecture Broadcast
Network spanning None
Discovery
Lookup server
Service

Not applicable
Broadcast
Services
Initial access
Leasing
Remote invocation
Client interaction

Direct
No
Device specific
Direct
Security None
Transactions Not supported
Event support Yes
Licensing No royalties
PLATFORMS
Target applications Internet appliances, networked devices
Target CPUs Must support HTTP, XML, and SOAP
NETWORKING
Protocols TCP/IP
Interprocess communication services SOAP, XML, and service-specific support

UPnP Forum
(425) 882-8080
www.upnp.org

Sponsored Recommendations

Board-Mount DC/DC Converters in Medical Applications

March 27, 2024
AC/DC or board-mount DC/DC converters provide power for medical devices. This article explains why isolation might be needed and which safety standards apply.

Use Rugged Multiband Antennas to Solve the Mobile Connectivity Challenge

March 27, 2024
Selecting and using antennas for mobile applications requires attention to electrical, mechanical, and environmental characteristics: TE modules can help.

Out-of-the-box Cellular and Wi-Fi connectivity with AWS IoT ExpressLink

March 27, 2024
This demo shows how to enroll LTE-M and Wi-Fi evaluation boards with AWS IoT Core, set up a Connected Health Solution as well as AWS AT commands and AWS IoT ExpressLink security...

How to Quickly Leverage Bluetooth AoA and AoD for Indoor Logistics Tracking

March 27, 2024
Real-time asset tracking is an important aspect of Industry 4.0. Various technologies are available for deploying Real-Time Location.

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!