Lehrstuhl Prof. Otto K. Ferstl Lehrstuhl Prof. Elmar J. Sinz

Transkript

1 Universität Bamberg Lehrstuhl Prf. Ott K. Ferstl Lehrstuhl Prf. Elmar J. Sinz Stephan Mantel, Bernd Knblch, Thrsten Rüffer, Martin Schissler, Klaus Schmitz, Ott K. Ferstl, Elmar J. Sinz Analyse der Integratinsptenziale vn Kmmunikatinsplattfrmen für verteilte Anwendungssysteme Feldkirchenstraße 21, Bamberg, Tel / , Fa / mantel@frwin.de,

2 FORWINBerichtNr.: FWN FORWIN Bayerischer Frschungsverbund Wirtschaftsinfrmatik, Bamberg, Bayreuth, ErlangenNürnberg, Regensburg, Würzburg 2000 Alle Rechte vrbehalten. Insbesndere ist die Überführung in maschinenlesbare Frm swie das Speichern in Infrmatinssystemen, auch auszugsweise, nur mit schriftlicher Einwilligung vn FORWIN gestattet. ii

3 Zusammenfassung Bei Kmmunikatinsplattfrmen für verteilte Anwendungssysteme in ffenen Anwendungssystemarchitekturen ist der aktuelle technlgische Entwicklungsstand vr allem durch MiddlewareTechnlgien, wie CORBA, COM/DCOM und EJB markiert. In dieser Arbeit wird zunächst ein methdischer Rahmen für die Analyse der Integratinsptenziale dieser Kmmunikatinsplattfrmen entwickelt. Ausgehend vn Integratinsmerkmalen und Integratinsknzepten wird daraufhin ein Katalg vn Technlgiemerkmalen abgeleitet, mit dessen Hilfe die einzelnen Plattfrmen hinsichtlich ihrer Integratinsptenziale bewertet werden und ihre Eignung zur Realisierung bestimmter Integratinsknzepte bestimmt wird. Abstract The status qu f cmmunicatin platfrms fr distributed applicatin systems in pen applicatin system architectures is marked by middleware technlgies, like CORBA, COM/DCOM, and EJB. This paper develps a methdical framewrk fr analysis f the integratin ptential f these cmmunicatin platfrms. Based n different integratin characteristics and integratin cncepts, we deduce a catalgue f technlgical characteristics. Using this catalgue, we evaluate the integratin ptential f each cmmunicatin platfrm and check the suitability f these platfrms t implement several integratin cncepts. iii

4 Inhalt 1 EINFÜHRUNG METHODISCHER RAHMEN INTEGRATIONSMERKMALE UND KONZEPTE INTEGRATIONSMERKMALE INTEGRATIONSKONZEPTE KOMMUNIKATIONSPLATTFORMEN FÜR KOMPONENTENBASIERTE ANWENDUNGSSYSTEME OMA / CORBA COM / DCOM / COM EJB UNTERSTÜTZUNG VON INTEGRATIONSZIELEN UND INTEGRATIONS KONZEPTEN DURCH KOMMUNIKATIONSPLATTFORMEN TECHNOLOGIEMERKMALE UNTERSTÜTZUNG DER INTEGRATIONSMERKMALE DURCH TECHNOLOGIEMERKMALE RELEVANZ DER TECHNOLOGIEMERKMALE FÜR DIE INTEGRATIONSKONZEPTE BEWERTUNG DER KOMMUNIKATIONSPLATTFORMEN ANHAND DER TECHNOLOGIEMERKMALE OMA / CORBA COM / DCOM / COM EJB BEWERTUNG UND SCHLUSSFOLGERUNG LITERATUR iv

5 1 Einführung Der Trend zu steigenden Autmatisierungsgraden in den betrieblichen Infrmatinssystemen erfrdert Kpplungen vn Anwendungssystemen innerhalb und zwischen den Unternehmen. In den dabei entstehenden verteilten Anwendungssystemen sind die SftwareSysteme Netzwerke vn mehreren, im Allgemeinen unterschiedlichen Rechnersystemen und unterschiedlichen Betriebssystemen (hetergenes Netzwerk) [Mitr98]. Die Gestaltung und Verteilung der SftwareSysteme beruht zunehmend auf dem Paradigma der kmpnentenrientierten Sftwareentwicklung. Hierbei werden Anwendungssysteme aus unabhängigen binären Einheiten (Kmpnenten) zusammengesetzt, die miteinander interagieren, um die Aufgaben eines Anwendungssystems durchzuführen (vgl. z.b. [Grif98, 29ff.; Szyp98, iii]). Ziel der kmpnentenrientierten Sftwareentwicklung ist die Knstruktin fachlicher Anwendungssystemschichten, die weitgehend unabhängig vn systemtechnischen Schichten (Hardware, Betriebssysteme, Datenbankverwaltungssysteme, etc.) gestaltet sind [FSH97, 25]. Kmpnentenbasierte Anwendungssysteme benötigen hierfür geeignete systemtechnische Basismaschinen für die Kmmunikatin zwischen den Kmpnenten, die dem Bereich der Middleware zugerdnet werden [FSH97, 27]. Im Rahmen dieser Arbeit wird der Frage nachgegangen, inwieweit verschiedene Kmmunikatinsplattfrmen für die Entwicklung und Nutzung vn verteilten Anwendungssystemen geeignet sind. Da verteilte Anwendungssysteme immer auch eine Integratin vn Kmpnenten implizieren, erflgt eine Betrachtung der Integratinsptenziale der Plattfrmen anhand vn Integratinsmerkmalen und knzepten. 2 Methdischer Rahmen Der Gegenstand dieser Arbeit ist wie bereits ausgeführt die Untersuchung und anschließende Bewertung der Integratinsptenziale vn Kmmunikatinsplattfrmen für verteilte Anwendungssysteme. Um die Nachvllziehbarkeit des Vrgehens zu gewährleisten, wird der in Abbildung 1 dargestellte methdische Rahmen eingeführt. Dieser dient gleichermaßen Strukturierungs und Dkumentatinszwecken. Der Untersuchungsraum umfasst die Entwicklung eines verteilten Anwendungssystems als Gestaltungsaufgabe und wird entlang zweier Dimensinen aufgespannt. Die erste Dimensin differenziert zwischen der Anwendungsebene und der zugehörigen systemtechnischen Ebene. Die zweite Dimensin gliedert 1

6 den Untersuchungsraum in die Frmalziele der Gestaltungsaufgabe und in Knzepte zur Realisierung dieser Frmalziele im Entwicklungsprzess. Die Frmalziele bei der Gestaltung auf der Anwendungsebene werden als Integratinsziele bezeichnet und beziehen sich auf angestrebte Ausprägungen sgenannter Integratinsmerkmale. Unterschieden werden die Merkmale Redundanz, Verknüpfung, Knsistenz und Zielrientierung (siehe Abschnitt 3.1). Zur Realisierung dieser Frmalziele werden verschiedene Integratinsknzepte eingesetzt (siehe Abschnitt 3.2). Die vielfach genutzten Knzepte datenflussrientierte Funktinsintegratin, Datenintegratin und Objektintegratin erlauben bezüglich der genannten Frmalziele sehr unterschiedliche Zielerreichungsgrade [Fers92; Fe Si01, 220]. Dieser Zusammenhang wird durch Beziehung 1 beschrieben. Technlgiemerkmale, wie beispielsweise Kapselung, Implementierungsvererbung der Ortstransparenz, bilden Frmalziele bei der Gestaltung der systemtechnischen Ebene. Sie unterstützen die Erreichung der Frmalziele der fachlichen Ebene (Integratinsziele) in unterschiedlichem Ausmaß (Beziehung 2). Die Auswahl der Technlgiemerkmale wird zusätzlich vn dem verwendeten Integratinsknzept bestimmt, da vn ihm die Bedeutung einzelner Integratinsmerkmale und damit die Bedeutung der sie unterstützenden Technlgiemerkmale abhängt (Beziehung 3). Ebene Frmalziele Redundanz Verknüpfung Knsistenz Zielrientierung Realisierung der Frmalziele Datenflussrient. Funktinsintegratin Datenintegratin Objektintegratin Anwendungsebene Integratinsknzept Integratinsmerkmal (1) (2) (3) (5) Systemtechnische Ebene Technlgiemerkmal (4) Technlgische Plattfrm OMA / CORBA COM / DCOM / COM EJB Abbildung 1: Methdischer Rahmen 2

7 Am Markt verfügbare technlgische Plattfrmen setzen die Frmalziele der systemtechnischen Ebene in unterschiedlicher Weise um. Der Grad der Zielerfüllung ist Ergebnis dieser Umsetzung (Beziehung 4). Im weiteren Verlauf werden die MiddlewarePlattfrmen Object Management Architecture (OMA) / Cmmn Object Request Brker Architecture (CORBA), Cmpnent Object Mdel (COM), inklusive der Erweiterungen Distributed Cmpnent Object Mdel (DCOM) und COM, swie Enterprise JavaBeans (EJB) betrachtet. Diese Plattfrmen sind hinsichtlich ihrer Knzeptin am weitesten gereift und verfügen darüber hinaus über die größten Anteile im MiddlewareMarkt. Aus den Beziehung 1 bis 4 ergibt sich transitiv eine spezifische Eignung der betrachteten Plattfrmen zur Verflgung der verschiedenen Integratinsknzepte (Beziehung 5). 3 Integratinsmerkmale und knzepte 3.1 Integratinsmerkmale Die Aufgaben eines Infrmatinssystems werden im Rahmen der Aufgabenanalyse anhand mehrerer Kriterien, wie z.b. dem Objekt der Verrichtungsprinzip der nach den Phasen Planung, Durchführung und Kntrlle, zerlegt. Die Zerlegung vn Aufgaben resultiert in einer Abgrenzung vn Teilaufgabenbjekten und einer Zielzerlegung. Zur Realisierung der Gesamtaufgabe des Infrmatinssystems sind Leistungs und Kmmunikatinsbeziehungen zwischen den Teilaufgaben vrzusehen. Dem Gestaltungsprzess liegen selbst Frmalziele wie z.b. Nutzung vn Ähnlichkeiten zwischen Verrichtungen im Verrichtungsprinzip zugrunde. Spezielle Frmalziele nehmen auf die Beziehungen zwischen den Teilaufgaben Bezug. Sie werden als Integratinsziele bezeichnet [Fers92; FeSi01, 215f.]. Die Zielerreichung unterschiedlicher Aufgabenzerlegungen und Aufgabenträgerzurdnungen bezüglich dieser Integratinsziele bestimmt den Integratinsgrad der Aufgaben eines Anwendungssystems. Die Integratinsziele nehmen auf ausgewählte Struktur und Verhaltensmerkmale der fachlichen Ebene eines Anwendungssystems die Integratinsmerkmale Bezug und legen Zielausprägungen der Integratinsmerkmale fest (Abbildung 2) [Fers92]. Zu den die Systemstruktur des Anwendungssystems betreffenden Integratinsmerkmalen gehören die Redundanz der Systemkmpnenten (Datenstrukturen, Funktinen, Objekte, usw.) swie die Verknüpfung dieser Kmpnenten. Verhaltensbezgene Integratinsmerkmale 3

8 sind die Knsistenz und die Zielrientierung der Teilaufgaben in Bezug auf die Gesamtaufgabe [FeSi01, 217]. Die Merkmale können weiter wie flgt differenziert werden: Merkmalsgruppe Ziel: Einhaltung einer vrgegebenen Ausprägung des Merkmals... Struktur Redundanz Datenredundanz (DR) Funktinsredundanz (FR) Verknüpfung Kmmunikatinsstruktur (KS) Verhalten Knsistenz Semantische Integrität (SI) Operatinale Integrität (OI) Zielrientierung Vrgangssteuerung (VS) Abbildung 2: Integratinsmerkmale Redundanz Dieses Merkmal gibt an, inwieweit die einer bestimmten Systemfunktin dienenden Systemkmpnenten mehrfach vrhanden sind. Der Wegfall redundanter Kmpnenten beeinträchtigt im Nrmalfall die Funktinsfähigkeit eines Systems nicht, im Störfall dienen redundante Kmpnenten als Rückfallstufe. Argumente für die Vermeidung vn Redundanz sind mögliche Inknsistenzen zwischen redundanten Kmpnenten, die Ntwendigkeit der Prüfung und Krrektur vn Inknsistenzen, swie mangelnde Wirtschaftlichkeit der Ressurcennutzung. Für eine Erhaltung vn Redundanz spricht die mögliche Tleranz des Systems bei Ausfall vn Kmpnenten, mögliche Leistungssteigerungen des Systems durch parallele Nutzung redundanter Kmpnenten und eine mögliche Reduzierung der Strukturkmpleität des Systems durch die Verwendung vn Systemkmpnenten mit redundanten Merkmalen. Das Integratinsziel ist die Vermeidung ungeplanter Redundanz vn Kmpnenten [Fers92; FeSi01, 218]. Dabei wird zwischen Daten und Funktinsredundanz unterschieden. 4

9 Verknüpfung Das Merkmal Verknüpfung umfasst Art und Anzahl der Kmmunikatinskanäle zwischen den Systemkmpnenten. Der Bedarf an Kmmunikatin zwischen den Systemkmpnenten eines Anwendungssystems flgt aus dessen Aufgabenstellung. Kanäle eistieren in herkömmlichen Anwendungssystemen zwischen Funktinen und in bjektrientierten Anwendungssystemen zwischen Objekten. Die zur Verflgung der Gesamtaufgabe eines Infrmatinssystems erfrderliche Anzahl vn Kmmunikatinskanälen ergibt sich aus der Abgrenzung der Systemkmpnenten und deren Grad an Redundanz. Das Integratinsziel bezüglich der Verknüpfung ist die Bildung eines Kmmunikatinssystems, das (1) die Nachrichten zwischen den beteiligten Systemkmpnenten ausreichend schnell und sicher überträgt und (2) die Kmmunikatinsstruktur rbust bezüglich Störungen und Erweiterungen gestaltet [Fe Si01, 219]. Knsistenz Ein Anwendungssystem beinhaltet ein Mdell eines Ausschnitts der realen Welt und bildet z.b. Lagerbestände, Kntstände der Persnenmerkmale ab. Zustände des Mdellsystems, die keine Entsprechung in der Realität besitzen, werden ausgeschlssen und als inknsistent bezeichnet. Es werden zwei Frmen der Knsistenz unterschieden: 1. Semantische Integritätsbedingungen beschreiben, welche (Mdell) Systemzustände knsistent sind. Beispielsweise charakterisiert die Integritätsbedingung (Rechnungssumme = Summe der Rechnungspsitinsbeträge) in einem System mit den Datenbjekten Rechnungskpf und Rechnungspsitin krrekte Zustände dieser Datenbjekte. 2. Operatinale Integritätsbedingungen definieren in einem Anwendungssystem, das parallele Transaktinen erlaubt, Bedingungen für knsistente Systemzustände vr und nach der Durchführung vn Transaktinen. Die permanente Einhaltung der semantischen und peratinalen Integrität des gesamten Anwendungssystems stellt smit das Integratinsziel bezüglich der Knsistenz dar [FeSi01, 219f.]. 5

10 Die Knsistenz vn kmpnentenbasierten Anwendungssystemen wird vn den Knsistenzeigenschaften seiner Kmpnenten und vn der krrekten Knfiguratin des Gesamtsystems bestimmt. Einzelaspekte der Knsistenzsicherung in verteilten Systemen sind knsistente Datenhaltung, peratinale Integrität nebenläufiger Zustandsübergänge und glbaler Transaktinsschutz [FSH97, 26]. Zielrientierung Bei der sukzessiven Zerlegung der Gesamtaufgabe eines Anwendungssystems werden die Aufgabenbjekte und die Aufgabenziele zerlegt. Auf jeder Zerlegungsebene wird eine als Vrgangssteuerung bezeichnete Einrichtung benötigt, die zur Krdinatin der erzeugten Teilaufgaben dient. Das Integratinsziel bezüglich der Zielrientierung ist die Lenkung der Vrgänge eines Anwendungssystems, die eine Zielausrichtung aller Kmpnenten und Teilsysteme vrnimmt. Die Ntwendigkeit der Zielrientierung erwächst aus der Tatsache, dass ein integriertes Anwendungssystem aus Außensicht eine Gesamtaufgabe unterstützt [FeSi01, 220]. 3.2 Integratinsknzepte Die Aufgaben eines Anwendungssystems sind das Ergebnis einer MetaGestaltungsaufgabe, die als Autmatisierungs und Integratinsaufgabe bezeichnet wird [Fers92]. Das Aufgabenbjekt dieser Gestaltungsaufgabe sind die zu integrierenden Aufgaben des Anwendungssystems. Sachziel der Gestaltungsaufgabe ist die Autmatisierung der Aufgaben unter Beachtung der im vrherigen Abschnitt beschriebenen Integratinsziele. Für die Durchführung der Gestaltungsaufgabe stehen unterschiedlichste Methden zur Verfügung. Die der Umsetzung der Integratinsziele dienenden Methden werden als Integratinsknzepte bezeichnet. Häufig genutzte Integratinsknzepte sind die Funktinsintegratin, die Datenintegratin und die Objektintegratin. Sie erreichen bezüglich der Integratinsziele sehr unterschiedliche Zielerreichungsgrade und werden im Flgenden kurz vrgestellt [Fers92, FeSi01, 221ff.]. Bei der Bewertung der Integratinsknzepte hinsichtlich der verflgten Integratinsziele werden die Integratinsmerkmale semantische und peratinale Integrität gemeinsam betrachtet, da sie bei allen betrachteten Integratinsknzepten den gleichen Zielerreichungsgrad aufweisen. 6

11 Datenflussrientierte Funktinsintegratin Bei der datenflussrientierten Funktinsintegratin tauschen Kmpnenten Datenflüsse, im Allgemeinen hne Bezug auf die vm Anwendungssystem durchzuführenden Transaktinen, aus. Das Anwendungssystem wird als ein Netzwerk vn Teilsystemen betrachtet, die jeweils aus Datenspeichern für die Erfassung vn Aufgabenbjekten, swie Funktinen für die Realisierung der Aufgabenverrichtungen bestehen (Abbildung 3). Auftragsbearbeitung Datenspeicher I VS DR Kstenrechung Finanzbuchführung KS FR Datenspeicher Kmmunikatin Funktinen Daten Datenspeicher Integratinsmerkmal: DR = Datenredundanz FR = Funktinsredundanz KS = Kmmunikatinsstruktur der Kmpnenten I = Integrität der Systemzustände VS = Vrgangssteuerung Ausprägung des Integratinsmerkmals: Merkmal wird unterstützt 0 Merkmal wird bedingt unterstützt Merkmal wird nicht unterstützt Abbildung 3: Datenflussrientierte Funktinsintegratin Die datenflussrientierte Funktinsintegratin wurde hauptsächlich in den 60er und 70er Jahren eingesetzt, um bestehende Autmatinsinseln zu verbinden und Kmmunikatinskanäle unter Vermeidung vn Medienbrüchen zu autmatisieren. Es wird primär das Integratinsziel bezüglich der Kmmunikatinsstruktur verflgt (Abbildung 3). Datenintegratin Dieses Integratinsknzept wurde mit der Einführung vn Datenbanksystemen und MehrplatzDialgsystemen in den 70er und 80er Jahren einsetzbar. Gemäß dem Knzept der Datenintegratin perieren Funktinen über einer als eterne Sicht (View) bezeichneten Teilmenge eines knzeptuellen Datenschemas. Das knzeptuelle Datenschema und die eternen Sichten dienen dabei swhl der Erfassung vn Aufgabenbjekten als auch der Kmmunika 7

12 tin zwischen Funktinen (Abbildung 4). Diese Kmmunikatin über eterne Sichten resultiert daher in einer engen Kpplung der Funktinen untereinander. KRe FiBu AufBe LGe Bu BDE I VS DR View View View View View KS FR Knzeptuelles Datenschema Kmmunikatin Funktinen Daten Integratinsmerkmal: DR = Datenredundanz FR = Funktinsredundanz KS = Kmmunikatinsstruktur der Kmpnenten I = Integrität der Systemzustände VS = Vrgangssteuerung Ausprägung des Integratinsmerkmals: Merkmal wird unterstützt 0 Merkmal wird bedingt unterstützt Merkmal wird nicht unterstützt Abbildung 4: Datenintegratin Die Datenintegratin ist auf die Integratinsziele Optimierung der Datenredundanz und Erhaltung der Integrität ausgerichtet (Abbildung 4). Die Datenredundanz wird anhand vn Methden der Datenmdellierung gestaltet. Die Erhaltung der semantischen Integrität wird anhand eplizit definierter semantischer Integritätsbedingungen überwacht. Die Einhaltung der peratinalen Integrität ist Gegenstand der Transaktinsverwaltung des zugrunde liegenden Datenbankverwaltungssystems (DBVS). Die Zielerreichung bezüglich der weiteren Integratinsziele wird nicht methdisch unterstützt. Insbesndere sind aufgrund der engen Kpplung der Funktinen kmplee m:nkmmunikatinsbeziehungen zwischen den Funktinen möglich. Die Kmmunikatinsstruktur ist daher kaum kntrllierbar und flglich häufig die Ursache vn fehlerhaftem Systemverhalten. Objektintegratin Ein Anwendungssystem kann bjektrientiert aus knzeptuellen Objekten und Vrgangsbjekten zusammengesetzt werden. Knzeptuelle Objekte und Vrgangsbjekte sind untereinander lse gekppelt und tauschen Nachrichten über Kmmunikatinskanäle aus (Abbildung 8

13 5). Knzeptuelle Objekte erfassen und manipulieren in ihrem internen Speicher Zustände der realen Welt, d.h. sie bilden ein Mdell des betrachteten Ausschnitts der realen Welt. Die öffentlichen Methden der knzeptuellen Objekte führen Zustandsübergänge des knzeptuellen Objekts bzw. des Mdellsystems durch und realisieren Aktinen auf dem Aufgabenbjekt, das ein knzeptuelles Objekt repräsentiert. Vrgangsbjekte führen Aufgaben durch, indem sie Aktinen auf ihrem jeweiligen Aufgabenbjekt mittels der öffentlichen Methden vn knzeptuellen Objekten ausführen. Vrgangsbjekt Vrgang in KRe Vrgang in FiBu Vrgang in AufBe Vrgang in LGe Bu Vrgang in BDE I VS DR Glbales Kmmunikatinssystem KS FR Knzeptuelles Objekt Kunde Kmmunikatin Funktinen Daten Auftrag Knt KST Integratinsmerkmal: DR = Datenredundanz FR = Funktinsredundanz KS = Kmmunikatinsstruktur der Kmpnenten I = Integrität der Systemzustände VS = Vrgangssteuerung Ausprägung des Integratinsmerkmals: Merkmal wird unterstützt 0 Merkmal wird bedingt unterstützt Merkmal wird nicht unterstützt Abbildung 5: Objektintegratin Bezüglich der Datensicht krrespndiert der Verbund der knzeptuellen Objekte eines Anwendungssystems weitgehend mit einem knzeptuellen Datenschema. Die Zielerreichungsgrade bezüglich der Integratinsziele Datenredundanz und Integrität sind daher vergleichbar. Zur Sicherung der semantischen Integrität wird die Kmmunikatin mit Hilfe vn Nachrichten genutzt. Die Objektintegratin erlaubt darüber hinaus auch die Kntrlle des Integratinsmerkmals Funktinsredundanz, das die mehrfache Realisierung vn Funktinen erfasst. Deren Vermeidung dient das Knzept der Generalisierung vn Funktinen und der Nutzung vn Vererbungsbeziehungen. Die Kmmunikatin aller Objekte erflgt über ein eigenes Kmmunikatinssystem, s dass die Kntrlle der Kmmunikatinsstruktur des Anwendungssystems möglich ist. 9

14 4 Kmmunikatinsplattfrmen für kmpnentenbasierte Anwendungssysteme Im Flgenden werden ausgewählte Kmmunikatinsplattfrmen für verteilte Anwendungssysteme anhand ihrer Architektur, swie anhand spezieller Merkmale beschrieben und erläutert. Bei der Auswahl der Plattfrmen wurden die Kriterien Verfügbarkeit der Technlgie, Stand der Standardisierung und Herstellerptenzial herangezgen. Diese Kriterien führen zur Auswahl der flgenden Plattfrmen: Object Management Architecture (OMA) und Cmmn Object Request Brker Architecture (CORBA) der Object Management Grup (OMG) Cmpnent Object Mdel (COM), inklusive der Erweiterungen Distributed Cmpnent Object Mdel (DCOM) und COM vn Micrsft Enterprise JavaBeans (EJB) vn Sun Zwischen CORBA bzw. der OMA und der EJBPlattfrm sind Annäherungen z.b. beim Kmpnentenmdell (CORBA Cmpnent Mdel (CCM), [vgl. Stal00]), bei der Standardisierung des Transaktinsdienstes beider Plattfrmen swie der Interperabilität vn Enterprise JavaBeans mit CORBAClients festzustellen. Micrsft dagegen verflgt mit COM ein anderes Knzept, s dass sich eine Plarisierung zwischen Micrsft auf der einen Seite und den beiden anderen Plattfrmen auf der anderen Seite abzeichnet. Neben diesen drei Kmmunikatinsplattfrmen eistieren weitere Ansätze, die in diese Arbeit nicht mit einbezgen werden. Zu nennen sind hier z.b. die.netinitiative vn Micrsft [Micr00a] der spezielle ReflectiveMiddlewareAnsätze [OV00]. Diese Plattfrmen stehen erst am Anfang ihrer Entwicklung, bieten aber interessante Anknüpfungspunkte für zukünftige Betrachtungen. 4.1 OMA / CORBA Die Cmmn Object Request Brker Architecture (CORBA) ist ein Standard der Object Management Grup (OMG), einer NnPrfitOrganisatin mit derzeit über 800 Mitgliedsfirmen. Ziel der OMG ist es, einen ffenen Standard für eine bjektrientierte Middleware Plattfrm zu schaffen [OMG99]. Die OMG spezifiziert hierzu eine Object Management Ar 10

15 chitecture (OMA), swie einen Standard für Object Request Brker (ORB) als Kern. Eine OMA besteht aus den flgenden Kmpnenten (vgl. Abbildung 6) [OMG97; TaKa98]: Object Request Brker leiten Dienstaufrufe vn einem aufrufenden Objekt zu einem den Dienst ausführenden Objekt und liefern das Ergebnis der Ausführung zurück. Sie srgen smit für eine transparente Kmmunikatin lse gekppelter Objekte in verteilten Anwendungssystemen. Ein CORBAObjekt ist eine virtuelle, anhand einer Objektreferenz i dentifizierbare Entität, die einen der mehrere Dienste für Clients anbietet und verschiedene Zustände annehmen kann. [ScVi97, 1]. CORBAObjekte stellen selbst keine Implementierung ihrer Dienste zur Verfügung, sndern deklarieren ausschließlich einen Dienst. Die eigentliche Dienstausführung übernehmen sgenannte Object Implementatins der Servants, die vm ORB an eine Objektreferenz bzw. ein CORBAObjekt gebunden werden. CORBAServices stellen allgemeine, d.h. dmänenunabhängige Dienste der Objektverwaltung dar. Sie beinhalten u.a. Dienste zur Transaktinsverwaltung, zur persistenten Speicherung vn Objektzuständen und LifecycleDienste, die das Erzeugen, Kpieren der Löschen vn Objekten ermöglichen. CORBAFacilities sind Biblitheken vrdefinierter Objekte, die einen Teil der Funktinalität eines Anwendungssystems abdecken. Man unterscheidet hrizntale Facilities, bei denen es sich um dmänenunabhängige Objektklassen, wie beispielsweise Druckdienste der graphische Nutzerberflächen handelt, und vertikale Facilities, die Objektklassen für bestimmte Dmänen, wie Finanzdienstleistungen der ECmmerce beinhalten. Applicatin Objects sind nicht Teil der Standardisierungsbemühungen der OMG. Sie stellen anwendungsspezifische Objekte dar, die die Funktinen eines verteilten Anwendungssystems mittels der zuvr genannten Dienste realisieren. 11

16 Applicatin Objects CORBAFacilities Object Request Brker (ORB) CORBAServices Abbildung 6: Object Management Architecture (OMA) (vgl. [OMG97]) CORBA stellt eine Spezifikatin für einen ORB innerhalb der OMA dar. Abbildung 7 zeigt die CORBAArchitektur. Kernstück ist der eigentliche Object Request Brker (ORB Cre), der Basisdienste für die Kmmunikatin vn Objekten bereitstellt [Sequ99a]. Die Kmmunikatin zwischen zwei Objekten flgt dem Client/ServerPrinzip, wbei zwei alternative Frmen der Kmmunikatin unterstützt werden [FeSi01, S. 400f]: Bei Nutzung der statischen Kmmunikatinsschnittstelle kmmunizieren Client und ServerObjekte über CORBAObjektspezifische, unveränderliche Schnittstellen. Die Clientseitige statische Schnittstelle eines CORBAObjekts bzw. genauer deren Implementierung wird als Stub, die Serverseitige als Skeletn bezeichnet. Das StubObjekt bietet aus Sicht des Clients die Dienste des CORBAObjekts an und leitet Dienstaufrufe über den ORΒ an die Implementierung des CORBAObjekts (Servant) weiter. Das SkeletnObjekt nimmt im statischen Fall diese Dienstanfrderung für den Servant vm ORB entgegen und übermittelt dessen Resultat an den ORB. Stub und Skeletn werden in der Regel autmatisch aus der Schnittstellenbeschreibung des ServerObjekts erstellt, die in der Interface Definitin Language (IDL) abgefasst ist. Clients, die die statische Schnittstelle verwenden, können nur Dienste vn ServerObjekten nutzen, vn denen ihnen zur Build Time ein entsprechender Stub zur Verfügung steht. Bei Nutzung der dynamischen Kmmunikatinsschnittstelle wird Server der Clientseitig zur Laufzeit über das Dynamic Skeletn Interface (DSI) bzw. das Dynamic Invcatin Interface (DII) auf generische Weise ein Dienstaufruf erzeugt. Dabei werden die An 12

17 rdnung und Typisierung der Aufrufparameter erst zur Laufzeit festgelegt. Die hierfür nötigen Infrmatinen sind z.b. in einem Interface Repsitry hinterlegt, das über das ORB Interface zur Verfügung steht. Client Object Implementatin Dynamic Invcatin IDL Stubs ORB Interface Static IDL Skeletn Dynamic Skeletn Objekt Adapter ORB Cre Interface identical fr all ORB implementatins There may be multiple bject adapters There are stubs and a skeletn fr each bject type ORBdependent interface Upcall interface Nrmalcall interface Abbildung 7: Cmmn Object Request Brker Architecture (CORBA) [OMG99] In beiden Fällen srgt ein Object Adapter für die Verbindung zwischen einer Object Implementatin (Servant), die das Verhalten eines CORBAObjekts realisiert, und dem ORB. Der Object Adapter leitet die Dienstanfrderung anhand der Objektreferenz an die Object Implementatin weiter und stellt darüber hinaus Dienste für die Aktivierung und Deaktivierung vn Objekten, swie zur Verwaltung vn Objektreferenzen der zur Bindung vn Object Implementatins an Objekte zur Verfügung [ScVi97]. Zur Zeit sind der Basic Object Adapter (BOA), swie der mächtigere und fleiblere Prtable Object Adapter (POA) vn der OMG standardisiert. 4.2 COM / DCOM / COM Das Cmpnent Object Mdel (COM) stellt einen Standard für die Interperabilität vn Kmpnenten bereit, der es Clients erlaubt, Dienste vn Objekten, die dem COMStandard entsprechen (sgenannte COMObjekte), anzufrdern. Die Dienste, die ein COMObjekt bereithält, werden über Schnittstellen nach außen bekannt gemacht. Schnittstellen bündeln l 13

18 gisch zusammengehörende Methden [Kirt98a]. Clients können nur über diese Schnittstellen auf die Methden eines Servers bzw. COMObjekts zugreifen. Objekte und Schnittstellen werden mittels der Micrsft Interface Definitin Language (MIDL) spezifiziert. Um Namenskllisinen zu vermeiden, benötigt jedes Objekt und jede Schnittstelle eine Identifikatinsnummer (Glbal Unique Identifier GUID) [SKHB97; SEI00]. Die Schnittstellen eines COMObjekts sind nicht veränderlich, d.h. nachdem eine Schnittstelle definiert ist, dürfen keine Methden hinzugefügt, gelöscht der geändert werden [Wi Ki94; TEG97; ThWa97]. Sll eine Kmpnente neue Funktinalität bereitstellen, s muss diese über ein neues Interface zur Verfügung gestellt werden. Jedes COMObjekt läuft innerhalb eines COMServers (auch als COMCntainer bezeichnet) ab, wbei ein Server mehrere Objekte beinhalten kann. Abbildung 8 zeigt, wie ein Client auf drei verschiedene Arten auf ein COMObjekt zugreifen kann [WiKi94; Micr96; Mal97; SEI00]: 1. InPrcess Server: Client und Server sind Teil desselben Przesses. Die Kmmunikatin erflgt direkt über einen Methdenaufruf. 2. Lcal Object Pry: Client und Server gehören zu unterschiedlichen Przessen innerhalb eines Rechners. Die InterPrzessKmmunikatin erflgt hierbei über einen Lightweight Remte Prcedure Call (LRPC). 3. Remte Object Pry: Client und Server gehören zu unterschiedlichen Przessen, die sich auf verschiedenen Rechnern befinden. Die Netzwerkkmmunikatin erflgt über einen Remte Prcedure Call (RPC). Dieser Mechanismus für den Zugriff auf entfernte Server wird im Distributed Cmpnent Object Mdel (DCOM), einer Erweiterung zu COM, spezifiziert. Falls Client und Server sich in unterschiedlichen Adressräumen befinden (Zugriffsart 2 und 3), s müssen Methdenaufrufe und Parameter übersetzt werden (Marshaling) [HKi97]. Dies wird vm COMSystem mittels eines PryObjekts auf der ClientSeite und eines Stub Objekts auf der ServerSeite durchgeführt und geschieht für den Client transparent [WiKi94]. 14

19 InPrcess Object Stub Lcal Object Client Applicatin InPrcess Server RPC COM Lcal Server Lcal Server Prcess Lcal Object Pry Remte Machine Client Prcess Remte Object Pry COM RPC Stub COM Remte Server Prcess Remte Object Remte Server Abbildung 8: (Distributed) Cmpnent Object Mdel (vgl. [WiKi94]) COM ist eine Erweiterung vn DCOM und kann als Verschmelzung vn DCOM mit dem Micrsft Transactin Server (MTS) verstanden werden. Innerhalb des MTS können COM Objekte im Kntet einer Transaktin zusammenarbeiten. Im Fehlerfall srgt der MTS für die Wiederherstellung vn Objektzuständen [Stal00]. Darüber hinaus beinhaltet COM eine Reihe neuer Basisdienste, wie beispielsweise [Kirt97a; Kirt98b; Kirt98c; Clev00]: Transaktinsunterstützung: Durch die Eingliederung des MTS können auf COM basierende Anwendungssysteme die Funktinen eines Transactin Prcessing (TP) Mnitrs nutzen. Lastverteilung: In COM erflgt eine Lastverteilung, indem Anfragen zur Objekterzeugung zunächst an einen zentralen Server, den sgenannten Cmpnent Library Balancing (CLB) Server, gesendet werden. Dieser Server überwacht die Last der zur Verfügung stehenden COMServer und leitet die Anfrage an einen geeigneten Server weiter. Object Pling: Object Pling ermöglicht es, dass beim Start eines Anwendungssystems eine bestimmte Anzahl vn COMObjekten erzeugt wird, die dann entsprechend der Anfrderungen während des Betriebs "wiederverwendet" werden können. Dieser Pl an Objekten kann durch Angabe vn Unter und Obergrenzen knfiguriert werden. Object 15

20 Pling kann den Aufwand für die Erzeugung und Löschung vn Objekten reduzieren und wirkt sich s psitiv auf die Perfrmanz des Anwendungssystems aus. Queued Cmpnents: Diese unterstützen transaktinsgestützte, asynchrne Kmmunikatin mit Hilfe vn Warteschlangen. Verbesserte Sicherheitsmechanismen: COM übernimmt und erweitert das rllenbasierte Sicherheitsknzept des MTS. InMemry Database (IMDB): IMDB dient Kmpnenten, die einen sehr schnellen Lesezugriff auf Daten benötigten. Um diesen zu realisieren, werden anhand vn Knfiguratinseinstellungen Datenbanktabellen präventiv in den Arbeitsspeicher geladen. 4.3 EJB Die EnterpriseJavaBeans (EJB)Architektur ermöglicht wiederverwendbare, rbuste und skalierbare ServerBausteine. Eine Enterprise Bean ist eine spezialisierte JavaKmpnente, die innerhalb eines EJBServers ausgeführt wird. Der EJBServer stellt den Enterprise Beans Dienste über die Zwischenschaltung eines EJBCntainers zur Laufzeit zur Verfügung (Abbildung 9) [Baue98]. Ein EJBCntainer ist für die Erzeugung, Aktivierung, Deaktivierung und Löschung vn Enterprise JavaBeans verantwrtlich (Life Cycle Management). Darüber hinaus erfüllt er weitere Aufgaben wie Transaktinsverwaltung, Sicherheitsdienste der PersistenzManagement [Pur99a; Pur99b]. Die EJBSpezifikatin umfasst zwei Arten vn Enterprise Beans [Baue98; Thm98; Pur99a; RÖb99b; Zna99; Stal00]: Sessin Beans: Eine Sessin Bean ist ein nur im Verlauf einer einzigen Client/Server Sessin identifizierbares Objekt, das als Instanz nur für die Dauer dieser Sessin eistiert. Sessin Beans können smit genau einem Client zugerdnet werden. Sie können ptinal transaktinsgestützt ablaufen. Im Falle eines Serverabsturzes kann die Instanz einer Sessin Bean nicht wiederhergestellt werden. Es können weiterhin Stateless Sessin Beans und Stateful Sessin Beans unterschieden werden. Stateful Sessin Beans können unterschiedliche Zustände annehmen und verfügen deshalb über eine eindeutige Identität. Stateless Sessin Beans weisen dagegen nur einen einzigen Zustand auf. Verschiedene In 16

21 stanzen (Sessin Objects) einer Stateless Sessin Bean innerhalb eines Cntainers unterscheiden sich daher nicht in ihrem Object Identifier. Entity Beans: Eine Entity Bean repräsentiert aus Sicht der Clients ein bjektrientiertes Mdell der realen Welt, das z.b. mittels einer Datenbank verwaltet wird. Mehrere Clients können knkurrierend auf eine Entity Bean zugreifen. Jede Instanz einer Entity Bean (Entity Object) besitzt eine eindeutige Objektidentität. Zugriffe auf Entity Beans laufen in der Regel unter Transaktinsschutz ab. Transaktinen können vn einer Bean angestßen werden (Beanmanaged Transactins) der vm Cntainer (Cntainermanaged Transactins). EJB Server Client Client Web Server Sessin Hme Sessin Remte EJB Cntainer Sessin Bean Client Client Servlets, JSP Pages HTML, XML Entity Hme Entity Remte EJB Cntainer Entity Bean Daten Server Abbildung 9: Enterprise JavaBeans Zugriffe auf Enterprise Beans swie deren Verwaltung erflgen über zwei Schnittstellen [Thm98; Pur99a; RÖb99b]. Hme Interfaces dienen der Verwaltung, Remte Interfaces dem Zugriff auf die Methden vn Enterprise Beans. Hme Interface: Ein Client ruft über das Hme Interface Dienste zum Erzeugen und Löschen vn Enterprise Beans auf. Bei Entity Beans stehen zusätzlich eine der mehrere Methden zur Suche nach BeanInstanzen zur Verfügung (sgenannte Finder Methds). Diese nutzen den Primärschlüssel der Entity Beans. Remte Interface: Das Remte Interface spezifiziert die Methden, die eine Enterprise Bean zur Verfügung stellt. Es enthält sämtliche Methden der öffentliche Schnittstellen 17

22 einer Enterprise Bean, die ein Client aufrufen kann, und repräsentiert die Sicht eines Clients auf eine EJBKmpnente. Die Clients greifen meist nicht direkt auf die Schnittstellen einer Enterprise Bean zu, sndern indirekt über Servlets, JSPPages der HTML/XMLSeiten, die sich auf einem WebServer befinden. 5 Unterstützung vn Integratinszielen und Integratinsknzepten durch Kmmunikatinsplattfrmen Gegenstand dieses Kapitels ist die Analyse vn Integratinsptenzialen der Kmmunikatinsplattfrmen OMA / CORBA, COM / DCOM / COM und EJB. Mit Bezug zu dem in Abbildung 1 eingeführten methdischen Rahmen wird flgendes Vrgehen gewählt: Zunächst werden in Abschnitt 5.1 Technlgiemerkmale ausgewählt, die grundsätzlich geeignet sind, Integratinsmerkmale bzw. Integratinsknzepte zu unterstützen. In Abschnitt 5.2 wird untersucht, welche Integratinsmerkmale (siehe Abschnitt 3.1) durch die einzelnen Technlgiemerkmale unterstützt werden (Beziehung 2 des methdischen Rahmens). Die in Abschnitt 3.2 eingeführten Integratinsknzepte sind durch unterschiedliche Ausprägungen der einzelnen Integratinsmerkmale gekennzeichnet. In Abschnitt 5.3 wird daher die Unterstützung der verschiedenen Integratinsknzepte durch die einzelnen Technlgiemerkmale untersucht (Beziehung 3). Dabei werden die Nutzung vn Integratinsmerkmalen in einem Integratinsknzept und die Nutzbarkeit eines Technlgiemerkmals für die Realisierung eines Integratinsmerkmals in einem Integratinsknzept berücksichtigt. In Abschnitt 5.4 erflgt eine Bewertung der drei ausgewählten Kmmunikatinsplattfrmen bezüglich der Technlgiemerkmale (Beziehung 4). Die Ausführungen in Kapitel 5 bilden die Grundlage für die abschließende Bewertung der Unterstützung vn Integratinsknzepten durch die einzelnen Kmmunikatinsplattfrmen (Beziehung 5) in Kapitel 6. 18

23 5.1 Technlgiemerkmale Zur Bestimmung der für die Unterstützung vn Integratinsmerkmalen bzw. Integratinsknzepten relevanten Technlgiemerkmale vn Kmmunikatinsplattfrmen wird das ADK Mdell verwendet. Das ADKMdell [FeSi01, 289f.] gliedert ein Anwendungssystem in die Teilsysteme Anwendungsfunktinen (A), Datenverwaltung (D) und Kmmunikatin (K). Letzteres Teilsystem wird weiter in die Bereiche Kmmunikatin mit Persnen (K P ) und Kmmunikatin mit weiteren maschinellen Systemen (K M ) zerlegt. Die Kmmunikatin mit Persnen wird vn den betrachteten Kmmunikatinsplattfrmen nicht unterstützt. Für die eterne Kmmunikatin mit weiteren maschinellen Systemen werden grundsätzlich die gleichen Kmmunikatinsmechanismen wie für die interne Kmmunikatin genutzt. Im Flgenden stehen daher die kmpnentenrientierte Gestaltung des A und des DTeils swie die Kmmunikatin zwischen diesen Kmpnenten im Vrdergrund. Gemeinsame Merkmale der betrachteten Plattfrmen sind die transparente Kmmunikatin vn Kmpnenten über einen Object Request Brker (ORB), swie der Einsatz bjektrientierter Knzepte innerhalb der Kmpnenten. Kmpnenten werden daher aus Außensicht als Objekte betrachtet, die durch Name, Attribute und Operatren bestimmt sind. Aufbauend auf diesen Merkmalen werden im Flgenden Architekturen für datenfluss (Abbildung 10), daten (Abbildung 11) und bjektintegrierte (Abbildung 12) kmpnentenbasierte Anwendungssysteme entwickelt. Hierbei handelt es sich um technische Realisierungsfrmen der fachlichen Integratinsknzepte auf Basis vn kmpnentenbasierten Kmmunikatinsplattfrmen für verteilte Anwendungssysteme. Bei der klassischen Darstellung der Integratinsknzepte in Abschnitt 3.2 werden unter anderem die Teilbereiche Funktinen, Daten und Kmmunikatin unterschieden. In der hier vertretenen kmpnentenrientierten Sichtweise werden Daten mit Attributen vn Kmpnenten und Funktinen mit Operatren vn Kmpnenten assziiert. Die Kmmunikatin zwischen den Kmpnenten erflgt unter Nutzung des ORB der Kmmunikatinsplattfrm. 19

24 ATeil DTeil Name Op. Attr. Funktinen Daten Name Op. Attr. ORB Abbildung 10: Datenflussintegriertes kmpnentenbasiertes Anwendungssystem Bei der datenflussrientierten Funktinsintegratin erflgt die Kperatin bzw. Kmmunikatin zwischen Teilsystemen über Datenflüsse. Jede Kmpnente realisiert die Aufgabenverrichtung anhand vn Funktinen, die auf dem jeweiligen Aufgabenbjekt perieren. Die Aufgabenbjekte der verschiedenen Kmpnenten überlappen sich dabei nicht. Die Datenflüsse werden bei einer Realisierung der datenflussrientierten Funktinsintegratin auf Basis vn ORBs durch Methdenaufrufe über den ORB realisiert (Abbildung 10). Da der Austausch der Datenflüsse im Allgemein nicht transaktinsbezgen erflgt, werden transaktinsspezifische Eigenschaften des ORB nicht unbedingt benötigt. ATeil DTeil Name Op. Attr. Name Op. Attr. DBEngine Op. Attr. PryObjekt für Zugriff auf Datenbasis Funktinen Daten ORB Abbildung 11: Datenintegriertes kmpnentenbasiertes Anwendungssystem Bei einem datenintegrierten kmpnentenbasierten Anwendungssystem perieren alle Kmpnenten auf einem gemeinsamen Aufgabenbjekt. Die Kmpnenten kmmunizieren nicht direkt miteinander, sndern nur über die das Aufgabenbjekt repräsentierende, gemeinsame Datenbasis. Der Zugriff auf die Datenbasis erflgt bei Nutzung vn ORBs über eine Database 20

25 Engine, die als ORBObjekt ihren Datenverwaltungsdienst anbietet. Beispielsweise kann die JDBCSchnittstelle in eine CORBASchnittstelle übersetzt werden. Die Database Engine verwaltet die Repräsentatin des Aufgabenbjekts des verteilten Systems. Aus Sicht des ORB stellt sie eine Kmpnente des verteilten Anwendungssystems dar. Abbildung 11 zeigt die Architektur eines slchen datenintegrierten kmpnentenbasierten Anwendungssystems. Lesende der schreibende Zugriffe einer Kmpnente des ATeils auf die Datenbasis erflgen über den Aufruf eines entsprechenden Operatrs der Database Engine. Diese liest die gewünschten Daten aus der Datenbasis und übergibt sie an die beauftragende Kmpnente. ATeil DTeil VOS KOS Name Op. Name Op. Attr. Funktinen Name Op. Name Op. Attr. Daten ORB Abbildung 12: Objektintegriertes kmpnentenbasiertes Anwendungssystem Ein bjektintegriertes kmpnentenbasiertes Anwendungssystem besteht aus knzeptuellen Objekten und Vrgangsbjekten. Die knzeptuellen Objekte sind Teil des knzeptuellen Objektschemas (KOS), die Vrgangsbjekte Teil des Vrgangsbjektschemas (VOS). Vrgangsbjekte führen Aufgaben in Frm vn Vrgängen durch und rufen dafür über den ORB Methden der knzeptuellen Objekte auf. Ein Vrgang besteht aus der Durchführung mehrerer Aktinen auf dem Aufgabenbjekt der Aufgabe, wbei die Vrgangsbjekte die Aktinensteuerung übernehmen, während die knzeptuellen Objekte die Aktinen durch ihre Operatren realisieren. Ein knzeptuelles Objekt ist swhl dem A, als auch dem DTeil zuzurdnen. Ein Vrgangsbjekt gehört ausschließlich dem ATeil eines Anwendungssystems an. Die Kmmunikatin zwischen Vrgangsbjekten realisiert den Wrkflw im Rahmen der Aufgabendurchführung. Die Kmmunikatin zwischen knzeptuellen Objekten dient der Erfüllung vn semantischen Integritätsbedingungen, die sich über mehrere knzeptuelle Objekte erstrecken. 21

26 Die vrgestellten kmpnentenbasierten Architekturen zur Realisierung der verschiedenen Integratinsknzepte dienen nun als Rahmen, um den Katalg an Technlgiemerkmalen zu entwickeln. Es lassen sich dabei Struktur und Verhaltensmerkmale unterscheiden. Strukturmerkmale krrespndieren mit den Eigenschaften der kmmunizierenden Kmpnenten, swie mit deren Gestaltungsprinzipien. Verhaltensmerkmale lassen sich anhand der Kmmunikatin zwischen den Kmpnenten ableiten. Hier sind insbesndere Aspekte der Transparenz und des Kmmunikatinsablaufs vn Interesse. Strukturmerkmale: Kapselung: Das Merkmal der Kapselung beschreibt die Zusammenfassung vn Attributen und Methden eines Objekttyps in einer Kapsel, über die nach außen nur Namen und Wirkung der Methden bekannt sind. Die Datenstrukturen der Attribute und die Implementierung des Verhaltens werden nicht preisgegeben (vgl. das Knzept des Abstrakten Datentyps) [FeSi01, 300]. Die verfügbaren Dienste werden der Außenwelt durch eine zugehörige Schnittstelle bekannt gemacht. Nutzung der Dienste und Zugriff auf Attribute des Objekttyps sind ausschließlich durch den Aufruf vn öffentlichen Methden der Schnittstelle möglich. Gegebenenfalls vrhandene private Methden sind nach außen nicht sichtbar und können nur innerhalb der Kapsel verwendet werden [Heue92, 195]. Schnittstellenvererbung: Die Schnittstelle eines Objekttyps publiziert die vn ihm angebtenen Dienste (Methden) und beschreibt damit dessen Verhalten. Zusätzlich können Integritätsbedingungen spezifiziert werden, die das zulässige Verhalten des Objekttyps einschränken. Vn einer Schnittstelle können durch Vererbung neue Schnittstellen abgeleitet werden, die Spezialisierungen dieser Schnittstelle darstellen. Eine spezialisierte Schnittstelle übernimmt die Methdendeklaratinen und Integritätsbedingungen der allgemeineren Schnittstelle und ergänzt diese um spezifische Verhaltenseigenschaften. Eine abgeleitete Schnittstelle bietet mindestens die Dienste ihrer Vrgängerschnittstelle an [Heue92, 204f.]. Hat eine Schnittstelle genau einen Vrgänger, spricht man vn einfacher Vererbung, hat sie mehrere vn mehrfacher Vererbung. Implementierungsvererbung: Analg zu Schnittstellen, die die Außensicht eines Objekttyps beschreiben, lässt sich auch deren Implementierung (Innensicht) vererben. Hierbei wird die Realisierung der Attribute und Methden des Vererbungsvrgängers über 22

27 nmmen. Bei Bedarf kann die Implementierung einer geerbten Methde den spezifischen Anfrderungen angepasst der vllständig überschrieben werden (Plymrphismus). Die durch Schnittstellen und Implementierungsvererbung resultierenden Hierarchien müssen sich aufgrund der strikten Trennung vn Außen und Innensicht keineswegs entsprechen [Heue92, 205f.]. Auch bei der Implementierungsvererbung unterscheidet man, je nach Anzahl der Vrgänger eines erbenden Objekttyps, zwischen einfacher und mehrfacher Vererbung [FeSi01, ]. Trennung vn przess und ressurcenspezifischen Objekten: Die betrieblichen Aufgaben, die ein Anwendungssystem realisiert, werden in Frm vn Vrgängen durchgeführt. Ein Vrgang besteht aus einer Flge vn Aktinen, die durch Ereignisse miteinander verknüpft sind [FeSi01, 5457]. In einem bjektrientiert realisierten Anwendungssystem entspricht jede Aktin dem Aufruf einer Methde eines Objekts. Ein Vrgang beschreibt demnach das Zusammenwirken mehrerer Objekte bei der Durchführung einer Aufgabe aus Ablaufsicht. Auf der Grundlage dieser Darstellung lassen sich die Objekte eines Anwendungssystems differenzieren in (1) ressurcenspezifische Objekte zur Verwaltung vn Datenbjekten und anderen Ressurcen swie zur Durchführung vn Aktinen auf diesen Ressurcen und (2) ablauf der przessspezifische Objekte zur Steuerung der Vrgänge durch Aufruf der Methden ressurcenspezifischer Objekte entsprechend der Vrgangsdefinitin (vgl. [FeSi01, 210]). 3 Tier Architecture: Ein Anwendungssystem kann in Erweiterung der allgemeinen Client/ServerArchitektur in mindestens drei Schichten unterteilt werden (3 Tier Architecture). Bei einer 3SchichtenArchitektur unterscheidet man gewöhnlich die flgenden Schichten: Die Präsentatinsschicht stellt die Funktinen der Nutzerschnittstelle bereit und realisiert die Kmmunikatin mit dem Anwender. Die Anwendungsschicht realisiert die fachlichen Anwendungsfunktinen des Systems. Die Datenhaltungsschicht speichert den Zustand des Anwendungssystems und verwaltet hierzu die vn den Anwendungsfunktinen erzeugten und verarbeiteten Datenbjekte. 23

28 Mehr als dreischichtige Architekturen entstehen z.b. durch weitere Aufteilung des Präsentatins der Anwendungsteils. WebApplicatinServer sind beispielsweise durch eine 4SchichtenArchitektur gekennzeichnet, bei der jedch die klare Trennung in die ben beschriebenen Funktinsbereiche nicht aufrecht erhalten wird. Hier differenziert man in die Schichten (1) WebClient, (2) WebServer, (3) ApplicatinServer swie (4) Daten Server inklusive LegacyAnwendungen [SiKM00]. Verhaltensmerkmale: Ortstransparenz: Ortstransparenz ermöglicht die Nutzung der Dienste vn Kmpnenten eines verteilten Systems hne Kenntnis der Systemtplgie. Die Lkatin einer Kmpnente wird vr der aufrufenden Kmpnente verbrgen und ist für diese unerheblich, da der Zugriff über einen (lgischen) Namen erflgt, der keine Infrmatinen über den Ort enthält, an dem sich die Kmpnente befindet [MaR99]. Zugriffstransparenz: Dieses Merkmal besagt, dass die Kmpnenten eines verteilten Anwendungssystems beim Aufruf der Dienste anderer Kmpnenten stets mit demselben Zugriffsmechanismus perieren können, um die Zusammenarbeit zwischen hetergenen Systemen zu ermöglichen. Lkale und entfernte Methdenzugriffe sind aus Sicht der aufrufenden Kmpnente identisch. Zugriffstransparenz wird durch spezielle Funktinen realisiert, welche die Transparenz durch geeignete Knvertierungen z.b. der Aufrufstrukturen und Datentypen (Marshaling / Unmarshaling) sicherstellen [MaR99]. Implementatinstransparenz: Dieses Merkmal kennzeichnet Systeme, die Implementierungsdetails (Innensicht) seiner Kmpnenten, wie beispielsweise die verwendete Prgrammiersprache bzw. Basismaschine der die knkrete Realisierung einer Methde, vr den anderen Systemkmpnenten verbergen. Ihnen sind nur die publizierten Schnittstellen (Außensicht) bekannt, über die sämtliche Dienstaufrufe abgewickelt werden. Bleibt die Spezifikatin der Schnittstelle unverändert, s kann die Implementierung einer Methde jederzeit mdifiziert werden, hne dass Anpassungen bei aufrufenden Kmpnenten erfrderlich sind. Implementatinstransparenz wirkt sich psitiv auf die Fleibilität, Zuverlässigkeit und Erweiterbarkeit vn Anwendungssystemen, swie auf den Aufwand der Systementwicklung (Lkalität) aus [FeSi01, 295]. 24

29 Transaktinen: Eine Transaktin ist eine Flge vn Operatinen, die einen knsistenten Zustand eines Anwendungssystems in einen anderen knsistenten Zustand überführt. Allgemeine Anfrderungen an Transaktinen werden im sgenannten ACIDPrinzip zusammengefasst. Im Einzelnen wird gefrdert, dass eine Operatinsflge vllständig der gar nicht ausgeführt wird (Atmicity), dass die Knsistenz des Systemzustands durch die Ausführung der Transaktin nicht verletzt wird (Cnsistency), dass mehrere zeitlich parallel ablaufende Transaktinen einander nicht beeinflussen (Islatin) und dass die durch eine Transaktin verursachte Zustandsänderung dauerhaft ist (Durability) [GrRe93, 6]. Im Kntet verteilter Anwendungssysteme ist insbesndere der erstgenannte Aspekt der Sicherstellung atmarer Flgen vn Operatinen, die durch mehrere Systemkmpnenten dezentral ausgeführt werden, vn Interesse. Das ZweiPhasenCmmitPrtkll (Tw Phase Cmmit) für verteilte Systeme (vgl. [GrRe93, 562ff.]) stellt einen Mechanismus zur Krdinatin aller an der Durchführung einer Transaktin beteiligten Systemkmpnenten bereit. In verteilten Anwendungssystemen wird dieses Prtkll im Allgemeinen mit Hilfe vn TPMnitren (Transactin Prcessing Mnitrs) realisiert. Mnitring der Kmmunikatinsbeziehungen: Die Überwachung der Kmmunikatinsbeziehungen in verteilten Anwendungssystemen bezieht sich auf die jeweilige Senderund Empfängerkmpnente eines Nachrichtenaustausches, die angefrderten Dienste und die zurückgelieferten Leistungen. Sie wird durch die Verfügbarkeit eines ORB erleichtert. Die Überwachungsaufgabe, die in der Regel auch die Prtkllierung (Lgging) der Interaktinen beinhaltet, wird typischerweise vn TPMnitren durch Realisierung vn Transactinal Remte Prcedure Calls (TRPCs) wahrgenmmen [GrRe93, 295f.]. Sie ist die Vraussetzung für die Ermittlung der Verursacher vn Störungen und Fehlersituatinen während des Systembetriebs und zur Wiederherstellung knsistenter Systemzustände [Fe Si01, 219]. Interceptins: ORB leiten Dienstaufrufe an ServerObjekte vn ClientObjekten an Servants weiter, die den Dienst implementieren. Interceptins erlauben es dem Entwickler eines verteilten Anwendungssystems in das Zusammenspiel zwischen ORB und Servant einzugreifen und bei Eintritt bestimmter Ereignisse wie z.b. dem Aufruf einer Methde eines ServerObjekts zuvr bestimmte Operatinen zur Ausführung zu bringen. Auf diese Weise lassen sich z.b. Dienste für die Systemüberwachung der Sicherheitsmechanismen implementieren, die der ORB nicht vrsieht [Stal00]. 25

30 Sicherheit: Die Festlegung rllen, gruppen der benutzerspezifischer Sicherheitsknzepte sllte im Rahmen einer umfassenden Sicherheitsplitik erflgen. Sicherheitsdienste schließen Knzepte zur Authentifizierung, zur Zugriffskntrlle/Autrisierung und zum Schutz gegenüber Dritten (Integrität, Vertraulichkeit, Verbindlichkeit) ein. Zu den besnderen Sicherheitsaspekten in verteilten Systemen zählen der Schutz des Datennetzes gegen feindliche Kmpnenten, der Schutz der Kmmunikatin zwischen Kmpnenten, die Authentifizierung entfernter Kmpnenten, die Zugriffskntrlle auf entfernte und verteilte Ressurcen swie weitere Aspekte im Rahmen eines erweiterten Sicherheitsmanagements [Krum99]. Reflectin: Reflectin, zu deutsch Reflein, bedeutet allgemein das Nachdenken über sich selbst. In der Infrmatik beschäftigt sich Reflectin mit Anwendungssystemen, Kmpnenten der Objekten, die in der Lage sind, sich selbst zu beschreiben und zu manipulieren [Tune00]. Im Rahmen sftwaretechnischer Plattfrmen erlaubt Reflectin den Kmpnenten, MetaInfrmatinen über sich und andere Kmpnenten, wie z.b. die zur Verfügung stehende Schnittstelle, abzufragen und gegebenenfalls zu manipulieren. Message Queueing: Bei dieser Frm der asynchrnen Kmmunikatin tauschen Kmpnenten Nachrichten über eine Queue aus. Die Nachrichten können in ihrer Länge variieren und verschiedenen Typs sein. Im Allgemeinen können mehrere Kmpnenten Nachrichten an eine Queue senden und vn ihr empfangen. Message Queueing erlaubt eine asynchrne Kmmunikatin zwischen Kmpnenten. Die Message Queue stellt dabei sicher, dass die Nachricht auch dann den Empfänger erreicht, wenn der Empfänger der der Kmmunikatinskanal zum Zeitpunkt des Sendens nicht erreichbar ist. In diesem Fall wird die Nachricht zu einem späteren Termin versendet [GrRe93, 333f.; IBM00]. PerfrmanzAspekte werden im Rahmen dieser Arbeit nicht betrachtet. Die Perfrmanz eines Systems resultiert aus den technlgischen Merkmalen der sftwaretechnischen Plattfrm. Sie ist smit kein Merkmal an sich, sndern das Ergebnis einer spezifischen Merkmalskmbinatin. 26