Distributed object computing (DOC) middleware, even if commonly used, has several drawbacks to support large and complex distributed applications: no visibility of distributed object interconnections, no implementation separation between business logic and system services, and no application deployment process. In response to this, DOC middleware is evolving to distributed component computing (DCC) middleware such as the Enterprise Java Beans and the CORBA Component Model (CCM). Such middleware provides new solutions to exhibit component interconnections, to separate functional and non-functional aspects, and to deploy components. However, this new middleware generation does not allow applications to have a fine-grain control on their deployment process, i.e. the deployment process is hard-coded into DCC middleware and applications cannot adapt it to their requirements. In the context of the CCM, this paper promotes a flexible deployment process supported by a dynamic CORBA Component platform. This platform is composed of an OMG IDL compiler, generic container servers, and our CorbaScript engine (basis and first implementation of the OMG IDLscript specification). It allows software architects to dynamically drive the deployment of their distributed components, as well as to be reactive to their evolutions.

Nowadays, Autonomous Distributed Systems, such as large-scaled telecom and manufacturing applications, rely on the use of middleware. In order to find back resources and to interconnect applications, the middleware has to provide a trading function. Unfortunately, standard traders such as the ODP/OMG CosTrading service, are error-prone due to the lack of type checking at compilation time, but only performed at runtime. In order to address this problem, we have defined the Trader Oriented Request Broker Architecture (TORBA) to provide a trading framework and its associated tools, which tend to offer type-safe trading operations that are simple to use from applications and checked at compilation time. Based on the concept of Trading Contracts, a resource is described using the TORBA Definition Language, and then compiled to generate trading proxies offering simple interfaces to applications. The example used in this paper clearly states the benefits brought by the TDL trading contracts: type checking at compilation time, simple to use, and providing a powerful and reliable framework for CORBA object trading.

Trading is a key function in the context of distributed applications: It allows runtime discovering of available resources. In order to standardize this function, the Open Distributed Processing (ODP) and Object Management Group (OMG) have speci ed a trading service for CORBA objects: The CosTrading. This speci cation has two main drawbacks: First, this service is complex to use from applications and second, it does not oer type checking of trading requests at compilation time. Both are discussed in this paper. The main goal of our Trader Oriented Request Broker Architecture (TORBA) is to provide a trading framework and its associated tools, which tend to oer typed trading operations that are simple to use from applications and checked at compilation time. In that, we de ne the concept of Trading Contracts, written with the TORBA De nition Language (TDL). Such contracts are then compiled to generate trading proxies oering simpleto -use interfaces. These interfaces completely hide the complexity of the ODP/OMG CosTrading APIs. In the meantime, TDL contracts could be dynamically used through a generic graphical console exploiting a contract repository. The example used in this paper, clearly states the advantages brought by the TDL trading contracts: type checking at compilation time, simple to use, and providing a powerful framework for CORBA object trading.

Building component-based distributed applications is a complex task involving a set of cooperating actors like architects, developers, transactions or persistency specialists. For more than ten years, the Object Management Group (OMG) defines open standards to build interoperable distributed applications. First, the Common Object Request Broker Architecture (CORBA) introduced interoperability between heterogeneous distributed objects: An object oriented middleware. Now, the Model Driven Architecture (MDA) introduces interoperability between heterogeneous models: A model oriented middleware. In this context, we advocate the separation of concerns in order to structure the modeling and meta modeling of enterprise distributed component architectures. In the meantime, design related knowledge is most often lost at runtime. Nevertheless, this knowledge could be important to reify architectures of applications at runtime and to support their administration and reconfiguration. Thus, we intend to support separation of concerns from design to runtime of applications, using a meta data repository centric approach. This paper discusses our proposal, CODeX, to structure the definition of meta models in order to offer dedicated points of view of a model to each of the actors of the software engineering process, from architects to application administrators.

Abstract — This work presents an infrastructure that simplifies the development of distributed applications that can adapt automatically to nonfunctional properties of their components and of their execution environment. This infrastructure, based on the programming language Lua and on CORBA, allows applications to select dynamically the components that best suit their requirements, to verify whether the system is satisfying these requirements, and to react, when appropriate, to variations in the nonfunctional properties of the services in use. We use CORBA’s Trading Service to support dynamic component selection. An extensible monitoring facility supports monitoring of dynamically defined requirements. We use the Lua language to specify adaptation strategies, and a smart proxy mechanism to apply these strategies. The paper also describes a programming example based on the proposed infrastructure. Keywords—dynamic adaptation, distributed auto-adaptive systems, middleware, CORBA, component-based applications, nonfunctional requirements.

Abstract not found

Abstract not found