Architecture Overview

In APMT, application intelligence is distributed between central application pools and termi-nals in the periphery. An application residing on an application pool will download applets into the terminals that serve as intelligent sensors and that deal with every issue that is local to the terminal. Applications access low-level terminal objects as well as high-level application pool utilities. One such utility is the connection manager that establishes connections among the ter-minals that participate in a multipoint application. The application pool must be considered as

a center of control and coordination, and will rarely be the source or sink of multimedia data.

Multimedia data transmission and processing is performed by standard hardware and software devices within the terminals, and multimedia data streams bypass the application pool on their way from source to sink terminals, as is indicated in Figure 6.1.

Architecture Components

Application pool and multimedia terminal are the principal components of APMT. Other com-ponents have been identified, but since their role is considered to be secondary they will not be addressed with the same level of detail as the application pool or the multimedia terminal. The components of APMT are:

• application pool: all applications are installed on application pools. An applica-tion pool provides high-level utilities to applicaapplica-tions running on it. Applicaapplica-tions can be built from such utilities, and from other applications.

• multimedia terminal: a terminal provides functionality that allows users to start applications and to join application sessions in an application pool. Applications download applets into the terminal, and collaborate with the terminal infrastruc-ture in the establishment of multimedia data connections with other terminals.

• multimedia object server: a multimedia object server is a special kind of termi-nal. It contains a subset of the multimedia middleware commonly found in ter-minals, and specializes some of the control interfaces of the terminal.

• user agent pool: a user agent pool contains a set of user agents. A user agent serves as contact point between user and application. As such it knows for instance about the whereabouts of a user.

• service gateway: the primary role of service gateways is service localization.

Application pools dynamically register and unregister their applications and active sessions with the service gateway. Service gateways may help distribut-ing application startup requests over a range of application pools.

• directory service: the directory service distributes information about users, ter-minals, application pools and service gateways.

Figure 6.1. APMT example scenario.

Application

Application Pool

Connection Manager Miscellaneous

Utilities ApplicationPool Control

Terminal Control

Stream Agent Applet Handler

Graph

Multimedia Terminal

MT

MT

MT

MT: Multimedia Terminal

APMT components can be internally distributed. As an example, a multimedia terminal may consist of a single machine as well as of a cluster of cooperating machines. It is neverthe-less likely that APMT components are not internally scattered over different administrational domains. As an example, an application pool will not run applications on machines outside the network of its owner.

Applications versus Services

The word service is used with care in the specifications of APMT. APMT is first and foremost an architecture for the development, deployment and execution of MMC applications. It is possible to commercialize these applications as telecommunication services, but the way this can be done exactly is outside the scope of this thesis. The name service gateway for the archi-tecture component that mediates between application pools and users was chosen on purpose in order to indicate that the APMT application platform can be tuned into a service platform.

This requires most notably support for service subscription and accounting. In its current form, APMT does not provide any support for service subscription, which means that users are unknown to the application pools on which they run their applications. Also not supported by APMT is accounting. It is likely that users will want to pay the majority of services provided by application pools with electronic money [Neum95], making it maybe more important to provide support for electronic payment than for classical accounting. However, service sub-scription and accounting can be added to APMT without any difficulties. The APMT compo-nent that handles the participation of terminals and users in application sessions is extensible and may be supplemented by more sophisticated ones. This makes it possible to add new ses-sion management components to the platform that are tailored to business requirements, and that interface to an accounting framework.

APMT and Internet Technology

APMT builds on existing Internet protocols for all control and data communication. The trans-port protocols that are relevant for APMT are TCP for reliable point-to-point transmission, UDP for unreliable unicast datagrams, and IP multicast in combination with UDP for the unre-liable delivery of datagrams to multiple receivers. What is still missing is a standard reunre-liable multicast protocol as a multipoint counterpart to TCP. Applications have widely differing requirements on multipoint transmission, which makes it impossible to define a single generic reliable multicast protocol that fits all applications. It may therefore happen that multiple pro-tocols are standardized by the IETF, or that one generic protocol is standardized on top of which additional functionality can be layered. There is a special interest group in the IETF working on the standardization of reliable multicast protocols [Mank96]. The scalable reliable multicast (SRM) protocol proposed by Van Jacobson and others [Floy96] is a promising candi-date for standardization.

The Internet in its current form offers a single transport service, which is the best-effort delivery of an IP datagram. The network does not allow to specify QoS parameters for the delivery of packets, it does not allow to reserve resources for packet streams, and it does not support admission control. IP networks are based on the assumption that most of the traffic is point-to-point and connection-oriented. This allows to implement congestion avoidance and control in the transport protocol, rather than in the network. Connectionless multimedia traffic on the other hand poses a problem for the Internet. The source of a high-volume stream of UDP packets is not aware of the congestion that its packets may cause in network nodes, and is therefore unable to adapt the data rate it generates to the actual network load. There are three solutions to this problem, which are congestion control on application level, resource

reserva-tion together with admission control, and overprovisioning of network resources. Congesreserva-tion control on application level can be done by more centralized applications that have control over both senders and receivers. Such an application monitors the transmission characteristics of its streams and throttles senders when it realizes that the network is congested. However, congestion control on application level is not a viable solution because it cannot be enforced that every application implements it. As to resource reservation, the IETF is working on RSVP, which is a resource reservation protocol for the Internet [Zhan93]. It will still take a couple of years until RSVP is widely deployed on the Internet, making overprovisioning the only solu-tion that is at hand today. However, overprovisioning becomes expensive as the number of users grows, as is for instance shown by Scott Shenker [Shen95]. It is therefore impossible to renounce on reserve reservation in the long run.

APMT can be deployed on the Internet or on enterprise networks that are based on IP. The MMC applications running on top of APMT do not necessarily require high-speed networks for data transmission among terminals. The APMT platform may for instance support modern low-bitrate audio and video codecs that make it possible to transmit a bidirectional audio and video stream over a 28.8 kbit/s modem line. What is more likely to be a problem is control communication, which may suffer from the high roundtrip times commonly experienced on the Internet. APMT takes this into account, and tries for instance to reduce control communication over the network as much as possible.

Deploying an MMC platform on the Internet has many advantages. The most important ones are listed in the following:

• low deployment costs: the infrastructure exists, and there is no need for any fun-damental modifications to it.

• low communication costs: the usage of the Internet is basically free, making it pos-sible to develop and deploy applications free from any commercial constraints.

• large user base: a large number of users and potential programmers can be reached via the Internet.

• joint development: the development of platform and application software can be a joint effort of many volunteers that require only little central coordination¹.

It can also be imagined that the success of an MMC platform on the Internet may justify the investments to be made for a similar platform on a telecommunications network, i.e., it may pave the way for TINA.

APMT and CORBA

APMT deploys CORBA as DPE, and tries to profit as much as possible from existing and future CORBA specifications. The approach of APMT is therefore to make the best out of CORBA, rather than developing proprietary solutions for problems whenever the respective CORBA standard is not completely satisfying. As an example, APMT adopts the object model of CORBA rather than defining its own. Once the RM-ODP object model is adopted by CORBA it will also be adopted by APMT. APMT is therefore following CORBA standardiza-tion, rather than preceding it, as does TINA. The benefit of this is again ease of deployment.

APMT can be readily implemented on today’s object request brokers, whereas TINA takes the

1. See the article "Leveraging Cyberspace" by Thomas A. Kalil for examples of problems that were solved by a large number of networked users [Kali96].

position that CORBA is not completely acceptable in its present state. CORBA profits from TINA input, but TINA does not profit from CORBA as much as it could if it were ready to adopt other CORBA standards than just the basic object request broker.