Current researchEclipse a distributed softwaredevelopment environmentby David Hutchison and Jonathan WalpoleEclipse is an integrated project support environment (IPSE) whosepurpose is to support the development of software systems fromthe specification stage through to their operation and maintenance.It is being developed by a consortium of universities andcompanies with funding from the GK Science and EngineeringResearch Council and the national Alvey programme. Eclipse is adistributed IPSE using high-powered workstations and both localand wide area networks. This paper presents an overview of theEclipse project and a more detailed description of Eclipse'sdistributed architecture.1 Eclipse overview

1.1 BackgroundEclipse is an integrated project support

environment (IPSE) being developed by aconsortium with funding from the Alveyprogramme and the (JK Science andEngineering Research Council. The con-sortium is led by Software Sciences Ltd.,with CAP (GK) Ltd., Learmonth BurchettManagement Systems, the Universities ofLancaster and Strathclyde and the Univer-sity College of Wales at Aberystwyth.

It is intended to provide assistance inthe development of large-scale, long-term projects involving teams of peoplepossibly on geographically distributedsites. The main result of this assistancewill be a reduction in the full life-cycle costof the software product. This will beachieved in Eclipse by providing assis-tance in the organisation of the project, itsmanagement, and the ability to representand handle the software system as awhole, as well as improving the workingenvironmentof the projectteam member.

Facilities that will improve the effective-ness of a team member using Eclipseinclude the ability to share information ina common database and the provision ofan advanced user interface that includestext, menus, forms and diagrams.

Eclipse is a 'mainframe' IPSE, powerassisted by workstations. The centralmainframes are DEC VAX 11 seriesmachines running the UNIXf 4.2BSDoperating system, connected to the work-stations by an Ethernet local area net-work. The workstations also run UNIX4.2BSD and tend to have a mouse point-ing device, multiple windows, graphicsand multiple fonts. Eclipse will also incor-porate inter-VAX connections over widearea networks.

Since Eclipse is to hold and manipulateall the information in a large softwaredevelopment project it incorporates adatabase which is held on each VAX. Thisis the SDS-2 database which was designedby Software Sciences Ltd. specifically tosupport software development by largeteams [ 1 ].

1.2 Eclipse objects

SDS-2 is used to provide a two-tierdatabase in which data are stored in anumber of versioned units each of whichcomprises an object in the first tier andoptionally an object body in the secondtier. The object in the first tier containscontrol attributes, and either the infor-mation itself or a pointer to an object bodyin the second tier containing the infor-

directory

m0 0 0

t/1 \000 k11 \0 00

Omega

catalogues

items objects

Fig. 1 Eclipse naming scheme

88

mation. Object bodies are stored in thefilestore of the underlying operating sys-tem, in this case the UNIX filestore.

Objects are named in Eclipse using ahierarchical naming scheme, in whichobjects belong to 'items', which in turn aregrouped into 'catalogues'. The root of thenaming tree is a special catalogue calledOmega, and objects are named by speci-fying the pathname from Omega. Eachobject belongs to a single item and is dis-tinguished from other objects belonging tothat item by its control attributes. An item isintended to represent a software compo-nent and objects are intended to representparticular versions of that component. Allthe information about how an object wascreated is recorded in Eclipse, and there-fore objects are reproducible [2]. Userviews are also provided in SDS-2 in theform of directories, which allow users togroup together particular items orcatalogues.

2.3 The Eclipse objectmanagement system (OMS)

Built on top of SDS-2 is the Eclipseobject management system which offerssupport in the areas of:

documentation control andmanagement configuration management andcontrol automatic system building analysing the impact of potentialchanges to the database recording maintenance and proces-sing of project management information testing control release control.

Eclipse's database may be accesseddirectly via the SDS-2 software, orthrough the Eclipse OMS version andvariant control software which gives adatabase of versioned objects.

1.4 Layers in Eclipse

Eclipse is structured as a central corewith outer cladding. The core of Eclipse is

fCINIX is a trademark of AT&T BellLaboratories.

Software Engineering Journal March 1986

considered to be application indepen-dent, and includes: the Eclipse object managementsystem distribution over several machines the integrated tools interface (IT1) the man machine interface (MMI) the SDS-2 database.The rest of Eclipse is the outer claddingand consists of: methodology support tools (provid-ing support for the MASCOT, LSDM, JSD,and VDM software design methodologies) Ada cross-development (tools fordeveloping, loading and testing Ada pro-grams to be executed on a targetcomputer without an Ada compiler) software re-use and fast prototyping diagramming capability.Eclipse is however intended to be open, inthat it should: potentially support any developmentmethodology allow the use of existing tools in thehost operating system allow the incorporation of foreigntools (tools written with no knowledge ofEclipse).Foreign tools are intitiated under the con-trol of Eclipse but do not access thedatabase, whereas integrated tools areinterfaced directly to the Eclipsedatabase. The integrated tools interfaceoffers a uniform interface to the facilitiesof the Eclipse database, and allows tooland methodology implementors tospecify the internal structure of versionedobjects using the interface definition lan-guage for Eclipse (IDLE). IDLE wasderived from the interface definition lan-guage 1DL developed at Carnegie-MellonUniversity in the USA [3].

In order to meet the demands men-tioned above, the interfaces to Eclipse willbe well specified and will be made public.

A phased approach is being adopted inthe development of Eclipse. Version 1 ofEclipse, currently being developed, willhave a restricted architecture to allow thedevelopment of initial versions of the coreand cladding. The final version of Eclipsewill be a prototype 1PSE.Ada is a registered trademark of theGovernment, Ada Joint Program Office.

foreigntools

foreigntoolsinterface

MMI

all tools andmethodologiesthat integratewith thedatabase

integratedtoolsinterface (ITI)

automaticbuild &releasecontrol

Eclipse object management system

directaccesstoSDS-2e.g.onlinebrowse

SDS-2 database

UNIX A.2BSD filestore

Fig. 2 Layers in Eclipse

2 Aims of the distribution project

The development of a large software sys-tem frequently involves work on morethan one computer, possibly on separatesites. Eclipse must provide support forsuch configurations and will therefore usea network of computers. This will involvecommunication over both local and widearea networks and will support the dis-tribution of processing and data.

The aims of the distribution project are:

to provide the protocols for distribu-ting processing and data across aninternetwork to design and build the software archi-tectures required to enable Eclipse tooperate over this internetwork.The distribution project is concerned withboth local and wide area networks [4],configured as follows: Workstations connected to a VAX via alocal area network. This is an Ethernet inwhich all the workstations on the local siteare connected directly to each other andto the VAX. The VAX is, however, con-sidered to be a central machine as com-munication will usually be between aworkstation and the VAX rather thanbetween two workstations. The architec-ture is therefore logically a star with theVAX at the centre and the workstationsaround it (see Fig. 3). An internetwork of local area networksand wide area networks, with VAXes (eachassociated with a LAN) connected

together by a wide area network (WAN)(see Fig. 4).Distribution between workstations andthe VAX over a local area network willrequire a different strategy than betweentwo VAXes over a wide area network,owing to the differences in link speeds. Inthe long term, we take the view that thecommunication between two VAXes willapproach the speed of the communi-cation over local area networks (forexample British Telecom's Megastream)[5]. Within the timescales of the project,however, we have only Packet SwitchStream (PSS) or Kilostream (see alsoRef. 5) data rates available over WAN con-nections, that is of the order of a thousandbits per second rather than a million. Thisis a constraint under which we have towork across the WAN in the project.

The SDS-2 database has beendesigned to run in a single machine. Itdoes not make sense technically toattempt to produce a distributed form ofSDS-2 within the timescales of this pro-ject. Because we cannot distribute SDS-2,the question of a distributed databasedoes not arise. We are, however, distribu-ting processing about the system,although this will not be done dynam-ically. Data bodies will be taken to proces-sing sites, but under the control of theEclipse environment. The choice of whichmachine is to run a particular process willbe predetermined on the basis of suchthings as its interaction with the user ordatabase and the amount of processingrequired.

Fig. 3 LAN configurationa physical b logical ws = workstation Fig. 4 WAN configuration

Software Engineering Journal March 1986 89

worbstettaiA

window

application

ITI VI

filestorerep

VAX

rtogln

r loginterminal

SDS-2applicationservices

lEclipse OMS

SDS-2database)

versionedstore

(Import/export)

Fig. 5 Phase 1 architectureStandard use of UNIX is allowed in this architecture configuration

UDP

rep , rloginTCP

IP ARP

Ethernet (CSMA/CD)

Fig. 6 Internet protocol set

Co-operation between several data-bases within a single Eclipse will becatered for, and this includes the develop-ment of a naming scheme for multiple-database Eclipses.

The distribution project is undertakinga phased approach to solving these prob-lems, the phases being timed to coincidewith the three releases of Eclipse:

Phase 1: Workstation-VAX config-uration across a LAN. Implementation ofsuitable protocols to enable communi-cation between workstations and the VAXand to allow 'import' and 'export' ofbodies between Eclipse and the work-station (see Section 4). Phase 2: Full integrated access tothe Eclipse database from tools executingon a workstation. Co-ordination betweenseparate Eclipses across a WAN underexplicit human control. Phase 3: Unified Eclipse over aninternetwork (LAN/WAN combination)with decisions made transparently to theuser (the unified Eclipse should look justlike a local Eclipse to the user).

3 The workstation environment

The efficiency and quality of the userinterface to Eclipse is an important factorin determining the efficiency of the user. Itis for this reason that Eclipse is a main-frame IPSE, power assisted by work-stations. The workstations provide localstorage and processing power, whichenables a fast and consistent response

rate to be provided.The Ethernet local area network

ensures rapid workstation interaction withthe database and with other users ifnecessary.

Sun Microsystems workstations arecurrently being used for developmentwithin the project, but it is intended thatother types of workstation will be used astargets within Eclipse in the future.

Sun workstations

The workstations currently in use areavailable with:

10MHzMC68010CPCJ 2 Mbytes of main memory 42 or 71 Mbyte disk 10 Mbit/s Ethernet 1152 x 900 pixel high-resolution bit-mapped graphics 'mouse' pointing device multi-window display UNIX 4.2BSD operating system.Eclipse will support dot-matrix printers,laser printers, letter quality printers andplotters to provide hard copy output. Intel80286 processors will be connected tothe VAX for Ada cross-developmentpurposes.

4 Phase 1: import/export

We are implementing two separate archi-tectures for Eclipse during the project.

The architecture for phase 1 of the pro-ject is being developed to meet the tighttimescales for the first release of Eclipse,and is therefore less ambitious than thearchitecture for phases 2 and 3 of theproject.

Phase 1 architecture

For phase 1 of Eclipse there is no directinterface to the two tier database. Object

bodies may be exported to the work-station for processing and then importedback to the database. Export is a functionwhich returns a structured filestore file.Import is a function that takes a localfilestore file and stores it in the databaseas a new version of the nominated item.

A restricted version of the integratedtools interface ITI VI will be used in phase1 of the project. The data in a structuredbody may be interpreted by ITI VI as longas the structure is specified using IDLE.ITI VI also imposes the restriction thatrelationships within structured bodiesmust not refer to other bodies or otherparts of the database. This is necessarybecause ITI VI is not capable of interpret-ing the information within a structuredbody in order to export further objects thatmay be needed as a result of such refer-ences. This is a restriction that will notappear in the later versions of Eclipse.

In this architecture we intend to providethe following:

Access to SDS-2 from the workstationby means of a remote login facility. TheSDS-2 code will remain entirely on theVAX. Access to the Eclipse OMS on the VAXfrom the workstation as in the pointabove. Access to the Eclipse OMS via theEclipse ITI VI from the workstation forimport/export of objects. Standard use of the Eclipse OMSfrom the VAX. Standard use of UNIX on workstationsand VAX, and standard use of UNIX on theVAX from a workstation.

The import-export architecture will bedeveloped solely for phase 1 of the projectin order to provide a framework withinwhich the other elements of Eclipse canbe tested. This architecture is shown inFig. 5.

For phase 1 of Eclipse, the Berkeleyprotocol set that is available with UNIX4.2BSD will be used as follows:

File transfers will be carried out using'rep' Berkeley's remote file copymechanism. For logging on to remote machinesBerkeley's remote login mechanism'rlogin' will be used.These Berkeley protocols were writtenspecifically for efficient performancealong with UNIX 4.2BSD, and sit on top ofthe Internet TCP/IP protocol set.

The Internet protocol set is used inEclipse over an Ethernet local area net-work, and contains the followingprotocols:

GDP: universal datagram protocol (abasis for experimental connectionlessprotocols).

90 Software Engineering Journal March 1986

TCP: transmission control protocol[6] (a virtual circuit protocol). IP: Internet protocol [7]. ARP: address resolution protocol(resolves conflicts between TCP/IP andEthernet addressing schemes).The Internet protocol is a simple data-gram protocol developed by the CISDARPA for use over ARPANET. IP hasbeen under development since 1973 andis now widely accepted. The rest of theInternet protocol set consists of higher-level protocols built around IP to supportparticular applications (see Fig. 6).

Inter-process communication inEclipse will use the UNIX 4.2BSD socketmechanism and Internet domain sockets[8].

5 Phases 2 and 3We consider phases 2 and 3 together as asingle architecture plan. For this archi-tecture we envisage two working environ-ments, the Eclipse environment, in whichthe user actions are strictly recorded, andthe UNIX environment.

In the UNIX environment the user will beable to gain direct access to SDS-2 fromthe workstation as in the phase 1 archi-tecture. The user will also be able to usetools which run on the VAX and operateon the VAX filestore as well as using localworkstation tools on local filestore.

In the Eclipse environment the usercommands will be passed through theEclipse ITI to enable strict monitoring tobe performed. The Eclipse ITI is imple-mented as shown in Fig. 7.

Applications wishing to access thedatabase do so through the ITI. There isone instance of the workstation ITI pro-cess per application process but only oneinstance of the VAX ITI process per 'login'.This enables several application pro-cesses to have a single view of thedatabase.

The workstation ITI process communi-cates with the ITI kernel on the VAX via theUNIX 'socket' interprocess communi-cation mechanism. UNIX sockets may beused to implement both datagram andvirtual circuit communications. Virtual cir-cuit socket communication provides asequenced, reliable, two-way connection-based service, whereas datagram socketsprovide an unreliable, connectionless ser-vice for passing messages. We will beexperimenting with both datagram andvirtual circuit connections between work-station and VAX and will be using Internetaddressing.

The ITI kernel process on the VAX offersa procedural interface to the workstationITI, and we will be using a remote pro-cedure call mechanism on top of theinterprocess communication connection.

We will also use a file transfer protocolover a virtual circuit connection to trans-

workstation 1 VAM

| ITI switch/ \

[IDLE |- keroelstu6

remoteprocedure

'( IPCmechanism)

s\ ITI kernel |/ \

j SDS-2|-| Eclipse OMS|

Fig. 7 Workstation-VAX interprocess communication (IPC)

VAX

wifidow terminal

application application

ITI (w/s) |

kernelstub

IiI I ITI (m/ f> 1I

ITI kernelIPC

filestore

Ecli

1 SDS-2 d / b versionedstore

Fig. 8 Phase 2/3 architectureport objects between the workstationfilestore and the database.

It is likely that the users of a workstationwill want to access only a small proportionof the objects in the SDS-2 database,however, and these objects will probablybe accessed fairly frequently. In order tomake this access more efficient we intendto implement a cache system to allowcopies of objects to be stored on the work-station. Copies of objects stored in thiscache are read only, and hence there areno multiple copy update problemsinvolved. Changes are made by creating anew object which may then be registeredin the SDS-2 database. This is interpretedas forming a new version of the item in thedatabase.

Objects may not be destroyed in thissystem, but if unlinked they will be subjectto a garbage collection process.

We are also investigating methods fortransmitting structured data across a net-work of heterogeneous machines, and wewill be looking into the problems of hand-ling inter-object references when using acache.

5.1 Remote procedure calls inEclipse

Remote procedure calls (RPCs) [9] willbe used in the second and third phases ofEclipse, and their use is shown in Fig. 7.

The remote procedure call model issimilar to that for local procedure calls.When a procedure is called locally thecaller places parameters to the procedurein an accessible place and transfers con-trol to the procedure, which on com-pletion returns control to the caller. Theresults of the procedure are then retrievedfrom some other accessible location andthe caller continues.

In the remote procedure call model, thecaller process sends a call message to adormant server process (usually on aremote machine) and then waits for areply message. The server then runs theprocedure with the parameters that werepassed as part of the call message. Theresults of the procedure are then passedback to the caller as part of the reply mes-sage and the caller continues. In thismodel a single thread of control passesthrough the caller process, the server pro-cess and then back to the caller process,that is, only one of the two processes isactive at one time.

In phases 2 and 3 of Eclipse, work-station operation involves the executionof procedures on the VAX to access andmanipulate objects in the database. Thetransfer of object bodies and controlattributes between the workstation file-store and the VAX is also involved, andthese operations will be implemented inthe form of a remote procedure call

Software Engineering Journal March 1986 91

| PM database |

\| site 1 | | site 2 | site n

Fig. 9 Hierarchy of databases

between the workstation ITI kernel stuband the ITI kernel on the VAX.

The RPC protocol to be used has not yetbeen decided, but may be either our ownimplementation or the Sun or Courierversions.

5.2 The Sun RPC

The RPC under development by SunMicrosystems uses the Internet protocolset as its underlying transport protocol. AtSun, their RPC is currently implementedon top of both TCP/IP and GDP/IP pro-tocols [10].

This RPC handles arbitrary data struc-tures and different machine byte ordersby converting them to the external datarepresentation (XDR) standard [11]before sending them over the network.Calls can be made from any language andbetween processes on the same or dif-ferent machines.

5.3 The Courier RPC

Courier is the Xerox remote procedurecall protocol [12] and was originallydesigned to use the XNS protocol set[13]. Courier has recently been imple-mented on top of the Internet TCP/IP pro-tocol set and is available experimentallyunder UNIX 4.2BSD.

Courier is both a protocol and a specifi-cation language. The protocol defines themethod of invoking remote procedures,and the language provides a means ofdescribing the remote interfaces withindistributed programs.

Courier enables a program on onemachine to invoke the execution of pro-cedures on a separate machine whilemaintaining the appearance of local pro-cedure execution.

5.4 Co-operating databases

In Eclipse, we aim to be able to build anarbitrary hierarchy of individual SDS-2databases which will behave as a singlelarge IPSE. There are two parts to be con-sidered for co-operation betweendatabases. These are:

one or more VAXes on the same siteconstituting a single IPSE (each VAX withits own copy of SDS-2) more than oneVAX may be needed owing to lack ofcapacity in processor/disk/memory a multi-site project using several92

1r

WSuser

ocal databasenachine

-

~

internetworklink

electronic mail channel

site mail manager(or secretary)

remote databasemachine

1 :

Fig. 10 Use of electronic mail for database co-operation

databases, to be seen as a (logically)single IPSE.

For either of these architectures, weenvisage a special 'project management'(PM) database at the top of the hierarchyfor the registration of software and controlof documents (see Fig. 9).

The PM database is considered to be atthe top of the hierarchy of databases foreach particular project and will containinformation about the contents of theother databases in the project.

Documents and software will be sub-mitted to a validation procedure beforebeing copied into the PM database. Weintend to make use of the facilitiesprovided by electronic mail (messagehandling system) for moving documentsand software between databases. This willtake place as shown in Fig. 10.

Document movements, including soft-ware, will take place up, down, and acrossthe logical hierarchy; if possible within theEclipse environment.

We also intend to provide user accessto the re-use component catalogue whichwill probably be located at the PM site.

A major aim is to use communicationsfacilities to aid project management andorganisation in a distributed IPSE.

6 Current state of the projectBecause Eclipse is a large project, manyparts must be implemented together, andall projects are due to be ready for the firstrelease by the first quarter of 1986. Thedistribution aspects of phase 1 of Eclipseare now ready.

The main problems for the distributionproject are concerned with the design ofthe distributed process architecture andwith the design of a system for co-operat-ing databases to form a single IPSE.

We are evaluating the use of RPCsacross the present (slow) WANs for use inlater phases of the project with a view toimplementing closely coupled work-station-VAX communications across aWAN.

Also scheduled for the later phases ofthe project is a study of the problems ofintegrity and reliability in the event offailures.

7 Acknowledgments

Thanks are due to David Rodway andAlbert Alderson of Software Sciences Ltd.and Mike Tedd of the University College ofWales for reading and commenting ondrafts of this paper.

8 References1 'SDS-2 Overview'. Software Sciences Ltd., Farnborough, Hampshire, England, 19842 ALDERSON, A., BOTT, M.F., and FALLA, M.E.: 'An overview of the Eclipse project', in

McDERMID, J.A. (Ed.): 'Integrated project support environments' (Peter Peregrinus, 1985)3 NESTOR, J.R., WULF, W.A., and LAMB, DA: IDL interface description language'. Report

CMCJ-CS-81-139, Revision 1.0, Computer Science Department, Carnegie-Mellon University,Pittsburgh, PA, USA, Sept. 1981

4 HUTCHISON, D.: 'Local area networks: an introduction', Software & Microsystems, 1983, 2,(4), pp. 87-95

5 ADAMS, M.J., and WESLEY, E.: 'Data communication networks', British Telecom Tech-nology Journal, 1980, 1,(1)

6 POSTEL, J. (Ed.): 'DOD standard transmission control protocol', ACM Computer Communi-cation Review, 1980, 10, (4), pp. 52-132

7 POSTEL, J. (Ed.): 'DOD standard internet protocol', ibid., 1980, 10, (4), pp. 12-518 COFFIELD, D., and SHEPHERD, W.D.: 'An introduction to interprocess communication on

BSD 4.2 UNIX systems'. Internal Report, Department of Computing, University of Lancaster,Lancaster, England, July 1985

9 BIRRELL, A.D., and NELSON, B.J.: 'Implementing remote procedure calls', ACM Trans-actions on Computer Systems, 1984, 2, (1)

10 'Remote procedure call reference manual'. Sun Microsystems, Inc., Mountain View, CA, USA,Oct. 1984

11 'External data representation reference manual'. Sun Microsystems, Inc., Mountain View, CA,USA, Oct. 1984

12 'Courier: the remote procedure call protocol'. Xerox Systems Integration Standard XSIS-038112, Xerox Corp., Stamford, CN, USA, Dec. 1981

13 'Internet transport protocols'. Xerox Systems Integration Standard XSIS-028112, Xerox Corp.,Stamford, CN, USA, Dec. 1981

D. Hutchison and J. Walpole are with the Department of Computing, University of Lancaster,Bailrigg, Lancaster LAI 4YR, England.

Software Engineering Journal March 1986