scispace - formally typeset
Search or ask a question

Showing papers on "Common Component Architecture published in 1998"


Proceedings ArticleDOI
04 Mar 1998
TL;DR: SOFA and DCUP provide a small set of well scaling orthogonal abstractions which address three areas: the background for electronic commerce, the component model, and support for dynamic component updating in running applications.
Abstract: In this paper the authors address some of the challenges of the current technologies in the area of component-based programming and automated software downloading. These challenges include: component updating at runtime of affected applications, adopting the "true-push" model in order to allow for silent software modification (e.g., for removing minor implementation errors), and finding a way to integrate these technologies and electronic commerce in software components. To respond to these challenges, the SOFA (SOFtware Appliances) architecture, the SOFA component model and its extension, DCUP (Dynamic Component UPdating), are introduced. SOFA and DCUP provide a small set of well scaling orthogonal abstractions (easily mapped to Java and CORBA) which address three areas: the background for electronic commerce, the component model, and support for dynamic component updating in running applications. The updating granularity can scale anything from minor implementation changes to a major reconfiguration.

274 citations


Journal ArticleDOI
TL;DR: The state of component software as embodied in DCPs is reviewed, which shows the two DCP market leaders are Microsoft's DCOM (or ActiveX/DCOM) and Sun's JavaBeans, but Internet and OMG component standards are emerging that will likely impact both the content and status of these two DCPs.
Abstract: Several vendors and consortia have independently developed standards that define the basic mechanics for building and interconnecting software components. Sun's JavaBeans has emerged as the leading rival to Microsoft's DCOM, supplanting the OpenDoc standard from the now defunct Component Integration Laboratories. Component software is moving from its original focus on desktop-bound compound documents to enterprise applications that include distributed server components. The backers of competing standards are racing to capture market leadership by delivering the tangible benefits of component standards via distributed component platforms-integrated development and runtime environments that isolate much of the conceptual and technical complexity involved in building component-based applications. With DCPs, businesses can assign their few highly skilled programmers to component construction and use less sophisticated developers to carry out the simpler assembly tasks. By making component standards available to the broadest possible spectrum of developers, DCPs essentially drive those standards to market. This article reviews the state of component software as embodied in DCPs. The two DCP market leaders are Microsoft's DCOM (or ActiveX/DCOM) and Sun's JavaBeans. However, Internet and OMG component standards are emerging that will likely impact both the content and status of these two DCPs. The article also discusses component frameworks, which extend DCPs to provide more complete application development solutions.

86 citations


Patent
17 Sep 1998
TL;DR: In this article, the authors proposed a method and system to detect and correct an out-of-date component by creating several components to detecting and correcting an out of date component, and each component involved will act upon one of the situations to determine if a build should be done.
Abstract: The method and system of the present invention solves the problems of the prior art by creating several components to detect and correct an out of date component. A component is considered out of date if one of the constituent files is newer than the components. At that point a build of the component is in order. A component dependent on another is considered out of date if the public interfaces to the component change. The interfaces of the dependent component do not necessarily have to be used by the component in question to affect the build situation. A component is considered up to date if all constituent files have a time stamp earlier than the component and no dependent components have changed their interfaces. Each of the components involved will act upon one of the situations to determine if a build should be done.

73 citations


Proceedings ArticleDOI
01 Nov 1998
TL;DR: This paper uses the experience in modeling the High Level Architecture for Distributed Simulation to show how one can capture the structured protocol inherent in an integration standard as a formal architectural model that can be analyzed to detect anomalies, race conditions, and deadlocks.
Abstract: An increasingly important trend in the engineering of complex systems is the design of component integration standards. Such standards define rules of interaction and shared communication infrastructure that permit composition of systems out of independently-developed parts. A problem with these standards is that it is often difficult to understand exactly what they require and provide, and to analyze them in order to understand their deeper properties. In this paper we use our experience in modeling the High Level Architecture (HLA) for Distributed Simulation to show how one can capture the structured protocol inherent in an integration standard as a formal architectural model that can be analyzed to detect anomalies, race conditions, and deadlocks.

69 citations


Journal ArticleDOI
Jeff Sutherland1
TL;DR: This paper is a retrospective view on key conceptual issues driving the standardization of a Business Object Component Architecture (BOCA) within the Object Management Group (OMG).
Abstract: Object technology, a necessary but not sufficient condition for software reuse, requires an infrastructure that supports plug compatible Business Object Components for fast and flexible delivery of new or enhanced products to the marketplace. This paper is a retrospective view on key conceptual issues driving the standardization of a Business Object Component Architecture (BOCA) within the Object Management Group (OMG). The seamless integration of BOCA with the Unified Modeling Language (UML), a standardized Meta-Object Facility (MOF), and an emerging CORBA Component specification is essential to design-driven generation of runtime components into heterogeneous distributed object frameworks. BOCA standardization can enhance software productivity with plug compatible, reusable components, the holy grail of object computing.

62 citations


01 Jan 1998
TL;DR: The issues and challenges surrounding component adaptation are described and various approaches in the literature are evaluated by comparing their use in adapting an existing component in a sample application to lead to a better understanding of the similarities andrences between existing adaptation techniques.
Abstract: Adapting existing code to include additional functionality or behavior is a common theme in software engineering. These e orts are complicated because the developer adapting the code will rarely be the designer of the code. As object-oriented and component-based software development achieve greater widespread use, there will be a distinct need to support such third-party adaptation. This paper describes the issues and challenges surrounding component adaptation and surveys various approaches in the literature. We evaluate these adaptation techniques by comparing their use in adapting an existing component in a sample application. Our experience leads us to a better understanding of the similarities and di erences between existing adaptation techniques.

57 citations


Journal ArticleDOI
01 Apr 1998
TL;DR: This survey of the theory and design of component based software illustrates their use and utility with a prototype system for manipulating and solving large, sparse systems of equations.
Abstract: Component programming models offer rapid construction for complex distributed applications, without recompiling and relinking code. This survey of the theory and design of component based software illustrates their use and utility with a prototype system for manipulating and solving large, sparse systems of equations.

51 citations


Proceedings Article
01 Jul 1998
TL;DR: Object−oriented programming hasn't created a viable software component industry because of an insufficient consideration of the unique requirements of component software.
Abstract: Object−oriented programming hasn't created a viable software component industry. From a technical perspective, the reason for this failure lies in an insufficient consideration of the unique requirements of component software. Object−oriented programming too often concentrates on individual objects, instead of whole collections of objects, i.e., components. Component−oriented programming requires more stringent information hiding, a more dynamic approach, and better safety properties than object−oriented programming.

48 citations


Journal ArticleDOI
TL;DR: The author asserts that Boca provides a solution to the challenge of segregating core business information from the technological specifics of its home system while allowing different applications to exchange data across the enterprise.
Abstract: The Common Business Object Framework aims at coming up with a set of system-level abstractions and interoperability standards to simplify and standardize business systems development The author asserts that Boca provides a solution to the challenge of segregating core business information from the technological specifics of its home system while allowing different applications to exchange data across the enterprise

37 citations


Patent
20 Nov 1998
TL;DR: The inventive component data structure as discussed by the authors provides a complete definition of a component including its identity, state, behavior, and containment of other components, which are recursively nested instances of the inventive component.
Abstract: An object-oriented component data structure and method for constructing, extending, assembling, and modifying software components. The inventive component data structure provides a complete definition of a component including its identity, state, behavior, and containment of other components, which are recursively nested instances of the inventive component data structure. The inventive component data structure supports inheritance, such that the definition of a component inherits from the definition of another component; contained component data structures likewise support inheritance. Moreover, the inventive component data structure and resulting software components are compatible with the Java Virtual Machine (JVM), Java Class File, Java Byte Code, JavaBean, and CORBA specifications. The inventive component data structure and method are particularly well suited for providing tools for software development, trouble-shooting, and systems integration. Furthermore, the inventive component data structure minimizes the need for manual changes with respect to customized and localized software components when component revisions are made.

27 citations


Journal ArticleDOI
01 Mar 1998
TL;DR: This article provides a strategic comparison of the two major competing component software standards: COM and CORBA/JavaBeans.
Abstract: Component software addresses the fundamental requirement that software systems need to be composed from components. Potentially, each component can evolve on its own as a product. Composition may be static, much in the sense of traditional product assembly, but could just as well be dynamic. Dynamic assembly is even required in the increasingly important case of content-oriented solutions. In all cases the effectiveness of a component approach will rest on the degree of standardization achieved in a specific domain. This article provides a strategic comparison of the two major competing component software standards: COM and CORBA/JavaBeans.

Patent
23 Feb 1998
TL;DR: An extensible and replaceable network-oriented component system as mentioned in this paper provides a platform for developing network navigation components that operate on a variety of hardware and software computer systems, which assist users in navigating from information locations quickly and accurately.
Abstract: An extensible and replaceable network-oriented component system provides a platform for developing network navigation components that operate on a variety of hardware and software computer systems. These navigation components assist users in navigating from information locations quickly and accurately. Also, these navigation components may be modified or replaced with new navigation components for embedding various types of information therein. Communication among these components is achieved through novel application programming interfaces (APIs) to facilitate integration with an underlying software component architecture. Such a highly-modular cooperating layered-arrangement between the network component system and the component architecture allows any existing component to be replaced, and allows new components to be added, without affecting operation of the network component system.

Journal ArticleDOI
TL;DR: Based on the well-known pipe-and-filter architecture, DFC has been refined for use in the telecommunication domain and the authors point to ways this approach might work in other domains, including data networks.
Abstract: This article discusses a domain-specific component-based architecture called distributed feature composition. Based on the well-known pipe-and-filter architecture, DFC has been refined for use in the telecommunication domain. The authors also point to ways this approach might work in other domains, including data networks.

Book ChapterDOI
20 Jul 1998
TL;DR: The aim of component technology is the replacement of large monolithic applications with sets of smaller components whose particular functionality and interoperation can be adapted to users’ needs, but there is no support for dynamic component adaptation.
Abstract: The aim of component technology is the replacement of large monolithic applications with sets of smaller components whose particular functionality and interoperation can be adapted to users’ needs. However, the adaptation mechanisms of component software are still limited. Current proposals concentrate on adaptations that can be achieved either at compile time or at link time ([1], [2]). There is no support for dynamic component adaptation, i.e. unanticipated, incremental modifications of a component system at run-time. This is especially regrettable since systems that must always be operational would profit most from the ability to be structured into small interchangeable components that could evolve independently and whose functionality could be adapted dynamically.

Proceedings ArticleDOI
S. Sitharama Iyengar1
03 Nov 1998
TL;DR: An architecture for a universal object repository for enterprise metadata management that conforms to two key principles: Integration with distributed object/component architectures such as Common Object Request Broker Architecture (CORBA), Enterprise Java Beans (EJB) and Component Object Model (COM).
Abstract: This paper proposes an architecture for a universal object repository for enterprise metadata management that conforms to two key principles: Integration with distributed object/component architectures such as Common Object Request Broker Architecture (CORBA), Enterprise Java Beans (EJB) and Component Object Model (COM). Integration with metamodeling architectures and modeling standards defined in the object management group (OMG) meta object facility (MOF) and unified modeling language (UML) specifications. A summary of industry experience in integrating distributed objects and modeling technologies is also provided.

01 Jan 1998
TL;DR: It is shown that architecture theories can be used to adapt and combine retrieved components to satisfy a problem specification and several methods for controlling the selection of architectures during adaptation are developed based on the results of component retrieval.
Abstract: This work describes the use of formal specifications to assist and automate a system design process based on reusable components and architectures. Specifically, we focus on automated support for two reuse-related component-based design activities: (1) identification and retrieval of library components pertinent to the problem at hand, and (2) identification and application of structures for architectures) available for adapting these components. Formally verifying that a logical relationship holds between two specifications (a.k.a. specification matching (134)) to determine component reusability can be carried out using automated theorem proving. However, attempting specification matching over a large library of components is not a practical retrieval mechanism. To make specification matching efficient, it must be restricted to a small subset of the database. We have developed a heuristic for determining this subset of components based on the semantics provided by formal component interface specifications. A feature-based indexing scheme is used to classify components and allow efficient retrieval. A set of domain dependent classification rules state logical conditions defining when a component should be assigned specific features. If one of these conditions can be inferred from the component specification then the component is assigned the appropriate feature. We provide a formal argument that this method of classification ie appropriate for determining component reusability. We empirically evaluate the retrieval performance of an implementation of this mechanism over a library of 63 list manipulation components. The results indicate that the method performs as well as other specification-based retrieval systems, but with a faster response time. In most cases, component retrieval will not locate a component that completely satisfies a problem specification; solving a problem will require a component to be adapted or multiple components to be combined. We propose to use a formal model of software architecture, architecture theories, to automate component adaptation and composition. An architecture theory constrains the behavior of a system in terms of the behavior of its subcomponents via a collection of axioms. This relationship is specified declaratively, abstracting away implementation and focusing on the relationship between the system and component specifications. We show that architecture theories can be used to adapt and combine retrieved components to satisfy a problem specification. We develop several methods for controlling the selection of architectures during adaptation based on the results of component retrieval. The adaptation system is evaluated by constructing and adapting variations of the KWIC problem from the Model Problems in Software Architecture Archive and the JPEG compression algorithm.

Proceedings ArticleDOI
J.-L. Bakker1, H.J. Batteram
03 Nov 1998
TL;DR: This work applies the DSC framework, which supports component oriented distributed communication architecture such as TINA, to a TINA based service and network architecture called MESH (Multimedia Services an the Electronic Super Highway).
Abstract: We present our experiences with the DSC (Distributed Software Component) framework and development environment. The DSC framework supports component oriented distributed communication architecture such as TINA (Telecommunications Information Network Architecture). Within the component development environment, components can be developed and evaluated. Software components are self-contained packages of code that can be dynamically linked into a program. Operational interfaces cater for the external functionality of the component. The DSC can support both dynamic and static operational interfaces. Also, there can exist multiple instances of the same operational interface. Furthermore, components can be grouped together to form compound components. Through a common control and configuration interface the components can be configured with regard to events, properties, operational interfaces life cycle, and composition. We apply this framework to a TINA based service and network architecture called MESH (Multimedia Services an the Electronic Super Highway). An example is provided; a shared white board service is created using the DSC framework. The shared white board service can be used in multimedia conferencing applications.

Proceedings ArticleDOI
19 Aug 1998
TL;DR: An approach to cross-platform and cross-language object-oriented distributed software development through distributed component integration based on CORBA is presented and a distributed component model is developed to facilitate easy information retrieval at integration time.
Abstract: Component-based software development would allow application software to be largely constructed from existing software components. However, it faces many barriers in component integration, including programming languages, operating systems, communication mechanism, interface, etc. In this paper, an approach to cross-platform and cross-language object-oriented distributed software development through distributed component integration based on CORBA is presented. A distributed component model is developed to facilitate easy information retrieval at integration time. By dynamically generating adapters for distributed components using an integration tool, the component connecting process can be transparent to both component developers and software developers for integration. Group adapters are also developed for replicated component groups to automatically maintain state consistency and active group membership and provide fault-tolerance features in the resulting application software.


Proceedings ArticleDOI
20 Mar 1998
TL;DR: The work presented in this paper describes a specific technique for instrumenting components in a distributed system and constructs a wrapper around the component being measured that mimics the interface of the component that it is wrapping.
Abstract: The Common Object Request Broker Architecture (CORBA) supports the creation of distributed systems that cross processor, language and paradigm boundaries. These systems can be large and complex entities that consume considerable resources in their creation and execution. Measurements of characteristics of software systems is an important area of study in general and of particular interest for distributed systems. The work presented in this paper describes a specific technique for instrumenting components in a distributed system. The technique constructs a wrapper around the component being measured. Interactions with the ORB and other components are monitored and summarized. Each wrapper mimics the interface of the component that it is wrapping so that the remaining objects in the system do not need modification. Two approaches to wrapping the component are presented and contrasted. The result is an efficient and modular technique that can quickly be applied to a component.

01 Jan 1998
TL;DR: This work describes a component-based software architecture and its supporting CASE tool, and the application of this tool to the development of component- based design environments, focusing on visualisations developed when specifying a process modelling tool.
Abstract: Component-based software architectures are increasingly being adopted as solutions for various software engineering problems. We describe a component-based software architecture and its supporting CASE tool we have been developing. Our tool supports both static and dynamic visualisation of component-based systems, together with end-user configuration of such systems by user extension of these visualisations. We describe the application of this tool to the development of component-based design environments, focusing on visualisations developed when specifying a process modelling tool.

Proceedings ArticleDOI
M. Yasuda1, Katsuhiko Seo, Hisao Koizumi, Barry Shackleford, F. Suzuki 
10 Feb 1998
TL;DR: A top-down hardware/software co-simulation method for embedded systems is proposed and a component logical bus architecture is introduced as an interface between software components and hardware components.
Abstract: We propose a top-down hardware/software co-simulation method for embedded systems and introduce a component logical bus architecture as an interface between software components and hardware components. Co-simulation using a component logical bus architecture is possible in the same environment from the stage at which the processor is not yet determined to the stage at which the processor is modeled in register transfer language. A model whose design is based on a component logical bus architecture is replaceable and reusable. By combining such replaceable models, it is possible to quickly realize seamless co-simulation. We further describe experimental results of our approach.

Proceedings ArticleDOI
01 Nov 1998
TL;DR: Issues arising from the initial effort in this research are discussed, where the JavaBeans component model is extended to support component composition according to the C2 architectural style.
Abstract: 1. ABSTRACT Components have increasingly become the unit of development of software. In industry, there has been considerable work in the development of component interoperability models, such as ActiveX, CORBA and JavaBeans. In academia, there has been intensive research in developing a notion of software architecture. Our research involves studying how standard component models can be extended to accommodate important issues of architecture, including a notion of architectural style and support for explicit connectors. In this paper, we discuss issues arising from our initial effort in this research, where we have extended the JavaBeans component model to support component composition according to the C2 architectural style. 1.1

01 Oct 1998
TL;DR: A generic, Java-based component architecture is proposed as a basis for designing the agents used within multi-agent systems to facilitate code reuse and simplify agent construction, by building up a pool of components which can be easily combined to produce agents with different capabilities.
Abstract: A generic, Java-based component architecture (JAF) is proposed as a basis for designing the agents used within multi-agent systems. The goal of this design is to facilitate code reuse and simplify agent construction, by building up a pool of components which can be easily combined in different ways to produce agents with different capabilities. JAF builds upon general component models by adding additional implementation and runtime support designed to produce more consistent and cohesive components. The architecture, based on Sun''s Java Beans, is explored, and both domain independent and applied component examples are described in detail.

Journal ArticleDOI
TL;DR: The architecture presented in this article builds connection mechanisms into the components, which facilitates composition and the construction of flexible, scalable systems.
Abstract: To deploy large-scale, interactive, distributed systems, we need architectures that support integration of new and existing components and allow dynamic configuration of component connections. The architecture presented in this article builds connection mechanisms into the components, which facilitates composition and the construction of flexible, scalable systems.

08 Jun 1998
TL;DR: This work proposes to extend the Java type system with a new construction: compound types, compositions of a class and any number of interfaces, applicable to several other languages than Java, as well.
Abstract: We propose to extend the Java type system with a new construction: compound types, compositions of a class and any number of interfaces. Java users will benefit from the type system''s increased expressiveness, resulting in more kinds of errors being statically excludable. Compound types are particularly beneficial when several independently predefined standards need to be considered, as typically required by component software. Compound types are a strict extension of Java, i.e., existing programs need not to be modified. Our proposal can be implemented using the existing Java Virtual Machine. Our scientific contribution is a new combination of name and structural type equivcalence, which our Java extension exemplifies. Type matching is decided by structural comparison of compositions of named types; the latter being only compatible if explicitly declared so. This concept is applicable to several other languages than Java, as well. We support the feasibility of our proposal by a formal and mechanically verified proof of the extended type system''s soundness.

Journal ArticleDOI
01 Feb 1998
TL;DR: It is concluded that, in order to successfully model the business domain, component models such as CORBA need to be integrated into a component-based application development process which takes account of a broader context such as that provided by RM-ODP.
Abstract: As a means of maximising reuse, component-based application development is a laudable objective. CORBA is an influential component model already adopted by the computing industry. The nature of a typical CORBA development process is examined. There is a discussion of the requirements for a more complete component-based application development method, and focus on the shortcomings encountered when applying CORBA outside such a framework. The ISO RM-ODP standard is introduced, its relevance is highlighted, and the issue of reuse in relation to both CORBA and RM-ODP is reviewed. It is concluded that, in order to successfully model the business domain, component models such as CORBA need to be integrated into a component-based application development process which takes account of a broader context such as that provided by RM-ODP.

Book ChapterDOI
24 Sep 1998
TL;DR: Implementation of the system based on this component level decomposition offers many advantages in terms of re-use, system maintenance and general support for change.
Abstract: Information Technology (IT) systems can generally be described through subdivision into components whose level of abstraction allows the people who are involved with their creation and maintenance to better understand the system. However, this component sub division seldom exists beyond the conceptual system description. Implementation of the system based on this component level decomposition offers many advantages in terms of re-use, system maintenance and general support for change.

Book ChapterDOI
20 Jul 1998
TL;DR: By integrating such services into the programming model for a component architecture, this work believes that it can provide a more practical and useful industrial-strength approach to the construction and deployment of component-based distributed applications.
Abstract: Currently the strongest support in industry for component-based frameworks appears with Microsoft’s component architecture (COM)[1]. However with COM it is difficult to program for evolution or adaptation. It is common for class identifiers to be bound into component structures, naming services are limited and there is no support for trading of services in distributed environments. CORBA[2] has basic support for these services in the form of a trader specification and type repositories but there is little industry adoption of these services. By integrating such services into the programming model for a component architecture we believe that we can provide a more practical and useful industrial-strength approach to the construction and deployment of component-based distributed applications.

01 Jan 1998
TL;DR: This paper presents a classification of distribution support at the level of middleware component systems, and discusses the benefits to be gained from component migration, and adapt techniques from process migration research to the problem of component migration.
Abstract: Component technology has been advocated as a means of simplifying the design and implementation of distributed applications. This paper presents a classification of distribution support at the level of middleware component systems. This classification identifies a form of distribution support, component migration, which is not supported by the component infrastructure currently available. After discussing the benefits to be gained from component migration, we adapt techniques from process migration research to the problem of component migration. Finally we identify a number of open questions that we expect our current work will address. Introduction Distributed applications have historically been difficult to build. Typically such applications are large and complex, leading to code reuse and maintenance problems. Component technology promises to simplify distributed application design by encapsulating dependencies within components. Component middleware implementations effectively separate the design of an application from the details of distribution by providing a communication mechanism to the component programmer. We present a classification of distribution support for component systems in terms of increasing application flexibility. After presenting this classification, the provision of component relocation support in existing infrastructure is considered. Emphasis is given to the adaptation of process migration techniques from the operating systems community to component systems. Distributed Applications Distributed applications are gaining popularity as they have the potential to provide greater reliability and availability than traditional centralised applications. When a module in a centralised application becomes corrupted, either through software or hardware failures, access to the entire application is lost. Alternatively, if the application were distributed across a number of machines ideally only access to the functions performed by the damaged module would be affected. Fragile or heavily used modules may be replicated in distributed applications to ensure continued availability in the face of failures ie. fault-tolerance. Such replication may also be used to increase the transaction capacity and throughput of an application by having users introduce additional module replicas to handle growth in transaction rates. This is particularly applicable to systems where the transaction loads are variable. The potential for increasing the available computing resources to an application is a key reason why distributed applications are gaining popularity. Some applications such as airline ticketing and banking systems are inherently distributed. It is conjectured that these systems are therefore easier to design, build and maintain if the distribution inherent in the problem is reflected in the resultant application. It is desirable however, to shield the application programmer from the complexities of implementing the support for distribution. Such support for distribution needs to be provided by the underlying component infrastructure. Recent popularisation of the Internet has ensured the widespread availability of long distance networking. Continued expansion of the Internet and increasing interest in networking solutions in general suggest that the number of computers connected to networks will continue to increase. Since network connectivity is the basic requirement for distribution, current indications suggest the use of distributed applications will increase in the future. Nevertheless, although the hardware infrastructure required for building distributed applications is reasonably mature, it is still unclear how we can best support these distributed applications. Distribution Support Classification Currently available component infrastructure such as CORBA [OMG98] and DCOM [Roy97] support distributed applications by providing a transparent communication mechanism between components across hosts. The locality of the components in these systems is specified prior to the execution of the application. Existing distribution support explicitly prevents the re-distribution of components after binding the component. We conjecture that distributed applications often have a relatively long execution time. It would therefore be desirable for such applications to be adaptive to changing application loads and usage patterns. Such distributed applications require the ability to re-distribute components at any time during the execution of an application. Without the provision of dynamic support for these changes it is necessary to restart the application when structural changes to the application are made. We have developed the following taxonomy to consider the possible alternatives in specifying the locality of application components: $ Static configuration With statically configured distribution, the locality of the components comprising the application is specified and fixed prior to the execution of the application. This would usually be achieved by creating a configuration file that specifies the locality of each component in the application. Alternatively, during the initial boot, the application could require the user to specify the locality of each individual component. $ Dynamic configuration (boot-time configuration) Dynamically configured distributed applications rely on the component infrastructure to determine the appropriate fixed location for each component in the application. Once the locality of a component is established it does not change for the remainder of the application’s execution. Existing systems achieve this by using “trader services”. These services allow the application to make a request of the service for a particular type of component. The trader service then performs some form of look-up for a component of the desired type and returns a reference to the appropriate component. This look-up may result in the trader instantiating a component of the required type where necessary. $ Dynamic relocation (component relocation) The initial configuration of a dynamically relocatable application may be specified by either of the preceding methods (or a combination of both). Unlike the previous methods, this form of locality specification is not fixed for the duration of the application execution. This means that the location of a component may be altered at run-time thereby allowing the application to take advantage of changing system loads and adapt to varying application use. Dynamic Distribution Support As stated earlier, existing component systems, such as DCOM and CORBA, are sufficient to support statically distributed component-based applications. That is, these systems support applications whose distribution structure is configured prior to execution, with the application’s structure remaining static over the entire execution time of the application. In our classification this form of distribution support is identified as static configuration. The addition of a trader service to the existing component systems introduces support for dynamic configuration of distributed applications. With this type of distribution configuration the application makes a request of a well-known service for a component that meets some specified criteria. On receiving the request, the trader locates an instance of an appropriate component returning a component reference to the application — thereby binding the application to the component. Depending on the criteria specified and the state of the component system a trader may act to create an instance of the required component in order to service the request. This form of distribution support is referred to as dynamic configuration in our classification and is provided in existing component systems by the Object Trading Service from the CORBAServices for CORBA [OMG97]. Clearly each of these options requires an increased level of support from the underlying component framework. Statically configured applications require support to instantiate components on remote hosts according to a specified locality configuration. For dynamically configured applications the framework must support some way of algorithmically determining the best location for each component. This determination may be based on the load of individual hosts in the system, known behaviour of the application (from previous executions/modelling) and the existence of other instances of the required component already in the system. The third category in our classification, dynamic relocation, requires the component infrastructure to support some form of component migration. At present, it is not clear what form such support will take in the component system. We expect however, that component relocation will be amicable to techniques applied to process migration technology in previous research [RicH97, Ric96]. Component Migration We define component migration as the movement of an instance of a component from one host in the system to another. Component migration may be used to improve the performance and flexibility of an application in a number of areas. For example: $ Application load balancing In a distributed application the transaction load on given components and hosts often vary significantly. In such cases a component may be migrated from a host with a relatively high load to one under a lower load to improve the performance of the application. The movement of a highly loaded component to a host with a lower load additionally may improve the system performance as a whole. $ Application restructuring The usage pattern and processing load experienced by a distributed application is likely to change over the lifetime of an execution instance. For many distributed applications it may be preferable to restructure the application to reflect these changes without halting the execution of the application. Possible changes to the structure of a distributed application include those resulting from th