Conference heron::euro_swas_ai

276.0. "FYI: Trellis/DOWL" by YIPPEE::TARANTOLA (Carlo *AI IST* @VBE) Thu Feb 07 1991 13:45

        <<< CLT::DISK$CLT_LIBRARY3:[NOTES$LIBRARY]OO_PROGRAM.NOTE;1 >>>
                   -< Object-Oriented (Technology) Program >-
================================================================================
Note 58.0               Distributed Trellis announcement               1 replies
LUTZ::HEUSER "Lutz Heuser, CEC Karlsruhe"            49 lines   1-FEB-1991 12:28
--------------------------------------------------------------------------------

				A N N O U N C E M E N T

	Today the DOCASE project presents:

			       +--------------+
			       | Trellis/DOWL |
			       +--------------+

	Trellis/DOWL is a distributed version of Trellis consisting of both
	an upwards compatible programming language and an upwards compatible
	type library.

	Trellis/DOWL is part of the overall DOCASE effort which will support
	the development of distributed object-oriented applications. DOCASE
	itself is one of the key projects of the DIAMANT program driven by
	the CEC Karlsruhe. DOCASE is a joint project of Digital's CEC and two
	external research organization, the Institute for Telematics at the
	University of Karlsruhe and the	AG Telematics at the University of
	Kaiserslautern.

	Since 1988 several components of DOCASE were successfully developed and
	transferred to various sites within Digital. Trellis/DOWL is one of the
	first languages supporting distribution for object-oriented programs.
	It is an upfront research effort which was also presented at
	the international TOOLS'89 conference.

	Trellis/DOWL allows application programmers to write distributed
	programs having high abstraction, i.e. not worrying about network
	protocols or any services. It leads to a new generation of languages.

	The current prototype is the first one of a series. The goal of it is
	to give a first impression to the Trellis user comunity. In addition,
	feedback and comments are more than welcome to identify the needs
	for such an effort inside and outside Digital.

	Comments can be either mailed to KAMPUS::HEUSER or
	DECWRL::"bruno@informatik.uni-kl.de".

	The kit is located at


		nestvx::~guest/DOWL-V1.0.tar.Z
		==============================

	The first reply to this mail is the README file from the kit.

	Lutz Heuser		Bruno Achauer

================================================================================
Note 58.1               Distributed Trellis announcement                  1 of 1
LUTZ::HEUSER "Lutz Heuser, CEC Karlsruhe"           358 lines   1-FEB-1991 12:32
                               -< README file >-
--------------------------------------------------------------------------------
		The DOCASE project proudly presents:

			Trellis/DOWL V0.0
			=================



Trellis/DOWL (or short DOWL) extends the Trellis system to support
distribution. Its key features are:

  * a distributed, object-oriented language

  * upward compatible to Trellis (at user code level)

  * supports distributed, volatile objects

  * ability to move objects between the nodes of the distributed system

  * transparent operation invocation on remote objects

  * linguistic support to describe location relationships between objects

Distribution in DOWL is largely transparent: a programmers never sees
it unless he explicitely requests to. In particular, invoking an
operation on an object residing on a remote node has exactly the same
effect as if performed locally, except for a performance penalty.
Therefore, applications can easily be developed and debugged in a
single-node environment and then moved to the network.


A few extensions to the Trellis system allow to control distribution.
To separate mechanism from policy, only a minimal set of primitives is
built into the system; other, more powerful mechanisms can be
constructed out of these building blocks as required by the
characteristics of the application to be distributed.


Here are some sample language features:

  * determine foo's location:

	foo.$location

  * move foo to the node where bar resides (this works even if there
    are active method invocations on foo):

	foo.$location := bar

  * move foo to a node and keep it there until made mobile again:

	foo.$fixed_at := some_node;

  * make foo mobile:

	foo.$fixed_at := Nil;

  * tell the system that bar should move also if foo moves:

	type_module foo
	    component me.bar: $attached object is field;

  * specify how arguments are passed to operations on remote objects:

	operation foo(me, bar: $move Object, baz: $visit Object)

Contents of the DOWL Kit
========================

The following files are part of the DOWL kit:

    bin/trellis_dowl		- the DOWL executable.

    demo/			- Examples (see below):

	docase_demo.owl		- The DOCASE mail system demo.
	dowl_demo.owl		- Demo to show some DOWL features.
	dowl_demo.eval		- Evaluator script for the DOWL demo.

    docs/			- Documentation:

	edowl.txt		- Describes EDOWL.
	tools89.ps		- Describes our motivation for
				  creating distributed Trellis.
	syntax.ps		- Documents DOWL's extensions to the
				  Trellis language and library.

    edowl/			- Contain sources required to
    trellis/			  build the workspaces (see below).


    wspdir/			- Contains the workspaces:

	trellis.wsp		- This is the raw workspace required
				  to run distributed Trellis. Contains
				  the Trellis programming environment.
	dowl.wsp		- Built on top of trellis.wsp.
				  Contains a few demo programs.
	edowl.wsp		- Contains the EDOWL system.


Building DOWL
-------------

We don't distribute a ready-to-run kit to save network bandwith.
Instead, you have to build the workspaces yourself. You will need:

  - A VAX running Ultrix 3.1 or higher.
  - Enough swap space (at least 20MB for each DOWL process).
  - 5.5 MB of disk space for the raw distribution kit.
  - Aprox. 30 MB of disk space to build either wspdir/dowl.wsp or
    wspdir/edowl.wsp.
  - Additional disk space to hold your own workspaces. The exact
    amount depends on your applications, but you'll need at least
    14 MB for one workspace. You can delete either wspdir/trellis.wsp
    or wspdir/dowl.wsp; this will free about 14 MB.


You have to follow these steps to build DOWL or EDOWL:

  1. Cd to the trellis subdirectory.
  2. Type "make dowl" or "make edowl" to build wspdir/dowl.wsp
     or wspdir/edowl.wsp, respectively.

Depending on your machine and how much memory you have, the second
step will take some time (a VaxStation 3100 with 16MB needs about 50
minutes for it).

Don't worry about the compiler messages issued by step 2, they're
normal. If anything is really wrong, there will be some beeps and
the advice to "call implementers".

Running DOWL
============

The current DOWL version defines each node in the network to be
running in one of three modes:

  * A node in STANDALONE MODE runs without any connection to the
    network; the system behaves essentially like a Trellis system.

  * The first node of a distributed system must run in PRIMARY SITE
    MODE. All other nodes will query this node to obtain information
    about the network.

  * All other nodes are in SECONDARY SITE MODE.

The prototype requires that each node of the system runs on top of
exactly the same workspace; therefore, compiling and saving a
workspace is only possible while in standalone mode.



To run a distributed application, follow these steps:

  1. Develop your application on a standalone node. Save the workspace.
  2. Start a primary site.
  3. After the primary site is up and running, start secondary sites.



A couple of new command line options determine mode and details of
communication for a DOWL node; asterisks indicate how far the options
can be abbreviated:

  -standalone

     Run the node in standalone mode. This is the default.

  -prim*ary_site <name>

     Run the node in primary site mode, using <name> as the node's
     logical name (i.e. value of Local_Node(DOWL_Node).node_name).
     Node names must be unique and cannot be reused, even after a
     node went down.

  -sec*ondary_site <name>

     Run the node in secondary site mode. Again, <name> identifies
     the node's logical name.

  -ps_node <name>

     Tells a secondary site the name of the primary site's
     *physical* node (i.e. the name of the computer on which the
     primary node was started).

  -port <number>

     Every DOWL node listens on an internet socket for connection
     attempts from other nodes. The socket's address is determined by
     the node's physical name and a default port number (4711). If
     the default port conflicts with something else in your system
     or if you are running several logical nodes on the same physical
     node, use this option to override the default port.

     IMPORTANT: Logical nodes running on the same physical node
                must have distinct port numbers.

  -ps_port <number>

     Tells secondary sites that the primary site has changed its
     default port number.



Examples:
---------

  * Standalone mode. Batch-compile foo.owl, run the programming
    environment, then collect and save the workspace:

      katrx1% trellis_dowl -work $WSPDIR/trellis.wsp \
                           -compile foo.owl -run -collect \
                           -save $WSPDIR/foo.wsp

  * Start a distributed system of three nodes, using default port
    numbers:

      katrx1% trellis_dowl -primary node_1 \
                           -work $WSPDIR/foo.wsp -run

      katrx2% trellis_dowl -secondary node_2 -ps_node katrx1 \
                           -work $WSPDIR/foo.wsp -run

      katrx3% trellis_dowl -secondary node_3 -ps_node katrx1 \
                           -work $WSPDIR/foo.wsp -run

  * Start a distributed system of two nodes running on the same
    physical node. Use alternative port numbers:

      katrx1% trellis_dowl -primary node_1 \
                           -port 8613 \
                           -work $WSPDIR/foo.wsp -run

      katrx2% trellis_dowl -secondary node_2 -ps_node katrx1 \
                           -port 8614 -ps_port 8613 \
                           -work $WSPDIR/foo.wsp -run
Prepared Demos
==============

Dowl.wsp contains two pre-built demonstration programs: a little type
module to show some of DOWL's features and an implementation of the
simple mail system from the DOCASE V1.0 kit. This workspace is also
prepared to share results from the evaluator tool between all nodes;
i.e. you can access symbols defined in one evaluator from any other
evaluator in the system.



Running the DOWL test demo
--------------------------

  * Start a distributed system with two nodes:

      katrx1% trellis_dowl -primary katrx1 \
			   -work dowl.wsp -run

      katrx2% trellis_dowl -secondary katrx2  -ps_node katrx1 \
			   -work dowl.wsp -run


  * Demo/dowl_demo.eval contains an evaluator script for the demo. You
    can either type these expressions in the evaluator tool and
    evaluate them, or you can simply load the script into the file
    tool, select an expressions by triple-clicking on it and then
    evaluate it.

    To run the demo, follow the instructions in the evaluator script.


  * At any point, you can use an inspector tool to examine the test
    object and determine its location. This is especially valuable if
    you get lost in the example and don't know where the object
    currently resides.



Running the DOCASE mail demo
----------------------------

This demo, borrowed from the DOCASE V1.0 kit, models a mail system
connecting four members of the DOCASE team. Each team member has its
own mailbox with a list of mail messages. Mailboxes are distributed
over three logical nodes, uni_ka, uni_kl and dec_cec, and allow their
owners to receive and read mail messages and to send messages to other
team members. Mailbox functions are accessible through a mailbox tool.


The following steps are needed to start the demo:

* Start three logical nodes:

    katrx1% trellis_dowl -primary uni_ka \
			 -work dowl.wsp -run

    katrx2% trellis_dowl -secondary dec_cec -ps_node katrx1 \
			 -work dowl.wsp -run

    katrx3% trellis_dowl -secondary uni_kl -ps_node katrx1 \
			 -work dowl.wsp -run


* Initialize the mail system from an evaluator tool (on any node). This
  will also create the mailbox tools:

	mb := initialize(Mail_System)



Known Bugs and Limitations
==========================

This is the first DOWL prototype, and it contains some restrictions.
In particular, we are aware of the following:

  - DOWL is built on top of a now obsolete version of Trellis, and
    it runs only on VAX/Ultrix.

  - Invoking an iterator on a remote object doesn't work.

  - Garbage collecting a running system will corrupt the workspace;
    the "gc-temp" and "gc-all" buttons in the storage tool are disabled.

  - The protocol to forward updates to a fixed name or a mytype
    component is not yet implemented. Result is that each node
    in the system has its own copy of every fixed name and mytype
    component. (However, there is a workaround for fixed names).

  - The language constructs to describe distribution of fixed names and
    mytype components are not sufficient. There is no mechanism to
    specify whether a fixed name should be global to all workspaces
    or replicated.

  - This version does not allow to use the compiler while running the
    distributed system. Code has to be developed in a single-node
    environment and the distributed system has to be restarted from
    scratch. This leads to annoying delays in the development cycle.

  - There is no way to shut down a node gracefully.

  - Error handling in general is very poor.

  - There is no distributed garbage collection yet.


We are currently working on merging our extensions to Trellis V1.0 and
porting the system to MIPS/Ultrix (sorry, no VMS version is planned
yet). In this version, all bugs (i.e. items 2 through 5) from the
above list will be fixed. The other topics need some more work:

  - To get an idea what constructs are needed for the handling of
    global variables, we are planning to port a rather large
    application to DOWL.

  - Not being able to add or modify code interactively hurts us most
    at this moment. We have some ideas on how to reduce this
    restriction, but a general solution is still far away.