Lean Software Development ist eine Disziplin der agilen Softwareentwicklung. Für die Softwareentwicklung bedeutet lean (schlank), nur das Wesentliche ohne überflüssigen Balast zu implementieren. Lean Softwareentwicklung wird von klaren Anforderungen und einem hohen Verständnis für eine Technologieplattform getragen.
Java EE hat aus der Entwicklerperspektive sehr viel Balast verloren. Java EE ist leichtgewichtig, Deployment Deskriptoren sind optional und werden zumeist durch Annotationen ersetzt. EJB 3 Komponenten implementieren schlanke Java Schnittstellen ohne zusätzliche EJB-Artifakte.
Java EE ist vorkonfiguriert ("convention over configuration" bzw. "configuration by exception"), sodass häufig mit wenig Quellcode ein vollfunktionsfähiger Service implementiert wird. Java EE ist durchgängig, sodass mit JSF 2, CDI, EJB 3 und der JPA mit wenig Quellcode Daten von einer Webseite in eine Datenbank geschrieben werden können. Java EE ist klar spezifiziert und durch eine Referenzimplementierung gesichert. Java EE ist ein Framework, der dem Entwickler keine unnötige Last aufbürdet. Java EE ist herstellerunabhängig und auf unterschiedlichen Applikationsservern betreibbar. Die Liste des Lobes könnte noch sehr viel länger werden, im Kern aber nicht mehr Aussagen als: Java EE ist ein Standard mit hohem Reifegrad.
Die Gefahr den Standard zu unterschätzen ist trotz des Reifegrades nach wie vor gegeben. Häufig werden Java EE Anwendungen durch ein bestehendes Datenmodell getrieben. Ein korrektes Datenbankmodell und das Nutzen der Möglichkeiten des Datenbankmanagementsystems ist deshalb essentiell für eine Java EE Anwendung, die dem "Lean Ansatz" gerecht wird.
Ein aufgeblähtes Persistenzmodell mit vielen häufig unnötig vorgeladenen Entitäten bringt eine schlechte Performanz hervor. Die Ladestrategie "Lazy Loading" kann die Situation verbessern, bei falscher Verwendung durch höhere Komplexität allerdings zur Fehleranfälligkeit führen. Konform der Separation of Concerns sind Funktionalitäten, die in der Persistenzschicht einer Java EE Anwendung implementiert werden, ebenfalls in Stored Procedures und Datenbanktrigger auslagerbar. Darüber hinaus trägt der Einsatz von Views wesentlich zur Vereinfachung eines komplexen Datenmodells bei und reduziert die Anzahl der im Persistenzkontext der Java EE Anwendung vorgehaltenen Entitäten.
Schematische Darstellung einer View-Struktur
 | |||
| View-Struktur |
Neben den Views ist es ebenso naheliegend Stored Procedures als "Subqueries" in SQL-Abfragen und Triggern zu verwenden. Beide Varianten sind in der Praxis zu finden. Ein Datenbanktrigger entlastet eine Java EE Anwendung. Datenbanktrigger sind vielfältig bei Datenbankoperationen einsetzbar. In der Persistenzschicht einer Java EE Anwendung stehen Interzeptoren für Entity Manager Operationen (@PrePersist, @PostPersist, etc.) zur Verfügung. Diese Interzeptoren sind konform mit den Datenbanktriggern, belasten aber zusätzlich die Laufzeitumgebung des Applikationsservers.
Szenario mit Datenbanktrigger und Stored Procedure
 | |
| Separation of Concerns mit Trigger und Stored Procedure |
Erläuterung des Szenarios:
- Speicherung der Bestellung über die Facade auslösen
- JPA Provider speichert die Entität der Bestellung in der Tabelle für Bestellungen
- Das Datenbankmanagementsystem feuert den Trigger für Neubestellungen
- Der Trigger für Neubestellungen führt die Prozedur zur Aktualisierung der Produkttabelle aus
- Die Produkttabelle wird aktualisiert
- Das Datenbankmanagementsystem feuert den Trigger zur Aktualisierung der Produktmenge
Das Szenario verdeutlicht, wie Funktionalitäten in das Datenbankmanagementsystem verlagert werden, um die Last in der Persistenzschicht einer Java EE Anwendung zu reduzieren. Es ist deshalb empfehlenswert die Planung der Nutzung des Datenbankmanagementsystems in die Konzeption einer Java EE Anwendung mit einzubeziehen. Diese Vorgehensweise wirkt sich später bei hoher Produktionslast positiv auf die Antwortzeiten einer Java EE Anwendung aus.
