ATLAS, a platform for transparently developing distributed applications

Atlas : a platform for transparently developing distributed applications M. Fairen and  A. Vinacua Department of Software, Institute of Rob otics and Industrial Informatics, U.P.C. Diagonal 647, 8 ena planta E08028 Barcelona, Spain +34 3 401 6739 f mfairen,alvar g @lsi.upc.es ABSTRACT We discuss the design and implementation of a software development platform that allows unsophisticated programmers to include advanced features to their applications with no or very little extra information and eort. These features include the splitting of the application in distinct pro cesses that may b e distributed over a network, a p owerful conguration and scripting language, and several to ols including an input system to easily construct reasonable interfaces. We attempt to describ e b oth the techniques used to achieve transparency for the programmer and what exactly a user must do to build new Atlas mo dules. KEYWORDS Distributed applications, Software development to ols, External data representation 1 INTRODUCTION Atlas represents an attempt to facilitate to programmers in our lab the incorp oration to their applications of certain services at a minimum cost. In fact, Atlas helps them build distributed applications (problems involved in distribution were fo cused in [2]), provides them with p owerful conguration mechanisms and a macro language and include a journaling facility, among other things. All these asp ects require a substantial amount of familiarity by the programmer with the said techniques, and a fair amount of programming for them on each application. In a research lab like ours a large amount of software is constantly b eing develop ed to demonstrate ideas, but eventually has to b e rewritten when certain functionalities need to b e combined. It also remains in an un- nished status and is usually hard to use or demonstrate by anyb o dy except the author, b ecause of the high cost of \nishing up" the details. We then realized that a development platform that facilitated the construction of this software giving easy access to many sophisticated resources and establishing basic rules that eased the joint op eration of mo dules was valuable to us, since it enabled exp erimental software to grow in a more harmonious way, and facilitated even the reuse of old comp onents. Evolving from the ideas originally presented in [9] we designed Atlas for this purp ose. Since our work is centered in Computer Graphics applications we included certain mechanisms esp ecially designed for that domain which we've discussed in sp ecialized forums [6]. However by far the largest p ortions of eort and of co de involved very general to ols usable by interactive applications in most other domains. Therefore Atlas can also b e viewed as a general programming to ol that greatly simplies the construction of fairly sophisticated applications. In this pap er we shall present a view of Atlas from this last p ersp ective, discussing the general asp ects not present in other publications ab out it and showing how and in which ways it can enhance the software development pro cess. In the next section we shall enumerate more concrete ob jectives and criteria used in the design of Atlas . Section three will briey present the solution adopted for the interpro cess communication, and section four will describ e asp ects of the design and implementation of an Atlas application from the p oint of view of the user |the programmer building the application. Finally we will turn briey to conclusions and future work. 2 OBJECTIVES AND DESIGN CRITERIA The rst priority in the design of Atlas has b een to make its inner workings as transparent to the user as p ossible. To this end, some asp ects may not have the intrinsically b est or most p owerful or most exible solution, but users can build applications on Atlas without almost any concern ab out it, yet getting substantial b enets from its presence. In terms of functionality, Atlas includes these ob jectives:  Low level of paral lelism . Atlas applications feature several distinct pro cesses running concurrently in the same or dierent machines in a network; pro cesses encapsulate Atlas comp onents or user mo dules. The user implements routines that are 1 accessible to other pro cesses as remote pro cedures.  Interprocess communication . Since the application is split in several pro cesses, these need to communicate over the network and exchange data b etween p ossibly dierent architectures. This gives rise to many dierent problems that need to b e addressed [1].  Standardized input model . A great deal of eort in an application's development is sp ent in its user interface. Atlas provides a uniform but exible view of inputs that allows many dierent dialogue mo des in a uniform way, somewhat related to Abstract Data Views [3].  Conguration and macro language . A exible yet p owerful way must b e provided for a programmer to describ e what is in each of his mo dules, and how it should relate to others, and also to dene the dialogues of the application and its b ehavior in a simple way.  Journaling mechanism . This is not yet implemented and only mentioned here in passing. It is partially designed and will b e at the heart of other services oered by Atlas .  Fault tolerance . Since the application is spread out among several hosts, it b ecomes more exp osed to transient or p ermanent failures (of the communications or of any of the hosts involved). Fault tolerance is transparently provided based on the journaling mechanism and on heartb eat messages sent by all pro cesses so that their status can b e assessed.  Reusability . Each user mo dule is completely isolated from others (in a separate pro cess) except through a well dened interface describ ed in Atlas 's programming language. Thus new comp onents can incorp orate and use reliably old ones. Not all these asp ects can b e discussed here, as they would take an inordinate amount of space. The following sections center around asp ects of the present b eta version concerning the housekeeping of pro cesses and communications, and how Atlas helps users build applications with these features easily. 3 IMPORTANT ISSUES IN THE Atlas COMMUNICATIONS MECHANISM 3.1 Problems That Need To Be Addressed Since Atlas rst priority is to oer the maximum transparency to the develop er, the design of Atlas architecture must hide the intricacies of the interpro cess communications from the programmer. The communications mechanism has to address problems like how to start a pro cess in an application, how to manage the interchange of information b etween processes and also how to detect failures in the application communications in order to know when the faulttolerance mechanism should b e activated. To start a pro cess in a dierent machine it is necessary to have a pro cess listening for a connection in the chosen host (this requires to have knowledge of low level connections in the op erating system), and it would b e also desirable that the pro cess to b e started inherits the application environment. The interchange of information b etween pro cesses has also an added diculty when they are running in an heterogeneous network b ecause data can b e interpreted with dierent meaning dep ending on the architecture where they are used. Next subsection explains how these problems have b een addressed in Atlas . 3.2 The Approach Used In Atlas The Atlas architecture is represented in gure 1, where the ovals denote pro cesses and the arrows represent communications b etween them. It is a centralized architecture where the pro cess distr acts as the master pro cess and is the center of each Atlas application. This architecture allows an intelligent distribution to b e managed, i.e. the distr pro cess is able to decide the pro cesses distribution dinamically dep ending on the aptitude of each host in the network to run each application pro cess. Therefore, this master pro cess is the most crucial one in this architecture and also in the communications mechanism b ecause it is the communications center for each application. It is also the one to take care ab out the status of each pro cess in execution at any time. This is easy b ecause of the heartbeat mechanism designed in Atlas . The heartbeat mechanism makes every pro cess b eing executed in the application send a short message p erio dically to the master pro cess giving the required information to control the global status of the execution. This mechanism is very useful to detect if a pro cess or the communication with it fail, therefore it will b ecome necessary to the fault-tolerance mechanism which, although it is not available yet, has b een almost completely designed. This mechanism will b e shortly discussed in the future work section b elow. Server Process Design The Atlas server pro cess is a simple but very imp ortant pro cess in the Atlas architecture. Its role, in the 2 B-Rep Volume Command Subsystem Input Subsystem Solver Constraints distr server@host Octree Machine Figure 1: A sample execution of an Atlas application. current version, is to accept connections from the master pro cess distr and run the application pro cess requested by it. In future versions it will also implement a handshake with distr to achieve a certain degree of load-balancing. As the server daemon is normally run at b o ot time with root p ermissions, it must change its p ermissions to the user's p ermissions b efore executing the user's pro cess in order to protect the system. Moreover, to do that it must b e sure of the identication of the user and also inherit the user environment to achieve a successful execution. This environment information is sent by the distr pro cess in the connection message. The user identication mechanism is based on a sp ecial 32 bytes long user identier that every Atlas user must have generated b efore he executes Atlas for the rst time. Communications Drivers Design An Atlas application pro cess execution is based on a remote-procedure-cal l -like paradigm. A pro cess can b e then considered as a set of routines to do the pro cess related work plus a communications driver to manage the interchange of messages with the rest of the application (see section 4). The communications driver is the main program of the pro cess, and its role is to listen requests or messages from the master pro cess and other connections added and dispatch them as needed. The most relevant requests or messages sent by the master pro cess can b e related with a routine call, data answering a request, or an Atlas event notication (see section 4.3). The main execution of an Atlas pro cess is then the dispatch routine of its communications driver. It enters in a lo op listening in the group of channels actived by this pro cess (the default is only the connection with the master pro cess), and when it receives a message it dispatches it and keep on listening for another one (see gure 2). Apart from dispatching messages the driver can also dispatch interruptions (like signals). In fact the heartbeat mechanism uses the SIGALRM interruption. Driver add timer add channel routine call ATLAS event treatment answer data dispatch dispatch dispatch timeout handling timeout sub channel optional Figure 2: Driver role scheme. The default treatment of an Atlas pro cess driver is managing the messages comming from the master process and the interruption of SIGALRM. But the actual driver is much more exible (as can b e seen in gure 2). It also allows the pro cess to add channels to listen to, add a timer treatment or remove channels added b efore. This exibility only requires to have implemented the treatment for messages b eing received by these new channels. The Atlas communications mechanism is implemented using so ckets, and its implementation takes prot of the wrapp er classes for so ckets oered by the public domain package ACE Wrapp ers (see [7] and [8]). 3 The biggest problem to solve in communications b etween Atlas pro cesses is the interchange of data. Since these pro cesses may b e running in dierent architectures, data must b e sent through the network using a standard representation in order that they have the same meaning to the dierent pro cesses. Furthermore, these data need to b e {at least very often{ accessible to Atlas itself, which includes a programming language to dene user-machine dialogs or otherwise interconnect to dierent mo dules (see section 4). The problem of actually transfering the data robustly has long since b een solved. Indeed we just rely on XDR [10] for that purp ose. To attain these data sharing with the maximum of transparency for the develop er, Atlas includes a mechanism based on our data structures (called Variables ) used to wrap user data in each pro cess (this mechanism is thoroughly explained in [5]). These structures oer access metho ds used by the interpreter of the command language, and also encapsulate metho ds to enco de and deco de XDR streams transparently. Using this mechanism and adding also the automatic co de generation explained in the next section, the develop er needs not b e aware of XDR and indeed almost not b e aware of our interchange metho d at all. 4 DESIGNING AN APPLICATION. BENEFITS TO THE DEVELOPER. 4.1 Transparency To The Develop er The most imp ortant aim that Atlas wants to achieve is a high level of transparency to the develop er. Almost all services that Atlas oers to applications develop ed over it are techniques that normally require a lot of sp ecialized programming. The emphasis in Atlas 's design is to relief the programmer from this eort. Many facilities oered by Atlas , like distribution or the communications mechanism, must b e totally managed by Atlas in order to achieve the maximum transparency to the develop er. The programmer need not know ab out these mechanisms and can concentrate on the ob jectives of his application. Automatic Code Generation The Atlas pro cess communications require quite a bit of co de in each pro cess devoted to handshaking with distr , generating the heartbeat messages at the adequate rate, preparing the arguments for pro cess routines or collecting results and enco ding them for b eing transp orted over the network, and dispatching calls to pro cess routines. To handle this, Atlas automatically generates co de stubs that the develop er must link with his program. These stubs are constructed from the interface declaration of the pro cess (like in gure 3), which contains the typ e denitions used for variables to b e exp orted and the prototyp e denitions of the pro cess extern routines. The generated co de also includes stubs to automatically transfer the user's data into Atlas Variables and backwards, through bridge types used to isolate the develop er from the details of the Atlas Variables (which an advanced programmer can use directly if he wishes to). The bridge types are used to build intermediate objects with the data structure of the pro cess ob jects (as p er their Atlas declarations) but without the metho ds of the pro cess ob jects (which remain unknown to Atlas ). Each bridge type has also metho ds to translate to and from Atlas Variables , making b oth translations transparent to the develop er. The only burden on the develop er is then to provide his classes with conversion metho ds to and from these bridge type ob jects which is usually trivial (unless the develop er choses to have a very dierent structure for the Atlas data that the one used internally by his program). As an example we can see some relevant p ortions of this automatically generated co de in app endix. 4.2 Design Pro cess Of An Atlas Application An Atlas application is a set of pro cesses which can communicate b etween them through the Atlas communications mechanism. Each pro cess can b e seen as a mo dule oering some public metho ds that can b e used by the other pro cesses. Therefore, it must b e designed as a set of exp orted routines that may b e called by other pro cesses. This should b e the general view of a pro cess b elonging to an Atlas application. From the develop er p oint of view, a pro cess consists of two parts: its interface and its implementation. The Process Interface The pro cess interface is a mo dule written in ATL language which denes the prototyp e of the public routines of the pro cess and the needed typ es for their parameters and return results. The ATL language (describ ed in detail in [4]) is an imp erative and mo dular language designed for Atlas applications. It allows to dene typ es, variables, functions and pro cedures that can b e exp orted (visible to the others) or lo cal. It also accepts the most common control structures inside functions and pro cedures (conditionals, lo ops, etc.) and routine calls b oth synchronous and asynchronous. Although only its prototyp es and typ es are needed for a pro cess interface, the mo dule dening the pro cess interface can also include functions or pro cedures dened in ATL which describ e the interaction with other pro cesses 4 in the application or with the user (e.g. asking for input data). ATL mo dules which are not the interface of any pro cess but dene the execution co ordination and interaction b etween pro cesses can also b e dened in the application, and users may dynamically add their own. An example of an ATL mo dule with part of the interface of a pro cess called volum can b e seen in gure 3. Since it is an example it is not complete, but it shows the definition of a set of typ es exp orted by the mo dule (some of them are needed as parameters of extern routines), the prototyp es of two extern routines (these prototyp es and the typ es of its parameters would form the interface of the pro cess), and the description of a pro cedure (b eing also exp orted to b e visible to other mo dules) that combines the execution of the pro cess routines, asks for an input datum (through GETDATA ) and also calls to a pro cedure of another mo dule ( se::Output ). USE se; EXPORT #deftype point STRUCT x -> real; y -> real; z -> real; ENDSTRUCT EXPORT #deftype face VECTOR [3] OF STRUCT p1 -> point; p2 -> point; id -> integer; ENDSTRUC T EXPORT #deftype simplex STRUCT name -> string; sides -> VECTOR [4] OF face; ENDSTRUC T EXPORT #deftype scene VECTOR [100] OF simplex EXPORT #deftype property integer EXPORT scene totalsc; ... PROT EXTERN FUNCTION segmentat io n (scene sc, property p) RETURNS scene; EXTERN PROCEDURE display_ sc ene (scene sc); ... ENDPROT ... EXPORT PROCEDURE SegmentS im pl ex () IS display_s ce ne (segmenta ti on (to ta ls c, GETDATA(" In put the property value"))) ; se::Outpu t ("Segment ati on complete d" ,"m ") ; ENDPROCED UR E Figure 3: Portion of the interface denition in Atlas for the volume mo deling pro cess (\volum"). The Process Implementation Since giving the pro cess interface in the ATL mo dule allows Atlas to generate co de stubs to implement the communications driver for this pro cess (see subsection 4.1), from the develop er p oint of view the pro cess implementation consists of the set of C++ routines declared as externals in the ATL mo dule plus the denition of the C++ classes used by their parameters. This implementation can also include whatever the develop er wants as a private part of the pro cess. This part won't b e visible outside the pro cess. Figure 4 shows how an Atlas executable pro cess is generated from its source les. The les depicted on the left most column are those that the develop er must implement. The automatically generated co de is divided in three les: the atl process.hh le denes the C++ prototyp es for the pro cess routines declared as extern routines in the ATL mo dule; the atl process.H le has the bridge types implementation for that typ es used by the extern routines of the pro cess; nally the atl process.C le implements the main co de for the communications driver and also auxilary routines which convert Atlas Variables to the pro cess C++ classes and backwards in order to b e able to call the corresp onding pro cess routine with the correct parameters and result variables. 4.3 Other Benets To The Develop er There are also other b enets provided to the develop er that mayb e are interesting to b e mentioned:  At run time, the Atlas kernel keeps some structures containing information ab out the status of the application (what pro cesses are in execution, if there is some request waiting for an input data, etc). To give the opp ortunity that an application pro cess b e informed ab out changes in this internal structures, Atlas oers the Atlas events mechanism that allows the pro cess to ask for a subscription to a particular Atlas event (ADD PROCESS when a new pro cess starts in the application or ADD INPUT when an input is pro duced by the end user, for example). Whenever an Atlas event is pro duced the distr pro cess sends the corresp onding event message to every pro cess subscrib ed to that event, and the driver of the pro cess, when it receives this event message, calls the routine attached to this event at subscription time.  In order to address the standardized input model presented as an Atlas ob jective in section 2, Atlas also oers a generic input handling pro cess. It provides a window in which all the textual interactions o ccur (issuing commands or entering numerical data), but can also b e instructed to capture events from other windows (owned by the rest of the pro cesses in the application) and consider them input data to b e channeled to those pro cesses. The input system is also extensible. In fact it is also an interface b etween Atlas and an extended Tcl/Tk [11] engine, so scripts in Tcl can b e sent to it to instantiate new interface comp onents. Using this Atlas comp onent the develop er can prepare the user interface for his application almost trivially, and dedicate most of his time to the prop er sub ject of his application. 5 (prototypes) ATLAS processgenerated filesdeveloper files atl_process.hh atl_process.H atl_process.C (bridge types) (driver main) process.atl interface process.h (C++ classes) includes includes process.C private part + routines extern implementation process Figure 4: Creating an Atlas pro cess.  The virtual machine that interprets ATL co de allows b oth synchronous and asynchronous calls to external routines. Some pro cesses may therefore act as large batch pro cesses that are executed concurrently with the application. To rendezvous with these asynchronous calls, Atlas uses a simple device: the virtual machine tags all output parameters or return values of an asynchronous call as \dirty", and any attempt to use one of them as an r-value freezes the executing thread. Thus asynchronous calls may b e issued and other p ortions may prop erly await their completion in a transparent manner. 5 CONCLUSIONS AND FUTURE WORK We have presented a software platform designed to allow develop ers to incorp orate advanced features in their development with the least hassle. It is presently b eing used within our lab to p ort several packages develop ed here, and also to build new ones. It's design favors the construction of reusable mo dules that can relatively easily b e combined with each other. This seems very desirable, esp ecially in an environment like ours, where large p ortions of co de are constantly b eing generated by students which later depart. The users may just as easily add pro cesses to implement a new application or to extend Atlas itself. Presently, for instance, a menu-handling mo dule is b eing constructed, that will then b e available for all other Atlas applications to dene their own, very exible, menus. We are currently p orting the current version (0.2) of Atlas to dierent platforms, currently including Suns under b oth Solaris 1.x and 2.x, and HPUX, but so on to include also SGI's IRIX 6.x and Windows NT. We are also completing the journaling mechanism, which will not only allow replays of sessions, but will supp ort the fault-tolerance within Atlas , and will provide unlimited (alb eit exp ensive) undo's and redo's through a \commit" blo cking instruction within the journal, and supp ort for inverse functions. Among the near future pro jects, we plan to add some supp ort for CSCW by the simple device of cloning the application for the dierent users collab orating, and establishing sp ecial connections b etween the corresp onding distr pro cesses, only one of which acts as master. This, although limited, would turn essentially every Atlas application into an CSCW-capable application, with no or extremely little eort by the develop ers, as p er Atlas 's requirements. REFERENCES [1] G. R. Andrews. Paradigms for Pro cess Interaction in Distributed Programs. ACM Computing Surveys , 23(1), March 1991. [2] R. S. Chin and S. T. Chanson. Distributed Ob jectBased Programming Systems. ACM Computing Surveys , 23(1), March 1991. [3] D. D. Cowan and C. J. Lucena. Abstract Data Views: An Interface Sp ecication Concept to Enhance Design for Reuse. IEEE Transactions on Software Engineering , 21(3), March 1995. [4] M. Fairen and A. Vinacua. ATLAS. Sistema de Comandes: Manual tecnic (in Catalan). Report LSI95-11-T , 1995. http://www.lsi.up c.es/~ mfairen. [5] M. Fairen and A. Vinacua. Interpro cess data transfer in Atlas , a platform for distributed applications. 1997. Submited to the OPENARCH'98 conference. [6] M. Fairen and A. Vinacua. Atlas , a platform for distributed graphics applications. 1997. To app ear in the pro ceedings of Eurographics Workshop on Programming Paradigms in Graphics. [7] D. C. Schmidt. The ADAPTIVE communication environment: Ob ject-oriented network programming comp onents for developing client/server ap6 plications. In 12th Sun Users Group Conference , 1994. [8] D. C. Schmidt. Reactor: An ob ject b ehavioral pattern for concurrent event demultiplexing and event handler dispatching. In Proceedings of the 1st Pattern Languages of Programs Conference , August 1994. [9] A. Soto, S. Vila, and A. Vinacua. A To olkit for constructing command driven graphics programs. Computer & Graphics , 16(4):375{382, 1992. [10] R. Srinivasan. Rfc 1832: Xdr: External data representation standard, August 1995. [11] B. B. Welch. Practical Programming in Tcl and Tk . Prentice Hall PTR. Upp er Saddle River, New Jersey 07458, 1995. APPENDIX: AN EXAMPLE OF THE AUTOMATICALLY GENERATED CODE Using the p ortion of the volum pro cess interface shown in gure 3 the Atlas co de generator makes automatically the les atl volum.hh , atl volum.H and atl volum.C which are partially depicted in gures 5 through 7. #ifndef __ATL_vo lu mh h_ _ #define __ATL_vo lu mh h_ _ #ifndef NOHEADER #include "volum.h" #endif #include "atl_volu m. H" scene segmentati on (s ce ne, pr op ert y) ; void display_ sce ne (s ce ne) ; #endif Figure 5: The automatically generated atl volum.hh le. Figure 5 shows the co de generated to dene the C++ prototyp es for the two extern routines declared in the interface. This le also includes the volum.h le implemented by the develop er b ecause the prototyp es use pro cess typ es only known by the develop er co de. In gure 6 we can see two of the ve bridge type denitions corresp onding to the exp orted typ es dened in the interface: the most simple one is the one corresp onding to a typ e denition which dep ends on another typ e de- ned b efore, and the other one is the one corresp onding to the most complex one whose contents dep end on another typ e dened b efore and its metho ds show how this bridge type is made from an Atlas Variable and backwards. These two metho ds make p ossible the automatic translation b etween the bridge type and the corresp onding Variable , isolating the develop er from this Atlas external representation. The last one, gure 7, shows a p ortion of the main co de of the driver. This co de includes an auxiliary routine for each one dened as an external routine in the interface (in the gure only the one for segmentation routine is shown), and the main routine of the communications driver. The auxiliary routine is the one to translate the parameter typ es from Variables to the pro cess typ es (through bridge types ) in order to call the pro cess routine in the correct way, and also to translate back the result of the pro cess routine to have a Variable to go through the network. The main routine of the driver only have to make some initializations for it and enter in the dispatching lo op. 7 ... namespace volum { typedef atl_pyra mi d atl_simpl ex; } namespace volum { struct atl_scene { atl_simp le x cont[10 0]; operator Variable () { // automati c translat io n to a Variable Type t("volum: :s cen e" , "V[100]S( nam e string,ba se V[3]S(p1 S(x real,y real,z real), p2 S(x real,y real,z real), ident integer) , sides V[3]V[3] S( p1 S(x real,y real,z real), p2 S(x real,y real,z real), ident integer) )" ); Variable v(t,"") ; v.build_ tr ee () ; for (int i1=0;i1 <10 0; i1 ++) { *((*(v.T re e( ))) .a cc ede (i 1) ) = *(((Vari ab le )c ont [i 1] ).T re e( )) ; } return (v); } atl_scen e( ) {} atl_scen e( Var ia bl e &v) { // construc to r from a Variable if (v.Tree() == NU LL) atl_exit (- 1) ; // Invalid variable for (int i1=0;i1 <10 0; i1 ++) { Variable v2("S(nam e string,ba se V[3]S(p1 S(x real,y real,z real), p2 S(x real,y real,z real), ident integer) , sides V[3]V[3] S(p 1 S(x real,y real,z real), p2 S(x real,y real,z real), ident integer) )" ," "); v2.build_ tr ee (); *(v2.Tree () )= *(( *( v. Tre e( )) ). acc ed e( i1) ); atl_simpl ex tpaux(v2 ); cont[i1]= tp au x; } } }; } ... Figure 6: Portion of the automatically generated atl volum.H le. Comunic_D is tr distrib( CAN AL _C OMU NI C_ DI STR ); String nameprogr am ; Driver driv(dist ri b) ; ... void aux_segm ent at io n( Str in g codi, DLList<Var ia bl e *> ¶mete rs ) { Pix p=paramet er s. fi rst () ; atl_scen e ptp0(*(pa ram et er s(p )) ); scene par0(ptp0 ); paramete rs .ne xt (p ); property ptp1(((n od ein t *)paramet er s(p )- >T ree () )- >G etv al ue ()) ; paramete rs .ne xt (p ); --> scene res=segme nt at ion (p ar 0,p tp 1) ; atl_scen e restp; restp=re s. con ve rs io n_t o_ br idg e_ ty pe (); Variable *vr=new Variable( res tp ); ReturnVa lu e *rv=new ReturnVal ue (c od i,v r) ; distrib. se nd( rv ); } ... void main(int argc,cha r **argv) { nameprog ra m=a rg v[ 0] ; ini_to_c al ls( ); // some inicializ ati on s for the driver driv.set _n ame _p ro gr am( na me pro gr am ); ini_proc es s() ; // inicial iza ti on s of the process itself driv.Dis pa tch () ; // loop close(CA NA L_C OM UN IC _DI ST R) ; exit(0); } Figure 7: Portion of the automatically generated atl volum.C le. The arrow has b een added p ointing to the p oint where user co de is actually invoked. 8