Vert. Systeme | Kap 7

Nach der Definition von Szyperski werden Komponenten als Ganzes spezifiziert,implementiert und verwendet. Zur Kommunikation mit anderen Komponentenwerden Schnittstellen spezifiziert, die Implementierung dieser wird jedoch von der Komponente gekapselt und bleibt damit nach außen verborgen.Dies ist wesentlich für die Forderung, dass Komponenten nur explizitdefinierte Abhängigkeiten zu anderen Komponenten bzw. dem Laufzeitsystembesitzen dürfen. Durch Schnittstellenspezifikationen werden dieAbhängigkeiten explizit definiert. Für Verteilte Systeme gehören zu den Abhängigkeiten auch die Beziehungen zu den Basisdiensten der Laufzeitumgebung,also insbesondere Transaktionssteuerung, Sicherheit und Persistenz.Diese sollten ebenfalls explizit definiert und nicht implizit im Implementierungscode der Komponente umgesetzt werden. Andernfalls ist die Komponente nur eingeschränkt wiederverwendbar.

Nach [CD00] können die vier Sichten Komponentenspezifikation, Komponentenimplementierung,installierte Komponente und Komponentenobjekt unterschieden werden. Die Komponentenspezifikation bietet zunachst eine implementierungsunabhängige Sicht auf die Komponente. Für diese werden die angebotenen und benötigten Schnittstellen jedoch keine Interna der Komponente definiert. Damit können vor allem Kompositionen von Komponenten und die Beziehungen der einzelnen Komponenten untereinander auf Architekturebene betrachtet werden. Die Spezifikation kann etwa in Form von Kompontenten- oder Klassendiagrammen in UML mit einem entsprechenden UML-Werkzeug wie Rational Rose oder Omondo UML in Eclipse erfolgen.Dabei werden die Schnittstellen der Komponente mit den einzelnen Operationen und deren Parametern derfiniert.Die Sicht der Komponentenimplementierung definiert dann die Interna der Komponente gemäß der Komponentenspezifikation. Die Hülle der Komponentenspezifikation wird mit Inhalt, also Code für die Anwendungslogik in Bezug auf ein konkretes Komponentenmodell, gefüllt. Dabei können für eine Komponentenspezifikation mehrere Komponentenimplementierungen erstellt werden. Es wird also Code für die Anwendungslogik der Komponente, bezogen auf eine Komponentenplattform wie EJB erzeugt. Als Werkzeug kann ein einfacher Texteditor aber auch eine Entwicklungsumgebung wie Eclipse oder NetBeans eingesetzt werden. Installierte Komponenten beschreiben die Sicht auf das Deployment einer Komponentenimplementierung in eine konkrete Komponentenplattform. Dabei erfolgt eine Anmeldung und Bereitstellung der Komponentenimplementierung innerhalb der Plattform sowie die Bindung an konkrete Plattformdienste wie Persistenz, Transaktionssteuerung und Sicherheit. Im Ergebnis ist die Komponentenimplementierung innerhalb der Plattform verfügbar und ihr Verhalten in Bezug auf die Basisdienste der Plattform wurde konfiguriert. Ein Werkzeug für das Deployment wird in der Regel von der Komponentenplattform bereitgestellt. Komponentenobjekt beschreiben letztlich Instanzen von Komponenten zur Laufzeit, die innerhalb der gewählten Realisierungsplattform verwaltet und ausgeführt werden. Diese besitzen nun eine Identität und enthalten die implementierte Anwendungslogik. Zur Überwachung und Verwaltung der Komponentenobjekte bieten Application Server in der Regel proprietäre Werkzeuge an.

Das Komponentenmodell von Enterprise JavaBeans unterscheidet Komponenten der drei Typen Session Bean, Entity Bean und Message-Driven Bean. Session Beans enthalten die Anwendungslogik für die Interaktion mit Nutzern in einer Sitzung. Eine Instanz einer Session Bean ist deshalb jeweils einem Nutzer zugeordnet. Session Beans können zustandsbehaftet sein. In diesem Fall kann ein Zustand über mehrere Aufrufe innerhalb einer Sitzung verwaltet werden, etwa zur Implementierung eines Warenkorbes.Bei zustandlosen Session Beans wird entsprechend kein Zustand verwaltet. Message-Driven Beans enthalten ebenfalls Anwendungslogik. Im Gegensatz zu Session Beans werden diese aber asynchron durch Messaging angesprochen und nicht nach dem synchronen Request/Response Interaktionsschema per RMI. Außerdem besteht keine Zuordnung zu Nutzern in einer Sitzung. Message-Driven Beans können etwa zur Verarbeitung von Bestellungen eingesetzt werden. Entity Beans repräsentieren Anwendungsdaten bzw. Geschäftsobjekte. Dies können etwa Kunden- oder Produktdaten sein. Entity Beans kapseln insbesondere die Logik zur persistenten Speicherung dieser Anwendungsdaten.

EJB-Komponenten stellen ihre Funktionalität über Schnittstellen bereit. Diese sind im Standardfall entfernt per Remote Method Invocation (RMI) aufrufbar. Damit wird jeder Aufruf uber entsprechende Stubs und Skeletons abgewickelt. Diese bereiten die Aufrufdaten für die Übermittlung über ein Netzwerk auf und versenden diese entsprechend, wie dies in Kapitel 3 beschrieben wurde. Damit entsteht verglichen mit einem lokalen Methodenaufruf ein entsprechender Mehraufwand. Werden Methoden einer Bean nur von lokalen Komponenten aufgerufen, ist dieser Mehraufwand nicht notwendig. Deshalb wurde zur Leistungsoptimierung die Möglichkeit vorgesehen, Schnittstellen als lokal zu kennzeichnen. Methodenaufrufe werden damit als lokale Java-Methodenaufrufe umgesetzt, können damit natürlich nicht mehr entfernt aufgerufen werden.