Ein Leitfaden für Anfänger zu Enterprise JavaBeans

Enterprise JavaBeans (EJB) hat seit der Ankündigung der Enterprise JavaBeans Specification Version 1.0 im März 1998 viel Aufregung ausgelöst. Unternehmen wie Oracle, Borland, Tandem, Symantec, Sybase und Visigenic haben unter anderem Produkte angekündigt und / oder geliefert, die der EJB-Spezifikation entsprechen. Diesen Monat werden wir uns auf hoher Ebene ansehen, was genau Enterprise JavaBeans sind. Wir werden untersuchen, wie sich EJB vom ursprünglichen JavaBeans-Komponentenmodell unterscheidet, und diskutieren, warum EJB so großes Interesse geweckt hat.

Aber zuerst ein Hinweis: Wir werden uns diesen Monat nicht mit Quellcode oder Anleitungen befassen. Dieser Artikel ist kein Tutorial. Vielmehr handelt es sich um einen architektonischen Überblick. EJB deckt ein großes Gebiet ab, und ohne vorher die grundlegenden Konzepte zu verstehen, sind Code-Schnipsel und Programmier-Tricks bedeutungslos. Wenn die Leser von JavaWorld Interesse haben , werden in zukünftigen Artikeln möglicherweise die Besonderheiten der Verwendung der Enterprise JavaBeans-API zum Erstellen eigener Enterprise JavaBeans behandelt.

Um zu verstehen, warum EJB für Entwickler so attraktiv ist, benötigen wir einen historischen Hintergrund. Zunächst werden wir uns die Geschichte der Client / Server-Systeme und den aktuellen Stand der Dinge ansehen. Anschließend werden die verschiedenen Teile eines EJB-Systems erläutert: EJB-Komponenten, die auf einem EJB-Container in einem EJB-Server ausgeführt werden, und EJB-Objekte, die der Client als eine Art "Fernsteuerung" von EJB-Komponenten verwendet . Wir werden die zwei Arten von EJBs durchgehen: Sitzungs- und Entitätsobjekte . Sie werden auch über zu Hause und fern lesenSchnittstellen, die EJB-Instanzen erstellen und Zugriff auf die Geschäftsmethoden der EJB gewähren. Am Ende des Artikels haben Sie eine Vorstellung davon, wie erweiterbare Server mit Enterprise JavaBeans erstellt werden können. Aber zuerst ein Rückblick in die Zeit.

Client / Server-Verlauf

Alte Geschichte

Am Anfang war der Mainframe-Computer. Und es war gut. (Oder zumindest so gut wie es nur ging.) Der Stand der Informationsverarbeitung in den 1960er Jahren bestand hauptsächlich aus großen, teuren Maschinen, die von großen Organisationen zur Unterstützung ihres täglichen Geschäftsbetriebs eingesetzt wurden. Minicomputer und Timesharing in den 1970er Jahren verbesserten die Zugänglichkeit von Rechenleistung, aber Information und Verarbeitung waren immer noch auf einzelnen Maschinen zentralisiert. Die ersten PCs in den 1980er Jahren überfüllten die Unternehmenslandschaft schnell mit Tausenden winziger Informationsinseln, die unermüdlich Berichte unterschiedlicher Qualität verfassten, kritische Daten verloren, wenn sie abstürzten, und schnell inkonsistent wurden.

Client / Server zur Rettung

Die Client / Server-Architektur ist eine der häufigsten Lösungen für das Rätsel, wie die Notwendigkeit einer zentralisierten Datensteuerung und einer weit verbreiteten Datenzugriffsfähigkeit zu bewältigen ist. In Client / Server-Systemen werden Informationen relativ zentral gehalten (oder auf verteilte Server verteilt und / oder repliziert), was die Kontrolle und Konsistenz der Daten erleichtert und gleichzeitig den Zugriff auf die Daten ermöglicht, die Benutzer benötigen.

Client-Server-Systeme bestehen heute üblicherweise aus verschiedenen Ebenen. Das alte Standard-Mainframe- oder Timesharing-System, bei dem die Benutzeroberfläche auf demselben Computer wie die Datenbank und die Geschäftsanwendungen ausgeführt wird, wird als einstufig bezeichnet. Solche Systeme sind relativ einfach zu verwalten und die Datenkonsistenz ist einfach, da Daten nur an einem Ort gespeichert werden. Leider sind einstufige Systeme nur begrenzt skalierbar und anfällig für Verfügbarkeitsrisiken (wenn ein Computer ausfällt, fällt Ihr gesamtes Unternehmen aus), insbesondere wenn die Kommunikation involviert ist.

Die ersten Client / Server-Systeme waren zweistufig, wobei die Benutzeroberfläche auf dem Client ausgeführt wurde und die Datenbank auf dem Server gespeichert war. Solche Systeme sind immer noch üblich. Ein zweistufiger Servertyp mit Gartenvielfalt führt den größten Teil der Geschäftslogik auf dem Client aus und aktualisiert gemeinsam genutzte Daten, indem SQL-Streams an den Server gesendet werden. Dies ist eine flexible Lösung, da die Client / Server-Konversation auf der Ebene der Datenbanksprache des Servers stattfindet. In einem solchen System kann ein ordnungsgemäß gestalteter Client geändert werden, um neue Geschäftsregeln und -bedingungen widerzuspiegeln, ohne den Server zu ändern, solange der Server Zugriff auf das Datenbankschema (Tabellen, Ansichten usw.) hat, das zum Ausführen der Transaktionen erforderlich ist. Der Server in einem solchen zweistufigen System wird wie unten gezeigt als Datenbankserver bezeichnet .

Datenbankserver haben jedoch einige Verbindlichkeiten. Häufig ist die SQL für eine bestimmte Geschäftsfunktion (z. B. Hinzufügen eines Artikels zu einer Bestellung) identisch, mit Ausnahme der Daten, die von Anruf zu Anruf aktualisiert oder eingefügt werden. Ein Datenbankserver analysiert und analysiert nahezu identisches SQL für jede Geschäftsfunktion. Beispielsweise sind wahrscheinlich alle SQL-Anweisungen zum Hinzufügen eines Artikels zu einer Bestellung sehr ähnlich, ebenso wie die SQL-Anweisungen zum Finden eines Kunden in der Datenbank. Die Zeit, die diese Analyse benötigt, sollte besser für die eigentliche Datenverarbeitung aufgewendet werden. (Es gibt Abhilfemaßnahmen für dieses Problem, einschließlich SQL-Analyse-Caches und gespeicherter Prozeduren.) Ein weiteres Problem besteht darin, die Clients und die Datenbank gleichzeitig zu versionieren: Alle Computer müssen für Upgrades heruntergefahren werden.Clients oder Server, die in ihrer Softwareversion in Verzug geraten, können normalerweise erst verwendet werden, wenn sie aktualisiert wurden.

Anwendungsserver

Eine Anwendungsserverarchitektur (siehe nächstes Bild) ist eine beliebte Alternative zu einer Datenbankserverarchitektur, da sie einige der Probleme löst, die Datenbankserver haben.

Eine Datenbankserverumgebung führt normalerweise Geschäftsmethoden auf dem Client aus und verwendet den Server hauptsächlich zur Persistenz und Durchsetzung der Datenintegrität. Auf einem Anwendungsserver werden Geschäftsmethoden auf dem Server ausgeführt, und der Client fordert den Server auf, diese Methoden auszuführen. In diesem Szenario verwenden Client und Server normalerweise ein Protokoll, das eine Konversation auf der Ebene von Geschäftstransaktionen anstelle von Tabellen und Zeilen darstellt. Solche Anwendungsserver bieten häufig eine bessere Leistung als ihre Datenbank-Gegenstücke, leiden jedoch immer noch unter Versionsproblemen.

Sowohl Datenbank- als auch Anwendungssysteme können durch Hinzufügen zusätzlicher Ebenen zur Architektur erweitert werden. Sogenannte dreischichtige Systeme platzieren eine Zwischenkomponente zwischen Client und Server. Eine ganze Branche - Middleware - ist aufgetaucht, um die Verbindlichkeiten von zweistufigen Systemen zu adressieren. Ein Transaktionsverarbeitungsmonitor,Ein Middleware-Typ empfängt Anforderungsströme von vielen Clients und kann die Last zwischen mehreren Servern aufteilen, ein Failover bereitstellen, wenn ein Server ausfällt, und Transaktionen im Namen eines Clients verwalten. Andere Arten von Middleware bieten die Übersetzung von Kommunikationsprotokollen, die Konsolidierung von Anforderungen und Antworten zwischen Clients und mehreren heterogenen Servern (dies ist besonders beliebt beim Umgang mit Legacy-Systemen beim Business Process Reengineering) und / oder die Bereitstellung von Service-Metering- und Netzwerkverkehrsinformationen.

Mehrere Ebenen bieten eine Flexibilität und Interoperabilität, die zu Systemen mit mehr als diesen drei Serviceebenen geführt hat. Beispielsweise sind n-Tier- Systeme Verallgemeinerungen von dreischichtigen Systemen, wobei jede Softwareschicht den darüber und darunter liegenden Schichten ein anderes Servicelevel bietet. In der n-Tier-Perspektive wird das Netzwerk als Pool verteilter Dienste betrachtet und nicht nur als Mittel für einen Client, um auf einen einzelnen Server zuzugreifen.

Da objektorientierte Sprachen und Techniken in Mode gekommen sind, haben sich Client / Server-Systeme zunehmend in Richtung Objektorientierung bewegt. CORBA (Common Object Request Broker Architecture) ist eine Architektur, mit der Objekte in Anwendungen - auch in verschiedenen Sprachen geschriebene Objekte - je nach den Anforderungen einer bestimmten Anwendung auf separaten Computern ausgeführt werden können. Vor Jahren geschriebene Anwendungen können als CORBA-Dienste gepackt werden und mit neuen Systemen zusammenarbeiten. Enterprise JavaBeans, das so konzipiert ist, dass es mit CORBA kompatibel ist, ist ein weiterer Eintrag in den objektorientierten Anwendungsserverring.

Der Zweck dieses Artikels besteht nicht darin, ein Lernprogramm für Client / Server-Systeme bereitzustellen. Es war jedoch erforderlich, Hintergrundinformationen bereitzustellen, um den Kontext zu definieren. Schauen wir uns nun an, was EJB zu bieten hat.

Enterprise JavaBeans und erweiterbare Anwendungsserver

Nachdem wir uns ein wenig Geschichte angesehen und verstanden haben, was Anwendungsserver sind, schauen wir uns Enterprise JavaBeans an und sehen, was es in diesem Kontext bietet.

Die Grundidee von Enterprise JavaBeans besteht darin, ein Framework für Komponenten bereitzustellen, die an einen Server "angeschlossen" werden können, wodurch die Funktionalität dieses Servers erweitert wird. Enterprise JavaBeans ähnelt den ursprünglichen JavaBeans nur insofern, als es einige ähnliche Konzepte verwendet. Die EJB-Technologie wird nicht von der JavaBeans-Komponentenspezifikation geregelt , sondern von der völlig anderen (und massiven) Enterprise JavaBeans-Spezifikation. (Einzelheiten zu dieser Spezifikation finden Sie unter Ressourcen.) Die EJB- Spezifikation ruft die verschiedenen Akteure im EJB-Client / Server-System auf, beschreibt, wie EJB mit dem Client und vorhandenen Systemen zusammenarbeitet, erläutert die Kompatibilität von EJB mit CORBA und definiert die Verantwortlichkeiten für die verschiedenen Komponenten im System.

JavaBeans-Unternehmensziele

Die EJB-Spezifikation versucht, mehrere Ziele gleichzeitig zu erreichen:

  • EJB wurde entwickelt, um Entwicklern das Erstellen von Anwendungen zu erleichtern und sie von Systemdetails auf niedriger Ebene zu befreien, die Transaktionen, Threads, Lastausgleich usw. betreffen. Anwendungsentwickler können sich auf die Geschäftslogik konzentrieren und die Details der Verwaltung der Datenverarbeitung dem Framework überlassen. Für spezielle Anwendungen ist es jedoch immer möglich, "unter die Haube" zu gehen und diese untergeordneten Dienste anzupassen.

  • Die EJB- Spezifikation definiert die Hauptstrukturen des EJB-Frameworks und definiert dann spezifisch die Verträge zwischen ihnen. Die Verantwortlichkeiten des Clients, des Servers und der einzelnen Komponenten sind klar definiert. (Wir werden gleich darauf eingehen, was diese Strukturen sind.) Ein Entwickler, der eine Enterprise JavaBean-Komponente erstellt, hat eine ganz andere Rolle als jemand, der einen EJB-kompatiblen Server erstellt, und die Spezifikation beschreibt die Verantwortlichkeiten der einzelnen Strukturen.

  • EJB soll die Standardmethode für Client / Server-Anwendungen sein, die in der Java-Sprache erstellt werden. So wie die ursprünglichen JavaBeans (oder Delphi-Komponenten oder was auch immer) von verschiedenen Anbietern kombiniert werden können, um einen benutzerdefinierten Client zu erstellen, können EJB-Serverkomponenten von verschiedenen Anbietern kombiniert werden, um einen benutzerdefinierten Server zu erstellen. EJB-Komponenten, die Java-Klassen sind, können natürlich ohne Neukompilierung auf jedem EJB-kompatiblen Server ausgeführt werden. Dies ist ein Vorteil, den plattformspezifische Lösungen nicht bieten können.

  • Schließlich ist der EJB mit anderen Java-APIs kompatibel und verwendet diese, kann mit Nicht-Java-Apps zusammenarbeiten und ist mit CORBA kompatibel.

Funktionsweise eines EJB-Client / Server-Systems

Um zu verstehen, wie ein EJB-Client / Server-System funktioniert, müssen wir die grundlegenden Teile eines EJB-Systems verstehen: die EJB-Komponente, den EJB-Container und das EJB-Objekt.

Die Enterprise JavaBeans-Komponente

Eine Enterprise JavaBean ist eine Komponente, genau wie eine herkömmliche JavaBean. Enterprise JavaBeans werden in einem EJB-Container ausgeführt, der wiederum in einem EJB-Server ausgeführt wird. Jeder Server, der einen EJB-Container hosten und ihm die erforderlichen Dienste bereitstellen kann, kann ein EJB-Server sein. (Dies bedeutet, dass viele vorhandene Server möglicherweise zu EJB-Servern erweitert werden. Tatsächlich haben viele Anbieter dies erreicht oder die Absicht angekündigt, dies zu tun.)

Eine EJB-Komponente ist der Typ der EJB-Klasse, der am wahrscheinlichsten als "Enterprise JavaBean" betrachtet wird. Es ist eine Java-Klasse, die von einem EJB-Entwickler geschrieben wurde und Geschäftslogik implementiert. Alle anderen Klassen im EJB-System unterstützen entweder den Clientzugriff auf EJB-Komponentenklassen oder stellen Dienste (wie Persistenz usw.) bereit.

Der Enterprise JavaBeans-Container

Im EJB-Container "lebt" die EJB-Komponente. Der EJB-Container bietet den enthaltenen EJB-Komponenten Dienste wie Transaktions- und Ressourcenverwaltung, Versionierung, Skalierbarkeit, Mobilität, Persistenz und Sicherheit. Da der EJB-Container alle diese Funktionen übernimmt, kann sich der EJB-Komponentenentwickler auf Geschäftsregeln konzentrieren und die Datenbankmanipulation und andere solche feinen Details dem Container überlassen. Wenn beispielsweise eine einzelne EJB-Komponente entscheidet, dass die aktuelle Transaktion abgebrochen werden soll, teilt sie dies ihrem Container einfach mit (in einer durch die EJB-Spezifikation definierten Weise , und der Container ist dafür verantwortlich, alle Rollbacks durchzuführen oder alles zu tun, was zum Abbrechen von a erforderlich ist Transaktion läuft. In einem einzelnen EJB-Container sind normalerweise mehrere EJB-Komponenteninstanzen vorhanden.

Das EJB-Objekt und die Remote-Schnittstelle

Client-Programme führen Methoden auf Remote-EJBs über ein EJB-Objekt aus. Das EJB-Objekt implementiert die "Remote-Schnittstelle" der EJB-Komponente auf dem Server. Die Remote-Schnittstelle repräsentiert die "Geschäfts" -Methoden der EJB-Komponente. Die Remote-Schnittstelle erledigt die eigentliche, nützliche Arbeit eines EJB-Objekts, z. B. das Erstellen eines Bestellformulars oder das Verschieben eines Patienten an einen Spezialisten. Wir werden die Remote-Schnittstelle weiter unten genauer besprechen.