Sextant - A JEE standard and interoperable Geoportal solution

09/05/11 12:07

IFREMER, the French Research Institute for Exploitation of the Sea, has just published online a new version of their georeferenced marine data portal, SEXTANT. Geomatys was responsible for a significant part of this, seeing that we took charge of the realization of the “Cart” and “Geoviewer” components, the global configuration of the platform, the personalization of the portal as well as the inter-portlet communication to the “Catalog” portlet, which was done by a different service provider.

This project is interesting in more than one respect, as it offered the occasion to implement different technical solutions developed by our teams and to integrate them into the Liferay portal solution, making it a true Geoportal solution.

Geoviewer : a cartographic visualizer as a portlet

The technological core:

LIferay is an enterprise portal solution developed in Java/JEE, respecting the standards laid down by the Java Community Process for developing portal solutions. The use of standards has allowed Liferay to set up a “Container Portlet”, a technical receptacle destined to host “portlets” or application components based on the JSR 286 standard. Furthermore, it defines a communication module which is also standardized (Inter-Portlet Communication), allowing the portlets to interact, even though they were developed in perfectly isolated contexts or using different technologies or languages. We shall see that these advantages were particularly valuable in the context of this project.

Yet, let us focus on the platform.

Apart from portlet execution, Liferay also offers an environment permitting fine-grained integration within an enterprise setup. This includes: communication with LDAP directories, integration into SSO, CAS and OpenID authentication solutions, as well as the possibility to compartmentalize the portal into regulated communities through user specific rights and roles, to name but a few. Liferay notably embeds a large quantity of portlets allowing the establishment of more classical content management solutions, shared calendar solutions and a whole array of utility applications.

The application components:

The challenge with the Sextant project was to develop several distinct application components, and to finely integrate them in a way as to develop an application not reflecting any heterogeneity. In this context, it was thus necessary to implement all of the advantages offered by the JSR 286 standard and to propose portlets featuring Javascript-rich interfaces built around a kernel written in Java and communicating via the IPC protocol.

For the past three years, the Geomatys teams have been developing MapFaces, a hybrid solution combining Java/JEE and Javascript with the objective of offering WebSIG clients that are perfectly integrated into a JEE environment. Our aim had long since been focused on the portal and its standards, and it is thus only natural that we used this cartographic framework to develop the two portlets that we were contracted to handle.

With MapFaces relying on the JSF presentation framework developed in JCP (JSR 314), it therefore has the capacity to handle portlet building and the ability to perfectly integrate with Liferay.

The “Geoviewer” portlet is the portal’s cartographic visualisation component. This tool allows you to visualise a large number of cartographic layers obtained from a multitude of WMS services. These services are provided by various solutions, such as Mapserver or Constellation-SDI, for the multidimensional information sources. This geovisualiser includes all of the classical functions of this type of tool, with the addition of its capacity to interrogate the multidimensional services, notably the Coriolis, Mars2D or Mars3D modules.

MapFaces was developed parallel to Constellation-SDI; we thus tried to propose a client module for each Web service provided by Constellation. The Geoviewer is consequently already capable to further interrogate the SensorWeb Based (SOS/SOS-T) data consulting Service, put in place to serve the in-situ information from the fixed and drifting floats managed by IFREMER. As for future prospects, chances are that the further development of Sextant could very well offer the possibility of consulting these information sources by means of additional components.

The “Cart” portlet is a data extraction module relying on a batch mode solution. The interface simply allows you to define data sets, to specify the spatial reference data output system, to draw a bounding box and to launch the command that will then execute the task. Once the extraction is finished, the user is informed by email of the availability of data layers on a remote FTP server. This module hooks up to existing extraction services within the institutes Information System, and, together with the other portlets of the project, adds interaction capacity.

Interactions within the Sextant portal

Integrating the portlets:

This last section clearly illustrates the advantages of a portal solution developed in a multi service provider context. As stated in the beginning of this article, IFREMER has called upon two service providers to develop the portal components. The first was in charge of implementing the catalog and the client exploiting it, and the second, (Geomatys in this case), was in charge of the two above mentioned components, the integration of all the portlets in the Liferay portal as well as their communication and configuration.

For this project – with the “Catalog” portlet having been developed by a different service provider – technologies different to our own were used (in this case an OpenLayers and Jquery). We took the developments provided throughout the completion of the project which we then encapsulated into Java code in order to make the global configuration of the portal possible.

Finally, after having integrated the three business modules into Liferay, we worked towards making them communicate among themselves in IPC mode. It was therefore possible to let the components that had been developed with different technical solutions interact in order to get a seamless solution.

An example of the use of IPC in a heterogeneous portlet context

Here, the portlet solution fulfills a twofold role, seeing as it allows the components to communicate among themselves at a very fine granularity (an action on a button in portlet A can prompt an action on one of the components in portlet B). Furthermore, the rules for rights management provided on “portlet container” level are applied in a transparent way to all the portlets developed for that purpose.

Furthermore, this portlet concept together with the interaction capacity attributed by this standard opens up encouraging perspectives in functional modularity and enhancement for Web-SIG applications built in the form of Geoportals. It is important not to confuse them with certain practices implementing Iframes (there are also portlets encapsulating Iframes), because it would then be impossible to provide any direct interaction between the modules.

Within the scope of this project, the Liferay portal has also been enhanced to enable global and adaptive management of the cartographic configuration of each of the portlets, for all of the communities. It is possible to easily parameterize the initial extent of the cartographic contexts, the predefined zooms, the URL of the cartographic context file to be loaded in such and such portlet, the CS-W server URL for the “Catalogue” portlet and so forth. In short, each community (or “sub-portal” containing its own portlets) has the ability to use the same base modules, but configured in totally different ways.