Komponentenmodelle für Web Anwendungen

Inhaltsverzeichnis

1 Einleitung
1.1 Zielsetzung
1.2 Gliederung

2 Beschreibung von Komponentenmodellen
2.1 Grundlagen der komponentenbasierten Softwareentwicklung
2.1.1 Begriffe und Definitionen
2.1.2 Grundidee der komponentenbasierten Softwareentwicklung
2.2 Die de-facto-Standards der komponentenbasierten Softwareentwicklung
2.2.1 Die Common Object Request Broker Architecture
2.2.2 Die Enterprise JavaBeans der Java 2 Enterprise Edition
2.2.3 Die Assemblies des .NET Frameworks
2.2.4 Web-Services
2.2.5 Vergleich der Komponentenmodelle

3 Beschreibung von Web-Anwendungen
3.1 Grundlagen
3.1.1 Begriffe und Definitionen
3.1.2 Anforderungen an Web-Anwendungen als Kriterienkatalog . .
3.2 Architekturen
3.2.1 Mehrschichtige-Architekturen
3.2.2 Middleware
3.2.3 Model-View-Controller-Muster

4 Architekturen und Lösungsstrategien für Web-Anwendungen
4.1 Common Object Request Broker Architecture (CORBA)
4.1.1 Architektur
4.1.2 Lösungsstrategien zu den Anforderungen an Web-Anwendungen
4.2 Java 2 Enterprise Edition (J2EE)
4.2.1 Architektur
4.2.2 J2EE-Anwendungen nach dem Model-View-Controller-Muster
4.2.3 Lösungsstrategien zu den Anforderungen an Web-Anwendungen
4.3 .NET Framework
4.3.1 Architektur
4.3.2 Lösungsstrategien zu den Anforderungen an Web-Anwendungen
4.4 Web-Services
4.4.1 Architektur
4.4.2 Lösungsstrategien zu den Anforderungen an Web-Anwendungen

5 Terminkalender als komponentenbasierte Web-Anwendung
5.1 Anforderungen an das Produkt
5.1.1 Begriffe für KALENDARO
5.1.2 Die Akteure von KALENDARO
5.1.3 Funktionale Anforderungen
5.1.4 Nichtfunktionale Anforderungen
5.2 Auswahl des Komponentenmodells
5.2.1 Common Object Request Broker Architecture
5.2.2 .NET Framework
5.2.3 Java 2 Enterprise Edition
5.2.4 Web-Services
5.2.5 Ausgewähltes Komponentenmodell
5.3 Architekturentwurf
5.3.1 Architektur der Web-Anwendung
5.3.2 Architektur der Synchronisationsanwendung
5.4 Entwicklung der Web-Anwendung
5.4.1 Verwendete Entwicklungswerkzeuge und Plattformen
5.4.2 Der Persistenzmechanismus von KALENDARO
5.4.3 Entwicklung der Synchronisationsanwendung
5.5 Bewertung der Web-Anwendung und Schlussfolgerungen . .
5.5.1 Bewertung der Anforderungen aus dem Kriterienkatalog
5.5.2 Schlussfolgerungen

6 Ausblick

7 Zusammenfassung

Anhänge
Anhang A: Anwendungsfälle
Anhang A.1: Paket Terminkalender
Anhang A.2: Paket Terminteilnahme
Anhang A.3: Paket Suche
Anhang A.4: Paket Verwaltung
Anhang A.5: Paket Administration
Anhang A.6: Paket Conduit
Anhang B: Datenbankschema
Anhang C: Document Type Definition der Synchronisationsdateien . .
Anhang D: WSDL Beschreibung der Web-Services zur Kalendersynchroni- sation

Glossar

Abkürzungsverzeichnis

Literatur

Bilderverzeichnis

1 Object Management Architecture (OMA)

2 Clientsicht auf Komponenten in CORBA

3 Entwicklersicht auf Komponenten in CORBA

4 CORBA Container-Programming-Modell

5 Typen von Enterprise JavaBeans

6 Clientsicht auf Komponenten in EJB für Session Beans und Entity Beans

7 Beziehungen zwischen den Klassen eines EJB Containers

8 Die .NET Framework Architektur

9 Bestandteile von .NET Assemblies

10 Web-Service als virtuelle Komponente

11 Beziehung zwischen UDDI, SOAP und WSDL

12 2-Schichten-Architektur

13 Mehrschichtige Architektur

14 Verteilungsplattform als Infrastruktur für verteilte Systeme

15 Kommunikation und Datenaustausch zwischen den einzelnen Teilen des Model-View-Controller-Musters

16 Mehrschichtige Architektur einer Web-Anwendung mit CORBA . .

17 Beispiel für den Einsatz einer half bridge

18 Mehrschichtige Architektur einer .J2EE Web-Anwendung

19 Beispiel eines Model-View-Controller-Muster in J2EE

20 Mehrschichtige Architektur einer .NET Web-Anwendung

21 Service-orientierte Architektur (SOA)

22 Aufteilung der Anwendungsfalldiagramme in Pakete

23 Anwendungsfalldiagramm des Paketes Terminkalender

24 Anwendungsfalldiagramm des Paketes Terminteilnahme

25 Anwendungsfalldiagramm des Paketes Suche

26 Anwendungsfalldiagramm des Paketes Verwaltung - Teilnehmer . .

27 Anwendungsfalldiagramm des Paketes Verwaltung - Terminkalender

28 Anwendungsfalldiagramm des Paketes Verwaltung - Veranstalter . .

29 Anwendungsfalldiagramm des Paketes Administration

30 Anwendungsfalldiagramm des Paketes Conduit

31 Architektur der Web-Anwendung

32 Architektur der Synchronisationsanwendung

33 Klassen des Sequence Blocks Entwurfsmusters

34 Sequenzdiagramm der Synchronisation

35 Filter-Servlet zur Prüfung der Autorisation in KALENDARO

36 Erwartete Entwicklungsstufen des Web

37 Relationales Datenbankschema von KALENDARO

Tabellenverzeichnis

1 CORBA Komponentenkategorien

2 Vergleich der Komponentenmodelle

3 Synchronisation der KALENDARO Kalendereinträge mit der empfan- genen Synchronisationsdatei

4 Synchronisation des Palm Datebooks mit der Synchronisationsdatei, Kalendereinträge hinzufügen oder löschen

5 Synchronisation des Palm Datebooks mit der Synchronisationsdatei, Kalendereinträge ändern

6 Anwendungsfälle des Paketes Terminkalender

7 Anwendungsfälle des Paketes Terminteilnahme

8 Anwendungsfälle des Paketes Suche

9 Anwendungsfälle des Paketes Verwaltung - Teilnehmer

10 Anwendungsfälle des Paketes Verwaltung - Terminkalender

11 Anwendungsfälle des Paketes Verwaltung - Veranstalter

12 Anwendungsfälle des Paketes Administration

13 Anwendungsfälle des Paketes Conduit Zielsetzung

1 Einleitung

Das World-Wide-Web (kurz Web) konnte sich innerhalb kürzester Zeit als Plattform für verteilte Anwendungen etablieren. Immer häufiger wird dieses Medium von Betrieben und Organisationen benutzt, um Produkte und Dienstleistungen mit Hilfe von Web-Anwendungen anzubieten. Web-Anwendungen sind nicht nur durch eine Anbindung an betriebliche Anwendungen geprägt, sondern erfordern auch eine entsprechende Umsetzung von betrieblichen Abläufen im Web [Gaedke 99]

Web-Anwendungen sind Softwaresysteme die Inhalte und Dienste über eine Benutzerschnittstelle zur Verfügung stellen. Sie beruhen auf Spezifikationen des World Wide Web Consortiums [Kappel 04]. Das einfache, dokumentenbasierte Modell, das dem Web zugrunde liegt, behindert jedoch den Entwurf, die Wartbarkeit und Evolution von Web-Anwendungen. Die Softwaretechnik hat viele Verfahren, Modelle und Methoden zur Lösung dieser Probleme hervorgebracht, sie werden für Web-Anwendungen aber nur selten verwendet [Gaedke 99] Allgemein anerkannt in der Softwaretechnik ist die komponentenbasierte Softwareentwicklung. Sie soll Zeit- und Kostenersparnisse und eine Qualitätssteigerung von Software bringen indem sie die Wiederverwendung durch Komposition von SoftwareBausteinen ermöglicht.

In der komponentenbasierten Softwareentwicklung haben sich verschiedene Komponentenmodelle und Spezifikationen als de-facto-Standards durchgesetzt. Zu diesen Standards zählen:

- Die Common Object Request Broker Architecture (kurz CORBA),
- die Enterprise JavaBeans (kurz EJB) der Java 2 Enterprise Edition (kurz J2EE),
- die Assemblies des .NET Frameworks und
- die Web-Services.

Um eine industrielle Konstruktion und Produktion von Web-Anwendungen mittels dieser de-facto-Standards zu erreichen, ist es Voraussetzung, dass das Zusammenspiel der Software-Komponenten durch ein Framework definiert wird. Das Framework kann als Halbfertigfabrikat ein vordefiniertes Architekturrahmengerüst anbieten und spielt eine wichtige Rolle für die Entwicklung von Web-Anwendungen [Pree 99].

1.1 Zielsetzung

In dieser Arbeit werden Frameworks und Spezifikationen im Zusammenhang mit Komponentenmodellen untersucht, welche zur Entwicklung von Web-Anwendungen dienen. Dazu wird ein Überblick über die de-facto-Standards der komponentenbasierten Softwareentwicklung gegeben.

Die Theorie der komponentenbasierten Softwareentwicklung bestimmt verschiedene Erwartungen und Anforderungen an Softwarekomponenten. Durch einen Vergleich der Komponentenmodelle werden die jeweiligen Vor- und Nachteile untersucht und gegenübergestellt. Somit soll festgestellt werden, ob die vorgestellten Komponentenmodelle den Erwartungen und Anforderungen entsprechen.

Betriebe und Organisationen haben gewisse Anforderungen an Web-Anwendungen und deren Architekturen. Ziel ist es, die wichtigsten dieser Anforderungen festzustellen und in einem Kriterienkatalog zusammenzufassen. Mittels dieses Kriterienkatalogs werden die de-facto-Standards der komponentenbasierten Softwareentwicklung in einer Literaturstudie verglichen.

Praktisches Ziel der Diplomarbeit ist die Entwicklung eines Softwareprototypen in Form eines Terminkalenders. Für diese Aufgabe soll ein geeignetes Komponentenmodell evaluiert werden. Anhand dieses praktischen Beispiels wird geprüft, ob die für dieses Komponentenmodell zur Verfügung stehenden Frameworks und Spezifikationen, den Anforderungen aus dem Kriterienkatalog gerecht werden.

1.2 Gliederung

Die vorliegende Diplomarbeit gliedert sich in vier Hauptteile:

Das Kapitel 2 der Diplomarbeit beschäftigt sich mit der komponentenbasier- ten Softwareentwicklung. Dabei werden die Komponentenmodelle von CORBA, der EJB Spezifikation, des .NET Frameworks und die Web-Services vorgestellt. Durch einen Vergleich der Komponentenmodelle werden deren Vor- und Nach- teile bestimmt.

Das Kapitel 3 dient der Beschreibung von gängigen Softwarearchitekturen für Web-Anwendungen. Anschließend werden die wichtigsten Anforderungen an Web-Anwendungen evaluiert und in einem Kriterienkatalog zusammengefasst.

Im Kapitel 4 werden die Frameworks und Spezifikationen von CORBA, der J2EE Spezifikation, dem .NET Framework und der Web-Services überprüft, ob sie den evaluierten Anforderungen aus dem Kriterienkatalog gerecht werden.

Das Kapitel 5 zeigt schließlich die Entwicklung des Prototypen des Terminkalen- ders und einer Synchronisationsanwendung zum Datenabgleich des Terminkalen- ders mit einem handelsüblichen Handheld-Computer. Dazu werden Komponen- tenmodelle, Frameworks und Spezifikationen aus den vorangegangenen Kapiteln ausgewählt und untersucht, ob sie den evaluierten Anforderungen des Kriterien- katalogs entsprechen.

Kapitel 6 enthält einen Ausblick auf zukünftige Entwicklungen der komponentenbasierten Softwareentwicklung für Web-Anwendungen.

2 Beschreibung von Komponentenmodellen

In diesem Kapitel werden im Abschnitt 2.1 die Grundlagen der komponentenbasierten Softwareentwicklung beschrieben, auf denen diese Arbeit aufbaut. Danach wird im Abschnitt 2.2 eine Einführung in die wichtigsten Komponentenmodelle und Spezifikationen gegeben und deren Vor- und Nachteile bestimmt.

2.1 Grundlagen der komponentenbasierten Softwareentwicklung

Im Unterabschnitt 2.1.1 werden die wichtigsten Begriffe der komponentenbasierten Softwareentwicklung definiert. Danach wird im Unterabschnitt 2.1.2 die Grundidee der komponentenbasierten Softwareentwicklung erklärt, um die Verwendung von vor- gefertigten Software-Komponenten für Web-Anwendungen verstehen zu können.

2.1.1 Begriffe und Definitionen

Wiederverwendung von Software

Softwareprodukte werden immer komplexer, ihre Entwicklungszeiten immer kürzer. Um diese und viele andere Probleme der Softwaretechnik in den Griff zu bekommen, ist es notwendig, bereits vorhandene Software anpassen und wieder verwenden zu kön- nen. Es stellt sich daher zuerst die Frage was unter Wiederverwendung von Software verstanden wird.

Unter [Biggerstaff 89] findet sich folgende Definition für diesen Begriff:

„Wiederverwendung von Software ist das erneute Anwenden von bei der Entwicklung eines Softwaresystems entstandenen Artefakten und angesam- meltem Wissen bei der Entwicklung eines neuen Softwaresystems, um den Aufwand zur Erstellung und Pflege dieses neuen Systems zu reduzieren.“

Eine weitere Definition für die Software-Wiederverwendung wird in [Ezran 89] ver- wendet:

„Software reuse is the systematic practice of developing software from a stock of building blocks, so that similarities in requirements and/or architecture between applications can be exploited to achieve substantial benefits in productivity, quality and business performance.“

Aus diesen Definitionen kann der Schluss gezogen werden, dass Software-Wieder- verwendung immer hinsichtlich des Prozesses der Softwareentwicklung zu sehen ist. Sie stellt eine systematische Verwendung von bereits gegebenen Software-Komponen- ten (Software-Bausteinen) dar, das einen wohldefinierten Prozess der komponentenbasierten Softwareentwicklung erfordert [Schmietendorf 02].

Software-Komponente

Dies führt unmittelbar zu einer Definition des Begriffes Software-Komponente. Der Begriff Software-Komponente und Komponente wird im weiteren Verlauf der Diplom- arbeit analog behandelt. In [Balzert 96] findet sich folgende allgemeine Definition:

„Ein Halbfabrikat bzw. eine Komponente (componentware) ist also ein abgeschlossener, binärer Software-Baustein, der eine anwendungsorientierte, semantisch zusammengehörende Funktionalität besitzt, die nach außen über Schnittstellen zur Verfügung gestellt wird. Beim Entwurf des Halbfabrikats wurde auf hohe Wiederverwendbarkeit großer Wert gelegt.“

Eine der bekanntesten und allgemein anerkannten Definitionen ist die von [Szyperski 02]:

„A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.“

Der Begriff Komponente ist in der Literatur nicht eindeutig definiert. Es existieren viele unterschiedliche Ansichten. Allgemein trifft es die Aussage, dass eine Kompo- nente eine eigenständige Software ist, mit wohldefinierten Interaktionspunkten und - modi. Sie kann mit anderen Komponenten zu größeren Software-Gebilden verbunden werden und somit als Software-Baustein angesehen werden [Atkinson 03].

Komponentenmodell

Eine weitere Definition, die sich bereits aus dem Titel dieser Arbeit ergibt, ist die der Komponentenmodelle. In [Szyperski 02] wird beschrieben, dass ein Komponentenmodell festlegt, welche Anforderungen eine Komponente erfüllen muss, und zwar sowohl in syntaktischer, als auch in semantischer Hinsicht.

Eine ausführliche Definition findet sich in [Thomas 98]:

„A component model defines the basic architecture of a component, specify- ing the structure of its interfaces and the mechanisms by which it interacts with its container and with other components. The component model provi- des guidelines to create and implement components that can work together to form a larger application. Application builders can combine components from different developers or different vendors to construct an application.“

Das Komponentenmodell ist demnach der „Bauplan“ der komponentenbasierten Softwareentwicklung, welcher dem Entwickler und Benutzer von Software-Kompo- nenten Standards und Vorgehensweisen zur Softwareentwicklung vorgibt.

Framework

In der Einleitung wurde der Begriff des Frameworks verwendet. In den meisten komponentenbasierten Softwareprojekten kommen nicht einzelne Software-Komponenten zum Einsatz, es werden vielmehr Sammlungen von Komponenten in so genannten Rahmenwerken (engl. frameworks) verwendet. Software die aufgrund eines Frameworks entwickelt wurde, verwendet nicht nur bereits existierenden Quellcode, sondern ermöglicht auch die Wiederverwendung von Softwarearchitekturen [Pree 97]. Frameworks werden von [Pree 97] folgendermaßen definiert:

„A framework is simply a collection of several single components with pre- defined cooperations between them, for the purpose of accomplishing a cer- tain task.“

Ein Framework stellt somit eine Sammlung von Komponenten dar, wobei die ver- wendete Programmiersprache nebensächlich ist. Die Komponenten interagieren nach einem vordefinierten Schema und bieten eine Schnittstelle zur Erweiterung nach au- ßen (so genannte hot spots oder variation points) [Pree 02]. Frameworks ergänzen die Komponentenstandards und erleichtern die industrielle Konstruktion und Produktion von Software [Pree 99].

Die bereits angesprochene „Wiederverwendung von Software durch Komponenten“ gilt allgemein als ein Schlüssel für die Etablierung einer ingenieurmäßigen Vorgehens- weise bei der Entwicklung von Software [Schmietendorf 02]. Im Folgenden Unter- abschnitt wird daher die Grundidee der komponentenbasierten Softwareentwicklung erläutert.

2.1.2 Grundidee der komponentenbasierten Softwareentwicklung

Seit langem beschäftigt sich die Softwareindustrie mit den Problemen der Wiederverwendung von Software. Diese Probleme gründen darin, dass mit zunehmender Leistungsfähigkeit der Computer die Computerprogramme immer komplexer werden. Gleichzeitig werden die Zeiträume für die Entwicklung von Software immer kürzer und die Entwicklungsteams immer größer. Mit den traditionellen funktionalen und prozeduralen Programmiermethoden kann dies zu schwer wartbaren Programmen führen. Daher kann sich ein Großteil des Gesamtaufwandes der Softwareentwicklung auf die Wartung und Korrektur von Programmen verlagern.

Objektorientierte Softwareentwicklung

Als eine der Antworten auf die Probleme der Softwarewiederverwendung galt die ob- jektorientierte Softwareentwicklung. Damit sollte erreicht werden, dass eine komplexe Anwendung in kleine Einheiten (in so genannte Objekte), zerlegt werden kann. Diese Einheiten sollten möglichst unabhängig voneinander entwickelt und getestet werden können. Ein wichtiger Aspekt der objektorientierten Softwareentwicklung ist die Möglichkeit, neue Klassen¹ zu definieren, indem diese von vorhandenen Klassen erben. Dadurch kann der vorhandene und schon getestete Funktionsumfang wieder verwendet und gleichzeitig angepasst und spezialisiert werden.

Besonders die frühen Vertreter der objektorientierten Softwareentwicklung vertraten den Standpunkt, dass Objekte die am besten geeignete Abstraktion für die Wiederverwendung von Software darstellen [Sommerville 01]. Die objektorientierte Softwareentwicklung konnte die Probleme allerdings nicht vollständig lösen und weist unter anderem folgende Grenzen und Schwächen auf:

Klassen und Objekte verschiedener Programmiersprachen können oft nicht zusammen in einem Softwareprodukt verwendet werden.

Eine einzelne Klasse für sich ist häufig nicht nützlich.

Wiederverwendung durch Vererbung kann starke Abhängigkeiten schaffen, sodass kein Austausch der ursprünglichen Klasse (zum Beispiel durch eine neuere Version) möglich ist.

Vielfältige Beziehungen zwischen einzelnen Klassen können ein komplexes Geflecht an Abhängigkeiten erzeugen.

Die Verteilung von Klassen und Objekten über ein Netzwerk ist oft nicht möglich.

Komponentenbasierte Softwareentwicklung

Abhilfe soll hier die Idee der komponentenbasierten Softwareentwicklung bringen. Dieses Konzept ist nicht neu und wurde bereits 1968 auf einer NATO-Konferenz in Garmisch-Patenkirchen von Mc Ilroy formuliert [McIlroy 68]. Als Beispiele sol- cher frühzeitigen Komponentenansätze seien das Funktionsprinzip der Programmier- sprache C oder auch das UNIT-Konzept der Programmiersprache PASCAL genannt [Schmietendorf 02].

Das Ziel der komponentenbasierten Softwareentwicklung ist die Zusammensetzung von Software durch Wiederverwendung von Komponenten. Dies soll Zeit- und Kosten- ersparnisse bei der Entwicklung und eine zusätzliche Qualitätssteigerung der Software bringen. Der Anwendungsentwickler hat dabei normalerweise keinerlei Zugriff auf den Quellcode einer Software-Komponente, da Software-Komponenten häufig nur in binärer Form zur Verfügung stehen. Er kann ihr Verhalten aber über die Konfiguration ihrer Eigenschaften anpassen.

Im Folgenden seien noch die Erwartungen an Software-Komponenten und die Anforderungen an deren Architektur aufgelistet:

Erwartungen an Software-Komponenten. In [Schmietendorf 02] werden folgende Erwartungen an Software-Komponenten gestellt:

Höhere Qualität und Verfügbarkeit von Softwareprodukten: Durch umfangreichen Einsatz und Test der Software-Komponenten wird angenommen, dass diese weniger Fehler aufweisen.

Arbeitsteilige Softwareentwicklung: Durch den Einsatz von wohldefinierten Software-Komponenten besteht die Möglichkeit, die Softwareentwicklung auf mehrere Personen oder örtlich aufzuteilen.

Verteilung wirtschaftlicher Risiken: Durch die Verteilung von fachlichen Anforderungen in der Softwareentwicklung entstehen hohe Risiken, die durch komponentenbasierte Softwareentwicklung gemindert werden können.

Spezialisierung: Es können Techniken zum Einsatz kommen, die durch das spezielle Wissen des Entwicklers entstanden sind, dem Benutzer der Software-Kom- ponenten wird kein entsprechendes Wissen abverlangt.

Verbesserte Erweiterbarkeit: Durch klar voneinander abgegrenzte Software-Kom- ponenten wird die Wartung, Pflege und Erweiterung vorhandener Software-Kom- ponenten vereinfacht. Eine fehlerhafte Software-Komponente kann durch eine Neuentwicklung einfach ausgetauscht werden.

Verkürzung der Entwicklungszeiten: Die Wiederverwendung von bereits gefer- tigten Software-Komponenten verkürzt die Entwicklungszeit von Softwarepro- dukten.

Anforderungen an die Architektur von Software-Komponenten. Aus obigen Erwartun- gen ergeben sich folgende Anforderungen an die Architektur von Software-Kompo- nenten welche unter [Griffel 98] folgendermaßen zusammengefasst und beschrieben sind:

Unabhängigkeit von der technischen Umgebung: Das Zusammenarbeiten von Komponenten sollte möglichst unabhängig von Programmiersprachen, Betriebssystemen, Netztechniken und Entwicklungsumgebungen sein.

Ortsunabhängigkeit: Eine Komponente sollte nutzbar sein, unabhängig davon, ob sie sich auf einem lokalen Rechner, in einer anderen Prozessumgebung oder im Netzwerk auf einem entfernten Rechner befindet. Die dazu notwendigen Mechanismen sollten für den Benutzer nicht sichtbar sein.

Trennung von Schnittstelle und Komponentenquellcode: Die Spezifikation einer Komponente sollte vollständig unabhängig von deren Entwicklung erfolgen kön- nen.

Selbstbeschreibende Schnittstellen: Zur Laufzeitkopplung und besseren Wiederverwendbarkeit von Komponenten sollte sie Auskunft über ihre eigenen Möglichkeiten und Zugriffspunkte geben können.

Sofortige Nutzbarkeit: Eine Komponente sollte auf jeder Plattform installier- und nutzbar sein. Dies impliziert insbesondere eine binäre Unabhängigkeit des Kom- ponentencodes.

Integrations- und Kompositionsfähigkeit: Eine Komponente sollte zusammen mit anderen Komponenten zu einer neuen funktionsfähigen Komponente integriert werden können.

2.2 Die de-facto-Standards der komponentenbasierten Softwareentwicklung

Im Alltag der Entwicklung von Web-Anwendungen existieren vier Modelle, die die Erstellung von Komponenten zu standardisieren versuchen:

- Das Komponentenmodell der Object Management Group (OMG): CORBA Component Model (CCM) [CORBA 02],
- die Komponentenmodelle von Sun mit der Enterprise JavaBeans (EJB) Spezifikation [EJB 02],
- die Komponentenmodelle des .NET Frameworks von Microsoft [Microsoft(2) 04] und
- die Web-Services.

Die fundamentalen Eigenschaften in Form des Objektmodells, der Object Management Group, von Sun und von Microsoft, sind vergleichbar. Ein etwas anderer Weg wird mit Web-Services beschritten. Gemeinsam ist ihnen, dass sie das Konzept der Trennung von Schnittstelle und Komponentenquellcode benutzen.

Diese Komponentenmodelle, die de-facto-Standards darstellen, werden in den fol- genden Unterabschnitten 2.2.1, 2.2.2, 2.2.3 und 2.2.4 genauer beschrieben. Ein ab- schließender Vergleich der Komponentenmodelle in Unterabschnitt 2.2.5, wird deren Vor- und Nachteile bestimmen.

2.2.1 Die Common Object Request Broker Architecture

„CORBA - the Common Object Request Broker Architecture is OMG’s showcase specification for application interoperability independent of plat- form, operating system, programming language - even of network and pro- tocol.“

Object Management Group

Dieser Unterabschnitt gibt eine Einführung in das Komponentenmodell von CORBA. Zuerst wird auf die Object Management Architecture eingegangen. Da- nach wird das Komponentenmodell von CORBA genauer beschrieben, welches in der CORBA-Components Spezifikation dargestellt wird (siehe [CORBA 02]). Wegen des enormen Umfangs der Spezifikation kann hier natürlich nur ein Überblick gegeben werden. CORBA wird getrennt aus Clientsicht und aus Entwicklersicht betrachtet. es werden die so genannten Container, die Schnittstellen-Beschreibungen und die XML- Beschreibungen der Archive erläutert.

Object Management Group (OMG)

Die Common Object Request Broker Architecture (CORBA) ist eine Spezifikation der Object Management Group (OMG). Die Object Management Group ist eine interna- tionale Organisation, die 1989 gegründet wurde, und mittlerweile über 600 Mitglieder zählt. Die primären Ziele der Organisation sind die Förderung der Wiederverwend- barkeit, der Portierbarkeit und der Interoperabilität von objektorientierter Software in verteilten, heterogenen Umgebungen [CORBA 02]. Die aktuelle Version des CORBA Standards ist die Version 3.0, welche in dieser Beschreibung Verwendung findet.

Object Management Architecture

Die Grundlage für die CORBA-Spezifikation bildet die Object Management Archi- tecture (OMA). Die Object Management Group hat erkannt, dass viele verschiedene Anwendungen die gleichen Dienste benötigen. Mit der Object Management Architec- ture wird versucht, diese Dienste zu extrahieren und als eine Menge standardisierter Objekte zur Verfügung zu stellen [CORBA 02(2)]. Die Architektur besteht aus 5 Tei- len, deren Beziehungen zueinander in Bild 1 dargestellt sind und im Folgenden kurz beschrieben werden:

Die Common Object Request Broker Architecture 11

Abbildung in dieser Leseprobe nicht enthalten

Bild 1: Object Management Architecture (OMA)

Der Object Request Broker: Der Object Request Broker (ORB) ist der Mittelpunkt der Object Management Architecture. Er ermöglicht die Kommunikation in heterogenen, verteilten Umgebungen.

Die Common Object Services: Die Common Object Services (COS) bieten Dienste, die über den reinen Transport der Methodenaufrufe hinausgehen und die generell genug sind, um von vielen Anwendungen verwendet werden zu können. Zu diesen Diensten gehören beispielsweise der Naming Service, der Trading Service und der Event Service.

Die Common Facilities: Die Common Facilities bieten Dienste, die auf die Common Object Services aufgebaut sind. Die Dienste der Common Facilities sind spezieller als die Common Object Services und erledigen komplexere Aufgaben. Diese sind in folgende Bereiche gegliedert:

- Informationsmanagement
- Benutzerschnittstellen
- Systemmanagement
- Taskmanagement

Die Domain Objects: Die Domain Objects stellen die nächst höhere Abstraktionsstufe dar. Diese stellen Dienste für Benutzer in einem speziellen Anwendungsbereich zur Verfügung.

Die Application Objects: Die Application Objects sind nun die eigentlichen verteilten Anwendungen und unterliegen daher nicht der Standardisierung durch die Object Management Group.

Das CORBA Komponentenmodell

Das CORBA Komponentenmodell (CCM) ist ein serverseitiges Komponentenmodell, das in erster Linie für Business-Komponenten² gedacht ist. In einer aus CORBA-Kom- ponenten zusammengesetzten Anwendung laufen die Komponenten in einem oder mehreren verteilten Servern. Clients greifen über CORBA auf diese Komponenten zu, um deren Dienste zu benutzen [CORBA 02].

Eine Komponente in CORBA ist ein einfacher Typ, welcher eine Erweiterung und Spezialisierung des Object-Metatypen von CORBA darstellt. Die interne Repräsenta- tion der Komponente wird dabei gekapselt [CORBA 02]. Eine wichtige Eigenschaft besteht auch darin, dass Komponenten mehrere Schnittstellen exportieren und impor- tieren können [Stal 00].

Clientsicht auf Komponenten

Clients stellen Anfragen (engl.: requests) an CORBA-Objekte, deren Implementie- rungsdetails und Ort verborgen bleiben. Client und ausführbares CORBA-Objekt kön- nen in verschiedenen Programmiersprachen entwickelt worden sein und auf verschie- denen Plattformen laufen [CORBA 02]. Als Client wird in diesem Zusammenhang je- de Entität bezeichnet, die eine Anfrage an ein CORBA-Objekt richtet, also auch andere CORBA-Objekte.

Eine Referenz auf eine Komponente ist ähnlich der Referenz auf ein CORBA-Ob- jekt. Clients die noch keine Komponenten kennen, können diese wie eine gewöhnliche Referenz auf ein Objekt benutzen. Diese Referenz auf eine Instanz einer Komponen- te verweist immer auf eine ausgezeichnete Schnittstelle der Komponente, der so ge- nannten Äquivalenzschnittstelle. Eine Komponente kann auch weitere Schnittstellen besitzen, die Facetten genannt werden. Der Client kann über die Äquivalenzschnitt- stelle diese Facetten ansteuern. Durch die Möglichkeit der zusätzlichen Schnittstellen, wird die Wiederverwendbarkeit und Erweiterbarkeit beträchtlich gesteigert, da einer Komponente weitere Funktionen hinzugefügt werden können, ohne dass bestehende Schnittstellen oder Clients davon betroffen sind [Stal 00][CORBA 02].

Eine Komponente obliegt der Zuständigkeit einer Home-Schnittstelle (kurz Home genannt). Jedes Home administriert Komponenten genau eines bestimmten Typs. Je- de Komponente ist also stets eindeutig einem Home zugeordnet. Clients können die Home-Schnittstelle benutzen, um auf eine standardisierte Weise den gesamten Lebens- zyklus der Komponente zu kontrollieren. Ein Home kann optional einen Primärschlüs- sel benutzen, um eine Zuordnung von Schlüsselwerten zu Komponenteninstanzen her- zustellen. Der Weg zur Komponente erfolgt also stets über das Home. Clientanwen- dungen lokalisieren das Home über einen Home-Finder, bei dem sie sich zur Initiali- sierungszeit registrieren [CORBA 02]. Die „Clientsicht auf Komponenten“ ist in Bild 2 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2: Clientsicht auf Komponenten in CORBA

Entwicklersicht auf Komponenten

Das Komponentenmodell bietet verschiedene Arten von Schnittstellen die in der Spezifikation [CORBA 02] folgendermaßen beschrieben sind (siehe Bild 3):

Facetten (engl.: facets): Facetten sind benannte Schnittstellen eines bestimmten Typs. Über sie kann der Client auf die Dienste der Komponente zugreifen. Dazu werden die Schnittstellen als gewöhnliche CORBA-Objektreferenzen zur Verfügung gestellt (siehe auch Abschnitt „Clientsicht auf Komponenten“).

Die einzelnen Facetten einer Komponente sind soweit voneinander unabhängig, dass mehrere Facetten des gleichen Typs definiert werden können, ohne dass sich deren Verwendung gegenseitig, zum Beispiel durch einen gemeinsamen Zustand, beeinflussen. Damit können Facetten verschiedene Sichten einer Komponente darstellen und verschiedene Rollen eines Clients gegenüber der Komponente de- finieren. Die Lebenszeit einer Facette ist durch die Lebenszeit der Komponente, zu der sie gehört, begrenzt.

Receptacles: Ein Receptacle bezeichnet die Fähigkeit einer Komponente, eine Schnittstelle eines bestimmten Typs zu verwenden. Ist die Komponente mit einer solchen Schnittstelle verbunden, ist von einer Connection die Rede. Die Etablierung der Verbindungen erfolgt über so genannte Monteure [Stal 00].

Receptacles ermöglichen die für Komponenten wichtige Wiederverwendung durch Komposition. Eine Komponente kann so die Dienste einer anderen Kompo- nente oder eines Objektes in Anspruch nehmen und wieder zur Verfügung stellen. Es besteht allerdings keine implizite Beziehung oder Abhängigkeit zwischen der Komponente und der verbundenen Objektreferenz. Es kann also nicht automa- tisch von einer Delegation oder Weiterleitung von Operationsaufrufen ausgegan- gen werden. Allein der Komponentenentwickler definiert die Bedeutung eines Receptacles.

Ereignisse (engl.: events): Das Ereignis-Modell des CORBA Komponentenmo- dells ist ein push-Modell, das heißt die Komponenten übergeben die Ereignisse einem Ereigniskanal. Der einfache Mechanismus dieses push-Modells ist durch so genannte Consumer-Schnittstellen verwirklicht worden. Entwickler spezifizie- ren das Interesse einer Komponente, Ereignisse zu senden oder zu empfangen, indem sie Ereignisauslöser beziehungsweise Ereignisempfänger der Komponen- tendefinition hinzufügen:

- Ereignisauslöser (engl.: event sources): Ereignisauslöser in Komponenten haben Referenzen zu Consumer-Schnittstellen und geben Ereignisse eines speziellen Typs zu einem oder mehreren Ereignisempfänger, oder an einen Ereigniskanal weiter.

- Ereignisempfänger (engl.: event sinks): Ereignisempfänger liefern Consumer-Schnittstellen, an die andere Entitäten (Clients, Komponenten, usw.), die Ereignisse eines bestimmten Typs senden.

Optional können Entwickler auch angeben, ob mehrere Empfänger ein Ereignis empfangen sollen, oder ob dies explizit nur einem Empfänger ermöglicht wird.

Konfiguration von CORBA-Komponenten. Eine CORBA-Komponente besitzt Attri- bute, welche eine Konfiguration der Komponente ermöglichen. Im Sinne der Wieder- verwendbarkeit dienen sie dabei in erster Linie zur Bestimmung des Verhaltens, aus einer Menge möglicher Verhaltensmuster. Dadurch soll die Komponente die Möglich- keit haben, an spezielle Verwendungssituationen angepasst werden zu können. Der Quellcode der Komponente muss dabei nicht geändert werden [CORBA 02].

Zugriff auf die Attribute wird über Accessor-Methoden und Mutator-Methoden ermöglicht. Accessor-Methoden liefern nur die Werte von Attributen, verändern aber nicht den Zustand der Komponente. Das heißt die Attribute können nur gelesen werden. Mutator-Methoden können den Zustand der Komponente verändern, sie können auf die Attribute lesend und schreibend zugreifen [CORBA 02].

Container für Komponenten. Ein Container bildet eine Schale um die Komponente und stellt ihr verschiedene Programmierschnittstellen zur Verfügung. Die Grundüber- legung hierfür ist, dass eine Komponente kein Wissen über die Interaktion mit dem darunter liegenden System benötigt, dies bewirkt Plattformunabhängigkeit [Stal 00].

Abbildung in dieser Leseprobe nicht enthalten

Bild 3: Entwicklersicht auf Komponenten in CORBA

Ein Container weist zwei unterschiedliche Arten von Programmierschnittstellen auf:

1. External API³: Definiert die Schnittstellen, die einem Client verfügbar gemacht werden. Hierzu zählen die Äquivalenzschnittstelle, die Facetten und das Home.
2. Container API: Definiert ein Framework, das dem Komponenten-Entwickler ver- fügbar ist. Hierbei wird zwischen internen Schnittstellen (engl.: internal interfa- ces) und Rückruf-Schnittstellen (engl.: callback interfaces) unterschieden. Über interne Schnittstellen ist es der Komponente möglich, die vom Container ange- botenen Dienste zu benutzen. Die Rückruf-Schnittstellen sind innerhalb der Kom- ponente zu entwickeln. Sie stehen dem Container zur Verfügung.

In diesem Kontext existieren zwei unterschiedliche Ausprägungen, um Komponentenreferenzen mit oder ohne einen Persistenzstatus zu verwalten: Entity Container für persistente Container und Session Container für eine transiente Verwaltung von Komponenten [CORBA 02][Stal 00].

Zwischen dem Container, der zu Grunde liegenden CORBA-Implementierung (dem Portable Object Adapter (POA)) und den CORBA-Diensten existieren wiederum drei unterschiedliche Interaktionsmöglichkeiten - die Container Implementation Types: Wenn ein Servant⁴ sämtliche Instanzen eines Komponententyps repräsentiert, dann spricht man von einer Interaktion des Typs stateless, wobei beim Typ conversional zu jeder Instanz ein eigener Servant zugeordnet wird. Bei persistenten Containern

Die Common Object Request Broker Architecture 16

gibt es nur einen Implementierungstyp, der durable genannt wird. Auch bei diesem wird jede Komponente mit einer eindeutigen Referenz auf einen Servant verbunden [CORBA 02].

Daraus ergeben sich vier Komponentenkategorien als Kombination von Con- tainertyp, Container Implementierungstyp sowie Primärschlüsseln (siehe Tabelle 1) [CORBA 02]:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1: CORBA Komponentenkategorien

Die Architektur des Container-Programming-Modells ist in Bild 4 zusammenge- fasst.

Abbildung in dieser Leseprobe nicht enthalten

Bild 4: CORBA Container-Programming-Modell

Schnittstellenbeschreibungen von CORBA-Komponenten. Die Schnittstellen der CORBA- Komponenten wurden bis zur CORBA-Version 2.3 mit Hilfe der Interface Definition Language (IDL) beschrieben. Mit der Version 3.0 erfolgt die Beschreibung in einer Erweiterung der Interface Definition Language, der Component Interface Definition Language (CIDL). Damit wurde eine deklarative Sprache definiert, um die Entwick- lung und den Einsatz von Persistenzmechanismen einer Komponente zu beschreiben.

Die Component Interface Definition Language stellt dem Entwickler abstrakte sprachliche Mittel zur Verfügung, um eine Komponente sowie deren Zusammenwirken mit Persistenzmechanismen zu beschreiben. Ein Übersetzer erzeugt daraus programmiersprachliche Lese- und Schreiboperationen zum Zugriff auf das zu Grunde liegende persistente Speichermedium [Stal 00].

Zur Speicherung von persistenten Zuständen sieht das Komponentenmodell zwei Möglichkeiten für die Zuständigkeiten vor [Stal 00]:

1. Ist der Container für die Durchführung der Persistenzmechanismen zuständig, spricht man von Container managed Persistence. Der Container erzeugt dann automatisch die benötigten Speicher- und Ladeoperationen und führt diese aus.
2. Wenn der Entwickler diese Aufgabe nicht dem Containern übertragen, sondern stattdessen selbst für die entsprechende Aktion zuständig sein will, dann spricht man von Component managed Persistence. Er kann sich dabei des Persistenz- dienstes bedienen oder stattdessen proprietäre Mechanismen einsetzen.

Komponentenbeschreibung mittels Descriptoren. Zur „Verpackung“ von einer oder mehreren Komponenten dienen Archive, die so genannten Component Archive (CAR) Dateien. Neben den Implementierungs- und Ressourcendateien sind XML⁵ -basierte Beschreibungen, die Descriptoren genannt werden, Teil dieser Auslieferung. Die Kom- ponenten erhalten einen Softwarepaket-Descriptor, der Informationen zu den ausführ- baren Dateien im Archiv enthält. Für jeden Komponententyp gibt es einen Descriptor, der den Typ, die Schnittstellen und weitere Informationen enthält [Stal 00].

2.2.2 Die Enterprise JavaBeans der Java 2 Enterprise Edition

„The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification.“

Linda G. DeMichiel, Sun Microsystems

In diesem Unterabschnitt wird eine Einführung in Enterprise JavaBeans (kurz EJB) gegeben. Die aktuelle Version, die hierbei Verwendung findet, ist die Enterprise JavaBeans 2.1 Specification. Zu Beginn werden die Ziele dieser Spezifikation vorge- stellt, danach werden die verschiedenen Typen von Enterprise JavaBeans beschrieben und schließlich wird das Komponentenmodell aus Clientsicht und Entwicklersicht be- trachtet.

Enterprise JavaBeans Spezifikation

Enterprise JavaBeans sind eine vollständige Spezifikation für Server-Komponenten. Sie wurde von Sun Microsystems, zusammen mit anderen Herstellern von Middleware- und Datenbank-Produkten entwickelt. Es wurde ein Standard entwickelt, welcher komponentenbasierte, transaktionsorientierte und mehrschichtige Anwendungen in Java realisiert. Die EJB Spezifikation wird durch große Teile der Industrie gefördert (unter anderem IBM, Oracle, Bea Systems, Borland) [Backschat 02].

Ziele der EJB Spezifikation

Die Ziele der EJB Architektur lassen sich wie folgt zusammenfassen [EJB 02]:

Die EJB Spezifikation soll die Standard-Komponentenarchitektur für verteilte ob- jektorientierte Geschäftsanwendungen in der Programmiersprache Java werden.

Die EJB Spezifikation soll das Entwickeln von Anwendungen erleichtern, indem sich der Entwickler nicht mehr um die technischen Details, wie Transaktions- und Zustandsverwaltung, Persistenz, Sicherheit, Nebenläufigkeiten und Ressourcenverwaltung kümmern muss.

Die EJB Spezifikation folgt der „Write Once, Run Anywhere“⁶ Philosophie.

Kompatibilität soll sowohl im Rahmen der bestehenden Java-APIs, als auch mit Server-Systemen von Drittanbietern und CORBA-Protokollen gewährleistet sein.

Die EJB Spezifikation soll die Verwendung und die Entwicklung von WebServices ermöglichen.

Entsprechend den vorgestellten allgemeinen Zielen, kann die EJB Spezifikation sowohl als herstellerunabhängiger Vorschlag für die Entwicklung mehrschichtiger Client/Server-Anwendungen als auch als Integrationsplattform in heterogenen Systemumgebungen verstanden werden [Schmietendorf 02].

Typen von Enterprise JavaBeans

Es gibt verschiedene Typen von Enterprise JavaBeans (siehe Bild 5), die jeweils für bestimmte Einsatzbereiche vorgesehen sind [Backschat 02]:

Abbildung in dieser Leseprobe nicht enthalten

Bild 5: Typen von Enterprise JavaBeans

Entity Beans: Entity Beans modellieren Daten-Entitäten, mit dauerhaft gespei- cherten Daten (persistente Daten). Bei diesen Enterprise JavaBeans besteht nicht für jeden Client eine eigene Instanz, sondern für alle Clients eine gemeinsame, auf die jedoch ein gleichzeitiger Datenzugriff möglich ist. Entity Beans werden meist durch eine Datenbank verwaltet und können somit auch vor Serverabstür- zen gesichert werden.

Man unterscheidet wiederum zwei Typen von Entity Beans:

- Die Bean Managed Persistence Beans (BMP-Beans) überlassen es dem Komponentenentwickler, sich um die Persistenz der Daten zu kümmern. Er ist selbst dafür verantwortlich eine Verbindung zu einem Datenbank-Mana- gement-System (DBMS) aufzubauen und die nötigen Daten darin zu speichern oder von dort zu laden.
- Einfacher wird es dem Entwickler bei Container Managed Persistence Beans (CMP-Beans) gemacht. Er muss lediglich beschreiben welche Daten er ge- speichert haben möchte. Der Container baut die Verbindung zum Datenbank- Management-System auf, um Daten zu speichern oder zu laden. Ein weiterer Vorteil kann die Unabhängigkeit vom Datenbank-Management-System sein.

Session Beans: Session Beans werden dazu verwendet, Anwendungslogik auf dem Server auszuführen. Eine Session Bean ist nicht persistent. Sobald die Kommunikation zwischen dem Client und dem Server beendet ist, kann auch die Instanz durch den Container zerstört werden.

Man kann Session Beans in Stateless Session Beans und Stateful Session Beans unterteilen:

- Stateless Session Beans (SLS) besitzen keinen spezifischen Zustand und stehen einem Client nur für die Zeit eines Methodenaufrufes zur Verfügung. Der Vorteil besteht darin, dass wesentlich weniger Instanzen vorhanden sein müssen, als Clients vorhanden sind.
Die Enterprise JavaBeans der Java 2 Enterprise Edition 20
- Bei Stateful Session Beans (SFS) handelt es sich um kompliziertere Kon- struktionen. Sie besitzen einen so genannten Conversational State, einen zu- standsbehafteten Status. Dadurch wird die Stateful Session Bean über ihren gesamten Lebenszyklus hinweg einem Client zur Verfügung gestellt.

Message-Driven Beans: Message-Driven Beans ermöglichen eine Bearbeitung von Nachrichten die über einen Nachrichtendienst, dem Java Message Service (JMS), eingehen können. Sie können keinen spezifischen Zustand halten und ha- ben keine individuelle Identität. Alle eingehenden Nachrichten werden vom Con- tainer entgegengenommen, der sie dann zur Verarbeitung an eine zuständige In- stanz weiterleitet.

Session Beans und Entity Beans werden direkt über Schnittstellen angesprochen. Diese Aufrufe sind synchronisiert, das heißt Session Beans bleiben solange blockiert, bis die Dienste der Entity Beans abgearbeitet sind. Für Message-Driven Beans wird hingegen eine asynchrone Kommunikationsform verwendet. Der Client kann unmit- telbar nach dem Absenden einer Nachricht fortfahren und wird nicht blockiert.

Clientsicht auf Komponenten

Der Zugriff eines Clients auf die Dienste einer Session Bean oder auf eine Entity Bean erfolgt über folgende Schnittstellen (siehe Bild 6):

Home-Interface: Das Home-Interface steuert den Lebenszyklus der Komponente. Dazu zählen die Erzeugung, die Beseitigung und die Lokalisierung einer EJB- Komponente.

Component-Interface: Das Component-Interface spezifiziert die nach Außen sichtbaren Dienste der EJB-Komponente.

Abbildung in dieser Leseprobe nicht enthalten

Bild 6: Clientsicht auf Komponenten in EJB für Session Beans und Entity Beans

Damit ein Client auf eine konkrete EJB-Instanz zugreifen kann, benötigt er eine Referenz auf das entsprechende Home-Interface. Diese erhält der Client zum Zeitpunkt der Ausführung über den Namens- und Verzeichnis-Dienst JNDI (Java Naming and Directory Interface).

Message-Driven Beans reagieren nur auf Nachrichten und haben somit keinen un- mittelbaren Client. Daher exportieren sie auch keine Schnittstellen für einen Aufruf, sondern verarbeiten eingehende Nachrichten über den Java Message Service (JMS).

Lokale (engl. local) und entfernte (engl. remote) Clients. EJB unterscheidet zwei Arten von Clients, die die Sichtweise des Clients auf die Enterprise JavaBean verändert [Backschat 02]:

Local Clients: Local Clients liegen im gleichen Adressraum des Containers und werden von derselben Java Virtual Machine (JVM) ausgeführt.

Remote Clients: Remote Clients können in einem anderen Adressraum als der Container liegen, sie laufen beispielsweise in einer anderen Java Virtual Machine (JVM) ab, oder können sich auf einem anderen Rechner befinden.

Entwicklersicht auf Komponenten

Für den Entwickler einer Enterprise JavaBean besteht diese aus verschiedenen Schnittstellen und Hilfsklassen, der Bean-Klasse selbst, sowie dem Deployment Descriktor. Diese Bestandteile seien im Folgenden beschrieben [Backschat 02]:

Remote Home-Interface: Das Remote Home-Interface wird von Remote Clients aufgerufen und übernimmt die Steuerung des Lebenszyklus der Enterprise Java- Bean.

Local Home-Interface: Das Local Home-Interface übernimmt dieselben Aufga- ben wie das Remote Home-Interface, ist jedoch nur für Local Clients zugänglich.

Remote Component-Interface: Das Remote Component-Interface deklariert alle Methoden die eine Bean-Klasse zur Verfügung stellt. Diese Methoden werden Geschäftsmethoden genannt.

Local Component-Interface: Das Local Component-Interface erfüllt denselben Zweck wie das Remote Component-Interface. Es ist jedoch nur für Local Clients zugänglich.

Bean-Klasse: In der Bean-Klasse werden alle Geschäftsmethoden des Home-In- terface und des Component-Interface implementiert. Weiterhin enthält sie noch zusätzliche Methoden, die direkt vom Container aufgerufen werden und zur Verwaltung der Bean-Instanzen dienen.

Die Zuordnung der Schnittstellen-Methoden auf die Bean-Klassen wird vom Container übernommen. Der Container generiert die Klassen für die Kompo- nenten-Schnittstellen, in denen dann die Methodenaufrufe an die Methoden der

Bean-Klasse delegiert werden. Container werden auf Seite 22 genauer beschrie- ben.

Für die Methoden aus den Home-Interfaces gibt es keine gleichnamigen Implementierungen in der Bean-Klasse. Da diese aber dennoch vorhanden sein müssen, gibt es Konventionen denen diese Methoden entsprechen müssen.

Primärschlüssel-Klasse: Sie ist nur für Entity Beans nötig und muss nur als eigene Klasse zu einem Entity Bean definiert werden, wenn sich der Primärschlüssel nicht auf eine Standard-Klasse von Java abbilden lässt.

Deployment Descriptor: Der Deployment Descriptor enthält Metadaten der Komponente. In dieser XML⁷ -Datei werden die Anforderungen einer Enterprise JavaBean an seine Laufzeitumgebung beschrieben. Die Elemente der XML-Datei sind von der EJB-Spezifikation vorgegeben. Die Informationen aus dem Deployment Descriptor werden vom Container ausgewertet, um der Komponente die gewünschte Laufzeitumgebung zu bieten.

Der Container der Enterprise JavaBeans. Der Container verwaltet den Lebenszyklus einer Enterprise JavaBean. Er verwaltet EJB-Objekte für den Zugriff durch Clients, bearbeitet Transaktionen zwischen Clients und EJB-Objekten, ermöglicht Zugriffskontrollen für einzelne Methoden einer EJB und ist für die Erzeugung, das RessourcenPooling⁸ und die Vernichtung von Enterprise JavaBeans zuständig [Backschat 02]. Die folgenden Zusammenhänge sind in Bild 7 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Bild 7: Beziehungen zwischen den Klassen eines EJB Containers

Nachdem dem Container das Home-Interface, das Component-Interface, die Bean- Klasse sowie der Deployment-Descriptor zur Verfügung gestellt wurde, erzeugt der

Container die verschiedenen Klassen, durch die diese Komponenten zusammengehalten werden. Alle Anfragen von Clients zum Erzeugen, Suchen und Löschen von Enterprise JavaBeans oder zum Aufruf von EJB-Methoden werden durch den Container vermit- telt. Entweder verarbeitet er sie selbst, oder er gibt die Anfragen an die entsprechen- den Methoden des EJB-Objekts weiter. Nachdem ein Client eine Referenz auf eine Schnittstelle für ein EJB-Objekt erhalten hat schaltet sich der Container in alle Me- thodenaufrufe bei der Enterprise JavaBean ein, um sie mit erforderlichen Maßnahmen wie beispielsweise zur Transaktionsverwaltung und Sicherheit zu versorgen. Außer- dem bietet der Container Unterstützung bei der Persistenz von Enterprise JavaBeans, indem er entweder den Zustand selbst verwaltet, oder indem er die Enterprise JavaBean informiert, wenn sie ihren Zustand persistent speichern oder laden muss.

Ein Container kann während seiner Lebenszeit mehrere EJB-Objekte und Objektar- ten verwalten. Dabei hat er gewisse Freiheiten bei der Verwaltung von Ressourcen. Beispielsweise kann ein Container entscheiden, ob er eine Enterprise JavaBean vor- übergehend serialisiert und auf dem Dateisystem des Servers, oder auf einem anderen persistenten Speicher ablegt. Dieser Vorgang wird als Passivieren einer Enterprise Ja- vaBean bezeichnet.

Bei der Inbetriebnahme eines EJB-Objekts in einem Server kann angegeben wer- den, wie der Container die Enterprise JavaBean zur Laufzeit, bezüglich der Transak- tionsverwaltung, des Ressourcen-Pooling, der Zugriffskontrollen und der Datenpersis- tenz behandeln soll. Für diesen Zweck sind die Deployment-Descriptoren zuständig. Diese Einstellungen können für jede Inbetriebnahme eines EJB-Objekts entsprechend angepasst werden.

Das Deployment der Enterprise JavaBeans. Die Inbetriebnahme einer EJB innerhalb eines Containers wird als Deployment bezeichnet. Dazu gehören die folgenden Schrit- te:

1. Die Deployment-Informationen und die Optionen für die Enterprise JavaBean werden in Form des Deployment-Descriptors angegeben. Die Informationen in diesem Deployment-Descriptor umfassen die Namen der Klassen, die als Compo- nent-Interfaces, Home-Interfaces und Bean-Klassen der EJB dienen, sowie Op- tionen für die Transaktionsunterstützung und Einstellungen für die Zugriffskon- trolle. Zusätzlich zu der grundlegenden Deployment-Information erfordern die verschiedenen Typen von Enterprise JavaBeans (siehe Seite 18) jeweils eine Rei- he zusätzlicher Metadaten [Backschat 02].
2. Generierung der vom Container zur Verfügung gestellten Klassen.
3. Verpackung der Enterprise JavaBeans in einem EJB-Jar-Archiv. Darin werden alle für die Komponente relevanten Dateien zusammengefasst. Viele Entwick- lungsumgebungen für Enterprise JavaBeans, können dieses Archiv automatisch erzeugen. Der Komponentenentwickler kann es aber auch durch einen einfachen Befehl selbst erzeugen [Backschat 02].

2.2.3 Die Assemblies des .NET Frameworks

„The Microsoft ® .NET Framework is an important new component of the Microsoft Windows ® family of operating systems. It is the foundation of the next generation of Windows-based applications that are easier to build, de- ploy, and integrate with other networked systems. [...] The .NET Framework helps software developers and systems administrators more easily build and maintain systems with improvements toward performance, security, and re- liability.“

Microsoft Corporation

Dieser Unterabschnitt gibt eine Einführung in die neueste Komponententechnik von Microsoft, die Bestandteil des .NET Frameworks (.NET wird als „dot-net“ gesprochen) ist. Zu Beginn wird auf die Entwicklungsgeschichte der Komponententechniken von Microsoft eingegangen, danach werden das .NET Framework und dessen SoftwareKomponenten beschrieben.

Entwicklungsgeschichte der Komponententechniken von Microsoft

Die Komponententechniken von Microsoft wurden im Gegensatz zu CORBA oder EJB, nicht am „Reißbrett“ geplant. Vielmehr stellen diese gewachsene Standards dar, dessen Entwicklung im Wesentlichen durch die Produktpflege und durch Marketingmaßnahmen beeinflusst wurden [Gruhn 00]. Im Folgenden werden die einzelnen Entwicklungen kurz beschrieben.

Das Component Object Model (COM). Microsofts Component Object Model (COM) wurde erstmals 1993 veröffentlicht und ist auf Windows-Betriebssystemen allgegenwärtig. Es stellt den Standard dar, auf den alle anderen Komponentenmodelle von Microsoft aufgebaut wurden.

COM ist ein binärer Standard, der die Kommunikation von Objekten regelt, die sich auf einem Rechner mit einem Windows-Betriebssystem befinden. Es wird nicht vorgeschrieben, in welcher Programmiersprache die Komponenten entwickelt werden müssen. Es werden lediglich Schnittstellen definiert, sie stellen die einzige fundamentale Entität von COM dar [Szyperski 02].

Distributed COM (DCOM). Um COM das Verteilen der Komponenten über ein Netzwerk zu ermöglichen, wurde es 1996 um ein Netzwerkprotokoll erweitert und Distributed COM (DCOM) genannt.

Ermöglicht wird die Kommunikation über Rechnergrenzen hinweg, durch Nutzung von Remote Procedure Calls (RPC). Dadurch ist es möglich, zahlreiche verbindungs- orientierte und verbindungslose Netzwerkprotokolle (zum Beispiel TCP, UDP, IPX, usw.) zu verwenden.

OLE und ActiveX. Um den Begriff OLE, das für Object Linking and Embedding steht und den Begriff ActiveX, besteht einige Verwirrung. OLE in der ursprünglichen Bedeutung bezog sich nur auf die von Microsoft benutzten Verbunddokumente. Die OLE Version 2 bezog dann zusätzlich COM mit ein, Microsoft nannte dies aber nach wie vor OLE. Anfang 1996 änderte Microsoft seine Meinung und wählte als neuen Markennamen für OLE, nun den Ausdruck ActiveX. Damit bezog sich nun OLE er- neut nur auf die Verbunddokumenttechnik. Daher lässt sich ActiveX als Sammlung von Techniken, die auf Basis von COM und DCOM definiert sind, bezeichnen. Dies unter- streicht die fundamentale strategische Bedeutung von COM und DCOM für Microsoft [Brosius 98].

COM+. Eine weitere Version von Microsofts COM, ist die Version COM+, sie wurde 1997 veröffentlicht. COM+ stellt die Vereinigung von COM, des Microsoft Transaction Server (MTS) und des Microsoft Message Queue Server (MSMQ) dar und war erstmals in Windows 2000 enthalten [Szyperski 02].

Das .NET Framework. Die Entwicklung des .NET Framework begann mit der Ent- wicklung einer neuen Version von COM+. Sehr schnell stellte sich allerdings für Mi- crosoft heraus, dass .NET sich so weit von COM entfernen würde, dass ein neuer Na- me gerechtfertigt ist. Zunächst wurde das Konzept Next Generation Windows Service (NGWS) genannt, seit Juli 2000 verwendet Microsoft den Begriff .NET Framework.

Das .NET Framework bildet den Kern von Microsofts .NET (.NET ist ein Begriff welcher für eine ganze Reihe von Techniken von Microsoft steht). Die Architektur des .NET Framework, wird in Bild 8 dargestellt [Reilly 02].

Bild 8: Die .NET Framework Architektur Common Language Runtime (CLR) Die Common Language Runtime (CLR) ist die Laufzeitumgebung von .NET-Program- men. Sie basiert auf einer virtuellen Maschine mit einem eigenen Befehlssatz, der Common Intermedia Language (CIL). In diese Sprache wird der Quellcode aller .NETProgramme übersetzt.

Die Common Language Runtime (CLR) stellt also eine gemeinsame Plattform aller .NET-Programme dar, egal in welcher Sprache sie geschrieben wurden oder auf welcher Maschine sie laufen [Beer 03].

Assemblies

Die Software-Komponenten des .NET Frameworks werden Assemblies genannt. Sie sind die Nachfolger der COM-Komponenten [Beer 03]. Um die Akzeptanz des .NET Frameworks zu fördern, wurde von Microsoft eine Interoperabilität mit COM-Kompo- nenten sichergestellt.

Assemblies bilden eine Sammlung von Klassen und anderen Ressourcen (zum Beispiel Bilder). Sie werden entweder als EXE-Datei oder als DLL-Datei gespeichert und ausgeliefert. Als EXE-Datei wird ein ausführbares Programm (von execute), welches durch einen Übersetzer (engl. compiler) erzeugt wurde, bezeichnet. Eine DLL-Datei (Dynamic Link Library (DLL)) bezeichnet einen Bibliotheksbaustein.

In Bild 9 werden die einzelnen Bestandteile eines Assemblies verdeutlicht. Die nachfolgenden Erläuterungen klären die dabei verwendeten Begriffe:

Abbildung in dieser Leseprobe nicht enthalten

Bild 9: Bestandteile von .NET Assemblies

- NET-PE-Datei: PE (Portable Executable) bezeichnet das Windows-Binärformat, das von Windows direkt geladen werden kann. Da .NET für Windows-Plattfor- men entwickelt worden ist, hat Microsoft sich für ein Format entschieden, wel- ches mit dem PE-Binärformat kompatibel ist, den so genannten .NET-PE-Datei- en [Beer 03].

Der Unterschied einer .NET-PE-Datei zu einer bisherigen PE-Datei, besteht in .NET-spezifischen Informationen, die in der Datei enthalten sind. Sie werden von der Common Language Runtime (CLR) verwendet um das Programm ausführen zu können.

Modul: Jede .NET-PE-Datei ist ein Modul. Die Common Language Runtime (CLR) kann ein Modul alleine nicht direkt verwenden, es wird dazu das Manifest benötigt [Beer 03].

Manifest: Das Manifest besteht aus Metainformationen die in einer Tabelle gespeichert werden. Sie enthalten alle Informationen die notwendig sind, um Assemblies zu definieren:

- Die Identität des Assembly (Name, Version, usw.), - die Namen aller Dateien im Assembly,
- einen kodierten Hashwert aller Dateien im Assembly,
- Details der vorhandenen Klassen, Methoden und Eigenschaften und
- Namen und Hashwerte aller referenzierten Sicherheitseinstellungen des As- sembly.

Ein Modul zusammen mit einem Manifest bildet ein Assembly. Während ein Modul also immer eine physische Datei ist, stellt ein Assembly eine rein logische Einheit dar.

Es kann aus einer einzigen .NET-PE-Datei bestehen, einem so gennanten single file assembly, oder sich aus mehreren einzelnen Dateien zusammensetzen, dann nennt man es ein multi file assembly (siehe Bild 9) [Beer 03].

In einem Assembly besitzt genau ein Modul das Manifest. Im Manifest wird auf alle anderen im Assembly enthaltenen Dateien verwiesen, dies hält das Assembly zusammen. Bei einem direkt ausführbarem Programm (einer EXE-Datei) sollte das Modul mit dem Eintrittspunkt (der Main-Methode) auch das Manifest enthalten.

Kapselung durch Assemblies. Ein Assembly bildet eine Kapsel um alle beteiligten Elemente und regelt damit:

Sichtbarkeit (engl.: visibility): Damit wird geregelt welche der im Assembly definierten Typen nach außen hin sichtbar sind. Zum Beispiel können mit dem Schlüsselwort private Typen nach außen unsichtbar gemacht werden.

Zugriffsrechte (engl.: accessibility): Zugriffsrechte regeln den Zugriff auf das ge- samte Assembly. D. h. es wird die Referenzierung auf die Komponente geregelt.

Private Assemblies. Ein privates Assembly kann von genau einer Anwendung be- nutzt werden. Sie werden in einem Ordner, der zur Struktur der Anwendung gehört, installiert. Dazu wird meist der Ordner verwendet, indem sich die ausführbare Datei der Anwendung befindet. Die Installation kann mittels eines einfachen Kopierens der Datei erfolgen.

Die Identifikation des private Assembly wird anhand eines Namens vorgenommen. Dieser Name findet sich im Manifest des private Assembly und im Dateinamen.

Shared Assemblies. Shared Assemblies werden im Global Assembly Cache (GAC) installiert und sind somit für alle Anwendungen benutzbar. Der Global Assembly Cache (GAC) ist eine eigene Datenstruktur zur Verwaltung von Assemblies. Hier können auch gleichnamige DLL-Dateien stehen, sie werden durch einen so genannten starken Namen unterschieden [Szyperski 02].

Starker Name. Jedes Assembly enthält in seinem Manifest einen Metadaten-Ein- trag, der es eindeutig identifiziert. Die Identifikation des Assembly wird durch den starken Namen bestimmt, dieser besteht aus vier Teilen [Beer 03]:

1. Name (name): Der Name des eines Assembly sollte mit dem Dateinamen über- einstimmen. Dies erleichtert das Auffinden des Assembly.
2. Versionsnummer (version): Die Versionsnummer setzt sich aus vier durch Punk- te getrennte Zahlen zusammen. Sie kann entweder mittels eines Attributes im Quellcode festgelegt werden oder durch den Assembly-Linker generiert werden.
3. Sprache (culture): Sie ordnet dem Assembly sprach- und länderspezifische Infor- mationen zu. Dies kann wiederum durch ein Attribut festgelegt werden oder vom Assembly-Linker generiert werden. Die Zeichenkette für die Sprachangabe muss einem standardisierten Format (IETF RFC 1766) entsprechen (zum Beispiel „de- AT“ für österreichisches Deutsch).
4. Öffentlicher Schlüssel (public key): Damit wird der Produzent des Assembly iden- tifiziert. Durch eine digitale Signatur kann das Assembly vor Veränderungen von Dritten geschützt werden.

Assemblies und Sicherheit. In .NET können Rechte nicht nur für einzelne Benutzer, sondern auch für einzelne Assemblies vergeben werden. Dies wird Code Access Security (CAS) genannt und basiert darauf, ob ein Assembly Zugriff auf eine bestimmte Ressource erhalten soll oder nicht [Beer 03].

In jedem Assembly werden Informationen über dessen Identität, Herkunft, Ent- wickler, usw. gespeichert. Diese Informationen werden unter dem Begriff evidence zusammengefasst. Es können somit zwei wichtige Sicherheitsfragen geklärt werden [Westphal 02]:

1. Woher kommt der Code?
2. Wer hat den Code erstellt?

Beispielweise kann damit einem Assembly eines bestimmten Herstellers, der Zu- griff auf das Dateisystem verwehrt werden (identifiziert durch den öffentlichen Schlüs- sel).

2.2.4 Web-Services

Es stellt sich die Frage, weshalb ein weiteres Komponentenmodell - die Web-Services - entworfen wurde, wo doch bereits de-facto-Standards wie CORBA, Enterprise JavaBeans und .NET existieren. Dieser Unterabschnitt beschreibt, was unter dem Begriff Web-Services allgemein verstanden wird.

Beschreibung von Web-Services

Für den Begriff Web-Services existieren zahlreiche Definitionen. Hier sei die Definition des World Wide Web Consortiums (W3C) angeführt [Booth 04]:

„[Definition: A Web service is a software system designed to support inter- operable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other sys- tems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML seriali- zation in conjunction with other Web-related standards.]“

Aus der Sicht eines Clients sind Web-Services ähnlich zu den bereits in dieser Ar- beit vorgestellten Software-Komponenten. Sie bieten dem Client Dienste über stan- dardisierte Schnittstellen, ohne dessen Quellcode zu offenbaren [Szyperski 02]. Ein Web-Service muss aber nicht notwendigerweise komponentenbasiert sein. Es ist da- mit beispielsweise auch möglich, betriebliche Standardsoftware als Web-Services zu verpacken und sie somit in andere Architekturen einzubinden [Dustdar 03].

Wie in Bild 10 dargestellt, kann ein Web-Service als eine virtuelle Kompo- nente betrachtet werden. Sie verbirgt die zugrundeliegende konkrete Komponen- te [Leymann 03]. Web-Services werden meist mit Hilfe der beschriebenen Kom- ponententechniken von CORBA, der Enterprise JavaBeans oder dem .NET Frame- work realisiert. Sie können allerdings auch mit anderen Techniken entwickelt wer- den, wie beispielsweise mit der Skriptsprache PHP [David 04] oder mit CGI Skripten [Chappell 03].

Abbildung in dieser Leseprobe nicht enthalten

Bild 10: Web-Service als virtuelle Komponente Standards und Protokolle

Für Web-Services wurden eine Reihe von Standards und Protokolle geschaffen, die wichtigsten seien hier angeführt:

Simple Object Access Protocol (kurz SOAP). SOAP ist ein Kommunikationsprotokoll das für verteilte Anwendungen entworfen wurde. Es definiert Codierungs- und Bin- dungsstandards und ermöglicht den Austausch von strukturierten und typisierten Da- ten mit Hilfe der Beschreibungssprache XML [Chappell 03]. Der Vorteil von SOAP besteht darin, dass verschiedene Protokolle als Übertragungsprotokoll verwendet wer- den können. SOAP definiert selbst keine Anwendungssemantik und kann dadurch für ein breites Anwendungsspektrum verwendet werden. Dies reicht vom einfachen Zu- stellen einer Nachricht bis zum entfernten Aufruf von Prozeduren [Rahm 02].

Der Aufbau einer SOAP Nachricht sieht folgendermaßen aus [Rahm 02]:

Abbildung in dieser Leseprobe nicht enthalten

Das XML-Element Envelope ist das Wurzelelement der Nachricht. Es kann neben dem XML-Element Body das optionale XML-Element Header enthalten. Durch das XML-Attribut encodingStyle kann angegeben werden, wie Objekte zu XML serialisiert werden, um in einer Nachricht verschickt zu werden. Dieses Attribut kann auch innerhalb anderer XML-Elemente verwendet werden. Es gilt dann nur für den entsprechenden Teil der Nachricht. Der angegebene encodingStyle entspricht der Serialisierung, die in der SOAP-Spezifikation angegeben ist. Im XML-Element Envelope wird noch das Kürzel soap für den SOAP-Namensraum definiert [Rahm 02].

Der Header einer SOAP-Nachricht bietet einen Mechanismus um SOAP erweitern zu können. Diese Erweiterungen müssen vorher nicht mit anderen Kommunikationspartnern abgestimmt werden. SOAP definiert einige XML-Attribute, die es erlauben anzugeben, wie der Empfänger mit Header-Erweiterungen umgehen soll und ob diese Erweiterungen verpflichtend sind [Rahm 02].

Das XML-Element Body einer SOAP-Nachricht bietet eine einfache Möglichkeit, Daten zwischen einem Sender und einem Empfänger auszutauschen. SOAP selbst de- finiert nur ein XML-Element, das innerhalb des XML-Elements Body vorkommen kann - das Fault Element. Dieses XML-Element wird zur Übermittlung von Fehlerzuständen benutzt. Die Serialisierung von Daten basiert auf einem einfachen Typsystem.

[...]

---

¹ Menge von Objekten, die eine gemeinsame Struktur haben und ein gemeinsames Verhalten zeigen.

² Konfigurierbare Softwaremodule mit eigener Verarbeitungslogik und Datenhaltung, die selbständig lauffähig sind.

³ Application Programming Interface (API)

⁴ Eine Instanz der Objektimplementierung wird in der CORBA-Spezifikation als Servant bezeichnet. Servants werden von einer Server-Anwendung erzeugt.

⁵ Extensible Markup Language (XML)

⁶ Ohne Neukompilierung oder Änderung des Quelltextes lauffähige Softwareeinheit oder Anwendung, auf jeder beliebigen Plattform.

⁷ Extensible Markup Language (XML)

⁸ Ressourcen-Pooling ist eine Methode der Leistungsoptimierung.