8.4 Architecture Elements


Services in the HAVi architecture are modeled as self-contained entities, called (software) elements. Each element is accessible through a well-defined interface and executed within a (software) execution environment hosted by the device on which the object runs. Different devices may host different execution environments.

8.4.1 Element Identifiers

Each element is uniquely named. No distinction is made between objects used to build system services and those used for application services. Elements make themselves known via a system-wide naming service known as the Registry. Software objects can query the Registry to find objects used for interfacing elements and can use the result of that query to send messages to those objects.

The identifier assigned to an element is created by the messaging system before an element registers. These identifiers are referred to as Software Element Identifiers (SEID). SEIDs are guaranteed to be unique, however the SEID assigned to an object may change as a result of reconsideration of the home network (e.g., device plug-in, removal, or reinitialization).

8.4.2 Message-Based Communication

All objects communicate using a message passing model intended to provide a generic software model that is sufficiently flexible to allow multiple implementations with a variety of software systems and languages. Any object that wishes to use the service of another object does so by using a general purpose message passing mechanism that delivers the service request to the target object. The target object is specified using the unique SEID just discussed.

This general purpose message passing mechanism abstracts from the details of physical location, namely there is no distinction between an object on the same device and one on a remote device. The format of HAVi messages and the protocol used for their delivery, is standardized to assure interpretability. In contrast, the actual implementation of the message passing mechanism differs from device to device and between vendors .

8.4.3 Element Descriptions

The software elements of the HAVi architecture support the basic notions of network management, device abstraction, inter-device communication, and device user interface management. Collectively these software elements expose the Interpretability API, a set of services for building portable distributed applications on the home network. The software elements themselves reside above a vendor specific platform such as a RTOS.

Figure 8.1 depicts the arrangement of software elements on an FAV device. Although not intended as an implementation blueprint, the diagram does highlight how the HAVi software elements form a middle layer between platform specific APIs and platform independent applications.

Figure 8.1. HAVi architecture for full audio video device.

The software elements comprising the HAVi architecture are as follows :

  • Messaging system : It is responsible for passing messages between software elements. It contains a 1394 communication media manager that allows other software elements to perform asynchronous and isochronous communication over 1394 FireWire.

  • Registry : Serves as a directory service, allows any object to locate another object on the home network.

  • Event manager : Serves as an event delivery service. An event is the change in state of an object or of the home network.

  • Stream manager : It is responsible for managing real-time transfer of audio video and other media between functional components .

  • Resource manager : It facilitates sharing of resources and scheduling of actions.

  • DCM : It is a software element (e.g., havlet) used to control a device. A DCM includes code for the DCM itself as well as code for Functional Component Modules (FCMs) for each functional component within the device.

  • DCM Manager : It is responsible for installing and removing DCM code units on FAV and IAV devices.

In addition to these software elements, devices may contain the following:

  • Application module : The HAVi architecture provides a general platform for several forms of applications. In general a HAVi application creates software elements that use other software elements to provide specific services. A HAVi application may be developed in native code and embedded (resident) on an FAV or IAV. A HAVi application can be Java bytecode and can be obtained from external sources (i.e., uploaded over the Internet) or from existing software elements using mechanisms defined by HAVi.

  • Self Describing Device (SDD) data : HAVi-compliant devices contain descriptive information about the device and its capabilities. This information, called SDD data, follows the IEEE 1212 addressing scheme used for configuration ROM. The SDD data may include a DCM code unit and vendor-specific data for constructing user interface elements.

  • JRE : It provides an execution environment for uploaded DCMs and applications implemented using Java bytecode.

  • Data Driven Interaction (DDI) controller : This is a software element involved with user interaction. The DDI controller handles user input and interprets ( renders ) DDI elements.

Table 8.1 lists which architectural elements are present for the various device categories, which are absent, and which are optional, with the following provisions:

  • A DDI controller is required on an IAV or FAV if the device renders DDI elements according to the DDI protocol. Display-capable IAVs or FAVs contain DDI controllers.

  • A resource manager is required on an IAV device that hosts or can host DCMs.

  • A stream manager is required on an IAV if its applications make streaming connections.

  • A DCM for an FAV or IAV resides on the device itself.

  • A DCM Manager is required on an IAV device if it can host DCMs for BAVs or LAVs on the 1394 network. For both BAV and LAV devices there is an associated device control module somewhere on the home network. For a BAV device, the DCM is typically obtained via the device's SDD data. For LAV devices, the DCM may be embedded on the controlling FAV or IAV.

  • For IAV devices it is not necessary that a DCM exists on the home network. If such a DCM does not exist then interoperable applications cannot control the device.

Table 8.1. HAVi Configurations

Element

FAV

IAV

BAV

LAV

Java Runtime

required

     

Application Module

optional

optional

   

DDI Controller

optional

optional

   

Resource Manager

required

optional

   

Stream Manager

required

optional

   

DCM Manager

required

optional

   

Registry

required

required

   

Event Manager

required

required

   

Messaging System

required

required

   

1394 Interface

required

required

   

SDD Data

required

required

required

 

DCM

required

optional

required

required



ITV Handbook. Technologies and Standards
ITV Handbook: Technologies and Standards
ISBN: 0131003127
EAN: 2147483647
Year: 2003
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net