A document oriented application allows the user to save his work anytime he wants. The user also has to have the posibility to continue his work when he wants to restore the saved "document".

In our application a document is a file that contains your saved work. At this moment only one document can be opened at one time, unlike some other applications, like text editors. This part of the application is still under development. When this part is implemented every user will be able to use the application for slide shows. A user will have the possibility to create the slides he wants to present, whitout connecting to the server, and save them, on the local file system. When the user connects to the server, he just loads the "slides" and shows them, in the order he wants.

Two "tools" are at hand for data introduction. The mouse can be used for drawing objects on the whiteboard area or typing text in the chat area or whiteboard area using the keyboard. It would be better if you could connect a "pen" to your computer instead of the mouse. Using this so called pen you'll find it easyer to draw objects.

This application is designed to be used on the Internet. We can find a lot of multiuser applications on the Internet, one example could be the IRC (Internet Relay Chat) where a lot of users from every part of the Earth are connected to a server and they can communicate with each other. The WhiteBoard application is based on this multiuser concept. A server is running on a computer connected to the Internet, and users can connect to this server anytime they want and communicate with each other through the whiteboard area or the chat area of the client interface.

There are two classes in this program: the main class, StartServ, is a server that accepts connections from clients and assigns them to new connection handler objects. The Handler class actually does the work of listening for messages and broadcasting them to all connected clients. One thread (the main thread) handles new connections, and there is a thread (the Handler class) for each client.

Every new user (in our case Whiteboard user ) will connect to the StartServ; this StartServ will hand the connection to a new instance of the Handler class that will receive messages from the new user (client). Within the Handler class, a list of the current handlers is maintained; the broadcast() method uses this list to transmit a message to all connected WhiteBoard Clients.

This class is concerned with accepting connections from clients and launching handler threads to process them.

This class is a simple standalone application. It includes a constructor that performs all the work for the class, and a main() method that starts it.

This constructor, which performs all of the work of the server, is very simple. We create a ServerSocket and then wait in a loop accepting clients with the accept() method of ServerSocket. For each connection, we create a new instance of the Handler class, passing the new Socket as a parameter. After we have created this handler, we start it with its start() method. This starts a new thread to handle the connection. After this thread starts, the server waits for other connections.

This class is concerned with handling individual connections. We must receive messages from the client and re-send these to all other connections. We maintain a list of the connections in a static Vector.

We extend the Thread class to allow a separate thread to process the associated client. The constructor accepts a Socket to which we attach; the run() method, called by the new thread, performs the actual client processing.

ObjectInputStream in;

The constructor keeps a reference to the client's socket and opens an input and an output stream.

protected static Vector list=new Vector();

The run() method is where our thread enters. First we add our thread to the Vector of Handlers list. The list Vector keeps a list of all of the current handlers. It is a static variable and so there is one instance of the Vector for the whole Handler class and all of its instances. Thus, all Handlers can access the list of current connections.

It is very important for us to remove ourselves from this list afterwards if our connection fails; otherwise,all other handlers will try to write to us when they broadcast information. This type of situation, where it is imperative that an action take place upon completion of a section of code, is a prime use of the try ... finally construct; we therefore perform all of our work within a try ... catch ... finally construct.

The body of this method receives messages from a client and rebroadcasts them to all other clients using the broadcast() method. When the loop exits, whether because of an exception reading from the client or because this thread is stopped, the final clause is guaranteed to be executed. In this clause, we remove our thread from the list of handlers and close the socket.

This method broadcasts a message to all clients. We first synchronize the list of handlers. We don't want people joining or leaving while we are looping, in case we try to broadcast to someone who no longer exists; this forces the clients to wait until we have finished synchronizing. If the server must handle particularly heavy loads, then we might provide more fine-grained synchronization.

Within this synchronized block we get an Enumeration of the current handlers. The Enumeration class provides a convenient way to iterate through all of the elements of a Vector. Our loop simply writes the message to every element of the Enumeration. Note that if an exception occurs while writing to a WhiteBoard client, then we call the client's stop() method; this stops the client's thread and therefore performs the appropriate cleanup, including removing the client from handlers.

The Whiteboard application could be used as an applet that is included in an HTML page. This can be done by including a little applet, that contains only one button, which will bring up the GUI window that includes the whiteboard application. If the whiteboard is used as an applet, there will be some limitations. The user would not be able to save the created document, or could not load from the local file system. Considering these limitations this possibility is important for those users who don't have Java on their machines but have a Java enabled browser, and they consider that it's easier to use the application in this way.

Scalability is related to the possibility to further extending the capabilities of the whiteboard as an auxiliary tool for a scientific data dynamic front-end.