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.

Deployment Deskriptoren dienen zur Beschreibung der Verteilungsspezifikavon Komponenten. Diese umfassen allgemeine Informationen wie denBeantyp, die zugehörigen Schnittstellen und Implementierungsklassen sowiedas Verhalten der Bean hinsichtlich Transaktionsverwaltung, Persistenzund Sicherheit.Die Beschreibung dieser Aspekte erfolgt deklarativ in Form von Attributen.Der Deployment Deskriptor in EJB besitzt einen allgemeinen Teil fürdie Beschreibung der Bean und einen als Assembly Descriptor bezeichnetenTeil zur Definition der Verteilungsspezifika.Zur Erstellung von Deployment Deskriptoren bieten Application Serverin der Regel entsprechende Werkzeuge an. Die Deskriptoren werden zumZeitpunkt des Deployments, also der Installation der Beans in einer konkretenLaufzeitumgebung, ausgewertet und durch Generierung von Codebzw. entsprechende Konfigurationsparameter umgesetzt. Damit erfolgt einestrikte Trennung der Anwendungslogik von der Definition der Verteilungsaspektefür die Beans.

Als Application Server wird eine Produktkategorie bezeichnet, die eine umfassendeLösung zur Umsetzung der Anwendungslogik in der Verarbeitungsschichtbietet. Application Server stellen eine Laufzeitumgebung, Kommunikationsmechanismenund weitere Basisdienste für die Umsetzung VerteilterSysteme bereit. Die Laufzeitumgebung unterstützt dabei typischerweise einKomponentenmodell (etwa EJB oder .NET) sowie eine Kommunikation überentfernte Methodenaufrufe.Die wesentlichen bereitgestellten Basisdienste sind nun ein Verzeichnisdienstzur Registrierung und Suche von Komponenten und weiteren Ressourcen, dieUnterstützung einer (automatisierten) Verwaltung persistenter Daten auf derBasis relationaler Datenbanken, die Steuerung von verteilten Transaktionenüber einen Transaktionsmonitor sowie Sicherheitsmechanismen für Authentifizierung,Autorisierung und Verschlüsselung.Neben diesen grundlegenden Diensten für die wichtigsten Verteilungsaspektewerden außerdem weitere Dienste wie die nachrichtenbasierte Kommunikationüber Message Oriented Middleware, die Integration weiterer bestehenderSoftwaresysteme, die Adaption von Daten, Aufrufen und Protokollen, zurLaufzeitverwaltung des Systems sowie zur Unterstützung von Ausfallsicherheitund Skalierbarkeit durch Replikation und Lastverteilung bereitgestellt.

Verteilte Anwendungen werden in der Regel auf mehreren autonomen Rechnernausgeführt. Diese besitzen unter anderem keinen gemeinsamen Speicherund keine synchronisierte Zeitbasis. Durch eine sich ständig ändernde Auslastungder Rechner und der Netzwerke sind deshalb die Auslieferungsreihenfolgesowie die Laufzeit von Nachrichten kaum vorhersagbar. Der BegriffIndeterminismus bezeichnet das daraus resultierende Problem, dass Verarbeitungsabläufe in Verteilten Systemen auch bei gleicher Eingabe nicht reproduzierbarsind. Aus der Verteilung und den damit verbundenen Nachrichtenlaufzeitenfolgt außerdem, dass eine globale Sicht auf den Zustand desgesamten Systems zu einem bestimmten Zeitpunkt nicht hergestellt werden kann. Darüber hinaus führt die Ressourcennutzung des Debuggers selbst zu Interferenzen mit dem zu debuggenden System.Zur Beherrschung des Indeterminismus und dem Fehlen einer globalen Sichtauf den Systemzustand kann das Lamport-Verfahren eingesetzt werden. Diesesermöglicht die Herstellung einer globalen logischen Ordnung von kausalzusammenhängenden Ereignissen, mit deren Hilfe verteilte Programmläufereproduziert werden können. Dem Problem der Interferenz kann durch eineMinimierung der Eingriffe in das laufende System durch den Debugger begegnetwerden. Je mehr Informationen über das System gesammelt werden sollen,desto mehr wird in der Regel in den Programmablauf eingegriffen. Durchdas Sammeln von Logging-Informationen im realen Systembetrieb und eineanschließende Auswertung dieser führt beispielsweise zu nur geringen Eingriffenin das zu testende System.

Abbildung A8