The qualitative requirements imposed on the platform architecture are defined as a set of prop-erties. The platform must be
• open
• extensible
• programmable
• scalable
• deployable
• simple
These properties have all a very concrete impact on the shape the platform has to take. The following provides a discussion of the required platform properties along with their implica-tions.
2.3.1 Open
An MMC platform architecture has to be open, meaning that its interfaces and computational behavior are well-defined and published in form of a standard. Clients that conform to the stan-dardized mode of interaction with the platform can access its services. The three principal types of platform clients that can be identified are the user, the platform provider and the ser-vice provider that develops and deploys applications. The MMC platform must have open interfaces wherever client interests meet, most importantly between the user terminal and the platform, between the platform and the application, and between parts of the distributed plat-form that are under different administration. In addition to that, platplat-form extension must be open, requiring that internal platform interfaces have to be standardized.
Openness is directly linked with standardization. The standardization of an MMC platform has to be in the hand of a single organism upon which all interested parties agree. The stan-dardization must come up with a globally accepted architectural framework that, while defin-ing all important interfaces, leaves considerable room for competition. Important areas of competition are applications and platform extensions. The MMC platform architecture must make maximum use of existing standards and concentrate on architectural issues. Relevant standards are for instance multimedia data encoding and transmission standards, or control middleware standards, but it can also be envisaged that the platform encapsulates existing sys-tems similar to the way the Web provided access to Gopher [Liu94].
As the computational interactions among platform components are likely to be complex there is a need for formal methods in the definition of the interfaces that reduce the ambiguity plain text often exhibits. The application of formal specification methods should nevertheless be done with moderation, and care should be taken to keep interaction complexity at a level that can be handled with a limited amount of specification.
Openness fosters application development and is a necessary condition for ubiquity.
2.3.2 Extensible
An MMC platform has to be extensible if it is to be long-lived. Extension should be possible on architecture level and on component level. New components that are built on top of plat-form extension interfaces may become part of the platplat-form following a light-weight standard-ization process. It can also be envisaged that new components are introduced without any standardization, with their integration into the platform being linked with the success of appli-cations that are using them. Apart from extension on component level it must also be possible to extend the architecture itself as new developments in MMC demand this. The key to this second kind of extensibility is modularity. Low-level platform components have to be grouped into modules that can be added to and removed from the platform without affecting the plat-form as a whole. This allows to adapt the platplat-form to the needs of new application classes, or to simply improve existing modules. Different versions of the same module may coexist, with older versions being removed as the applications that are using them become obsolete or are ported to the new versions. The advantage of this is that the size of the platform may remain manageable over time. The phenomenon that will be observed after the platform has been in use for some years is that the platform is mutating rather than growing. It is clearly more desir-able to have a platform that is mutdesir-able than a new platform every once in a while. An example for platforms that are not mutable are today’s monolithic operating systems. Considerations similar to the ones presented here led to the development of modular micro-kernel operating systems like Chorus [Rozi91] that are able to go with the times.
2.3.3 Programmable
Programming on top of the platform, be it for applications or platform extensions, must be comfortable. Most importantly, the platform must help the application developer in dealing with the problems that arise out of distribution, providing for instance solutions for location transparency, partial failure and concurrency. The platform must also provide an application model, i.e., an explicit programming paradigm that guides application design and develop-ment. An application model allows the development of a standard proceeding for application design, and helps structuring application code. A good application model may further lay the ground for a compiler that generates application skeletons based on formal application descrip-tions. Tools like an application compiler help automatizing the application development pro-cess and hide the complexities of low level application programming interfaces. A platform should provide the possibility to program on toolkit level while leaving the door open for low-level programming. This allows application developers to rapidly include standard functional-ity and to concentrate on the features that distinguish their application from others. Standard functionality may for instance be included in the form of active components that are orches-trated rather than programmed by the application.
MMC applications are hard to test and to debug because it is difficult to emulate the condi-tions under which they are deployed. An MMC application may for instance be exposed to the statistically combined input of a large number of users, something that is difficult to check on a test-bed. Another problem is high-speed data transfer and processing where conceptual mis-takes or programming errors are hard to trace down, especially when they are timing-related, resulting in programs that seem to work correctly when checked with a debugger, but that mis-behave when running at normal speed. An MMC platform must provide solutions for testing and debugging. A good application model already helps to structure an application, allowing to debug different application parts separately. The separate debugging of application parts is only possible if the platform services that are used by an application part can be run
indepen-dently from the rest of the platform. If this is not the case the complete platform software has to be run whenever a newly coded feature needs to be tested. There is a clear need for develop-ment platforms that allow to streamline the process of designing, impledevelop-menting and testing an MMC application. Besides that an MMC platform must be deployable on small test-beds that allow to run applications with reasonable effort in a real-world environment.
2.3.4 Scalable
A platform is scalable if it can grow without running into performance problems. The MMC platform has to scale well on several levels:
• number of platform nodes: the platform shall perform equally well when deployed on a small private network or on a large public network like the Inter-net.
• number of applications: the platform should not put any restriction on the num-ber of installed applications.
• number of platform extensions: the platform should accommodate a large num-ber of extensions. Not all extensions need to be installed on all platform nodes.
• number of platform users: the platform should be able to serve large numbers of users.
• number of concurrent platform users: the platform should allow large numbers of users to use the platform and its applications in parallel.
• number of application users: the platform should support applications having a large number of users.
• number of concurrently active applications: the platform should allow to run a large number of applications in parallel.
Scalability is a prerequisite for ubiquity. If an MMC platform cannot scale with the number of users or the number of concurrently running applications, its availability will suffer, result-ing in frustrated users. Scalability is a property that mostly concerns the platform architecture, and not so much its implementation. It is naturally desirable that a given implementation scales on many levels, but it is not required that it scales on all the levels mentioned above. There is no single implementation of the platform that can fit all possible deployment scenarios.
2.3.5 Deployable
An MMC platform must be deployable in the sense that its introduction into a network is eco-nomically feasible. An MMC platform that requires drastic changes in the network infrastruc-ture even before its initial deployment is bound to disappear in favor of a platform that makes the best out of the existing infrastructure. Once deployed such a platform may justify infra-structure changes and other investments with the appeal and usefulness of its applications. The architecture of the MMC platform must support this kind of deployment scenario by defining a small and easily deployable platform kernel that can then be extended following the lines of a partly predefined migration path. A good migration path is necessary to keep ad-hoc exten-sions from leading the platform architecture into an early dead end. Designing a platform to be deployable is a constraint that is hard to impose on a team of enthusiastic designers because it implies that technically elegant solutions cannot be considered if they are economically doubt-ful.
2.3.6 Simple
The architecture of the MMC platform must be simple in the sense that it provides a lot of functionality with a small number of concepts. Economy of concepts reduces platform com-plexity and increases usability. The platform must be simple to use, to program, to install and to maintain. People using the platform in one way or another should at no time have the impression of dealing with a complex and clumsy system.