Date[ July 29, 1998] Recordnr[ ] Stored[ file-cabinet, Papers Composition Who[ J. Magee, N. Dulay, J. Kramer Title[ Regis: A Constructive Development Environment for Distributed Programs Published[ IEE/IOP/BCS Distributed Systems Engineering, 1(5): 304-312, Sept 1994. Keywords[ Comment[ Other papers about Regis/Darwin: Ng, K. and Kramer, J.; Automated Support for Distributed Software Design, appeared in 7th International Workshop on Computer-aided Software Engineering (CASE 95) Mostly describes the Software Architect's Assistant, a visual tool to set up distributed systems. Magee, J. and Dulay, N. and Eisenbach, S. and Kramer, J.;Specifying Distributed Software Architectures, appeared in 5th European Software Engineering Conference (ESEC 95) Presents a formal model of Darwin in Robin Milner's Pi-Calculus. Magee, J. and Dulay, N. and Kramer, J.; Regis: A Constructive Development Environment for Distributed Programs; IEE/IOP/BCS Distributed Systems Engineering},Volume = {1},Number = {5},1994 Describes the most recent distributed execution environment for Darwin-structured applications. Summary[ Darwin is a configuration language, Regis is a system supporting Darwin and generating the distributed systems specified in Darwin. For each component an interface is specified that contains all incoming and outgoing links. These can be of different types (pipes, ports...). The communications are implemented by special C++ components. The components to be configured/assembled can be either composite components, consisting of a set of lower level components, or computation components. Latter are written in C++ and must inherit from a predefined class process. Darwin also allows to imbed directly program code in the component descriptions. Components are garbage collected after termination. Regis runs on a Unix environment, the components can run on different Unix-workstations. A mapping file defines on which processor of the multicomputer which component is run. My conclusions: Regis supports program generation for a homogeneous environment. The distribution seems only to be local - I do not know if it is suited for servers located outside the intranet. The components that are composed are controlled entirely by the configuration language and by Regis (automatic garbage collection) - no autonomous servers that exist and run independant of the client. No equivalents to "EXAMINE", "ESTIMATE". Legacy code probably could be brought in, but I have not seen this issue being specifically adressed. As far as I know, no commercial application. Notes of Louis: I looked at a bunch of papers from Imperial College, London. The head of that group is Jeff Kramer, the relevant URLs are: Regis: http://www-dse.doc.ic.ac.uk/~regis/ Darwin: http://www-dse.doc.ic.ac.uk/~jsc/research/darwin.html Some of their work is relevant for RapArch, Architecture, and RapNet (see below). Regis has been in use since 1992. Darwin/Regis ============ Regis is a programming environment aimed at supporting the development and execution of distributed program. A Regis program consists of loosely coupled components either directly written in C++ (primitive components) or constructed out of simpler subcomponents by using the Darwin language. As such, Darwin is an Architecture Description Language (ADL) remarkably similar to the RAPIDE ADL. The Regis environment lets you develop the individual C++ components and the composition using Darwin, then compiles everything into executables and runs it on distributed sites. Regis/Darwin is restricted to the design/implementation phase. Once the program is compiled, installed and running, it is on its own, there is no support for ongoing analysis. One '95 paper said they will do run-time monitoring and management, but that will probably be primitive (i.e. just monitoring if they still run) and may not even exist. They stress the fact that a Regis program can be distributed (a la mobile agents), but I don't think that is the exciting thing about it. The Darwin ADL -------------- Darwin boxes are called "components", action declaration are called "services", arrows are called "bindings". Like RAPIDE, Darwin specifies both provided as required services. Services are typed and type conformance is enforced. Darwin allows hierarchical composition of components as well as parametrization, a component can consist of n subcomponents, with n decided statically at run time or dynamically at runtime. The latter is what they call dynamic architectures. In both cases, all n components have the same type, bindings, etc. This is just simple instantiation of a class. In some aspects Darwin is more general than Rapide ADL. The communication mechanism is not restricted to events. Darwin supports any communication mechanism (events, streams, RPC, etc. In Regis, the mechanism is then implemented as a C++ class). Thus the type of an action denotes the C++ class that implements it. A Darwin filter on a stream of characters would look like component filter { provide output; require input; } A funny thing happens when one looks at services of type "port". A port is used to send messages through and is interpreted in a procedure call style. Thus, to send a message, a sensor *requires* a port, the "output" becomes "required". The following comes from their paper and seems wrong for a RAPIDE person (at least for me). component sensor { provide input; require output; } I guess they run into this problem because they support both push (stream, event) and pull (port) communication with others. Pi-calculus ----------- Darwin is also specified in Milner's \pi-calculus. This is an elementary calculus for describing and analyzing concurrent, independent processes that communicate via channels. A subset of the Pi-calculus (http://www.cwi.nl/~arie/picalc.html) seems to be a candidate for our RapNet composition language. Software Architect Assistant ---------------------------- Regis comes with a graphical architecting tool called Software Architect Assistant (SAA), similar to RapArch. In comparison to RapArch, SAA's focus is more on providing semantics and ease-of-use and less on providing fancy drawing capabilities. All "boxes" have the same size, and "arrows" are laid out automatically by the tool and cannot be changed. (See http://www-dse.doc.ic.ac.uk/sel/sereports/rj1/rj1.html for an evaluation.) On the other hand, boxes and arrow have full semantic meaning, and correctness is checked at data entry point. The graphical and the textual view are always consistent. I especially like the separation between connections and interfaces. The "arrow" is just a line, the ending points indicating in which direction it points are part of the "box". This makes sense, because when you define a box, it is already clear which "actions" are "required" and which are "provided". SAA also displays nicely how services are connected when components are hierarchically encapsulated in each other. SAA also supports libraries of components, that can be included as sub-components in other components and it can read Darwin (textual) code not written by SAA. The SAA exports RTF reports that can be directly imported into word processors.