next up previous contents
Next: 4.2 Server, Clients and Up: 4. Implementation Previous: 4. Implementation


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.
\includegraphics[clip, width = 4cm, keepaspectratio]{ArtifactBlocks.eps}

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.
\includegraphics[clip, totalheight = 6cm, keepaspectratio]{ArtifactClass.eps}

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.

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:

next up previous contents
Next: 4.2 Server, Clients and Up: 4. Implementation Previous: 4. Implementation
Norbert Harrer