Andrea's Home Page - Andrea architecture

Andrea architecture

Andrea is a Distributed, Object Oriented Window System, with a client - server architecture. It is designed to work on UNIX systems.

The Andrea Window System has two main parts:

1. Server side, platform-independent and device- independent, which consists in several services like object management, graphic aspect control, fonts and images handling and others.

2. Client side, platform dependent, which runs on the local machine and controls the user inputs and outputs. It provides device drivers and graphic libraries.

A third part exists, the Applications side. This part consists in Andrea applications and this applications can run on machines different than server machine and client machine. But this side is not a part of Andrea System itself.

These three entities are communicating using different channels. All of them are running on different machines, network transparent. This way, Andrea is a distributed system. Particulary, the Client and the Applications may run on the same machine as the Server.

The following picture presents the architecture of Andrea Window System:

[Andrea Architecture]

Even Andrea has a client-server architecture, client and server are not monolithic applications. Both client and server consists in small applications which perform particular, well defined tasks. This tasks communicates one with other (see figure), and all of them are independent processes. This approach provide a high level of flexibility and diversity, because users can choose any service (except the Andrea Server) in same way they can choose the desired wallpaper image. All of this services will always perform the same taks, but in different ways. And what is more important is that interfaces between services will be always the same.

But this micro-kernel (or micro-server) architecture allows and encourages developers to write more services for the same task, so the final user have the posibility to choose anytime the one he wants. More than this, the maintainance of the whole system will be easier.

Communication mechanism

Communication system is implemented using a library which is linked with every application, even with Andrea components. This library provides platform-independent and protocol-independent functions that allow inter-object communication. At this moment, the TCP/IP protocol is used for remote communications, and shared memory (IPC) for local inter-process communication.

Server side

Andrea Server's main job is the management of objects on the screen. It controls what is on top, what is hidden and what is partially covered. When an application creates an object Andrea Server puts it on the objects table and destroys it when application does that. But how can Server know when an object is created? If the application and Server run on the same machine, they share the memory area of the object. But if the application run on another machine, object's constructor sends to Server, through network, the objects properties and Server will create a similar object with received properties. This ability of an object is implemented in root object of Andrea hierarchy so the programmer is out of any worry.

Another job of Server is to manage user inputs (key pressed and mouse movement and pointing). It determines the object who will receive these inputs and puts in its queue some messages. Finally, Andrea Server sends outputs to Andrea Client using an Aspect Manager.

An Andrea Server will be started for each client connection.

Aspect Manager's single job is to control aspect of every object on the screen. When Andrea Server wants to draw an object it does not perform that directly by communicating with the Client. Andrea Server will send to Aspect Manager the properties of the object (coordinates, text, status, etc.) and, at Aspect Manager request, enviroment properties like system color, font size and style, and others. Aspect Manager will decide how the object must look like and will send to Client one or many graphic primitives like points, lines, fills command, etc. The only condition is not to get over the object area. So it is possible to develop an Aspect Manager who draws objects like Motif, another for OpenLook, another for Windows'95 and so on.

Because of graphic primitives, vector images will be more performant than bitmap images. But Andrea implements a caching mechanism similar to web browsers to decrease the traffic and time of waiting.

An Aspect Manager will be started for each server started.

Color Server implements Color Management System, designed to support any color representation model such as RGB and CYMK for example. To perform it, Andrea defines hardware color, an unsigned four byte integer to represent a shade of color. The first mode to use colors is to work with this hardware color itself or with it's text equivalent like "Blue" of "Aquamarine". Corespondence between several color names and integer values is realized by a configuration file. More, any application can create its own colors name or modifing existing one, without affecting other applications. The second way is to translate a color from a particular representation model to a hardware color value using proper routines by an application. These routines are not part of Andrea Color Management System but will be available in shared libraries.

Usually, Color Server will be started once, but if a Client desire another Color Server, this one will be started, if available.

Image Server provides graphic format handling. Handling of graphic formats is requested by Aspect Maganager and applications. Because the diversity of graphic file formats, fonts, icons, mouse pointers, etc., Andrea provides a unique mechanism to load and handle any image. We decided to use the "lug" library developed by Raul Rivero. There are many, many graphic formats and Andrea cannot support all of them from the beginning. But like communication protocols, new formats can be added to Andrea without any change in existing software at that moment. This is also true for fonts and other types of visual resources.

Another feature is there are no restrictions in using images. For an icon, for example, you can use any available image which will be scaled at icon size established by the user. No matter if it is a very large one. It's his problem to wait for scalling and transferring. For backgound he will be able to use every documents recognized by a viewer. Initially, only few image types will be recognized, but in the nearly future will be possible to use for background HTML, PostScript or other formatted documents, or even video sequences like MPEG, FLI, AVI, and so on.

Usually, Image Server will be started once, but if a Client desire another Image Server, this one will be started, if available.

Font Server provides the same services as Image Server, but for fonts. Our desire is to be developed servers capable to handle large types of fonts, like TrueType 1 and 2, Adobe and others.

Of course, some other servers may appear in time, providing different services.

Client side

Andrea Client does not know anything about applications or objects. It provides a graphic screen where it draws graphic primitives received from Aspect Manager. It also sends to Server all user inputs from keyboard and pointing device like mice. It works with the graphic adapter and monitor using device drivers and a graphic library. The device drivers are implemented as separated processes, and these are managed by the graphic library. This way, the Client will be easy to install and configure, and the drivers will be easy to develop.

Andrea Client can be ported to any system that supports graphic displays and network communications. In environments where proper graphic libraries and device drivers already exists, only communication library and client are to be ported. This enable Andrea to be used in etherogenous networks.

Applications side

Applications are servers for the user, and clients for Andrea Server. Applications used can be run locally or remotely. For Server it is no difference. This advantage provide to Andrea Window System the same features like Java applications, but with some notable differences. Applications will not run on the machine used by the final user. It will run on the Application Server machine, or on any other host. The idea is to implement the model fat server, thin client.

The core part of Andrea is written entirely in C++. However, Andrea does not enforce programmers to use a particular language; it's enough to write the communication library for C, Objective-C, perl, python, guile, etc., together with some corresponding toolkits, even if only the C++ implementation is provided at the very start.

All Java qualities like write once, run anywhere, zero administration or single upgrade for all users can be find in this model. In the same way how Java need a Java Virtual Machine for every particular platform, it is needed a particular Andrea Client with drivers and graphic library for every platform.

Andrea Desktop is the first application started by the Client. It provides the desktop, the virtual screens, icons, takbar, launchpad, etc. In fact, it provides the graphic enviroment that user wants. Anytime, users can choose the desired one, if available.

It is not necesarry that the Desktop to be installed on the same machine like Client. This allow any user to use preferred enviroment work remotely, like telnet or rlogin. And this without massive images transfer across the network.

In a classic, etherogenous LAN, an usual situation of using Andrea Window System is suggested by the picture below:

[Andrea in a classic etherogenous LAN]