The previous three sections developed a set of qualitative and functional requirements for MMC platforms. These requirements will be used to assess the platforms that are discussed in Chapter 4 and 5, and to evaluate the platform that is proposed by this thesis. It has to be noted that the platforms discussed in Chapter 4 and 5 will only be assessed, and not evaluated or judged. Every one of these platforms was developed on the basis of a particular set of objec-tives and requirements that needs to be taken into account when they are evaluated. There is nevertheless a sometimes significant overlap of the requirements defined for the platforms dis-cussed in Chapter 4 and 5 and those set forth by this thesis, and it is therefore possible to com-pare these platforms on the basis of single features with the MMC platform developed by this thesis.
Table 2.1 is the template for the table that will be used to summarize the assessment of every platform discussed in this thesis. The table shows in its upper part the qualitative require-ments that are defined in Section 2.3, and in its lower part the functional requirerequire-ments devel-oped in Section 2.4. The bottom of the table shows if the platform is built on top of a standard DPE. Table rows list from left to right the requirement, the assessment of the platform with respect to this requirement, and a short remark. Up to three stars (❄) are used to indicate how well a platform fulfills a given requirement. A function that is not supported is marked with an n. If a function is not in the scope of a platform it is marked with a hyphen (-). Table 2.1 shows some examples of how assessment will look like.
Figure 2.1. Possible relationships between application, MMC platform and DPE.
A B C D
Application
MMC
MMC
Application Application Application
MMC MMC
DPE DPE DPE
Network
2.7 Conclusion
This chapter first introduced a set of major aims for the MMC platform, namely ubiquity, lon-gevity, support for development and support for deployment. It is stated that an MMC platform as defined in Chapter 1 will not thrive if it does not recognize these aims as absolutely funda-mental to the design of the platform. Based on these aims a set of still qualitative platform properties was discussed. It is stated that an MMC platform has to exhibit these properties in order to conform to the previously defined major aims. The required platform properties are in turn at the basis of a broad range of required platform functionality. It is stated that the func-tionality required from the platform is too extended to be attainable with a single design and development effort. Functionality that is not MMC specific, and here especially the distributed processing environment, should therefore be provided by another platform. The following chapter looks at different technologies for the DPE of the MMC platform.
Platform Name
Requirement Fulfilled Remark
Open ❄ ❄ ❄ emphasis on standards
Extensible ❄ ❄ fairly well extensible
Programmable ❄ limited support for application programming Scalable no the platform architecture is not scalable Deployable
Simple
Session Management ❄ ❄ ❄ extensive session management functionality
Connection Management ❄ ❄ some remarkable connection management functionality Multimedia Data Processing ❄ limited support for multimedia data processing Multipoint Control Comm. no no support for multipoint control communication Resource Management - not in the scope of the platform
Synchronization Mobile Code
Presentation Environment Federation of Applications Security
Mobility Directory Service Platform Management Accounting
Standard DPE
Table 2.1. The platform evaluation table.
3.1 Introduction
The previous chapter presented a comprehensive list of requirements an MMC platform has to fulfill. A principal requirement is that the MMC platform must be built on top of a distributed computing platform that makes the network transparent for control communication. Such a platform helps overcoming the problems that distributed applications are faced with, and offers communication services that ease the life of application developers. It would be an enormous task to build an MMC platform offering all the functionality described in the previous chapter without a distributed computing platform at the base. The distributed computing platform pro-vides services beyond basic control communication, as for instance a name service, a security service, or a distributed file service. These support services are likely to be built on top of the same control communication services that are offered to applications. Given that the distrib-uted computing platform offers more than just basic control communication, it makes sense to refer to it as a Distributed Processing Environment (DPE). Another reason for choosing this denomination is its use in the context of Intelligent Networks and TINA where it takes the same architectural role.
Platforms for distributed computing have been based on messages in the 1970s, on remote procedure calls in the 1980s, and on objects since the beginning of this decade [Wald94]. A prime objective of such platforms is to hide the network programming interface1 from the application, and to provide support for the design and implementation of application-level pro-tocols. There is no more need to design, verify, implement and test one or more message-based protocols for every distributed application. With remote procedure calls, an application-level protocol is based on a single request/reply protocol that is implemented by a combination of standard runtime libraries and automatically generated stub code. The application interfaces to the four well-known protocol service primitives invocation, indication, response and confirma-tion directly via funcconfirma-tion calls. Platforms for distributed computing are therefore linked with programming languages, which is not the case for normal message-based protocols where ser-vice interfaces are usually of secondary order. The close relation to programming languages facilitates the design and implementation of application-level protocols, but it links the lifetime of the platform with the lifetime of a programming paradigm, or even with the lifetime of a sin-gle programming language. Until now, platforms for distributed computing tend to not survive a paradigm shift in computing. This can be accepted as the price that has to be paid for increased programming comfort, but is clearly undesirable. Historically, progress in the field of distributed computing has been rather evolutionary than revolutionary. Remote procedure calls bundle two messages into a protocol. Distributed object computing bundles procedure calls into object interfaces. The upcoming component framework paradigm bundles objects into groups of cooperating objects. There is a tendency of new paradigms being layered on top of
1. Examples for network programming interfaces are the Berkeley Sockets and the Unix System V Transport Layer Interface (TLI) [Stev90].
older ones. This suggests that platforms that are organized in a modular way and that are flexi-ble enough to form an intermediate layer will have the chance to survive paradigm shifts, with the advantage that legacy applications may run on the same distributed computing platform as modern applications.
The previous chapter introduced longevity as one of the major aims for the MMC platform.
Since the DPE will be at the heart of the MMC platform it has to be just as future-proof as the MMC platform is required to be. The trend at the time of writing is clearly towards distributed object computing (DOC) [Orfa96]. It is difficult if not impossible to predict the lifetime of this paradigm, but since it is the most modern, and since it offers the most in terms of programma-bility, it is the natural choice for the DPE. The following section shows that at the moment there is only a single DOC platform that satisfies the requirements developed in the previous chapter - this is CORBA. The choice of CORBA is justified with a first quick look at possible alternatives. Following that comes a comprehensive description of CORBA with an emphasis on those features that are used by the MMC platform proposed in this thesis. It is then possible to have a closer look onto alternative distributed computing platforms and to discuss them with respect to CORBA.