GNATDIST : a conguration language for. distributed Ada 95 applications. Yvon Kermarrec and Laurent Nana. Departement Informatique

Transcription

1 GNATDIST : a conguration language for distributed Ada 95 applications Yvon Kermarrec and Laurent Nana ENST de Bretagne Departement Informatique Technop^ole de l'iroise F Brest Cedex France Yvon.Kermarrec@enst-bretagne.fr Laurent Pautet Telecom Paris Departement Informatique 46 rue Barrault F Paris cedex 13 France pautet@inf.enst.fr Abstract We need a programming language for distributed systems which makes it possible to benet from the potential interests of distributed platforms: e.g., performances, high availability. Ada 95 denes a general framework for programming distributed applications but there is still no language for conguring. Our paper presents our proposal for such a language and we have implemented some of its features. This is part of our eort to make GNAT an environment for programming distributed systems. keywords: Distributed systems programming - conguration language - GNAT 1 Introduction Distributed systems are available thanks to the emergence of networks, workstations and PCs. Programming distributed systems still implies low level interactions with the operating system or communication network interfaces. This is incompatible with a well disciplined programming approach and leads to non 1

2 portable application codes. Advances in computer science have made possible the transition from assembly languages to high level programming languages. We all know the benets of the latter in terms of abstraction and other software engineering principles. In some respects, nowadays, programming distributed systems can be compared to some use of assembly language (e.g., the programmer deals with IP numbers, port numbers). Our contribution aims at dening a high level programming language which can be used to program distributed applications without considering the details of the underlying platform. We say contribution because many programming languages have been proposed and we do not intend to reinvent the wheel. Moreover, Ada has been extended to deal with distributed applications (see Annex E of ISO ) but we still have a minimal language that requires extensions and enhancements. In the rst section of this paper we present the existing solutions for programmming distributed systems. The benets of a programming language for distributed systems are major over traditional approaches which lead to system dependent codes. In the second section, we present the requirements of a language and we justify these elements from existing technologies. This study highlights the main features which can be incorporated into a distributed language and we describe in detail what we call a conguration language. In the third section, we give a brief overview of an Ada 95 approach for distributed systems and the implementation-dependent features as suggested by the reference manual. In the fourth section, we present GNATDIST which is our conguration language. Its syntax and semantics are described and we illustrate its characteristics with an example. As a conclusion, we present the work in progress and our activities around GNAT. 2 Various approaches for programming distributed systems Several approaches exist for programming distributed systems and we do not intend to explore them all. H. Bal and A. Tannenbaum made a complete survey of these issues in [2] and the interested reader will nd a precise analysis of this topic there. Nevertheless, we can isolate three distinct strategies: The use of the underlying facilities of the operating system The use of some middleware or API (Application Programmer Interface). The use of languages dedicated to distributed programming The rst approach is quite traditional and well known and consists in using facilities of the underlying operating system and its network operations. For 2

3 example, in UNIX, we have numerous IPCs (Inter Process Communication) to communicate through the network: e.g., sockets, TLI (Transport Layer Interface). Such an application code depends on the operating system and thus the code cannot be portable on other platforms. In this respect, POSIX (Portable Operating System Interface) aims at proposing a common interface to the OS facilities: the key challenge is to reach portability of even system level applications. Nevertheless, this system programming is low-level and the programmer is responsible for dealing with both complex and error-prone system calls. The second approach proposes the middleware as an intermediate layer between the application code and the target facilities. In the traditional domains of intensive scientic computation, we have PVM (Parallel Virtual Machine) [7] [3]: a software package that permits a heterogeneous collection of machines and workstations to appear as a unique computing resource. The PVM team has ported PVM on many platforms, and many multiprocessors can also be programmed with PVM thanks to the constructors. PVM appears as an answer to the portability problem but still the programmer is faced with the diculties of the message-passing approach: e.g., dealing with data representation, buer management and packing data into buers. OSF DCE (Distributed Computing Environment) [12] [11] proposes an interesting framework for the development of distributed systems. This approach is more suitable for information technologies and has been widely used for cooperative or client/server applications. "OSF DCE provides services and tools that support the creation, use, and maintenance of distributed applications in a heterogeneous computing environment.\ DCE constitutes a signicant step towards facilitating programming distributed systems since the application can rely on numerous services (e.g., security, name services, clock synchronization) and access them through the same interface whatever the platform is. Nevertheless, DCE oers these services through a complex API aimed at sequential programming languages. The third approach is to use specic programming languages. Our view is that a language for distributed systems has to integrate two features: an algorithmic side to program the fragments and a conguration aspect to map the fragments to the computing resources. H. Bal [2] describes the maze in these domains and the variety of approaches in terms of distribution unit, application domains and paradigms. The benets of developing a distributed application with an adequate language are numerous. One of the major advantages consists in considering the application as a unique entity that can be started, controlled and terminated. The language must provide constructions with both the syntax and the semantics to execute an application onto a distributed system and to support 3

4 communication/synchronization and other forms of control between the various fragments of the application. Remotely-located components can communicate using some form of message-passing abstraction or the remote procedure call paradigm (RPC). Other paradigms have been proposed and oer high level abstraction mechanisms: e.g., Linda [4] [5] or ORCA [1]. For example, Occam [10] incorporates a conguration language and the programmer can associate components of an Occam program with physical resources (processors and communication links). The conguration language of Occam is compiled and the generated code contains all the requirements and directives to load the fragment codes. From the conguration program, the compiler extracts topology information that will be used to route the application codes. In Occam 2, there is a clear distinction between the functional aspects and the conguration expression. Once the application has been debugged and tested on a centralized platform, only the conguration program has to be recompiled for a distributed execution. We have selected the programming language approach and in the next section we present some of the features that it can integrate. 3 Features of a distributed language Let us consider the various elements that can be included in a programming language for distributed applications. Their order of presentation does not preclude their relative importance. Only the rst two are required whereas the other elements are optional. 3.1 Building fragments A fragment is dened as an execution unit and is composed of numerous other items depending on the nature of the language. The distribution unit can be the program, the process, the object, the function, the variable or something else. The conguration language has to oer supports for assigning a distribution item to fragments. 3.2 Mapping fragments onto processors On the one hand, we have the software application which is composed of fragments; on the other hand, we have processing elements which understand only binary code. Translation from the software to the binary code is well known in the compilation process. Basically, the code generator must take into account the nature of the processor and must select the appropriate back-end accordingly. Due to the heterogeneous composition of numerous distributed systems, the conguration language has to propose some language construction to specify 4

5 the target. Some other constructions could dene the technical details of the underlying architecture to take advantage of its components (e.g., existence of a co-processor) or to prevent exhaustion of resources (e.g., memory limits). The language must include directives to map fragments of the applications to specic processing elements. This information consists of the machine name, its IP number or any other way to access the processing element. This directive to select the appropriate code generator exists in the conguration language of Occam as Inmos has implemented it. In PVM, the programmer is responsible for calling the compilers for each of the potential targets. To avoid conict between the various versions, the binary code is stored in a le whose path sux is the target. 3.3 Load balancing This facility acts as a complement to the previous one. We have numerous load balancing denitions and we shall consider the static situation. When an application fragment is started, it is executed on the less loaded machine of the network. This static version will not generate thrashing or other complex measurements. Load balancing appears as one possible answer when looking for performance by maximizing the parallelism. Many criteria can be used to dene the activity/load of any machine: its memory use, its CPU use, etc. This requires the code to be available for all the potential targets. In addition, here we have to dene a set of targets in some way. This denition of load balancing and this facility have been implemented in PVM. The criterion is set to be a combination of the CPU utilization and the relative speed of the processor. The set of targets can be all machines of the virtual machine, or a homogeneous subset (e.g., any HP 9000). 3.4 Fault tolerance issues and reconguration Distributed systems are used for their availability and reliability that could be higher than in the case of a monolithic system. In a centralized system, whenever one component crashes or fails then the whole machine is unavailable. When we have several processing elements, the probability of having them all down is very minimal. Nevertheless, we have the so called partial failure which does not preclude system responsiveness but puts it in a degraded performance mode. The nature of potential faults have been studied in depth in the literature. In our context, we consider the case of a faulty communication link or processing element. These events can be detected by the runtime. 5

6 Isolated faulty components do not cause any trouble and have no impact on the global system. Troubles appear when these components interact with each other in some ways: e.g., the communication link is broken, or the processor at the end of the communication path is down. We have various approaches when dealing with these situations. The easiest one is to do nothing at all, but this may generate deadlocks and the application will never terminate. The second approach consists in taking into account the various signals or events that could be sent by the runtime when a faulty component is detected. Then the application can handle these events and execute some prepared scenario, or the runtime can retry the interactions. In both cases, we need some form of interaction from the runtime to the application level: the programmer must be able to catch these events and to trigger adequate action, and the semantics of the interaction has to be specied to avoid side eects. (an expired timeout is not enough to state that a processor is down...) Another way to deal with fault tolerance is to incorporate some redundancy at application level. This approach is quite similar to what we have in hardware where critical components are duplicated. The point is that we then need some form of election to select only one result or to combine the various outputs. Let us consider the case of replicated units. At the application level, we need some way to express replication of critical software resources. For the runtime and in case of failure, we need some mechanisms to select one of the replicas and to redirect the future interactions and requests to it. When dealing with resources in a distributed application, we can use some form of name service or directory service. This service keeps track of the association of a logical name and a network address. This server is accessed only on the rst call: i.e., when the name association is still unknown to the application and the return information is stored in a local cache. This prevents numerous successive calls to the name server and thus reduces bottlenecks. Nevertheless, when information is cached to increase performance and response time, then we face some troubles for reconguration. We need some way to break the association and re-make a call to the name server. The programmer is in charge of specifying the desired level of cache management. DCE oers these possibilities and specic code is inserted in the stubs when they are generated. 3.5 Data representation Computers do not encode data in the same ways. When they are isolated from each other and when they do not interact, we can just ignore these internals. This is not the case in a distributed application where the various fragments work together and need to communicate and synchronize. For this we use some form of common data representation or syntax of transfer. Syntax of transfer 6

7 can be compared to a protocol for data exchange in heterogeneous systems. XDR and ASN-1 are available as syntaxes of transfer. The use of the syntax of transfer generates overheads which are unsuitable in a homogeneous environment. The decision has to be made by the designer of the application. Moreover, the data representation chosen has to be made in advance so that the stubs can make the appropriate calls. 3.6 Levels of security In many ways, distributed systems encourage ows of information and promote sharing resources and other network services. We all know breaches that can be used to access data or tricks to listen to ows of information. The point is that if we want to address the information technology business then we need to give condence in the security issue. Security envolves many issues and we do not intend to investigate them in detail. Our point is to establish the link between the security requirements and their expression in a programming language. As one can guess, enforcing security produces major overhead. For some application, this is the price to pay while for other non sensitive businesses this could be optional. Security has three aspects: authentication, tamper protection and condentiality. 4 Ada 95 approach for distribution The distribution of an Ada 95 program is achieved through the Ada partition model as described in annex E of the Reference Manual [8]. A distributed program comprises one or more partitions that execute independently (except when they communicate) in a distributed system. A partition is either active or passive. An active partition has one or more threads of control. A passive partition has no thread of control of its own and its data and subprograms are accessible to one or more active partitions. The intention of a passive partition is to represent a shared address space across one or more computers on which the application is congured. Library units may be included in partitions and each partition may be elaborated and executed independently. Using categorization pragmas, the programmer designates the library units which play a specic role for distribution. Among the categorization pragmas we can nd : Remote Call Interface (RCI) : the specication of an RCI library unit acts as an interface denition (like an IDL in the CORBA approach) for the 7

8 RPC paradigm which is the communication mechanism between partitions. Shared Passive (SP) : the entities declared in such a library are to be mapped on a shared address space. When two partitions use such a library unit, they can communicate by reading or writing the same variable. This supports the shared variables paradigm. Remote Types (RT) : an RT library unit factorizes declarations and makes them accessible to other categorized units and still guarantee the dependency rules. In order to ensure semantic consistency between a distributed program and the equivalent non-distributed program, some compile-time restrictions are associated with each categorization pragma. The annex also introduces a 'Version attribute to deal with the run-time consistency of the distributed program. It is therefore impossible to have an application whose partitions use dierent versions of the same specication. This rule is a continuation of the compilation rules applied to single Ada programs. The standard exception mechanism still holds. When the execution of a remote subprogram raises an exception, this exception has to be re-raised in the caller of the remote subprogram. The Ada 95 distribution scheme has numerous advantages. We enumerate some of them : Distribution has been introduced into the language without adding new syntactic constructors. The strong typing model and the exception mechanism of Ada are maintained even when distributed code sections communicate. This is due to the use of the RPC mechanism instead of message passing. Interactions inside the distributed application are isolated clearly. Only the subprograms which are dened in an RCI unit can be called from remote. This isolation makes it possible to go through selected steps before reaching the remote service. These steps are dened in the stubs which the compiler generates. They can be modied to add new features for fault tolerance and security and there will be no impact on the user's code. The mapping of partitions of a program to the physical nodes is a postcompilation issue. Thus, applications may be partitioned for dierent distributed systems architectures without recompilation. This eases the addition of new features such as reconguration and migration. The main advantage is that it is possible to debug a distributed application as a 8

9 traditional application and then we can map to a distributed architecture once no execution problems remain. The distributed system annex supports the distributed object paradigm through remote-access-to-class-wide features. Distributed objects are somewhat an association of the RPC paradigm with the object-oriented approach. On the one hand, this combination enables local and remote objects to be accessed with no semantic dierence. On the other hand, due to the object-based approach, accesses to the distributed object state are restricted to operations dened in the interface and this promotes the type-safe disciplined communication within a distributed execution environment. The annex species the interface between the compiler and the Partition Communication Subsystem (PCS). Apart from this minimal interface and the pragmas, the implementor has a large degree of freedom: he can extend the partition model with new features such as replication, etc. The availability of such an interface also makes a distributed Ada application portable. The user can switch easily from one PCS implementation to another. The annex denes a minimal set for programming distributed applications. However, the integration of this framework into an existing Ada environment requires several extensions. The following work has been done for that purpose and has been incorporated into GNAT : The front-end has to be modied to deal with additional checks. The expander has to translate the standard subprogram calls into calls to bind to the server code. This expansion is known as stub generation. A PCS has to be provided to support communication between partition and run-time checks have to be made [9] and [6]. A language is needed to deal with the assignment of library units to partitions, the generation of the executable for each partition, the handling of partition identiers and several other issues. 5 GNATDIST: the language and rationale 5.1 Syntax and semantics A conguration le As mentioned before, an Ada 95 distributed application comprises a number of partitions which can be executed concurrently on the same machine or can 9

10 be distributed on a network of machines. A partition is a set of compilation units which are linked together to produce an executable binary. A distributed program comprises two or more communicating partitions. The distributed systems annex does not describe how a distributed application should be congured. It is up to the user to dene what are the partitions in his program and on which machines they should be executed. The GNATDIST tool and its conguration language have been purposely designed to allow the user to partition his program and specify the machines where the individual partitions are to be executed. GNATDIST reads a conguration le and builds several executables, one for each partition. It also builds a shell script (default) which is used to launch the dierent partitions and to pass specic arguments to each partition Conguration declaration The conguration language is designed to be simple and convenient to use. Its syntax is similar to the Ada syntax in some respects in order to ease the job of an Ada programmer. For this reason, most of the Ada keywords have been reused, sometimes in a slightly dierent context. The distribution of an Ada program is described by a single conguration unit. This conguration unit has a specication part and an optional body part. A conguration unit is declared as an Ada procedure would be. The keyword conguration is reserved for this purpose. CONFIGURATION_UNIT ::= configuration IDENTIFIER is DECLARATIVE_PART [begin SEQUENCE_OF_STATEMENTS] end [IDENTIFIER]; Partition declaration In the declarative part, the user declares his partitions and can change their default behavior. GNATDIST provides a predened type Partition. The user can declare a list of partitions and can also initialize these partitions with an initial list of Ada units. DECLARATIVE_PART ::= {DECLARATIVE_ITEM} DECLARATIVE_ITEM ::= 10

11 PARTITION_DECLARATION REPRESENTATION_CLAUSE SUBPROGRAM_DECLARATION PARTITION_DECLARATION ::= DEFINING_IDENTIFIER_LIST : Partition [:= ENUMERATION_OF_ADA_UNITS]; DEFINING_IDENTIFIER_LIST ::= DEFINING_IDENTIFIER {, DEFINING_IDENTIFIER} STATEMENT ::= IDENTIFIER := ENUMERATION_OF_ADA_UNITS; SEQUENCE_OF_STATEMENTS ::= STATEMENT {STATEMENT} Once declared, a partition is an empty list of Ada units. The operator ":=" adds the Ada units list on the right side to the current list of Ada units that are already mapped to the partition. This is a non-destructive operation. Whether a unit is a relevant Ada unit or not is checked later on by the back-end of GNATDIST. These assignments can occur in the declarative part as well as in the body part. ENUMERATION_OF_ADA_UNITS ::= ({ADA_UNIT {, ADA_UNIT}}); As GNATDIST generates full Ada code in order to build the dierent executables, all the Ada keywords have been reserved even if they are not used in the conguration language Physical nodes Logical nodes (or partitions) can be mapped onto physical nodes. GNATDIST default behavior is to ask for themi nteractively. It is possible to modify the default behavior of all the partitions via an attribute denition clause applied to the predened type Partition. It is also possible to modify the default behavior of a given partition via an attribute denition clause applied to the partition itself. The host-name can be either a static or dynamic value. In case of a static value, the expression is a string literal. In case of a dynamic value, the representation clause argument is a function that accepts a string as parameter and that returns a string value. When the function is called, the partition name is passed as parameter and an host-name is returned. REPRESENTATION_CLAUSE ::= for IDENTIFIER'Host use STRING_LITERAL; for IDENTIFIER'Host use SUBPROGRAM; 11

12 for Partition'Host use STRING_LITERAL; for Partition'Host use SUBPROGRAM; The signature of the function should be the following : it takes a string parameter which corresponds to a partition name. It also returns a string parameter which corresponds to an host-name. The function that returns the host-name can be an Ada function (default) or a shell script. A pragma Import is used to import a function dened in Ada or in Shell. This function is called before launching the partition. Therefore, in case of load balancing, the function can return the most appropriate host from among a set of hosts Executable location There are several other attributes that can be applied to a partition. Storage Dir allows the user to specify in which directory the partition executable is stored. This can be useful in heterogeneous systems when the user wants to store executables of the same target in a given directory. Specifying the directory is also useful if the partition executable is not directly visible from the user environment. For instance, when a remote command like rsh is invoked, the executable directory has to be present in the user path. If the Storage Dir attribute has been specied, the executable full name is used. REPRESENTATION_CLAUSE ::= for IDENTIFIER'Storage_Dir use STRING_LITERAL; Partition main procedure Basically, the distributed system annex helps a user in building a distributed application from a non-distributed application. The user can design, implement and test his application in a non-distributed environment, and then should be able to switch from his non-distributed case to a distributed case. This twophase design approach has several advantages. For this reason, the conguration language provides a way to declare the main procedure of the non-distributed application. procedure MAIN_UNIT is in PARTITION; In this case, the partition in which the main procedure has been mapped will include in its code a call to this main procedure. Other partitions will have a null body as a main procedure. But the user can also modify this behavior by providing an alternate main procedure. 12

13 procedure MAIN_PROCEDURE; for PARTITION'Main use MAIN_PROCEDURE; In a non-distributed case, the user executes only one main executable possibly with a name corresponding to the main unit name of his application. With GNATDIST, in a distributed case, a main executable with a name corresponding to the main unit name is responsible for starting the entire distributed application. For this reason, the user can start his application the same way he used to do in the non-distributed case. As a default, the main executable is a shell script that starts one at a time the dierent partitions on the appropriate remote machines. But the user may ask for a full Ada starter procedure. The pragma Starter allows the user to ask for one starter or another. type Method_Type is (Ada, Shell, None); pragma Starter (Method => Method_Type); Alternate services There are several other pragmas in the conguration language. The pragma Crossed Elaboration allows the user to violate E.4 (14) or E.5 (21) : 14 If a remote subprogram call is received by a called partition before the partition has completed its elaboration, the call is kept pending until the called partition completes its elaboration (unless the call is cancelled by the calling partition prior to that). 21 The procedure System.RPC.Establish RPC Receiver is called once, immediately after elaborating the library units of an active partition (that is, right after the elaboration of the partition) if the partition includes an RCI library unit, but prior to invoking the main subprogram, if any. pragma Crossed_Elaboration (Allowed => Boolean); The rationale of such a pragma comes from the following situation: 13

14 -- On partition 1 package body RCI_3 is... begin Read (File, Default3); end RCI_3; with RCI_2; package body RCI_1 is... begin RCI_2.Get_Default2; Compute (Default1); end RCI_1; -- On partition 2 with RCI_3; package body RCI_2 is... begin RCI_3.Get_Default3; Compute (Default2); end RCI_2; To elaborate on partition 1, RCI 1 has to wait for the elaboration of RCI 2. But, to elaborate on partition 2, RCI 2 has to wait for the elaboration of RCI 3. If we follow the LRM restrictions, requests to RCI 3 should be kept pending until partition 1 has been fully elaborated. Thus, we are in a deadlock situation. The GNAT distributed annex is designed such a way that this restriction is not necessary. The default behavior follows the LRM restriction, but this can be suppressed by pragma Crossed Elaboration. 5.2 A short example File `my_config.cfg' The name of the file prefix must be the same as the name of -- the configuration unit, in this example `my_config'. The -- file suffix must be `cfg'. For a distributed program, -- you can have as many configuration files as you wish. configuration My_Config is Partition_1 : Partition := (); procedure Master_Procedure is in Partition_1; -- Partition 1 contains no RCI package at this point. However, -- it will contain the main procedure of the distributed -- application, called `Master_Procedure' in this example. If -- the line `procedure Master_Procedure is in Partition_1;' -- was missing Partition 1 would be completely empty. This is -- forbidden, a partition has to contain at least one lib. unit gnatdist produces an executable shell script with the name -- of Master_Procedure which will start the various partitions -- on their host machines in the background. The main -- partition is launched in the foreground. Partition_2, Partition_3 : Partition := (Normal); -- Partition_2 and Partition_3 contain package Normal 14

15 -- whatever mapped RCI units are. for Partition_2'Host use "foo.bar.com"; -- Specify the host on which to run partition 2. function Choose_Best_Node (P : String) return String; pragma Import (Shell, Choose_Best_Node, "./best-node"); for Partition_3'Host use function Choose_Best_Node; -- Use the value returned by a function to decide at execution -- time the name of the host on which partition 3 should -- execute. For instance, execute the shell script `best-node' -- which returns a string giving the name of the partition. Partition_4 : Partition := (RCI_B5); -- Partition 4 contains one RCI package RCI_B5 -- No host is specified for this partition. The startup -- script will ask for it interactively when it is executed. for Partition_1'Storage_Dir use "/usr/ada/sunos-5.4/bin"; for Partition_2'Storage_Dir use "/usr/ada/sunos-4.1.3/bin"; -- Specify the directory in which the executables in each -- partition will be stored. Default is the current directory. pragma Starter (Method => Ada); -- Specify the kind of launch procedure you would like. -- Three methods are available. Shell method builds a shell -- script that means that all the partitions will be launched -- from a shell script. If Ada method is chosen, then the -- launch procedure is the main Ada procedure itself. If -- None method is chosen, then no launch procedure is built -- and you have to start the partition manually. In the -- following example, Partition_2, Partitions_3 and -- Partition_4 will be started from Partition_1 - Master_Procedure. -- The configuration body is optional. You may have fully -- described your configuration in the declaration part. begin Partition_2 := (RCI_B2, RCI_B4); -- Partition 2 contains two RCI packages RCI_B2 and RCI_B4 -- and a normal package. A normal package is not categorized. Partition_3 := (RCI_B3); -- Partition 3 contains one RCI package RCI_B3 and a Normal package. end My_Config; 5.3 GNATDIST internals Command line GNATDIST is an upper layer to GNATMAKE and includes some of its functionalities. For instance, if you want to compile with debugging information, the option "-g" works the same way it does for GNATMAKE. Thus, all the generated 15

16 stubs will be compiled with debugging information. By default, GNATDIST builds the executables of all the partitions declared in the conguration le. The user can ask for the creation of a given set of partitions by indicating such a set on the command line. For instance, the user can build some of his partitions with particular options (dierent -I and -L paths depending on the platforms) when the remaining partitions are built by using another set of options Implementation constraints One of our main restrictions was to keep GNATDIST simple and ecient. For this reason, GNATDIST has an executable size similar to GNATMAKE. GNATDIST parser was written manually and we decided not to use Aex and Ayacc for this reason. GNATDIST reuses the GNAT sources in order to remain consistent with any modication of the ALI le format. Since GNAT is really well written, it is really a great benet to have access to its optimized, portable functionalities. Eciency and portability were two major reasons for discarding the idea of a graphical tool. First of all, such a tool is very ashy for novices in case of demos but is almost useless in the context of a large project. It is hardly portable as there is a strong dependency on the graphic environment and it also involves a large amount of code that is not concerned with the application distribution, which is of little benet to the user GNATDIST directory hierarchy GNATDIST creates a directory hierarchy in order to store its own les (Ada stub, ali les, object les). To keep the user directory clean from all the private les of the distributed system annex, all these les are stored in the dsa directory. This directory is structured as follows : dsa/caller Contains the caller stubs (Ada sources, ali les, object les) dsa/receiver Contains the receiver stubs (Ada sources, ali les, object les) dsa/<partition > Contains copies or links to Ada units mapped onto this partition, mostly received stubs for RCI units. 16

17 Here is what goes on behind the scenes when building a distributed application: 1. Each compilation unit in the program is compiled into an object module (as for non distributed applications). This is achieved by calling gnatmake on the sources of the various partitions. This step can be skipped by using the -n option. 2. GNATDIST performs a number of consistency checks, for instance it checks that all packages marked as remote call interfaces are mapped onto partitions. It also checks that an RCI package is mapped onto only one partition. GNATDIST checks that all the mapped units of the conguration le are visible Ada units. 3. Stubs are generated and compiled into object modules. Several timestamp checks are performed to avoid useless recompilation. These les are respectively stored in dsa/caller and dsa/receiver directories. 4. GNATDIST builds a directory dsa/<partition> and installs the receiver stub les of RCI units mapped on the current partition. Depending on the operating system, this installation is a copy, or a link to the appropriate les. 5. A main procedure is built in the same directory. In this le, GNATDIST makes all the mapped units visible. Some special services are also activated at this point, such as version id consistency. 6. Finally, the executables for each partition in the program are created along with the generation of the shell script to start them on the appropriate machines GNATDIST and GARLIC The GNAT Partition Communication Subsystem, GARLIC (Generic Ada Reusable Library for Interpartition Communication), is included in the source distribution. GARLIC implements all the functions and services required in System.RPC and also provides extended services to the distributed ystem annex. Among other things, GARLIC provides a distributed termination algorithm. But this functionality can be inhibited by the user if the partition attribute Termination is set to False. This way, the distributed algorithm is still active, but when the termination request is received by such a partition, the request is forwarded to neighbors but ignored locally (See E.1 (14)). 14 An implementation may allow the state of some of the partitions of a distributed program to persist while other partitions of the program terminate and are later reinvoked. 17

18 Several extended services are not mentioned in the LRM but are available in GARLIC. During conguration, the user can ask for these services which are made available via several library calls embedded in the partition main procedures built by GNATDIST. One of these services would be to allow crossed elaboration or to suppress global termination. GARLIC and GNATDIST installation are performed at the same time. In the previous section, we mentioned that GNATDIST takes full advantage of GARLIC specic features. In this purpose, GARLIC is automatically made visible to the user through GNATDIST. 6 Conclusions and work in progress GNATDIST is our language for programming distributed Ada 95 applications. The features we have presented in section 5 have been implemented. GNATDIST can be compared to a conguration language which assists the programmer and masks many technical details. This language is our answer to the "implementation dependent" elements as dened in Annex E. Its reduced syntax and semantics make it possible for a programmer to implement and congure a distributed application and benet from the advantages of a distributed system: redundancy for fault tolerance, distribution for performance. Its consistency with Ada 95 in terms of syntax and constructs will be easily understiood by the Ada 95 programmer and this guarantees a continuation and consistency from the programming of the partitions to their conguration. Its source distribution make it possible for a team to adapt and tailor GNATDIST to its needs or to add additional features if required. Moreover, conguring an application with a language increases portability and exibility. This initial version of GNATDIST is operational and we have started to distribute it. It has been used in a student project for a ray tracing application and the transition from a centralized execution to a distributed execution on several workstations has been very smooth. The evaluations of the testers will be helpful and we are waiting for their comments. From these evaluations and experiments, we also plan to extend the potentialities of the language but we do not yet have a schedule of deliveries. Our team is working in conjunction with other teams in Lausanne (EPFL) and Uppsala (Departement of Computer Systems) and, with their cooperations, we hope to implement new features in GNATDIST. In some ways, GNATDIST completes the work we were doing in distributed systems for many years. At the beginning, we have been working on software components for distributed applications and we have already addressed various algorithms, services and paradigms. During this phase, our concern was 18

19 reusability and software engineering at the application level. In another phase, the GNAT team assigned to us the implementation of the distributed system annex. This work was at the compiler level: we completed the front-end checks and the stub generations. Run time libraries have also been developed and for this we benet from our experience and our earlier developments of software components. The last phase is GNATDIST. Our achievements do not preclude parallel work or additional extensions. We indicate a few on-going or future projects. We intend to add new features in the run-time libraries to detect faults and to anticipate the application recon- guration, to deal with various syntaxes of transfers, and to address embedded applications. HOOD is a software method that is promoted by the European Space Agency and the new version incorporates a proposal for the design of distributed applications. Our current work consists in establishing a "link" between the description of the application in HOOD and its distributed execution, through the generation of Ada 95 and GNATDIST codes. References [1] H. Bal, M. Kaashoek, and A. Tanenbaum. Orca : a language of parallel programming of distributed systems. IEEE transactions on software engineering, 18(3):190{205, march [2] H. Bal, J. Steiner, and A. Tanenbaum. Programming languages for distributed computing systems. ACM computing surveys, 21(3):260{322, september [3] A. Beguelin, J. Dongarra, R. Manchek, and V. Sunderam. A users' guide to PVM parallel virtual machine. Technical Report ORNL/TM-11826, Oak Ridge NAtional Laboratory, July [4] N. Carriero and D. Gelernter. How to write parallel programs : a guide to the perplexed. ACM Computing Surveys, 21(3):323{358, September [5] N. Carriero and D. Gelernter. Linda in context. Communications of the ACM, 32(4):444{458, April [6] A. Gargaro, Y. Kermarrec, L. Pautet, and S. Tardieu. PARIS : Partitionned Ada for Remotely Invoked Services. In Eurospace, editor, Ada Europe Conference, Franckfurt Germany, Heidelberg, October CNES and European Space Agency, Lectures Notes in Computer Sciences. [7] A. Geist, A. Beguelin, J. Dongarra, and W. Jiang et al. PVM 3 user's guide and reference manual. Technical Report ORNL/TM-12187, Oak Ridge National Laboratory, May

20 [8] Intermetrics. Ada 95 reference manual. International Standard ANSI / ISO / IEC-8652:1995, January [9] Y. Kermarrec, L. Pautet, and S. Tardieu. GARLIC : Generic Ada Reusable Library for Interpartitions communication. In Proceedings of the Tri Ada conference, Anaheim, California, November ACM. (technical report of Telecom Bretagne). [10] D. May. Occam 2, langage denition. Prentice Hall, February [11] Ward Rosenberry, David Kenney, and Gerry Fisher. Understanding DCE. O'Reilly and associates, inc, [12] John Shirley. Guide to writing DCE applications. O'Reilly & Associates, Inc, June