Diplomarbeit der Philosophisch-naturwissenschaftlichen Fakultät. vorgelegt von. Michael Held

Transkript

1 Scipting fü CORBA Diplomabeit de Philosophisch-natuwissenschaftlichen Fakultät de Univesität Ben vogelegt von Michael Held 1999 Leite de Abeit: Pof. D. Osca Niestasz Institut fü Infomatik und angewandte Mathematik

2 Die Adesse des Autos: Softwae Composition Goup Institut fü Infomatik und angewandte Mathematik - Univesität Ben Neubückstasse 10 CH-3012 Ben held@iam.unibe.ch WWW: held ode Michael Held Römestasse 16 CH-2563 Ipsach

3 Zusammenfassung Veteilte Applikationen stellen hohe Anfodeungen an die Softwae-Hestelle, da diese Applikationen seh schnell seh komplex weden, unzueichende Entwicklungswekzeuge haben und einen hohen Administationsaufwand veusachen. Zu Untestützung weden heutzutage oft Middlewae- Technologien eingesetzt, wie zum Beispiel DCOM, RMI ode CORBA. In diese Abeit wid CORBA analysiet und mit Hilfe eines in diese Abeit estellten Vebesseungsansatzes und eine Skipt-Spache zu einem Komponenten Famewok vebesset. CORBA ist eine Middlewae fü veteilte, heteogene Applikationen und vespicht die Unabhängigkeit von Pogammiespache sowie eine tanspaente Veteilung von Objekten. CORBA hat einige Schwachstellen, wie zum Beispiel die mangelhafte Flexibilität, die mit hohem Aufwand vebundene Eweitebakeit ode das aufwendige Testen. In de Infomationstechnologie gibt es heute viele, schnelle Veändeungen, was ein hohes Mass an Flexibilität und Eweiteba- beziehungsweise Veändebakeit de Softwae efodet. In diese Abeit wid gezeigt, dass eine Middlewae, wie CORBA, duch einen einfachen Vebesseungsansatz, de Komponenten-Poxy-Methode, wesentlich vebesset weden kann. Mit Hilfe diese Methode und de vewendeten Skipt-Spache Python wid ein Komponenten Famewok estellt, das die Vewendung von veteilten Komponenten wesentlich flexible macht. Duch dieses Famewok wid eine höhee Abstaktion de Applikationen eeicht, da die Applikationslogik von den Komponenten getennt weden kann und die Komponenten duch Scipting vebunden weden. Daduch entstehen allgemeinee Komponenten, die einfache wiedevewendet weden können. Die Komponenten-Poxy-Methode födet zudem die Einsatzmöglichkeiten von COR- BA. Es weden Ansätze fü einen tavelling agent und einen intelligent poxy gezeigt. i

4 Pesönliche Bemekungen So eine Abeit wid eigentlich nie fetig, man muss sie fü fetig ekläen, wenn man nach Zeit und Umständen das Möglichste getan hat. Goethe, Italienische Reise An diese Stelle möchte ich allen danken, die mich in igendeine Fom bei diese Abeit untestützt haben. Nachfolgenden Pesonen gilt ein ganz besondee Dank; ich möchte sie namentlich ewähnen. Als estes danke ich meinem Beteue Jean-Guy Schneide fü seine kompetente Untestützung. E wa jedezeit beeit, mit mi Pobleme ode Unklaheiten zu diskutieen. Sein Rat sowie seine Pape-Tips bachten mi stets neue, hilfeiche Anegungen. Danken möchte ich insbesondee Pof. D. Osca Niestasz fü seine Untestützung, ohne die diese Abeit nicht möglich gewesen wäe. Ein Dank geht an die ganze Softwae Composition Goup, die ich jede Zeit um Rat fagen konnte. In diese Abeitsguppe hescht eine offene, keative und kitische Abeitsatmosphäe. Daniel Kühni und Nissim Buchs danke ich fü die kitische Duchsicht de ganzen Diplomabeit und die hilfeichen Gespäche, die wi in de Mensa fühen konnten. Fanz Achemann und Tobias Röthlisbege möchte ich fü den Review de Abeit danken. Schliesslich gilt mein ganz pesönliche Dank meinem Vate fü die finanzielle Untestützung und meine Feundin Käthi Ubanek fü ihe Geduld, das Veständnis und ihe Untestützung. ii

5 Inhaltsvezeichnis Zusammenfassung Pesönliche Bemekungen i ii 1 Einleitung Motivation Ziele Aufbau de Abeit Begiffe und Konzepte Veteilte Systeme Middlewae DCOM RMI CORBA Softwae Komposition Komponenten Komponenten Famewok Legacy Komponenten Skipt-Spachen Einleitung Eigenschaften Ein Übeblick Python CORBA Einleitung Achitektu OMA Guide (Object Management Achitectue Guide) Aufbau eines CORBA ORBs Eigenschaften IDL (Inteface Definition Language) Spachanbindung (Language mapping) iii

6 iv INHALTSVERZEICHNIS Inteopeabilität Dynamische Methodenaufuf Picing -Applikation - ein Beispiel Poblemanalyse Pobleme von CORBA Einschänkung de Poblemstellung Lösungsansatz de CORBA-Pobleme Übeblick Die Methode des Komponenten-Poxy Komponenten-Poxy Die Methode NameSeve Das Modul coba poxy Vewendung Komponenten Famewok fü CORBA Softwae Achitektu Python - die Skipt-Spache Glue - Wapping von legacy components Zusätzliche Möglichkeiten Intelligent Poxy Agent (Mobile Agent) Genzen Kein dynamische Methodenaufuf Halb-dynamische Methodenaufuf Abbildung von Python-Komponenten nach CORBA Fallstudie: FAMOOS Das FAMOOS-Pojekt Einleitung Aufgabe Wapping de beiden bestehenden Komponenten Adaption de sniff2cdif-komponente Adaption de FAMOOS-Dastellungs-Komponente Eweiteungen von FAMOOS GUI de FAMOOS-Dastellung TableGeneato Vewendungsbeispiele Inteaktives Debugging von Komponenten Applikationslogik - zwei Beispiele Agenten Komponenten-Eweiteung mit dem Intelligent Poxy

7 INHALTSVERZEICHNIS v 8.7 Diskussion Schlussbemekungen Eeichte Ziele Offene Pobleme A Abeitsumgebung 93 B Technische Details von CORBA 95 B.1 Ausnahmen (Exception) beim VisiBoke B.2 Das low level-vehalten eines ORBs B.3 IOR/IIOP - Inteopeabilität B.4 CORBA de neue Standad B.5 Fnob fü Python B.6 Skipt-Spachen-Anbindung an CORBA C CORBA Komponenten-Bibliothek 100 C.1 Komponenten-Poxy-Methode C.1.1 coba poxy - Modul C.1.2 NameSeve C.1.3 Intelligent Poxy C.1.4 Mobile Agent C.2 CORBA-Komponenten C.2.1 Hallo, Welt! C.2.2 Counte-Komponente C.2.3 Picing C.2.4 Das ZeitSeve-Beispiel C.3 FAMOOS C.3.1 sniff2cdif-komponente C.3.2 FAMOOS-Dastellung C.3.3 TableGeneato C.3.4 Skipts C.4 Weitee CORBA-Beispiele C.4.1 Komplexe Zahlen C.4.2 DII Liteatuvezeichnis 108

8 Abbildungsvezeichnis 2.1 Eine Middlewae vebindet Client und Seve Komponente als black box Ein ideales Komponenten Famewok Scipting vs. System Pogamming Languages von John Oustehout Python, die Skipt- bzw. System-Pogammiespache Ein Python-Skipt: Suchen und esetzen von Wöten in eine Datei Tie Achitektu Tie Achitektu n-tie Achitektu CORBA liegt zwischen Applikation und Betiebssystem OMA-Refeenzmodell Methodenaufuf übe den ORB Die Stuktu eines ORBs IDL-Beispiel: Komplexe Zahlen Inteopeabilität Eine Abstaktion duch ein Modul Ein Komponenten-Poxy leitet die Anfagen zu Oiginal-Komponente weite Methode de Komponenten-Poxy Mechanismus de Komponenten-Poxy-Methode Achitektu des Komponenten Famewoks Hieachische Stuktu eine n-tie Applikation Test von CORBA-Komponenten Gafische Benutzeobefläche eine Passwotabfage Adaption eine Komponente duch einen Wappe Tansfomation von inkompatiblen Datentypen in de Applikationslogik Analyse Tool mit Hilfe des Intelligent Poxy UML Klassendiagamm des Intelligent Poxy Sending Agent Tavelling Agent Aufbau des Tavelling Agent Kein Python-Poxy fü CORBA vi

9 ABBILDUNGSVERZEICHNIS vii 8.1 Famoos Reengineeing-Lebenszyklus Famoos Komponenten Famoos Szenaio Gafische Benutzeobefläche fü ein FAMOOS-Modell B.1 Ausnahmebehandlung im VisiBoke fü Java B.2 Inteopeabilität mit IIOP C.1 Eingabe Applet vom Komplex Rechne C.2 Gafische Dastellung de Resultate des Komplex Rechnes

10 Tabellenvezeichnis 3.1 Wichtige Pogammie-Paadigmen Python, Pel und Tcl im Vegleich Auflistung alle CORBA Dienste Die IDL-Spezifikation IDL nach Java Mapping B.1 Übeblick de CORBA Spezifikationen viii

11 Kapitel 1 Einleitung Das Gebiet de Infomationstechnologie ist einem dauenden Veändeungspozess ausgesetzt. Laufend weden neue Technologien entwickelt und nu kuze Zeit späte sind diese in Fom eines Poduktes auf dem Makt ehältlich. De Makt de Infomationstechnologie ist seh goss, was einen enomen Konkuenzkampf zu Folge hat. Als Folge diese schnellen Veändeungen und des gossen Konkuenzkampfes entstehen die unteschiedlichsten Nomen, sowie eine Vielfalt an Standads und Potokollen. Aus diese Vielfalt an Nomen esultieen inkompatible Sofwaekomponenten, was zu gossen Kommunikationspoblemen fühen kann. Ein Ansatz zu Lösung des Kommunikationspoblems besteht in de Definition eines globalen Standads, de die Inteopeabilität gaantieen wüde, so dass unteschiedliche Softwaekomponenten mit den unteschiedlichsten Nomen sich veständigen könnten. Ein Ziel de idealen Infomationstechnologie ist dahe ein univeselle Standad, de alle Had- und Softwaekomponenten umfassen könnte. Leide sind wi heute von de idealen Infomationstechnologie weit entfent. Es weden abe imme wiede Schitte untenommen, um inkompatible Fomate miteinande zu vebinden. COR- BA ist ein Standad, de Inteopeabilität zwischen heteogenen, veteilten Rechnen mit unteschiedlichen Pogammiespachen emöglicht. 1.1 Motivation CORBA ist eine Middlewae fü veteilte, heteogene Client/Seve-Applikationen und vespicht die Unabhängigkeit von Pogammiespache und eine tanspaente Veteilung von Objekten. Diese Eigenschaften machen CORBA zu einem Standad, de Inteopeabilität zwischen veschiedenen Hadwae- und Softwaekomponenten emöglicht. Aus de paktischen Vewendung von CORBA egeben sich abe die folgenden Pobleme (vgl. Poblemanalyse in Kapitel 5): Mangelnde Flexibilität: De Standad von CORBA 2.0 basiet auf einem Objektmodell (vgl. [OMG97b]). Die Efahung hat gezeigt, dass die objektoientiete Technologie keine Gaantie fü flexible und anpassbae Softwae-Entwicklung ist (vgl. [SN98a]). 1

12 2 KAPITEL 1. EINLEITUNG Aufwendiges Testen: Das Testen eine einzelnen Komponente ist aufwendig, das heisst, um einen Seve zu testen, muss ein vollständige CORBA-Client geschieben weden. Zudem gibt es noch keine Debugge und Analyse-Tools fü CORBA (vgl. [BR97]). Ungenügende Eweitebakeit: CORBA-Objekte besitzen aufgund de Implementation genau eine Schnittstelle (vgl. [OMG97b]). Diese Eigenschaft bigt die Schwieigkeit Komponenten zu veänden (vgl. [Maf97]), das heisst, CORBA-Objekte müssen fü jede zusätzliche Funktionalität neu angepasst weden (vgl. [BR97]). Mangelhaftes Abstaktionsniveau: Gosse Applikation tendieen zu gosse Komplexität (vgl. [Maf97]). Oft wid dahe die Applikationslogik auf veschiedene Komponenten veteilt, was zu eine Maintenance Nightmae fühen kann. Wiedevewendungspoblem: Da gössee CORBA-Applikationen meist eine hohe Komplexität elangen und CORBA nicht seh fehletoleant ist (vgl. [EKM97]), müssen diese Client/Seve-Applikationen oft genau aufeinande abgestimmt weden. CORBA-Komponenten von solch aufeinande abgestimmten Applikationen können dahe kaum wiedevewendet weden. Es stellt sich zudem die Fage, auf welche Weise legacy components in CORBA integiet weden können. 1.2 Ziele In diese Abeit wid vesucht, CORBA in Fom eines Komponenten Famewoks zu vewenden, in welchem die einzelnen Komponenten mit eine Skipt-Spache zusammengesetzt (connected) weden. Das Ziel diese Abeit ist, einen vetieften Einblick in die Themengebiete Scipting und CORBA zu ehalten. Es sollten die folgenden Teilziele eeicht weden: Einabeitung in die Themengebiete: Skipt-Spachen und CORBA Estellung eine Poblemanalyse von CORBA Ausabeitung eines Vebesseungsansatzes mit Hilfe eine Skipt-Spache Validieung des Ansatzes anhand eine Komponenten-Bibliothek Mit dem in diese Abeit ausgeabeiteten Vebesseungsansatz sollen die folgenden Vebesseungen zu den oben ewähnten CORBA-Poblemen ezielt weden: Die Komponenten-Poxy-Methode (vgl. Abschnitt 7.1) emöglicht Scipting von CORBA- Komponenten ohne CORBA-Kenntnisse. Auf diese Weise kann zum Beispiel ein inteaktives debugging und Testen von CORBA-Komponenten betieben weden. Eine höhee Flexibilität wid duch ein Komponenten Famewok (vgl. Abschnitt 2.3.2) eeicht. Das Komponenten Famewok nimmt eine klae Tennung zwischen Komponenten und Applikationslogik vo, was ein bessees Abstaktionsniveau zu Folge hat.

13 1.3. AUFBAU DER ARBEIT 3 Eine vebessete Eweitebakeit de CORBA-Komponenten kann duch einen eleganten Ansatz, den Intelligent Poxy (vgl. Absatz 7.3.1), ealisiet weden. Die Softwaewiedevewendung wid duch das Komponenten Famewok gefödet, da die Applikationslogik von den CORBA-Komponenten getennt wid. Bei de Komponenten- Entwicklung kann dahe meh Wet auf die Wiedevewendbakeit gelegt weden. Zudem können legacy components mit dem Glue des Komponenten Famewoks integiet weden. Die voliegende Abeit zeigt, dass mit einem elativ einfachen Vebesseungsansatz eine seh gosse Wikung ezielt weden kann, wie zum Beispiel de Zugiff auf CORBA-Komponenten ohne CORBA-Kenntnisse ode die Realisieung eines Komponenten Famewoks. Mit Hilfe von diesem Vebesseungsansatz weden zwei nicht tiviale zusätzliche Möglichkeiten entwickelt, die CORBA ganz neue Dimensionen veleihen: Intelligent Poxy und Agent (Mobile Agent vgl. Absatz 7.3.2). Die Entwicklung des Intelligent Poxy und des Mobile Agent kann als positives Egebnis betachtet weden. 1.3 Aufbau de Abeit Diese Abschnitt gibt dem Lese einen kuzen Übeblick übe die voliegende Abeit, die wie folgt in vie Einheiten unteteilt wid: Gundlagen (Kapitel 2 bis 4): In Kapitel 2 weden die fü diese Abeit wichtigen Begiffe und Konzepte eläutet, welche fü das Veständnis de ganzen Abeit benötigt weden. Das 3. Kapitel stellt das Themengebiet de Skipt-Spachen vo. Besondee Aufmeksamkeit gilt de Skipt-Spache Python, da in diese Abeit eine Python-Anbindung an CORBA vewendet wid. Im 4. Kapitel wid die Middlewae CORBA eingefüht. Die Achitektu und die Vewendung von CORBA wid in Fom eine Einfühung vogestellt. Poblem-Beabeitung (Kapitel 5 und 6): Das 5. Kapitel untesucht anhand ausgewählte Liteatu die Pobleme von CORBA. De Poblemkeis von CORBA wude in diese Abeit aus zeitlichen Günden eingeschänkt. Das Kapitel 6 bescheibt einen Lösungsansatz, wobei mit diese Studie vegleichbae Ansätze zuvo kuz vogestellt weden. Methode (Kapitel 7 und 8): Die in diese Abeit estellte Komponenten-Poxy-Methode wid im Kapitel 7 eläutet. Es wid ein Komponenten Famewok beschieben, das die Vewendung von CORBA- Komponenten veeinfacht. Diese Ansatz eweitet CORBA mit zusätzlichen Möglichkeiten wie zum Beispiel dem Intelligent Poxy. Im Kapitel 8 wid anhand eine Fallstudie im Foschungspojekt FAMOOS (vgl. [DT98]) die Methode vewendet und gezeigt, wie das Komponenten Famewok eingesetzt weden kann. Egebnisse (Kapitel 9): Im letzten Kapitel wid eine Zusammenfassung de Resultate estellt. Anhand de Egebnisse weden offene Pobleme und mögliche Fagestellungen fü weitee Abeiten beschieben.

14 Kapitel 2 Begiffe und Konzepte In diesem Kapitel weden die fü diese Abeit wichtigen Begiffe und Konzepte vogestellt. COR- BA ist eine Middlewae, die das Entwickeln von veteilten Systemen eleichtet. Mit CORBA estellt man Client/Seve-Applikationen. Ein Seve ist eine Komponente und Komponenten können duch Softwae-Komposition zu eine Applikation zusammengesetzt weden. Ein Komponenten Famewok eleichtet die Softwae-Komposition. De Glue des Famewoks emöglicht das Einbinden von legacy components. 2.1 Veteilte Systeme Am Anfang de Computetechnologie waen die infomationsveabeitenden Maschinen seh goss und extem teue. Diese Situation ändete sich ab Mitte de 80e Jahe duch die folgenden zwei technologischen Fotschitte: Leistungsstake Mikopozessoen: Nach und nach kamen billige und seh leistungsstake Mikopozessoen auf den Makt. Die Leistung eines solchen Rechnes entspach bald einmal einem mittleen Mainfame. Hochgeschwindigkeits-Computenetzweke: De Fotschitt in de Hochgeschwindigkeits-Netzwektechnologie emöglicht das Vebinden von meheen Rechnen mit hohen Datenübetagungsaten. Man untescheidet zwischen Lokal Aea Netwoks (LAN) und Wide Aea Netwoks (WAN). Diese Fotschitte elauben es, eine gosse Anzahl von billigen Mikocomputen duch ein Hochgeschwindigkeits-Netzwek zu vebinden. Stattet man ein solches Netzwek mit einem geeigneten Betiebssystem aus, dann handelt es sich um ein veteiltes System. Tanenbaum definiet ein veteiltes System wie folgt (vgl. [Tan95]): Definition 1 Ein veteiltes System ist eine Sammlung voneinande unabhängige Compute, die dem Benutze des Systems den Einduck vemitteln, es handle sich um einen einzigen Compute. 4

15 2.2. MIDDLEWARE 5 Dabei sind zwei Aspekte wichtig. Estens weden die Compute als autonom betachtet; zweitens soll dem Benutze das Gefühl vemittelt weden, als handle es sich bei dem System um einen einzigen Rechne. 2.2 Middlewae Es hat sich in de Paxis gezeigt, dass veteilte Client/Seve-Applikationen seh schnell seh komplex weden. Ein Gund liegt in dem gossen Spektum von Entwufs- und Entwicklungsaltenativen. Dahe wid imme häufige Hilfssoftwae eingesetzt, die die Abeit de Entwickle eleichtet und veeinfacht. Bei de Entwicklung von veteilten Infomationssystemen kommt Middlewae- Softwae eine Schlüsselolle zu (vgl. [BR97]). Fü Middlewae gibt es noch kein einheitliches Veständnis (vgl. [Te97]). Man kann sich abe unte Middlewae eine zusätzliche Abstaktionsschicht vostellen, die zwischen eine Clientode eine Seve-Komponente und dem daunte liegendem Betiebssystem liegt. Die zusätzliche Abstaktionsschicht übenimmt die Kommunikation zwischen Client und Seve (vgl. Abbildung 2.1). Client Seve Middlewae Abbildung 2.1: Eine Middlewae vebindet Client und Seve Gemäss Benstein (vgl. [Be96]) beinhaltet Middlewae hauptsächlich Kommunikationskomponenten, die duch Dienste und Funktionalitäten vewiklicht weden. Dabei untescheidet Benstein zwischen den folgenden Middlewae-Diensten: Kommunikationsdienst System-Dienst Infomations-Dienst Ablaufkontoll-Dienst Päsentations-Dienst Beechnungs-Dienst Tesch (vgl. [Te96]) bezeichnet die klassischen Aufgaben von Middlewae als Kommunikation zwischen Client und Seve sowie den Zugiff auf veteilte Datenbanken:

16 6 KAPITEL 2. BEGRIFFE UND KONZEPTE Kommunikations-Middlewae Fü die Kommunikation zwischen Client und Seve gibt es gundsätzlich zwei Mechanismen: Estens emöglicht de Remote Pocedue Call (RPC) das Ausfühen eine Pozedu auf einem entfenten Rechne. Und zweitens bescheibt das Message Queueing die asynchone Kommunikation (Mailbox-ähnlich). SQL-Middlewae fü den Zugiff auf veteilte Daten Middlewae schimt die Applikation von de Heteogenität de Betiebssysteme und de Netzwekpotokolle ab. Es weden Standadschnittstellen und Dienste beeitgestellt. Daduch weden folgende Ziele eeicht: Vebinden von veteilten Objekten Integation von heteogenen Applikationen Özsu (vgl: [ODV94]) unteteilt die aktuelle Middlewae-Entwicklung aufbauend auf den Gundfunktionalitäten de Kommunikation, Datenvewaltung und Ablaufkontolle in die folgenden Fomen von Middlewae: Kommunikations-Middlewae fü veteilte Objekte Multimedia-Anfageschnittstellen Data Waehousing Agenten und Koodinatoen Tansaktions-Monitoe (TP-Monitoe) Middlewae mit Anwendungslogik Die heute seh bekannten Beispiele von Middlewae sind CORBA, DCOM und RMI. Nachfolgend weden diese dei Vetete kuz vogestellt DCOM DCOM ist ein Podukt von Micosoft (vgl. [Mic98]). DCOM (Distibuted Component Object Model) ist eine Eweiteung von COM (Component Object Model) fü veteilte Objekte. COM (beziehungsweise zukünftig COM+) bietet eine Infastuktu und Kommunikationsmechanismen fü die Entwicklung von Objekten. COM veeinfacht die Applikationsentwicklung, indem ein gosse Teil des Vewaltungsaufwandes de Objekte übenommen wid. Mit Hilfe von COM kann man zum Beispiel in eine Anwendung auf einfache At und Weise ein Name ode eine Adesse aus eine Datenbank anfoden. COM definiet einem binäen Standad wie Klassen, beziehungsweise Objekte vewaltet und deen Methoden aufgeufen weden. Daduch ist es möglich Objekte zusammenabeiten zu lassen,

17 2.2. MIDDLEWARE 7 die in veschieden Pogammiespachen geschieben sind. Die Weiteentwicklung DCOM (fü Distibuted COM) bietet eine Plattfom fü veteilte Anwendungen, das heisst, DCOM ist eine Entwicklungsuntestützung fü Applikationen mit Objekten, welche auf veschiedenen Rechnen leben. Zu Zeit untestützt DCOM die folgenden Pogammiespachen: Visual C++, Visual Basic und Visual J++ 1. DCOM läuft voallem auf Windows- und Mac-Rechnen. Die Potieung von DCOM auf andee Plattfomen wie Sun Solais (SPARC) soll gemäss einige Expeten noch Schwieigkeiten beeiten (vgl. [Wit97]). De Softwae AG 2 hingegen sind keine solche Schwieigkeiten bekannt. Viele de Pinzipien und Funktionalitäten von DCOM sind seh ähnlich zu denjenigen von CORBA (vgl. [Pud97]). DCOM kennt hingegen keine Inteopeabilitätspobleme, da die Kontolle de Implementieung in de Hand von Micosoft liegt und daduch eine Abhängigkeit zu einem Entwickle besteht, dies obwohl Micosoft DCOM an die Open Goup 3 übegeben hat. DCOM spezifiziet ein binäes Inteface, das von de Objektimplementieung getennt wid. De Quellcode von Objektintefaces ist nicht offen, das heisst eine Wiedevewendung efolgt nu übe Aggegation auf Binäebene RMI RMI (Abküzung fü Remote Methode Invocation) wude fü den Methodenaufuf von veteilten Objekten entwickelt (vgl. [Sun97]). Das veteilte Objektmodell von RMI wude in Java integiet. Diese Middlewae untestützt nu Client/Seve-Applikationen, die in de Pogammiespache Java geschieben weden. RMI ist ab de Vesion 1.1 vom Java Develope Kit (JDK) ein Teil von Java und besteht aus den folgenden dei Java-Paketen: java.mi, java.mi.seve und java.mi.egisty. Die Seve-Objekte publizieen ihe Java-Intefaces bei de Registy, damit die Clients übe dieses Inteface auf den Seve zugeifen können. RMI besitzt einen Naming Sevice fü das Auffinden von Seve-Objekten. Mit Hilfe dieses Dienstes können Seve duch einen Namen efeenziet weden. Fü die veteilten Objekte gibt es einen Mechanismus, de den Speiche von nicht meh vewendeten Objekten feigeben kann (gabage collection) CORBA CORBA (Common Object Request Boke Achitectue) ist eine Spezifikation (vgl. [OMG97b]) eine spachunabhängigen Middlewae fü offene, veteilte und objektoientiete Client/Seve- vgl.! #"$%& ')(+*)"-,. /* & vgl &02*!%(4*5-/%6/%7 $%* 8%,9" &%:%(4- &%(4;'%(4- &%(;:! & vgl. Die Active Goup ist eine Tochte von Open Goup.

18 8 KAPITEL 2. BEGRIFFE UND KONZEPTE Applikationen, deen Intefaces auf ASCII-basieen. CORBA wid in Kapitel 4 ausfühlich bespochen. 2.3 Softwae Komposition Auf Gund de vielen veschiedenen Hadwaekomponenten und Betiebssystemen divesifiziet sich auch die Softwae stak. Bei de Softwaeentwicklung wid eine Applikation jeweils auf die entspechende Hadwae beziehungsweise das vewendete Betiebssystem zugeschnitten. Fü die entwickelten Softwaekomponenten eschwet sich daduch die Wiedevewendung in eine andeen Umgebung. Es wid oft vesucht, Komponenten mit unteschiedlichen Achitektuen auf eine geeignete At zusammenzusetzen um ein zusammenhängendes Softwaesystem zu elangen. Dieses Zusammensetzen von beliebigen Softwaekomponenten zu eine Applikation nennt man Softwae Komposition. In diese Disziplin hat sich ein neues Pogammie-Paadigma heauskistallisiet: de komponentenoientiete Stil. Diese Stil lässt sich mit de einfachen Fomel 2.1 bescheiben. (2.1) Komponenten Components ae designed to be composed. Osca Niestasz and Jean-Guy Schneide [SN98b] Eine Komponente kann man sich als black box vostellen. Die black box ist ein Pogamm, von dem man wede die Gösse noch dessen Inhalt kennen muss. Eine Komponente besitzt abe dei wichtige Mekmale, die in de Abbildung 2.2 esichtlich sind: voausgesetzte Dienste Eweiteungen (slots) angebotene Dienste black box Abbildung 2.2: Komponente als black box Angebotene Dienste: Es weden Dienste übe ein Inteface angeboten. Diese Dienste können von andeen Komponenten benutzt weden. Voausgesetzte Dienste: Eine Komponente kann gewisse Voaussetzungen besitzen, das heisst, es düfen Dienste von andeen Komponenten voausgesetzt weden. Sind diese Voaussetzungen nicht efüllt, so kann die Komponente nicht vewendet weden.

19 2.4. LEGACY KOMPONENTEN 9 Eweiteungen: Es soll die Möglichkeit bestehen, die Komponenten mit neuen Fähigkeiten zu eweiten (plug-in). Zu Veanschaulichung eine Komponente kann man sich zum Beispiel ein Tansistoadio vostellen. Das Radio ist dann eine black box, die mit einigen Knöpfen vesehen ist. Diese Knöpfe entspechen den Diensten, die angeboten weden. Damit mit einem Tansistoadio übehaupt Musik gehöt weden kann, muss das Radio mit Stom vesogt sein. Das heisst, als voausgesetzte Dienst haben wi zum Beispiel Batteien, die das Radio mit Enegie speisen. Eweiten könnte man des Radio zum Beispiel mit extenen Lautspechen Komponenten Famewok Ein Komponenten Famewok bescheibt, wie Komponenten und Applikationen mit Komponenten estellt weden. Ein Famewok definiet die Bauweise de Komponenten, damit sie in eine vogegebene Achitektu passen. Eine Applikation besitzt meist eine Menge von Komponenten. Zusammengesetzt weden die Komponenten dann in einem Skipt. Die Abbildung 2.3 zeigt ein ideales Bild des Komponenten Famewoks, das aus den folgenden vie Elementen zusammengesetzt ist: Die Achitektu eines Komponenten Famewoks bescheibt, dass eine Applikation aus zwei Bausteinen besteht: Komponenten und Konnektoen (vgl. [GS96]). Komponenten weden duch Skipts vebunden (connected). Es wid zudem eläutet, wie die Komponenten gebaut, beziehungsweise vewendet weden. Die Applikationslogik (Konnektoen) befindet sich in einem Skipt. Mit Koodination weden Abstaktionen bezeichnet, die nebenläufige Pozesse synchonisieen und deen Inteaktion steuen, wie zum Beispiel bei UNIX die Mechanismen von piping und filteing. De Glue adaptiet bestehende, vealtete Komponenten (legacy applications), die nicht zu diesem Famewok gehöen. Diese Adaption wid oft mit einem sogenannten Wappe (vgl. Adapte Patten in [GHJV95]) ealisiet. Skipts fügen dann schliesslich die beeits aufeinande abgestimmten Komponenten zusammen. 2.4 Legacy Komponenten Im letzten Abschnitt wude ein Komponenten Famewok beschieben. De Glue des Komponenten Famewoks wid fü die Adaption von legacy components vewendet. Unte eine legacy component (legacy engl. Vemächtnis) vesteht man eine bestehende Softwae-Komponente, die veebt wude und die nützlich und wetvoll ist. Eine solche Komponente kann meistens aus Kompatibilitätsgünden nicht diekt in eine aktuelle Applikation übenommen

20 10 KAPITEL 2. BEGRIFFE UND KONZEPTE Skipt Glue Komponenten Famewok Koodination Achitektu Abbildung 2.3: Ein ideales Komponenten Famewok weden. Eine legacy componet muss dahe oft veändet ode umgewandelt weden. Legacy components weisen meist eines de folgenden typischen Pobleme (vgl. [Nie98]) auf: De Entwickle de Softwae-Komponente abeitet nicht meh in deselben Fima. Die Komponente wude in eine andeen Pogammiespache geschieben. Teile de vewendeten Methoden sind vealtet ode sind nicht meh koekt. An dem System wuden viele Veändeungen beziehungsweise Eweiteungen gemacht. Es gibt meist keine ode nu eine mangelhafte Dokumentation. Die Komponente läuft nu auf eine andeen Plattfom. Viele Fimen haben ein gosses Poblem, wenn sie zum Beispiel ihe Geschäftspozesse veänden. Pobleme entstehen bei de Anpassung de Softwae. Es stellt sich hie die folgende Fage: Muss die ganze Softwae von Gund auf neu geschieben weden, ode kann man die bestehende Altsoftwae anpassen und Teile wiedevewenden? Es wid oft entschieden, dass alles von Gund auf neu implementiet wid. Diese Entscheidung hat den Voteil, dass die Anwendungen danach dem neusten technologischen Stand entspechen. Das ist zum Beispiel so, wenn ein Infomationssystem an das Jah 2000-Poblem angepasst weden muss. Ein weitee Voteil besteht dain, dass man so eine saubee, gut stuktuiete Lösung bekommt. Es ist oft de Fall, dass eine bestehende Applikation dauend vebesset und veändet wid. Solche Applikationen sind meist so komplex, dass sie fü die Watung (zu) teue und nicht flexibel genug weden. Nachfolgend weden Nachteile eine Neuentwicklung aufgezählt: Es entstehen hohe Kosten. Alle Kindekankheiten de neuentwickelten Softwae müssen wiede eliminiet weden. Es kann Jahe dauen, bis das System entwickelt und danach auch zuvelässig ist.

21 2.4. LEGACY KOMPONENTEN 11 Solche Nachteile bewegen viele Fimen dazu, bestehende Altsoftwae wiede zu vewenden. Zudem haben sich die bestehenden Komponenten schon übe Jahe bewäht und sind meist fehlefei. Es gibt abe auch Systeme, bei denen es in Anbetacht ihe Komplexität iskant ist, diese von Gund auf neu zu entwickeln (vgl. Patten fo legacy Integation in [MM97]). Solche Pojekte weden meist zu teue und/ode laufen Gefah zu scheiten. Oft wid die bestehende Altsoftwae angepasst und wiedevewendet. Zu gleichen Zeit beginnt man die Softwae von Gund auf neu zu entwickeln. Nach und nach weden neue Komponenten in das System integiet und die alten esetzt. Diese Vogang dauet so lange, bis am Schluss das ganze System eneuet ist. Eine legacy application stellt einen gewissen Wet ode Nutzen da, dahe will man diese Komponenten in eine Entwicklung integieen. Die Integation von legacy applications ist nicht einfach und efodet eine Umwandlung (Adaption) de bestehenden Altsoftwae. Diese Umwandlung von legacy applications heisst Wapping (Vepackung, Umhüllung). Das Ziel vom Wapping ist die Wiedevewendung von bestehende Altsoftwae. Es ist nicht einfach eine Applikation aus bestehenden Komponenten zu bauen. Diese Poblematik ist unte Achitectual Mismatch bekannt (vgl. [GAO95]). Um Altsoftwae in einem neuen Softwae-System zu vewenden, sind beispielsweise die folgende Schitte notwendig (vgl. [Sne96]): Analyse des Altsystems Spezifizikation de Schnittstellen (zum Beispiel als CORBA-IDL) Veändeung de Altkomponente, so dass diese einzeln aufgeufen weden kann Entwicklung eines Wappes, de die Aufufe de Altkomponente umsetzt

22 Kapitel 3 Skipt-Spachen Inceases in compute speed and changes in the application mix ae making scipting languages moe and moe impotant fo applications of the futue. John K. Oustehout Skipt-Spachen, Glue, Achitektu und Koodination sind die vie Elemente, die ein ideales Komponenten Famewok bilden (vgl. Absatz 2.3.2). Skipt-Spachen weden fü die komponentenoientiete Pogammieung benötigt. In diesem Kapitel weden zu Beginn die wichtigsten Eigenschaften de Skipt-Spachen eläutet. Anschliessend weden wichtige Vetete von Skipt-Spachen kuz vogestellt. Am Ende dieses Kapitels weden die wichtigsten Mekmale von Python eingefüht, da Python die in diese Abeit vewendete Skipt-Spache ist. 3.1 Einleitung Skipt-Spachen, wie zum Beispiel AXLE, AWK, Sed, Unix Shell und HypeTalk (vgl. [Nie96]), gibt es schon seit längee Zeit. Die Liste de Skipt-Spachen ist goss. Diese Typ von Pogammiespache konnte sich lange Zeit nicht so ichtig duchsetzen, da die Rechneleistung fü die intepetieten Skipt-Spachen zu langsam wa. Est in den letzten fünf Jahen efeut sich die scipting-community einem egelechten Aufschwung. Diese Tendwende lässt sich auf veschiedene Faktoen zuückfühen (vgl. [Ous97]): Die Hadwae wid imme billige und deen Leistung imme gösse. Das hat beispielsweise zu Folge, dass de vefügbae Speiche kein Flaschenhals meh dastellt. Heutzutage haben die gafischen Obeflächen (GUI) einen enom wichtigen Stellenwet. Mit Hilfe von Tk kann auf eine einfache At und Weise eine gafische Benutzeobefäche estellt weden. Das Intenet boomt in einem Ausmass, das vo zehn Jahen die kühnsten Optimisten nicht pognostiziet hätten. Fü Seve-seitige Web-Anwendungen weden hauptsächlich Skipt- 12

23 3.1. EINLEITUNG 13 Spachen zum Estellen von CGIs vewendet. Java-Applets weden im Gegensatz dazu oft auf de Client-Seite eingesetzt. Aus de Komponentenvielfalt entwickelt sich ein neues Pogammiepaadigma: de komponentenoientiete Pogammiestil (vgl. Tabelle 3.1 aus [Nie96]). Stil Impeativ Funktional Logisch Objektoientiet Komponentenoientiet Pogamm Pogamm := Algoithmus + Daten Pogamm := Funktion\ Funktion Pogamm := Fakten + Regeln Pogamm := Objekte + Nachichten Pogamm := Komponenten + Skipts Tabelle 3.1: Wichtige Pogammie-Paadigmen Skipt-Spachen weden imme häufige eingesetzt. Abe was sind Skipt-Spachen genau? Es ist schwieig, eine Skipt-Spache exakt zu definieen. Die Ansichten übe die Definition de Skipt-Spachen sind nicht einheitlich. Nachfolgend weden zwei wichtige Definitionen dagestellt. Definition 2 (Clemens Szypeski) Unlike mainsteam component pogamming, scipts do not intoduce new components, but simply wie existing ones. Scipts can be seen as intoducing new behaviou but no new states. Aus Definition 2 gehen zwei wichtige Aspekte hevo. Estens macht Clemens Szypeski die Untescheidung zwischen Komponenten-Pogammiespachen (auch system pogamming ode taditionelle Pogammiespachen genannt) und Skipt-Spachen. Zweitens haben Skipt- Spachen den Zweck, Komponenten zu vebinden und nicht etwa um Neue zu estellen. Auch John K. Oustehout untescheidet wie Clemens Szypeski zwischen diesen zwei Spachtypen. Die Gafik 3.1 aus Scipting: Highe Level Pogamming fo the 21st Centuy (vgl. [Ous97]) zeigt diese zwei Typen. Skipt-Spachen sind meist schwach typisiete Spachen. Man nennt sie auch dynamisch typisiet, da de Datentyp de Objekte beziehungsweise de Methoden est zu Laufzeit veifiziet wid. Im Gegensatz dazu weden die taditionellen Spachen von einem Compile unte andeem auf Datenintegität gepüft und sind dahe stak typisiet. Definition 3 (Jean-Guy Schneide, Osca Niestasz) Scipting languages ae designed fo configuing and connecting components. In Definition 3 wid hauptsächlich de Zweck de Skipt-Spachen hevogehoben. Skipt- Spachen adaptieen und vebinden Komponenten, welche meist aus andeen Pogammiespachen stammen.

24 14 KAPITEL 3. SKRIPT-SPRACHEN 1000 Scipting Visual Basic Instuctions/Statement Tcl, Pel Python C C++ Java 1 None Assembly Degee of Typing System Pogamming Stong Abbildung 3.1: Scipting vs. System Pogamming Languages von John Oustehout Jede Pogammiespache kann im Pinzip zum Vebinden von Komponenten vewendet weden. Wie untescheiden sich nun taditionelle Spachen von Skipt-Spachen? 3.2 Eigenschaften Die Efahung hat gezeigt, dass eine Pogammiespache est dann als Skipt-Spache bezeichnet weden kann, wenn sie auch zu diesem Zweck vewendet wid. Skipt-Spachen besitzen meistens die nachfolgenden typischen Eigenschaften (vgl. [SN98b]): eweiteba: Skipt-Spachen sind auf zwei Aten eweiteba: Eineseits ist eine Eweiteung de Skipt-Spache leicht möglich, das heisst benutzedefiniete Pozeduen ode Funktionen (meist in C) lassen sich als Modul ode soga in den Spachken aufnehmen. Dies ist vo allem wichtig, wenn die Geschwindigkeit eine Rolle spielt. Andeeseits lassen sich Skipts zu Komponenten eweiten, so dass sie in einem Komponenten Famewok vewendet weden können. adaptieen und vebinden Komponenten: Skipt-Spachen wuden entwickelt zum Adaptieen und Vebinden von Komponenten (connecting components). Komponenten Famewok: Eine Skipt-Spache ist ein wichtige Bestandteil eines Komponenten Famewoks.

25 3.3. EIN ÜBERBLICK 15 in andeen Pogammiespachen integieba: Skipt-Spachen lassen sich in andeen Pogammiespachen wie zum Beispiel C ode Java integieen. Man nennt die Skipt-Spachen dann auch embeddable. Auf diese Weise können die taditionellen Pogammiespachen von den Fähigkeiten de Skipt-Spachen pofitieen. intepetiet ode dynamisch compiliet: Die Pogamme müssen nach de Implementieung nicht selbst compiliet und gelinkt weden wie das in den taditionellen Spachen de Fall ist. Ein Skipt kann sofot gestatet weden, dabei wid es eineseits zeilenweise intepetiet ode andeeseits zu Laufzeit compiliet. Die Ausfühungsgeschwindigkeit ist dahe nicht ganz so schnell wie zum Beispiel bei einem C-Pogamm. potabel: Pogammcode (ein Skipt) lässt sich ohne Veändeung auf einem andeen Rechnetyp ausfühen, da das Pogamm nicht in einen Maschinencode umgewandelt wid. Skipts weden est wähend de Ausfühung intepetiet ode dynamisch compiliet. dynamisch typisiet: Es ist keine Vaiablendeklaation efodelich. Eine Vaiable wid definiet, indem man ih einen Wet zuweist. Bei den meisten Skipt-Spachen ist es so, dass die gleiche Vaiable zum Beispiel einmal Zahl und einmal Sting als Wet haben kann. fei vefügba: De Gebauch diese Pogammiespachen ist meist kostenlos. Das bedeutet natülich nicht, dass Skipt-Spachen nichts Wet sind. Im Gegenteil; die Entwicklung eine Skipt-Spache ist eine seiöse Abeit. Viele Pogammiee und um die Welt decken Fehle auf und machen Vebesseungsvoschläge, da die Spachen fei vefügba sind. Die meisten Skipt-Spachen sind wähend vielen Jahen intensiv entwickelt woden. Ein Skipt zeichnet sich meistens duch seine kompakte, flexible At aus. Skipts weden hauptsächlich in den folgenden Anwendungsbeeichen vewendet: dynamische Web-Anwendungen Testen von Applikationen Systemadministationsaufgaben Entwicklung von Pototypen (vo allem gafische Benutzeobeflächen) Softwaeentwicklung mit Hilfe eines Komponenten Famewoks 3.3 Ein Übeblick Die esten Skipt-Spachen waen shell languages und command languages. Diese Spachen wuden vo allem fü Betiebssysteme und spezielle veändebae Applikationen vewendet. Beispielsweise wude 1971 die Unix-Shell als Benutzeinteface (Shell) und als Skipt-Spache entwickelt. Man vewendete diese Spachen um eine Reihe von Befehlen abzuabeiten, ohne dass eine Inteaktion mit dem Benutze stattfand. Die abzuabeitenden Befehle schieb man in Dateien, damit die gleiche Befehlssequenz mehee Male ausgefüht weden konnte. Diese Dateien

26 16 KAPITEL 3. SKRIPT-SPRACHEN nennt man auch batch files. In DOS-Systemen ekennt man diese Dateitypen an de Dateiendung.bat. Ein Beispiel ist die Datei autoexec.bat. Diese Datei wid beim Bootvogang automatisch ausgefüht. In de Folge wuden sogenannte text pocessing languages wie zum Beispiel AWK, Pel ode Sed benötigt. Diese Typ von Pogammiespache ist auf die Veabeitung von Texten und Dateien spezialisiet. text pocessing languages können auch seh gosse Dateien beabeiten. Heute fasst man alle Pogammiespachen mit solchen Fähigkeiten zusammen und nennt sie Skipt-Spachen. Es gibt viele Vetete von Skipt-Spachen. Am meisten vewendet und am bekanntesten sind: AppleScipt, VB, Tcl/Tk, Pel und Python (vgl. [LS97]). Im Atikel Scipt im Giff von Cameon Laid und Kathyn Soaiz (vgl. [LS98b]) weden einige Scipt-Spachen im Übeblick dagestellt. Die Tabelle 3.2 basiet auf diesem Atikel und zeigt zusammenfassend die wichtigsten Untescheidungsmekmale von Tcl/Tk, Pel und Python. Nachfolgend weden diese Skipt-Spachen kuz vogestellt. Python Pel Tcl/Tk Paadigma Objektoientiet Impeativ Impeativ Konzept/Motto Eveything is Thee is moe than Eveything an object. one way to do it. is a sting. veteilte ja ja ja Pogammieung Hauptzweck Administation Textpocessing GUI Voteil saube, potiebae vebeitet, einfache Syntax, Spache dominant in CGI eweiteba Nachteil Fachkenntnisse Maintenance umständlich fü noch klein wenige beachtet einfache Aithmetik Tabelle 3.2: Python, Pel und Tcl im Vegleich Pel Pel (Pactical Extaction and Repot Language) ist eine weit vebeitete Skipt-Spache. Pel wid vo allem in de Unix-Welt vewendet. Sie wude mit gosse Sogfalt entwickelt und ist dahe eine seh sichee Spache (vgl. [WCS96]). In de letzten Zeit wude Pel hauptsächlich fü die Estellung von CGIs (Common Gateway Inteface) vewendet. Thee is moe than one way to do it ist das Motto von Pel. Mit Pel kann man seh einfach Texte, Dateien und Pozesse manipulieen. Pel ist optimiet um Infomationen aus Dateien zu extahieen. Ein sogenanntes patten matching elaubt ein seh schnelles duchabeiten von gossen Mengen von Daten. Dateien können manipuliet weden wie zum Beispiel Umbenennen von Dateinamen ode Änden von Zugiffsechten. Pel elaubt das

27 3.3. EIN ÜBERBLICK 17 Ezeugen, Steuen und Venichten von Pozessen. Sie eignet sich fü die meisten Systemadministationsabeiten und vo allem fü Textpocessing. Die Länge eines Datentyps ist nicht auf igendeine Zweiepotenz limitiet, wie das in manchen Pogammiespachen de Fall ist. Vaiablennamen, Stings und Aays düfen unbeschänkt lange weden, das heisst bis man keinen Speiche meh hat. Binäe Datentypen bieten keine Pobleme. Pel-Pogamme sind siche, da sie unsichee Datentypen duch einen tacing -Mechanismus euieen können. Diese Mechanismus beugt vielen Sicheheitslöchen vo. Diese Pogammiespache läuft auf den gängigsten Betiebssystemen und Hadwae-Achitektuen. Pel ist eine dynamisch compiliete Spache, das heisst, dass Pelpogamme (Skipts) est zu Laufzeit compiliet weden und nicht explizit compiliet weden müssen. Sie ist eine pozeduale Spache, die ab de Pel Vesion 5 auch die objektoientiete Pogammieung elaubt. Pel kombiniet die besten Fähigkeiten von C, sed, awk, und sh. Die Ausduck-Syntax ist seh ähnlich wie die Ausduck-Syntax von C. Tcl/Tk Im Jahe 1988 begann John K. Oustehout mit de Entwicklung von Tcl/Tk (vgl. [Ous94]). Tcl/Tk besteht aus zwei Softwae-Paketen: Tcl (genannt tickel ) ist eine intepetiete, stingbasiete Skipt-Spache. Tk eweitet Tcl um gafische Benutzeobeflächen. Bei de Entwicklung von Tcl (Abküzung fü Tool Command Language) wude vo allem daauf geachtet eine wiedevewendbae Befehlsspache zu scheiben. De Ken von Tcl besteht aus eine Bibliothek von C-Pozeduen. Sie ist eine leicht eweitebae Spache, die hauptsächlich als Kontoll- und Eweiteungsspache benutzt wid. Anwendungen weden aus eine Kombination von bestehenden und einigen neuen Funktionen geschieben. Tcl vefolgt das Motto: Eveything is a sting.. Tcl eignet sich fü Stingmanipulationen und patten matching mit Hilfe von eguläen Ausdücken. Tcl wid abe hauptsächlich wegen seines X Window Toolkits Tk (spich tee-kay ) vewendet. Tk ist eine gafische Eweiteung von Tcl. Sie emöglicht auf eine einfache Weise, gafische Benutzeintefaces zu scheiben. Auch Tk besteht wie Tcl nu aus einigen gundlegenden Befehlen. Mit diesen Funktionen kann man seh einfach gafische Objekte ezeugen, welche Widgets genannt weden. Diese Widgets lassen sich duch einen Geometie-Manage gestalten, damit man auf einfache Weise das Layout ehält. Tk elaubt gafische Benutzeschnittstellen zu estellen und diese mit eine Tcl-Applikation zu kombinieen.

28 18 KAPITEL 3. SKRIPT-SPRACHEN 3.4 Python Python 1 wude von Guido van Rossum wähend den Weihnachtsfeien 1989/1990 entwickelt (vgl. [vr96]). Python wude zum Testen des neu entwickelten, veteilten Betiebssystems Amoeba 2 vewendet. Bei de Pogammieung von Python wude besondeen Wet auf die Eweitebakeit de Spache und deen Pogamme gelegt. In Python vehalten sich Funktionen, Klassen, Methoden und Module wie Daten, das heisst man kann sie auch als Agumente an Funktionen übegeben. Man nennt das auch fist class values. Python ist eine intepetiete, objektoientiete Pogammiespache (vgl. [Lut96] und [vlf97]). Mehfachveebung (multiple inheitance) wid untestützt, das heisst eine Klasse kann mehee Basisklassen haben. Die Syntax von Python ist kuz und seh aussagekäftig. De Pogammcode ist imme schön fomatiet, da in Python die Blockstuktu duch das Einücken gebildet wid. Auf eine Zeile steht nomaleweise nu ein Kommando, das hat zu Folge, dass die Pogamme viel besse lesba sind. Python hat eine automatische Speichevewaltung. De Pythonintepete ist seh fehletoleant, das heisst, e untestützt einen Ausnahmebehandlungsmechanismus mit ty- und except-anweisungen. Fehle in Pogammen können auf diese Weise sanft abgefangen weden. Es gibt veschiedene Möglichkeiten die Agumente eine Methode zu definieen. Man untescheidet wie folgt: Agumente können als optional deklaiet weden, das heisst man kann Standadwete fü die Agumente (default aguments) angeben. Beim Methodenaufuf können die Agumente mit Standadweten auch weggelassen weden. def add(a=1, b=1): könnte zum Beispiel de Kopf eine Methodendefinition sein, die zwei Zahlen addiet. Eine Methode kann auch mit vaiable Anzahl Agumente deklaiet sein. Die Anzahl de Agumente wid beim Methodenaufuf bestimmt. def sum(*ags): könnte zum Beispiel de Kopf eine Methodendefinition sein, die eine Liste von Zahlen zusammen summiet. Die Agumente können auch als ungeodnete Menge definiet weden. Beim Methodenaufuf baucht man dann sogenannte Schlüsselwotpaamete, da die Reihenfolge de Agumente keine Rolle spielt. def eg(**sw): könnte zum Beispiel de Kopf eine Methodendefinition sein. Mit eg(name= ]] Held]], gösse=182) könnte eine Peson egistiet weden. 1 De Name Python kommt von de bitischen Comedy-Tuppe: Monty Pythons Flying Cicus. 2 Amoeba entstand 1981 an de Vije Univesität von Amstedam, Niedelande, in einem Foschungspojekt im Beeich de veteilten und paallelen Beechnung unte de Leitung von Andew S. Tanenbaum.

29 3.4. PYTHON 19 Es gibt natülich auch ganz nomale Agumente, wie bei andeen Pogammiespachen auch. In Python gibt es zwei dynamische Konstukte: Die exec-anweisung emöglicht, Anweisungen zu Laufzeit auszufühen, wie zum Beispiel: >>> exec "pint 7" 7 Um Ausdücke dynamisch auszuweten, vewendet man die Funktion eval. Ein mögliche Ausduck sieht wie folgt aus: >>> eval("1+2") 3 Python ist nicht nu eine Skipt-Spache, denn sie eignet sich auch ausgezeichnet fü das Estellen von gossen Applikationen. Die Gafik 3.2 von Cameon Laid und Kathyn Soyiz (vgl. [LS98a]) zeigt diese Auspägung von Python seh schön. Scipting Languages Tcl Awk Java Pel Python C Rexx C++ Systems Languages Abbildung 3.2: Python, die Skipt- bzw. System-Pogammiespache Einige de wichtigsten Mekmale von Python als Skipt-Spache sind nachfolgend aufgezählt: intepetiet, bzw. compiliet zu Byte-Code automatische Speichevewaltung dynamisch typisiet

30 20 KAPITEL 3. SKRIPT-SPRACHEN Eigenschaften von Python als taditionelle Pogammiespache sind: Objekt-oientiet, Mehfachveebung, Polymophie Spachanbindungen (language mapping) an CORBA (ILU, Fnob) und COM/ActiveX (PythonWin) Python kann sowohl im inteaktiven Modus als auch in einem Skipt als Pogamm ausgefüht weden. Die inteaktive Abeitsweise sieht wie folgt aus: Python (#14, Oct , 11:33:24) [GCC 2.7.2] on sunos5 Copyight Stichting Mathematisch Centum, Amstedam >> pint "Hallo Welt!" Hello Wold! >>> def inc(x):... etun x+1... >>> map(inc, ange(5, 33, 3)) [6, 9, 12, 15, 18, 21, 24, 27, 30, 33] >> Ein Pythonpogamm (auch Skipt genannt) wid in eine Datei gespeichet. Auf diese Weise kann dieselbe Befehlsfolge mehee Male ausgefüht weden. Kleine Skipts eignen sich vo allem zum Testen von andeen Pogammen. Python ezeugt beim esten Pogammduchlauf einen Plattfom unabhängigen Byte-Code. Die Abbildung 3.3 zeigt ein Beispiel eines Pythonpogammes, das das Suchen und Esetzen eines Stings in eine angegebenen Datei emöglicht. Es ist ein gosse Pluspunkt von Python, dass umfangeiche Bibliotheken vohanden sind. Es wude bei de Entwicklung von Python daauf geachtet, dass de Spachken möglichst klein gehalten wude. Mit Hilfe von Modulen gelang es die eigentliche Spache zu entlasten. Die Bibliothek enthält vo allem die folgenden Modul-Guppen: Stings, zum Beispiel sting, egex ode egsub Betiebssystem, etwa os, time ode socket UNIX: posix ode pwd Intenet: cgi, ullib ode ftplib Multimedia, wie zum Beispiel audioop, jpeg ode imageop GUI: Tkinte, stdwin ode ect Python besitzt in Pythonwin 3 eine DCOM-Integation. Diese Integation befindet sich abe noch in einem expeimentellen Status (vgl. [vlf97]). In Zukunft wid es seh wichtig sein, Komponenten von veschiedenen Autoen in einem System zu integieen. Solche Aufgaben weden 3 Pythonwin ist eine Vesion von Python. Es ist ein eines Windows-Pogamm, das von Mak Hammond unte Visual C++ entwickelt wude.

31 3.4. PYTHON 21 # seach and eplace a sting in a file # Standad/built-in modules. impot sting, sys, os # Function def seach_eplace(x, y, z): # x: text to scan # y: sting that has to be eplaced # z: eplacing sting l = sting.splitfields(x, y) etun sting.joinfields(l, z) # Main if name == main : # is thee a file and two stings? if (len(sys.agv[1:])< 3): # no pint "usage: seach_eplace.py <file> <seach> <eplace>" elif (len(sys.agv[1:]) == 3): # yes filename = sys.agv[1] seach = sys.agv[2] eplace = sys.agv[3] # is filename eally a file? if (os.path.isdi(filename)==0 and os.path.isfile(filename)==1): f = open(filename) text = f.ead() f.close() pint seach_eplace(text, seach,eplace) else: pint "The fist agument must be a file!" else: # no pint "usage: seach_eplace.py <file> <seach> <eplace>" Abbildung 3.3: Ein Python-Skipt: Suchen und esetzen von Wöten in eine Datei. mit veteilte Pogammieung gelöst und dazu kann Middlewae wie DCOM ode CORBA vewendet weden. Etwas besse sieht es mit de Middlewae CORBA aus. Mit dem ILU (Inte Language Unification) von de Fima Xeox (vgl. [JS97]) und dem Fnob de Univesität von Queensland aus Austalien (vgl. [Chi98]) besitzt Python zwei echt zuvelässige ORBs. Leide ist die Anbindung (language mapping) von IDL nach Python noch kein Standad. In Python Language Mapping eichten Matin Löwis, Bill Janssen und Matin Chilves (vgl. [CJvL98]) einen Voschlag fü diese Abbildung de OMG ein (Stand de Skipt-Spachen-Anbindung an CORBA vgl. im Anhang B.6). Fü das Intenet sind vo allem sogenannte CGI-Skipts (Common Gateway Inteface) von gosse Bedeutung. Mit Python kann man seh einfach solche Skipts scheiben (vgl. [WvRA96]). CGI ist eine Schnittstelle zwischen einem Web-Seve und einem extenen Pogamm. De Web- Seve statet das extene Pogamm (CGI-Skipt) und übegibt ihm die Umgebungsvaiablen. Python enthält in seine Standadbibliothek ein Modul cgi. Dieses Modul veeinfacht das Lesen und Veabeiten de Umgebungsvaiablen. Nach de Veabeitung ezeugt das Pogamm eine HTML-

32 22 KAPITEL 3. SKRIPT-SPRACHEN Antwot. Es hat sich in de Vegangenheit gezeigt, dass die Benutze liebe mit gafischen Obeflächen abeiten als mit kommandozeilenoientieten Pogammen. Python bietet veschiedene Möglichkeiten ein GUI (gaphical use inteface) zu estellen. Gundsätzlich gibt es zwei Lage. Estens gibt es Module, die auf de Micosoft Foundation Class (MFC) und nu auf Micosoft-Betiebssystemen laufen. Und zweitens hat man veschiedene Module die auf Tcl/Tk basieen wie zum Beispiel das Modul Tkinte. Mit diesem Modul kann man seh einfach eine gafische Benutzeobefläche estellen. Zusammenfassend weden anschliessend die wichtigsten Eigenschaften von Python heausgehoben, die in einem Komponenten Famewok benötigt weden: Komponenten können einfach zusammengestellt und vebunden weden (composition). Python eignet sich um Komponenten zu adaptieen (Gluing). Es können seh einfach gafische Benutzeobeflächen estellt weden. Python eignet sich fü das Testen von Komponenten. Komponenten können dynamisch ausgefüht weden.

33 Kapitel 4 CORBA Communication softwae and distibuted sevices fo next geneation applications must be eliable, efficient, flexible, and eusable. These equiements motivate the use of the Common Object Request Boke Achitectue (CORBA). Silvano Maffeis and Douglas C. Schmidt 4.1 Einleitung Als man noch mit Mainfame-Systemen abeitete, wa jede Benutze übe ein Teminal mit einem zentalen Rechne vebunden. Mit stetig steigende Anzahl von Benutzen und zunehmende Komplexität de Anwendungen wuden Rechne mit eine imme gösseen Leistung vewendet. Mit de Zeit wuden fü gewisse Abeiten imme meh peisgünstige, leistungsstake Mikoechne (PC) eingesetzt. Das fühte dazu, dass man alltägliche Abeiten, wie zum Beispiel Biefe scheiben ode Tabellen estellen, auf dem PC eledigte und fü Hauptgeschäftsanwendungen mittels Teminal auf den Mainfame zugiff. Duch die Entwicklung von Netzwektechniken entstand die Möglichkeit, Rechne auch übe gosse Entfenung miteinande zu vebinden. Eineseits können nun PC s mit PC s und andeseits auch PC s mit Mainfames vebunden weden. Fü den Zugiff auf einen entfenten Rechne wuden daaufhin sogenannte Client/Seve-Achitektuen entwickelt. De Gund fü diesen Wandel liegt in den vielen Voteilen die veteilte Anwendungen im Gegensatz zu den Mainfames bingen (vgl.[tan95]). Am Anfang de Client/Seve-Äa entwickelte man Systeme, bei denen de Client einen diekten Zugiff auf den Seve hatte. Man nannte sie auch 2-Tie 1 Achitektuen (vgl. Abbildung 4.1). De Client enthielt die ganze Anwendungs- und Päsentationslogik. De Seve veabeitete lediglich spezifische Anfagen und fühte zum Beispiel eine Datenbankabfage ode eine spezielle Beechnung duch. Auf Gund dieses Ungleichgewichtes zwischen Client und Seve entstand auch de Name Fat Client. Diese 2-Tie Achitektuen hatten folgende Nachteile: 1 engl. fü Stufe, das heisst zweistufig 23

34 24 KAPITEL 4. CORBA Client Seve Abbildung 4.1: 2-Tie Achitektu inhäente Komplexität de Entwicklung veteilte Anwendungen kleinee Leistung von Seven, was oft zu Leistungsengpässen fühte Sicheheitspobleme gosse Netzwekbelastung In eine weiteen Stufe baute man 3-Tie Client/Seve-Systeme. Das bedeutete fü die Clients, dass sie nicht meh diekt auf den Seve zugeifen konnten, da eine weitee Schicht, eine sogenannte Applikationslogik, dazwischen gelegt wude. De Client bestand nu noch aus de Päsentationslogik und wude demzufolge Thin Client genannt. Die Abbildung 4.2 vedeutlicht diese neue Achitektu. Seit einige Zeit baut man n-tie Achitektuen (vgl. Abbildung 4.3). In gösseen Systemen dängt es sich auf, dass die Applikationslogik nicht nu aus einem iesigen Gebilde besteht. Eine gössee Anzahl kleinee Dienste entstanden aus de gossen Applikationslogik. Ein solche modulae Dienst kann unabhängig von andeen Diensten entwickelt weden. Die Gesamtheit alle diese Dienste epäsentiet die Applikationslogik. Clients Seve Datenbank Applikationslogik Manifame Abbildung 4.2: 3-Tie Achitektu n-tie Achitektuen vespechen die nachfolgenden Vebesseungen:

35 4.2. ARCHITEKTUR 25 bessee Lastveteilung geingee Netzwekbelastung Diese n-tie Achitektuen haben abe nicht nu Voteile, hie einige Nachteile: hohe Administationsaufwand unzueichende Entwicklungs- und Watungswekzeuge n-tie Achitektuen weden duch die Middlewae-Technologie untestützt. Die heute bekanntesten Typen von Middlewae sind CORBA, COM und RMI (vgl. Abschnitt 2.2 auf Seite 5). Clients Seve Dienst A Datenbank Dienst B Manifame Dienst C Abbildung 4.3: n-tie Achitektu 4.2 Achitektu CORBA ist die Abküzung fü Common Object Request Boke Achitectue. Ein Standad entsteht in de Infomatik nomaleweise aus einem Podukt (meist eine einzelnen Fima), das sich bewäht hat. Ganz andes ist es mit CORBA. Diese Achitektu wude inteessanteweise von einem Konsotium, de Object Management Goup (kuz OMG), und nicht von eine einzelnen Fima definiet. Die OMG wude 1989 gegündet und hat heute übe 750 Hestelle und Fimen als Mitgliede. CORBA ist keine Implementieung sonden lediglich eine Spezifikation. Die Implementieung diese Spezifikation liegt bei den einzelnen ORB-Hestellen (Object Request Boke). Die einzelnen ORBs weden von unteschiedlichen Hestellen entwickelt und sind dahe nicht hundetpozentig kompatibel. Die OMG vefolgt die folgenden zwei Ziele (vgl. [OMG97b] und [VD97]): Födeung de objektoientieten Technologie in de Softwae Entwicklung. Entwicklung eines gemeinsamen achitektonischen Famewoks fü veteilte, objektoientiete Applikationen basieend auf eine Inteface Spezifikation.

36 26 KAPITEL 4. CORBA Die Common Object Request Boke Achitectue (CORBA) definiete einen ORB-Standad gemäss dem OMA-Refeenzmodell. Die OMG veöffentlichte 1991 die este CORBA-Spezifikation CORBA 1.1. CORBA 2.0 wude im Jahe 1995 veöffentlicht und vespach Inteopeabilität zwischen den veschiedenen ORBs (Hestelle übegeifend). Die Abbildung 4.4 zeigt die Beziehung zwischen Betiebssystem, Pogammiespache und CORBA. Duch die Middlewae CORBA weden eine Pogammiespache Teile de Kommunikation mit dem Betiebssystem veeinfacht ode ganz abgenommen. Pogammiespache CORBA Betiebssystem Netzwek Abbildung 4.4: CORBA liegt zwischen Applikation und Betiebssystem OMA Guide (Object Management Achitectue Guide) In de OMA wid ein Middlewae-Refeenzmodell beschieben. Dieses Refeenzmodell fü veteilte objektoientiete Applikationen wude von de OMG estellt und enthält eine umfassende Bescheibung, wie dieses Softwaesystem aussehen soll. Die Abbildung 4.5 stellt die Achitektu de OMA da. Die OMA (vgl.[oh97] und [OMG97b]) besteht aus den folgenden Elementen: Im Zentum steht de Object Request Boke (ORB). E emöglicht eine tanspaente Kommunikation zwischen den Objekten. Object Sevices definieen eine Sammlung von Diensten, welche in Fom von Schnittstellen beschieben sind. Diese Dienste können unabhängig vom Anwendungsgebiet von allen Objekten benutzt weden. Die Common Facilities definieen spezialisiete und anwendungsspezifische Funktionalitäten, wie zum Beispiel das Distibuted Document ode die Time Facilities. Die Domain Intefaces sind eine Sammlung von Diensten. Sie wuden fü bestimmte Anwendungsgebiete definiet, wie zum Beispiel fü Poduktionspozesse ode das Gesundheitswesen.

37 4.2. ARCHITEKTUR 27 Application Inteface sind die Podukte de Anwende. Die Application Objects sind die fü eine veteilte Anwendung entstandenen Objekte. ``` ``` ``` aaa aaa bbb bbb ccc ccc Application Intefaces d d d d e e e e f f f f g g g g Domain Intefaces ll llm ll l l lm m l lm m mm lmm jjk jj j jk k j jk k kk jkk Object Sevices Object Request Boke ^^^ ^^^ ^^^ hhh hhh hhh iii iii iii Common Facilities Abbildung 4.5: OMA-Refeenzmodell Im folgenden weden die einzelnen Elemente des OMA-Refeenzmodells noch genau eläutet. ORB (Object Request Boke) Ein ORB ist ein logische Objektbus, de die einzelnen Komponenten übe mehee Rechne hinweg vebindet. De ORB emöglicht zwischen CORBA-Objekten (Komponenten mit einem Anschluss an einen ORB) eine tanspaente Kommunikation. Das Client-Objekt baucht wede zu wissen, wo sich das Seve-Objekt befindet, noch muss ein Pot angegeben weden, um mit dem Seve-Objekt zu kommunizieen. Fü den Client spielt es keine Rolle, ob sich de CORBA-Seve lokal ode auf einem entfenten Rechne befindet, de ORB übenimmt die Kommunikationsaufgaben. Die Tennung von Inteface und Implementieung und die spachneutalen Datentypen emöglichen es CORBA, spach-, betiebssystem- und hadwaeunabhängig zu sein. Die Abbildung 4.6 zeigt wie zum Beispiel ein Client, in Java pogammiet, Methoden eines C++-Seves vewendet. De ORB vebindet die zwei Komponenten und übenimmt die Kommunikation. Ein CORBA ORB emöglicht sowohl einen statischen als auch einen dynamischen Methodenaufuf. Statische Methodenaufufe weden vo de Kompilation definiet und können nach de Kompilation nicht meh veändet weden. Duch die Möglichkeit eine Methode dynamisch zu ufen, ehält man maximale Flexibilität, in dem man die Methode est zu Laufzeit bindet (late binding) ode vo dem Gebauch eines Objektes die Funktionalität efoscht (un-time discoveing).

38 28 KAPITEL 4. CORBA Host A Java n n o o n n o o n n o o Client ppp ppp ppp qqq qqq C++ Seve Host B eplay equest ORB Abbildung 4.6: Methodenaufuf übe den ORB Common Object Sevices De CORBA Standad stellt einen Rahmen fü die Realisieung von veteilten Applikationen zu Vefügung. Die OMG definiete die Common Object Sevices (auch Dienste ode CORBA Sevices genannt) um die Softwae-Entwicklung zu eleichten. Diese Dienste bieten den Softwae- Entwicklen egänzende Möglichkeiten wie zum Beispiel das Vewalten von Objekten ode Daten. Alles in allem wid es fünfzehn veschiedene CORBA Sevices geben (vgl. Tabelle 4.1), abe leide sind noch nicht alle Dienste spezifiziet und dahe nu wenig implementiet. Nachfolgend weden einige Dienste kuz beschieben (fü eine ausfühliche Einfühung vgl. zum Beispiel [EFA96]): De Naming Sevice emöglicht das Refeenzieen von Objekten mit einem eindeutigen Namen innehalb eines veteilten Namensaumes. Die Reichweite dieses Telefonbuchähnlichen Dienstes ist beschänkt auf den jeweiligen ORB. De Namensdienst ist eine de wenigen CORBA Dienste, die schon fast in jedem ORB vohanden sind. De Event Sevice emöglicht die Entkoppelung de Kommunikation zwischen Client und Seve. Übe einen Eeignis-Kanal weden Eeignisse gesammelt und anschliessend wiede veteilt, so dass die beteiligten Komponenten nichts voneinande wissen müssen. De Lifecycle Sevice besteht aus Standadschnittstellen, die definieen, wie Objekte ezeugt, gelöscht, kopiet ode auch bewegt weden. De Tansaction Sevice emöglicht die Entwicklung von zuvelässigen, veteilten Applikationen. In diesem Dienst weden sogenannte ACID 2 -Tansaktionen definiet. Common Facilities Die Common Facilities, fühe auch Hoizontal Famewok genannt, definieen eine Sammlung von Schnittstellenbescheibungen eines Famewoks. Diese Sammlung von endanwendungsoientieten Diensten kann in einem beiten Beeich von Anwendungen eingesetzt weden. Die meisten 2 ACID steht fü Atomicity, Consistency, Isolation und Duability.

39 4.2. ARCHITEKTUR 29 Dienst Naming Sevice Event Sevice Life Cycle Sevice Pesistence Sevice Relationship Sevice Extenalization Sevice Tansaction Sevice Concuency Contol Sevice Licensing Sevice Quey Sevice Popeties Sevice Secuity Sevice Time Sevice Collections Sevice Tade Sevice Ekläung Identifikation von Objekten duch einen Namen Sammeln und Veteilen von veteilten Eeignissen Standad Opeationen fü Komponenten Speicheung von Komponenten Guppieung von Komponenten Mechanismen von Komponenten fü Dateninput/-output Koodination von Komponenten Koodination von nebenläufigen Pozessen Gebauchs- und Beechnungskontolle (Messinstument) SQL-ähnliche Komponentenabfage Dynamische Zuodnung von Eigenschaften Zugiffskontolle Synchonisation de Uhzeit Ezeugung und Beabeitung eine Sammlung von Komponenten Publikation von Diensten Tabelle 4.1: Auflistung alle CORBA Dienste de einzelnen Dienste sind konfiguieba. Common Facilities bieten zum Beispiel ein Dokumentenmanagement fü veteilte Dokumente ode eine Pozessablaufsteueung. Domain Intefaces Die Domain Intefaces bieten vo allem banchenspezifische Dienste an, wie zum Beispiel in den Beeichen des Intenets, de Telekommunikation ode des Finanzwesens. Fühe nannte man diese Dienste auch Vetical Famewok, da sie hauptsächlich fü bestimmte Anwendungsgebiete definiet wuden wuden diese ehe banchenspezifischen Dienste von den Common Facilities getennt Aufbau eines CORBA ORBs De ORB wude bishe imme nu als eine Einheit dagestellt, wie in Abbildung 4.5 auf Seite 27 esichtlich. De CORBA ORB setzt sich bei genaue Betachtung abe aus meheen Bestandteilen zusammen gemäss Abbildung 4.7. De ORB ebingt die Kommunikation zwischen Client und Seve. Diese Kommunikation efolgt mit Hilfe de veschiedenen Schnittstellen, die die einzelnen Bestandteile anbieten und einem ORB-Agent (daemon pocess). Die Schnittstellen Dynamic Invocation Inteface, Dynamic Skeleton Invocation, Basic Object Adapte und de ORB Ken liegen als vogefetigte Komponenten in eine Bibliothek vo. De Stub und das Skeleton weden aus dem IDL-Inteface (siehe unten)

40 30 KAPITEL 4. CORBA Client Seve Object Implementation Inteface Repositoy Dynamic Invocation Client IDL Stub ORB Inteface Static Skeleton Dynamic Skeleton Invocation Object Adapte Implementation Repositoy Object Request Boke Coe Abbildung 4.7: Die Stuktu eines ORBs duch einen Compile automatisch ezeugt. Nachfolgend weden die Aufgaben de einzelnen Bestandteile eines ORBs eläutet: De ORB Ken (Object Request Boke Coe) bietet vielseitige Dienste fü den Client und den Seve. E hilft zum Beispiel den Basic Object Adapte (BOA) zu initialisieen ode eine Objektefeenz in einen Sting umzuwandeln (object to sting()-methode) (vgl. Absatz 4.3.4). Das Implementation Repositoy speichet die Pogamme, zum Beispiel die Java-Byte-Code Dateien. Assoziationen zwischen Objekten und Seve weden mit idle ode unning vemekt. Das Implementation Repositoy ist noch nicht spezifiziet, das heisst es ist von ORB zu ORB veschieden. De Basic Object Adapte wude in CORBA 2.0 definiet. Seine Hauptaufgabe ist die Aktivieung und Deaktivieung von Seveobjekten. De Stub wid automatisch aus dem IDL-Inteface geneiet. De Client kann mit Hilfe eines Stubs einen statischen Methodenaufuf ezeugen. De Stub übenimmt das Mashaling (vgl. Absatz 4.3.2) bei einem Methodenaufuf. Das Dynamic Invocation Inteface (DII) emöglicht einen dynamischen Methodenaufuf, das heisst es wid kein Stub benötigt. Das DII definiet eine Pseudo-IDL-Schnittstelle. Diese Schnittstelle elaubt ein Seveobjekt zu efeenzieen, sowie Methoden und deen Agumente zu setzen. Diese Infomationen weden duch den Aufuf eine DII-Methode (invoke) zum Seveobjekt übetagen. Das Skeleton wid wie de Stub automatisch aus dem IDL-Inteface ezeugt. Es liegt zwischen BOA und CORBA-Seve. Das Skeleton tansfomiet die empfangenen Datenpakete in den entspechenden Methodenaufuf (Unmashaling). Die Dynamic Skeleton Invocation nimmt Anfagen des DII entgegen und ezeugt einen dynamischen Opeationsaufuf beim Seveobjekt.

41 4.3. EIGENSCHAFTEN 31 Im Inteface Repositoy weden die Intefaces de Seveobjekte abgespeichet. Ohne diese Infomationen könnten die Methoden nicht dynamisch aufgeufen weden. 4.3 Eigenschaften IDL (Inteface Definition Language) CORBA ist wede an eine bestimmte Pogammiespache noch an eine Hadwae noch an ein bestimmtes Betiebssystem gebunden. Diese Unabhängigkeit wid duch die Tennung von Inteface und Implementieung eeicht. Jedes CORBA-Seve-Objekt hat eine kla definiete Schnittstellenbescheibung. Diese Schnittstellen weden in eine Inteface Definition Language (IDL) deklaiet. Die IDL ist eine ein deklaative Spache, welche ausschliesslich zu Bescheibung de Objektschnittstellen vewendet wid. Die IDL wude von de OMG spezifiziet und hat gosse Ähnlichkeit zu de Syntax von C++. Die Tabelle 4.2 gibt einen Übeblick übe die OMG-IDL Spezifikation. Die IDL-Spezifikation kann in die folgenden vie Aspekte aufgeteilt weden: Datentypen weden zusammengesetzt aus den Basistypen, den zusammengesetzten Typen und den Templatetypen. Attibute und Methoden definieen die Aktionen, die ein Seve-Objekt zu Vefügung stellt. Ein Attibut ist eine einfache Möglichkeit, zwei Methoden (get und set) zu ezeugen, die auf eine einzelne Vaiable zugeifen. Ein Inteface definiet die Schnittstelle zu einem Seve-Objekt. Eine Schnittstelle kann von eine andeen Schnittstelle eweitet weden. Ein Modul fasst Schnittstellen und Deklaationen zusammen und wid in einen eigenen Namensaum (scope) abgelegt. Die Abbildung 4.8 zeigt ein Modul Math mit dem IDL-Inteface ComplexIF. Das Modul bescheibt das Inteface in einem eigenen Namensaum, damit es keine Namenskonflikte gibt Spachanbindung (Language mapping) CORBA-Seve-Objekte definieen ihe Schnittstellen duch die Inteface Definition Language. Jede Pogammiespache benötigt fü seine Spachkonstukte eine Abbildung (language mapping) in die entspechenden Typen de IDL. Die Tabelle 4.3 auf Seite 34 zeigt als Beispiel die Abbildung von IDL nach Java. Man vewendet diese Abbildung, um aus einem Inteface den entspechenden Pogammcode zu ezeugen. Diese Pogammcode weden duch einen Compile, zum Beispiel einen IDL nach Java Compile (idl2java), automatisch ezeugt. De Pogammcode übenimmt nun die ganze Kommunikation zwischen Client und Seve, wie zum Beispiel Kommunikationsaufbau, Umwandlung de Datenstuktuen in einen Byte-Steam (Mashaling) ode

42 32 KAPITEL 4. CORBA OMG-IDL Eläuteung Basistypen shot 16-bit 2e Komplement (ohne Vozeichen) Intege unsigned shot 16-bit 2e Komplement (mit Vozeichen) Intege long 32-bit 2e Komplement (ohne Vozeichen) Intege unsigned long 32-bit 2e Komplement (mit Vozeichen) Intege float 16-bit IEEE floating point numbe double 32-bit IEEE floating point numbe octet 8-bit unintepeted type cha ISO Latin-1 Chaacte boolean Boolean mit TRUE und FALSE any igendein IDL-Typ Zusammengesetzte Typen enums Aufzähltyp mit Integeweten (Constuctet types) stuct fü die Deklaation neue Datentypen disciminated union Deklaation eines Auswahltyps Templatetypen sequence geodnete Kollektion; unbestimmte Anzahl Elemente sting Sting mit vaiable Länge (fixed at un-time) aay Ein Aay mit feste Länge und bestimmten Typ Inteface inteface Definiet Schnittstelle eines Objekts Inheitance specification Eben eines Intefaces type declaation Deklaation neue Datentypen constant declaation Konstantendeklaation exception declaation Deklaation von Ausnahmen attibute declaation Attibutdeklaation opeation declaation Methodendeklaation Module module Definition eines eigenen Namensaumes (scope) type declaation Deklaation neue Datentypen constant declaation Konstantendeklaation exception declaation Deklaation von Ausnahmen inteface declaationen Intefaces module declaationen Schachtelung von Modulen Tabelle 4.2: Die IDL-Spezifikation

43 4.3. EIGENSCHAFTEN 33 // IDL- Inteface of complex numbes // Declaation of a module: module Math{ // Declaation of an exception exception ZeoDivisionEo{ sting name; }; // Declaation of a datastuctue stuct Complex{ float e; float im; }; // Declaation of the inteface: inteface ComplexIF{ Complex add(complex z1, Complex z2);... Complex div(complex z1, Complex z2) aises ZeoDivisionEo; }; }; Abbildung 4.8: IDL-Beispiel: Komplexe Zahlen Methodenaufuf Inteopeabilität De ORB selbst ist das Kommunikationsmedium zwischen Anwendungen. E ist auch fü die Inteopeabilität von Pogammiespachen und Plattfom unabhängige Anwendungen zuständig. Benutzt man abe ORBs von veschiedenen Hestellen, so weden weitee Konzepte benötigt. Die Inteopeabilität zwischen veschiedenen ORBs basiet auf den zwei folgenden Elementen (vgl. Abbildung 4.9 und [SAT98]): Das Intenet-Inte-ORB-Potocol (IIOP) definiet ein Kommunikationspotokoll gemäss dem Geneal-Inte-ORB-Potocol (GIOP). Die OMG definiete est in CORBA 2.0 das abstakte Potokoll GIOP. Die Inte-ORB Refeence (IOR) emöglicht eine weltweit eindeutige Refeenzieung de CORBA-Objekte. Diese eindeutige Refeenz enthält die Intenetadesse des Objektes, eine Pot-Numme und eine ORB-abhängige Objektidentifikation.

44 34 KAPITEL 4. CORBA OMG-IDL Java (VisiBoke) Basistypen long int unsigned long int shot shot unsigned shot shot float float double double octet byte cha cha boolean(true, FALSE) boolean(tue, false) any Klasse CORBA.any(og.omg.CORBA.Any) Constuctet types enums Klasse mit static final enum Wet stuct Klasse mit Instanzvaiable und Konstukto disciminated union Klasse mit get und set Methoden fü die Felde Templatetypen sequence aay sting java.lang.sting aay aay Inteface inteface inteface exception Klasse mit Instanzvaiable, eweitet CORBA.UseException Module module packages Tabelle 4.3: IDL nach Java Mapping Dynamische Methodenaufuf Ein CORBA-Client kann mit Hilfe des Dynamic Invocation Inteface (DII) dynamisch Methoden aufufen, das heisst, de Client kann auch ohne das compiliete Inteface, den Stub, auskommen. De Client ezeugt einen Request, de dann dynamisch ausgewetet wid. Diese Request enthält die Infomationen übe die Objektefeenz, den Methodennamen sowie Datentypen und Wete de Agumente. De Client kann diese Infomationen duch das Inteface Repositoy elangen. Im nachfolgenden Pogammcode wid exemplaisch ein dynamische Methodenaufuf eines CORBA-Client in Java mit dem VisiBoke aufgezeigt:... // get object efeence with a stingified object efeence (io) CORBA.Object obj = ob.sting_to_object(io); // get the inteface definition fom Inteface Repositoy CORBA.IntefaceDef int_def = obj._get_inteface();

45 4.3. EIGENSCHAFTEN 35 s s t t s s t t s s t t CORBA Objekt A uuu uuu uuu vvv vvv vvv CORBA Objekt B ORB X IIOP CORBA 2.0 ORB Y Abbildung 4.9: Inteopeabilität // get full inteface desciption CORBA.IntefaceDef_.FullIntefaceDesciption full_int_def = int_def.descibe_inteface(); // using the DII to make an invocation // ceate a suppot object DiiAnySuppot dii_any_suppot = new DiiAnySuppot(); // ceate and initialize esult NVList esult_list = ob.ceate_list(0); esult_list.add_value("", dii_any_suppot.tc2any( full_if_desc.opeations[0].esult, PaameteMode._PARAM_OUT ),0 ); // ceate and initialize an agumentlist fo the equest NVList ag_list = ob.ceate_list(0); ag_list.add_value(full_if_desc.opeations[0].paametes[i].name, dii_any_suppot.tc2any(full_if_desc.opeations[0].paametes[i].type...); // ceate equest CORBA.Request equest = obj._ceate_equest(...); // invoke equest equest.invoke(); // get esult System.out.pintln("esult:\n " + equest.esult().value() ); An diesem Pogammcode fällt auf, dass ein Client bei einem dynamischen Methodenaufuf - genau gleich wie beim statischen Aufuf (vgl. nächste Abschnitt) - est den ORB initialisiet und danach mit Hilfe de sting to object-methode den Seve efeenziet. Danach sind die zwei Vefahen veschieden. De Client baucht nun die Untestützung des Inteface Repositoy um einen Request zu machen. Zwei Listen weden fü den Methodenaufuf benötigt: Eine Resultat- und eine Agumentliste. Um einen dynamischen Methodenaufuf zu machen, wid das Inteface Repositoy vewendet. Das Inteface Repositoy ist seit CORBA 2.0 standadisiet. Die ORB-Hestelle sollten eigentlich

46 36 KAPITEL 4. CORBA das Inteface Repositoy alle einheitlich implementiet haben. Somit sollte ein dynamische ORBübegeifende Zugiff auf die CORBA-Komponenten möglich sein. 4.4 Picing -Applikation - ein Beispiel Anhand eines Beispiels soll die Anwendung von CORBA dagestellt weden. Es wude bewusst ein einfaches Beispiel gewählt, um die eigentlichen Mechanismen de Estellung eine CORBA- Applikation mit statischen Methodenaufufen hevozuheben. De PicingSeve (vgl. Anhang C) ist eine in Java geschiebene Client/Seve-Applikation. Clients können beim Seve Peisinfomationen übe bestimmte Atikel ehalten. Ist de Atikel nicht in de Sevedatenbank enthalten, escheint die Meldung UnknownAticle. Diese CORBA-Applikation besteht aus den folgenden Dateien: Picing.idl : Definition des Intefaces des Picing Objektes Picing.java : Implementation de Picing-Klasse PicingSeve.java : CORBA Seve PicingClient.java : Implementation des CORBA-Client Je nach Hestelle gibt es veschiedene Vogehensmöglichkeiten, eine CORBA-Applikation zu estellen. De VisiBoke (vgl. [Vis97]) zum Beispiel bietet neben dem idl2java -Compile noch zwei weitee Hilfsmittel. Estens übesetzt ein sogenannte Caffeine -Compile (java2iiop) Java nach IDL, das heisst, das Inteface kann in Java geschieben weden und de Compile übesetzt anschliessend dieses Java-Inteface in ein IDL-Inteface. Zweitens ezeugt ein weitees Hilfsmittel (java2idl) aus eine bestehenden Applikation den IDL-Code. Diese Zusätze sind abe vom Hestelle angebotene Eweiteungen und kommen nicht bei jedem ORB vo. Nomaleweise estellt man eine CORBA-Applikation wie folgt: 1. Estellen eines IDL-Intefaces 2. Compilation des IDL-Codes zu Stub und Skeleton 3. Implementieung des Seves 4. Implementieung des Clients 5. Compilation des Client beziehungsweise des Seves 6. Seve staten 7. anschliessend den Client staten De IDL-Inteface-Code des PicingSeve -Beispiels sieht wie folgt aus:

47 4.4. PRICING -APPLIKATION - EIN BEISPIEL 37 // Picing.idl; IDL-Inteface fo a picing object // namespace "Stoe" module Stoe{ // exception fo non existing aticles exception UnknownAticle{}; inteface Picing{ float cost(in sting aticle) aises (UnknownAticle); }; }; //End module Dieses Inteface definiet das Modul Stoe, das fü dieses Inteface einen eigenen Namensaum keiet. Das Modul besteht aus eine Ausnahmen-Deklaation (exception) und dem Inteface Picing. Das Inteface enthält eine Methode, welche eine Ausnahme geneieen kann. Nach de Intefaceestellung folgt deen Compilation. idl2java heisst de Compile vom VisiBoke (VisiBoke fo Java). Die Compilation ezeugt den Stub und das Skeleton, sowie einige weitee Klassen, Module und Intefaces. In unseem Beispiel geht das folgendemassen: %idl2java Picing.idl Ceating: Stoe Ceating: Stoe/UnknownAticle.java Ceating: Stoe/UnknownAticleHolde.java Ceating: Stoe/UnknownAticleHelpe.java Ceating: Stoe/Picing.java Ceating: Stoe/PicingHolde.java Ceating: Stoe/PicingHelpe.java Ceating: Stoe/_st_Picing.java Ceating: Stoe/_sk_Picing.java Ceating: Stoe/_PicingImplBase.java Ceating: Stoe/PicingOpeations.java Ceating: Stoe/_tie_Picing.java Ceating: Stoe/_example_Picing.java De Stub (in unseem Beispiel Stoe/ st Picing.java) ist fü den Client zuständig. E zelegt Methodenaufufe des Clients in geeignete Datenpakete (Mashaling) und leitet sie weite an den ORB. Die Datenpakete gelangen duch den ORB zum Seve. Auf de Seite des Seves ist ein Skeleton (in unseem Beispiel Stoe/ PicingImplBase.java). Das Skeleton übenimmt die Datenpakete und setzt sie wiede zusammen. De Seve füht nun die aufgeufene Methode mit den entspechenden Agumente aus. Stoe/Picing.java und Stoe/UnknownAticle.java sind zwei geneiete Intefaces, die vom Stub beziehungsweise dem Skeleton benötigt weden. Die Estellung eines CORBA-Seves efolgt imme in zwei Schitten. Estens implementiet man die im Inteface definiete Klasse (hie Picing.java). Zweitens estellt man einen Seve, de das Picing-Objekt de CORBA-Welt zu Vefügung stellt. De Code de Picing-Klasse sieht wie folgt aus: // Picing.java; Java-Implementation of the Picing class

48 38 KAPITEL 4. CORBA class Picing extends Stoe._PicingImplBase { /** Constuct a pesistently named object. */ public Picing(Sting name){ supe(name); } /** Constuct a tansient object. */ public Picing(){ supe(); } public float cost(java.lang.sting aticle) thows Stoe.UnknownAticle { // the implementation in this methode is just a dummy // nomally hee would be a eal database access if (aticle.equals("apple")){ etun (float)1.2; } else if (aticle.equals("banana")){ etun (float)0.33; } else { // if it is not an apple o a banana aise an exception thow new Stoe.UnknownAticle(); } } } Die eigentliche Klasse implementiet das definiete Inteface und entspicht im wesentlichen eine ganz nomalen Java-Klasse. Es gilt zu beachten, dass die Klasse Picing von de Klasse Stoe. PicingImplBase ebt. Die Obeklasse Stoe. PicingImplBase ist das vom IDL-Compile ezeugte Skeleton. Die Picing-Klasse hat zwei Konstuktoen, die dann die Konstuktoen de Obeklasse aufufen. De este Konstukto hat einen Paamete, das elaubt diesem Objekt einen Namen zugeben (vgl. Naming Sevice zum Beispiel in [Sie96]). Es folgt de Code des PicingSeves: // PicingSeve.java public class PicingSeve { public static void main(sting[] ags){ ty{ // Initialize the ORB (Object Request Boke). og.omg.corba.orb ob = og.omg.corba.orb.init(); // Initialize the BOA (Basic Object Adapte) og.omg.corba.boa boa = ob.boa_init(); // Ceate an Object "FuitStoe" Picing fuitstoe = new Picing("FuitStoe"); // Expot the newly ceated object. boa.obj_is_eady(fuitstoe); System.out.pintln(fuitstoe + " is eady.");

49 4.4. PRICING -APPLIKATION - EIN BEISPIEL 39 } // Wait fo incoming equests boa.impl_is_eady(); } catch (og.omg.corba.systemexception e) { System.e.pintln("ERROR: " + e); } } // End main Die Seve-Klasse enthält eine main-methode, damit de Seve selbstständig gestatet weden kann. Diese Methode ist static, damit ein ORB efeenziet weden kann und sie elaubt das Übegeben von Agumenten. Das Innee de main-methode wid von einem ty-catch- Block umhüllt, damit die CORBA-Ausnahmen gefangen weden können. Zuest wid ein ORB mit ORB.init() efeenziet. Mit diese Refeenz kann nun auch de BOA (Basic Object Adapte) initialisiet weden. Ein Objekt de Klasse Picing wid ezeugt, das anschliessend vom BOA aktiviet und fü die CORBA-Welt egistiet wid. Schliesslich noch den Code des Clients: // PicingClient.java public class PicingClient{ public static void main(sting[] ags) { ty{ // Initialize the ORB. og.omg.corba.orb ob = og.omg.corba.orb.init(); // Locate the "FuitStoe" object Stoe.Picing pice_make = Stoe.PicingHelpe.bind(ob, "FuitStoe"); ty{ // invoke the method "cost" of the object "FuitStoe" System.out.pintln("An apple costs SF." + pice_make.cost("apple")); } catch(stoe.unknownaticle e){ System.out.pintln("\nThis fuit is not in the ange!") ; }; ty{ System.out.pint("A pineapple costs SF."+pice_make.cost("pineapple")); } catch(stoe.unknownaticle e){ System.out.pintln("\nSoy, but this fuit is not in the ange!") ; }; } catch (og.omg.corba.systemexception e) { System.out.pintln("ERROR : " + e) ; } } // end main } Die PicingClient-Klasse hat eine ähnliche Stuktu wie die PicingSeve-Klasse. De ORB wid efeenziet, damit danach das Seve-Objekt lokalisiet weden kann. Diese Lokalisation benutzt den Naming Sevice, das heisst dieses Objekt konnte duch den Namen Fuit- Stoe gefunden weden. De Aufuf de Methode cost muss mit eine Ausnahmebehandlung

50 40 KAPITEL 4. CORBA umgeben weden, da diese Methode eine Ausnahme ezeugen kann. De Client und de Seve weden nun compiliet. De Java-Compile ezeugt einen Byte- Code, de auf eine Java Vitual Machine ausgefüht weden kann. Die ausfühbae Applikation kann nun gestatet weden. Zuest wid de Seve gestatet und anschliessend de Client. Die Ausgabe des Seves sieht folgendemassen aus: %java PicingSeve Picing[Seve,oid=PesistentId[epId=IDL:Stoe/Picing:1.0, objectname=fuitstoe]] is eady. UnknownAticle aised! und die des Clients: %java PicingClient An apple costs SF.1.2 A pineapple costs SF. Soy, but this fuit is not in the ange! Es wude absichtlich ein einfaches Beispiel gewählt. Das Beispiel vewendet nu einen ORB mit eine Pogammiespache, damit das Vogehen anschaulich gezeigt weden kann. Inteopeabilität Um das FuitStoe-Objekt übe veschiedene ORBs hinweg zu vewenden, sind die folgenden zusätzlichen Schitte nötig: In de PicingSeve-Klasse muss man eine Refeenz des FuitStoe-Objektes ezeugen. Diese Refeenz wid zum Übetagen in einen hestelleunabhängigen Sting umgewandelt. De Sting wid IOR (Inte-ORB Refeence) genannt. Die IOR muss igendwie zum Client gelangen. Dies kann zum Beispiel in Fom eine URL- Adesse ode via eine Datei geschehen. De Client liest die IOR und wandelt diesen wiede in eine Objektefeenz um.

51 Kapitel 5 Poblemanalyse Die nachfolgende Analyse eötet die Poblematik de Middlewae CORBA. Auf einen Vegleich mit DCOM ode RMI wid vezichtet, da dies den Rahmen diese Abeit spengen wüde. Diese Untesuchung wid allgemein gehalten und geht nicht auf die unteschiedlichen COR- BA ORBs ein, da die Hestelle de einzelnen ORBs sich an den vogegebenen Standad halten. Zudem bieten einzelne Hestelle divese Eweiteungen, die nicht dem Standad entspechen. Dahe ist es sinnvoll, sich hauptsächlich auf die Spezifikation von CORBA 2.0 zu beziehen. CORBA ist eine Middlewae, die Pogammiespachenunabhängigkeit vespicht. Diese Technologie eignet sich fü die Pogammieung von veteilten, heteogenen Applikationen. Zudem vespicht man sich mit CORBA eine tanspaente Veteilung de Seveobjekte. Eine objektoientiete Achitektu bildet die Basis von CORBA. In diesem Kapitel weden die vespochenen Eigenschften von CORBA übepüft und die Schwachstellen aufgezeigt. 5.1 Pobleme von CORBA Ein estes Hello, Wold! geht in den meisten Fällen ohne gosse Pobleme. Leide ist das nicht so mit CORBA. Beim Elenen von CORBA fällt sofot auf, dass gewisse Kenntnisse efodelich sind, um das este Hello, Wold! scheiben zu können. De Weg zu diesem Einstiegspogamm ist mit divesen Schwieigkeiten vebunden, welche teilweise ga nichts mit de Pogammieung des Clients beziehungsweise des Seves zu tun haben. Meist ist nicht genau esichtlich, wo sich die Fehlequelle befindet, wie zum Beispiel die falsche Vesion des Betiebssystems ode ein Fehle in einem CORBA-Sevice. Divese Kitike haben sich schon mit den Poblemen von CORBA befasst. Sie deckten beim paktischen Gebauch veschiedene Mängel diese Middlewae auf. Im allgemeinen wid diese Standad als seh gut bewetet. Abe je nach Benutzungsfeld können zusätzliche Bedüfnisse an CORBA entstehen. Nachfolgend weden Meinungen ausgewählte Kitike aufgelistet. 41

52 42 KAPITEL 5. PROBLEMANALYSE In Client/Seve Pogamming with Java und CORBA listen Robet Ofali und Dan Hakey (vgl. [OH97]) folgende Schwachpunkte von CORBA auf: Die Spezifikationen von CORBA sind nu schlecht ode mangelhaft dokumentiet. Fü viele Pogammiespachen fehlen die IDL-Mapping-Standads. Fü Python zum Beispiel ist das Mapping (IDL-to-Python) noch nicht definitiv festgesetzt. Wie weden Seve skaliet? Es gibt keinen Mechanismus, de eine gosse Anzahl von Seven vewalten kann. Ein weitees ungelöstes Poblem stellt die Lastveteilung da. Hie handelt es sich um die Fage, wie ein stak belastete Seve die Abeit auf mehee Pozesse veteilen kann. Bei de Lösung von Mission-citical equiements wid de Anwende nicht von CORBA untestützt. Die Kommunikation zwischen Client und Seve kommt nu dann zustande, wenn beide gleichzeitig aktiv sind (synchone Kommunikation). CORBA hat keine asynchone message queue, welche vo allem fü heteogene Systeme von gossem Voteil wäe. Mit dem asynchonen Modus könnten sowohl Client als auch Seve voneinande unabhängig abeiten. Walte Bischofbege und Dik Riehle (vgl. [BR97]) unteteilen die Poblematik von CORBA in die dei Gesichtspunkte: Objektmodell, Softwae Achitektu und pagmatische Übelegungen. Sie untesuchen, ob CORBA zu Entwicklung von Anwendungssystemen taugt. Objektmodell: In de Spezifikation weden nu die einfachsten Aspekte von Objekten definiet. Es gibt nu wenig gemeinsame Standadfunktionalitäten fü alle Objekte. Eine Gundfunktionalität von de jedes Objekt eben muss, existiet nicht. Es fehlt ein allgemeines Zugiffspotokoll fü den Objektzustand, was fü das Estellen von Debuggen efodelich wäe. CORBA hat keine Schnittstelle mit geneische Funktionalität. De Anwende muss daduch existieende Implementationen fü jede Einfühung neue Funktionalität unnötigeweise neu anpassen und eweiten. CORBA basiet fix auf einem Objektmodell, daduch wid eine Evolution von Objektsystemen veunmöglicht.

53 5.1. PROBLEME VON CORBA 43 Softwaeachitektu: CORBA definiet eine Menge von Diensten und Facilities. Wie man abe mit diesen Gundelementen umgehen soll, eklät CORBA kaum. So ist es schwieig, mit Hilfe de Dienste und Facilities ein Famewok fü Client/Seve Achitektuen zu bauen. Wie schon ewähnt, ist CORBA eine Objekt-Achitektu. Seit einige Zeit hat sich gezeigt, dass eine Komponentenachitektu viel geeignete fü das Estellen von Softwaeachitektuen ist. Die OMG hat dieses Poblem ekannt und wid daauf mit dem CORBA 3.0 Standad eagieen. Aus einem gosstechnischen, konsensoientieten Standadisieungspozess wie bei COR- BA esultieen nomaleweise elativ komplexe, schwe veständliche Standadgebilde. Die OMG ist ein Konsotium von übe 750 Mitglieden, das hat zu Folge, dass die Standadisieung nu schleppend voan kommt. Einige de ORB-Anbiete bauen dahe ihe eigenen adhoc Eweiteungen, um den Kundenwünschen geecht zu weden. So entsteht eine Diskepanz zwischen den einzelnen ORBs und de Spezifikation des CORBA Standads. CORBA ist ein offene Standad, daduch ist es jedemann möglich, seinen eigenen ORB zu bauen. Dahe gibt es viele veschiedene ORB-Anbiete und es hescht zwischen den Anbieten ein gosse Konkuenzkampf. De Kunde muss bei seine ORB-Evaluation jeweils noch die Übelebenschancen de ORB Hestelle einbeechnen. Pagmatische Übelegungen: Aus dem Atikel von Bend Eichne, David Kambe und Stephan Mue (vgl. [EKM97]) und dem Refeat von Stefan Mue an de Object Expo (vgl. [Mu97]) gehen die folgenden Poblempunkte hevo: Die CORBA Sevices sind noch nicht fetig spezifiziet. Die Entwickle bauchen diese Dienste abe um ihe Applikationen einfache entwickeln zu können. Andeeseits sind beeits standadisiete Dienste sind noch nicht ausgeeift. CORBA mangelt es an Fehletoleanz (fault-toleance). In einigen Fällen teten unewatete Pobleme auf. CORBA geneiet Fehlemeldungen, die es nicht elauben, den Ot des Fehles zu lokalisieen. Beispielsweise bicht eine Applikation ab und meldet: COMPLETION MAYBE 1 1 Diese Fehlemeldung besagt eineseits, dass ein Fehle aufgeteten ist, abe andeeseits lässt sich de Fehleot nicht genau lokalisieen.

54 44 KAPITEL 5. PROBLEMANALYSE Douglas C. Schmidt et al. (vgl. [SGHP97]) bemängelt vo allem das Echtzeitvehalten von CORBA. E vemisst Echtzeitgaantien, wie sie in vielen Anwendungsapplikationen, wie zum Beispiel in de Luftfaht ode de Telekommunikation, unelässlich sind. Diese Echtzeitpobleme entspingen aus den nachfolgenden Defiziten: CORBA fehlt eine Spezifikation übe die Dienstqualität (Quality of Sevice). Es gibt auch keine Untestützung fü die Duchfühung eine End zu End Dienstqualität. Fü die Ababeitungseihenfolge de Clients existieen zum Beispiel keine Pioitäten. Die Echtzeitpogammieung (eal-time featues) wid von CORBA nicht untestützt. Ein weitees Poblem besteht dain, dass die meisten ORBs nicht effizient abeiten, da COR- BA nicht auf Geschwindigkeit optimiet wude. Um eine bessee Pefomance zu ezielen, müssten die veschiedensten Stategien wie zum Beispiel die intene Message Buffeing Stategy ode auch divese Algoithmen vebesset weden. Silvano Maffeis (vgl. [Maf97] und [MS97]) macht voallem auf die Mängel aufmeksam, die duch den intensiven Gebauch von CORBA aufteten. Das sind: Es gibt keine absolute Zuvelässigkeit (eliablility). In einem 7x24-System 2 ist CORBA nicht geeignet, da unewatete Fehle aufteten können. Gössee Applikationen mit CORBA tendieen seh schnell seh komplex zu weden. Ein solches System kann fast nicht meh gewatet weden. Silvano Maffeis spicht von einem maintenance nightmae. CORBA hat Eweiteungspobleme. Veändet man ein IDL-Inteface, so kann es sein, dass mehee Clients eine Anpassung benötigen. CORBA ist nicht geeignet fü eine langsame, stufenweise Applikationsentwicklung im Sinne eines Spialenmodells (vgl. [Jen97]). Zusammenfassend kann gesagt weden, dass vo allem folgende Punkte die Schwachstellen von CORBA ausmachen: Fehlende Eweitebakeit Mangelnde Flexibilität Ungenügende Fehletoleanz Lastveteilungspoblem Unvollständigkeit de Sevices Keine Dienstqualitätsspezifikation fehlendes Echtzeitvehalten 2 In einem 7x24-System daf es keine Untebüche geben, d.h. es muss 7 mal 24 Stunden zu Vefügung stehen.

55 5.2. EINSCHRÄNKUNG DER PROBLEMSTELLUNG Einschänkung de Poblemstellung Im letzten Abschnitt wude anhand von ausgewählte Liteatu eine eingehende Poblemanalyse von CORBA estellt. In diesem Abschnitt wid basieend auf diese Poblemanalyse die Poblemstellung fü die voliegende Abeit eduziet, da sonst de zeitliche Rahmen diese Abeit gespengt wüde. Die Fachguppe Softwae Composition Goup de Univesität Ben, unte de Leitung von Pof. D. O. Niestasz, befasst sich unte andeem mit dem Zusammenstellen von Softwae- Komponenten (component composition). Unte dem Begiff Softwae vesteht man Applikationen, Methoden ode Komponenten, welche auf igendeine At von Rechne laufen. Im Sinne de Foschungsguppe inteessiet die Vewendbakeit sowie die Vebesseung von Entwicklungshilfsmittel. Nachfolgend weden die in diese Abeit zu lösenden Pobleme von CORBA aufgelistet: Mangelnde Flexibilität De Standad von CORBA 2.0 basiet auf eine Objekt Achitektu (vgl. [OMG97b]). Softwaesysteme sind dauenden Veändeungen ausgesetzt. Die Efahung hat gezeigt, dass die objektoientiete Technologie keine Gaantie fü flexible und anpassbae Softwae-Entwicklung ist (vgl. [SN98a]) und dass Objekt Achitektuen sich nicht einfach veänden lassen. Bei gossen Applikationen wid die Applikationslogik oft auf mehee Komponenten veteilt, das heisst Client und Seve sind meist aufeinande abgestimmt. Es ist elativ aufwendig, eine CORBA-Komponente zu vewenden, da eineseits die ganzen CORBA-Kenntnisse benötigt weden und andeeseits veschiedene Infomationen von de CORBA-Komponente bekannt sein müssen, um übehaupt ein CORBA-Objekt zu ezeugen. Aufwendiges Testen CORBA-Applikationen haben ein sogenanntes all o nothing-poblem. Das heisst eine Seve- Komponente kann nicht alleine existieen. Um ein lauffähiges Pogamm zu ehalten, muss zu jedem CORBA-Seve ein entspechende Code fü den CORBA-Client geschieben weden. Das Testen eine einzelnen Komponente ist dahe aufwendig, das heisst, um einen Seve zu testen, muss ein vollständige CORBA-Client geschieben weden und de CORBA-Client muss in die Middlewae CORBA eingebunden weden. Zudem gibt es noch keine Debugge und Analyse- Tools fü CORBA (vgl. [BR97]). Ungenügende Eweitebakeit CORBA-Objekte sind stae Gebilde, da sie implementoisch gesehen nu genau eine Schnittstelle (vgl. [OMG97b]) besitzen. Diese Eigenschaft bigt die Schwieigkeit Komponenten zu veänden (vgl. [Maf97]), das heisst, CORBA-Objekte müssen fü jede zusätzliche Funktionalität neu

56 46 KAPITEL 5. PROBLEMANALYSE angepasst weden (vgl. [BR97]). Das Eweiten eine bestehenden CORBA-Applikation kann aussedem eschwet sein, wenn sich die Applikationslogik auf eine tiefen Abstaktionsebene befindet. Es ist oftmals einfache, eine neue CORBA-Applikation zu scheiben, da die Einabeitung in eine schon Bestehende zu viel Zeit benötigt. Zudem ist es schwieig, bestehende Nicht-CORBA-Komponenten einzubinden, da dies von CORBA nu mangelhaft untestützt wid. Mangelhaftes Abstaktionsniveau Gosse Applikationen bestehen meist aus meheen Clients und Seven, und diese tendieen seh schnell seh komplex zu weden (vgl. [Maf97]). Aussedem wid oft die Applikationslogik auf veschiedene Komponenten veteilt, so dass es leicht zu einem tiefen Abstaktionsniveau fühen kann. Eine auf veschiedene Komponenten veteilte Applikationslogik eschwet das Veständnis de Implementieung und kann zu eine Maintenance Nightmae fühen. Wiedevewendungspoblem Um eine CORBA Komponente wiedezuvewenden, benötigt man CORBA Kenntnisse, denn ohne CORBA-Kenntnisse kann keine Komponente eingebunden weden. Es stellt sich auch die Fage, auf welche Weise legacy components in CORBA integiet weden können. Da gössee CORBA-Applikationen meist eine hohe Komplexität elangen und CORBA nicht seh fehletoleant ist (vgl. [EKM97]), weden diese Client/Seve-Applikationen oft genau aufeinande abgestimmt. CORBA-Komponenten von speziell aufeinande abgestimmten Applikationen können dahe kaum wiedevewendet weden. Zudem weden nomaleweise nu Komponenten wiedevewendet, wenn sie mit gosse Sogfalt getestet wuden, was ja mit CORBA schwieig ist.

57 Kapitel 6 Lösungsansatz de CORBA-Pobleme Wie aus dem letzten Kapitel esichtlich wude, existieen mit CORBA noch einige ungelöste Pobleme. CORBA vespicht ein objektoientietes Famewok zu sein. Abe die Standadisieung ist noch nicht beendet und kommt nu langsam voan. Das bedeutet fü die Entwickle, dass sie das objektoientiete Famewok nu eingeschänkt vewenden können. Dieses Kapitel gibt zuest einen Einblick, wie man die Pobleme von CORBA lösen könnte. Anschliessend wid de Ansatz de Komponenten-Poxy eläutet, de in diese Abeit eingefüht wid. Diese Ansatz soll die Möglichkeit bieten, aus CORBA eine Komponenten Achitektu zu machen. Duch den Einsatz eine Skipt-Spache kann ein flexiblees und leichte veändebaes Komponenten Famewok fü CORBA estellt weden. 6.1 Übeblick Die vie Fimen IBM, Netscape, Oacle und Sunsoft fodeten die OMG auf (vgl. [INOS97]), den Standad schnelle voan zu teiben. Es wid zudem velangt, dass CORBA unbedingt eine Skipt- Spache benötigt. Skipt-Spachen sollen als Entwicklungsumgebung fü kleine Applikationen (apid application development) zum Einsatz kommen. Zu Laufzeit kann man Skipt-Spachen zum Scheiben von neuen Skipts und deen anschliessenden Ausfühung duch eine eval -Funktion gebauchen. Diese Spachen bieten die Möglichkeit, aus CORBA ein Komponenten Famewok zu machen. CORBA basiet auf eine Objekt Achitektu. Um aus CORBA ein Komponenten Famewok zu machen, benötigt CORBA unte andeem eine Anbindung an eine Skipt-Spache (vgl. Absatz 2.3.2). Die OMG hat das Fehlen eine Skipt-Spache ekannt und veöffentlichte ein Request fo Poposal (RFP vgl. [TC98]). Einige Mitgliede-Fimen haben daauf eagiet und haben ihe Voschläge eingeeicht. De Standad de Anbindung eine Skipt-Spache an CORBA befindet sich abe noch in Beabeitung (vgl. Anhang B.6). Mittleweile gibt es schon einige expeimentelle ORBs, die eine Anbindung an eine Skipt- 47

58 48 KAPITEL 6. LÖSUNGSANSATZ DER CORBA-PROBLEME Spache ealisiet haben. Es ist zu beachten, dass diese Anbindungen an die IDL noch nicht standadisiet sind. Nachfolgend weden einige Vetete von ORBs aufgezählt, die eine Skipt- Spache anbinden: MICO fü Tcl (vgl. [RPP97]) Inte-Language Unification fü Python (vgl. [JS97]) Fnob fü Python (vgl. [Chi98]) COPE fü Pel (vgl. [Res98]) Eine Skipt-Spachen-Anbindung an einen ORB emöglicht de entspechenden Skipt-Spache ihe Voteile auf CORBA zu übetagen. Das Entwickeln von CORBA-Applikationen ist echt aufwendig und benötigt viel Efahung. Um eine CORBA-Komponente mit eine Skipt-Spache zu estellen, ist das Vefahen genau gleich wie zum Beispiel das Entwickeln eine CORBA-Komponente mit Java. Das bedeutet, um eine CORBA-Komponente (Client ode Seve) in eine Skipt-Spache zu implementieen, benötigt man das ganze Wissen übe CORBA. Aus diesem Gund wid abe de Einsatz eine Skipt-Spache im eigentlichen Sinn seh stak eingeschänkt. Ein schnelles Vebinden ode Testen einzelne Komponenten wid zu eine aufwendigen Angelegenheit, das heisst, Voteile eine Scipt-Spache gehen veloen. An de Univesität von Lille in Fankeich abeitet eine Foschungsguppe an einem CORBA- Pojekt (vgl. [MGRG98]), das GOODE (Geneic Object-Oiented Dynamic Envionment) heisst. In diesem Pojekt wid gezeigt, wie die Skipt-Spache CobaScipt dynamisch auf CORBA- Komponenten zugeifen kann. Man eeicht diesen dynamischen Zugiff auf CORBA-Objekte duch zusätzliche Dienste (CORBA tools). Diese Dienste sind von diese Foschungsguppe estellte Eweiteungen eines ORBs. De Intepete von CobaScipt püft die Datentypen zu Laufzeit, indem e mit dem Inteface Repositoy von CORBA Kontakt aufnimmt. In Scipting COM components in Haskell von Simon Peyton Jones und Eik Meije (vgl. [JM98]) wid gezeigt, wie man eine funktionale Pogammiespache an Micosoft s Component Object Model (COM) anbindet. Mit Hilfe de highe-ode Featue de funktionalen Pogammiespache können Komponenten auf eine ganz spezielle At zusammengesetzt weden, wie zum Beispiel mit lazy evaluation. Diese zusätzlichen Eigenschaften sollen die Sicheheit sowie die Aussagekaft de Applikationen föden. 6.2 Die Methode des Komponenten-Poxy Im Vegleich zu den im obeen Abschnitt genannten Lösungsansätzen ist de Ansatz de voliegenden Abeit nicht an einen einzelnen ORB gebunden. De hie vewendete Lösungsansatz basiet

59 6.2. DIE METHODE DES KOMPONENTEN-PROXY 49 auf eine sogenannten Komponenten-Poxy -Methode, welche eine ORB-unabhängige Integation von CORBA-Komponenten emöglicht. De Zweck eines Poxy wid im Buch Design Patten (vgl. [GHJV95]) wie folgt beschieben: Ein Poxy kontolliet den Zugiff auf ein Objekt mit Hilfe eines vogelageten Stellvetete- Objekts. Die Methode des Komponenten-Poxy füht ein weitees Abstaktionsniveau ein. Diese Abstaktion wid als zusätzliche Schicht, in Fom eines Moduls zwischen die Skipt-Spache und CORBA gelegt (vgl. Abbildung 6.1), was zu eine ORB-Unabhängigkeit füht. Die CORBA- Komponenten weden daduch von de Skipt-Spache abgekapselt, können jedoch mit Hilfe dieses Moduls als sogenannte Stellvetete-Objekte (Komponenten-Poxy) ezeugt weden. Diese Komponenten-Poxies können dann von de Skipt-Spache vewendet, als wäen sie ganz nomale Objekte. Ein Poxy-Objekt kann entwede mit de Objektefeenz ode mit seinem Namen ezeugt weden. Damit ein Stellvetete-Objekt duch seinen Namen instanziet weden kann, muss ein globale Namensdienst (NameSeve) estellt weden. Skipt-Spache Modul CORBA Abbildung 6.1: Eine Abstaktion duch ein Modul Ein Objekt des Komponenten-Poxy befindet sich in de Welt de Skipt-Spachen (Remote- Poxy) und agiet genau gleich wie die Oiginal-Komponente mit dem Unteschied, dass die Aktionen nicht im Poxy beabeitet weden, sonden weitegeleitet und vom Oiginalseve ausgefüht weden (vgl. Abbildung 6.2). De CORBA-Seve sendet das Resultat übe die eingebaute Abstaktion an den Poxy zuück. De Anwendungspogammiee bemekt von diesem Weiteleiten nichts, das heisst, die Komponente muss nicht speziell behandelt weden. Die Komponenten-Poxy-Methode bingt folgende Voteile: Es wid eine ORB-Unabhängigkeit eeicht, da diese Methode keine ORB spezifischen Veändeungen vonimmt. CORBA-Komponenten können ohne spezifisch Kenntnisse von CORBA vewendet weden. Es kann eine einzelne CORBA-Seve-Komponente vewendet weden, ohne dass ein vollständige Client dazu geschieben weden muss, da das duch das Modul ezeugte Stellvetete-Objekt wie jedes andee Objekt vewendet weden kann.

60 50 KAPITEL 6. LÖSUNGSANSATZ DER CORBA-PROBLEME Skipt- Spache www www www xxx xxx Komponenten-Poxy yyy yyy yyy zzz zzz Oiginal-Komponente Abbildung 6.2: Ein Komponenten-Poxy leitet die Anfagen zu Oiginal-Komponente weite. Eine Skipt-Spache hat mit Hilfe des Moduls eine tanspaente Sicht auf die bestehenden CORBA-Komponenten. Das einfache Vewenden von CORBA-Komponenten födet die Wiedevewendbakeit von bestehenden und das Estellen von allgemein vewendbaen Komponenten. Aus de ORB-Unabhängigkeit egibt sich abe ein Nachteil. Die CORBA-Komponenten müssen sich entwede beim globalen NameSeve anmelden ode sonst igendwie ihe Refeenz publik machen.

61 Kapitel 7 Komponenten-Poxy In diesem Kapitel wid gezeigt, wie man ein Komponenten Famewok fü CORBA estellt. Zuest wid mit Hilfe de in diese Abeit entwickelten Methode Komponenten-Poxy de Gundstein fü das Komponenten Famewok gelegt. Mit diese Methode eeicht man eine Komponenten Achitektu, das heisst, Komponenten und deen Steueung weden getennt. Danach wid de Aufbau eines Famewoks basieend auf diese Komponenten Achitektu eklät. Es weden anhand von zwei Ansätzen die neuen Möglichkeiten aufgezeigt. Abschliessend weden die Genzen dieses Ansatzes diskutiet. In diese Abeit wid ein ORB mit eine Anbindung an Python vewendet. Diese ORB heisst Fnob und wude an de Univesität von Queensland in Bisbane (Austalien) entwickelt (vgl. [Chi98]). De Fnob wude gewählt, weil e zum Zeitpunkt de Evaluation de am weitesten entwickelte ORB fü eine Skipt-Spache wa. Zudem untestützte e schon damals die Mechanismen fü die Inteopeabilität. De Fnob ist abe imme noch ein expeimentelle ORB. Man hätte abe fü die Komponenten-Poxy-Methode genausogut einem andeen ORB vewenden können. 7.1 Die Methode Die Komponenten-Poxy -Methode emöglicht das automatische Estellen eines Stellvetete- Objektes (Komponenten-Poxy) von einem CORBA-Seve. Diese CORBA-Seve können sich igendwo im Rechnenetz befinden und sie sind in eine beliebigen Pogammiespache mit eine IDL-Anbindung geschieben. Die Abbildung 7.1 zeigt den Aufbau diese Methode. Die Methode emöglicht Python den Zugiff auf eine CORBA-Komponente. Diese Zugiff efolgt mit Hilfe eines Stellvetete-Objekts (Komponenten-Poxy). Die Kommunikation veläuft zwischen Stellvetete und CORBA-Komponente übe CORBA ORBs. Die Methode wid mit Hilfe de folgenden zwei Eweiteungen ealisiet: Das Modul coba poxy emöglicht, ein Stellvetete-Objekt zu ezeugt. 51

62 52 KAPITEL 7. KOMPONENTEN-PROXY Python {{{ {{{ Komponenten-Poxy CORBA-Komponente }}} }}} }}} ~ ~ ~ ~ ~ ~ CORBA ORBs Abbildung 7.1: Methode de Komponenten-Poxy De globale NameSeve ist ein Namensdienst, bei dem sich die CORBA-Komponenten anmelden können. Diese Dienst wid in Fom eines CORBA-Seves ealisiet. Diese zwei Eweiteungen nehmen keine Veändeungen am ORB-Ken ode am sonstigen CORBA-Standad vo. Die Methode ist dahe nicht an einen einzelnen ORB gebunden und kann auf die CORBA-Komponenten von veschiedenen ORBs zugeifen. Da diese Methode keine Veändeungen an CORBA vonimmt, ist es leicht vostellba, dass diese Ansatz auf andee Middlewae- Achitektuen übetagen weden kann. Die Abbildung 7.2 zeigt den detailieten Ablauf diese Methode. Ein CORBA-Seve bietet seine Dienste an, die von Python vewendet weden möchten. Das Kommunikationsmedium ist die Summe alle vewendeten CORBA ORBs. Es düfen beispielsweise de Fnob und de VisiBoke (vgl. [Vis97]) vewendet weden. Die Entscheidung, welche ORBs ausgewählt weden sollen, ist abhängig von de vewendeten Pogammiespache. Nicht jede ORB untestützt jede Pogammiespache. De globale NameSeve und das Modul coba poxy emöglichen Python einen einfacheen Zugang zu CORBA-Komponenten. De globale NameSeve ist eine zusätzliche CORBA- Komponente, die Infomationen übe alle vohandenen Seve sammelt. Das Modul liegt zwischen Python und dem Fnob, und geneiet mit Hilfe des NameSeve Stellvetete-Objekte. Ein Stellvetete-Objekt wid wie folgt ezeugt: De globale NameSeve wid als estes gestatet. Die CORBA-Komponente muss sich nach seine Ezeugung beim NameSeve anmelden (egiste).

63 7.1. DIE METHODE 53 Duch ein Python-Skipt ode die Python-Shell wid das Modul coba poxy impotiet, um ein Stellvetete-Objekt des CORBA-Seves zu estellen. Das Modul coba poxy vebindet sich mit dem globalen NameSeve um die Refeenz des CORBA-Seves zu bekommen (ask). Ist de Seve egistiet, so estellt das Modul ein Komponenten-Poxy-Objekt, das mit dem CORBA-Seve vebunden wid (connect). Von Python aus können nun die Dienste des Seves via den Komponenten-Poxy vewendet weden. Python-Shell >>> Python- Skipt ƒƒƒƒƒƒ ƒƒƒƒƒƒ ƒƒƒƒƒƒ ƒƒƒƒƒƒ ƒƒƒƒƒƒ ƒƒƒƒƒƒ globale NameSeve Stellvetete-Objekt Modul coba_poxy CORBA-Komponente ask (get_) egiste (add_seve) connect (load) CORBA ORBs Abbildung 7.2: Mechanismus de Komponenten-Poxy-Methode NameSeve De globale NameSeve ist eine CORBA-Komponente, die fü die Komponenten-Poxy-Methode zusätzlich estellt wude. Diese Komponente ist ein untestützende Dienst, de das Auffinden von CORBA-Seven veeinfacht. Die Aufgaben des NameSeves lassen sich in zwei Beeiche unteteilen. Eineseits können sich CORBA-Seve hie egistieen, damit potentielle Benutze sie auch auffinden. Andeeseits benötigt das Modul Infomationen übe die Seve um einen Komponenten-Poxy zu estellen. De NameSeve ist ein Dienst, de mit dem CORBA NamingSevice vegleichba ist. Im Unteschied zum CORBA NamingSevice ist de NameSeve nicht in einem ORB integiet, sonden eine nomale CORBA-Komponente. Im NameSeve weden die CORBA-Seve auch nicht automatisch egistiet, das muss von jedem einzelnen selbst gemacht weden. Bei de Anmeldung

64 54 KAPITEL 7. KOMPONENTEN-PROXY egistiet eine Komponente zum Beispiel den Namen, den Stub-Namen und die IOR (Inteopeable Object Refeence). Die Dienste des NameSeve sind duch das nachfolgende IDL-Inteface definiet: // NameSeve.idl; IDL-Inteface of the global NameSeve module NameSeve{ // define an exception exception UNKNOWN_SERVER{}; inteface NameSeveIF{ shot numbe_available_seves(); // maximum index is one less then numbe_available_seves(), // because counting stats with 0 sting get_seve_name(in shot index) aises (UNKNOWN_SERVER); sting get_stub_name(in sting name); sting get_ior(in sting name); sting get_idl(in sting name); // is this seve available boolean is_avail(in sting name); void add_seve(in sting name, in sting IOR, in sting Stub_Name, in sting IDL); void emove_seve(in sting name) aises (UNKNOWN_SERVER); }; }; Fü das Inteface des globalen NameSeve wid ein gleichnamige Namensaum ezeugt, damit es keine Konflikte mit andeen CORBA-Seven gibt. Es wude eine Ausnahme (UNKNOWN - SERVER) definiet, damit de Zugiff auf nicht egistiete Sevenamen eine Ausnahme ezeugen kann. Um abe solche Ausnahmen zu vemeiden, gibt es eine Methode is avail, die übepüft, ob ein entspechende Sevename existiet. Zu Veeinfachung wude das Inteface de Methoden get Stub Name, get IOR und get IDL ohne Ausnahmebehandlung definiet. Ein Seve muss sich mit de add Seve-Methode egistieen. Bei de Registation kann e seinen Namen, die IOR, den Stub und sein IDL-Inteface angeben. Nomaleweise wid bei de Registation de Name des Seves, die Zeichen-Folge ode de Dateiname de IOR und de Name des Stub angegeben. Die Registation sieht zum Beispiel in Java mit dem VisiBoke wie folgt aus: // egiste the Famoos Model Seve at the NameSeve // the IOR of the NameSeve is saved in a file DataInputSteam file=new DataInputSteam(new FileInputSteam("nameseve.ef")); Sting stingifiedior = new Sting(file.eadLine()); // connect to the NameSeve og.omg.corba.object obj = ob.sting_to_object(stingifiedior); NameSeve.NameSeveIF ns = NameSeve.NameSeveIFHelpe.naow(obj); // egiste at the NameSeve: name, io, stub, idl ns.add_seve("fm", "/home/held/public_html/ior/fmseve.ef", "FM", "");

65 7.1. DIE METHODE 55 Das IDL-Inteface wid in de Methode add Seve nu dann vewendet, wenn noch kein Stub vohanden ist. In diesem Fall besteht die Möglichkeit, den Stub zu Laufzeit mit Hilfe des IDL-Intefaces zu estellen (vgl. halb-dynamische -Methodenaufuf in Absatz 7.4.2). De globale NameSeve befindet sich imme an einem fest definieten Ot, damit jedemann zu jede Zeit diesen Dienst benutzen kann. Diese Infomationen können zum Beispiel auf dem Web publiziet weden. Fü den statischen Methodenaufuf bedeutet das, dass sowohl die in einen Sting umgewandelte IOR als auch de Stub des CORBA-Seves bekannt sein müssen. Ein dynamische Methodenaufuf benötigt dagegen nu die Refeenz des Seves (IOR) vom NameSeve Das Modul coba poxy Es wude ein Modul coba poxy entwickelt, das eine weitee Abstaktion emöglicht. Das Modul bildet eine Schicht zwischen CORBA und Python. Die Abbildung 6.1 auf Seite 49 zeigt, wie die Kommunikation mit de Komponenten-Poxy-Methode von CORBA zu Skipt-Spache und umgekeht veläuft. CORBA emöglicht sowohl einen statischen als auch einen dynamischen Methodenaufuf innehalb eines ORBs. In diese Abeit wid gezeigt, wie die Komponenten-Poxy-Methode den statischen Methodenaufuf untestützt. Statische Methodenaufuf Das estellte Modul basiet auf statischen Methodenaufufen, das heisst Methodenaufufe benötigen Stub und Skeleton. Stub und Skeleton weden automatisch aus dem IDL-Inteface des CORBA- Seves geneiet. Bei einem Methodenaufuf übenehmen sie das Absenden und Entgegennehmen de Datenpakete (Mashaling und Unmashaling). Im nachfolgenden Pogammcode wid ein gosse Teil des Moduls coba poxy gezeigt. Zu Veeinfachung wude ein Teil de Methode load weggelassen. Im voliegenden Teil diese Methode sieht man, wie ein Stellvetete-Objekt mit Hilfe des NameSeves ezeugt weden kann. De weggelassene Code wüde das Stellvetete-Objekt duch seinen Stub-Name und seine IOR auf analoge Weise ezeugen. Es folgt das Listing des coba poxy-moduls (vgl. auch im Anhang C): # coba_poxy.py; a Python module to geneate poxy-objects # Standad/built-in modules. impot sys, sting, os, ullib # Fnob modules (a CORBA 2.0 ORB). fom Fnob.ob impot BOA, CORBA class GenealPoxy: """This is the geneal poxy class """ def init (self, *ags):

66 56 KAPITEL 7. KOMPONENTEN-PROXY pint "GenealPoxy init" # Initialise the ORB. self.ob = CORBA.ORB_init(sys.agv, CORBA.ORB_ID) def load(self, *ags): if (len(ags)==0): pint "usage: load(<stub>, <io>) o load(<name>)" elif (len(ags)==1): # load the object by name, the nameseve must be unning # impot the Stub of the nameseve impot NameSeve # get the name name = ags[0] # connect to the nameseve (to simplify: local efeence) f = open( nameseve.ef, ) stingified_io = f.ead() f.close() # Convet the stingified IOR into an active object efeence. ns = self.ob.sting_to_object(stingified_io) if ns.is_avail(name): # get the stub and the io of the named object stub = ns.get_stub_name(name) io = ns.get_ior(name) if os.path.isfile(io): f=open(io, "") io = f.ead() f.close ty: # load the stub impot (stub) except: pint "ERROR: bad stub" sys.exit() ty: pint "ceate the poxy-object" etun self.ob.sting_to_object(io) except: pint "ERROR: bad io" sys.exit() else: pint "NameSeve doesn t know this name." elif (len(ags)==2): # locate the object with the stub and the IOR (URL o filename)... else: pint "usage: load(<stub>, <io>) o load(<name>)" Das estellte Modul coba poxy besteht aus eine Klasse GenealPoxy. Diese Klasse hat einen Konstukto und eine Methode load. De Konstukto initialisiet den ORB. Die Methode load ezeugt ein Stellvetete-Objekt, das alle Methodenaufufe dem CORBA-Seve weite leitet. Die load-methode kann auf zwei veschiedene Aten vewendet weden:

67 7.1. DIE METHODE 57 Eineseits kann die Methode mit einem Agument aufgeufen weden. Das Agument entspicht dem Namen des Seves. De globale NameSeve wid kontaktiet 1, damit man von diesem Seve den Stub und die IOR in Efahung bingt. Mit Hilfe von Stub und IOR wid dann das Stellvetete-Objekt ezeugt. Andeeseits kann ein Komponenten-Poxy auch diekt, das heisst ohne Rückfage beim NameSeve estellt weden. Auf diese Weise benötigt man das Wissen, wie de Stub (absolute Pfad) heisst und wo die Datei mit de IOR abgespeichet ist. Die IOR kann auch hie als URL angegeben weden Vewendung Nomaleweise besteht eine CORBA-Applikation aus Clients und Seven. Eine solche Applikation wid mit dem Ziel pogammiet, ein spezifisches Poblem zu lösen. Das bedeutet, dass die Komponenten diese Applikation oft genau aufeinande abgestimmt sind (in einande vezahnt) und daduch meist nu fü genau ein Poblem vewendet weden können. Mit Hilfe de in diese Abeit estellten Komponenten-Poxy-Methode können CORBA-Seve seh einfach vewendet weden, das heisst die Methode bingt eine Eleichteung bei de Estellung de Clients. Die inteaktive Vewendung eine CORBA-Komponente (vegleiche dazu einen vollständigen Client PicingClient auf Seite 39) sieht zum Beispiel fü die Hello - Komponente (vgl. im Anhang C.2.1) wie folgt aus: >>> impot coba_poxy >>> gp = coba_poxy.genealpoxy() >>> say = gp.load("hello") >>> pint say.hello() Hello Wold! In diesem Beispielcode wid est das estellte Modul coba poxy geladen. Danach wid die Klasse GenealPoxy instanziet, die fü die Estellung de Stellvetete-Objekte zuständig ist. Mit de Methode load des GenealPoxy-Objektes kann ein Stellvetete-Objekt ezeugt weden. Im obigen Beispiel wude ein Komponenten-Poxy des Hello -Seves estellt. Mit dem Stellvetete-Objekt say kann nun die Methode hello des Seves ausgefüht weden. Damit die CORBA-Komponenten auf diese Weise vewendet weden können, sind die folgenden zwei Schitte efodelich: De globale NameSeve muss einmal gestatet weden und wid imme aktiv bleiben. Diese NameSeve ist eine CORBA-Komponente, die in Python geschieben wude. Es ist ein zusätzliche Dienst, de mit nameseve.py gestatet wid. Je nach Vewendung weden die CORBA-Seve gestatet. 1 Zu Veeinfachung befindet sich die Refeenz des NameSeve in eine Datei, abgespeichet im aktuellen Vezeichnis. Die Refeenz könnte zum Beispiel auch mit eine globalen bekannten URL auf dem Web ode via publiziet weden.

68 58 KAPITEL 7. KOMPONENTEN-PROXY 7.2 Komponenten Famewok fü CORBA Im letzten Abschnitt wude die Komponenten-Poxy-Methode vogestellt. Wie in Abschnitt beschieben, besteht ein ideales Komponenten Famewok aus eine Achitektu, Skipts, Glue und Koodination. In diesen Abschnitt wid ein Komponenten Famewok zu diese Methode eingefüht. In diesem Komponenten Famewok wid beschieben, wie man eine Applikation mit Hilfe de Komponenten-Poxy-Methode estellt. Es weden vo allem die Elemente des Komponenten Famewok eläutet, die im Zusammenhang mit de Komponenten-Poxy-Methode ode CORBA ein andees Vehalten haben Softwae Achitektu In diesem Komponenten Famewok wid in eine Applikation zwischen zwei Softwaebausteinen unteschieden. Eineseits hat man die Komponenten, das sind in diese Abeit CORBA-Seve. Andeeseits gibt es eine Applikationslogik (Clients), die in einem Skipt geschieben sind. Die Kommunikation zwischen veteilten Komponenten übenehmen die CORBA ORBs. Die Abbildung 7.3 zeigt diese Tennung von Komponenten und Applikationslogik (connecto). Eine Applikation besteht aus meheen unabhängigen Seven, die duch ein Skipt vebunden und gesteuet weden. Python- Skipt Applikationslogik ŠŠŠ ŠŠŠ ŠŠŠ ˆˆˆ ˆˆˆ CORBA-Komponenten Abbildung 7.3: Achitektu des Komponenten Famewoks CORBA-Seve - die Komponenten In diesem Famewok sind CORBA-Seve die Softwaekomponenten, das heisst, es können nu CORBA-Komponenten vewendet weden. Die Komponenten düfen in igendeine Pogammiespache mit eine CORBA-Anbindung geschieben weden. Damit man ein wiedevewendbaes System ehält, muss daauf geachtet weden, dass die CORBA-Komponenten eine unabhängige Einheit dastellen. Das heisst, ein Seve sollte nicht fest mit einem andeen Seve vebunden sein. Steht ein Seve in Abhängigkeit mit einem andeen Seve, so muss die Vebindungsaufnahme im Skipt explizit gesetzt weden können.

69 7.2. KOMPONENTEN FRAMEWORK FÜR CORBA 59 Fü die Estellung von CORBA-Komponenten gibt es gundsätzlich dei Möglichkeiten: Eine Komponente wid von Gund auf neu estellt. Man vewendet einen beeits bestehenden CORBA-Seve. Man bindet auch beeits existieende Nicht-CORBA-Komponenten in das Famewok ein. Die Estellung eines neuen CORBA-Seves veläuft nomaleweise in zwei Schitten: Bescheibung des IDL-Intefaces Implementation des Seves Jede CORBA-Seve wid duch sein IDL-Inteface beschieben. Das Inteface bescheibt die Dienste, die de Seve anbietet. Bei de Implementieung de CORBA-Komponente muss daauf geachtet weden, dass die implementieten Dienste als unabhängige Einheiten definiet weden. Das heisst fü eine Komponente, dass sie nicht diekt mit eine andeen Komponente vebunden sein daf (die Vebindung wid vom Skipt estellt.). Unabhängige Dienste können einfache estellt und späte besse wiedevewendet weden. Jede Seve muss sich beim NameSeve anmelden. Mit de Methode object to sting wid die Refeenz des Objektes als Sting abgelegt und dem globalen NameSeve gemeldet. Vewendet man einen beeits existieenden CORBA-Seve, sind zwei Schitte efodelich. Estens muss die Komponente auf ihe Unabhängigkeit hin untesucht weden. Zweitens muss de beeits existieende Seve sich beim NameSeve anmelden. Komponenten wie die des komplexe Zahlen-Beispiels (vgl. C.4.1) haben das Poblem, dass gewisse Resultate an eine weitee Komponente, den Display-Seve, weitegegeben weden. Diese Komponente muss est unabhängig gemacht weden, und das heisst de Quellcode muss veändet weden. Alle Softwae Komponenten, die ohne die Middlewae CORBA pogammiet sind, können als sogenannte Nicht-CORBA-Komponenten zusammengefasst weden. Eine Nicht-CORBA-Komponente kann aus de Sicht des Komponenten Famewoks als legacy application (vgl. Abschnitt 2.4) bezeichnet weden. Wie man solche Komponenten in de Komponenten Achitektu einbindet, wid im Abschnitt Glue (vgl. Abschnitt 7.2.3) beschieben. Applikationslogik - die Steueung Die Applikationslogik ist de zweite Baustein de Komponenten Achitektu. In de Applikationslogik weden die CORBA-Komponenten vewendet und mit andeen CORBA-Komponenten in Vebindung gebacht. In de Applikationslogik befindet sich die Logik und Steueung eine Applikation.

70 60 KAPITEL 7. KOMPONENTEN-PROXY Diese Teil eine Applikation wid in diesem Komponenten Famewok mit de Skipt-Spache Python geschieben. Python vewendet die Komponenten-Poxy-Methode um die einzelnen COR- BA-Seve zu efeenzieen und anschliessend koodinieen zu können. Die Komponenten weden entwede in einem Skipt ode von de Python-Shell aus benutzt. Wie in Absatz 4.1 auf Seite 23 beschieben, kann eine n-tie Applikation aus meheen Diensten bestehen. Ein Dienst besteht in diesem Komponenten Famewok aus meheen veschiedenen CORBA-Komponenten und eine eigenen Applikationslogik (ode auch Dienstlogik). Die Applikationslogik steuet die einzelnen CORBA-Komponenten ode die veschiedenen Dienste und bildet somit eine hieachische Applikationsstuktu. Die Abbildung 7.4 zeigt wie eine n-tie Applikation aufgebaut sein kann. Python- Skipt Applikationslogik ŒŒŒ ŒŒŒ ŒŒŒ A B C ŽŽŽ ŽŽŽ ŽŽŽ Dienste CORBA-Komponenten Abbildung 7.4: Hieachische Stuktu eine n-tie Applikation Die Tennung zwischen Applikationslogik und Seven födet das Estellen von kleinen, geneellen und flexiblen Komponenten. Diese Seve Komponenten können daduch späte viel einfache wiedevewendet weden. Die Abtennung de Applikationslogik von den CORBA-Komponenten bingt eine bessee Abstaktion. Diese Abstaktion födet das Veständnis de Applikation ode des Dienstes und veeinfacht das Auffinden von Fehlen, da eineseits die Komponenten einzeln getestet weden können, und andeeseits die ganze Steueung zentalisiet ist. Diese Ansatz macht veteilte Applikationen einfache und veständliche. Eine Veändeung eines Seves bei gleichbleibendem Inteface und gleiche Semantik (Vesioningpoblem) hat keinen Einfluss auf die Applikationslogik. Das heisst ein seh wichtige Teil de Applikation muss bei einem Seve update nicht eneuet weden. Bei nachtäglichen Abändeungen ode Eweiteungen eine Applikation können bestehende Seve-Komponenten einfach wiedevewendet weden und es muss hauptsächlich die Steueung

71 7.2. KOMPONENTEN FRAMEWORK FÜR CORBA 61 im Skipt angepasst weden. Solche Beispiele weden in de FAMOOS-Fallstudie gezeigt (vgl. Kapitel 8) Python - die Skipt-Spache Die Komponenten-Poxy-Methode emöglicht Python den Zugiff auf eine CORBA-Komponente ohne dass de Benutze Kenntnisse von CORBA benötigt. Diese Zugiff auf die CORBA-Komponenten efolgt übe ein Stellvetete-Objekt. Eine CORBA-Applikation kann auf diese Weise mit Hilfe eines Python-Skipts estellt weden. Python eignet sich gut zum Scheiben von kleinen, flexiblen Skipts, die Stellvetete-Objekte steuen und vebinden. Python hat viele Eigenschaften (vgl. Abschnitt 3.4), die fü eine fehlefeie Entwicklung und paktische Vewendung eine Applikation eingesetzt weden können, wie zum Beispiel das Estellen eine gafischen Benutzeobefläche ode eines Testskipts. Ein Stellvetete-Objekt wid in dei Schitten estellt; das sieht im Beispiel de FuitStoe- Komponente (vgl. Beispiel C.2.3) wie folgt aus: impot coba_poxy gp = coba_poxy.genealpoxy() fuitstoe = gp.load("fuitstoe") Zuest wid das Modul coba poxy geladen. Dann muss das GenealPoxy-Objekt instanziet weden. Und dittens wid mit de Methode load das Stellvetete-Objekt ezeugt. Die Skipt-Spache Python hat in diesem Komponenten Famewok hauptsächlich die folgenden wichtigen Aufgaben: Eineseits ist die Skipt-Spache Python in diesem Famewok dazu da, die einzelnen CORBA-Komponenten zu vebinden und zu steuen, das heisst die Applikationslogik befindet sich in einem Skipt. Andeeseits ist das Testen von Komponenten eine kontollieende Aufgabe, die die Komponenten abschliessend testet, bevo sie zum Einsatz kommen. Das Testen von einzelnen Komponenten kann mit Hilfe von Python duchgefüht weden. Abschliessend efolgt eine Inteaktion mit dem Benutze meist übe eine gafische Benutzeobefläche. Eine gafische Benutzeobefläche kann in einem Python-Skipt estellt weden. Testen von Komponenten Bevo Softwae-Komponenten vewendet weden, sollten sie getestet weden, denn testen ist ein Pozess, de das Vetauen de Benutze aufbaut (vgl. [Sch94]). Unte Testen wid das Püfen von Softwae-Komponenten duch Ablauf in eine definieten Umgebung vestanden. Man kann eineseits die Komponenten inteaktiv debuggen, das heisst man estellt ein Stellvetete-Objekt (wie in Absatz beschieben) und sucht nach Fehlen. Ode es wid andeeseits ein Skipt geschieben, dass dann veschiedene Tests duchfüht. Die Abbildung 7.5 zeigt die veschiedenen Testszenaien, die sich wie folgt untescheiden lassen:

72 62 KAPITEL 7. KOMPONENTEN-PROXY DB Python- Skipt Python- Skipt b) a) Komponenten- Poxy Modul š š š š š š œ œ œ œ œ œ Abbildung 7.5: Test von CORBA-Komponenten a) Fü eine CORBA-Komponente wid ein Test-Skipt estellt, damit kann diese Komponente wähend de Entwicklung egelmässig auf ihe Koektheit hin gepüft weden (egession test). Eine Komponente wid mit Testdaten und Testesultaten aus eine Datenbank getestet. Koektuen und nachtägliche Eweiteungen können zu neuen Fehlen fühen. Mit Hilfe des Regessionstests wid gepüft, ob die Komponente auch nach de Veändeung noch koekt ist. b) Eine alte Komponente wid duch eine neue esetzt. Das Skipt füht bei beiden Komponenten dieselben Opeationen aus, und vegleicht anschliessend die Resultate. GUI (Gaphical Use Inteface) Ein wichtige Aspekt eine Applikation stellt die gafische Benutzeobefläche da. Es gibt Benutze, die Applikationen nu auf Gund ihe paktischen gafischen Obeflächen kaufen und vewenden. GUIs können mit Python geschieben weden, da mit Python auf eine seh einfache At eine gafische Benutzeobefläche estellt weden kann. Python kennt mindestens vie veschiedene Möglichkeiten um ein GUI zu estellen (vgl. [vlf97]). Die umfangeichste und bekannteste Möglichkeit bietet das Tkinte-Modul. Das Tkinte-Modul wid von einem Geometie-Manage untestützt, de die Positionen de Widgets 2 in einem Fenste beechnet. Die Abbildung 7.6 zeigt als Beispiel eine kleine Inteaktion mit einem Benutze fü eine Passwotabfage, die in Python geschieben wude. Natülich können auf diese Weise auch komfotable Menüsteueungen fü gosse Applikation pogammiet weden. 2 Unte einem Widget wid ein Beeich in einem Fenste (GUI) vestanden, de ein bestimmtes Aussehen und eine wohl definiete Funktionalität hat. Ein Knopf (Button) ode eine Dialogbox sind Beispiele von Widgets.

73 7.2. KOMPONENTEN FRAMEWORK FÜR CORBA 63 Abbildung 7.6: Gafische Benutzeobefläche eine Passwotabfage Glue - Wapping von legacy components Ein sogenannte Glue (engl. leimen) wid vewendet, um Komponenten, die nicht zu vogegebenen Achitektu gehöen, anzupassen. Man kann zwischen zwei Typen von Glue untescheiden (vgl. [SN98a]): Adaption Tansfomation Adaption von Komponenten an die Achitektu Damit die Komponenten-Poxy-Methode vewendet weden kann, müssen CORBA-Komponenten voliegen. Damit eine beeits bestehende Nicht-CORBA-Komponente auch als Komponenten- Poxy vewendet weden kann, muss man diese zuest CORBAifizieen. Wapping (Einhüllen) ist die Technik fü diese Anpassung (vgl. die Design Patten Bidge in [GHJV95] und Object Wappe in [MM97]). Duch das Wapping weden die Komponenten eingehüllt und mit deselben Funktionalität abe in einem andeen Umfeld wiedevewendet. Eine Adaption bescheibt, wie eine nicht zu Achitektu gehöende Komponente (legacy application) zum Famewok adaptiet wid (vgl. Abbildung 7.7). Bestehende Applikationen können in igendeine Pogammiespache implementiet sein. Es stellt sich nun das Poblem, wie man diese Komponenten zu eine CORBA-Komponente umwandelt. Man untescheidet zwischen den folgenden Typen von sogenannten Nicht-CORBA-Komponenten: Komponenten eine Spache mit CORBA-Anbindung: Eine Softwaekomponente die zum Beispiel in C++ geschieben ist, kann nicht a pioi in eine CORBA-Komponente umgewandelt weden. Es stellt sich die Fage: Sind die in de Komponente vewendeten Signatuen konfom zu IDL-Datentypen? Wenn ja, dann kann man diekt aus de Komponente eine CORBA-Komponente estellen und wie in Absatz CORBA-Seve - die Komponenten beschieben, in das Famewok integieen.

74 64 KAPITEL 7. KOMPONENTEN-PROXY legacy component Adaption Wappe žžžžžžž žžžžžžž žžžžžžž žžžžžžž žžžžžžž ŸŸŸŸŸŸŸ ŸŸŸŸŸŸŸ ŸŸŸŸŸŸŸ ŸŸŸŸŸŸŸ ŸŸŸŸŸŸŸ CORBA ORB Abbildung 7.7: Adaption eine Komponente duch einen Wappe De Uspung diese Poblematik liegt in den Spachanbindungen an CORBA. Es weden alle IDL-Datentypen auf Datentypen eine Pogammiespache abgebildet abe nicht umgekeht, das heisst, dass gewisse Pogammiespachen Datentypen haben, die von CORBA nicht untestützt sind. Zum Beispiel kann ein Aay von vaiablem Datentyp, wie man es von Python he kennt, nicht in einen IDL-Datentyp umgewandelt weden. Softwaekomponenten mit nicht untestützten Signatuen müssen in eine andeen Fom epäsentiet weden. Eine Möglichkeit dies zu eeichen wäe zum Beispiel das Scheiben eine neuen Methode, welche die inkompatible Methode aufuft, abe danach eine IDLkonfome Signatu hat. Komponenten eine Spache ohne CORBA-Anbindung: Fü Applikationen, die in eine Spache ohne IDL-Anbindung geschieben wuden, muss man auf jeden Fall einen Wappe bauen. Das heisst die bestehende Komponente wid umwickelt und mit einem neuen Inteface vesehen. Diese Umwicklung kann zum Beispiel auf die folgenden zwei veschiedenen Aten ealisiet weden: Eine Komponente wid duch eine Spacheweiteung adaptiet. Das Wapping eine Applikation kann mit Hilfe von Paamete-Optionen efolgen. Zum Beispiel können Systemopeationen (wie beispielsweise ein sot-befehl in UN- IX) duch einen Kommandoaufuf und den entspechenden System-Paameten gewappt weden. Und dann duch ein CORBA-Seve epäsentieen. binäe Komponenten: Softwae, die nu in binäe Fom voliegt und es keinen Soucecode dafü gibt. Solche Softwae-Komponenten können meistens nicht an CORBA adaptiet weden, da fü das Wapping oft auch de Soucecode leicht angepasst weden muss. Tansfomation Eine Tansfomation fomt inkompatible Datenfomate um. Die CORBA-Komponenten definieen im IDL-Inteface, wie ihe Methoden vewendet weden können. Im Inteface wid fü jede

75 7.2. KOMPONENTEN FRAMEWORK FÜR CORBA 65 Methode die Signatu angegeben. Die Abbildung 7.8 zeigt schematisch, wie zwei Komponenten auf Gund ihe inkompatiblen Datentypen nicht vebunden weden können. Mit Hilfe eine Umwandlung in de Applikationslogik können diese Komponenten abe miteinande kommunizieen. A Umwandlung Abbildung 7.8: Tansfomation von inkompatiblen Datentypen in de Applikationslogik De Time-Seve und de Display-Seve (vgl. im Anhang C.2.4) sind zum Beispiel CORBA- Komponenten, die zueinande inkompatibel sind. Das Inteface des Time-Seves sieht wie folgt aus: // Inteface of a Time-Seve module Time{ inteface TimeIF{ shot get_hou(); shot get_minute(); }; }; Das Inteface TimeIF hat zwei Methoden get hou und get minute, die die aktuelle Stunde beziehungsweise die Minuten in Fom eines shot liefet. Die CORBA-Komponente des Time-Seves wude in diesem Beispiel so gewählt, dass sie die Zeit eine andeen Zeitzone 3 liefet. De Display-Seve hat das folgende Inteface: // Inteface of a Display-Method inteface DisplayIF{ void display_time(in sting time); }; Die Tansfomation efolgt im nachfolgenden Skipt: B impot coba_poxy gp = coba_poxy.genealpoxy() time = gp.load("time") display = gp.load("display") h = time.get_hou() m = time.get_minute() m = (m - 30)%60 h = (h-2)%24 display.display_time("es ist " + st(h)+":"+st(m)+" Uh.") hat. 3 Genaue gesagt, musste die Komponente ga nicht speziell angepasst weden, da das JDK dieses Fehlvehalten

76 66 KAPITEL 7. KOMPONENTEN-PROXY In dem Code des aufgelisteten Skipts weden zwei Tansfomationen gemacht. Estens liefet de TimeSeve die Zeit eine andeen Zeitzone, das heisst die Uhzeit muss um die Zeitveschiebung angepasst weden. Zweitens muss dem Display-Seve ein Sting übegeben weden. Die Uhzeit muss dahe von einem shot in einen Sting umgewandelt weden (Typenumwandlung, casting). 7.3 Zusätzliche Möglichkeiten Die Komponenten-Poxy-Methode veeinfacht die Vewendung von CORBA-Seven. Das Komponenten Famewok hilft Applikationen zu bauen, die aus einfachen, flexiblen Komponenten bestehen. Die Methode soll den Einsatz von Python in CORBA föden. De Agent und de Intelligent Poxy sind zwei mögliche Anwendungsbeeiche, bei denen man diese Methode einsetzen kann Intelligent Poxy Die in diesem Kapitel vogestellte Methode coba poxy emöglicht das Ezeugen von Stellvetete-Objekten, die jeweils die Methodenaufufe an den Oiginal-Seve weiteleiten. Die Tätigkeit de Stellvetete-Objekte besteht lediglich im Weiteleiten von Methodenaufufen. Stellvetete- Objekte haben im Allgemeinen keine weiteen Funktionalitäten. Die Abbildung 7.9 zeigt den Ansatz, wie Komponenten-Poxies mit eine gewissen Intelligenz vesehen weden könnten. De Ansatz besteht dain, dass die Stellvetete-Objekte in Vebindung mit einem zusätzlichen Pogamm und/ode eine Datenbank stehen. Mit Hilfe de Eweiteung des Komponenten-Poxy könnten zum Beispiel die folgenden Vebesseungen ealisiet weden: Es besteht die Möglichkeit zusätzliche Sicheheitsvokehungen zu teffen. Man kann sich beispielsweise eine Passwot-Abfage vostellen. Ein Benutze kann nu einen Komponenten- Poxy benutzen, wenn e das ichtige Passwot eintippt. Es ist auch denkba, einem Benutze nu patielle Zugiffsechte zu eteilen. Jedem Benutze könnte man so ein pesönliches Zugiffspofil geben. De Komponenten-Poxy speichet ein lokales Abbild de Sevedaten. Auf diese Weise könnte das Stellvetete-Objekt einfache Abfagen gleich selbst beantwoten. Dieses lokale Beantwoten von Anfagen hat einen positiven Einfluss auf die Pefomance sowie die Netzwekbelastung. Die Gewähleistung de Datenintegität stellt hingegen einen Schwachpunkt da. Es müsste zum Beispiel ein Polling betieben weden, um sich beim Seve zu ekundigen, ob die Daten noch aktuell sind. Das Stellvetete-Objekt sendet den Methodenaufuf nicht nu an den Seve, sonden auch noch an eine weitee Instanz. Ein Analyse-Tool liesse sich zum Beispiel auf diese Weise auf den Komponenten-Poxy aufsetzen (vgl. [MK98]).

77 7.3. ZUSÄTZLICHE MÖGLICHKEITEN 67 Python- Skipt DB Pogamm Intelligent- Poxy CORBA-Komponente Abbildung 7.9: Analyse Tool mit Hilfe des Intelligent Poxy Die Eweiteung de Komponenten-Poxy-Methode kann zum Beispiel duch eine Klasse Intelligent Poxy ealisiet weden. Die Klasse Intelligent Poxy ebt von dei Klassen wie aus de Abbildung 7.10 esichtlich ist. Die Intelligent Poxy-Klasse ist ein sogenanntes mixin (vgl. [Gi98]), das heisst, die Klasse besitzt keine vollständige Funktionalität, wid abe zu Kombination mit weiteen Klassen fü die Mehfachveebung vewendet. Wichtig fü die Eweiteung de Intelligent Poxy-Klasse ist die Klasse Poxy, welche auf dem Poxy Design Patten in Python (vgl. [Ves97]) basiet. Fü den nachfolgenden Code de Klasse Intelligent Poxy ist die pythonspezifische Ababeitungseihenfolge (von links nach echts) de geebten Klassen von Bedeutung (vgl. [vr96]): class Intelligent_Poxy(Extension, Restiction, Poxy): def init (self, subject): Poxy. init (self, subject) # based on the Python s Poxy-Patten class Poxy: def init (self, subject): self. subject = subject def getatt (self, name): logfile(name) etun getatt(self. subject, name) # fo an analyse tool Die Klasse des Intelligent Poxy emöglicht Stellvetete-Objekten die folgenden neuen Möglichkeiten: Eweiteung von CORBA-Komponenten Einschänkung von CORBA-Komponenten

78 68 KAPITEL 7. KOMPONENTEN-PROXY Extension Restiction Poxy Intelligent-Poxy Abbildung 7.10: UML Klassendiagamm des Intelligent Poxy Ansatz fü ein Analyse-Tool Die folgende Klasse Extension ist eine Supeklasse de Klasse Intelligent Poxy und emöglicht eine Eweiteung von bestehenden CORBA-Komponenten. # This is an extention of the Hello-Seve class Extension: def good_moning(self): etun "good moning!!\n" # extend the component with a method In de oben definieten Klasse Extension wid die in Java geschiebene Hello-Komponente (vgl. im Anhang C.2.1) um die Methode good moning eweitet. Auch die Klasse Restiction ist eine Obeklasse von de Klasse Intelligent Poxy und elaubt es bestehende CORBA-Komponenten einzuschänken. class Restiction: def say_hello(self): pass Die Klasse Restiction macht die Methode de Hello-Komponente unzugeifba, das heisst die Methode say hello wid übeschieben duch die Klasse Restiction. De Ansatz fü ein Analyse-Tool wid in de Klasse Poxy gelegt. In diese Klasse wid die Methode logfile aufgeufen und die sieht in de einfachsten Fom wie folgt aus: def logfile(name): pint "log", name Die Vewendung sieht zum Beispiel wie folgt aus: >>> gp = coba_poxy.genealpoxy() GenealPoxy init >>> helloseve = gp.load("hello") ceate Object >>> pint helloseve.say_hello() Hello wold!!

79 7.3. ZUSÄTZLICHE MÖGLICHKEITEN 69 >>> ip = Intelligent_Poxy(helloseve) >>> pint helloseve.say_hello() Hello wold!! >>> pint ip.say_hello() None >>> pint ip.good_moning() good moning!! In diese beispielhaften Vewendung wid ein Stellvetete-Objekt helloseve von dem CORBA-Seve Hello ezeugt. Diese Komponente wid anschliessend mit de Klasse Intelligent - Poxy, wie oben definiet, um die Methode good moning eweitet und um die Methode say hello eingeschänkt und heisst nun ip Agent (Mobile Agent) Unte einem Mobile Agent kann man sich dasselbe vostellen, wie unte einem Handelseisenden: Jemand, de von Ot zu Ot eist, um dot jeweils gewisse Geschäfte (Tätigkeiten) zu eledigen und kommt mit den gewünschten Resultaten zuück (fü eine genaue Definition vgl. zum Beispiel [FG96] ode [Mil96]). In einem lokalen Netzwek könnte ein solche Agent zum Beispiel die folgenden Aufgaben eledigen und daduch eine geingee Netzwekbelastung eeichen: Laufende Pogamme eines bestimmten Benutzes suchen Pogamme, die zu ausgeloggten Uses gehöen, finden. Dateien auf /va/tmp, die älte als 30 Tage sind, suchen. Suchen von Dateien im lokalen Filesystem, die 10MB (zum Beispiel übelaufende Log- Files) sind. Mit Hilfe de Komponenten-Poxy-Methode kann ein Mobile Agent estellt weden. Ein COR- BA-Seve kann einen Agenten entgegennehmen, ihn seine Tätigkeit ausfühen lassen und weiteleiten. Ein Agent füht bei einem entspechenden Seve seine Tätigkeit (Skipt) aus und geht je nach Auftag zum nächsten Seve ode zuück. Man kann die folgenden zwei veschiedenen Typen von Mobile Agent untescheiden: De Agent besucht nu eine Maschine und bingt anschliessend die Resultate zuück. Danach geht e zum nächsten Rechne. In Abbildung 7.11 wid diese Agent Sending Agent genannt, da e po Auftag nu zu einem Kunden gesandt wid und anschliessend wiede zuückkommt. Ein Tavelling Agent wid von einem Auftaggebe (Python-Skipt) von Maschine zu Maschine geschickt, bis e alle möglichen Kunden (Rechne) besucht hat (vgl. Abbildung 7.12). Bei de Rückmeldung de Resultate kann man zwischen eine diekten (am aktuellen Ot kommt eine diekte Meldung zum Auftaggebe) und eine stufenweisen Rückmeldung an den jeweiligen Aufufe (die Resultate gehen duch jeden bishe besuchten Rechne zuück zum Auftaggebe) untescheiden.

80 70 KAPITEL 7. KOMPONENTEN-PROXY Host D ª ª ª ª ª ª Host C «««««««««Python- Skipt Host B Host A Host D ± ± ± ± ± ± ² ² ² ² ² ² Abbildung 7.11: Sending Agent Host C ³ ³ ³ ³ ³ ³ ³ ³ ³ Python- Skipt µ µ µ µ µ µ µ µ µ Tavelling Agent Seve Host B Host A Applikationslogik Abbildung 7.12: Tavelling Agent Tavelling Agent - ein Beispiel In diesem Absatz wid als Beispiel ein Tavelling Agent beschieben, de von Rechne zu Rechne geht, um zu schauen, ob sich im /va/tmp -Vezeichnis die gesuchte Datei befindet. Die veteilte Applikation besteht aus eine Applikationslogik und meheen Tavelling Agent Seven. Die Applikationslogik ezeugt einen Agenten, de mit einem Auftag von Seve zu Seve geht um gewisse Tätigkeiten auszufühen. De Agent enthält eine Agentenlogik (eigene Applikationslogik), damit e selbstständig duch das lokale Netz navigieen kann. Mit Hilfe diese Agentenlogik kann de Agent einen Auftag in einem Seve eledigen und die Resultate sammeln. Das IDL-Inteface de Tavelling Agent-Seve sieht wie folgt aus: // IDL Inteface fo the tavelling agent seve module Agent { exception Invalid_Scipt{}; inteface AgentIF { sting my_scipt(in sting scipt) aises (Invalid_Scipt);

81 7.3. ZUSÄTZLICHE MÖGLICHKEITEN 71 }; }; Das Inteface besteht aus eine Methode my scipt, die eine Ausnahme geneieen kann. In diese Methode wid de Tavelling Agent als Agument in Fom eines Skipts zum Seve gelangen. De Tavelling Agent Seve wid dann den Agenten mit exec staten. Gibt es bei de Ausfühung einen Fehle, so wid eine Ausnahme ezeugt. In de Applikationslogik hat es eine Methode agent, die den Tavelling Agent geneiet und auf den Weg schickt. Übe das Agument (to do) kann man dem Tavelling Agent den Auftag eteilen. De Auftag besteht aus einem Python-Skipt und muss eine Vaiable esult haben, wo das Resultat des Auftages abgelegt wid. Nachfolgend wid die Schlüsselmethode agent de Applikationslogik gezeigt: # application logic; build the tavelling agent # the agument "to_do" contains the job (python-scipt) fo the tavelling agent def agent(self, to_do): # build the head of the tavelling agent head = """ impot coba_poxy, sting # seves to visit seves = sting.splitfields(sevelist, ",") if len(seves): # is thee a seve nextseve = seves[0] # take the fist seves.emove(seves[0]) sevelist = "" fo s in seves: sevelist = sevelist + s + "," else: nextseve = "" sevelist = sevelist[:-1] """ # build the tail of the tavelling agent tail = """ if len(nextseve): # the data of the tavelling agent contains tee infomations # sepaated by a "<:--:>" data = home+ "<:--:>"+sevelist+"<:--:>"+ esult # the tavelling agent has a scipt and data sepaated by a "<- ->" TA = scipt + sepaato + data # connect to the next TASeve gp = coba_poxy.genealpoxy() ta = gp.load(nextseve) # send the tavelling seve to do the job ta.my_scipt(ta) """ # the scipt (logic of the agent) is a sting containing # a head, a scipt (agument) and a tail

82 72 KAPITEL 7. KOMPONENTEN-PROXY scipt = head + to_do + tail sepaato = "<- ->" # connect to the NameSeve gp = coba_poxy.genealpoxy() nameseve=gp.load("nameseve", " held/ior/nameseve.ef") # initialize sevelist = "" fistseve = "" # whee to go? fo i in ange(nameseve.numbe_available_seves()): seve = nameseve.get_seve_name(i) if sting.count(seve, "TA_Seve"): if len(fistseve): sevelist = sevelist + seve + ", " else: fistseve = seve sevelist = sevelist[:-1] # whee is the application logic machine = posix.uname()[1] pint "home: ", machine # home-host <:--:> sevelist <:--:> esultsting data = machine + "<:--:>" + sevelist + "<:--:>0" # the tavelling agent has a scipt and data ta = scipt + sepaato + data # send the scipt and the data to the next TASeve if len(fistseve): gp = coba_poxy.genealpoxy() ta_home = gp.load(fistseve) ta_home.my_scipt(ta) else: pint "un a TASeve.py" Die Methode agent estellt einen Tavelling Agent und schickt ihn auf den Weg. De Tavelling Agent besteht aus eine Agentenlogik scipt und Daten data (vgl. Abbildung 7.13). Die Daten weden duch das folgende Potokoll übetagen: data = home+ "<:--:>"+sevelist+"<:--:>"+ esult agent scipt data head to_do tail home sevelist esult Abbildung 7.13: Aufbau des Tavelling Agent Jede Tavelling Agent speichet in home die Adesse seine Applikationslogik, damit die Resultate zuückgesendet weden können. Die sevelist enthält die Namen alle Seve, die de

83 7.3. ZUSÄTZLICHE MÖGLICHKEITEN 73 Agent noch besuchen muss. In esult befinden sich alle bishe gesammelten Resultate (ein At Quittungen). Das Skipt, die Agentenlogik, geht imme mit dem Tavelling Agent mit und wid in dei Teile aufgeteilt und sieht wie folgt aus: scipt = head + to_do + tail Im head weden die aktuellen Module geladen, sowie de nächste zu besuchende Seve bestimmt. to do ist ebenfalls ein Skipt, das schon als Agument de Methode agent de Applikationslogik übegeben wude und das die eigentliche Aufgabe des Agenten beinhaltet. In tail wid de Tavelling Agent wiede zusammen gebaut und zum nächsten Tavelling Agent Seve geschickt. De Tavelling Agent besucht auf seine Reise Seve, die wie folgt aussehen: # tavelling agent seve def my_scipt(self, ta): local_name_space = { name : main } scipt, data = sting.splitfields(ta, "<- ->") home, sevelist, esult = sting.splitfields(data, "<:--:>") # pass data to the scipt(hee: sepaato, scipt,...) local_name_space["sepaato"] = "<- ->" local_name_space["scipt"] = scipt local_name_space["home"] = home local_name_space["sevelist"] = sevelist[:-1] local_name_space["esult"] = esult # stat the scipt exec(scipt)in local_name_space, local_name_space # send the esult home gp = coba_poxy.genealpoxy() ta_home = gp.load("tahomeseve") if len(local_name_space["esult"]): es = local_name_space["esult"] else: es = "No esults" machine = posix.uname()[1] # etun the esults to the home town ta_home.collect_esult("results fom " + machine + ":\n" + es) Im obigen Seve weden gemäss dem in diesem Beispiel vewendeten Potokoll Agentenlogik und Daten, sowie die einzelnen Infomationen euiet. Diese weden dann übe gemeinsame Vaiablen dem Skipt zu Vefügung gestellt. Das Skipt wid dynamisch mit exec gestatet. Abschliessend wid das Resultat (wiede übe eine gemeinsame Vaiable esult) de Applikationslogik zuückgegeben.

84 74 KAPITEL 7. KOMPONENTEN-PROXY 7.4 Genzen In diesem Abschnitt weden Genzen de Komponenten-Poxy-Methode aufgezeigt. Es wid eläutet, wieso mit diesem Modul coba poxy im Moment noch kein dynamische Methodenaufuf möglich ist. Es ist abe möglich einen sogenannten halb-dynamischen Methodenaufuf zu geneieen. Python-Komponenten können nicht automatisch zu CORBA-Komponenten umgewandelt weden Kein dynamische Methodenaufuf Ein CORBA-Client kann mit Hilfe des Dynamic Invocation Inteface dynamisch Methoden aufufen, das heisst, de Client kann auch ohne das compiliete Inteface, den Stub, auskommen (vgl ). Um einen dynamischen Methodenaufuf zu ezeugen, wid das Inteface Repositoy vewendet. Das Inteface Repositoy ist seit CORBA 2.0 standadisiet. Die ORB-Hestelle sollten eigentlich alle das Inteface Repositoy einheitlich implementiet haben. Somit sollte ein dynamische ORB-übegeifende Zugiff auf die CORBA-Komponenten möglich sein. Bei den duchgefühten Testvesuchen konnte abe festgestellt weden, dass ein solche Zugiff im Moment noch nicht möglich ist, da das Inteface des efeenzieten Objektes nicht emittelt weden kann. Genaue gesagt, konnte de Zugiff auf das entfente Inteface Repositoy nicht ealisiet weden. Diese unglückliche Situation wude auf Anfage vom Entwickle des Fnobs bestätigt und als geneelles CORBA 2.0 Poblem beschieben. De Vesuch von Python übe den Fnob und den VisiBoke auf einen CORBA-Seve zuzugeifen, endete beim folgenden Pogammschitt: full_int_desc = intdef.descibe_inteface() ==> beak down. Das hat zu Folge, dass ein ORB-unabhängige, dynamische Ansatz (wie die Komponenten- Poxy-Methode) ohne einen Eingiff auf einen ORB veunmöglicht wid. Im globalen NameSeve kann das IDL-Inteface abgespeichet weden. Somit könnte man die Intefacebescheibung de Seve auch aus dem NameSeve elangen. Diese Ansatz wüde abe einen Nachbau eines Inteface Repositoy bedeuten Halb-dynamische Methodenaufuf Es hat sich gezeigt, dass ein Methodenaufuf mit de Komponenten-Poxy-Methode nu dann zustande kommt, wenn neben de IOR auch de duch den Compile ezeugte Stub des Seves voliegt. Ist de Stub noch nicht vohanden, so bietet de globale NameSeve eine zusätzliche Möglichkeit, indem e neben dem Sevename, Stub und IOR auch noch das IDL-Inteface speichen kann. Das emöglicht dem Client zu Laufzeit den Compile zu staten und sich den Stub zu ezeugen. Anschliessend kann das Seve-Objekt efeenziet weden und statisch eine Methode

85 7.4. GRENZEN 75 aufufen. Als Beispiel wid nachfolgend de Stub des Counte Seve (vgl. im Anhang C.2.2) dynamisch geneiet: # dynamic geneation of a stub impot fnidl idl_file = ns.get_idl("countseve") pint "IDL-file: ", idl_file pint "Geneating the stub. Wait..." fnidl.main(["", idl_file]) Zu Veeinfachung wid die Datei des IDL-Intefaces lokal abgelegt. De NameSeve muss somit nu den Dateinamen kennen. Danach wid mit dem Modul fnidl (Compile von IDL nach Python) de Stub ezeugt Abbildung von Python-Komponenten nach CORBA Die Abbildung 7.14 zeigt, dass CORBA-Komponenten mit Hilfe de Komponenten-Poxy-Methode nach Python abgebildet weden können (vgl. Abschnitt 7.1). Die Methode coba poxy estellt von eine CORBA-Komponente ein Stellvetete-Objekt, auf das dann Python zugeifen kann. De umgekehte Ansatz bietet veschiedene Pobleme. Diese Absatz soll Pobleme aufzeigen, die ein automatisches Abbilden von Python-Objekten nach CORBA hat. Skipt- Spache Modul CORBA Abbildung 7.14: Kein Python-Poxy fü CORBA Um Python-Objekte automatisch nach CORBA abbilden zu können, muss man aus einem Objekt das Inteface bestimmen. Fü Python-Pogamme ist das abe nicht so einfach möglich, da die Spache dynamisch typisiet ist. Bei eine Methode weden die Agumente nicht deklaiet und weden nu zu Laufzeit bestimmt. Die Signatu eine Methode kann dahe oft nu duch den Kontext bestimmt weden. Die folgende Methode out ist zum Beispiel est zu Laufzeit eindeutig bestimmt: def out(x): pint x Ist das Agument x de Methode out ein Intege ode abe ein Sting? Um zu bestimmen, was das Agument x fü einen Datentyp hat, müsste man den Pogammcode analysieen. Es kann

86 76 KAPITEL 7. KOMPONENTEN-PROXY abe auch sein, dass de Datentyp von x nicht eindeutig bestimmt weden kann, wenn zum Beispiel eine Inteaktion mit dem Benutze voliegt. In Python ist es auch möglich, dass das Attibut x einmal ein Sting und danach wiede als Intege aufgeufen weden kann. Python hat veschiedene Möglichkeiten die Agumente eine Methode zu definieen. Die Agumente eine Methode können in Python zusätzlich auch optional, von vaiable Anzahl ode ungeodnet definiet weden (vgl. 3.4). Nachfolgend ist ein Beispiel eine Methode definiet, die mit vaiable Anzahl Agumenten geufen weden kann: def sum(*x): s = 0 fo i in x: s = s + i etun s Die Methode sum kann zum Beispiel mit sum(2, 3) ode abe mit sum(1, 2, 3) geufen weden. CORBA untestützt in seine IDL keine solche Intefaces. Ein Aay kann in Python Elemente von veschiedenen Datentypen haben. Das folgende Aay ist beispielsweise in Python elaubt: a = [2, "da"] Das oben gezeigte Aay a enthält einen Intege 2 und einen Sting da. In CORBA ist ein solches Aay unmöglich, da ein Aay nu von einem Datentyp sein daf.

87 Kapitel 8 Fallstudie: FAMOOS Ziel de Fallstudie ist es, die in dem letzten Kapitel entwickelte Methode coba poxy und dessen Komponenten Famewok zu validieen. Bestehende Komponenten weden duch den Glue des Komponenten Famewok adaptiet. 8.1 Das FAMOOS-Pojekt Die Softwae Composition Goup 1 (SCG) abeitet unte andeem an einem Foschungspojekt FA- MOOS. FAMOOS ist die Abküzung fü Famewok-based Appoach fo Masteing Object-Oiented Softwae Evolution und ist ein ESPRIT-Pojekt 2. Es handelt sich um ein dei Jahe dauendes Foschungspojekt, welches am 1. Septembe 1996 begonnen hat. Dieses Foschungspojekt hat das folgende Ziel: Existieende Softwae soll duch eine geeignete Reengineeing flexible gemacht weden. Im FAMOOS-Foschungspojekt weden Methoden fü das Reengineeing entwickelt. Mit Hilfe de neuen Reengineeing-Methoden sollten vealtete objektoientiete Applikationen in ein Famewok umgewandelt weden. Die Abbildung 8.1 (von [DT98])) zeigt den FAMOOS Reengineeing-Lebenszyklus, de in die folgenden sechs Schitte unteteilt wude: (1) Analyse de Anfodeungen: In den Anfodeungen weden die Ziele fü das Reengineeing bestimmt. (2) Efassen des Modells: Die Einabeitung in das Modell efolgt übe das Veständnis von Applikation und deen Dokumentation. 1 Die Softwae Composition Goup ist die Foschungsguppe von Pof. D. O. Niestasz an de Univesität Ben. 2 ESPRIT-Pojekte sind Foschungs- und Entwicklungsaktivitäten auf dem Gebiet de Infomationstechnologie. FA- MOOS ist das ESPRIT-Pojekt mit de Numme

88 78 KAPITEL 8. FALLSTUDIE: FAMOOS Abbildung 8.1: Famoos Reengineeing-Lebenszyklus (3) Poblemanalyse: Mit de Analyse de Pobleme untesucht man Flexibilitäts- und Qualitätsaspekte. (4) Poblemlösung: De Lösungsansatz definiet die Wahl de neuen Softwae Achitektu. (5) Reoganisation: Die alte Applikation wid duch eine Umwandlung zu einem neuen Modell veändet. (6) Vebeitung de Veändeung: Das neue System wid bei den Kunden eingefüht, damit von de neuen Vesion pofitiet weden kann. Fü eine gezielte Foschung wuden die folgenden dei Foschungsgebiete bestimmt: Metiken & Heuistiken Modulaisieung (Gouping) Reoganisation Die intenationalen FAMOOS-Patne 3 estellen in den einzelnen Foschungsgebieten ihe eigenen Pototypen von Applikationen fü die geplanten Expeimente. Die Applikationen können in veschiedenen Pogammiespachen implementiet weden. Diese Applikationen weden in eine Bibliothek als Basis fü weitee Expeimente zu Vefügung gestellt. Damit sich die Applikationen veständigen können, wude ein Modell fü den Datenaustausch entwickelt. Dieses Modell heisst FAMOOS Infomation Exchange Model (vgl. [DT98]) und macht eine spachunabhängige Repäsentation eines objektoientieten Souce-Codes. Die Repäsentation bietet genug Infomationen fü Reengineeing-Aufgaben. Fü den effektiven Datenaustausch wid das einheitliche Fomat CDIF (Common Data Intechange Fomat) vewendet, das heisst, eine Applikation kann in ein Modell abgebildet weden und wid duch CDIF festgehalten. CDIF ist ein industielle Standad (vgl. [CDI98]), de als flache ASCII-Stom epäsentiet wid. CDIF eignet sich gut fü die Foschung, da diese ASCII-Stom (¹2¹2¹3ºË$ʾ̺Ã)Å ), und Sema Goup (¹2¹1¹ÂºÍÅ4Á 'ºÅÍ ). 3 Die Foschungspatne sind Nokia (¹1¹2¹3º»'¼%½!¾ -ºÀ¼Á ), Daimle-Benz (¹1¹2¹ÂºÃ )¾Á6Ä9ÅÆRÇÉÈÅ4»:Ê!ºÀ/¼%Á ), FZI

89 8.2. EINLEITUNG 79 ein veständliche Code dastellt und daduch eine Fehlesuche veeinfacht. 8.2 Einleitung Fü die voliegende Abeit ist FAMOOS geeignet, da in diesem Foschungspojekt veschiedene voneinande unabhängige Komponenten entwickelt weden. Die Abbildung 8.2 gibt einen Übeblick des aktuellen Standes de Foschung in diesem Pojekt. Die beeits estellten und vewendeten Komponenten weden nachfolgend kuz beschieben: SNiFF+ sniff2cdif FAMOOS- Dastellung (a) C++ (b) C (c) Java Inteface Pojekt Code Pojektdatei (.poj) Pojektdatei (.poj) CDIF Datei CDIF Datei Unix Inteface (d) FAMOOS- Dastellung (e) Metiken Smalltalk Smalltalk (f) Analyse VB Access Excel Windows CDIF Datei CDIF Datei Tabellen Tabellen Beichte Auswetungen Abbildung 8.2: Famoos Komponenten (a) SNiFF+ ist eine spachunabhängige Entwicklungsumgebung von de Fima TakeFive softwae und ist auf dem Intenet unte de folgenden URL zu finden: Mit SNiFF+ wid de Quellcode eine Applikation geladen, das emöglicht dann dem Entwickle ein komfotables Abeiten mit eine gafischen Benutzeobefläche. Ein Bowse elaubt veschiedene Ansichten wie zum Beispiel das Anzeigen alle Unteklassen eine Klasse und stellt Wekzeuge zu Vefügung. SNiFF+ speichet alle Infomationen zu eine Applikation in eine Datei. Diese Datei heisst Pojekt-Datei und hat die Endung.poj. (b) Die in C geschiebene Komponente sniff2cdif liest die von SNiFF+ gespeicheten Infomationen aus eine Pojekt-Datei und wandelt diese in eine CDIF-Repäsentation um. Die CDIF-Repäsentation wid in eine Datei abgelegt. (c) Die FAMOOS-Dastellungs-Komponente ist eine Implementieung des FAMOOS Infomation Exchange Models, welche objektoientieten Souce-Code übe ein Inteface epäsentiet. Diese Komponente wude in Java geschieben. Die FAMOOS-Dastellungs-Komponente liest aus eine CDIF-Datei die Infomationen eines Pogamms und estellt inten ein

90 80 KAPITEL 8. FALLSTUDIE: FAMOOS Modell. Das Modell kann übe ein Inteface abgefagt ode auch veändet weden. Die FAMOOS-Dastellung kann eine veändete Modell-Repäsentation wiede in eine Datei scheiben. (d) Diese FAMOOS-Dastellungs-Komponente ist analog zu (c), abe in Smalltalk geschieben. (e) Die in Smalltalk geschiebene Komponente Metiken liest den CDIF-Code aus eine Datei und ezeugt Tabellen auf Gund von vogegebenen Metiken. (f) Die Komponente Analyse liest die Tabellen aus eine Datei in VisualBasic, Access ode Excel ein und ezeugt fü die veschiedenen Metiken Beichte und Auswetungen. Die Komponenten SNiFF+, sniff2cdif und eine FAMOOS-Dastellung wuden auf dem Betiebssystem Unix entwickelt. Die Komponenten de andeen FAMOOS-Dastellung, de Metiken und de Analyse sind Komponenten, die auf einem Windows-Betiebssystem laufen. Hiezu ist zu sagen, dass die in Java und Smalltalk implementieten Komponenten auch auf andeen Betiebssystemen laufen. 8.3 Aufgabe In diese Fallstudie wuden aus dem FAMOOS-Foschungspojekt zwei Komponenten ausgewählt und mit Hilfe von dem im letzten Kapitel beschiebenen Famewok vewendet. Es sind die zwei folgenden Komponenten: Î sniff2cdif (in C pogammiet) Î die in Java geschiebene FAMOOS-Dastellung Diese Komponenten wuden ausgewählt, da mit ihnen die Basis fü die metischen Untesuchungen gelegt wid und die Mechanismen des Komponenten-Famewok (vgl. Kapitel 7.2) gezeigt weden. Beide Komponenten stellen aus de Sicht de Komponenten-Poxy-Methode legacy components da, da sie benötigt weden und keine CORBA-Komponenten sind. Die FAMOOS- Dastellung wude in Java geschieben und Java ist eine Pogammiespache, fü die es eine CORBA-Anbindung gibt. Fü die Pogammiespache C gibt es auch eine CORBA-Anbindung, doch in diese Abeit wid die Annahme getoffen, dass die sniff2cdif-komponente eine legacy component von eine Pogammiespache ohne CORBA-Anbindung sei. Auch fü eine solche Komponente soll ein Wapping-Mechanismus gezeigt weden. Nachdem die Komponenten sniff2cdif und FAMOOS-Dastellung zu CORBA-Komponenten umgewandelt woden sind, weden zwei Eweiteungen zu diesen Komponenten estellt. Eineseits wid fü die FAMOOS-Dastellung eine gafische Benutzeobefläche in Python entwickelt. Diese Benutzeobefläche soll bestehende Modelle veanschaulichen ode veänden können ode abe ein Modell von Gund auf neu estellen. Andeeseits wid eine zusätzliche CORBA-Komponente auch in Python estellt, welche die Tabellen fü die metischen Analysen ezeugt.

91 8.4. WRAPPING DER BEIDEN BESTEHENDEN KOMPONENTEN 81 Die Abbildung 8.3 zeigt das Ziel diese Fallstudie. Die zwei FAMOOS-Komponenten weden mit Wappen an das Komponenten-Famewok de Komponenten-Poxy-Methode angepasst. De TableGeneato ist eine zusätzliche CORBA-Komponente, die Tabellen fü die Analyse-Komponente estellt. Die gafische Benutzeobefläche wid mit einem Python-Skipt ealisiet. Mit Python kann auf alle dei Komponenten übe Komponenten-Poxies zugegiffen weden. Python CORBA Komponenten ÓÓÓÓÓÓ ÓÓÓÓÓÓ ÓÓÓÓÓÓ ÔÔÔÔÔÔ ÔÔÔÔÔÔ ÔÔÔÔÔÔ ÕÕÕ ÕÕÕ ÖÖÖ ÖÖÖ Ï Ï Ð Ð Ï Ï Ð Ð Ï Ï Ð Ð ØØØ ØØØ Komponenten-Poxy (in Python) sniff2cdif (in C) Wappe ÙÙÙÙÙÙ ÙÙÙÙÙÙ ÙÙÙÙÙÙ ÙÙÙÙÙÙ ÚÚÚÚÚÚ ÚÚÚÚÚÚ ÚÚÚÚÚÚ FAMOOS- Dastellung (in Java) Wappe Ñ Ñ Ñ Ñ Ò Ò Ò Ò TableGeneato (in Python) CORBA ORB Abbildung 8.3: Famoos Szenaio Anhand von exemplaischen Beispielen weden die neuen Vewendungsmöglichkeiten im FA- MOOS Foschungspojekt aufgezeigt wie zum Beispiel das pogammiespachenunabhängige Vebinden de nun veteilten FAMOOS-Komponenten. 8.4 Wapping de beiden bestehenden Komponenten Damit die bestehenden FAMOOS-Komponenten mit de Komponenten-Poxy-Methode vewendet weden können, müssen CORBA-Komponenten voliegen. Nachfolgend wid gezeigt, wie die Komponenten sniff2cdif und FAMOOS-Dastellung zu CORBA-Komponenten umgewandelt weden. Diese Umwandlungsvogang wude im Komponenten Famewok mit Gluing bezeichnet Adaption de sniff2cdif-komponente Die Komponente sniff2cdif wude in de Pogammiespache C geschieben. In diese Fallstudie wude die Aufgabe gestellt, dass diese Komponente nicht in einen in C geschiebenen CORBA- Seve umgewandelt wid. Dahe wid vesucht die Komponente möglichst geschickt zu umhüllen und eine Spache mit CORBA-Anbindung zu Vefügung zu stellen, dass eine CORBA-Komponente ezeugt weden kann.

92 82 KAPITEL 8. FALLSTUDIE: FAMOOS sniff2cdif wude in C so angepasst, dass diese Komponente von eine Shell gestatet weden kann. Die Methoden des sniff2cdif-intefaces wuden mit Hilfe von Paameten epäsentiet. Ein Shell-Aufuf de umhüllten sniff2cdif-komponente sieht zum Beispiel folgendemassen aus: sniff2cdif -level 2 +souceancho -o ziel.cdif quell.poj Mit Python wude nun ein CORBA-Seve estellt, de dasselbe Inteface wie die sniff2cdif- Komponente hat. Übe Shell-Kommandos wid die gewappte sniff2cdif-komponente aktiviet und deen Dienste vewendet. Die sniff2cdif-komponente hätte zum Beispiel auch auf die folgenden Aten gewapped weden können: Î SWIG (vgl. [Bea97]) ist ein Codeezeugungswekzeug, das C-Code eine Skipt-Spache wie Pel, Python ode Tcl duch ein Inteface zu Vefügung stellen kann. Î Eweiteung eine Pogammiespache Î In C einen CORBA-Wappe estellen Adaption de FAMOOS-Dastellungs-Komponente Die FAMOOS-Dastellungs-Komponente wude in Java implementiet. Die Implementieung des FAMOOS Infomation Exchange Models besteht aus ca. zwanzig Klassen (vgl. im Anhang C.3.2). Das Wapping de FAMOOS-Dastellungs-Komponente in eine CORBA-Komponente efolgt in dei Schitten. In einem esten Schitt muss ein IDL-Inteface zu diese Komponente definiet weden und das sieht wie folgt aus: // FamoosModel-Inteface module FM { exception Invalid_Connection{}; // Define an Enummeation-Type (it s a set) inteface enumsting { boolean hasmoeelements(); sting nextelement(); // etuns a uniquename/popetyname }; inteface FamoosModelIF { // load and save a model epesented in CDIF void loadval(in sting pat); sting saveval(); // model the model void ceateentity(in sting uniquename, in sting kind); void emoveentity(in sting uniquename); sting getkind(in sting uniquename);

93 8.5. ERWEITERUNGEN VON FAMOOS }; }; Es wude ein Inteface enumsting estellt, damit kann auf Modelle mit eine Menge von Elementen zugegiffen weden. Das inteface FamoosModelIF emöglicht das Laden und das Abspeichen eines Modells. Die weiteen Methoden elauben die Beabeitung des Modells. Im nächsten Schitt mussten zwei Klassen in Java implementiet weden, die das Seveinteface mit de FAMOOS-Dastellungs-Komponente vebinden. In einem ditten und letzten Schitt wude das definiete Inteface als CORBA-Seve beeitgestellt. Es gibt ORBs, die von eine bestehenden Nicht-CORBA Komponente das IDL-Inteface ezeugen können. Beim VisiBoke zum Beispiel ist diese Möglichkeit unte Caffeine bekannt (vgl. [Vis97]). In diese Fallstudie wid auf diese Möglichkeit vezichtet, da ein exemplaisches Wapping von Hand gezeigt weden wollte. 8.5 Eweiteungen von FAMOOS Die beiden in diese Abeit vewendeten FAMOOS-Komponenten weden mit einem GUI zu de FAMOOS-Dastellung und einem TableGeneato fü die Analyse-Komponente eweitet GUI de FAMOOS-Dastellung Zu Veanschaulichung de im FAMOOS Infomation Exchange Model gespeicheten Modelle wude eine zusätzliche gafische Benutzeobefläche (GUI) estellt. Die Abbildung 8.4 zeigt die in Python estellte Benutzeobefläche (vgl. im Anhang C.3.4). Diese gafische Benutzeobefläche kann in dei hoizontal getennte Regionen aufgeteilt weden; es entsteht ein Kopf-, ein Mittel- und ein Fussteil. De Kopfteil enthält eine Menüsteueung und diese besteht aus dei Menüs: File, Connection und Help. Das Menü Connection emöglicht den Vebindungsaufbau zu eine Famoos-Dastellungs- Komponente. Die Vebindung kann auch wiede duch Connection abgebochen weden, damit man sich mit eine andeen Famoos-Dastellungs-Komponente vebinden kann. Das Menü File emöglicht das Laden, das Speichen, das Löschen sowie das Estellen eines neuen Modells. Die eben ewähnten Möglichkeiten haben die Voaussetzung, dass eine Vebindung zu eine Famoos- Dastellungs-Komponente besteht. Unte dem Menü File kann das GUI mittels Quit beendet weden. Die gafische Benutzeobefläche elaubt in ihem Mittelteil das Anzeigen sowie die Eingabe von Infomationen. In de Abbildung 8.4 kann man sehen, wie von einem Modell alle Popeties 4 4 Ein Popety ist eine Einheit aus dem FAMOOS-Infomation Exchange Model.

94 84 KAPITEL 8. FALLSTUDIE: FAMOOS Abbildung 8.4: Gafische Benutzeobefläche fü ein FAMOOS-Modell de Klasse Test (igendein Beispiel-Modell) angezeigt weden. De Fussteil de gafischen Obefläche enthält Knöpfe, damit die Infomationen von eine Softwae in Fom eines Modells angeschaut, veändet ode auch eweitet weden können. Mit dem Knopf Ceate Entity kann zum Beispiel ein Modell um eine Methode eweitet weden. Remove Entity elaubt das Löschen eine Entität TableGeneato De TableGeneato ist eine zusätzliche CORBA-Komponente, die es elaubt die Tabellen fü die Analyse-Komponente von FAMOOS zu estellen. Diese Komponente wude estellt, da eine neue Vesion des FAMOOS Infomation Exchange Model definiet wude, und die in Smalltalk geschiebene Metiken-Komponente nicht meh auf dem neusten Stand wa. Das Inteface des TableGeneato sieht wie folgt aus:

95 8.6. VERWENDUNGSBEISPIELE 85 // TabelGeneato is aquivalent to the Analysis, FAMOOS module Metic{ inteface MeticIF{ void connect2famoosmodel(in sting fmname); sting Association_Table(); sting Attibute_Table(); sting Class_Table(); sting Entity_Table(); sting Inheitance_Table(); sting Method_Table(); sting MethodInvocation_Table(); }; }; De TableGeneato ist eine in Python geschiebene CORBA-Komponente. Das Inteface wude MeticIF genannt, da diese Komponente dasselbe Inteface hat, wie die Metiken-Komponente im FAMOOS-Foschungspojekt. Diese Komponente kann als eine Neuimplementieung eine beeits bestehenden Komponente angesehen weden, die abe nicht in die neue Achitektu passt. 8.6 Vewendungsbeispiele Inteaktives Debugging von Komponenten Mit de Komponenten-Poxy-Methode können Komponenten von Python inteaktiv gesteuet weden. Diese gibt die Möglichkeit Komponenten inteaktiv zu debuggen. So können bei de Entwicklung von Komponenten schon fühzeitig Fehle lokalisiet weden. Von diese Möglichkeit wude auch im FAMOOS-Foschungspojekt Gebauch gemacht und das sieht im Ansatz etwa wie folgt aus: >>> impot coba_poxy >>> gp = coba_poxy.genealpoxy() GenealPoxy init >>> famo = gp.load("fm") ceate Object >>> famo.loadref("test.cdif") >>> pint x.hasmoeelements() 1 >>> pint x.nextelement() Peson.set_name (self, ag) Applikationslogik - zwei Beispiele Metische Tabelle Das nachfolgende Skipt, eine Applikationslogik, vebindet die dei FAMOOS CORBA-Komponenten. Diese Applikationslogik estellt aus eine Pojekt-Datei eine metische Tabelle. # applicationlogic: geneating a metic out of a softwae-component impot coba_poxy

96 86 KAPITEL 8. FALLSTUDIE: FAMOOS gp= coba_poxy.genealpoxy() sniff2cdif = gp.load("sniff2cdif") file = open("test.poj", "") poj_steam = file.ead() file.close() cdif = sniff2cdif.eadsniffsymboltable(poj_steam, "") famoos_model = gp.load("fm") famoos_model.loadval(cdif) metic = gp.load("metic") metic.connect2famoosmodel("fm") association_table = metic.association_table() pint association_table Diese Python-Code impotiet das Komponenten-Poxy-Modul coba poxy, damit die Stellveteteobjekte de dei CORBA-Komponenten estellt weden können. Danach wid aus diesem Modul die Klasse GenealPoxy instanziet. Mit Hilfe des gp-objektes weden die Stellveteteobjekte sniff2cdif, famoos model und metic ezeugt. Duch das Objekt sniff2- cdif wid das Softwae-Pojekt Test.poj in einen CDIF-Code cdif umgewandelt. Das Stellveteteobjekt famoos model de FAMOOS-Dastellungs-Komponente lädt das Modell, das duch den cdif-code epäsentiet wid. metic, de TableGeneato, wid est mit einem FAMOOS-Dastellungs-Seve vebunden und estellt anschliessend eine metische Tabelle von allen Assoziationen, die in diesem Modell vokommen. Subset-Teste De Subset-Teste ist ein Python-Skipt, das testet, ob ein FAMOOS-Modell eine Untemenge von einem andeen FAMOOS-Modell ist. Dieses Skipt kann in Infomatik-Pojekten vewendet weden, um festzustellen, ob alle Signatuen de Spezifikation entspechen. In de Designphase weden viele Definitionen gemacht. In diese Phase des Pojektes weden hauptsächlich die Schnittstellen von Komponenten definiet. Diese Definitionen können zum Beispiel mit Hilfe des GUI de FAMOOS-Dastellungs-Komponente in einem FAMOOS-Modell M1 dagestellt weden. Fü ein Pojekt ist es wichtig, dass sich jede Pogammiee an die Definitionen des Intefaces hält. Mit Hilfe de FAMOOS-Komponenten kann wähend de Implementieungsphase aus dem vohandenen Code ein zweites FAMOOS-Modell M2 estellt weden. Mit dem folgenden Skipt kann übepüft weden, ob M1 eine Teilmenge von M2 ist. Das heisst, man kann echt schnell feststellen, ob sich jede Pogammiee an die Vogaben gehalten hat. # subset-teste: is cdif1 a subset of cdif2? impot coba_poxy, os def is_subset(cdif1, cdif2): gp = coba_poxy.genealpoxy() famo1 = gp.load("fm1") # 1. poxy

97 8.6. VERWENDUNGSBEISPIELE 87 if os.path.isfile(cdif1): famo1.clea() famo1.loadref(cdif1) else: famo1.loadval(cdif1) famo2 = gp.load("fm2") if os.path.isfile(cdif2): famo2.clea() famo2.loadref(cdif2) else: famo2.loadval(cdif2) x = famo1.enumentities() i = 0 diffeence = "" # fo all Elements while x.hasmoeelements(): i = i + 1 # load CDIF fom a file # load CDIF-steam # 2. poxy # i is an intenal counte # epeat until thee ae no moe elements pint i, " ", un = x.nextelement() bobject = famo2.isentity(un) # is un of M1 in M2? if not(bobject): diffeence = diffeence + "Object: " + un + "\n" y = famo1.enumpopeties(un) j = 0 # fo all Popeties while y.hasmoeelements() and bobject: j = j + 1 nextkind = y.nextelement() kindvalue = famo1.getpopety(un, nextkind) if not(kindvalue == famo2.getpopety(un, nextkind)): diffeence = diffeence + "Popey in :" + un + " : " \ + nextkind + " : " + kindvalue +"\n" if len(diffeence): pint "the diffeence is:\n" + diffeence[:-1] else: pint "It is a subset!" # counte to show that something is going on. famo1 und famo2 sind Stellveteteobjekte de FAMOOS-Dastellungs-Seve FM1 und FM2. Mit de loadref-methode wid ein Modell geladen. In famo1 wid Modell M1 und in famo2 M2 geladen. Eine doppelte while-schleife übepüft, ob sowohl alle Elemente als auch alle Mekmale (Popeties) de Elemente von M1 auch in M2 vokommen. Alle Abweichungen weden duch die Vaiable diffeence festgehalten und am Ende des Vegleiches ausgegeben Agenten Im FAMOOS Foschungspojekt könnte ein Agent, wie in Abschnitt eingefüht, eingesetzt weden, um festzustellen, ob und wo sich im Netzwek CDIF-Dateien befinden. Die Aufgabe (Skipt) des Sending-Agent wüde wie folgt aussehen: # scipt fo the sending agent

98 88 KAPITEL 8. FALLSTUDIE: FAMOOS def walke(ag, di, path): global esult fo val in path: if sting.find(val, seach_file) >= 0: esult = esult + machine + "::" + di + val + "\n" machine = posix.uname()[1] stating_path = "/va/tmp/held/" seach_file = ".cdif" esult = "" os.path.walk(stating_path, walke, None) Das eben beschiebene Skipt des Sending-Agent wid auf den Rechnen ausgefüht, zu denen es gesendet wid. Die Methode walke duchsucht alle Untevezeichnisse von einem vogegebenen Vezeichnis (stating path) um Dateien mit dem Teilsting.cdif zu finden. Das esult enthält den Namen des Rechnes und den genauen Ot de gefundenen Datei Komponenten-Eweiteung mit dem Intelligent Poxy In diesem Beispiel wid vesucht die TableGeneato-Komponente um eine Methode zu eweiten. Fü diese Aufgabe wid de Ansatz des Intelligent Poxy (vgl. Abschnitt Intelligent Poxy im Kapitel 7.3.1) vewendet. De Code de Eweiteung sieht wie folgt aus: # This is an extension of the TableGeneato-component class Extension: def vesion(self): etun "FAMOOS Vesion 1.1" class intelligent_poxy(extension, poxy): def init (self, subject): pint " init intelligent_poxy" poxy. init (self, subject) Die Klasse intelligent poxy ebt von den Klassen Extension und poxy. In de Klasse Extension können alle Eweiteungen (Methoden, Attibute) definiet weden, die zu einem Objekt subject gemacht weden sollen. Die Klasse poxy leitet alle Methodenaufufe an das im Agument (subject) übegebene Objekt weite. Die Vewendung diese Komponenten- Eweiteung kann etwa wie folgt aussehen: >>> gp = coba_poxy.genealpoxy() >>> tg = gp.load("tables") >>> extended_tg = intelligent_poxy(tg) >>> pint extended_tg.vesion()

99 8.7. DISKUSSION Diskussion Das Foschungspojekt FAMOOS ist ein geeignetes Fallbeispiel, um das in diese Abeit estellte Komponenten Famewok zu validieen. In FAMOOS existieen einige von einande unabhängige Komponenten, die sich übe den Austausch von Dateien veständigen. Eine de FAMOOS- Komponenten (FAMOOS-Dastellung) wude soga zwei Mal estellt. Zudem wude wähend diese Fallstudie eine gundlegende Veändeung am FAMOOS Infomation Exchange Model vogenommen, so dass Komponenten zum Teil von Gund auf neu implementiet weden mussten. Das Inteface diese Komponenten bleibt hingegen unveändet. In diese Fallstudie wid ein exemplaisches Gluing de sniff2cdif- und de FAMOOS-Dastellungs-Komponente vogenommen, damit diese zwei Komponenten im Komponenten Famewok de voliegenden Abeit vewendet weden können. Das Gluing bedeutet fü die zwei Komponenten, dass sie nun zu echneunabhängigen Seven gewoden sind. Die Veständigung zwischen den Komponenten efolgt nicht meh duch den Austausch eine Datei, sonden diekt übe Methodenaufufe. Die Veändeung des FAMOOS Infomation Exchange Models zeigt sich als eine seh inteessante Situation. Duch diese Veändeung mussten die aus de Sicht des Komponenten Famewok legacy components neu implementiet weden. Da diese Fallstudie unabhängig von dem Foschungspojekt gemacht wude, entstanden bei de Neuimplementieung keine CORBA-Komponenten, sonden wiede neue Nicht-CORBA-Komponenten. Diese neuen Komponenten haben dasselbe Inteface wie vohe, das heisst die Wappe bleiben unveändet. Das hat den Voteil, dass das Komponenten Famewok als Debugging- und Test-Umgebung eingesetzt weden kann. Auf diese Weise konnten einige Fehle behoben weden. Das GUI zu de FAMOOS-Dastellung-Komponente und die TableGeneato-Komponente eweisen sich als paktische Eweiteungen. Mit de gafischen Benutzeobefläche ist es seh einfach Modelle anzuschauen, Modelle zu eweiten, zu veänden ode neu zu estellen. De Table- Geneato kann als Neuimplementieung de in Smalltalk geschiebenen und duch die Veändeung vealteten Metiken-Komponente angesehen weden. Diese in Python implementiete Table- Geneato ezeugt Tabellen fü die Analyse-Komponente.

100 Kapitel 9 Schlussbemekungen 9.1 Eeichte Ziele In diese Abeit wuden die Themengebiete Scipting und CORBA behandelt. Die in Abschnitt 1.2 gesteckten Ziele konnten weitgehend eeicht weden. Aus zeitlichen Günden wuden einige Themen etwas wenige intensiv als andee behandelt. Dies daf fü das jeweilige Thema jedoch nicht wetend betachtet weden. Aus eine eingehenden Studie ausgewählte Liteatu wuden die Gundlagen fü diese Abeit eabeitet (vgl. Kapitel 2 bis 4). Daaus esultiete im Kapitel 5 eine Poblemanalyse von CORBA. Basieend auf de in diese Abeit entwickelten Komponenten-Poxy-Methode konnte gezeigt weden, wie CORBA-Komponenten in einem Komponenten Famewok vewendet weden können. Die Methode de Komponenten-Poxy ist ein ORB-unabhängige Ansatz, de an keinen spezifischen ORB gebunden ist und vom Ansatz he kann auch in andeen Middlewae- Technologien eingesetzt weden. Mit Hilfe diese Methode können CORBA-Komponenten vewendet weden, ohne dass CORBA-Kenntnisse nötig sind (vgl. Abschnitt 7.1). Die Methode de Komponenten-Poxy basiet auf statischen CORBA-Methodenaufufen und bingt die folgenden Vebesseungen von CORBA: Û Flexibilität: Duch das Komponenten Famewok können Komponenten wie Bausteine zusammengesetzt (connect) weden und weden daduch flexible (vgl. Abschnitt 7.2). Û Softwaewiedevewendung: Komponenten können voallem aus zwei Günden leicht wiedevewendet weden. Eineseits födet das Komponenten Famewok die Entwicklung von kleinen, unabhängigen Komponenten und andeeseits können legacy components mit dem Glue in das Komponenten Famewok integiet weden (vgl. Absatz 7.2.3). Û Eweitebakeit: Ein bestehendes System kann mit Hilfe des intelligent poxy leichte eweitet ode veändet weden (vgl. Absatz 7.3.1). 90

101 9.2. OFFENE PROBLEME 91 Û Testen: CORBA-Komponenten haben duch den Einsatz eine Skipt-Spache gute Testmöglichkeiten. Inteaktives Debugging ist mit Hilfe de Skipt-Spache schon wähend de Entwicklung möglich (vgl. Absatz 7.2.2). Û Watbakeit: Das Komponenten Famewok kann zu Entwicklung von Softwae fühen, die besse gewatet weden kann (vgl. Absatz 7.2.1). Û Abstaktionsniveau: Duch den Einsatz des Komponenten Famewoks weden vo allem kleine flexible Komponenten entwickelt, die zum Zusammenbauen von Applikationen mit Skipts vewendet weden. Duch diese Komponenten Achitektu (Komponenten und Skipts) elangen CORBA-Applikationen ein höhees Abstaktionsniveau. In de Fallstudie FAMOOS (vgl. Kapitel 8) wude die Komponenten-Poxy-Methode validiet. Anhand diese Validieung konnte festgestellt weden, dass sich die entwickelte Methode fü den vogesehenen Vewendungszweck eignet. In unteschiedlichen Pogammiespachen implementiete Komponenten wuden mit Hilfe von Wapping-Techniken zu CORBA-Komponenten umgewandelt. Die adaptieten Komponenten wuden duch das Komponenten Famewok vewendet. Es hat sich duch die Vewendung gezeigt, dass das noch echt unefoschte Wapping (vgl. [Sne96]) de Komponenten eine ziemlich schwieige Aufgabe ist. Diese Aufgabe kann abe dank dem Glue des Komponenten Famewok eine weitee Altenative zu Vefügung gestellt weden. Im Anhang C hat es eine Übesicht zu de in diese Abeit estellten Softwae. Die Softwaeanfodeungen fü die Vewendung sowie de Ablageot de CORBA-Komponenten und de Komponenten-Poxy-Methode wid ebenfalls im Anhang C beschieben. 9.2 Offene Pobleme Aus zeitlichen Günden konnten die folgenden Fagen nu am Rande ode ga nicht behandelt weden. Sie können abe Ziele fü weitefühende Abeiten sein: Û Welche veschiedenen Gluing-Techniken (Wapping) gibt es? Û Wie sieht das Zeitvehalten de in diese Abeit estellten Methode im Vegleich zu andeen Ansätzen aus? Û Ist de Ovehead, de duch die Stellveteteobjekte entsteht, elevant? Û Wid es mit dem neuen CORBA 3.0 Standad möglich sein, die Methode de Komponenten- Poxy auch mit dynamischen CORBA-Methodenaufufen zu ealisieen? Û Wie können CORBA-Komponenten geeignet typisiet weden, um einen optimalen Einsatz de Komponenten in einem Komponenten Famewok zu gewähleisten? Û Kann eine Qualität de Applikationen gaantiet weden? Û Wie kann die Last in eine solch veteilten Applikation veteilt weden? Was fü Mechanismen können vewendet weden?

102 92 KAPITEL 9. SCHLUSSBEMERKUNGEN Û Duch den Eweiteungsansatz intelligent-poxy eöffnen sich divese Anwendungsgebiete. Wie wid zum Beispiel ein Analyse-Tool fü CORBA estellt? Û Eignet sich de in Abschnitt estellte Ansatz von Agent fü die Aufgaben eines Systemadministatos? Was gibt es dabei fü Sicheheitspobleme? Können selbständige Agenten im Intenet ezeugt weden?

103 Anhang A Abeitsumgebung Hadwae Als Abeitsumgebung wuden SUN-Wokstations 1 de Fachguppe SCG vewendet. Die Ausstattung de Rechne ist elativ einheitlich. De in diese Abeit am meisten vewendete Rechne (Lusa) ist eine SPARCstation-4 (SUN) mit 32 MB RAM. Betiebssystem Auf den SUN-Wokstations ist das Sun Solais (UNIX) installiet. UNIX ist ein Multitasking- und Multiuse-Betiebssystem. Softwae Fü die voliegende Abeit wuden folgende Hilfsmittel vewendet: Û Pogammiespachen: Die objektoientiete Skipt-Spache Python wude fü das Komponenten Famewok vewendet. Fü die Komponenten-Estellung wude die objektoientiete, obuste und intepetiete Pogammiespache Java eingesetzt. Û Middlewae: De VisiBoke fü Java von Visigenic und de Fnob 3 fü Python sind die vewendeten CORBA 2.0 ORBs. Û Edito: Als Edito wude de xemacs (Vesion 19.14) vewendet und die Abeit wude mit LATEX (tetex) geschieben. Û Gafiken: Eineseits wuden die meisten Abbildungen mit dem Unix-Tool xfig estellt. xfig ist ein 1 Mehzahl, da die Client/Seve-Applikationen meist auf veschiedenen Rechnen ausgefüht wuden. 2 Solais 2.5 ode höhe gilt als Voaussetzung fü den VisiBoke 3.0! 3 De Fnob ist ab de Vesion 0.7 ganz unabhängig. 93

104 94 ANHANG A. ARBEITSUMGEBUNG Menü-gesteuetes Gafik-Tool, um Zeichnungen unte dem X Window System zu estellen. Andeeseits wuden GUIs von Applikationen mit dem Hilfsmittel snapshot in eine Abbildung festgehalten.

105 Anhang B Technische Details von CORBA B.1 Ausnahmen (Exception) beim VisiBoke Die CORBA-Ausnahmen weden aus den Java-Ausnahmen (java.lang.exception) abgeleitet. Die Abbildung B.1 aus [VD97] zeigt die Zusammenhänge zwischen den Java- und den CORBA- Ausnahmen. Die CORBA-Exceptions bestehen aus den System-Exceptions und den benutzedefinieten Exceptions. Die System-Ausnahmen enthalten Deklaationen von 26 veschiedenen Standad-Ausnahmen (Pe-defined SystemExceptions) fü Ausnahmen von Netzwek, ORB und System-Fehlen. Alle Pe-defined System Exceptions können kollektiv als CORBA.SystemException abgefangen weden. Eine Methode ezeugt nu dann benutzedefiniete Ausnahmen, wenn diese auch in de Signatu definiet sind. java.lang.object java.lang.thowable java.lang.exception CORBA.Exception CORBA.UseException CORBA.SystemException IDL defined Exception Pe-defined System Exception Abbildung B.1: Ausnahmebehandlung im VisiBoke fü Java 95

106 96 ANHANG B. TECHNISCHE DETAILS VON CORBA B.2 Das low level-vehalten eines ORBs Die Kommunikation zwischen veteilten Client/Seve-Applikationen wid vom CORBA ORB übenommen, das heisst, die Entwickle bauchen nichts von Sockets, Pots ode Potokollen zu wissen, da diese Abeit vom ORB übenommen wid. Daaus egibt sich de Nachteil: De Entwickle weiss nicht genau, wie nun die Kommunikation abläuft. Dahe ist es von Inteesse, wie de ORB diese Kommunikation ealisiet. Als estes wude das Handbuch des VisiBokes (vgl. [Vis97]) konsultiet. Anschliessend wude anhand eines Expeimentes de low level-ablauf de Kommunikation euiet. Das VisiBoke Refeence Manual besagt: 1) De Client macht einen UDP-Boadcast um den osagent zu finden. 2) De osagent teilt dem Client mit, wo e den Seve finden kann. 3) Ein TCP-Vebindung wid zwischen Client und Seve aufgebaut. Das snoop-expeiment Um die Kommunikationsabläufe heauszufinden, wude zuest ein UNIX-Pozess snoop 1 gestatet. snoop ist ein Pozess, de die Aktivität auf dem Netzwek übewacht. Danach wuden osagent, Seve und Client nacheinande auf dei veschiedenen Rechnen gestatet. Wähend diese Zeit wuden die einzelnen Datenpackete mit Hilfe von snoop in ein Logfile geschieben. Die Auswetung de Logdatei egab die folgenden Resultate: 1) De Client macht wiklich einen UDP-boadcast. 2) De Seve statet danach eine TCP-Vebindung mit dem Client. Die Kontaktaufnahme zum osagent konnte nicht festgestellt weden, das liegt wahscheinlich an de Tatsache, dass das eine intene Optimieung vom VisiBoke ist. B.3 IOR/IIOP - Inteopeabilität Die Kommunikation zwischen zwei veschiedenen ORBs nennt man Inteopeabilität und veläuft übe IOR/IIOP. Die IOR ist die Objektefeenz und IIOP das Potokoll, welches die Inteopeabilität von CORBA emöglicht. IOR (Inteopeable Object Refeence) Die IOR ist de Standad fü die Objekt Refeenzen in CORBA. Dank de IOR ist eine Inte-ORB- Kommunikation möglich. Wid eine IOR in einen Sting umgewandelt, so sieht sie wie folgt aus: 1 Captues packets fom the netwok and displays thei contents (UNIX manual).

107 B.4. CORBA DER NEUE STANDARD 97 IOR: c3a54696d652f54696d a312e d e39322e36352e c a00504d c3a54696d652f54696d a312e c6f636b In diesem Beispiel ist de IOR-Sting 358 Zeichen (Byte) lang, das kann abe von Objekt zu Objekt vaiieen. In diese sogenannten stingified IOR sind unte andeem Adesse und Pot des Seve-Objektes enthalten. IIOP (Intenet Inte-ORB Potocol) Fü die Inteopeabilität spezifiziete die OMG GIOP (Geneal Inte-ORB Potocol). GIOP definiet die Übetagungstypen fü die ORB-zu-ORB-Kommunikation. Das GIOP ist nicht dasselbe wie ein RPC und baut auf einem ORB auf (vgl. [Sie96]). Das GIOP efüllt die folgenden Anfodeungen: Û Vebindungsoientietes Potokoll Û Zuvelässige Übetagung Û Meldung bei Vebindungsuntebuch Û Modell fü die Initialisieung eine Vebindung Das IIOP ist eine Definition de GIOP Spezifikation (vgl. Abbildung B.2 aus [Sie96]). Das Potokoll IIOP basiet auf TCP/IP-Vebindungen. IIOP definiet eine Menge von Regeln fü das Fomatieen von Daten genannt CDR. CDR (Common Data Repesentation) definiet alle IDL Datentypen, type code und zusammengesetzte Typen fü die Datenepäsentation. CDR wid zudem fü das Bidging benötigt. Neben den CDR Regeln weden im IIOP einige Übetagungsaten festgesetzt. GIOP TCP/IP (IIOP) SPX OSI... Abbildung B.2: Inteopeabilität mit IIOP B.4 CORBA de neue Standad Die meisten heute vewendeten ORBs untestützen den CORBA 2.0 Standad. Doch de Standad wid laufend weite entwickelt. Die Tabelle B.1 zeigt die zeitliche Abfolge de einzelnen Vesionen von CORBA.

108 98 ANHANG B. TECHNISCHE DETAILS VON CORBA Standad Zeit CORBA 1.0 Oktobe 1991 CORBA 1.1 Febua 1992 CORBA 1.2 Dezembe 1993 CORBA 2.0 August 1996 CORBA 2.1 August 1997 CORBA 2.2 Febua 1998 CORBA 2.3 Spätsomme 1998 CORBA 3.0 Mitte 1999 Tabelle B.1: Übeblick de CORBA Spezifikationen In einem Pe-elease wuden die zu ewatenden Eneueungen des CORBA 3.0 Standads veöffentlicht (vgl. [OMG98]). Nachfolgend sind die wichtigsten Neueungen dieses Standads aufgelistet: Û Multiple Inteface elaubt das Estellen von Mehfach-Intefaces von einem Objekt. Das hat den Voteil, dass so die Sichtbakeit sowie die Zugiffskontolle geegelt weden können. Ü Eine Methode wid die Untestützung von Objects-by-Value anbieten. Objects-by-Value soll schnelle und intuitive sein. Ü Die OMG definiet mit CORBA 3.0 ein Famewok fü wiedevewendbae Objekte in eine Komponenten Achitektu. In diese Spezifikation sind auch JavaBeans enthalten. Ü CORBA 3.0 wid eine Spezifikation eine Skipt-Spache enthalten. Diese Skipt-Spache soll zum Zusammensetzen (compose) von CORBA-Komponenten zu eine Applikation vewendet weden. Ü Spezifikationen wie Realtime-CORBA 1.0 und Asynchonous Messaging weden im Beeich de Sevice Qualität eingesetzt. Die Event- und Life Cycle Sevices weden in CORBA- Objekten eingeschlossen, das heisst, Clients können dynamisch auf Methoden, Fähigkeiten und Events de Objekte zugeifen. Ü CORBA 3.0 definiet ein Inteface fü Fiewalls, damit können IIOP kontolliet kommunizieen. B.5 Fnob fü Python De Fnob (vgl. [Chi98]) ist ein noch expeimentelle CORBA 2.0 ORB, de fast vollständig in Python implementiet 2 wude. De Fnob wude als ein Teilpojekt von Hecto 3 am Coopeative 2 Das hatte den gossen Voteil, dass eine Fehlekoektu (Bug fix) eigenhändig duchgefüht weden konnte. Die Klassen des ORBs mussten wede neu compiliet noch gelinkt weden, de ORB wa sofot wiede benutzba. 3 vgl.ý Þ Þ ß6à)á%áâ2â1âÂãä!åÞ&æ%ãç4äèWãé)è'á%êç4æ7Þ&ëìá

109 B.6. SKRIPT-SPRACHEN-ANBINDUNG AN CORBA 99 Reseach Cente fü Distibuted Systems Technology an de Univesität von Queensland in Bisbane (Austalien) entwickelt. Die IDL nach Python Anbindung ist leide noch nicht standadisiet (vgl. [CJvL98]) und befindet sich in Beabeitung (vgl. nächste Abschnitt). B.6 Skipt-Spachen-Anbindung an CORBA Die OMG hat das Fehlen eine Skipt-Spache im CORBA 2.0 Standad ealisiet und hat deshalb ein RFP (Request fo Poposal) veöffentlicht (vgl. [OMG97a]). Im Moment ist de Status: Revised submissions have been eceived. Übe die aktuelle Situation kann man sich unte de folgenden Adesse infomieen: ííîíðïòñ+óõôzïòñ+ö+ôø ù4ú)ûü$ýlö$ñ$ûú!þ+þ$ óÿú!úù ôwþ$ $þ ûülú Ìú ûöyýzù ô ô AôWú ïüùó Die Liste de Revised Submission enthält folgende Skipt-Spachen: Ü CobaScipt (vgl. ü ù/ù ý: - +ûñ+ö Aí6ú! ï" # %$& ï'$ ö' (>ñ+ö( ) ûöyýzù ) Ü Tcl Ü JavaScipt (von Netscape) Ü Python

110 Anhang C CORBA Komponenten-Bibliothek Dieses Kapitel gibt eine Übesicht de in diese Abeit estellten Komponentenbeispielen, die mit Hilfe de Komponenten-Poxy-Methode vewendet weden können. Die estellten Implementieungen befinden sich noch in einem expeimentellen Stadium, das heisst, es existiet wohl ein lauffähiges System (Pototyp), das abe absichtlich einfach gehalten wude. In diesem Kapitel weden keine technischen Anweisungen zu Vewendung de Komponenten gegeben, da es beim Soucecode jeweils noch eine README-Datei hat. Sämtliche Code de nachfolgenden Komponenten ist unte de nachfolgenden Adesse vefügba: lokal: $ü ñ+óÿú $þ û%ôø $üzú! * W,+Iñ+óKýLñ, 2ú- Pù4ú-. ú- /þý//ú! Ìú ode üùù ýw - íîííðï01:ó ï0 / 2 %ú'ïòûü (3üZú! * W,+Iñ+óKýLñ, 2ú- Pù4ú-. ú- /þý//ú! Ìú Um die voliegenden Komponentenbeispiele zu vewenden, müssen die nachfolgenden Systemanfodeungen de Softwae efüllt sein: Ü De Fnob und Python müssen installiet sein, um die in diese Abeit implementiete Komponenten-Poxy-Methode zu vewenden. Ü De VisiBoke fü Java und Java sollten auf dem System vohanden sein, um die CORBA-Komponenten zu benutzen. Es kann abe auch sonst ein ORB mit eigenen Komponenten vewendet weden. Achtung: Eigene Komponenten müssen sich auch beim NameSeve anmelden, so wie es im Abschnitt 7.1 beschieben ist. Nachfolgend weden die Elemente de Komponenten-Poxy-Methode beschieben. Danach weden die CORBA-Komponenten sowie die FAMOOS-Komponenten vogestellt, die mit de Komponenten-Poxy-Methode vewendet weden können. Im letzten Abschnitt gibt es zwei weitee CORBA-Beispiele. 100

111 C.1. KOMPONENTEN-PROXY-METHODE 101 C.1 Komponenten-Poxy-Methode Diese Abschnitt enthält kuze Bescheibungen zu de in Kapitel 7 aufgestellten Methode Komponenten-Poxy-Methode. C.1.1 coba poxy - Modul Das Modul coba poxy wude in Python geschieben und besteht aus de Klasse GenealPoxy. De Zweck dieses Moduls ist das automatische Estellen eines Stellvetete- Objektes (Komponenten-Poxy) von einem CORBA-Seve. Das Modul emöglicht Python den Zugiff auf CORBA-Komponenten mittels eines Stellvetete-Objekts. Die Kommunikation veläuft zwischen Stellvetete und CORBA-Komponente übe CORBA ORBs. Das Modul coba poxy wid wie folgt vewendet: Ü Modul coba poxy impotieen. Ü Klasse GenealPoxy instanzieen. Ü CORBA-Objekte können mit de Methode load geladen weden. C.1.2 NameSeve De globale NameSeve ist eine CORBA-Komponente, die fü die Komponenten-Poxy-Methode estellt wude. Die Aufgaben des globalen NameSeves lassen sich in zwei Beeiche unteteilen. Eineseits können sich CORBA-Seve beim NameSeve egistieen, damit potentielle Benutze sie finden. Andeeseits können CORBA-Seve mit Hilfe dieses Dienstes ORB-unabhängig duch einen Namen efeenziet weden. Das Modul coba poxy benötigt Infomationen übe die Seve, um einen Komponenten-Poxy zu estellen. Das IDL-Inteface sieht wie folgt aus: // NameSeve.idl module NameSeve{ exception UNKNOWN_SERVER{}; inteface NameSeveIF{ shot numbe_available_seves(); sting get_seve_name(in shot index) aises (UNKNOWN_SERVER); sting get_stub_name(in sting name); sting get_ior(in sting name); sting get_idl(in sting name); boolean is_avail(in sting name); void add_seve(in sting name, in sting IOR, in sting Stub_Name, in sting IDL); void emove_seve(in sting name) aises (UNKNOWN_SERVER); }; };

112 102 ANHANG C. CORBA KOMPONENTEN-BIBLIOTHEK C.1.3 Intelligent Poxy De Intelligent Poxy ist ein zusätzliche Ansatz mit dem Stellvetete-Objekte flexible gemacht weden können. Diese Ansatz emöglicht den Stellvetete-Objekten vo allem dei neue Möglichkeiten: Eine CORBA-Komponente kann estens um zusätzliche Fähigkeiten eweitet weden, wie zum Beispiel unteschiedliche Zugiffsechte ode lokale Infomationen (Geschwindigkeit). Zweitens können Intefaces aus Sicheheitsübelegungen eingeschänkt weden. Dittens bietet diese Ansatz die Voaussetzung fü ein Analyse-Tool (vgl. Absatz 7.3.1). C.1.4 Mobile Agent Mit Hilfe de Komponenten-Poxy-Methode kann ein Mobile Agent estellt weden. Ein Mobile Agent kann in einem Rechnenetz unabhängige Aufgaben ausfühen. In diese Abeit wuden ein Tavelling Agent und ein Sending Agent implementiet (vgl. Absatz 7.3.2). C.2 CORBA-Komponenten Die Komponenten in diesem Abschnitt können nu gestatet weden, wenn auch de NameSeve läuft, da sie sich automatisch bei ihm anmelden. Diese Annahme wude zu Veeinfachung getoffen. Die nachfolgenden CORBA-Komponenten sind in Java implementiet woden. Beim Staten diese CORBA-Seve kann duch einen optionalen Paamete explizit de Name diese Komponente angegeben weden (zum Beispiel mit: java Hello myhello). C.2.1 Hallo, Welt! Die Hallo, Welt!-Komponente ist ein CORBA-Seve, de nu eine Methode hat. Diese Methode liefet als Rückgabewet Hello, Wold!. De Seve hat folgendes Inteface: // HelloWold.idl; Hello Wold Inteface module HelloWold{ inteface Discussion{ sting say_hello(); }; }; C.2.2 Counte-Komponente De Counte (Zähle) ist ein CORBA-Seve, de aus einem Attibut sum und eine Methode incement besteht. Das Inteface sieht wie folgt aus: // Count.idl module Counte { inteface Count { attibute long sum; long incement();

113 C.3. FAMOOS 103 }; }; C.2.3 Picing De Picing-Seve wude im Abschnitt 4.4 ausfühlich bespochen. C.2.4 Das ZeitSeve-Beispiel Das ZeitSeve-Beispiel besteht aus zwei CORBA-Komponenten. Die este Komponente Time ezeugt die aktuelle Zeit, die übe die Methode get hou und get minute abgefagt weden kann. Hie ist noch zu ewähnen, dass diese aktuelle Zeit leide nicht mit de lokalen Zeit übeeinstimmt (falsche Zeitzone; Java-Fehle in JDK 1.1.6). De Time-Seve hat das folgende Inteface: // Clock.idl module Time{ inteface TimeIF{ shot get_hou(); shot get_minute(); }; }; Die zweite Komponente Display ist ein Output-Seve. Mit de Methode display time kann die Zeit in Fom eines Stings ausgegeben weden. Die Display-Komponente hat folgende Stuktu: // Display.idl module Display{ inteface DisplayIF{ void display_time(in sting time); }; }; C.3 FAMOOS Diese Abschnitt enthält die Komponenten, die in de Fallstudie (vgl. Kapitel 8) estellt und vewendet wuden. C.3.1 sniff2cdif-komponente sniff2cdif ist eine in C geschiebene Komponente, die aus einem von SNiFF++ gespeicheten Softwae-Pojekt eine CDIF-Repäsentation estellt. Die sniff2cdif-komponente wude in einen CORBA-Seve umgewandelt. Diese Umwandlung wude duch eine Adaption ealisiet. Das Inteface de adaptieten sniff2cdif-komponente sieht wie folgt aus: // sniff_api.idl module sniff_api{ inteface sniff_apiif{

114 104 ANHANG C. CORBA KOMPONENTEN-BIBLIOTHEK void sniffapiisavailable(); void setlevel(in shot level); shot getlevel(); void showvaiableaccess(); void hidevaiableaccess(); void showmethodinvocation(); void hidemethodinvocation(); void showsouceancho(); void hidesouceancho(); void showfullinheitancedefinition(); void hidefullinheitancedefinition(); sting eadsniffsymboltable(in sting poj, in sting output_file); }; }; C.3.2 FAMOOS-Dastellung Die FAMOOS-Dastellungs-Komponente wude in eine Diplomabeit (vgl. [Fa99]) estellt. In de voliegenden Abeit wude ein Wappe um diese Komponente gelegt und zu einem CORBA- Seve umgewandelt. Das Wapping efolgte in dei Schitten: Ü Definition des Inteface (vgl. FamoosModel.idl) Ü Inteface mit de bestehenden Komponente vebinden Ü CORBA-Seve beeitstellen // FamoosModel.idl module FM { exception Invalid_Connection{}; inteface enumsting { boolean hasmoeelements(); sting nextelement(); //etuns uniquename/popetyname }; inteface FamoosModelIF { void loadref(in sting hef); void loadval(in sting pat); void saveref(in sting hef); sting saveval(); void ceateentity(in sting uniquename, in sting kind); void emoveentity(in sting uniquename); enumsting enumentities(); // List of uniquenames sting getkind(in sting uniquename); sting getid(in sting uniquename); //CDIFid void setpopety(in sting uniquename, in sting popety, in sting value); // getpopety: value of Popety sting getpopety(in sting uniquename, in sting popety); // enumsting: List of all Popetynames of an uniquenameentiety enumsting enumpopeties(in sting uniquename); void connection_teste() aises (Invalid_Connection);

115 C.3. FAMOOS 105 void clea(); }; }; C.3.3 TableGeneato De TableGeneato ist ein CORBA-Seve, de in Python implementiet wude. Diese Seve muss imme mit eine FAMOOS-Dastellungs-Komponente vebunden weden (connect2famoos- Model). De TableGeneato emöglicht es, aus einem Softwae-Modell Tabellen fü metische Analysen zu estellen. Nachfolgend ist das Inteface des TableGeneato zu sehen: // Metic.idl; Tabelgeneato fo the Metics module Metic{ inteface MeticIF{ void connect2famoosmodel(in sting fmname); sting Association_Table(); sting Attibute_Table(); sting Class_Table(); sting Entity_Table(); sting Inheitance_Table(); sting Method_Table(); sting MethodInvocation_Table(); }; }; C.3.4 Skipts ModelBuilde De ModelBuilde ist eine in Python geschiebene gafische Benutzeobefläche und wude zu Visualisieung de Famoos-Dastellungs-Komponente estellt. Mit dem ModelBuilde kann ein im FAMOOS infomation Exchange Model gespeichetes Softwae-Modell angezeigt, eweitet und gelöscht weden. Es können abe auch Modelle von Gund auf neu estellt weden. Subset-Teste De Subset-Teste ist ein Python-Skipt, das mit Hilfe von zwei FAMOOS-Dastellungs-Komponenten abeitet. Das Skipt testet, ob ein Softwae-Modell eine Teilmenge eines andeen Softwae- Modelles ist. Metische Tabelle Das Skipt de metischen Tabelle ist eine einfache Applikationslogik, die dei Stellvetete- Objekte miteinande vebindet. Das Skipt estellt aus eine Softwae-Pojekt-Datei eine metische Tabelle, die dann fü weitee Analysen vewendet weden kann.

116 106 ANHANG C. CORBA KOMPONENTEN-BIBLIOTHEK Finde CDIF-Dateien Die Aufgabe eines in diese Abeit eingefühten Mobile Agent ist ein Skipt. Ein Skipt (Aufgabe) kommt jeweils auf einem Rechne zu Ausfühung und übegibt anschliessend dem Agenten die Resultate. Das Skipt Finde CDIF-Dateien wid eingesetzt, um heauszufinden, ob und wo sich im Netzwek CDIF-Dateien befinden. C.4 Weitee CORBA-Beispiele C.4.1 Komplexe Zahlen Das Beispiel de komplexen Zahlen ist eine CORBA-Applikation, die in eine fühen Phase diese Abeit estellt wude. Es handelt sich dabei um ein Beispiel eine CORBA-Applikation mit eine auf veschiedene Komponenten veteilten Applikationslogik. Komponenten sind genau aufeinande abgestimmt. Komplexe Zahlen besteht aus dei Bestandteilen: Ü Ein CORBA-Client KeyBoad elaubt die Eingabe von komplexen Zahlen übe ein Applet (vgl. Abbildung C.1). Ü Ein CORBA-Seve Math übenimmt die Beechnung de komplexen Opeationen. Die Komponente Math ist abe zugleich auch wiede Client vom ShowSeve. Ü De CORBA-Seve ShowSeve ist fü die gafische Dastellung des Resultats veantwotlich (vgl. Abbildung C.2). Abbildung C.1: Eingabe Applet vom Komplex Rechne Anhand diese Applikation kann gezeigt weden, dass die Komponenten eine CORBA-Applikation nicht unbedingt einfach und wiedevewendba sein müssen. Das in diese Abeit estellte Komponenten Famewok hilft dem Entwickle einfachee Applikationen zu estellen.

117 C.4. WEITERE CORBA-BEISPIELE 107 Abbildung C.2: Gafische Dastellung de Resultate des Komplex Rechnes C.4.2 DII DII ist eine CORBA-Applikation, die dynamische Methodenaufufe macht. In diese Applikation weden wede Stub noch Skeleton vewendet. De Client ezeugt einen Request, de dann dynamisch ausgewetet wid. Diese Beispiel-Applikation kann fü weitefühende Abeiten seh wichtig sein.