<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="description" content="Piper Design Proposal">
   <meta name="keywords" content="Piper">
   <title>Piper design proposal - Jarl van Katwijk</title>
</head>
<body text="#000000" bgcolor="#818FFF" link="#0000FF" vlink="#EE82EE">

<h1>
Piper Design Proposal</h1>

<h6>
version Thu Feb 15 2001</h6>
&nbsp;
<p>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h3>
1. Overview</h3>
Piper is a collaborative of separate layers, processes communicating by
CORBA. Instances of Piper communicate on P2P basis to each other.
<p>TODO: Write some more..
<h4>
<u>1.1 UIL</u></h4>
UIL stands for User Interface Layer, and is the only layer that a user
will see. There can be more than one UIL for a Piper instance. The UIL
doesn't depend on a curtain type of display, it might be a text console,
Xwindows display, or anything else.
<h4>
1.1.1 creation of networks</h4>

<h4>
1.1.2 ...</h4>
&nbsp;
<h4>
<u>1.2 DL</u></h4>
The Definition Layer (DL) provides the glue for connecting two different
parts of Piper:
<p>- The Build-Time System. This part of Piper involves the user acting
through the user interface to create an interconnecting set of programs
to be executed.
<br>- The Run-Time System. This part of Piper is responsible for execution
of programs and piping information between programs.
<p>The DL rests firmly between the User Interface Layer (UIL) and the brokering
layer (BL) and mediates communication between these two sections of Piper.
In
<br>addition, the DL is responsible for storing XML describing the current
status of the userinterface, storing specialized XML descriptions of programs
and libraries,
<br>and communicating with remote Piper implementations.
<br>&nbsp;
<h4>
1.2.1 UIL-DL communications</h4>
Maintain communication with multiple user interfaces through a streaming
XML dialog communication protocol. This communication occurs though a local
<br>socket and allows user interfaces to be developed in any programming
language that provides support for sockets.
<h4>
1.2.2 Storage of XML data</h4>
Storing an XML representation of the user interface. This XML representation
models the connections between different nodes in the user interface and
the
<br>interrelationships between them. These XML representation will allow
users to save entire user interfaces or individual nodes, and will provide
the ability for
<br>recovery after crashes.
<h4>
1.2.3 Permanent storage</h4>
Maintaining a permanent storage location for specially designed nodes that
represent speci?c programs and libraries. The information for these nodes
will be
<br>stored as XML and be available directly available to the user interface
through the streaming XML dialog.
<h4>
1.2.4 XML transformation</h4>
Converting the XML representation generated by the build-time system into
an XML format that can be processed by the run-time system.
<h4>
1.2.5 Controlling the PL</h4>
Communication with the processing portion of the program by implementing
a CORBA client to a server in the brokering layer. This communication allows
<br>work ?ow diagrams to be passed to the processing layers for implementation,
and allows processes to be queried while running.
<h4>
1.2.6 Remote UIL</h4>
Communication with remote Piper programs as both a client and a server
using CORBA (through an idl that still has to be de?ned). This allows a
speci?c
<br>implementation of Piper to serve out a specialized node or set of nodes
to be utilized by other Piper implementations at remote locations. All
aspects of this
<br>remote communication will pass through the de?nition layer.
<h4>
1.2.7 main logging, glib based?</h4>
(http://developer.gnome.org/doc/API/glib/glib-message-logging.html)
<h4>
1.2.5 Communication Protocols</h4>
1.2.5.1 User Interface to Definition Layer
<p>Multiple user interfaces can communicate with the de?nition layer through
a CORBA interface de?ned in the IDL (interface de?nition language) ?le
uil2dl.idl.
<br>Further information on this communication is available in How To Write
a User Interface for Piper. Using CORBA for this communication protocol
allows user
<br>interfaces to be written in any language supporting CORBA language
bindings.
<p>1.2.5.2 Definition Layer to Processing Layer
<p>Communication between the de?nition and processing layers occurs using
a CORBA interface described in the interface de?nition language ?le vsh_dl2bl.idl.
<br>This communication occurs in three broad steps:
<p>1. The de?nition layer negotiates a connecting with the processing layer
and receives a unique id, the dlid for which to identify itself in future
communication.
<br>This connection is established by calling the following idl de?ned
function:
<p>interface Connection {
<br>processorS setup(in dlIdT dlid, in passwordT password,
<br>in connectionE connecttype) raises (IdInUse);
<br>};
<p>2. The de?nition layer uploads an XML document representing the programs
to be processed and the connections between them. This XML document will
then
<br>be parsed by the brokering layer and used to begin running the programs.
The brokering layer returns a URI id which the de?nition layer can then
use to further
<br>communicate with the brokering layer about the status of the processing.
The upload occurs through the following method:
<p>interface Representation {
<br>&nbsp;&nbsp;&nbsp; uriS upload(in string xmldocument, in dlIdT dlid,
<br>&nbsp;&nbsp;&nbsp; in passwordT password) raises (UriUndefined);
<br>};
<p>3. The de?nition layer then queries the brokering layer to determine
the status of different programs. When programs that return results are
?nished, the de?nition
<br>layer will then retrieve these results and return them to the user
interface to be displayed. Query and retrieval of processes are obtained
through the following:
<p>interface Obtain {
<br>&nbsp;&nbsp;&nbsp; statusS uriStatus(in uriS uri, in dlIdT dlid,
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in passwordT password) raises
(UriNotFound);
<br>&nbsp;&nbsp;&nbsp; string uriInfo(in passwordT processid, in uriS uri)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; raises (InfoNotAvailable);
<br>};
<br>&nbsp;
<h4>
<u>1.3 BL</u></h4>
BL stands for Brokering Layer. For every instance of Piper there will be
only one BL running. The task of the BL are:
<br>&nbsp;
<h4>
1.3.1 brokering of DL-PL data flow</h4>
Data traffic between the DL and PL will be transported by the BL. Corba
is the technology used all over Piper, it's used to do DL-BL and BL-PL
transports. All DL-PL communication is XML formatted, and at runtime labeled
by BL with a URI identifier :
<br>&nbsp;&nbsp;&nbsp; /**
<br>&nbsp;&nbsp;&nbsp;&nbsp; * URI type, a locating id:
<br>&nbsp;&nbsp;&nbsp;&nbsp; * uriT is in a IP (Internet protocol) style
<br>&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uriT = 2.0.0
-> All subnets and nodes local in instance 2
<br>&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uriT = 74.35.0
-> All nodes in subnet 35 of instance 74.
<br>&nbsp;&nbsp;&nbsp;&nbsp; *&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; uriT = 1.2.3
-> Node 3 in subnet 2 of instance 1.
<br>&nbsp;&nbsp;&nbsp;&nbsp; */
<br>&nbsp;&nbsp;&nbsp; struct uriS {
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dlIdT instanceID;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* Set by BL to DLid of DL that generated XML stream */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; blIdT subnetID;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* BL sets this */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; plIdT nodeID;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* ?PL sets this, ?BL parses XML */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; string description;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* ?ripped out XML, ?defined by DL */
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; statusS status;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/* BL handles this flag */
<br>&nbsp;&nbsp;&nbsp; };
<p>BL is capable of multiple instance communication, it uses a 'bookmarks'
list to locate other Piper instances. Remote Piper systems will be automatically
queried for available resources and nodes (?interfaces, ?public resources).
The BL will handshake to he BL of remote Piper instances that responded
to a query. All available nodes will be send in both ways during a BL handshake.
Available nodes include those nodes that are publicly available and those
in an area(*) that is active on the receiving BL. An area in a set of nodes
that all share the same area id. Those nodes can spread across Piper instances.
<br>&nbsp;
<h4>
1.3.2 communication between instances of Piper</h4>
BL - BL communications are not defined yet. A good candidate CorbaSec (http://cadse.cs.fiu.edu/corba/corbasec/faq/single-page/CORBASEC-FAQ.html).
But maybe it will turn out this implementation is too heavy for the modal
internet connection.
<p>TODO: Write idl \ communication API
<h4>
1.3.3 Security system</h4>
The BL should have a system that handles area's. An area is created by
the BL when a DL requests one. The area is given a unique number, the areaId.
The id and the password supplied by the DL at creation time will be needed
for access to that area. On the Piper instance where the area is created
(?area creation host), and at remote Piper's that host the area (?area
hosts). Closing down the area on a ?area host is not possible. Putting
tight quota's on an area on a ?area host is possible. The ?area creation
host can shut down the area, but by doing so, all parts of the area located
on remote systems will become separate area's, with new unique id's. ?area
hosts become ?are creation hosts once this happens.
<br>The implementation of the security system should be based on ?akenti
or ?sesame. Internally the BL should user the real node addressing, outside
the core, at the plugin- and DL-interfaces level, a different node id system
will block the interface to overrule the security.
<h4>
1.3.4 resource management</h4>
The BL policy is to obey resource quota's. Quota's can be set on ?networks
executed at once, ?cpu load, ?disk usage, ?ram usage, ? ... The BL does
active optimization of network execution. This is done by feeding historic
data about network execution times to an GP engine. Once the GP engine
starts to return hits with very high fitness, the BL will listen to the
GP engine instead of the DL. The GP expectations will overrule one node
parameter given by the DL. This is the requested location where the node
should be executed. The GP engine will might operate exploration, so produce
random results that indicate high finesses.
<h4>
1.3.5 ...</h4>
&nbsp;
<p>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h4>
<u>1.4 PL</u></h4>
PL stand for Processing Layer. A PL exists only during the execution of
a network. When a new network needs to be executed, a new PL is spawn for
that network. After the network is finished that PL quits running to. It
should do:
<h4>
1.4.1 execute networks</h4>

<h4>
1.4.2 handle legacy issues</h4>

<h4>
1.4.3 ...</h4>
&nbsp;
<p>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h4>
<u>1.5 GPL</u></h4>
GPL stands for Genetic Programming Layer. There is only one GPL for every
PIper instance. It's task are to:
<h4>
1.5.1 support DL, BL and PL with GP facilities</h4>

<h4>
1.5.2 use spare cpu cycles to process historic information for future optimizing</h4>

<h4>
1.5.3 ...</h4>
&nbsp;
<p>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h3>
<u>1.6 All Layers together</u></h3>
UIL &lt;--> uil2dl &lt;--> DL &lt;--> dl2bl &lt;--> BL &lt;--> bl2pl &lt;-->
PL&nbsp;&nbsp;&nbsp;&nbsp; &lt;==>&nbsp;&nbsp;&nbsp; <i><u>Executed Nodes
and Applications</u></i>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
dl2ail&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bl2ail&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
pl2ail
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+------------ AIL -------------+
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h3>
2. Interfaces of Layers</h3>
All layers communicate by Corba to each other. These interface have fixed
IDL definitions, and some additional properties like 1-1 or 1-N relationships,
security issues.
<br>&nbsp;
<h4>
<u>2.1 uil2dl</u></h4>
The UIL and DL have a 1-1 relation.
<p>TODO: Add uil2dl API
<br>&nbsp;
<h4>
<u>2.2 dl2bl</u></h4>
The DL and BL have a N-1 relation
<p><i>See ./piper/idl/DL2BL.idl for complete API</i>
<br>&nbsp;
<h4>
<u>2.3 dl2ail</u></h4>
The DL and AIL have a N-1 relation.
<p>TODO: Specify dl2ail
<h4>
<u>2.4 bl2pl</u></h4>
The BL and PL have a 1-N relation.
<p><i>See ./piper/idl/BL2PL.idl for complete API</i>
<h4>
<u>2.5 bl2ail</u></h4>
The BL and AIL have a 1-1 relation.
<p>TODO: Specify bl2ail
<br>&nbsp;
<h4>
<u>2.6 pl2ail</u></h4>
The PL and AIL have a N-1 relation.
<p>TODO: Specify pl2ail
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<h3>
3. Dependencies</h3>
These 3th party libraries are needed for Piper:
<p>- glib
<br>- gdk
<br>- gtk+
<br>- omniOrb
<br>- ...
<br>&nbsp;
<br>&nbsp;
<h4>
<i>Jarl van Katwijk<br>
Wed Feb. 14 10:53:42 CET 2001<br>
Den Haag, Netherlands</i></h4>
&nbsp;
</body>
</html>