Die Lösung “Automation Middleware” (AMW)

Mit AMW wurde eine Webapplikation geschaffen, um sämtliche Konfigurationen von Java EE Applikationen auf X Umgebungen in unterschiedlichen Versionen zu verwalten.

Es wurde darauf geachtet, das Datenbank-modell so generisch wie möglich zu gestalten, damit die Redundanz nahezu eliminiert werden konnte. Zudem wurden Hierarchien eingeführt, um Property Werte global, auf Umgebungsebene, pro Applikationsserver oder pro Applikation zu definieren respektive zu überschreiben. So können Ausnahmen durch Überschreiben eines globalen Properties einfach implementiert werden.

Konkret wird eine Java EE Applikation nun im AMW konfiguriert. Beim Generieren der Konfiguration werden die erfassten Werte auf den passenden Ebenen gesammelt und über ein Template in die effektive Form gebracht. Zudem wird die Applikation selber in der konfigurierten Version aus dem Applikations-Repository geholt. Anschliessend wird die Applikations-Konfiguration inklusive Applikation zum gewünschten Zeitpunkt auf dem Applikationsserver deployed.

Eingesetzte Technologien

Vorgabe war ein Java EE Stack mit EJB 3.1, JSF 2 und Richfaces, die restlichen Komponenten wurden in Zusammenarbeit mit dem Kunden eruiert und eingeführt. Die verwendeten Technologien setzen sich wie folgt zusammen:

• EJB 3.1 (Enterprise JavaBeans)
• CDI 1.0 (Contexts and Dependency Injection for the Java EE Platform)
• JSF 2 (Java Server Faces)
• RichFaces 4.1
• JPA (Java Persistence API) 2
• Hibernate 4
• Envers 4 (Wird für die Historisierung sämtlicher Daten verwendet)
• Freemarker 2.3 (Wird zum Generieren der Templates verwendet)

Die Applikation wird in einen JBoss EAP 6 deployed und betrieben. Die Konfiguration der Applikation wird durch AMW selbst verwaltet.

Eine besondere Herausforderung war das Datenbanksystem DB 2 (Vorgabe vom Kunden). Bereits zu Beginn wurde Puzzle intern eine eigene DB 2 Datenbank (Community Version) auf Linux installiert. Diese Instanz wurde für Integrationstest verwendet, welche jeweils vor einer Lieferung durchgeführt werden. Das Vorgehen hat sich bewährt.

Projektvorgehen

Gemeinsam mit den Kundenvertretern wurde zu Beginn Scrum als Projektvorgehen definiert. Wir erachten heute den Entscheid als optimal – so konnten wir stets auf äussere Einflüsse reagieren und Schritt für Schritt vorwärts gehen.

Der Product Owner wurde vom Kunden gestellt. Dies brachte die nötige Nähe zum Business und die Flexibilität, schnell auf Änderungen zu reagieren. Allerdings setzt diese Kombination ein gegenseitiges Vertrauen voraus, worauf wir zurückgreifen konnten. Die Rolle des Scrum Masters wurde durch Puzzle übernommen.

Früher Einbezug von UX und stetiger Kontakt

Besonders hervorzuheben ist die enge Zusammenarbeit mit unserem User Experience Studio, was wir mittlerweile als Fundament für ein erfolgreiches Projekt betrachten.

User Interfaces wurden bereits früh im Projekt durch die Usability Spezialisten spezifiziert und dokumentiert. Dies hatte nebst dem durch Spezialisten designten Interface auch den Vorteil, dass sich das Projektteam und die Stakeholder des Kunden frühzeitig ein Bild über die zukünftige Applikation machen konnten.

Anschliessend begleitete das UX-Team das Projekt in beratender Funktion. So konnten die Usability- und Interface Spezialisten im Verlaufe des Projekts ihre Stärken im Bereich der Interface Designs durch CSS, HTML und Javascript Implementierung konstant einbringen. Dies hatte den Vorteil, dass sich die Software Ingenieure auf das Umsetzen der Features kümmern konnten, während die UX Spezialisten die Feinarbeit im Interface Bereich äusserst effizient erbrachten.