WELD System Architecture


composed by Francis Chan

Overall Structure

After a number of rounds of discussion and refinement, here is my view of the structure of the WELD system.


A high-level view of the architecture of the WELD system.

The WELD system comprises the following entities:

User Interface

A client interacts with the WELD system through a network interface, e.g. Netscape, user interface of the "Network Computer" or an internally developed "browser", which supports the interpretation and display of presentation data.

Presentation Data

Currently, users of the World Wide Web are provided with static display of information in the form of text and graphics or with limited interactivity by means of java and programs that run on the remote server (Level 0 Client/Server, e.g. cgi-bins, WebObjects). However, we believe that a new paradigm of information visualization is to emerge where there is a change from (display-)application-centric pages to data-centric documents.

This may be achieved in a number of ways:

  1. MIME: MIME (Multi-purpose Internet Mail Extensions, the Internet standard for formatting electronic messages containing not only text, but other types of data) can be used by HTTP as the encoding mechanism to pack information into messages. Browsers with specific configurations can spawn different applications when different kinds of data are encountered. Example: ghostview and uncompress are called implicitly when one clicks on a compressed postscript file within a brwoser in a UNIX environment with the appropriate setting in the mailcap file.
    [Reference: WWW Based Structuring of Codesigns]

  2. "Agents" and Domains: Agents acts as a personal assistant for the user invoking tools, libraries, viewers and accessing data on the user's behalf. The domain, which specifies the environment that the user works in, is a bounded space template, defined by a set of relevant description methods, views and actions, and is characterized by a set of parameters and constraints. This idea could be extended to faulting in remote applications and/or java applets whenever necessary for specific applications.
    [Reference: Information Based Design Environment]

  3. Intelligent Agents: In addition to performing tasks for the users, these agents also prompt users for parameters such as memory, computing power, network bandwidth, time constraints etc.. and communicate with the remote host in determining the optimal strategy for the user, such as constructing a tailored document, java applet, or deciding the local vs remote computing/processing ratio for specific applications (Optimal Level 4 Client/Server).
These models of presentation data would involve extending the present HTML standard to support embedded commands or developing a new page description language which will be supported by existing browsers or a browser that is developed internally.

Agents

Agents include remote servers, i.e. application or tools, such as Nova, that reside on the WEB and processes that are spawned by user and other servers. One such process would be a "Wizard" that walks a user through an application or a design process. The client's local workstation should also be considered an agent.

Agents receives requests originated from clients and notifies the relevant objects in the database. After receiving instructions from the scheduler, agents also generate the presentation data that is to be displayed to the client.

Objects

Objects are basic entities, such as text, graphics, Java code segments, opcodes, etc., that are stored by the database. They make calls to the scheduler and inform it of the resources that they need to access. Objects form the basic input for agents and are defined by their respective properties, i.e. actions available on them. An entity/relationship approach could suitably be applied to modelling the relationships between objects in the database.

Scheduler

Operation requests by agents, which satisfy certain trigger conditions, will cause the invocation of the corresponding triggerred procedure which are to be handled by the general scheduler/dispatcher. The scheduler in turns, communicates with the relevants agents to perform the operations. This model also supports our idea of data-centricity.

Database

The database is the central repository for the WELD system as (almost) all agents communication with it to store and retrieve information (persistent objects). It mimics the role that the WWW will play in the eventual distributed design system. (The database relieves us temporarily of issues related to distributed systems, which include, fault tolerance, registration/authentication services, data availability and storage, etc..).

The database follows a weak consistency model as the global state is not stored in the database; states are updated when clients issue commands and operations that affect the data involved. Global state of information are owned by (possible separate) clients and can be recovered by aggregating local information . However, local state of information accessed by a non-onwer is an issue that has yet to be resolved. Possible approaches to this problem include distributed real-time update or resolution by means of an underlying system such as CVS or ClearCase.


Example/Storyboard

A user/client fires up a browser to look at a module of design project which contains a schematic entry and some textual documentation. When he clicks on the schematic part, the schematics agent is called. It calls the schematic object in the database. The object notices that it needs to be in an edit mode, calls the scheduler which calls the schematic server and opens up a window on the client's workstation with the schematic entry in original documentation. (The design domain amy have specified a path for such an editor or the executable could be downloaded to the client.) When the client saves and closes the application, the schematics agent stores the schematic entry as an object in the database which triggers a closing of the connection of the schematic editor from the clients workstation.

When the user clicks on the textual part of the document, a window is launched (wizard) asking which text editor the user wants to use, emacs, Word, html editor, FrameMaker. It also asks what the user's needs are, whether it is purely textual editting, or will there be pasting of gif files or bitmaps, his time constraints, memory configuration etc.. After the user's inputs, the wizard "decides" the best option would be to use Adobe's Acrobat Reader. The agent then retrives the location and actions required for downloading from the database and downloads the application from the WWW. It also automatically reconfigures itself and adds the entry to the list of available editors. The Acrobat Reader is then launched and the text portion chosen ready for editing.

Back to Index


Modified: March 19, 1996
Feedback: (fchan@ic.eecs.berkeley.edu)