Mehrere Instanzen

Betreibt man mehrere Instanzen einer Anwendung innerhalb eines Containers, so ist darauf zu achten, dass diese durch individuelle JNDI-Namen (Java Naming and Directory Interface) sauber voneinander getrennt werden. Andernfalls können sich die Softwareroutinen beim Zugriff auf Bibliotheken gegenseitig stören. Laufen wie im Falle des Java-Servers Jboss alle Anwendungen in einer virtuellen Java-Maschine, so muss das Class-Loading unter Umständen besonders konfiguriert werden. Änderungen bei den Einstellungen sowie der Neustart beeinflussen somit alle Instanzen. In vielen Fällen empfiehlt es sich daher, mehrere vollkommen getrennte Container zu verwenden, zum Beispiel indem man mehrere Instanzen des kompletten Applikations-Servers betreibt. Der Vorteil dabei ist, dass damit die Prozesse auf der Ebene des Betriebssystems vollkommen voneinander getrennt sind und jeder für sich einen überschaubaren Bedarf an System-Ressourcen beansprucht. Dieses Vorgehen führt natürlich zu einem Overhead durch redundant betriebene Serverprozesse.

Performance und Skalierbarkeit

Leistungsmessungen haben ergeben, dass Applikations-Server heute keinen Engpass mehr darstellen. Die Produkte können problemlos mit entsprechender Rechnerausstattung eine große Zahl von Benutzern bedienen. Gängige EJB-Produkte unterstützen Cluster-Funktionen, so dass mehrere Rechner im Verbund nutzbar sind. Doch typischerweise nutzen Firmen für Projekte einzelne, leistungsfähige Maschinen und ziehen die Cluster-Option - wenn überhaupt - oft erst später in Betracht. Allerdings sind Konfiguration und Betrieb eines umfangreichen Cluster-Systems auch nicht zu unterschätzen. Fällt ein Container aus, sind davon alle darin ablaufenden Beans betroffen. Anwendungen sind daher so zu konzipieren, dass sie sich leicht auf einen anderen Container portieren lassen.

Eine Architektur wird durch Cluster skalierbar, darf aber nicht abhängig davon sein. Auch aus diesem Grund sollten Unternehmen verteilte Transaktionen vermeiden. Und die sind auch gar nicht notwenig: Gerade Service-orientierte Architekturen kommen gut mit individuellen, voneinander getrennten Transaktionen aus, so dass die Komplexität einer verteilten Transaktionsverarbeitung in der Regel nicht gerechtfertigt ist.

Ferner ist es ratsam, sitzungsbezogenen Informationen überschaubar zu halten. Der Grund: Bei Verlust dieser Angaben muss der Client schnell wieder in einen konsistenten Zustand kommen, zum Beispiel mit Hilfe einer Datenbank. Beherzigen Firmen diese Regeln, so kann der Umstieg auf eine hochskalierbare Cluster-Umgebung reibungslos und gefahrlos erfolgen.

Wie geht es weiter mit EJB?

Die J2EE/EJB-Technik gibt es nun schon bald zehn Jahre, und sie ist mittlerweile bei der Version 3.0 angelangt. J2EE und EJB werden vom Java-Community-Prozesses (JCP) ständig verbessert und erweitert. Die Weiterentwicklung scheint für die nächsten Jahre garantiert zu sein.