System Aspects

2. Components   Client   The client tier consists of a Java applet that runs from a web browser. As a presenter delegate, it provides a graphical user interface for viewing, specifying and modifying project information.
The client tier does not interface directly in any way with a database, but it does maintain local state information.   Server   The application and database server tier provides access to data in persistent storage. The application services center (a facilitator delegate) is responsible for all database transaction handling.   Communication   All communication between client and server is done through object serialization (encoding of objects into a stream of bytes) over standard socket connections. This mechanism could be upgraded to use Remote Method Invocation or CORBA.
Communication between the application services center and the database is done through an JDBC bridge.   Middleware   Most of the bussiness logic is encoded in the middleware, a package of Java classes describing the data model used. These classes are common to both the client and server, and all communication between client and server is in the form of (serialized) objects from these classes.
A distinction is made between pure data objects and network objects that support the communication mechanisms.   Services   Most of the basic functionality is provided by numerous reusable services. These are independent modules that provide specific functionality to the system, such as database access, file access and authentication. Services are intended to be small and narrow-focused. As such, a common request may involve multiple services.
Services are grouped as to whether these require database access or not. Database services exist for the different data types. Other services provide access to the underlying file system and present information about users and delegates logged on to the network.
This service-based architecture allows for an easy extension of the system's functionality through the development and integration of new services.   Webtop   The webtop server tier brings this functionality closer/faster to the client. It serves as a cache for project information from the database and provides local services.
The webtop services center provides local versions of services available at the applications services center. Differences in the collections of services are due to the fact that the webtop server tier does not interface directly in any way with a database, but only caches project information arriving from the database server tier. Additional services provide localized functionality, such as access to the local file system.   Delegates   Developed as a collection of delegates, the minimal system configuration provides basic access to all project information. Additional delegates may provide extended functionality, short cuts or access different resources. Developed as individual Java applications, these can be dynamically linked into the system and access all services available (though functionality may be limited through access rights). They present themselves to the user as icons in the user interface. Four types of delegates can be distinguished: a representative represents a user to other users or delegates; a presenter presents information to a user in an appropriate form; a facilitator facilitates the exchange of information by structuring it appropriately; a mediator supports the communication between users and delegates. Both the webtop server tier and applications server tier provide a mediator to support access and communication.

3. Communication Model   Request   General information and activity requests are specified in a request object. A general request may consist of a sequence of basic requests, where each basic request concerns exactly one (named) service. A request object is served at the nearest service center, where each component is submitted to the appropriate service, in the specified order. If a service is unavailable or the available service cannot serve the particular request, the request is forwarded to the applications service center (if not already there).   Result   A basic request may only concern an action, or may result in information to be returned to the requester (or designated adressee). In the latter case, the resulting information is attached to the request and the request is flagged as successful. This resulting information can also be made available to the immediately subsequent request component in the sequence, for further action.   Exception   If any problem occurs while attempting to serve a request, the request is flagged as unsuccessful, a short message describing the problem attached to the request, and the request is immediately returned to the requester (or designated adressee), even if subsequent request components existed.   Event   Certain actions may be of interest to other users or delegates, e.g., the modification of a document. Such actions will result in an event that is posted (pushed) to all interested parties. The information that is sent with the event depends on the particular event. Five different types of events are distinguished: user events (users logging on or off), delegate events (delegates connecting or disconnecting), document events (altered documents), partner events (altered partner information), and project events (altered project information). Users and delegates can specify the types of events they are interested in when they log on or connect to the mediator.   Package   All information sent across the network between users and delegates must be packaged. The package information minimally includes adressee and sender information. Additionally, a return address may be specified that is different from the sender. If a result or response is forwarded in this way, the package information also includes the original sender.   Mandate   A mandate provides a delegate the means to represent itself within the client interface of a user. This mandate may contain a script (HTML and Javascript, or a URL) to be displayed in a specified window, as well as data. The script presents the delegate's functionality to the user and can rely on the data provided as well as other data accessible in the client interface. Such a mandate is commonly sent to the user in response to a query invoked by clicking on the delegate's icon in the client interface.

4. Security - Am I who I say I am?   User authentication   Upon starting the client interface, the user is queried for a password. This user authentication is important for a correct assignment of user access rights. A guest account allows non-registered users to access the system. They are asked to provide their e-mail address for identification. - Your signature is your word   Signatures   In order to have more than the minimal guest access rights, every delegate must be authenticated by its owner with a key pair (public and private). All public keys are deposited at a central repository (the applications and database server). Unless an owner's public key is deposited, no corresponding delegate will have access to the system.
When a delegate connects to a server, it authenticates itself by digitally signing a server-provided text for verification. - Can I trust the system?   Webtop authentication   The system distinguishes requests that can be considered user-independent, e.g., retrieval of partner, project or document information, from other requests that require user identification during the servicing of the request. The latter include all actions to create or modify information as well as document search requests, where the search result depends on the user's access rights.
User-independent requests can be submitted by any webtop server at any time. Other requests are only accepted when these originate from users that have indicated they trust the webtop server's owner. When a user authenticates, this is an automatic indication of trust with respect to the mediator (webtop server tier) this user is logging on to, until the moment the user logs off. Through the security delegate, a partner can indicate such trust to span the periods between consecutive authentications, for any particular owner.
This allows a partner to enable a delegate to act on the partner's behalf even while she is logged off. It also provides the owner's administrator with the ability to overwrite a partner's password, to assist this partner when she has forgotten her password. - What about other delegates?   Delegate authentication   For all other delegates, if a delegate has the same owner as the mediator (server tier) it connects to, then the delegate is allowed to submit a request from any user currently logged on to this mediator. Otherwise, a delegate is considered a guest (with corresponding privileges), and user-specific requests must be submitted from the user's client tier. - Trust is a two-way issue   Trust   The above specifications concern the identification of users and delegates in the system. An additional security feature allows you to ensure that information provided is reliable and originates from the database. Data objects have a trust lock, that can only be set by a database service. This not only ensures the origin of the information but also inhibits anybody from tampering with the information.

5. Data Model   Project   The information space is organized into projects. Each project specifies an administrator, its organization, the project partners involved and the access rights for these partners. The project-specific information may also contain a set of phases with start and end dates for this project. Projects are linked into a hierarchy; the root project specifies the entry point into the information space. Partners in a subproject must also be a partner in the root project.   Partner   For each project partner, a user profile is established that contains all contact information for this partner. This information can be maintained by the partner self. Partners must authenticate to the system in order to be recognized as oneself. This recognition serves to author documents and actions, such that both credit and responsibility are assigned to the right person. Partners are grouped into teams. Teams can only be defined for the root project, but this organization into teams is also visible in subprojects.   Document   Documents constitute the entities in the information space. The types of documents are defined by the partners and the applications and tools they adopt. Documents are referenced in the database by URL. Other document information includes categories, attributes, authoring and timing information and links to other documents. Document links allow the user to specify relationships between different documents, e.g., to group entities, specify threads of messages or attach messages to other information entities, or specify versioning sequences in collaborative work. Other user-defined links can also be specified. Link information includes authoring and timing information and an optional qualifier.   Cube   The documents in a project are organized according to three dimensions, named area, time and type. Each combination of project, area, time and type specifies a cube in the information space. The exact specification of these dimensions, i.e., their units, are left to the project team, in person of the project administrator. Documents may be searched and retrieved by cube. Search criteria include authoring and timing information, categories and attribute information.   Authoring   Authoring information is automatically recorded by the system as a result of user actions on documents or links. Additional authoring information can be specified to collaborative documents: partners can be specified as readers or writers for a specific document. Only readers and writers have corresponding access rights to collaborative documents.   Access rights   User access rights are specified by cube. A user may have delete, write, read or no permission to all the documents in a cube. Collaborative documents, with specification of readers and writers, overwrite these permissions by individual document.

  References A. Gupta, C. Ferris, Y. Wilson and K. Venkatasubramanian, Implementing Java computing: Sun on architecture and applications deployment, IEEE Internet Computing March-April 1998, 60-64.