Enterprise Java Beans: Wann lohnt der Einsatz?

Ein Beispiel: Man stelle sich vor, dass eine einfache Servlet-Anwendung für das Web gegeben ist, die eine Datenbank nutzt. JDBC wird verwendet, um von der Anwendung auf die Datenbank zuzugreifen. Als Ergebnis der SQL-Abfrage erhält man das ResultSet-Objekt mit einem Datensatz, der die Geschäftsobjekte darstellt. Dies ist keine wirklich komfortable Art der Datennutzung. Letztlich werden Java-Klassen erstellt, die eine Datenbankstruktur repräsentieren. Der Code wird Elemente wie diese enthalten:

Nachdem der Programmierer sich mit dem Übergang von Ergebnissätzen zur Objektpräsentation und vice versa vertraut gemacht hat, ist es an der Zeit, sich zu überlegen, wie diese Vorgänge in MyObject selbst angesiedelt werden können. Dazu lässt man das Objekt sich selbst in der Datenbank finden und ändert oder löscht es, um so ohne direkte Verwendung von Klassen aus dem java.sql.*-Paket das eigene Servlet von den JDBC-Zugangsinformationen zu trennen.

Damit ergibt sich ein weiteres Problem: Wie kann mittels einer Abfrage ein Objekt in der Datenbank gefunden werden? Wenn es anhand des Primärschlüssels gefunden werden muss, wird der Primärschlüssel an den Klassen-Konstruktor weitergegeben – das reicht. Wenn stattdessen anhand mehrerer Kriterien gesucht werden muss, benötigt man verschiedene spezielle, statische Methoden. Zudem wird eine Möglichkeit benötigt, Transaktionen zu unterstützen und, falls nötig, rückgängig zu machen.

Wenn eine Anwendung an Beliebtheit gewinnt, werden Verfügbarkeit und Zuverlässigkeit wichtig und man benötigt Replizierung, schnelle Objektpersistenz, Zwischenspeichern von Objekten, Database Connection Pooling, sichere Transaktionen und so weiter. All diese Probleme werden durch Entity Enterprise Java Beans gelöst. Es besteht keine Notwendigkeit, die Fehler zu wiederholen, die Tausende Programmierer bereits gemacht haben. Man implementiert einfach ein paar Interfaces und denkt nicht weiter an Datenbanken, auf die zugegriffen werden muss, wenn die Persistenz der Entity Bean durch CMP (Container Managed Persistence) bereitgestellt wird. Wenn dies nicht genau den eigenen Bedürfnissen entspricht, ist das kein Problem – die Persistenz der Entity Bean kann mittels BMP (Bean Managed Persistence) selbst programmiert werden.

In der Geschäftsdomäne der Anwendung gibt es nicht nur Objekte, die Daten enthalten, es gibt auch die Möglichkeit, Aktionen mit diesen Objekten durchzuführen. Diese Aktionen repräsentieren die Geschäftslogik. Beginnt man mit dem Schreiben einer Anwendung, befindet sich die gesamte Geschäftslogik innerhalb des Servlets. Die Anwendung wird letztendlich die Unterstützung mehrerer Servlets erfordern, wobei man sich dann entscheiden kann, ob der Geschäftslogikcode jedes Mal kopiert oder in separaten Klassen unterbracht wird. Irgendwann werden einige Anwender von verschiedenen Webseiten aus mit der Anwendung interagieren müssen, die Session-Informationen dieses Nutzers müssen also zwischen den jeweiligen Anfragen gespeichert werden. Dieses Problem wird über die sogenannte Session Bean gelöst, in der die gesamte Geschäftslogik der Anwendung zusammengefasst ist. Die Session Bean kann zustandsbehaftet (stateful) oder zustandslos (stateless) sein.