<<  Page 4 of 5  >>

Devices

A UPnP device can be thought of as a logical container with a unique type. Each UPnP device may offer any number of services, each service with its own unique service type. By itself, a device does nothing more than provide self-describing information such as the manufacturer, model name, and serial number. A device's services provide the real functionality.

A UPnP device may also contain other devices. That logical composition of devices gives the designer flexibility when determining how to implement the device. It also allows the embedded device to be discovered and used independently from the main container device. Figure 4 shows a detailed UML class diagram for a UPnP device.

Figure 4 - Class diagram: the UPnP Device

Services

Each service in a UPnP device may contain any number of actions, each action having a set of input parameters and an optional return value. Each action also has a name and an optional set of arguments. Each argument has a name, a value, and a direction. The direction may be either input or output (but not both), depending on whether the argument is passed into the action or is returned from the action to the caller. Each action may also have a return value that provides the result of the action.

Those familiar with interface-oriented object model systems, such as Microsoft COM or CORBA, can draw an analogy: a UPnP device is similar to an object, the services are like interfaces supported by the object, and the actions in a service are like functions in an interface.

Each UPnP service also has a service type Uniform Resource Identifier (URI) that uniquely identifies the service. Standard service types are defined by a UPnP Forum working committee. Every service also has a serviceId URI that uniquely identifies the service among all of a device's services. No two services may share the same serviceId. The services that a device must implement are determined by the device's type. The working committees of the UPnP Forum standardize the set of services a device type must support.

Each service may also maintain variables that represent that service's current status. A service may have zero or more such variables. Each state variable has a name, a type, a default value, and a current value. It also has a set of allowed values to describe the range of permissible variable values. Any state variable can trigger events on state changes; when such events occur is determined by a service's implementer.

If a variable triggers an event to indicate a state, that variable is said to be evented. Every input argument to an action is associated with one of the service's state variables, termed the argument's related state variable. One of an action's arguments may be designated as the action's return value. The return value provides the result of the action to the caller. Figure 5 shows a UML class diagram for a UPnP service.

Figure 5 - Class diagram: the UPnP Service

UPnP control points can subscribe to receive indications of state variable changes from a service. When a service detects a change to a state variable, that service notifies any registered control points of that change. For example, a service that renders audio tracks might keep a state variable of the URL of the current track being played. When the track changes, the service sends a state change notification with the new URL to all control points that have registered interest in receiving events from that service.

Control Points

A control point is a network entity that invokes a device's functionality. In client/server computing terms, the control point is the client and the device is the server. Control points invoke actions on services, providing any required input parameters and receiving any output parameters and possibly a return value. Figure 6 shows a control point invoking an action on a UPnP-enabled device that implements a single UPnP device type containing two services.

Figure 6 - A control point invoking an action on a service

As the figure illustrates, a control point discovers devices, invokes actions on a device's services, and subscribes to event notifications. A device, on the other hand, responds to invoked actions, sends events when state variables change, and supports a Web page for administrative control (a presentation page in UPnP terminology).

<<  Page 4 of 5  >>

Spontaneous Networking | Jini Community News | Discuss | Print | Email | First Page | Previous | Next

---

Pavilion Pages Exadel offers revolutionary Professional Tools for Open Source. Enterprise object relational mapping with Solarmetric's Kodo JDO. Visit the Crystal Developer Zone for Crystal Reports info. Cluster with Coherence for reliability, scalability and performance.

Sponsored Links Combine Job Scheduling + JMS Messaging with SwiftMQ. Shape the future of Java[tm] technology. Join the JCP[sm]. Download Free Chapters from the Artima Chapters Library.