Table 8.1 provides an overview of the IDL modules that define the multimedia middleware.
The modules that are relevant for device development are::Bas, which contains the definition of the interface hierarchy for devices and device connectors, the module ::DevMan, which contains the definition of the device management interface, and the modules ::Port and::
Cont, which contain pseudo-IDL definitions for device ports and data containers. The module ::Trans contains all definitions that are related to transport. Interfaces related to device graphs are defined in::Tgraph. The stream agent interface finally is defined in::Strag. On the side of the application pool there is the module::Cccm which contains the definition of the connection management interfaces.
Figure 8.1 shows as an example of a device graph an audio sender that consists of analog microphone and tape drive devices, an audio coder device, an IP multicast device and two device connectors. The audio coder digitizes the analog input signal from the microphone or the tape drive, and forwards audio data in the form of containers to the multicast device, which marshals containers into protocol data units and transmits them over the network. APMT defines two kinds of device connectors, namely auto connectors and connector boxes. Auto connectors connect the set of ports that they manage in the most straightforward manner, which means that it is very easy to program with them. Connector boxes are more advanced;
they have to be considered as little switches that provide control over how source and sink ports are connected with each other. Connector boxes contain connectors that are defined as a source port and a set of sink ports. Connectors can be active or inactive. A connector connects its source and sink ports on activation, and disconnects them on deactivation. The example in Figure 8.1 shows two connectors, of which only one can be active at a time. An application that wants to switch between the microphone device and the tape drive device does so by activating or deactivating the respective connectors. Figure 8.1 also indicates the major interfaces of devices and device connectors. Devices have a specific interface towards applications and applets, and a generic management interface towards the graph. This is similar for device con-nectors, with the difference that APMT does not define their management interfaces. Device connectors are part of the infrastructure, and their management interfaces are neither visible to devices nor to applets or applications, which makes it unnecessary to define them.
Component Module Remark
Graph Objects ::Bas graph object, device and device connector interfaces
::DevMan device factory interface, and interfaces related to device management ::Port pseudo-IDL interfaces for device ports
::Cont interfaces of the data buffer and header container ::Trans transport device interfaces
::Res resource management interfaces (not defined) Stream Agent ::Tgraph interfaces related to device graphs
::Strag stream agent interface (graph factory)
Application Pool ::Cccm interfaces of the conference configuration and connection manager
Table 8.1. APMT multimedia middleware modules.
Figure 8.2 depicts the interface inheritance diagram for graph objects, i.e., devices and device connectors. At the root of the subtree defined by APMT is the interface Bas::Gra-phObject, which is the base interface for devices and device connectors. Bas::GraphOb-ject inherits from theCosGraphs::Node interface of the CORBA relationship service. This allows devices and device connectors to participate in relationships that can be navigated by applications, applets, the terminal control panel, the graph, and finally by the devices them-selves. Example relationships are connect relationships and synchronization relationships. The CORBA relationship service can be the basis for compound operations on devices graphs like compound externalization, compound move and compound copy.
The interfaceBas::GraphObject defines two readonly attributes that are related to iden-tity, namely handle andname. Every graph object has an object handle that is unique within the graph. Object handles are used to refer to graph objects whenever the object reference is inadequate for this purpose, which is for instance the case when the object has not been created yet. Four more attributes in Bas::GraphObject inform about the state of the graph object.
The activity state attribute run_state indicates if the device is running or if it is paused, which can be controlled with the two operationspause() andcontinue(). Other operations that affect the state of a graph object are defined in the management interfaces and are there-fore hidden from applications. This is to avoid that applications interfere with compound graph control operations. Bas::GraphObject defines in addition to pause() and continue() an operation that allows to register for events, and a state change event.
The base interface for the auto connector and the connector box, Bas::DeviceConnec-tor, defines a single readonly attribute, contained_endpoints, which is the set of ports managed by a device connector. The interface Bas::AutoConnector adds two readonly attributes to that, namelyfailed_endpoints andmode. The attributefailed_endpoints informs about the ports that the auto connector could not connect. The attribute mode tells if the auto connector is working in best-effort or atomic mode. The interface Bas::Connec-torBox defines attributes for contained, active and failed connectors, and a set of operations for the compound activation and deactivation of connectors.
The base interface for all devices,Bas::Device, contains functionality related to ports. It defines the readonly attribute device_ports that lists the ports supported by the device, and the operationsget_port_info() andget_format() that return general information about
Figure 8.1. Example for a device graph.
Connector
a port and the description of the medium format with which the port is currently configured.
The operations hide() and show() are already known from the terminal server interface.
They allow to control the physical presence of a device on user interface level. Figure 8.2 shows how transport devices are situated in the interface inheritance diagram with respect to Bas::Device. All transport devices inherit from Trans::TransportDevice, which in turn inherits from Bas::Device. The interface Trans::TransportDevice contains, besides the definition of a source port and a sink port, a couple of attributes and operations that allow to monitor data transmission.
Devices and connectors constitute the lowest level of programming in the multimedia mid-dleware, as is indicated in Figure 8.3. This level can be raised by defining composite devices similar to the molecules in Medusa. There is no special support for composite devices on the terminal given that they differ from base devices only in the granularity of the functionality that they offer. It is assumed that the development of a composite device from multiple existing base devices is easy compared to the development of a base device. The minimal configuration of a graph containing a composite device consists of the composite device, a transport device and an auto connector between the two. This is for instance the case in Figure 8.1 when the audio coder, the microphone and the tape recorder are composed into a single audio sender device. It is also imaginable that devices and connectors are used to build independent terminal servers similar in spirit to the medium-specific applications known from the MBone. Such ter-minal servers would provide less flexibility than configurable device graphs, but more pro-gramming comfort because programmers would only need to deal with a single terminal server interface, rather than with graph, device and device connector interfaces. However, for the moment it is assumed that programming support is provided by application pool utilities rather
Figure 8.2. Graph object interface inheritance diagram.
get_port_info()
than extra layers of abstraction in the terminal, as is shown Figure 8.3. The application in the application pool controls application pool utilities which in turn control device graphs in termi-nals. Application pool utilities will rarely need to access device and device connector inter-faces. They mainly use the compound operations of the graph interface to control graph objects. The principal clients of the public device and device connector interfaces are therefore the applets that the application downloads into the terminals. It should be noted that applets are not limited to the usage of graph object interfaces. They may as well create graphs via the stream agent interface, and communicate with applets on other terminals for the purpose of connecting their graphs with others across the network.