4.1 Functionality of Artifact Objects

Artifacts as explained in chapter 3.1 are shared objects, which are made accessible to users by distributing copies of them to connected clients. The artifact has been designed to be independent from the rest of the system. It takes care of three different aspects:

  

Figure 4.1: The three function blocks of an artifact.

• Data: The artifact object encapsulates information according to the particular type of the artifact.

• Graphical User Interface: The artifact must be able to create an appropriate user interface on demand. The user can access the contained data through this user interface.

• Client Interface: This is a set of methods used by the client to integrate the artifact into the client.

The Java class Artifact is an abstract template class that is inherited by all artifacts (figure 4.2). This class contains variables and methods that are common for every artifact.

  

Figure 4.2: The artifact class.

Object Linking:

Artifacts can contain references to other artifacts. The Java objects that represent shared artifacts can not be referenced the same way as usually done in Java. The reason is that artifacts that are transmitted over the network are first serialized. Object serialization also serializes and exports all referenced objects. This is not wanted in this case, because only the artifact itself should be exported. It is possible to prevent the serialization of referenced objects in Java by declaring them transient. This does not lead to a solution either, since references can not be reconstructed at the receiver's side. No information has been transmitted that could be used to determine the links amongst artifacts in this case.

The problem has been solved by assigning each newly created artifact a unique object identification number. This ID is assigned with the constructor of an Artifact object. Artifacts refer to other artifacts via their ID's only. They are consistent at a system wide level. The ID of an artifact object is accessed by calling its getId method. Let's consider we want to refer to a drawing artifact (class GipDrawing). Usually an object would be referenced in the Java normal method:

private GipDrawing drawing = gipDrawing;

Instead, the ID of the drawing object is used now:

private int drawing = gipDrawing.getId();

Graphical User Interface:

Artifacts are completely autonomous. The client as well as the server knows anything about the nature of the containing data. The artifact can create an appropriate graphical user interface including the necessary event routines which process user inputs relative to the artifact. This is usually a Java AWT frame created on demand, which is nothing more than a window. However, not every artifact needs to create such a frame. Some artifacts use the frame of another artifact to display themselves. For example, a drawing object is using the frame of an image artifact to draw itself. There are two methods that deal with the creation of the GUI. They are called by the client whenever the content of the artifact needs to be displayed.

• isDisplayable: Artifacts that don't create frames return FALSE. This method is used by the client to determine if this artifact is able to create a frame.

• display: This method returns the frame that displays the contained data. The client is calling this method once the artifact has to be displayed.

As an example, let's consider the functionality and content of the display method for an image artifact. The display method generates a single window (frame). The main area of this window shows the image itself. The GUI components contain elements to allow the users to enhance and modify the image by providing image conversion, editing as well as manipulating and processing operations selectable from the windows menu system. In addition, the window has to receive and process events produced by mouse movement, mouse clicks and keyboard.

Client interface:

The following methods are used by the client to integrate it into the pool of replicated artifact:

• insertIntoSession: This method is called right after an artifact has been received by the client. The just received artifact can be either a new artifact or a newer version of an already existing artifact. In the later case, this method ensures that needed information is transferred from the replaced artifact before it is deleted. For example, a possible displayed frame associated with the old artifact is linked to the new version before it is repainted.

• remove: This method is called before the artifact is removed from the session. It removes all open frames and dialog boxes that have been created by this artifact.

• increaseVersion: Each instance of the Artifact class contains a version number. The version number is increased every time a new version is sent to the server.