14.3 Integration of Components with Architecture

  Previous section   Next section

Many current technologies, including CORBA, DCOM (Distributed Component Object Model), and Java RMI (Remote Method Invocation), can provide a de facto standard for local and distributed object communication (Baker 1998; Mowbray and Ruh 1997; OMG 1999; Rine and Retnadhas 1980; Rine and Ahmed 1997; Trevor et al. 1994). For these tools to be useful, the component implementations must be prepared to conform to the de facto standard imposed by the environment. These technologies provide client/server communications. However, each of these uses different incompatible styles. This simple requirement may make functionally useful commercial products impossible to use in some chosen environment.

Because interaction code for a given environment is part of the component's implementation, moving it to a different environment involves making changes to source code; changing the source code for a commercial product is generally not an option. In addition, as software components move to new environments, the underlying network often changes. Different networks offer different types of reliability and quality of service (QoS), and are managed and controlled in different ways. This heterogeneity is a source of complexity for software architects and designers of distributed applications, especially as the variety of network types and QoS options increases.

Integration can be difficult when even considering a single runtime environment and a de facto standard interaction style such as client/server (Beach 1992; Meyer 1992; White and Purtilo 1992; White 1995), particularly in the context of reuse and maintenance (Rine and Chen 1996, 1998; Rine 1997, 1998). Many problems can arise: differences in parameter ordering, differences in data types, differences in the expected interaction mechanism, and differences in the meaning or semantics of the interfaces themselves. These differences can sometimes be fixed by adapting the component source code; however, this usually leads to multiple different versions of the same component and means that the new version of the component should be retested, negating one of the benefits of reuse.

In general solving the interface problems of software components involves the study of three dimensions:

  1. Varying interface syntax

  2. Varying interface semantics

  3. Varying interface pragmatics

The problems addressed in this research include the varying mismatches between the interfaces of different software components.

Network performance is characterized by various QoS parameters, such as bandwidth, reliability, and end-to-end delivery delay. Different networks offer different QoS service levels, such as best effort, controlled, and guaranteed (Zhang 1996). Best-effort service networks do not provide applications assurance that a particular QoS request will be satisfied, but rather are engineered to deliver the best possible performance. An example of a best-effort network is the current Internet, which at times experiences significant levels of congestion and poor performance. Controlled and guaranteed service networks provide assured performance levels through combinations of admission control tests, traffic-policing mechanisms and packet-scheduling policies. Examples of these types of networks include the future-generation Internet proposals (Bradshaw 1997) and some types of ATM networks (ATM 1996).

Distributed applications must use different service networks in different ways. In a best-effort network, an application simply sends data using network send primitives. In controlled and guaranteed architectures, the application must specify a variety of desired QoS parameters before data are sent (Bradshaw 1997; Zhang 1996). Further, because of admission control and QoS restrictions, the network itself may reject or seek to modify the request. In order for applications to take advantage of these options, the networks' semantic differences must be reflected back through to the distributed application (Ahlgren et al. 1998; Clark and Tennenhouse 1990). By moving this management complexity into interface adapters, components can take advantage of entirely different network architectures without needing to have their code modified.

An example of the need for this type of control arises from a distributed educational software and course presentation system (Pullen 1998). An instructor uses distributed instructional software for slide presentations and real-time annotations. A possible scenario is to connect to a remote classroom by a high-bandwidth guaranteed service network capable of transporting two-way audio and video. At the same time, a student may be participating from home over a slow modem connection and a student may have a wireless mobile laptop. These two students have sufficient network connectivity for audio and slide only presentations. Further, the underlying network architectures supporting the remote classroom, the at-home student, and the student with the wireless unit are completely different from each other. It is desirable to support all three types of network connectivity without having to change the instructional software. This is possible by placing communication control in the appropriate adapters. This technical approach is being used at George Mason University, using the NEW distance education tools kit invented by Pullen, to teach distributed/distance education information technology and engineering courses.


Part IV: Applications of XML