Giselle

Giselle Architecture
System Architecture

As the system should be distributed, the three-tier client server architecture was adopted as a starting point and combined with some aspects of the terminal-host architecture to yield better performance. Figure 1 presents the details. Platform independence is assured by the use of Java as the development paradigm, and the use of web browsers running standardized Java Virtual Machine enables developers to minimize the effort devoted to hacking browser inconsistencies.

Relational databases with standardized Open GIS Community (OGC) extension for spatial data, development of OGC compatible application server and use of CORBA or Web Services standards in combination with XML data exchange format for communication assures that the solution will be compatible with the existing standards and exchangeable with other solutions.

Using web browsers for communication also enables usage of standard secure connections to assure communication security.


Figure 1: Schematic view of Giselle’s architecture

After the overview of the technologies used, let us describe the architecture into a greater detail. In the following paragraphs we will see how the described technologies were innovatively combined into the final solution.

Database Layer

For the ground database layer one of the two popular relational database servers with OGC extension can be used: open source database PostgreSQL or proprietary Oracle.

Oracle spatial database is a standard open freely available format, therefore it is our preference for the system. Other business functions can access spatial data without any custom software, just as any other attribute data. There is no lock-in for the users.

Additional arguments to use Oracle spatial database are:

• It is a proven, reliable and scalable RDBMS with built-in support for spatial data. Editing and viewing of GIS data are integrated with the non-spatial part of the business application;
• Many off-the-shelf tools and open APIs exist to access and manipulate the data for commonly used development languages such as Java or C++;
• Spatial data resides inside the database itself, so there is no need for awkward linking between spatial and non-spatial data. In addition, standard database tools such as report generators, various designers or CASE tools can be used with the spatial data;
• Built-in validation of spatial data;
• The spatial data can be managed with a generic SQL tool.

Application Layer

The application layer is a reminiscence of the terminal-host architecture in our system. Its main function is to serve as the data proxy to the database server and to pre-process this data for the client as to minimize the necessary  communication. It can also store remote spatial data layers when necessary.

Client (Presentation) Layer

Besides the user interface the client tier also contains all the application logic for data manipulation and validation.

There are two ways of implementing the presentation tier: Thin client (HTML) and thick client (JAVA).

The thin client solution can be completely internet / intranet based, meaning that all user functions are accessible from an internet browser. The thin client is used for general view of data accessed by any user. It is also used for producing geographical views for other modules like `show the picture of the parcel with ID on top of orthophoto image`, for example. There is no need for software installation and upgrades on client computers, which makes the system very easy to manage and available from anywhere, anytime and on all commonly used operating systems.

The thick client (feature rich client) is used for edits like digitalization of a new parcel, boundary change etc., which is usually coupled with some kind of wizard for the procedure (e.g. choose an applicant ID, show other data, finish). The GIS editor for land parcels can run either inside the browser or can be deployed as a client / server desktop application; the choice is left to the convenience of the user, thanks to the system's flexible configuration.
Both thin and thick client are launched as web modules in line with SSO principle of the main application.

A network launch protocol is used to automatically apply new versions or patches to all users, thus making maintenance an effortless process.
As Figure 1 presents, spatial data layers can be stored both locally on a client and on a remote server. The following combination is often used to minimize data transfer and maximize performance: the server stores a layer in vector form and the client reads it, shades it into a raster layer and adds it to the underlying image.

Although the performance issues were carefully addressed  during both the design and the development of Giselle, under some circumstances a bottleneck appears in the communication. This happens, for instance, when using extremely large raster datasets with extremely slow data connection. In such cases our client application can adapt to the situation: the user can choose to display the data in a smaller window or with less quality.

Application Architecture

Architecture of an application built using the Giselle library is shown in the figure below:



The building blocks composing the Giselle library are:
Widgets for the Graphical User Interface, such as the layer tree, dialogue boxes for setting properties of features and layers, tool bars... These widgets depend on the Application Programming Interfaces (APIs) exposed by Giselle core;

Giselle core is attainable to the application atop of it and the Giselle Widgets are accessible through a set of well-defined interfaces.

Giselle is not a monolithic framework, but a collection of tools, which makes it possible to use Giselle in applications built with other frameworks providing they are enriched with GIS functionality.

To allow easy integration of Giselle-based applications  into any kind of environment, the architecture is built around the concept of a plug-in. The plug-ins allow Giselle core and the application atop of it to transparently access GIS data from arbitrary data sources, such as:

• Spatial databases;
• Web services, either compliant to standards such as OpenGIS or custom; A Giselle application running on a server (a special web service);
• Files, stored on the local hard disk, on a CD or on network shares;
• Legacy sources of GIS data.

Through prebuilt plug-ins, Giselle achieves interoperability with the many data formats that exist in GIS and agro-environment data management systems.

Apart from being adjustable towards data sources, Giselle-based applications are also customizable for the users. Giselle has facilities for managing the configuration of the application such as the display styles of features, the data sources and properties of layers, etc. The default configuration for a given user profile can be stored at a central location (e.g., the Giselle server), but can be overridden by individual users, depending on the user's permissions.

Giselle-based applications are easily localizable in any of the European languages. The messages that are displayed to the users are stored in special property files, allowing localization without affecting the code of applications. Also, the appearance of applications can be arbitrarily customized to fit the branding needs of the organisation deploying a Giselle service or application.

Front page | Technical Background | Deployment Requirements | Giselle Architecture | Interoperability

For more details, contact :