Laufzeitkomponenten

Die Legacy-Anwendung kombiniert mehrere Java-EE-Technologien innerhalb eines Tomcat-Servlet-Containers. Tomcat stellt dabei nicht den vollständigen Funktionsumfang eines Java-EE-Applikationsservers bereit. Deshalb bringt das WAR wesentliche Laufzeitkomponenten selbst mit.

Weboberfläche

Die serverseitige Oberfläche basiert auf JSF 2.2 und Facelets. RichFaces 4.2.3 liefert zusätzliche UI-Komponenten, Skins, Datei-Upload und verschiedene Hilfsfunktionen. XHTML-Seiten und Managed Beans sind eng miteinander verbunden.

Im Browser ergänzen Dojo 1.10.1, jQuery und weitere JavaScript-Bibliotheken die serverseitige Oberfläche. Three.js und WebGL werden für die dreidimensionale Darstellung des Wissensraums genutzt. Ein Teil der Anwendung erzeugt JSON mit Klassen aus dem RichFaces-Paket, wodurch auch Fachcode an RichFaces gekoppelt ist.

REST-Schnittstellen

REST-Endpunkte werden mit JAX-RS 2.0 und Jersey 2.11 umgesetzt. Jersey läuft als eigener Servlet innerhalb der Webanwendung und verarbeitet Pfade unter /ws/*. Zusätzlich werden Multipart-Uploads, Exception-Mapping und ein eigener Transaktionsfilter verwendet.

Die Integration zwischen Jersey und CDI enthält projektspezifischen Code und verwendet teilweise interne Jersey-Erweiterungspunkte. Dadurch ist ein einfaches Versionsupgrade nicht möglich.

Dependency Injection

CDI wird durch Weld 2.2 bereitgestellt. Ein Listener im web.xml startet den Weld-Container. Beans werden über Annotationen wie @Inject, @Named, @RequestScoped, @SessionScoped und @ApplicationScoped verbunden.

Neben der normalen Dependency Injection existieren Hilfsklassen, die CDI- und JPA-Kontexte teilweise statisch zugänglich machen. Diese Kopplung erschwert isolierte Tests und einen Austausch des Komponentenmodells.

Persistenz

Die Persistenzschicht basiert auf JPA und Hibernate 4.3.6. Die Persistence Unit ist in META-INF/persistence.xml definiert und verwendet:

• den historischen Hibernate-Provider org.hibernate.ejb.HibernatePersistence,
• lokale Ressourcentransaktionen,
• eine per JNDI bezogene DataSource,
• den MySQL-5-InnoDB-Dialekt,
• Schema-Validierung beim Start.

Die Datenbank enthält nicht nur Tabellen, sondern auch Views, Trigger und Stored Procedures. Teile der Suche und Hierarchieverarbeitung verwenden natives SQL und datenbankspezifische Strukturen.

Datenbank-Bootstrap

bflies-bootstrap prüft und aktualisiert das Datenbankschema. Die SQL-Skripte sind nach Versionen geordnet und werden als Ressource innerhalb eines internen JARs bereitgestellt. Das Verfahren ist der historische Vorläufer der für BFlies Next vorgesehenen Flyway-Migrationen.

Authentifizierung und Autorisierung

Tomcat übernimmt die Authentifizierung über einen DataSourceRealm. Benutzer, Passwort-Hashes und Rollenzuordnungen werden aus Tabellen beziehungsweise einer View der Business-Flies-Datenbank gelesen.

Das web.xml definiert eine formularbasierte Anmeldung und schützt sowohl JSF-Seiten als auch REST-Endpunkte über die Rolle bflies. Die Anwendung ist damit eng an Tomcat, HTTP-Sessions und das bestehende Datenbankschema für Benutzer gekoppelt.

Container-Ressourcen

Tomcat stellt der Anwendung per JNDI zwei zentrale Ressourcen bereit:

• ds/bfliesDS als MySQL-DataSource,
• mail/Session als vorkonfigurierte JavaMail-Session.

JDBC-Treiber und JavaMail werden teilweise auf Container- und teilweise auf Anwendungsebene bereitgestellt. Diese Aufteilung ist Bestandteil des bestehenden Deployments und muss bei einem Umzug des WAR beachtet werden.