A database approach for information communication in a peer-to-peer collaborative CAD environment

SOFTWARE—PRACTICE AND EXPERIENCESoftw. Pract. Exper. 2007; 37:1193–1213Published online 6 February 2007 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/spe.804

A database approach forinformation communicationin a peer-to-peer collaborativeCAD environment

Haoxue Ma1 and Tore Risch2,∗,†

1Department of Applied Physics and Mechanical Engineering,Lulea University of Technology, SE-971 87, Lulea, Sweden2Department of Information Technology, Uppsala University,Box 337, SE-751 05 Uppsala, Sweden

SUMMARY

Timely and efficient information communication is a key factor in ensuring successful collaborationin engineering collaborative design. This work proposes a database approach to support informationcommunication between distributed and autonomous CAD systems. It provides the designer with an easyand flexible way, a project-based propagation meta-table, to specify what parts of a CAD information modelshould be communicated to other collaborating designers. A CAD peer manager, containing a peer databasethat stores information to be exchanged with the other collaborators, wraps each participating CAD system.The peer manager identifies changes made to the CAD model by using stored procedures and active rulesin the peer database that are automatically generated based on the propagation meta-table. The identifiedupdates are propagated in a timely manner to other peers via inter-database message passing, therebyminimizing the volume of necessary information to be exchanged. Furthermore, remote peer designers canflexibly incorporate, filter, or delete received updates by using a propagation control interface, which isalso used to issue user’s commands to download the data from the CAD system to the peer database andlookup the received messages in the peer database. The approach is applicable on any CAD system havinga CORBA interface and can also be applied to other kinds of object-oriented interfaces. Copyright c© 2007John Wiley & Sons, Ltd.

Received 20 March 2006; Revised 11 November 2006; Accepted 13 November 2006

KEY WORDS: peer-to-peer systems; peer databases; propagation meta-table; active databases; dynamic rulegeneration; object-orientation; information communication; propagation control interface

∗Correspondence to: Tore Risch, Department of Information Technology, Uppsala University, Box 337, SE-751 05 Uppsala,Sweden.†E-mail: [email protected]

Contract/grant sponsor: Swedish Agency for Innovation SystemsContract/grant sponsor: Swedish Foundation for Strategic Research

Copyright c© 2007 John Wiley & Sons, Ltd.

1194

Softw. Pract. Exper. 2007; 37:1193–1213DOI: 10.1002/spe

H. MA AND T. RISCH

1. INTRODUCTION

In distributed engineering collaborative design, successful collaboration heavily depends on timely andefficient product information communication between computer-based tools, such as CAD systems.Collaborative design is normally performed either within the same or between different domains, andcurrent information systems supporting the design activity are typically client–server based.

A peer-to-peer (P2P) system is a general software architecture that provides an alternative to thetraditional client–server architecture. It was initially used for distributed file sharing and made popularby the Napster system [1]. P2P can be defined simply as the sharing of computer resources andservices by direct exchange between peers rather than clients and servers [2]. In a P2P network, eachpeer is equal and can either request or provide services, making it different from the client–serverarchitecture where the server is dedicated to serve the clients. It opens a new window for, amongstothers, information communication over the network owing to its fundamental principles, viz. resourcesharing, decentralization, and self-organization [3,4]. Typical usage of a P2P network includes sharingfiles, storage, and computing power, and real-time data exchange. Recently, many P2P-based networks,protocols, and applications have been developed for both commercial and academic use. For instance,BitTorrent [5] and eMule [6] use P2P networks to share multimedia files among peers. The UnitedDevices Cancer Research Project [7] performs bioinformatics computing by the use of distributedcomputing power, which takes the unused computing power from many computers and uses themtogether to produce massive computing power. Skype [8] uses P2P VoIP technology to provide voiceand video conferencing.

Object-oriented methodology is currently used, almost by default, in the field of engineeringinformation systems, especially in the CAD community. Two important reasons for this are that it has anatural affinity with complicated engineering data structures and it allows code reusability to make thedevelopment of CAD systems easier. Object-oriented methodology is not only used to develop CADsystems, but also to define application programming interfaces (API) of CAD systems so that userscan enjoy the benefits of object-oriented analysis, design, and development. Some typical examples ofcommercial API products include Open I-DEAS for I-DEAS [9], Open NX for NX [9], and ObjectARXfor AUTOCAD [10].

According to the characteristics of P2P computing and collaborative CAD, a few requirements can beidentified and must be met to achieve successful information communication in such an environment,which is the aim of the present work:

• Efficient representation of objects having complex structures, operations, and methods as foundin CAD data representations. This is the basis for any downstream activities concerning datacommunication.

• Timely and effective exchange of design ideas between distributed designers. This is preciselywhat ‘collaboration’ concerns. These issues can be further divided into:

– identification of updates made in a CAD system;– propagation of the identified updates to peer designers;– selectable incorporation on updates made by peer designers.

• Information communication in a platform independent manner. This is required by software andhardware diversity.


1195


A DATABASE APPROACH FOR INFORMATION COMMUNICATION

• A scalable system architecture. This enables one to handle large amounts of complex CAD datacommunicated between many peers without significantly degrading performance.

• System extensibility. It should be easy to extend functionality by including new functionalityprovided by the CAD system.

In this work, an approach based on a P2P database management system (DBMS) [11] is proposedto facilitate information communication in a collaborative CAD environment. Each participating CADsystem is distributed and autonomous. It is wrapped by a peer manager system that contains a peerdatabase storing objects to be exchanged with other peers. The peer database is managed by an object-oriented and active peer DBMS. For easy extensibility, the designer simply needs to fill in one projectspecific propagation meta-table containing only the names and attributes of the CAD entities to bepropagated to other peers. Stored database procedures and active rules [12,13] in the peer databasesare automatically generated from the propagation meta-table. The identification and propagation ofCAD updates to be shared with other engineers are handled by these stored procedures and active ruleswhen the peer manager downloads design data from the CAD system. Inter-database message passingbetween the peer databases propagates the CAD updates. Through a propagation control interface,remote designers can issue commands to download the data from the CAD system to the peer database,look up the received messages in the peer database, and freely incorporate, filter, or delete the receivedupdates by manipulating the corresponding messages. Accepted changes are then uploaded from thepeer database to the receiving CAD system.

This approach is implemented on a CORBA [14] platform. It is applicable to any CAD systemhaving a CORBA or other object-oriented interface.

2. RELATED WORK

Recently, many research frameworks and prototypes have been introduced to facilitate collaborativedesign with different focuses. Tay and Roy [15] developed a collaborative multimedia-enabled 3D CADsoftware called CyberCAD. This system was built on Java and Java3D and enables distributeddesigners to build platform-independent Web-enabled virtual products as a team. In CyberCAD a self-developed communication protocol called controller/viewer is used where users can request and passthe control to each other. A designer is a ‘controller’ of their own design task and simultaneously actsas a ‘viewer’ of the modules of other designers. If a viewer wants to control their partner’s modules,they have to drag it to their local window.

Bidarra et al. [16] presented a client–server-based collaborative framework, called webSPIFF, tosupport integrated design of parts and assemblies using feature modelling. During modelling, teammembers can have their own product views, for example part design view, part manufacturing view,and assembly design view, and can simultaneously manipulate features. All clients connect to thesame server running a multiple-view feature modelling kernel and maintaining the complete productmodel. Another feature-based approach for distributed collaborative design can be found in the systempresented by Lee et al. [17], but with different emphases.

Ramani et al. [18] proposed a thin-client collaborative system, called CADDAC, for shapeconceptualization. It allows the creation and modification on geometry in a collaborative mode, andmaintains the shape creation history in the database on the server-side. Only the client who has thecontrol, called the master-client, is capable of doing real-time editing on geometry over the network.


1196


H. MA AND T. RISCH

To keep the client thin, all solid modelling and constraint solving operations are performed at theserver-side.

Alibre Design [19] is a commercial mechanical 3D CAD software supporting both conventionalCAD solid modelling and collaborative design. Multiple designers can communicate and work onthe same model in real time through a Team Design Server that supports session-based controlmechanisms. Design tasks are organized in sessions where designers can play different roles, suchas active model controller or passive viewer, by passing control tokens. CAD data only reside on aserver where the main modelling activities are carried out. Designers are essentially clients and only thedesigner who holds the control token is able to edit the model whilst other designers in the same sessionare viewers. Another commercial collaborative CAD system OneSpace [20] has a similar mechanismand architecture for work collaboration.

Despite much progress, most current systems employ a centralized model (controller–viewer andclient–server) to conduct collaborative design. However, compared to a P2P computing model, thereare some disadvantages with the centralized model: designers have either only shared access or privateaccess to CAD models, meaning that one designer has to wait until updating members release themanipulation control to the model. This model also requires high network bandwidth and is normallycomplicated to construct. Furthermore, the central server can be heavily burdened while performingcollaborative work serving many designers of complex products. For instance, in the webSPIFF case,client-specific views of part design, part manufacturing, and assembly design have to be constantlygenerated and propagated to all clients. Finally, it is potentially less fault-tolerant since the central hostis a single point of possible system-wide failure [21].

Using a DBMS in collaborative design has been recognized as an important issue. In the pilot systemdeveloped by Han et al. [22], product models are stored in a shared database that is formatted accordingto the Standard for the Exchange of Product Model Data (STEP). The schema of the database is basedon AP203 of STEP. Metadata and ontology concepts are used to improve the search capability of theproduct database.

Urban et al. [23] presented an Integrated Product Data Environment (IPDE), where a STEP databaseis used as a repository to share data between engineering design and analysis tools. The IPDE is capableof recognizing the STEP concepts, named Units of Functionality, so that users can extract only therelevant parts of a file from the database instead of checking in or out entire exchange files.

Central database servers have been employed to store file-based product data in the above systems,where sharing and concurrent access to the product data are thus allowed. This approach partiallysolves the inherent problem of file-based information exchange, i.e. a file is basically for archivingpurposes only and has no or at least insufficient functionality for online collaborative design regardingaccess to the CAD data structure and high-level functionality. However, it would be more beneficial totake advantage of advanced database capacities to assist the product design process rather than usinga database server just as a pure back-end repository. As the authors have experienced in the presentwork, database capacities enable a more efficient development of the application, and the applicationis more flexible, less complicated, and easier to maintain compared with using only conventionalprogramming languages, such as C++ and Java. For instance, by incorporating a DBMS to handleproduct data, one directly accomplishes high-level reuse of system functionality that otherwise requiresreimplementation since the DBMS automatically supports storage management, high-level queryprocessing, active rules, client–server database facilities, etc. In our system, P2P database facilities [11]in addition provide a decentralized architecture where changes are detected by database procedures


1197



and active rules, and then propagated between peers. The work on object deltas in [24] describesrepresentation of changes in an object-oriented database as first-class objects for debugging activerules. Our work is similar in that we also determine changes in object values and store them in anobject-oriented database. However, our changes happen in a wrapped CAD system where the wrapperdetects the changes. Furthermore, we use active rules to propagate object value changes betweenseveral autonomous P2P databases wrapping different CAD systems in a distributed environment.This P2P database approach enables a cooperative and non-distributed environment of loosely coupledCAD systems.

3. THE ACTIVE PEER-TO-PEER APPROACH FOR DATA COMMUNICATION

In this section, the system architecture and technical issues of the peer database in our approach aredescribed in detail. The database definition code presented is slightly different from the implementationso as to emphasize our methods rather than the code details.

3.1. The system setup

The system configuration is shown in Figure 1. Any number of geographically distributed peerdesigners are working with a traditional single-user stand-alone CAD system. Each CAD systemis autonomous and wrapped by a peer manager that uses an object-oriented active P2P-DBMS.The databases can communicate directly with one another after registering with a Name Server, wheredatabase communication information is stored. The exchange of update information between peer sitesis conducted via direct inter-DBMS message passing over the network. Designers perform design tasksat local CAD systems through a CAD GUI and then issue collaboration-related commands through apropagation control interface to the peer database to exchange design information with other designers.

A few advantages can be easily identified from this architecture.

• Each peer contains a copy of the shared data in its local system so that the designer has fullaccess to the data at any time, i.e. no check-in/check-out issues.

• Modifications made on the local model are identified and then propagated to other collaborativedesigners. The data volume to be distributed is therefore reduced since only the modificationsare transferred rather than the whole modified model.

• The designers at different sites can perform independent simultaneous work and have differentviews on the shared data since the data reside locally.

The DBMS used by our peer manager is AMOS II—an object-relational multi-database system. Its coreis an open, extensible DBMS supporting an object-relational data model [25]. The basic concepts ofthe AMOS II data model are types, functions, and objects corresponding to entities, attributes, andinstances of the engineering information model in this work. The data model is accessible throughAmosQL, an SQL-99 [26] related object-oriented query language that is used to define, populate,query, and update the database. Furthermore, AMOS II is an active DBMS where database event-condition-action (ECA), event-action (EA), and condition-action (CA) rule models are supported bya built-in rule processor. The specified events can be updated, added, removed, created, and deletedand are used to monitor updates to AMOS II functions as well as creation and deletion of objectinstances. The active rules monitor the ‘net effect’, i.e. the value changes rather than the actions [27].There are two main interfaces, the callin and the callout interfaces, that AMOS II uses to interface


1198


H. MA AND T. RISCH

Figure 1. The system architecture.

with external systems written in other languages such as C, Lisp, and Java. The external systems callthe DBMS through the callin interface while AmosQL functions call external subroutines written inother languages through the callout interface. AMOS II is also a peer database system [28] where eachpeer is an autonomous object-relational DBMS with its own query processor, storage, and catalogue.Every peer can act both as a client and a server to any number of other peers [29]. These AMOS IIfeatures are directly related to this work and are shown to be suitable to represent, store, access, andmanipulate complex engineering data from different and distributed data sources and react in a timelymanner to specific events.

CORBA is an object-oriented standard for distributed object computing using a client–server model[14]. It is used to provide object interoperability, i.e. enable communication between objects regardlessof host languages and platforms. CORBA requires objects to be expressed in and accessed through itsInterface Definition Language (IDL) and thereby hides the complexity of object source code.

In our approach, the application programming interface of the chosen CAD system conforms to theCORBA standard. As illustrated in Figure 2, CAD data are accessed by the peer manager through thecallout interface, the CAD Interface, and the CAD’s CORBA interface, and then stored as objects inthe peer database through the callin interface. The peer DBMS identifies updates, propagates relevantupdates to peers, and incorporates updates from other peers.

3.2. Naming mechanism for CAD objects

In a collaborative environment it is very important that each communicated CAD object has a globallyunique name managed and operated in a consistent way. An object identifier (OID) is a locally uniquesystem-generated identifier used to refer to a specific object in the peer database. When a CAD objectis created in a peer database, an OID with a unique identification number is automatically assigned


1199



Figure 2. The system data flow.

to the object. However, such an identifier is unique only in the local peer database, meaning thatit cannot be used to identify a CAD object in other peer databases of the distributed collaborativedesign environment. Therefore, we require that each object must have a universal logical key to identifycorresponding objects in different peer databases.

In a CAD system, objects of different or the same entities may have the same name in the rangeof a whole model and can therefore not be used as keys directly. However, object names of thesame entity in their direct owner/container are always unique. For instance, different solid parts mayhappen to use the same name in different projects of a CAD model, but their names must be uniquein their individual container—their direct owner. This is the foundation of our naming mechanism.An object key is thereby formed by concatenating the entity name and owner name of the object, viz.‘entityName ownerEntityName ownerObjectName objectName’. Two examples of object keys are

Part_BIN_Main_handlePartInstance_ASSEMBLY_PumpAssembly_handle1

where Part, BIN, Main, and handle are the names of the PART entity, and the BIN entity, anobject of the BIN entity that contains the part object, and the part object. Similarly, PartInstance,ASSEMBLY, PumpAssembly, and handle1 are names of the PART INSTANCE entity, and theASSEMBLY entity, an object of the ASSEMBLY entity that contains the part instance object, and thepart instance object. This mechanism avoids name conflicts in the global environment.

3.3. The Propagation meta-table and dynamic rule generation

The present work provides designers with a convenient way to specify project-based informationto be communicated between collaborative CAD systems through the propagation meta-table.


1200


H. MA AND T. RISCH

Table I. An example of propagation meta-table.

Entity name Attribute name

Part BoundingBox ValuePart Material NameAssembly InstanceDimension ValueTransform Value..... .....

The propagation meta-table contains names of entities and attributes to be propagated, as shown inTable I.

The propagation meta-table is this simple because:

• the CAD system data are treated in the database on an object level rather than as CAD systemnative data structures, meaning that the objects are independent logical entities in the peerdatabase;

• the naming mechanism provides enough information to distinguish objects and attributes.

Thus, the mechanisms for identification and propagation of entity updates are simplified and theycan be performed by using automatically generated database active rules having a particular template,as illustrated below. Note that entity, attribute, and instance in the CAD information model correspondto type, function, and object in the database model:

create rule update_typeName_functionName asfrom typeName eon updated(functionName(e))do propagateFunctionChange(typeName, e, functionName(e));

where typeName and functionName are substituted for the corresponding names of each entityand attribute specified in the propagation meta-table. PropagateFunctionChange is a storeddatabase procedure that propagates relevant changes of the object e to other peers. The rule specifiesthat if there is any change to the value of the given function of the given type, the system propagatesrelevant changed information to other peers.

When the system is initialized for a collaborative design task, it reads the propagation meta-tableand automatically generates a set of active rules based on the above template. Furthermore, with theevolvement of the meta-table, active rule definitions can be correspondingly updated at any time duringthe collaborative design process. This is done by sending active rule creation commands described inthe above template to the peer database to generate and activate new rules for those new entities.Each rule maps to one entity attribute and is responsible for determining its value change. These rulesare automatically triggered when the procedure for downloading CAD data to the peer database iscompleted. This mechanism for dynamic rule generation provides the designer with the flexibility tospecify project-based information to be propagated at any period in the design process, thereby makingthe system scalable and easy to maintain.


1201



Figure 3. The two-phase update identification.

3.4. Update identification

Among three possible updates to an object, viz. modification, creation, and deletion, modificationsto function values are identified by database active rules whose template was shown in Section 3.3.However, the principle for identifying updates on creation and deletion of objects differs from that forfunction values modification. To achieve this, one extra function, called state, is introduced in theCAD object definition. The AmosQL code below defines a type CADObject in the database, whichis the root type of any CAD entity defined in the database schema. This type has functions name, andCADID that returns the object key:

create type CADObject;create function name(CADObject) -> String;create function CADID(CADObject) -> String key;create function state(CADObject) -> String;create function operator(CADObject) -> String;

The function state is essentially a string‡ telling the database system about the state of anobject, which could be ‘created’, ‘deleted’, ‘modified’, or ‘unchanged’. Each sub-type of this roottype therefore inherits this function owing to the inheritance feature of the object-oriented data model.By checking state, the database knows the state of each object and can then act correspondingly toeither notify peer engineers about updates or upload updates made by other peers to the CAD system.

In the database, update identification is divided into two phases, namely identification of objectexistence and modification of values of object functions, as illustrated in Figure 3. In the example here,objects 1 and 3 are deleted, objects 2, 4, and 5 are modified, and object 6 is created in the CAD systemduring design work.

‡For efficient representation, the strings can actually be encoded bits associated with each object.


1202


H. MA AND T. RISCH

In order to be able to identify every update, a duplicated copy of the shared CAD objects arepopulated in the peer database and then the states of all these objects are set to be ‘deleted’. This takesplace only when the CAD data are downloaded into the database for the first time. Afterwards, duringsubsequent downloading in the first phase of change detection, the peer manager checks the existenceof each CAD object to be populated in the database. If the object does not exist, a new object iscreated with ‘created’; otherwise the state of the existing object is set to ‘unchanged’, meaning thatat this moment this object exists, but it still remains to be investigated if its function values havebeen modified. Objects that have not been touched during the download procedure have been actuallydeleted in the CAD system. The stored database procedure handling the downloading is defined belowin AmosQL:

create function theCADObject(String ID, String typeName)-> CADObject o as

beginselect CADObjectNamed(ID) into o;if o = nil then

begin/* The object ID does not exist, create one */set o = createObject(typeName);set CADID(o) = ID;set state(o) = "created";

endelse

set state(o) = "unchanged";result o;

end;

After downloading, the second phase takes place, where the database active rules are triggeredto determine function values that have been modified. Finally, the change-related information ispropagated to other peers. Note that the states in the third table in Figure 3 are the same as thosein the second table. This is because the function propagateFunctionChange in the active rulesimmediately propagates updates to peers so that the states for those objects do not need to be set, aswill be described in the next section.

3.5. Message construction and broadcasting

Updates are propagated to peers via inter-database message passing. The messages thereby:

• must contain necessary information to tell peer designers all details of the updates;• should be designed not only for designers to view the updates, but also for the peer database

systems to execute the updates specified in the messages. The designer should be able to modifythe data in the local database by reacting to the messages in a convenient way.

Therefore, the format of messages is of great importance.


1203



In the present work, a message is defined in the database as an object of type Message havingfunctions name, sender, receivedTime, and content:

create type Message;create function name(Message) -> String;create function sender(Message) -> String;create function receiveTime(Message) -> Timeval;create function content(Message) -> String;

The strings stored in the function content are actually database update commands to be executedat receiving peers. If a designer intends to incorporate updates made by certain peer designers, theycan simply select the messages sent by those peer designers and execute them in the receivingpeers. For instance, if an object has been deleted, the message content should enable the databaseto identify the object and perform deletion on this object. As a record of collaboration designhistory, such executable messages could actually have more functions telling the designer the stateof the message such as, whether the message has been read, whether and when the content of themessage has been incorporated, whether the peer needs to have the data resent, etc. By queryingthe above message functions and/or attributes, a local designer knows the status at the receiving peerdatabases.

The function createMessage shown below creates a message object in the database. It is calledby function broadcast that sends all peers a message—a command to create a message object in thepeers’ databases:

create function createMessage(String msgName, String senderName,String msgContent) -> Message m as

begincreate Message instances m;set name(m) = msgName;set sender(m) = senderName;set content(m) = msgContent;set receiveTime(m) = now( );result m;

end;create function broadcast(String msgContent) -> String peer asfor each Peer pwhere p = other_peers( )

beginsend(p, "createMessage(" + messageName( ) + sender( )

+ msgContent + ");" );end;

The function other peers detects all other peers in the collaborative design while the functionsend passes a message to peer P for evaluation, but does not wait for any reply as typically happensin a P2P environment. The database function messageName creates a name for this message andsender stores the sender’s name of the message.


1204


H. MA AND T. RISCH

As described in Section 3.4, created and deleted objects will be identified by the download procedure,and their states are set to be ‘created’ or ‘deleted’. The function propagateAll propagates allupdates to peers:

create function propagateAll( )->Boolean asbegin

for each CadObject o where state(o) = "created"beginbroadcast("created_object(" + CADID(o) + name(typeof(o))

+ sender( ) + ");" );end;

for each CadObject o where state(o) = ’deleted’beginbroadcast("deleted_object(" + CADID(o)

+ sender( ) + ");" );end;

rulecheck( ); /*propagates function values*/end;

This function first calls broadcast to create message objects in the peer databases for the createdand deleted objects, and then triggers the active rules generated automatically based on the propagationmeta-table to identify objects whose function values have been changed. The reason for this operationsequence is that the objects must be created before function value updates can take place.

When active rules are triggered, changes to function values of objects of the specified types areautomatically detected by the database system, and the function propagateFunctionChangebelow is then called to create message objects in peers’ databases for those objects:

create function propagateFunctionChange(String fn, CADObject arg,Object value) -> Boolean as

beginbroadcast("modified_object( fn, objectID(arg), value,

Sender( ) );" );end;

The procedure performed during message broadcasting is illustrated in Figure 4.

3.6. Incorporation update at peer side

A collaborative system must be designed for social expectations, for example, collective cooperationor autonomy. In our approach, peer designers are autonomous. It is totally up to the designer todecide whether or not the updates made by others should be incorporated, whose updates shouldbe incorporated, whose messages should be deleted, etc. After the designer broadcasts the messages,the messages are displayed on the peer designers’ screens and corresponding message objects arepopulated in their databases. Message objects created in the database are persistent and not lost unlessa user explicitly deletes them. This allows the restoration of the environment when users re-join thecollaborative design work.


1205



Figure 4. The procedure of message broadcasting.

By reading the messages, peer designers know detailed information of the updates sent byeach peer and can then incorporate the desired updates to their database by calling the functionexecuteMessage:

create function executeMessage(String sender) -> Boolean asbegin

for each Message msgwhere sender(msg) = sendereval( content(msg) );

end;

The database function sender gets the sender name of the message and eval sends itsinput parameter, a database command, to AMOS II for evaluation. In this case, it executes thecalls to the specified stored database procedures, created object, deleted object, andmodified object, sent by sender. The thought of function created object is illustratedin Figure 5.

The function created object creates an equivalent object to that which was created by the peersender in the database. The function first checks the existence of the object to be created. If it doesnot exist, the function then creates the object, sets its object key, and finally sets the state to ‘created’.If the object exists, meaning that the peer designer happens to have created an object with the same key,the designer will be informed of this conflict. This mechanism can avoid possible data inconsistencybetween peers. In this case, peer designers should coordinate their actions by using some conferencing


1206


H. MA AND T. RISCH

Figure 5. The flowchart for the function created object.

facility and groupware [30], such as video conferencing, shared applications, and a 3D CAD modelviewer:

create function deleted_object(String ID, String sender)-> CADObject o as

beginselect CADObjectNamed(ID) into o;if o = nil thenerror("Conflict! Object " + ID + " does not exists and can NOT

be deleted!")elsebegin

set state(o) = ’deleted’;set operator(o) = sender;

endend;


1207



Figure 6. Object states before and after message execution.

The function deleted object sets the state of the object that has been deleted by the peerdesigner sender. Later on, the function that is responsible for uploading updates to the CAD systemwill delete the corresponding objects in the CAD system and the database function will then also deletethem in the database according to this state:

create function modified_object(String ID, String fn, String val,String sender) -> Boolean as

for each CADObject obegin

select CADObjectNamed(ID) into o;if o = nil then

error("Conflict! Object " + ID + " does not exists and can NOTbe modified!")

elsebegineval("set " + fn + " (" + o + ") = " + val + ";");set state(o) = "modified";set operator(o) = sender;

endend;

The functionmodified object takes key ID, function name fn, and the new value of the modifiedobject val as input to set a new function value, and then sets the state of this object to be ‘modified’.

Figure 6 illustrates the states of objects stored in the peer designer’s database, both before and afterexecuting messages sent by peer A. Other functions for synchronizing the database and the CADsystem can then upload these updates to the CAD system according to the states of those objects.


1208


H. MA AND T. RISCH

4. IMPLEMENTATION

The proposed approach has been implemented in a collaborative design environment where a CAD peermanager containing a peer DBMS, AMOS II, is used to wrap a commercial CAD system I-DEAS.

The CAD system I-DEAS has a powerful capability that enables users to perform complex designtasks. It also has a mature and well-defined application programming interface, Open I-DEAS, whichconforms to the CORBA standard, and enables users to access and manipulate its internal data.I-DEAS is used in this implementation to perform collaborative design work. Its data is accessed,manipulated, and distributed via Open I-DEAS. Since CORBA is a platform-independent standardfor object computing, our approach can be directly implemented to the I-DEAS system running ondifferent operating systems as we have tested. When the system starts:

1. the CAD interface automatically establishes connection between the peer database and I-DEASvia the database callin, callout interface and the Open I-DEAS server;

2. the Peer database then

a. loads the database functions (described in Section 3) used to identify any updates made inCAD, propagate the updates to peers, and incorporate the updates to the database;

b. loads an Open I-DEAS-based schema defined specifically for I-DEAS data manipulation;functions defined in this schema are responsible for downloading I-DEAS data to thedatabase and uploading the database updates to I-DEAS;

c. registers with a Name Server and sets itself into ‘listen’ mode to listen to inter-databasemessages passed on by other peer databases.

The designer can send commands to the database via the propagation control interface where threeoptions can be currently chosen from:

1. lookup messages and/or upload updates to CAD;2. download CAD data and propagate updates;3. quit.

In option 1, the system calls the relevant function to check if there are any un-serviced messages inthe database, as illustrated in Figure 7(a). If there are such messages, they will be displayed and thedesigner can make a choice between incorporating messages sent by certain peer designers to I-DEAS,as illustrated in Figure 7(b), deleting the messages in the database, or keeping all of them.

In option 2, the system first calls the same functions as used in option 1 to look up messages and/orupload updates to the CAD. The system will then call functions to download I-DEAS data to thedatabase. A flowchart of downloading I-DEAS data is illustrated in Figure 7(c). At the end of thisprocedure, all CAD objects whose states are ‘deleted’ are deleted after the updates are identified andpropagated to peers. Finally, the state of all objects needs to be reset to ‘deleted’ so that the system isready to download CAD data the next time.

A sub-assembly of a steam engine modelled in I-DEAS is selected as the object to verify ourapproach. The assembly consists of two parts, soleplate and box bed, as shown in Figure 8.

The following examples illustrate how different propagation meta-tables can affect the designresult at peer sites and how the designer incorporates updates made by the selected peer designer.


1209



(a) (b) (c)

Figure 7. The flowcharts for (a) message lookup, (b) uploading data to CAD, and (c) CAD data downloading.

We assume that the project aim at this time is to modify existing solid models and adjust the positionsof parts in this assembly. Besides other modifications to the model, a designer at the local site increasedthe diameter of a hole and assembled the soleplate on the box bed, as shown in Figure 9. The designercan set up the propagation meta-table, perform option 2 to check un-serviced messages, and downloadI-DEAS data to the peer database. The peer database system will automatically identify all updatesmade in the CAD and then propagate only the desired design results specified in the propagation meta-table; in this case it could be dimension, position, or both.

After being informed, designers at peer sites can perform option 1 to incorporate the updates madeby the local designer. Figure 10 shows the results at peer sites when the sender’s propagation meta-tablecontains position, dimension, and both.

Moreover, peer designers can read all messages and are able to incorporate updates received fromthe chosen peer designers. Figure 11 illustrates this selectable update incorporation. Let us assumepeer designers A and B simultaneously perform individual design work based on the model shown inFigure 9(a). After completing the design work, their design results, shown in Figures 11(a) and 11(b),are propagated to designer C. It is up to designer C to select the desired updates to be uploaded totheir local I-DEAS. Figure 11(c) shows designer C’s result when designer A’s updates are selected andincorporated.


1210


H. MA AND T. RISCH

Figure 8. A solid model of a steam engine.

5. CONCLUSIONS AND FUTURE WORK

A generic approach is proposed to support engineering information communication between distributedand autonomous CAD systems. Each participating CAD system has workplace information stored inan object-oriented peer DBMS supporting active rules and message exchanges with database peers.Updates made in the CAD system are automatically identified by the peer database and only updates ofthe specified types are propagated to other peers using stored database procedures and active databaserules, and inter-database message passing. When the system is set up, the stored procedures and activerules are automatically generated based on a simple propagation meta-table specified by the designer.Furthermore, remote peer designers are able to flexibly incorporate, filter, or delete updates receivedfrom others by using a propagation control interface.

CAD data in the database are treated as independent objects identified by unique keys rendering thecommunication mechanisms simple and system independent. Together with dynamic rule generation,which makes the system scalable, extensible, and easy to maintain, this approach can be plugged intoany CAD system having CORBA and other types of object-oriented interface.

In the approach, a local designer is able to easily specify project-based CAD information to becommunicated and the remote site designer can flexibly incorporate, filter, or delete updates received


1211



(a) (b)

Figure 9. The local assembly result (a) before and (b) after modification.

(a) (b) (c)

Figure 10. The assembly result at the peer site when the propagation meta-table at the sender site respectivelycontains (a) position, (b) dimension, and (c) both.


1212


H. MA AND T. RISCH

(c)(a) (b)

Figure 11. Selectable incorporation on updates. (a) Peer designer A; (b) peer designer B; and (c) peer designer C.

from others by manipulating corresponding messages. The approach can thereby be used in a P2Pcollaborative design environment where designers and CAD systems are distributed and autonomous.

Furthermore, the approach can be used in either synchronous or asynchronous collaborative design,since peer designers can be notified in a timely manner about the updates and the messages recordedin the database can not only be available for designers to view but can also be used as a means ofmaintaining project notes and history.

The proposed approach is validated by constructing and demonstrating a running prototype systemwhere commercial running CAD systems can actually collaborate in practice using this approach.

Although the current system can automatically identify and propagate updates of a CAD model, thedownloading and uploading of CAD data are still manual, i.e. much effort for writing new methods inconventional programming language are needed when new types of CAD functions are added to thesystem. It is therefore necessary to develop high-level mappings of types and functions between theCORBA standard and our peer database system to enable automation of downloading and uploadingof the CAD data. Related work, such as in [31], is expected to solve some of these problems.

ACKNOWLEDGEMENTS

We are grateful for financial support provided by the Swedish Agency for Innovation Systems through the PolhemLaboratory at Lulea University of Technology, Sweden. We also acknowledge the Swedish Engineering DesignResearch and Education Agenda (ENDREA) financed by the Swedish Foundation for Strategic Research.

REFERENCES

1. Napster. http://www.napster.com/ [November 2006].2. Barkai D. An introduction to peer-to-peer computing. Developer Update Magazine. Intel Corporation, 2001.3. Aberer K, Hauswirth M. An overview on peer-to-peer information systems. Proceedings of the Workshop on Distributed

Data and Structures, Paris, France, 2002. Carleton Scientific: Ontario, Canada, 2002.


1213



4. Parameswaran M, Susarla A, Whinston AB. P2P networking: An information-sharing alternative. IEEE Computer 2001;34(7):31–38.

5. BitTorrent. http://www.bittorrent.com/ [November 2006].6. eMule. http://www.emule-project.net/ [November 2006].7. Grid. http://grid.org/home.htm/ [November 2006].8. Skype. http://www.skype.com/ [November 2006].9. UGS. http://www.ugs.com/ [November 2006].

10. Autodesk. http://www.autodesk.com/ [November 2006].11. Halevy AY, Ives ZG, Madhavan J, Mork P, Suciu D, Tatarinov I. The piazza peer data management system. IEEE

Transactions on Knowledge and Data Engineering 2004; 16(7):787–798.12. Bailey J, Ramamohanarao K. Issues in active databases. Proceedings of the 6th Australasian Database Conference,

Glenelg, South Australia, 1995. Australian Computer Science Communications, 1995; 27–35.13. Widom J, Ceri S. Active Database Systems. Morgan Kaufmann: San Francisco, CA, 1996.14. Corba. http://www.corba.org [November 2006].15. Tay FEH, Roy A. CyberCAD: A collaborative approach in 3D-CAD technology in a multimedia-supported environment.

Computers in Industry 2003; 52(2):127–145.16. Bidarra R, Kranendonk N, Noort A, Bronsvoort WF. A collaborative framework for integrated part and assembly

modelling. Journal of Computing and Information Science in Engineering 2002; 2(4):74–87.17. Lee J, Kim H, Kim K. A web-enabled approach to feature-based modelling in a distributed and collaborative design

environment. Concurrent Engineering Research and Applications 2001; 9(1):74–87.18. Ramani K, Agrawal A, Babu M, Hoffmann C. CADDAC: Multi-client collaborative shape design system with server-based

geometry kernel. Journal of Computing and Information Science in Engineering 2003; 3(2):170–173.19. Alibre Design. http://www.alibre.com [November 2006].20. One Space. http://www.cocreate.com [November 2006].21. Begole J, Smith RB. Struble CA, Shaffer CA. Resource sharing for replicated synchronous groupware. IEEE/ACM

Transactions on Networking 2001; 9(6):833–843.22. Han S, Choi Y, Yoo S, Park N. Collaborative engineering design based on an intelligent STEP database. Concurrent

Engineering Research and Applications 2002; 10(3):239–250.23. Urban SD, Ayyaswamy K, Fu L, Shah J. Liang J. Integrated product data environment: Data sharing across diverse

engineering applications. Computer Integrated Manufacturing 1999; 12(6):525–540.24. Urban SD, Abdellatif TB, Dietrich SW, Sundermier A. Delta abstractions: A technique for managing database states in

runtime debugging of active database rules. IEEE Transactions on Knowledge and Data Engineering 2003; 15(3):597–612.25. Uppsala Universitet. http://www.it.uu.se/research/group/udbl/amos [November 2006].26. Information technology—Database languages—SQL—Part 1: Framework (SQL/Framework). ISO/IEC 9075-1, 1999.27. Skold M, Risch T. Using partial differencing for efficient monitoring of deferred complex rule condition. Proceedings

of the 12th International Conference on Data Engineering (ICDE’96), New Orleans, LA, 24 February–1 March 1996.IEEE Computer Society Press: Los Alamitos, CA, 1996; 392–401.

28. Risch T, Josifovski V. Distributed data integration by object-oriented mediator servers. Concurrency and Computation:Practice and Experience 2001; 13(11):933–953.

29. Katchaounov T, Josifovski V, Risch T. Scalable view expansion in a peer mediator system. Proceedings of the 8thInternational Conference on Database System for Advanced Applications. IEEE Computer Society Press: Los Alamitos,CA, 2003; 107–116.

30. Krasner H, McInroy J, Walz DB. Groupware research and technology issues with application to software processmanagement. IEEE Transactions of Systems, Man, and Cybernetics 1991; 21(4):704–712.

31. Nystrom M, Risch T. Engineering information integration using object-oriented mediator technology. Software: Practiceand Experience 2004; 34(10):949–975.


Documents

A database approach for information communication in a peer-to-peer collaborative CAD environment