1 From Distributed Objects to Distributed Components

Transcription

1 From Distributed Objects to Distributed : the Olan Approach Luc Bellissard, Michel Riveill BP 53, F Grenoble Cedex 9, FRANCE Phone: (33) Fax: (33) Luc.Bellissard@imag.fr 1 From Distributed Objects to Distributed Programming of distributed applications is now supported by multiple alternatives when considering high level distributed environments. Using a system platform for remote access to services Such a platform can be a pure distributed operating system or a distributed language runtime like Emerald[1], Argus[2], Guide[3], or a platform that integrates distribution like CORBA[4], ILU[5], Network OLE, etc. Those technologies aim at providing transparent and easy access to distributed services available on a workstation cluster, thus normalizing the way of accessing them. Such a normalization most often deals with the interface description language (IDL[6]) that statically describe services available from various objects, and the mapping of such a language with existing programming languages used for the core implementation of objects. In order to access a service, a client object must first know the identity of the server object (that really provides the desired service), the type of interface that can be dynamically accessed. Then the client object submits a request to the system platform that handles the search for the server, the execution of the request and the delivery of the results. In contrast with this rather static approach, message busses[7][8] are providers of distributed access to dynamically declared services. A client requesting a service is

2 not interested in knowing the identity of server objects. The client sends a request to the bus and handles the binding to one or many available servers. The limitation of this extremely dynamic approach is the difficulty to handle a large number of processes operating together with one single bus. Each of the above approaches has both a programming language aspect, which mostly interests the application designer, and a runtime support aspect which concerns the distributed system designer. The Olan Approach The Olan proposal[11] tries to get the best of both kind of platforms and investigates both aspects. From the programming language point of view, Olan is closer to the notion of Module Interconnection Language[9][10] than IDL, even though we have originally extended the IDL to describe the interfaces of components, which have a richer semantic than objects. This extension is the definition of required services from other components at the interface level, in order to favor reuse. Naming of components is a tradeoff between the direct naming of server objects as in an ORB, which is the most performing solution, and the service based naming of software busses, which is more flexible. In Olan, naming works at two different levels : naming by the client (resp. the server) of a required service (resp. a provided service), then binding between the requirement and the provision through an interconnection language. Such a decomposition of the naming guarantees the same performances as with an ORB if the client is connected to one server, and performances are still acceptable when the client is connected to multiple servers. In addition, each binding is a potential service request between a client and a server separately described from the implementation, thus allowing easy reconfiguration of the interconnections with no programming effort on either the client or the server sides. Besides these advantages, Olan aims at providing support to the some of the constraints that distributed application designers usually face: the reuse of existing code, ranging from libraries, parts of application or entire applications accessible through an API. Such legacy applications are usually designed and constructed independently from their execution context, with no concern about the communication with the outside, the configuration à la carte that aims towards the deployment of a distributed application on a given execution environment, and the management of the various components of the application in order to adapt the behavior of the application to the existing resources of the host environment. This feature will ease the maintenance and the evolution process of the application and the environment

3 2 Olan : Putting Distributed to Work The Olan environment may be divided into two classes of tools: Tools for the design and the programming of distributed applications, and Execution units essentially made of the runtime support that implements the Olan virtual machine. The Tools for programming rely on a component based programming model from which the Olan Configuration Language derives and visual and incremental programming tools, as well as a compiler of OCL that helps producing various configuration of applications. The Execution units rely on the Olan Virtual Machine that allows distributed components to interact over a network of workstations, thus implementing various distributed services for the remote communication, the distribution of components, the naming, the management, etc. 2.1 The Olan Configuration Language OCL is a language belonging to the class of configuration languages : this means that OCL helps producing configuration of applications by describing interconnections of ready made components and influencing their behavior at runtime, such as the conditions of their creation or deletion, their placement, protection, etc. OCL was originally considered as an extension of the IDL for the description of the interfaces of components, but a configuration language must also describe what implementation is associated to an interface in order to completely define a component. An Olan application is thus made of a set of interconnected components, some of which encapsulate existing software pieces, modules or classes written in various programming languages. Two main notions are the basis of OCL: components and connectors. Compoents are the unit of software encapsulation and distribution. are made of an interface and an implementation. The interface tells what services the component can provide to any other components, along with the services it requires at runtime. The latter feature is mostly what makes OCL differs from the IDL. The implementation tells how the interface requirements will be fulfilled, from either existing pieces of software this is a primitive implementation or an interconnection of Olan components known as composite implementation. This feature is what makes OCL similar to a Module Interconnection Language.

4 Connectors Connectors are the objects in charge of ruling the interconnection between components and handling the communication at runtime. They ensure both roles either at the language level e.g. binding of component s services follows predefined rules, like a requirement must be bound to a provision or at the execution level e.g. the communication protocol or mechanism, the transformation of the exchanged information, etc. Application Primitive Implementation Component Modules, classes, etc Interface Component Connector Primitive Component Composite Implementation Fig. 1: OCL fundamental concepts Along with components and connectors, OCL enables the description of some dynamic aspects of the execution and some management aspects of the components behavior. Three interesting features help ensuring this: The dynamic instantiation and the collections, The associative naming of interconnected components according to dynamically evolving properties, and The management attributes declared in the management interface, that drives the behavior of components, such as the placement on nodes, etc. More details about OCL and the latter features can be found in [11]. 2.2 The Olan Virtual Machine The Olan Virtual Machine may be seen as a collection of services, functions and structures that support: as units of software encapsulation, composition and configuration of interconnections,

5 Connectors, as units of binding and communication between components, Configuration, as the action of describing applications as a set of software modules, of deploying the application on the desired, possibly heterogeneous, system platform, of controlling the behavior of the applications, and finally Management of application, as the action of instrumenting, monitoring and reacting on the way the application executes on the targeted set of workstation. These four complementary functions have lead to the separation of the virtual machine into four "sub machines", which cooperate to enable the execution of distributed applications (c.f.fig. 2). Olan Virtual Machine Connector Machine Configuration Machine Component Machine Management Machine Distributed Platforms OODE / ORB (ILU) Unix (AIX, Solaris,...) NT Fig. 2: The Olan Virtual Machine Principles of the Virtual Machine An Olan application is represented within OCL as a top level component that includes a specific service enacting the application launching. At runtime, an application is instantiated as a session. The session is an active instance of an application and multiple users can simultaneously use and share components. The session is managed and represented by a unique distributed, shared and active object, the Session Configurator, which is in charge of: Creating contexts and context configurators, Directing context configurators for all configuration operations, such as the creation, deletion of components and collections, the binding of components with connectors, the arrivals/departures of users in the session, etc Providing a distributed naming service within the session, and

6 Instrumenting each context of the application for monitoring and control purposes. Context Configurators are objects obeying to the session configurator and performing any configuration operation specific to their context, a context being in the Olan terminology, an address space associated together to a session, a node and a user. OCL description Compiler Dynamic interpretation of the Intermediate Representation Application Intermediate Representation Session Configurator Component Repository Connector Repository Context Configurator Context Configurator Application Component Context Configurator Connector Connector Multi context Connector Collection Fig. 3: The Virtual Machine Principles structures are produced by the compiler, inserted in a component repository and instantiated when the configurator is asking for it. may belong to multiple contexts when shared among multiple users or nodes. Connectors are chosen according to the OCL directives from a connector repository and they are set up either as intra or inter context connectors. As stated before, the application is the top level hence multi context component that is instantiated when a session is created by a user, and which is mapped to new contexts when new users join the session. The arrival of a new user provokes the creation of contexts as well as the creation of execution flows that will effectively execute encapsulated software pieces of primitive components and communicate through the connectors.

7 Implementation of the Virtual Machine The virtual machine has been first implemented on OODE[12], a distributed object oriented development platform which provide shared, distributed objects on a cluster of workstations running Solaris and AIX. The virtual machine was written with the accompanying programming language of OODE (1) : IDL for objects interface definition and OC++, a persistent extension of C++ for the object s implementation. The advantages of such a platform were the transparent distribution of objects, the sharing of objects (especially for multi context components,...) and the limits came from the C++ static typing of objects: asking a context configurator to dynamically create an object from a component class contained in the repository is not an easy feature to implement. The second step of the experiment is to adopt a more widely available platform, in our case the ORB from Xerox, ILU (Inter Language Unification). ILU is an ORB intended to make communicate objects written in various programming languages (C, C++, Python, etc) running on various platforms (Unix, NT, Windows 3.11, etc). The implementation of the virtual machine is being written in Python, a semi compiled interpreted programming language running on Unix, Windows and Macintosh systems, which allows dynamic typing, mobile code and dynamic interpretation of code. The main benefit of this approach is the very dynamic ability to create configuration of applications, the heterogeneity of platforms and the portability of the virtual machine, while the main limitation is the explicit handling of distribution and the distributed computations. 3 Conclusion This paper has described an environment for the construction and configuration of distributed applications. In our view, distributed applications are constructed by assembling a set of interacting software components, some of which are pre existing applications. We are considering an approach which combines object oriented programming for the description of individual software components and system integration techniques for the description of relationships and interactions between components. The proposed environment includes a model and a language which allow a high level specification of involved components, and a run time support for the actual execution and operational control of the application. ( 1 ) OODE is a distributed object based environment, CORBA compliant, derived from the research project Guide and pre industrialized by Bull.

8 Bibliography [1] A. P. Black, N. Hutchinson, E. Jul, H. Levy and L. Carter, Distribution and Abstract Types in Emerald, IEEE Transactions on Software Engineering, 12(12), dec [2] B. H. Liskov, The Argus Language and System, L.N.C.S, 190, [3] Balter R., Bernadat J., Decouchant D., Duda A., Freyssinet A., Krakowiak S., Meysembourg M., Le Dot P., Nguyen Van H., Paire E., Riveill M., Roisin C., Rousset de Pina X., Scioville R. and Vandôme G., Architecture and Implementation of Guide, an Object Oriented Distributed System, Computing Systems, Vol.4 (No.1), pp , 91. [4] Object Management Group, The Common Object Request Broker: Architecture and specification, ( ), December [5] Xerox Corp., ILU 1.8 Reference Manual, Xerox Parc, Palo Alto CA01, October [6] Lamb D. A., IDL: Sharing Intermediate Representations, ACm Trans. Program. Lang. Syst., 9(3), pp , July [7] Cutkosky M.R., Engelmore R.S., Fikes R.E., Genersereth M.R., Gruber T.R., Mark W.S., Tenenbaum J.M., Weber J.C., PACT: An Experiment in Integrating Concurrent Engineering Systems, Computer Journal, pp , January [8] Purtilo J.M., The POLYLITH Software Bus, ACM TOPLAS, Vol.16 (No.1), pp , Jan

9 [9] Kramer J., Magee J. and Sloman M., Constructing Distributed Systems in Conic, IEEE Transactions on Software Engineering, Vol.15 (No.6), pp , [10] Magee J., Dulay N. and Kramer J., A Constructive Development Environment for Parallel and Distributed Programs, Proceedings of the International Workshop on Configurable Distributed Systems, Pittsburgh, March [11] Bellissard L., Ben Atallah S., Boyer A. and Riveill M., Distributed Application Configuration, Proceedings of the 16th International Conference on Distributed Computing Systems (ICDCS 96), to appear IEEE, Hong Kong, May [12] Bull Open Software Systems, OODE: Une plate forme Objets pour les Applications Coopératives, AFCET, edited by AFCET, Paris France, Novembre 1994.