Enabling Technologies for Collaborative CAD

Enabling Technologies for Collaborative CAD

Abstract

Description

Introduction and Vision

• Ubiquitous access - Although desktop machines will still have more power, mobile computing is on the rise!

• Applications will be written to dynamically adapt to different hardware environments (depending upon factors such as the availability of resources including CPU, disk, network connection, etc.).

• There will be an increasing number of tools and services available on the network both for free and pay-per-use. These tools will be linked together using wizard-like graphical interfaces and will share compatible exchange formats.

• Data migration will be used to bring resources nearer to clients.

• Agent migration will bring tools to the data when the data out-masses the tool or when remote execution is otherwise beneficial.

• Distributed versioning and archiving systems will be required to keep track of old state used in network designs (i.e. to allow component updates without breaking existing designs).

Figure 1 : System Architecture

Persistent Object Package

The PersistentObject package allows Java (client) objects to be managed and manipulated by a network data server. One of the main goals of building the PersistentObject package was to empower application developers and users to add value to our system. The simple API, which consists of commands such as load, save, attach, etc., completely abstracts away the complexity of the underlying operations from the user, thus making it extremely straight-forward to develop applications which make use of the package. The overhead for using the package is also minimal, and exists mainly in object definition and instantiation. Currently, the object/application developer only has to add the extends PersistentObject clause in class definition, declare specific class-dependent variables, overload abstract methods in the PersistentObject declaration and perform a netObjSetup call during object construction, in order to take advantage of the PersistentObject functionality.

The package is also flexible in handling policies such as caching and security. While the infrastructure is present for implementing these policies (such as a isDirty field and a dbId field in the objects), no policy is enforced in the current implementation. Application developers are free to use the structures provided to implement the policies that suit their application-specific needs (e.g. dirty bit propagation through the object's parent hierarchy was the chosen implementation for saving and loading OctObjects in Java-Based Oct).

Due to the object-oriented nature of Java, it is very easy to extend the functionalities of the base package. For instance, developers are free to create additional objects that inherit from PersistentObject or to simply override existing methods. The classes are organized in a functionally-modular way so that any component can be changed if certain parameters need to be altered, such as the client-server communication protocol (PO_CommandConstructor.java) or the network connection (PO_NetClient.java) mechanism.

In order to facilitate a directory structure in the OODB server, a special class of PersistentObject (DirObject) was implemented. In addition to the PersistentObject functionality, DirObjects also provide special connection-related commands such as detach and getContext. A DB Browser graphical user interface (DBDialog) has been implemented in Java to allow users of the system to peruse the directory structure.

Object-Oriented Database Back-End Server

Currently, the OODBMS supports two separate schema; one for the HTTP protocol, and one for our object protocol, which is described below. At this point, the two are still slightly separate due to different development paths, but with the creation of the object-oriented directory structure mentioned above, a few simple additions to the server and protocol will make it possible for clients to access the same data using either protocol. (Previously, the system was geared towards OCT, with cells provided as entry points and naming structure. This updated version focuses on generalizing the naming structure, which makes it possible for HTTP access to be supported by both the protocol and the generic object system.)
(*HTTP is a fairly well-known protocol, and is not discussed here. For more information, please see the references.)

The data server accepts generic network socket connections, and thus can accommodate any client language that can open a socket. This includes Java, C/C++, PERL, etc, and allows the server to support both next-generation and legacy tools. Upon message reception, the server goes through a dispatch loop in which actions are taken based upon the message. Functionality of the server includes saving objects, loading objects both by id and by query, connecting objects, and traversing object connections.

Client-Server Communication Protocol

The communication protocol between the client and server follows a modified version of the HTTP protocols. The string "\n\r" is used to delimit fields, with a double occurrence indicating the end of the message. The protocol is fairly efficient in the sense that minimal overhead is sent along with the message. (To see the actual protocol, click the above link).

Although fairly short and straight-forward, this protocol can be used to create and link existing objects in a completely arbitrary manner. The persistent objects used in the front-end clients are mirrored onto the server over the network using a translation mechanism that the protocol enables. Although a "root directory" into the object-oriented filesystem is provided, no structure is imposed onto the application programmer at this point, and there are many alternate ways in which objects can be ordered and stored. Although additional structure will be added in the future to support additional users and applications, our intent is to leave as much flexibility and power as possible in the hands of the application developer.

Proxy Server

One result of this security model is that due to the platform/licensing dependencies of some of the server software (such as the Objectivity OODBMS and the Synopsys Design Compiler, both of which are licensed and distributed to run on our Sparc 20 only), the heaviest loaded server must carry the additional weight of being a full Netscape http server! (Although the astute reader will note that this load will become a problem anyway in the future, since it is envisioned that the OODBMS will eventually encompass most of the functionality of an http server as well. A potential fix for this might be the use of a distributed database). More importantly, it means that it is not feasible for a single socket server to be accessible to applets loaded from different sources.

Our short-term solution for this problem was to create a "proxy server" to be run on the same machine as the http server. This initial proxy server is very simple - it only knows enough about the communication protocols to detect the message termination string ("\n\r\n\r"). Messages on a given port are automatically forwarded to the same port on another machine. As a result, applets downloaded from a variety of http servers running proxies can now all access the same OODBMS server.

There are a number of beneficial and interesting functionalities that the proxy server could handle if it was made more sophisticated and implemented to take advantage of detailed knowledge of the protocols. These possibilities include:

• The automatic translation of data into different desired formats.

• The capability to filter and redirect data flow between applications.

• A centralized proxy server to track and monitor network tool use and dependency.

• Caching (probably the most common use of proxies today).

• A security tool that ensures that valuable internal designs are not accidentally sent out to unprotected networks.

Results

The PersistentObject package has undergone two revisions and has been used as the basic object structures for a Java-Based Octtools system and WebProj (A web-based project management application). Due to Netscape security constraints, the back-end aspect (mainly load and save) of the Java-Based Oct system was not thoroughly utilized. Enabled by proxy capability, a directory structure and extended object management features, WebProj has been able to fully demonstrate the functionality of both the client and server.

Currently, however, only a single-user environment has been available for testing of the complete system architecture, which has limited our ability to make conclusive judgments on system feasibility. Similarly, although only small network communication lag time has been encountered between clients, servers, and proxies, most of the existing tests have occurred on a protected local area network, and thus are not representative of general Internet performance. However, to our surprise, Java applet performance, which was expected to be a serious impediment, has been quite reasonable (perhaps due to the inherent brilliance of our programmer-guru, Francis Chan). This is very promising, especially in conjunction with the anticipated performance improvements that future optimizations such as just-in-time compilers will offer. In the future, we intend to gain insight into usability issues by stress-testing the robustness and scalability of the system in multi-user environments and in wide-area network collaboration with groups such as the NCSU CAD Benchmarking Laboratory.

Demonstrations

Figure 2 : WebProj Application Snapshot

Several applications which make use of the infrastructure have been implemented. We first created a general object infrastructure which could also be used to simulate a Java-based environment similar to that of the OctTools system for ee244 homework 1. Both the project description as well as many of the working applications created by the students are available on the WWW.

Implementing the Oct system in Java has given us much insight into ways of handling and representing generic object structures. Throughout this effort, we continued to monitor the issues and design approaches present in similar Java-based client applications. These outside influences helped us to extend the functionality of both the client and server environment.

Most of the features of our system can be demonstrated by a Java-Based Project Management application, WebProj, that Francis has been working on. The current functionality of the application is described below along with a table that pinpoints the demonstrated infrastructural capabilities.

Application Walk-through

Users can access the WebProj system either as a Java application or as an applet running through a Java-enabled network browser. Registered users log on to the application environment via a Profile window. After filling in the fields of the Profile window, a password window prompts the user for a password. The password is compared with the corresponding Member object in the back-end data server. After the verification process, the profile is saved and a e-mail is sent to the administrator indicating that a login has occurred. The main window of the application then appears, allowing the user to create new projects, updating existing projects, etc.. Through a database dialog window, the user can access desired additional information (i.e. members, projects, etc.) as allowed by his/her permissions.

(NOTE: Due to licensing, server load, and continued development, the OODBMS server will not be running constantly, and as a direct result it may not be possible for outside users to access its functionality with WebProj. However, we would be happy to arrange a demonstration upon request - please feel free to contact us!).

Activity	Infrastructure Capability Displayed
Loading from WWW-CAD.eecs.berkeley.edu (web server theseus) with data server at yoyodyne.eecs.berkeley.edu	Proxy Server
Password Verification	Loading Objects Query
Saving Profile (during log in)	Saving Object
E-mail Notification (during log in)	Messaging through e-mail
Opening Project	Database Browser Directory Structure Traversal Attachment Traversal

A more detailed description of the application can be found here.

Conclusions and Future Work

• The expansion of protocols to make object versioning available to network clients, which would enable the development of data and software configuration management applications.

• "Data Applets." At this time, server data can be accessed as objects with attachments or through the HTTP protocol. We intend to research the possible advantages of "active data objects" by creating an generic java applet structure that will allow data to be downloaded and perused on the client as applets. Inheritance and method overloading could be used to allow application writers to add desired functionality, such as alternate browsing and visualization techniques.

• OODB triggers that create applets on the fly. The creation process could be triggered by changes in the state of data in the database, and could use techniques such as animation to portray the status of designs.

• Research into the possibilities of increased intelligence in proxies, as discussed above.

• Java security. As security in Java continues to be probed, tested, and developed in the industry, we hope to gain insight into techniques that will allow our system to eventually be safe and usable for industry applications.

Related Work and References

• WebFS, a project being undertaken in the UC Berkeley NOW Group, is similar to some our work. WebFS provides the capability to map web servers into UNIX filesystems.

• The OctTools system, developed at the UC Berkeley CAD Group, is a development suite for EDA design.

• The WELD Project Design Automation Conference Demo was an early attempt to create a prototype demonstration system that shows the feasibility of network design systems.

• The Java Language Specification defines the language upon which much of our research depends.

• The HTTP Specification.