Verteilte Transaktionen über EJB-Container-Grenzen hinweg sind ohnehin zu vermeiden, da ein dafür nötiges Two-Phase-Commit-Protokoll (kurz 2PC) im Fehlerfall zu Schwierigkeiten führen kann. Übergreifende Transaktionen über Container verschiedener Hersteller hinweg sind kaum zu realisieren, da es keine Standards für 2PC gibt.

Deployment und Konfiguration

In der Praxis wird häufig die Frage gestellt, wie man EJB-Anwendungen konfiguriert und verteilt (Deployment). EJB-Applikationen an verschiedene Systemumgebungen anzupassen ist selten trivial. Hinzu kommt, dass der Betreiber einer EJB-Anwendung nicht unbedingt das Know-how besitzt, um selbstständig bestehende Enterprise-Archive-Dateien (EAR) zu konfigurieren. Außerdem zieht zum Beispiel die Änderung eines Deployment Deskriptors immer ein erneutes Deployment der Anwendung nach sich, was operative Risiken in sich birgt. Ganz abgesehen davon ist aus Gründen der Qualitätssicherung eine Manipulation einer einmal installierten und getesteten EAR-Datei häufig nicht erwünscht.

Komfortabler ist hier eine Lösung, bei der eine einmal ausgelieferte EAR-Datei direkt auf unterschiedlichen Systemumgebungen installiert werden kann. Neben dem EAR-File weitere Konfigurationsdateien zu verwenden führt meist zu Problemen, da der Dateizugriff auf solche Files sowie die Festlegung ihres Speicherorts innerhalb des Applikations-Servers nicht standardisiert ist. Bei umfangreicheren Anwendungen hat es sich bewährt, die gesamte Konfiguration in eine Datenbank auszulagern. Somit muss im Idealfall nur die "Datasource" konfiguriert werden, was außerhalb der EJB-Anwendung erfolgen kann. Ein weiterer Vorteil: Umgebungen lassen sich dynamisch konfigurieren, und ein erneutes Deployment erfordert keinen Neustart.

Konfigurationsschnittstellen

Ebenfalls empfehlenswert ist es, EJB-Anwendungen von Beginn an mit eigenen Konfigurationsschnittstellen auszustatten, die sich zum Beispiel über Web-Services und einfache Web-Frontends aufrufe lassen. Hierzu können Entwickler auf ausgereifte Basistechniken wie zum Beispiel JMX zurückgreifen.

Für kleinere Umgebungen beziehungsweise Systeme, die keine Datenbank verwenden, kann auch die Konfiguration über die Systemvariablen des Containers (System Properties) erfolgen. Da diese jedoch für den ganzen Container gelten, ist darauf zu achten, dass es hier nicht zu Konflikten mit anderen Anwendungen kommt.

Mandantenfähige Anwendungen

Eine genaue Planung erfordert es auch, wenn Anwender mehrere Instanzen einer EJB-Applikation parallel betreiben möchten. Dies ist zum Beispiel von Belang, wenn ein mandantenfähiges System zu realisieren oder verschiedene Entwicklungsstände in Produktion zu bringen sind. Anwender müssen klären, wie einzelne Instanzen voneinander getrennt werden können. Der Grund: Es ist nicht einheitlich geregelt, welche reale Ablaufumgebung ein Server für Anwendungen eines Containers zur Verfügung stellt.