Interface Hierarchy

All MSS objects inherit from the base interface MSSObject, which in turn inherits from the CORBA property service interface PropertySet. The PropertySet interface contains all the functionality that is necessary to set or get the values of properties. The most important component of the MSSObject interface is the definition of the location property. Three inter-faces inherit fromMSSObject:VirtualResource,Format andStream. The most interest-ing aspects of the Stream interface and its descendants have already been discussed. The Format interface is further refined with digital audio and video formats and analog connector formats. All MSS devices inherit fromVirtualDevice, which in turn inherits from Virtu-alResource. The MSS RP defines virtual video devices for different windowing technologies and basic microphone and speaker devices for audio. Not shown in Figure 5.3 are the file device and a compact disk player device.

The design of the interface inheritance tree is sound with the exception of the VirtualDe-vice hierarchy. The existence of the virtual devices VideoDevice, AVDevice and AudioDevice appears to be a result of taxomania [Meye96]. The IDL definition of these vir-tual devices contains only properties and capabilities, i.e., string constants, and no real func-tionality. The only recognizable function of these interfaces is that they protect the names of

Figure 5.3. MSS interface inheritance diagram.

MSSObject

the defined audio or video properties and capabilities. This however should be rather done by a CORBA module definition than by an interface definition. Note that MSS does not use CORBA modules at all, with the result that all MSS interfaces are defined on global scope.

5.3.6 Assessment

MSS is the most important CORBA-based multimedia middleware defined until now. It defines a complete framework for multimedia processing and transmission and is based on set of sound abstractions, most notably the virtual device, stream and format abstractions. The most important problem with it is maybe that it was never finished by the people that originally con-ceived it. The last MSS RP draft is incomplete and contains many inconsistencies, which is why it is certainly not easy to recycle it for PREMO. Some important details of the architecture do not work as they are supposed to, with examples being automatic format matching and compound resource allocation, and nobody has ever built a prototype for MSS. Maybe MSS

IMA-MSS

Requirement Fulfilled Remark

Open ❄❄ client interfaces open, internal device interfaces hidden

Extensible ❄❄ extensible design, but no implementation framework Programmable ❄❄ programming with capabilities is flexible, but tedious Scalable ❄ graphs may only contain a small number of devices

Deployable no no strategy for deployment

Simple ❄❄ small number of powerful concepts

Session Management - not in the scope of the architecture Connection Management ❄❄ a lot of flexibility at a low level

Multimedia Data Processing ❄❄❄ flexibility due to virtual device and format abstractions Multipoint Control Comm. ❄❄❄ use of CORBA and the CORBA event service Resource Management ❄ resource management architecture outlined Synchronization ❄❄ inter-stream and event-based synchronization

Mobile Code -

-Presentation Environment no does not address integration of objects into GUI’s Federation of Applications -

-Security no

-Mobility -

-Directory Service -

-Platform Management no

-Accounting -

-Standard DPE ❄❄❄ CORBA

Table 5.2. Evaluation of IMA-MSS.

came too early with respect to CORBA. The first version of MSS could not use any CORBA service, and by the time work on MSS stopped the CORBA property service had not even been finalized yet.

MSS is a framework for the support of application compatibility. As such it is not at all con-cerned with internal interfaces, and most notably not with the internal interfaces that have to be implemented by a virtual device or that are accessed by it. It is therefore not possible for third parties to develop virtual devices. Support for third-party device development requires at least the definition of the port and resource manager interfaces. It would also be necessary to add some GUI abstractions to MSS. The technology-prone video devices to be seen in Figure 5.3 would need to be replaced with widgets that can be readily integrated into GUI’s.

5.4 TINA

The Telecommunication Information Networking Architecture (TINA) is a platform for MMC service provision that is being developed by the TINA Consortium (TINA-C). The TINA con-sortium was founded at the beginning of 1993 following an initiative of Bellcore in the United States, British Telecom in the United Kingdom, and NTT Japan [Barr93], and has at the time of writing 45 members, including 26 telecommunications operators, 11 telecommunications manufacturers, and eight computer manufacturers and software companies¹. TINA is the pre-dominant effort in the area of telecommunications to come up with an open, next-generation architecture for the provision of MMC services. It is mainly motivated by the fact that cus-tomer premises equipment has become more intelligent than network equipment, with the con-sequence that it will play an important role in future telecommunications systems architectures. Other factors that lead to the foundation of the TINA consortium were market trends like the globalization of services and the increasing demand for service diversity. Cur-rent network and service architectures are complex and difficult to manage. They do not sup-port the rapid development and introduction of new services, and they are overwhelmed by service interaction problems. TINA is supposed to solve these and other problems of current networks by defining a radically new and future-proof architecture along with a viable migra-tion path to it.

TINA is required to provide architecture support for administrational domains, business roles and stakeholders. Transport mechanisms shall be transparent to TINA, making it possible to deploy TINA on top of all kinds of networks including ISDN, B-ISDN, WAN’s, LAN’s and mobile networks. TINA shall be useful at all stages of the service life cycle, and the range of services supported by TINA shall be open-ended. The following objectives are defined for TINA [Brow95]:

• interoperability: platform and application software of different vendors shall be able to interoperate.

• reusability of application software: support for the reuse of application design, and the run-time reuse of application software.

• distributed execution of applications: support for the transparent distribution of application and platform software onto physical nodes.

1. See the Web site of the TINA Consortium (http://www.tinac.com/) for up-to-date information regarding mem-bers.

• support of new types of service: support for MMC services, mobility, service customization and the handling of service interaction.

• support for management: support for the management of software and network resources, version management, replication management, accounting, etc.

• independence from computing environment and hardware: the architecture shall not rely on specific hardware and software environments.

• support for quality of services: the architecture shall provide QoS management functionality on multiple levels (network connections, service execution, etc.)

• scalability: implementations of the architecture shall work efficiently in the face of large numbers of users, nodes, administrational domains, etc.

• security: the platform architecture must address all possible security concerns.

• compatibility with existing telecommunication systems: the architecture must support interworking with existing telecommunication systems.

• flexibility against regulation: the architecture must be flexible with respect to specific regulatory environments.

• conformance testing: the architecture must define rules and guidelines for con-formance testing.

In its present state, TINA does not respond to all of these objectives. Service interaction and security are examples for important issues that are not sufficiently addressed by the current set of TINA specifications. However, the scope of TINA is so wide and the number of problems consequently so large that it would be astonishing if TINA could reach all of its objectives.

The following sections discuss the most important features of TINA, namely the business model, the service architecture, the connection management architecture, and the computing architecture on which all processing is based. Figure 5.5 sketches the service and connection management architecture of TINA, as well as some aspects of the business model.