Software standards of EEA and Eionet

Apologies. This web page contains obsolete information. For questions regarding EEA / Eionet technology infrastructure, please contact the EEA's IT Steering Committee.

EEA is mandated to provide high quality information to support the environmental policy process and sustainable development, and raise public awareness. One of its main tasks includes providing that information to a very wide range of target groups. The Internet is a perfect tool for this type of mission. EEA products displayed online should provide the best experience, be accessible to the largest possible number of users, across a wide range of computing equipment, operating systems and/or browser software. Online products should, in that perspective, not only be user-friendly, but be designed for unexpected usage.

Due to history and technological constraints, EEA's software development work fall into five technological areas:

Intranet
EEA's public websites
Geographical information systems
Eionet
Websites shared with other organisations

The aim of these guidelines is to provide guidance for the implementation of high quality products meant to be part of EEA's online communication in the Eionet and EEA public sphere.

The purpose of this document is to map the road of EEA's software development with a three year horizon. Compared with earlier versions of this document, EEA now has a large investment in existing infrastructure that it wishes to build on and protect.

Operational Rules

These standards shall be used by all projects that build shared infrastructure or common software tools for EEA in the relevant technological areas. It is not always possible for a project to determine the wider implications of their choices. Therefore, any project that starts software development shall do any of the following:

Comply with the standards. It is a good practice to inform EEA's IT Team of the choice and check about possible upcoming changes at project start.
Decide that the application is for use by the developers and their immediate colleagues only. In this case the standards don't apply.
Make a well-justified written application to EEA's IT Head of Programme to be allowed not to comply with the standards, understanding that support will in this case be limited.

If there is no standard in a particular area, the choice is open. However, it is still a good practice to inform EEA's IT Team.

Terminology

MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the item is an absolute requirement of the specification.
MUST NOT: This phrase, or the phrase "SHALL NOT", mean that the item is an absolute prohibition of the specification.
SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any functionality described with this label.
MAY: This word means that the the item is preapproved, and should be considered before considering other items not in the specification, but the item is not a core technology.

Service Levels

The standard systems listed herein are supported by EEA's IT Team and by the Eionet Network Management Centre. They are or can be installed to all systems upon request.

Software tools

All new software must be developed with products listed.

Operating Systems on Servers

Must use:

Linux
Windows Server 2003/2008

GIS tools/formats

Must use one or more of following:

ESRI file geodatabase/personal database/ArcSDE databases
Shapefiles
OGC and INSPIRE standards
FME (Feature Manipulation Engine) from Safe Software (Workspace and Server)
ArcGis from ESRI (Desktop and Server)
ArcGis online

Document Interchange Formats

Must use one or more of following:

(X)HTML
Those compliant with Microsoft Office Professional
OpenDocument
PDF

Relational databases

(should use) MySQL, PostgresQL or SQL Server 2005/2008
(should not use) Oracle

Internet Services

Should use:

HTTP on Apache
HTTP on IIS
Zope for application server
Tomcat for Java Servlets and JavaServer Pages
Plone for Content Management System

Websites should be able to interface with a reverse proxy for load distribution and caching.

Programming Languages

Those that work well in connection with the above Internet and database services

Server side:

(Should use) Python, Java, DotNet
(May use) Perl, PHP, C, C++

Client side:

(Should use) JavaScript for simple/thin client interactive functionality
(May use) Java, Flash, FlashBuilder or Silverlight for complex/thick client interactive functionality

Note that a website that only uses non-HTML technologies on the client side is not acceptable, as it very effectively prevents search engines from indexing the site.

Work procedures

Most development projects follow the iterative model. The project is assigned one or more technical supervisors from EEA. Their job is to ensure the product fits into EEA's system and has the required functionality. The technical supervisor will be available on Email and Instant Messaging, currently XMPP (Jabber).

EEA uses Subversion (SVN) for version control. We want you to use our version control system rather than your own or none at all. This is for our benefit and your protection as it allows us to document the progress in the project easily via the commit log and to differentiate between what you (as a contractor) have delivered and what other people have done to the code.

The software must come with complete instructions on how to install it and what prerequisites there are. The instructions must be bundled with the source code. Also, write down the engineering specifications, so that other folks can figure out how to extend and enhance the product.

Source code is defined as the files and file formats a programmer uses to create a computer program. For example .java files, Flash source, Photoshop files, and image files before text is written on them.

New Projects

If a company has received the contract to create a new independent piece of software, it is guaranteed that the contractor will be the only party to make modifications to the code until such time when the product is delivered and accepted. The delivery is considered to be the base release.

There will usually be a period of warranty where the contractor is obliged to fix bugs free of charge. Though the software can have been modified in the meantime, the contractor is only obliged to fix bugs that exists in the base release.

New functionality

If a company has received the contract to add functionality to an already existing product a baseline will be established upon which the modifications are created. The company is guaranteed that nobody but that company modifies code in that particular branch.

When the modification has been delivered and accepted to work with the base line it must be merged with the main branch in the development tree. Here we again establish a base line of the main branch and merge with it. Hopefully there were no additions to the main branch in the meantime otherwise we do the cycle again.

Maintenance

After a product has been delivered it goes into maintenance mode. It will stay here until the product is scrapped. The purpose of maintenance is to adjust the product to a changing environment, add new functionality and fix bugs. To keep track of it we use an issue tracking system such as Trac. Again, this is also to document progress.

Copyrights and licensing

EEA reserves the right to decide under what terms copies of the source of a software product will be released under. This will usually be the Mozilla Public License or the GNU Public License. The contractor must respect the copyright of other parties, whose software has been integrated into the product. The contractor must not integrate software with a license that is incompatible with the product's license. All source files must include a copyright statement referencing the licence terms.

Website architecture

EEA exists to handle information. Much of that information is freely available according to Regulation (EC) No 1049/2001 and the Aarhus Convention. To support retrieval, all representations of resources (webpages) must have a persistent URL. The URL should not change when access restrictions to the resource change or if underlying technology changes.

Accessibility

On 25 September 2001 the Commission adopted the Communication eEurope 2002: Accessibility of Public Web Sites and their Content and follows W3C's accessibility guidelines. Contractors must comply with WAI-A (single-A), and should comply with WAI-AA (double-A) specifications.

EEA branding

All websites must follow the EEA/Eionet look and feel. Authors must use semantically correct HTML markup and CSS for styling.

XHTML

New websites must be authored in XHTML 1.1. When a page uses frames, popups or opens new browser windows, the format is XHTML 1.0 Transitional. All pages must validate against the W3C HTML validator.

Multilinguality

EEA lives in a multilingual world. We handle three alphabets - sometimes on the same webpage. To avoid a painful cleanup, all pages must be written in UNICODE - and this usually means served to the webbrowser in UTF-8.

Preference should be given to development tools that eases localisation of navigation and content. See also the Best Practices for multilinguality document.

Browser compatibility

Webpages must look the same in Internet Explorer 7 and Firefox 3. The same pages should be usable in older browsers as well as handheld devices, unless the nature of the webpage makes it unnecessary. In a world of browser security bugs and popup blockers, the contractor shall not rely on Javascript and the ability to open new browser windows.

Authentication

All websites in need of authentication must use the Eionet site directory - an LDAP service.

Authorisation

Eionet has developed an authorisation design that is derived from DCE and adapted to persistent URI principles. In short, for a database record, a globally unique resource identifier is constructed from the host, table and primary key. I.e. http://<host.eionet.europa.eu>/<table>/<key>. To each object is associated a set of permissions, which can be set or unset for users and groups. It is not required to control access on record level. This depends on the nature of the application.

User associations to groups are available from the site directory, but is usually maintained locally within each application.

System to system interoperability