Verteilte Annotation von Dokumenten Architekturentwurf und Implementierung eines Frameworks auf J2EE-Basis

Transkript

1 Universität des Saarlandes Naturwissenschaftlich-Technische Fakultät I Fachrichtung Informatik Bachelor-Arbeit Verteilte Annotation von Dokumenten Architekturentwurf und Implementierung eines Frameworks auf J2EE-Basis angefertigt von Frank Stefan Fuchs unter der Leitung von Prof. Dr. Gerhard Weikum am Max Plank Institut für Informatik D5: Databases and Information Systems Saarbrücken, den

2 Eidesstattliche Erklärung Hiermit versichere ich an Eides statt, dass ich diese Arbeit selbstständig angefertigt habe und keine anderen als die angegebenen Hilfsmittel verwendet habe. Alle wörtlichen oder sinngemäßen Entlehnungen sind deutlich als solche gekennzeichnet. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungskommission vorgelegt und auch nicht veröffentlicht. Saarbrücken, den Frank Stefan Fuchs

3 Inhaltsverzeichnis I Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung und Aufbau der Arbeit Architektur Umfeld und Anforderungen Plattformen NET J2EE Beurteilung Bestandteile Verwendete Technologien J2EE Verteilte mehrschichtige Anwendungen J2EE-Komponenten Enterprise Java Beans Session Beans Entity Beans Message-Driven Beans Web Services Begriffsbestimmung und Funktionsweise Web Services und J2EE Applikationsserver... 17

4 Inhaltsverzeichnis II 4 Zentrale Koordinationskomponente Aufbau und Architektur AClientControllerBean Web Service Endpoint Interface Service-Implementierung Message-Queue und AMessageControllerBean Message-Queue AMessageControllerBean AServerControllerBean Web Service Endpoint Interface Service-Implementierung AServerDataBean Remote Interface Home Interface Bean-Implementierung ADocumentDataBean Remote Interface Home Interface Bean-Implementierung Datenbank-Schnittstelle Beispiel-Implementierung eines Clients 36 6 Kommunikation 40 7 Evaluation Versuchsaufbau Lastentest Zusammenfassung und Ausblick 46

5 Inhaltsverzeichnis III A Installation 48 A.1 Framework A.2 Client A.3 Annotationsserver B Abbildungsverzeichnis 52 C Tabellenverzeichnis 53 D Quelltextverzeichnis 54 E Literaturverzeichnis 55

6 1 Einleitung 1 1 Einleitung 1.1 Motivation In den letzten Jahren hat sich das World Wide Web zu einer Ansammlung von Dokumenten für Personen entwickelt. Es ist weniger ein Medium, welches maschinenlesbare Daten enthält und auf Grund derer die Semantik der Inhalte formal festgelegt wird. Es bedarf aber einer Vernetzung von Informationen, damit Abfragen wie Welcher Fußballer hat die meisten Tore bei der WM 2006 geschossen beantwortet werden können. Diese erweiterte Funktionalität des World Wide Webs wird als Semantisches Netz 1 bezeichnet. Die logische Zusammenfassung solcher Informationen wird Ontologie genannt. Da jedoch die Informationen nicht im Vorhinein als Ontologien verfügbar sind, bedarf es Techniken, die dies verwirklichen. Eine Haupttechnik hierbei ist das Annotieren von Dokumenten durch NLP-Software (Natural Language Processing) wie ANNIE 2 oder Minorthird 3. Durch die hohe Anzahl von Dokumenten (die deutsche Wikipedia-Seite allein mit über Artikeln) und der damit verbundenen Rechenlast bedarf es einer Lastenverteilung. Da die oben genannten Werkzeuge als typische Einzelplatzlösungen konzipiert und nicht für das Verwenden im Netz vorgesehen sind, wird ein Framework benötigt, das diese Unzulänglichkeiten beseitigt. 1.2 Zielsetzung und Aufbau der Arbeit Ziel dieser Arbeit ist es, ein webbasiertes Framework für die verteile Annotation von Dokumenten zu entwerfen und zu implementieren. Das Framework soll insbesondere die Integration von Annotationstools wie ANNIE und Minorthird als Backendsysteme leisten. Dabei stellt sich die Frage nach dem Senden, Empfangen und Verteilen einer großen Anzahl von Dokumenten von den Clients an die Backendsysteme. 1 Berners-Lee, T.; Hendler, J.; Lassila, O.: The Semantic Web, Scientific American, Mai Cunningham, H. et al.: Developing Language Processing Components with GATE (a User s Guide), University of Sheffield, Cohen, W.: Minorthird: Methods for Identifying Names and Ontological Relations in Text using Heuristics for Inducing Regularities from Data,

7 1 Einleitung 2 Im ersten Teil wird auf das Umfeld eingegangen, in dem das Framework zu dienen hat. Auf Grund dieses Umfeldes werden Umsetzungsalternativen bewertet und die grobe Architektur abgeleitet. Kapitel 3 gibt einen Überblick über die verwendeten Technologien, dabei wird auf die J2EE 4 (Java 2 Enterprise Edition) und deren Bestandteile eingegangen. Einen großen Raum in diesem Kapitel nimmt dabei der Abschnitt Web Services ein, da Web Services den Großteil der Kommunikation mit dem Framework bereitstellen werden. Der Hauptbestandteil dieser Arbeit wird im darauf folgenden Kapitel 4 vorgestellt. Hier wird die Zentrale Koordinationskomponente beschrieben. Dabei werden die einzelnen Komponenten näher erläutert, ihre Funktion in der Gesamtarchitektur und ihre Bedeutung für das Empfangen, Senden und Verteilen von Dokumenten dargestellt. In Kapitel 5 wird auf die Beispiel-Implementierung eines Clients eingegangen, welcher über Web Services mit dem Framework interagiert. Auf den Kommunikationsablauf zwischen Zentraler Koordinationskomponente, den Clients und den Annotationsservern 5 wird in Kapitel 6 eingegangen. In Kapitel 7 wird die Implementierung des Frameworks einem Lastentest unterzogen, um ihre Leistung beurteilen zu können. Eine Zusammenfassung und Ausblick auf zukünftige Entwicklungen sind im abschließenden Kapitel 8 zu finden. 4 Sun Microsystems: J2EE v1.4 Documentation, Fuchs, D.: Verteilte Annotation von Dokumenten Entwurf und Implementierung eines modularen Annotationsservers auf Basis von NLP-Technologien, Universität des Saarlandes, 2006

8 2 Architektur 3 2 Architektur 2.1 Umfeld und Anforderungen Um die Integration von heterogenen Annotationswerkzeugen als Backendsysteme und die Fähigkeit, eine große Anzahl von Dokumenten verteilt im Internet zu annotieren, zu gewährleisten, muss das Framework einige Kriterien an die zu verwendende Plattform stellen. Hierbei können folgende Kriterien von Anforderungen abgeleitet werden: Integration bestehender Systeme Selten wird eine neue Anwendung ohne Bezug auf bestehende Anwendungen entwickelt. Meist ist diese mit einer bereits bestehenden heterogenen IT-Landschaft zu verbinden. Dazu muss die Plattform Möglichkeiten der Integration bieten. Skalierbarkeit Gerade bei Anwendungen im weltweiten Netz ist es nicht möglich, die Last vorher zu sagen, die die Anwendung auszuhalten hat. Daher ist es wichtig, dass die Lastenverteilung unabhängig von der Implementierung der Anwendung konfiguriert werden kann. Flexibilität Bei einer Anwendung sollte die Möglichkeit bestehen, die Laufzeit- und Entwicklungsumgebung nach den Anforderungen der Anwendung zusammen zu stellen. Für die Implementierung des Frameworks kommen grundsätzlich zwei Plattformen in Betracht:.NET 6 von Microsoft und J2EE 7 von Sun Microsystems. 6 Microsoft Corporation:.NET Framework 1.0, default.aspx, Sun Microsystems: J2EE v1.4 Documentation,

9 2 Architektur Plattformen NET.NET ist eine Implementierung des Common Language Infrastructure Standards 8 für Windows durch die Firma Microsoft. Sie besteht aus einem Framework von Klassenbibliotheken und aus angeschlossenen Diensten, die gemeinsam eine Basis für Eigenentwicklungen bieten. Die Programme liegen ähnlich wie in Java in einem Zwischencode vor und benötigen daher die.net-laufzeitumgebung. Was.NET von anderen auf Zwischencode basierenden Laufzeitumgebungen signifikant unterscheidet, ist das berücksichtigte Nebeneinander mehrerer Programmiersprachen J2EE Im Gegensatz zu.net ist Java 2 Enterprise Edition von Sun Microsystems kein Produkt, sondern eine Spezifikation für verteilte Geschäftsanwendungen. Deren Implementierung ist den Herstellern vorbehalten. Sie stellt einen komponenten-basierten Ansatz für den Entwurf, Entwicklung, Aufbau und Deployment von Geschäftsapplikationen zur Verfügung. Die J2EE-Plattform bietet ein mehrschichtiges verteiltes Applikationsmodell, wieder verwendbare Komponenten, ein vereinheitlichtes Sicherheitsmodell, flexible Transaktionskontrolle und Web Services-Unterstützung durch den Austausch von integrierten Daten über XML-basierte offene Standards und Protokolle Beurteilung J2EE und.net sind zwei ähnliche Ansätze für die Entwicklung von Anwendungs-Frameworks. 8 Microsoft Corporation: Common Language Infrastructure Standard, ecma/, Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 1.

10 2 Architektur 5 Sowohl das J2EE- als auch das.net-architekturmodell basieren auf dem objekt-orientierten (OO) Vorgehen und besitzen mächtige OO-Frameworks (Klassenbibliotheken) für unterschiedliche Services wie Objekt-Persistenz, Komponenten-Management, Transaktionen, Web Services, asynchrone Kommunikation und Messaging. 10 J2EE und.net verwenden beide die Virtual Machine (VM)-Architektur. Die Anwendungsentwicklungs-Werkzeuge erzeugen Zwischencode anstatt plattform-spezifischen Binärcode. Dies bedeutet, dass die VM den Code in Echtzeit interpretiert oder die so genannte Just-In- Time (JIT)-Übersetzung vornimmt. Beide Plattformen basieren auf mehrschichtige Architekturen. 11 Für die Erstellung verteilter Anwendungen stehen die so genannten EJB-Container in J2EE bzw. die.net Managed Objects in.net zur Verfügung. In beiden Fällen wird die Verwaltung und Kontrolle der verteilten Objekte automatisch übernommen, ohne dass dies explizit implementiert werden muss. Die Attraktivität von J2EE wird insbesondere durch die Portabilität über unterschiedlichste Plattformen gestützt. J2EE ist ein offener Standard und eine Spezifikation, die unabhängig von der jeweils verwendeten Plattform ist. Im Falle von.net dagegen, handelt es sich um ein konkretes Produkt und damit um einen einzigen Hersteller Bestandteile Auf Grund der aufgeführten Vorteile der J2EE-Plattform (s. Kapitel 2.2), basiert das in dieser Arbeit entwickelte Framework auf das J2EE-Architekturmodell. Dieser Abschnitt gibt einen groben Überblick über den Aufbau und Architektur des Frameworks; eine ausführliche Beschreibung ihrer Funktionsweise und Komponenten erfolgt in den Kapiteln 4 und 5. Ein fester Bestandteil der J2EE-Architektur ist der J2EE-Applikationsserver. Er ist für die Steuerung der gesamten Anwendung verantwortlich (siehe Abbildung 1). Die Framework- Clients sind mit Hilfe von Web Services an das Framework angebunden. Als Backendsysteme dienen die Annotationsserver, die als Enterprise Information Systeme (EIS) im Framework 10 Younis, S.: J2EE vs..net An Executive Look, 2003, S Younis, S.: J2EE vs..net An Executive Look, 2003, S Thielscher, J.: J2EE und.net zwei konkurrierende Standards?, Computer Zeitung, Mai 2002, S. 4.

11 2 Architektur 6 integriert sind. Die Datenhaltung erfolgt über eine Datenbank, die über eine Datenbank- Schnittstelle vom J2EE-Applikationsserver angesprochen wird. Abbildung 1 : Überblick Framework

12 3 Verwendete Technologien 7 3 Verwendete Technologien 3.1 J2EE Verteilte mehrschichtige Anwendungen Die J2EE-Plattform verwendet ein verteiltes mehrschichtiges (multi-tier) Applikationsmodell für Anwendungen. Die Anwendungslogik ist in Komponenten anhand ihrer Funktion aufgeteilt. Die unterschiedlichen Anwendungskomponenten, aus denen die J2EE-Applikation besteht, können auf verschiedenen Rechnern installiert sein. Die Aufteilung erfolgt in Abhängigkeit von der Schicht in der mehrschichtigen J2EE-Umgebung, der die Anwendungskomponente zugeordnet ist. Abbildung 2 zeigt zwei mehrschichtige J2EE- Applikationen, die aus den im Folgenden beschriebenen Schichten bestehen: 13 Client-Schicht-Komponenten werden auf Client-Rechnern ausgeführt. Web-Schicht-Komponenten werden auf dem J2EE-Server ausgeführt. Business-Schicht-Komponenten werden ebenfalls auf dem J2EE-Server ausgeführt. Enterprise Information System (EIS)-Schicht-Software wird auf dem EIS-Server ausgeführt. 13 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 2.

13 3 Verwendete Technologien 8 Abbildung 2 : Mehrschichtige Anwendungen 14 Obwohl J2EE-Applikationen aus den drei oder vier Schichten bestehen können, sind sie in der Regel dreischichtig. Der Grund dafür ist, dass die Applikationen meistens über drei Stellen verteilt sind: Client-Rechner, J2EE-Server und Datenbank-Rechner J2EE-Komponenten J2EE-Applikationen bestehen aus Komponenten. Eine J2EE-Komponente ist eine in sich funktionierende Software-Einheit, einschließlich ihrer Klassen und Dateien, die in einer J2EE-Applikation eingebunden ist und die mit anderen Komponenten kommuniziert. Die J2EE-Spezifikation 16 definiert hierbei folgende J2EE-Komponenten: Applikations-Clients und Applets sind Komponenten, die auf einem Client-Rechner ausgeführt werden. Java Servlet- und Java Server Pages (JSP)-Komponenten sind Web-Komponenten, die auf dem Applikationsserver ausgeführt werden. 14 In Anlehnung an: Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S Sun Microsystems: J2EE Platform Specification 1.4,

14 3 Verwendete Technologien 9 Enterprise Java Beans-Komponenten sind Business-Komponenten, die ebenfalls auf dem Applikationsserver ausgeführt werden. J2EE-Komponenten sind in der Programmiersprache Java geschrieben und werden auf die gleiche Art und Weise kompiliert wie jedes andere Programm in dieser Sprache. Der Unterschied zwischen J2EE-Komponenten und Standard -Java-Klassen ist, dass J2EE-Komponenten in einer J2EE-Applikation eingebunden, wohlgeformt und im Einklang mit der J2EE- Spezifikation sind und von einem J2EE-Server ausgeführt werden. Da das Framework keine Web-Komponenten besitzt und mit Hilfe von Web Services kommuniziert, werden im Folgenden die Enterprise Java Beans und Web Services näher erläutert. 3.2 Enterprise Java Beans Enterprise Java Beans sind nach der EJB-Spezifikation entworfene, serverseitige Software- Komponenten, die in der vom EJB-Container zur Verfügung gestellten Umgebung ablaufen. Sie realisieren die Geschäftslogik, auf die Anwendungen (als Clients bezeichnet) zugreifen. 17 Der EJB-Container stellt die Laufzeitumgebung für die Enterprise Java Beans im J2EE-Server zur Verfügung und erfüllt hierbei verschiedene Dienste: Verwaltet den Lebenszyklus der Enterprise Java Beans. Stellt die Persistenz für Entity Beans (siehe Abschnitt 3.2.2) bereit. Regelt den Sicherheitsmechanismus und damit den Zugriff auf die Enterprise Java Beans. Stellt Dienste bereit, um mit dem Java Naming and Directory Interface (JNDI) 18 entfernte Objekte über ihren Namen zu finden. Koordiniert verteilte Transaktionen. Übernimmt die Remote-Kommunikation mit dem Client. Damit der EJB-Container diese Dienste erfüllen kann, benötigt er die Kontrolle über die Objekte der Enterprise Java Beans. Dies wird realisiert, indem der Client mit den Beans über 17 Backschat, M.: Enterprise Java Beans, Spektrum Akademischer Verlag, Sun Microsystems: Java Naming and Directory Interface (JNDI),

15 3 Verwendete Technologien 10 vom J2EE-Server generierte Stubs kommuniziert, die ihrerseits mit den entsprechenden Methoden der Beans kommunizieren. Dazu besitzt jedes Enterprise Java Bean zwei zu implementierende Schnittstellen, eine Ausnahme hiervon bilden die Message-Driven Beans (siehe Abschnitt 3.2.3) und Stateless Session Beans für Web Services (siehe Abschnitt 3.3): Das Home Interface stellt Methoden zum Erstellen und Finden der Bean-Objekte zur Verfügung. Das Remote Interface stellt Methoden der Anwendungslogik für den Client bereit. Die EJB-Spezifikation 19 unterscheidet drei Arten von Enterprise Java Beans: Session Beans, Entity Beans und Message-Driven Beans Session Beans Session Beans werden dazu verwendet, um die Funktionalität einer Anwendungslogik dem Client zur Verfügung zu stellen. Ein Session Bean realisiert somit den Ablauf (Workflow) einer Anwendung. Dabei greift das Bean zumeist auf andere Beans, insbesondere Entity Beans, zu. Session Beans werden in Stateless Session Beans (zustandslose) und Stateful Session Beans (zustandsbehaftete) unterteilt. Stateless Session Beans werden bei jedem Aufruf eines Clients neu erzeugt, das heißt sie können sich den Zustand einer vorherigen Anfrage nicht merken. Sie eignen sich für einfache Funktionsaufrufe, wie zum Beispiel Zahlungsvorgänge. Der Kunde sendet seine Bankdaten und den Betrag an das Session Bean und erhält eine Bestätigung über den Erfolg des Vorgangs. Somit ist der Lebenszyklus eines Stateless Session Beans sehr einfach, welches die Abbildung 3 verdeutlicht Sun Microsystems: Enterprise JavaBeans Specification 2.1, Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 858.

16 3 Verwendete Technologien 11 Abbildung 3 : Lebenszyklus eines Stateless Session Beans 21 Eine klassische Anwendung für das Stateful Session Bean ist der Gebrauch eines Warenkorbes. Der Nutzer wählt eine Ware aus und legt diese in den Warenkorb. Hierbei muss sich das Session Bean natürlich den Zustand des Warenkorbes merken. Somit ist der Lebenszyklus eines Stateful Session Beans komplizierter, da der EJB-Container beim nächsten Zugriff des Clients das richtige Bean übergeben muss. 22 Abbildung 4 : Lebenszyklus eines Stateful Session Beans 23 Eine weitere wichtige Eigenschaft, die im Rahmen dieser Arbeit von Bedeutung ist, ist die Fähigkeit eines Stateless Session Beans als Web Service zu dienen. Dies wird im Abschnitt 3.3 näher erläutert. 21 In Anlehnung an: Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S In Anlehnung an: Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 874.

17 3 Verwendete Technologien Entity Beans Entity Beans stellen die persistenten Daten einer Applikation dar. Dies bedeutet, dass sie auch nach einem Neustart des EJB-Containers vorhanden sein müssen. Die Persistenz kann theoretisch auf verschiedene Arten erreicht werden, wobei im praktischen Einsatz fast ausschließlich Datenbanken verwendet werden. Somit ist ein Entity Bean die Repräsentation einer Datenbanktabelle. Hier werden zwei Arten von Persistenz-Steuerung unterschieden. Entweder wird die Persistenz durch das Bean selbst verwirklicht, Bean Managed Persistence (BMP) genannt, oder sie wird durch den EJB-Container gesteuert, als Container Managed Persistence (CMP) bezeichnet. 24 Entity Beans erlauben den gleichzeitigen Zugriff von mehreren Clients. Um den reibungslosen Ablauf dieser Zugriffe zu gewährleisten, ist es wichtig, dass die Entity Beans mit einem Transaktionsmechanismus ausgestattet sind. Dieser Mechanismus wird wiederum von dem EJB-Container bereitgestellt. Damit die Entity Beans von den Clients auffindbar sind, besitzt jedes Bean eine eindeutige Identifizierung. Der Lebenszyklus eines Entity Beans ist in Abbildung 5 dargestellt. Abbildung 5 : Lebenszyklus eines Entity Beans Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 859ff. 25 In Anlehnung an: Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 876.

18 3 Verwendete Technologien Message-Driven Beans Ein Message-Driven Bean ist ein Enterprise Java Bean, welches J2EE-Applikationen die asynchrone Verarbeitung von Nachrichten erlaubt. So kann jede J2EE-Komponente, sei es ein Applikationsclient, ein anderes Enterprise Java Bean oder eine Web-Komponente, Nachrichten mit der JMS-API 26 auf eine Warteschlange legen. Das Message-Driven Bean agiert dabei als eine Art Message Listener, ähnlich einem Event Listener, und hört die Warteschlange auf Nachrichten ab. Das Bean reagiert dann entsprechend, falls eine Nachricht auf der Warteschlange vorhanden ist. 27 Dabei bilden die Message-Driven Beans eine Ausnahme unter den Enterprise Java Beans, denn sie werden nicht durch einen Client erzeugt und besitzen somit auch kein Home und Remote Interface. Da Message-Driven Beans keinen Status besitzen, haben sie einen ähnlichen Lebenszyklus wie die Stateless Session Beans (siehe Abbildung 3). 3.3 Web Services Begriffsbestimmung und Funktionsweise Unter Web Services werden selbstbeschreibende, modulare Software-Komponenten verstanden, die dynamisch über Standard-Internettechnologien andere Komponenten im Web ausfindig machen und benutzen können, um so eine komplette, umfangreiche Aufgabe zu erfüllen. 28 Im Gegensatz zu Anwendungen, die fest auf einem Rechner oder anderen Client- Geräten installiert werden, repräsentieren Web Services allgemein einen Geschäftsvorgang oder eine Systemfunktionalität, auf die über das Web zugegriffen werden kann. Konsumenten von Web Services können Personen sein, die auf den Service über einen Browser auf dem Rechner oder einem mobilen Endgerät zugreifen können, es können aber auch Anwendungsprogramme oder andere Web Services sein. 26 Sun Microsystems: Java Message Service, Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S Schmelzer, R. et al.: XML and Web Services Unleashed, Sams Publishing, 2002, S. 592; Sun Microsystems: Sun Open Net Environment (Sun ONE), 2002, S. 4.

19 3 Verwendete Technologien 14 Web Services sind somit durch die folgenden Charaktereigenschaften gekennzeichnet: 29 Sie sind über das Web verfügbar. Sie verfügen über eine Schnittstelle, die von anderen Programmen aufrufbar ist. Sie sind registriert und daher lokalisierbar. Sie kommunizieren mit Hilfe von Nachrichten über standardisierte Internetprotokolle. Sie unterstützen lose gekoppelte (loosely coupled) Verbindungen zwischen Systemen, das heißt Kommunikationsprozesse zwischen Programmen. Für die Realisierung von Web Services hat sich allgemein die Verwendung der extensible Markup Language (XML) durchgesetzt, mit der die Schnittstellen der Web Services beschrieben und Nachrichten kodiert werden. Wichtig ist dabei vor allem, dass es bei XML-basierten Web Services keine Rolle spielt mit welcher Technologie sie erstellt wurden. Sie kommunizieren über Standard-Internetprotokolle (zum Beispiel TCP/IP, HTTP, HTTPS, SMTP) mit Hilfe ihrer XML-Schnittstellen und XML-Nachrichten, die alle Anwendungen verstehen können. 30 Im Gegensatz zum monolitischen Implementierungsstil früherer Web-Applikationen basieren Web Services auf einer Reihe zusammenhängender Technologien: hierzu gehört insbesondere das XML-basierte Simple Object Access Protocol (SOAP) 31, welches für die Kommunikation zwischen Dienstnutzer und Dienstanbieter zum Einsatz kommt. Mittels der Web Service Description Language (WSDL) 32 lassen sich Web Services in einer einheitlichen, ebenfalls auf XML-basierten Sprache, beschreiben, die als Grundlage für die Registrierung von Web Services mittels der Universal Description, Discovery and Integration (UDDI) 33 dient. 29 Sun Microsystems: Sun Open Net Environment (Sun ONE), 2002, S. 5; Kochmer, C.; Frandsen, E.: JSP and XML: Integrating XML and Web Services in Your JSP Application, Addison-Wesley, 2002, S Sun Microsystems: Sun Open Net Environment (Sun ONE), 2002, S. 5; Clabby, J.: Web Services Explained: Solutions and Applications for the Real World, Prentice Hall, 2002, S World Wide Web Consortium (W3C): SOAP 1.2 Specification, World Wide Web Consortium (W3C): Web Services Description Language (WSDL) 1.1, OASIS Open: UDDI Version 2 Specifications,

20 3 Verwendete Technologien 15 Die nachfolgende Abbildung 6 veranschaulicht den Zusammenhang zwischen diesen drei Technologien. Abbildung 6 : Zusammenhang zwischen UDDI, SOAP und WSDL 34 Der Web Service-Anbieter legt zunächst die nach außen sichtbare Schnittstelle seines Services fest. Dies geschieht mit Hilfe der Web Services Description Language (WSDL). Anschließend kann der Dienst in einem Verzeichnis für Web Services veröffentlicht werden. Ein solcher Verzeichnisdienst wird von Universal Description, Discovery and Integration (UDDI) spezifiziert. Der Web Service-Nutzer kann UDDI verwenden, um nach einem bestimmten Service zu suchen und ihn in eigene Anwendungen zu integrieren. Die eigentlichen Aufrufe an den Web Service finden dann im Allgemeinen über das Simple Object Access Protocol (SOAP) statt In Anlehnung an: Hein, G.; Lewis, J.: Web Services Basics: Separating Hype and Reality, in: Burton Group, Network Strategy, 2002, S Kochmer, C.; Frandsen, E.: JSP and XML: Integrating XML and Web Services in Your JSP Application, Addison-Wesley, 2002, S. 79.

21 3 Verwendete Technologien Web Services und J2EE Stateless Session Java Beans können in J2EE als Web Services zur Verfügung gestellt werden. Dies erfolgt durch einen JAX-RPC Endpoint und ermöglicht das Aufstellen von EJB- Applikationen als Web Services. 36 JAX-RPC 37 steht für Java API for XML-based Remote Procedure Call. JAX-RPC ist eine Technologie zum Entwickeln von Web Services und Clients, die Remote Procedure Calls (RPC) und XML verwenden. Der RPC-Mechanismus wird oft als verteiltes Client-Server- Modell eingesetzt und ermöglicht den Clients Funktionalitäten auf unterschiedlichen Systemen auszuführen. Ein Remote Procedure Call wird in JAX-RPC durch ein XML-basiertes Protokoll wie SOAP repräsentiert. Die SOAP-Spezifikation legt die Struktur, Kodierungsregeln und Konventionen für die Darstellung sowohl der Remote Procedure Calls (Aufrufe) als auch ihrer Antworten fest. Diese Aufrufe und Antworten werden in der Form von SOAP-Nachrichten (XML-Dateien) über HTTP transportiert. SOAP-Nachrichten sind zwar komplex, die JAX-RPC-API verbirgt jedoch diese Komplexität: SOAP-Nachrichten müssen nicht generiert oder analysiert werden, dieser Prozess wird vom JAX-RPC-System automatisch übernommen. Das System wandelt die API-Aufrufe in SOAP-Nachrichten und die Antworten aus SOAP-Nachrichten um. 38 Die Definition einer JAX-RPC-API besteht aus zwei Teilen. Auf der Server-Seite werden die Remote Procedures durch das Definieren von Methoden in einer Java-Schnittstelle spezifiziert. Diese Methoden werden entsprechend in Klassen implementiert. Auf der Client-Seite erstellt das Client-Programm ein Proxy-Objekt (ein lokales Objekt, welches den Service repräsentiert) und ruft die Methoden dieses Proxy-Objekts auf. 39 Bei der Verwendung von JAX-RPC kommt für Clients und Web Services der bereits in den Kapiteln und diskutierte Vorteil der Plattformunabhängigkeit der Java-Programmiersprache zum Tragen. Außerdem ist JAX-RPC nicht restriktiv: ein JAX-RPC-Client kann mit einem Web Service kommunizieren, der nicht auf einer Java-Plattform ausgeführt wird, 36 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S Sun Microsystems: Java API for XML-Based RPC, Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 319.

22 3 Verwendete Technologien 17 und umgekehrt. Diese Flexibilität ist auf Grund der Verwendung von Standard-Technologien möglich: JAX-RPC benutzt vom World Wide Web Consortium (W3C) definierte Technologien wie HTTP, SOAP 40 und Web Service Description Language (WSDL) Applikationsserver Die Java System Application Server Platform Edition 8 unterstützt werkzeug-basiert die effektive Entwicklung und das schnelle Deployment von Anwendungen. Der Java-Applikationsserver ist lizenzfrei und kostenlos für Entwicklung und Wiederverwendung in Applikationen aus dem wissenschaftlichen Bereich. Die Sun Java Application Server Platform Edition 8 ist die erste vollständig kompatible Implementierung der J2EE 1.4 Plattform. Sie unterstützt zwei neue Technologien für die Entwicklung der Web-Schicht von auf der J2EE-Technologie basierenden Anwendungen: JavaServer Faces 42, welche den Aufbau von Benutzerschnittstellen in Web-Applikationen vereinfachen, und die JavaServer Pages (JSP) Standard Tag Library (JSTL) 43, welche Basisfunktionalitäten für auf JSP basierenden Anwendungen bündelt. Zusätzlich zu diesen neuen Features enthält die Applikationsserver-Lösung von Sun Microsystems eine skalierbare und zuverlässige J2EE-Applikationsplattform, die durch die folgenden Eigenschaften gekennzeichnet ist: World Wide Web Consortium (W3C): SOAP 1.2 Specification, World Wide Web Consortium (W3C): Web Services Description Language (WSDL) 1.1, Sun Microsystems: JavaServer Faces Technology, Sun Microsystems: JavaServer Pages Standard Tag Library, Sun Microsystems: J2EE v1.4 Documentation, ; Ramsey, L.: Java System Application Server Platform Edition 8,

23 3 Verwendete Technologien 18 Vollständige Übereinstimmung mit dem J2EE-Standard: Web Services Interoperabilität ist gewährleistet durch die Unterstützung des WS-I 45 Basisprofils. Einen hoch-performanten Java Message Service (JMS)-Provider: für das Anbieten geschäftlicher Applikationsservices und Web Services. Vollständige Web Services-Infrastruktur: enthält die Java API for XML Messaging (JAXM), Java API for XML Processing (JAXP), Java API for XML Registries (JAXR), Java API for XML-based RPC (JAX-RPC) 46, SOAP und WSDL. Unterstützung der neuen J2EE-Connector-Architektur: die bi-direktionale Connectivity für den Zugriff auf Geschäftsapplikationen unterstützt Standard-J2EE- Deployment-APIs. Dadurch ist es möglich, den Applikationsserver mit Hilfe von Standard-Java-IDEs, wie beispielsweise NetBeans 47, zu deployen. 45 Web Services Interoperability (WS-I): Sun Microsystems: Web Service API Specifications, NetBeans:

24 4 Zentrale Koordinationskomponente 19 4 Zentrale Koordinationskomponente 4.1 Aufbau und Architektur Die Zentrale Koordinationskomponente ist der Hauptbestandteil dieser Arbeit. Wie Middleware dient sie als Bindeglied zwischen den Clients und den Annotationsservern. Dabei dient die Zentrale Koordinationskomponente zur Lasten- und Dokumentenverteilung, ist webbasiert und ist unter Verwendung der in Kapitel 3 beschriebenen Technologien realisiert. Als Applikationsserver wird der Sun Java System Application Server Platform Edition 8 von Sun Microsystems eingesetzt (siehe Abschnitt 3.4). Das Framework beinhaltet somit Softwarekomponenten zur Kommunikation mit den Clients und den Annotationsservern, zur Datenhaltung und zur Lastenverteilung. Die Zentrale Koordinationskomponente, deren Aufbau und Architektur in Abbildung 7 verdeutlicht wird, besteht aus folgenden Komponenten: Das AClientControllerBean ist ein Stateless Session Bean, das als Web Service interagiert und für die Kommunikation mit den Clients verantwortlich ist. Als Message-Driven Bean verteilt das AMessageControllerBean die zu annotierenden Dokumente an die entsprechenden Annotationsservern. Eine Warteschlange (Message-Queue) vom Typ Topic, die für den asynchronen Nachrichtenaustausch zwischen dem AClientControllerBean und dem AMessageControllerBean zuständig ist. Das AServerControllerBean ist wiederum ein Stateless Session Bean, das als Web Service interagiert und für die Kommunikation mit den Annotationsservern verantwortlich ist. Das AServerDataBean ist ein Entity Bean, mit dessen Hilfe die Eigenschaften der Annotationsserver in die Datenbank gespeichert werden. Für die Datenhaltung der annotierten Dokumente ist das Entity Bean ADocumentDataBean verantwortlich. Über die Datenbankschnittstelle können die Entity Beans mit der Datenbank interagieren.

25 4 Zentrale Koordinationskomponente 20 Abbildung 7 : Framework-Architektur 4.2 AClientControllerBean Das AClientControllerBean stellt als Web Service die Kommunikation des Clients mit dem Framework bereit. Dabei definiert AClientControllerIF als Web Service Endpoint Interface des Beans die Methoden, die aus der Clientsicht aufrufbar sind. Diese Bean-Methoden sind wiederum durch das AClientControllerBean implementiert Web Service Endpoint Interface AClientControllerIF ist das Web Service Endpoint Interface des Beans. Es stellt die Clientsicht auf den Web Service bereit und verbirgt das Stateless Session Bean gegenüber dem Client. Quelltext 1 zeigt die Definition der Schnittstelle AClientControllerIF.

26 4 Zentrale Koordinationskomponente 21 package de.mpg.mpisb.aframework.ejb.aclientcontroller; import java.rmi.remoteexception; import java.rmi.remote; public interface AClientControllerIF extends Remote { public String getprojectid() throws RemoteException; public String[] getannotationtyps() throws RemoteException; public String adddocument(string p_id, String p_name, String p_content, String typ, String[] p_properties) throws RemoteException; public String[] getdocument(string p_id, String p_name) throws RemoteException; } Quelltext 1 : AClientControllerIF Service-Implementierung Die Klasse AClientControllerBean implementiert die Methoden, die durch das Interface AClientControllerIF definiert werden. Die Methode getprojectid()gibt eine eindeutige Projekt-Id zurück, mit deren Hilfe der Client Dokumente zum Framework senden kann. Beim Aufruf der Methode getannotationstyps() gibt der Web Service ein Array vom Typ String[] zurück, welches die Annotationswerkzeuge mit ihren Typen auflistet. Diese sind die Annotationstypen, mit deren Hilfe die Dokumente annotiert werden. Mit der Methode adddocument() wird das zu annotierende Dokument zum Framework gesendet. Hierbei werden die folgenden Daten als Parameter übergeben: die durch die Methode getprojectid()erhaltene Projekt-Id, der gewünschte Typ zum Annotieren, der Name und der Inhalt der Datei. Die Methode erzeugt aus diesen Parametern ein Datenhaltungsobjekt vom Typ ADocument. Dieses wird dann zur weiteren Verarbeitung als Nachricht auf eine Warteschlange (Message-Queue) vom Typ Topic (siehe Kapitel 4.3.1) gelegt.

27 4 Zentrale Koordinationskomponente 22 Durch dieses Vorgehen muss der Client nicht auf das annotierte Dokument warten, sondern kann sogleich ein weiteres Dokument zum Framework versenden oder andere Methoden aufrufen. Mit Hilfe der Methode getdocument() erhält der Client ein annotiertes Dokument vom Server zurück. Als Parameter werden die Projekt-Id und der Name des Dokumentes übergeben. Diese Methode ruft dann mit den Parametern die Finder-Methoden des Entity Beans ADocumentDataBean auf. Wird ein solches entsprechendes Entity Bean gefunden, so wird mit dessen Remote-Methoden das Ergebnis-Array gefüllt und an den Client zurückgegeben. Das Ergebnis-Array vom Typ String[] enthält die folgenden Informationen in der angegebenen Reihenfolge: Projekt-Id Name des Dokumentes Originalinhalt des Dokumentes Originalannotationen des Dokumentes Das annotierte Dokument Die gefundenen Annotationen Die Art, auf die das Dokument annotiert wurde. 4.3 Message-Queue und AMessageControllerBean Message-Queue Eine Warteschlange (Message-Queue) ist eine Implementierung der Schnittstelle Java Message Service (JMS) 48 (siehe Kapitel 3.2.3). Sie ermöglicht den Austausch von Nachrichten (Senden und Empfangen) zwischen unterschiedlichen Clients, die in der Programmiersprache Java geschrieben sind. Bei der Warteschlange gibt es immer einen Abnehmer, der auf Nachrichten wartet und einen Anbieter (Provider), der diese Nachrichten bereitstellt. Dabei werden die Nachrichten in der 48 Sun Microsystems: Java Message Service,

28 4 Zentrale Koordinationskomponente 23 selben Reihenfolge geliefert, in der sie gesendet wurden. Nachdem eine Nachricht empfangen und vom Abnehmer gelesen wird, wird sie von der Warteschlange entfernt. Es existieren zwei Arten von Warteschlangen: JMS-Queues und JMS-Topics. Der Unterschied zwischen denen ist der folgende: bei einer Queue werden alle Nachrichten vom Abnehmer (in diesem Falle ein Message-Driven Bean) gelesen und konsumiert. Im Gegensatz dazu werden bei einer Topic nur die Nachrichten gelesen, die zu einer bestimmten Kategorie gehören. Dies wird durch eine Topic (Überschrift) erreicht, die die Nachricht enthält. In dieser Arbeit wurde eine Warteschlange vom Typ Topic verwendet. Diese Technologie wurde wegen ihrer Flexibilität gewählt: sie könnte die Verwendung von kategorisierten Dokumenten bei zukünftigen Erweiterungen des implementierten Frameworks unterstützen AMessageControllerBean Das AMessageControllerBean ist ein Message-Driven Bean, das die Verteilung der einzelnen Dokumente an die Annotationsserver bewerkstelligt. Das Bean implementiert hierbei die von der J2EE-Spezifikation geforderte Methode onmessage(). Diese Methode wird automatisch aufgerufen, falls eine Nachricht auf die Warteschlange gelegt wurde. Das in der Nachricht gespeicherte Objekt vom Typ ADocument wird dabei ausgelesen. Mit dem in der Datenstruktur ADocument gespeicherten Annotationstyp wird nun die Finder-Methode findbyannotationtyp() des Entity Beans AServerDataBean aufgerufen. Als Ergebnis erhält das AMessageControllerBean eine Auflistung der Annotationsserver, die diesen Annotationstyp unterstützen. Aus dieser Auflistung wird ein Annotationsserver per Zufall in der Gleichverteilung ausgewählt. Über die Remote-Methoden des Entity Beans AServerDataBean werden dann die entsprechenden Daten zum Aufbau einer Socket-Verbindung zum Annotationsserver gelesen. Nach dem erfolgreichen Etablieren einer Verbindung wird das zu annotierende Dokument über ein spezielles Protokoll an den Server gesendet. Quelltext 2 verdeutlicht den Aufbau des Protokolls.

29 4 Zentrale Koordinationskomponente 24 ANNOTATOR:PUT <Project-Id> <Name des Dokumentes> <Annotationstyp> <Inhalt des Dokumentes> Quelltext 2 : Protokoll zum Senden von Dokumenten 4.4 AServerControllerBean Das AServerControllerBean ist ähnlich wie das AClientControllerBean für die Kommunikation mit dem Framework verantwortlich. Der Unterschied besteht darin, dass das Bean, zusammen mit dem AMessageControllerBean, für die Integration der Backendsysteme, genauer der Annotationsserver, verantwortlich ist. Die Schnittstelle AServerControllerIF definiert als Web Service Endpoint Interface des Beans die Methoden, die aus der Clientsicht, in diesem Falle Annotationsserver-Sicht, aufrufbar sind. Diese Methoden werden durch das AServerControllerBean implementiert Web Service Endpoint Interface Die Schnittstelle AServerControllerIF ist das Web Service Endpoint Interface des Beans. Es stellt die Annotationsserver-Sicht auf den Web Service bereit und verbirgt das Stateless Session Bean gegenüber dem Annotationsserver. Quelltext 3 veranschaulicht die Schnittstelle AServerControllerIF. package de.mpg.mpisb.aframework.ejb.aservercontroller; import java.rmi.remoteexception; import java.rmi.remote; public interface AServerControllerIF extends Remote { public String register(string p_name, int p_port, String[] p_typ, int p_corpussize) throws RemoteException; public String unregister(string p_name, int p_port) throws RemoteException; } public String adddocument(string p_id, String p_name, String p_rstannots, String p_rstdoc, String p_srcannots, String p_srcdoc, String p_typ) throws RemoteException; Quelltext 3 : AServerControllerIF

30 4 Zentrale Koordinationskomponente Service-Implementierung Die Klasse AServerControllerBean implementiert die Methoden, welche durch die Schnittstelle AServerControllerIF definiert sind. Mit der Methode register() meldet sich der Annotationsserver am Framework an. Dabei übergibt er seine IP-Adresse (p_name), den Port, die verfügbaren Annotationstypen und die maximale Anzahl von Dokumenten, die er in einem Annotationsdurchgang annotieren kann. Beim Aufruf dieser Methode wird die Methode create() des Entity Beans AServerDataBean aufgerufen und somit ein neues Objekt diesen Typs mit den Parametern der Methode register()erzeugt. Die Methode unregister() wiederum meldet einen Annotationsserver vom Framework ab. Mit den Parametern dieser Methode wird die Finder-Methode findbyserver() des Entity Beans AServerDataBean aufgerufen und das dadurch gefundene Objekt gelöscht. Um das Ergebnis einer Annotation an das Framework zu senden, benutzt der Annotationsserver die Methode adddocument(). Beim Aufruf dieser Methode wird mit deren Parametern wiederum die Methode create() des Entity Beans ADocumentDataBean aufgerufen und somit ein Objekt diesen Typs erzeugt. 4.5 AServerDataBean Das Enterprise Java Bean AServerDataBean ist ein Entity Bean, das einen Annotationsserver repräsentiert. Der Status dieses Beans ist in der Tabelle annotationserver einer relationalen Datenbank gespeichert. Die Datenbanktabelle annotationserver wurde mit der in Quelltext 4 dargestellten SQL-Anweisung erzeugt.

31 4 Zentrale Koordinationskomponente 26 CREATE TABLE `annotationserver` ( `id` int(10) unsigned NOT NULL default '0', `name` varchar(255) default NULL, `port` int(10) unsigned default NULL, `corpussize` int(10) unsigned default '10', `currentcorpussize` int(10) unsigned default '0' ) Quelltext 4 : SQL-Anweisung zum Anlegen der Tabelle annotationserver Wegen Nutzung der Bean Managed Persistence (siehe Kapitel 3.2.2), beinhaltet das Entity Bean alle SQL-Anweisungen zum Zugriff auf diese Datenbanktabelle. Das AServerDataBean implementiert zwei Schnittstellen: zum einen das Remote Interface AServerData, welches die Methoden zur Anwendungslogik des Beans enthält, und zum anderen das Home Interface AServerDataHome, welches die Methoden zur Erzeugung und zum Finden des Entity Beans bereitstellt Remote Interface Das Remote Interface AServerData definiert die Anwendungslogik des Entity Beans, auf die der Client zugreifen kann. Die Definition des Remote Interfaces wird im Quelltext 5 veranschaulicht. package de.mpg.mpisb.aframework.ejb.aserverdata; import java.rmi.remoteexception; import javax.ejb.ejbobject; public interface AServerData extends EJBObject { public String getname() throws RemoteException; public int getport() throws RemoteException; public int getcorpussize() throws RemoteException; } public String[] getannotationstyps() throws RemoteException; Quelltext 5 : AServerData

32 4 Zentrale Koordinationskomponente Home Interface Die Definitionen der Erzeugungs- und Finder-Methoden des Entity Beans sind im Home Interface AServerDataHome hinterlegt. Quelltext 6 verdeutlicht die zur Verfügung stehenden Schnittstellen-Methoden. package de.mpg.mpisb.aframework.ejb.aserverdata; import java.util.collection; import java.rmi.remoteexception; import javax.ejb.*; public interface AServerDataHome extends EJBHome { public AServerData create(string p_server, int p_port, String[] p_types, int p_corpussize) throws RemoteException, CreateException; public AServerData findbyprimarykey(integer p_id) throws FinderException, RemoteException; public Collection findbyannotationtyp(string p_type) throws FinderException, RemoteException; } public AServerData findbyserver(string p_server, int p_port) throws FinderException, RemoteException; Quelltext 6 : AServerDataHome Bean-Implementierung Home Interface-Implementierung Wenn ein Client die Methode create() der Schnittstelle AServerDataHome aufruft, wird der EJB-Container veranlasst die korrespondierende Methode ejbcreate() des AServerDataBean auszuführen. Diese Methode fügt mit einer SQL-INSERT-Anweisung die mit den Parametern übergebenen Daten in die Datenbank ein. Der Aufruf wird erfolgreich mit der Rückgabe des entsprechenden Remote Interfaces an den Client beendet. Die Finder-Methoden erlauben es einem Client die Entity Beans zu finden. Zu diesem Zweck kann der Client folgende drei Methoden benutzen:

33 4 Zentrale Koordinationskomponente 28 findbyprimarykey() findbyannotationtyp() findbyserver(). Für jede dieser Methoden implementiert das AServerDataBean die entsprechenden Methoden mit dem Präfix ejbfind. Beispielsweise wird die zu findbyserver() korrespondierende Methode ejbfindbyserver() genannt. Quelltext 7 veranschaulicht die Bean-Implementierung der Methode ejbfindbyprimarykey(). public Integer ejbfindbyprimarykey(integer primarykey) throws FinderException { boolean result; try { result = selectbyprimarykey(primarykey); } catch (Exception ex) { throw new EJBException("ejbFindByPrimaryKey: " + ex.getmessage()); } if (result) { return primarykey; } else { throw new ObjectNotFoundException("Row for id " + primarykey + " not found."); } } Quelltext 7 : AServerDataBean.ejbFindByPrimaryKey() Auf dem ersten Blick scheint diese Methode inkorrekt zu sein, da sie statt eines Objekts vom Typ AServerData ein Objekt vom Typ Integer zurückgibt. An dieser Stelle muss jedoch berücksichtigt werden, dass der Client lediglich die Methode findbyprimarykey() der Home-Schnittstelle ausführt und der EJB-Container die entsprechende Methode ejbfindbyprimarykey().

34 4 Zentrale Koordinationskomponente 29 Die Schnittstelle AServerDataHome erbt von der Basisschnittstelle EJBHome weitere Methoden, die vom AServerDataBean implementiert werden müssen. Diese Methoden dienen zum Speichern, Laden und Löschen des Entity Beans. Tabelle 1 veranschaulicht das Zusammenspiel dieser Methoden und der entsprechenden Datenbank-Operationen. Methode SQL-Anweisung ejbcreate() INSERT ejbfindbyprimarykey() SELECT ejbfindbyannotationtyp() SELECT ejbfindbyserver() SELECT ejbload() SELECT ejbremove() DELETE ejbstore() UPDATE Tabelle 1 : SQL-Anweisungen im AServerDataBean Remote Interface-Implementierung Durch die Implementierung der Methoden der Remote-Schnittstelle AServerData erhält das Entity Bean seine Anwendungslogik. Die Methoden führen keine Datenbankabfragen aus, womit sichergestellt ist, dass die Anwendungslogik von der Datenbankprogrammierung getrennt ist. Die Methoden getname() und getport() übergeben dem Client die IP-Adresse und den Port des Annotationsservers, auf welchem dieser die zu annotierenden Dokumente erhalten kann. Beim Aufruf von getcorpussize() wird die maximale Anzahl der Dokumente zurückgegeben, die der Server in einem Annotationsdurchgang annotieren kann. Mit der Methode getannotationstyps() erhält der Client ein Array vom Typ String[] mit den Annotationstypen, die der Annotationsserver zur Verfügung stellt. 4.6 ADocumentDataBean Das Enterprise Java Bean ADocumentDataBean ist ein Entity Bean, das ein annotiertes Dokument repräsentiert. Der Status dieses Beans ist in der Tabelle annotations einer relationalen Datenbank gespeichert. Die Datenbanktabelle annotations wurde mit der in Quelltext 8 veranschaulichten SQL-Anweisung erzeugt.

35 4 Zentrale Koordinationskomponente 30 CREATE TABLE `annotations` ( `id` int(11) unsigned NOT NULL default '0', `projectid` varchar(255) default NULL, `name` varchar(255) default NULL, `srcdoc` longtext, `srcannots` longtext, `rstdoc` longtext, `rstannots` longtext, `typ` varchar(255) default NULL ) Quelltext 8 : SQL-Anweisung zum Anlegen der Tabelle annotations Auch hier beinhaltet das Entity Bean wegen Nutzung der Bean Managed Persistence (siehe Kapitel 3.2.2) alle SQL-Anweisungen zum Zugriff auf diese Datenbanktabelle. Das ADocumentDataBean implementiert zwei Schnittstellen: das Remote Interface ADocumentData und das Home Interface ADocumentDataHome. Die Schnittstelle ADocumentData enthält die Methoden zur Anwendungslogik des Beans, während ADocumentDataHome die Methoden zur Erzeugung und zum Finden des Entity Beans bereitstellt Remote Interface Das Remote Interface ADocumentData definiert die Anwendungslogik des Entity Beans, auf welche der Client zugreifen kann. Quelltext 9 stellt die Definition des Remote Interfaces dar.

36 4 Zentrale Koordinationskomponente 31 package de.mpg.mpisb.aframework.ejb.adocumentdata; import java.rmi.remoteexception; import javax.ejb.ejbobject; public interface ADocumentData extends EJBObject { public String getprojectid() throws RemoteException; public String getname() throws RemoteException; public String getsourcedocument() throws RemoteException; public String getsourceannotations() throws RemoteException; public String getresultdocument() throws RemoteException; public String getresultannotations() throws RemoteException; } public String getannotationtyp() throws RemoteException; Quelltext 9 : ADocumentData Home Interface Die Definitionen der Erzeugungs- und Finder-Methoden des Entity Beans sind im Home Interface ADocumentDataHome hinterlegt. Quelltext 10 verdeutlicht die zur Verfügung stehenden Schnittstellen-Methoden.

37 4 Zentrale Koordinationskomponente 32 package de.mpg.mpisb.aframework.ejb.adocumentdata; import java.rmi.remoteexception; import javax.ejb.*; public interface ADocumentDataHome extends EJBHome { public ADocumentData create(string p_projectid, String p_name, String p_srcdoc, String p_srcannots, String p_rstdoc, String p_rstannots, String p_type) throws RemoteException, CreateException; public ADocumentData findbyprimarykey(integer p_id) throws FinderException, RemoteException; } public ADocumentData findbyname(string p_projectid, String p_name) throws FinderException, RemoteException; Quelltext 10 : ADocumentDataHome Bean-Implementierung Home Interface-Implementierung Wenn ein Client die Methode create() der Schnittstelle ADocumentDataHome aufruft, wird der EJB-Container veranlasst die korrespondierende Methode ejbcreate() des ADocumentDataBean auszuführen. Diese Methode fügt mit einer SQL-INSERT-Anweisung die mit den Parametern übergebenen Daten in die Datenbank ein. Der Aufruf wird erfolgreich mit der Rückgabe des entsprechenden Remote Interfaces an den Client beendet. Die Finder-Methoden erlauben es einem Client die Entity Beans zu finden. Der Client kann hierzu die folgenden zwei Methoden benutzen: findbyprimarykey() findbyname(). Für jede dieser Methoden implementiert das ADocumentDataBean die entsprechenden Methoden mit dem Präfix ejbfind. Beispielsweise wird die zu findbyname() korres-

38 4 Zentrale Koordinationskomponente 33 pondierende Methode ejbfindbyname() genannt. Quelltext 11 veranschaulicht die Bean- Implementierung der Methode ejbfindbyname(). public Integer ejbfindbyname(string p_projectid, String p_name) throws FinderException { Integer result; try { result = selectbyname(p_projectid, p_name); } } catch (Exception ex) { throw new EJBException("ejbFindInRange: " + ex.getmessage()); } return result; Quelltext 11 : ADocumentDataBean.ejbFindByName() Die Schnittstelle ADocumentDataHome erbt von der Basisschnittstelle EJBHome weitere Methoden, die vom ADocumentDataBean implementiert werden müssen. Ähnlich wie bei dem AServerDataBean dienen diese Methoden zum Speichern, Laden und Löschen des Entity Beans (siehe Kapitel 4.5.3). Tabelle 2 veranschaulicht das Zusammenspiel dieser Methoden und der entsprechenden Datenbank-Operationen. Methode ejbcreate() ejbfindbyprimarykey() ejbfindbyname() ejbload() ejbremove() ejbstore() SQL-Anweisung INSERT SELECT SELECT SELECT DELETE UPDATE Tabelle 2 : SQL-Anweisungen im ADocumentDataBean Remote Interface-Implementierung Durch die Implementierung der Methoden der Remote-Schnittstelle ADocumentData erhält das Entity Bean seine Anwendungslogik. Die Methoden führen keine Datenbankabfragen aus, womit die Trennung der Anwendungslogik von der Datenbankprogrammierung gewährleistet ist.

39 4 Zentrale Koordinationskomponente 34 Die Methoden getprojectid() und getname() übergeben dem Client die Projekt-Id und den Dateinamen des annotierten Dokumentes. Beim Aufruf der Methoden getsourcedocument() und getresultdocument() werden einmal der Originalinhalt und einmal der annotierte Inhalt des Dokumentes zurückgegeben. Mit den Methoden getresultannotations() und getsourceannotations() erhält der Client die Annotationen mit Angaben zur Position im Dokumententext und Worttyp (Person, Datum usw.). Schließlich gibt die Methode getannotationtyp() den Annotationstyp zurück, mit dem das Dokument annotiert wurde. 4.7 Datenbank-Schnittstelle Für die Speicherung der Daten benutzt das Annotations-Framework eine relationale Datenbank. Als Datenbankserver wird MySql 49 in der Version 4.1 eingesetzt. Grundsätzlich werden Datenbanken mit Hilfe ihrer JDBC-Treiber angesprochen. Mit einem JDBC-Treiber wird eine Verbindung (Connection Pool) aufgebaut, der ein entsprechender JNDI-Name zugewiesen wird. Eine als Connection Pool gespeicherte Verbindung kann ausgewählt werden und ihr kann eine virtuelle Datenbank zugeordnet werden. Dabei ist eine virtuelle Datenbank ein Datenbank-Objekt, welches einen JNDI-Namen besitzt. Über diesen JNDI-Namen können alle J2EE-Serverkomponenten Zugriff auf die Datenbank erhalten. 49 MySql:

40 4 Zentrale Koordinationskomponente 35 Durch die Verwendung von Connection Pools ist ein einfacher Wechsel zu unterschiedlichen Datenbanken gewährleistet. So wurde am Anfang dieser Arbeit die mit dem J2EE-Applikationsserver mitgelieferte Datenbank Pointbase 50 benutzt. Aus lizenzrechtlichen Gründen war jedoch ein Austausch notwendig. Als zu verwendende Datenbank wurde MySql gewählt. Der Wechsel verlief reibungslos: der entsprechende Datenbanktreiber wurde installiert, ein neuer Connection Pool wurde generiert (siehe oben) und dieser der virtuellen Datenbank zugewiesen. Nach diesem Vorgehen konnte die MySql-Datenbank direkt eingesetzt werden. 50 Pointbase:

41 5 Beispiel-Implementierung eines Clients 36 5 Beispiel-Implementierung eines Clients Die Beispiel-Implementierung eines Clients soll die Möglichkeiten eines Web Service-Clients verdeutlichen. Der Web Service-Client ist mit der JAX-RPC-API als Dynamic Proxy Client realisiert. Damit der Client mit dem Framework kommunizieren kann, muss er eine Verbindung zur Web Service-Schnittestelle des Session Beans AClientControllerBean aufbauen. Über diese Verbindung kann dann der Client die Methoden getprojectid(), getannotationstyps(), adddocument() und getdocument() aufrufen (siehe Abschnitt 4.2.2). Um die Verbindung mit dem Web Service aufzubauen, erzeugt der Client einen Dynamic Proxy wie im Folgenden beschrieben. Zuerst wird ein Objekt vom Typ Service erzeugt, welches Quelltext 12 verdeutlicht. Ein Service Objekt ist ein Entwurfsmuster für Proxies. Um das Service Objekt zu erzeugen, wird die Methode createservice() eines weiteren Entwurfmusters vom Typ ServiceFactory aufgerufen. ServiceFactory servicefactory = ServiceFactory.newInstance(); Service helloservice = servicefactory.createservice(p_url, new QName(nameSpaceUri, servicename)); Quelltext 12 : Dynamic Proxy Generierung Teil 1 Die Methode hat zwei Parameter: die URL der WSDL-Datei und ein QName Objekt. Mit Hilfe der WSDL-Datei erhält der Client Informationen über den Web Service. Sie wird beim Kompilieren des Web Services erzeugt. Diese URL wird in einem serialisierten AConfig Objekt des Clients abgespeichert. Abbildung 8 zeigt den Java Swing Dialog zum Ändern der URL an.

42 5 Beispiel-Implementierung eines Clients 37 Abbildung 8 : Dialog Konfiguration Ein Objekt vom Typ QName ist ein Tupel, welches einen XML konformen Namen repräsentiert. Das Tupel besteht aus einer Namespace URI und den lokalen Teil des Namens. Der lokale Servicename ist hierbei AClientController (siehe Quelltext 12). Anschließend generiert der Client einen Proxy (myproxy) mit dem Typ der Web Service Endpoint-Schnittstelle (AClientControllerIF): de.mpg.mpisb.aclient.webservice.aclientcontrollerif myproxy = (de.mpg.mpisb.aclient.webservice.aclientcontrollerif) helloservice.getport(new QName(nameSpaceUri, portname), de.mpg.mpisb.aclient.webservice.aclientcontrollerif.class); Quelltext 13 : Dynamic Proxy Generierung Teil 2 Das Objekt helloservice ist ein Entwurfsmuster für dynamische Proxies. Um myproxy zu erzeugen, ruft das Programm die Methode getport() auf. Diese Methode besitzt zwei Parameter: ein QName Objekt, das den Port-Namen spezifiziert, und ein java.lang.class Objekt für das Service Endpoint Interface. Diese Klasse wird mit dem Werkzeug wscompile und der WSDL-Datei des Web Services erzeugt. Der Port-Name (portname) ist wiederum in der WSDL-Datei spezifiziert.

43 5 Beispiel-Implementierung eines Clients 38 Mit dieser Proxy-Verbindung kann nun der Client die Methoden des Web Services aufrufen, die in der Web Service-Schnittstelle definiert sind. Quelltext 14 zeigt am Beispiel der Methode getprojectid()den vollständigen Aufruf einer Web Service-Methode. public String getprojectid(url p_url) { String result = null; try { ServiceFactory servicefactory = ServiceFactory.newInstance(); Service helloservice = servicefactory.createservice(p_url, new QName(nameSpaceUri, servicename)); de.mpg.mpisb.aclient.webservice.aclientcontrollerif myproxy = (de.mpg.mpisb.aclient.webservice.aclientcontrollerif) helloservice.getport(new QName(nameSpaceUri, portname), (de.mpg.mpisb.aclient.webservice.aclientcontrollerif.class); result = myproxy.getprojectid(); } catch (Exception ex) { ex.printstacktrace(); } return result; } Quelltext 14 : Clientaufruf von getprojectid() Zusätzlich zu der Grundfunktionalität mit einem Web Service interagieren zu können, besitzt der Client eine Benutzeroberfläche (siehe Abbildung 9), mit der diese Funktionalität gesteuert wird. Mit der leicht-bedienbaren Benutzeroberfläche können die verschiedenen Client-Funktionalitäten aufgerufen werden. Zu diesem Zweck bietet die Benutzeroberfläche zwei Registerkarten: für das Senden und für das Empfangen von Dokumenten (siehe Abbildung 9). Die Dokumente können mit Hilfe eines Datei-Auswahl-Dialogs bezüglich ihrer Projekt-Id zusammengestellt werden. Über die Registerkarte Senden können die Dokumente an das Framework gesendet werden, während über die Registerkarte Empfangen die gesendeten Projekte ausgewählt und empfangen werden können. Dabei werden die Dateien in das Verzeichnis abgespeichert, das im Konfigurationsdialog eingestellt ist (siehe Abbildung 8).

44 5 Beispiel-Implementierung eines Clients 39 Die Benutzeroberfläche wurde mit eigenen Modifikationen auf Basis der Bibliotheken jlooks und jforms 51 erstellt. Abbildung 9 : Benutzeroberfläche AClient 51 JGOODIES Java User Interface Design:

45 6 Kommunikation 40 6 Kommunikation In diesem Kapitel werden die Kommunikationsabläufe des Frameworks beschrieben, welche bei einem erfolgreichen Annotationsvorgang stattfinden. Damit das Framework seine Aufgabe, das Annotieren von Dokumenten, erfüllen kann, muss sich mindestens ein Annotationsserver als Backendsystem am Framework registriert haben. Zu diesem Zweck ruft der Annotationsserver die Web Service-Schnittstelle des Session Beans AServerControllerBean auf und meldet sich mit deren Methode register()an. Das AServerControllerBean schreibt anschließend über das Entity Bean AServerDataBean die Anmeldedaten in die Datenbank. Hat sich ein Annotationsserver am Framework angemeldet, kann ein Client, wie er zum Beispiel in Kapitel 5 implementiert wurde, eine Projekt-Id und eine Auflistung der vom Framework bereitgestellten Annotationstools anfordern. Dazu ruft er die Methoden getprojectid() und die getannotationstyps()der Web Service-Schnittstelle des Session Beans AClientControllerBean auf. Nun kann der Client mit der Methode adddocument()und den entsprechenden Parametern Dokumente zum Annotieren an das Framework senden. Wurde das Dokument an das Framework erfolgreich übertragen, so sendet des AClientControllerBean eine Nachricht mit den Dokumentendaten an die Topic-Warteschlange. Die Topic-Warteschlange wird von dem AMessageControllerBean abgehört. Falls die Warteschlange eine Nachricht für das AMessageControllerBean enthält, wird dessen Methode onmessage() ausgeführt. Beim Ausführen der Methode besorgt sich das Bean über das AServerDataBean die Daten eines Annotationsservers aus der Datenbank, mit dem das Dokument annotiert werden kann. Mit diesen Daten kann eine Socket-Verbindung aufgebaut werden. Über diese Verbindung wird, mit dem in Abschnitt beschriebenen Protokoll, das Dokument an den Annotationsserver verschickt. Hat ein Annotationsserver ein Dokument annotiert, so sendet er wiederum über die Web Service-Schnittstelle des Session Beans AServerControllerBean das annotierte Dokument an das Framework zurück. Dazu wird die Methode adddocument()aufgerufen, die dann die erhaltenen Daten über das ADocumentDataBean in die Datenbank speichert.

46 6 Kommunikation 41 Möchte nun der Client sein vorher gesendetes Dokument wieder bekommen, so ruft er über die Web Service-Schnittstelle des Session Beans AClientControllerBean die Methode getdocument()auf. Diese erhält die entsprechenden Dokumentendaten mit Hilfe des Entity Beans ADocumentDataBean von der Datenbank und gibt diese Daten an den Client zurück. Soll ein Annotationsserver von dem Framework abgemeldet werden, so wird dies über die Methode unregister() der Web Service-Schnittstelle des Session Beans AServerControllerBean erledigt. Die Methode löscht beim Aufruf die entsprechenden Daten über das AServerDataBean aus der Datenbank. Somit stehen dieser Annotationsserver und dessen Annotationswerkzeuge dem Framework nicht mehr zur Verfügung.

47 7 Evaluation 42 7 Evaluation Um die Leistung des Frameworks beurteilen zu können, wurde das Framework mitsamt angeschlossenen Client und Annotationsservern getestet. Im folgenden Kapitel wird der Versuchsaufbau beschrieben und die Ergebnisse der durchgeführten Lastentests dargestellt und beurteilt. 7.1 Versuchsaufbau Der J2EE-Applikationsserver von Sun Microsystems und der Client wurden auf einem Personal PC von Dell mit dem Microsoft XP Betriebssystem installiert. Die Annotationsserver wurden auf dem Linux Cluster des Max Plank Instituts für Informatik (MPI) betrieben. Die folgende Tabelle 3 gibt einen Überblick über die technischen Spezifikationen der Systeme. System Client und J2EE-Server System Annotationsserver Betriebssystem Microsoft Windows XP Professional Debian Linux CPU Intel Pentium 4, 3.0 GHz 2 * AMD Opteron, 2.4 GHz Hauptspeicher 1 GB 8 GB Tabelle 3 : Technische Spezifikation Versuchsaufbau Als Dokumentenbasis für das verteilte Annotieren dienten 2627 XML-Dokumente aus dem Wikipedia-Verzeichnis. Durch die Verteilung der Dokumente in 5 verschiedene Größenklassen kann von einer heterogenen Dokumentenbasis bezüglich der Größe gesprochen werden (siehe Abbildung 10). Hierbei war das kleinste 444 Bytes und das größte Dokument 104,69 Kilobytes groß. Die durchschnittliche Größe betrug 4,54 Kilobytes.

48 7 Evaluation 43 Abbildung 10 : Dokumentenverteilung 7.2 Lastentest Beim Lastentest wurden drei Hauptdurchgänge durchgeführt. Dabei wurde zweimal mit dem ANNIE-Annotationswerkzeug annotiert und zwar einmal mit einer Korpusgröße von 25 Dokumenten und einmal mit einer Korpusgröße von 50 Dokumenten. Des Weiteren wurde einmal mit Minorthird annotiert, jedoch nur mit einer Korpusgröße von 25 Dokumenten. Durch den hohen Speicherverbrauch und dem damit verbundenen Programmabsturz von Minorthird, war ein weiterer Durchgang mit einer Korpusgröße von 50 Dokumenten nicht möglich. Dieser Fall trat auch bei ANNIE auf, jedoch erst bei einer Korpusgröße von circa 100 Dokumenten. Jeder dieser einzelnen Durchgänge wurde insgesamt fünfmal durchgeführt. So wurde jeder Durchgang jeweils mit einem, zwei, drei, vier und acht an das Framework angemeldeten Annotationsservern bewerkstelligt. Insgesamt wurden somit 15 Annotationsvorgänge mit den 2627 Dokumenten ausgeführt. Zum Senden der XML-Dokumente an das Framework brauchte der Client im Durchschnitt 151 Sekunden und zum Empfangen der annotierten Dokumente 412 Sekunden. Der Zeitunterschied ist durch das höhere Datenaufkommen des Ergebnis-Arrays der Methode getdocument() (siehe Abschnitt 4.2.2) zu erklären.

49 7 Evaluation 44 Das Framework brauchte wiederum 153 Sekunden um die XML-Dokumente an die einzelnen Annotationsserver zu versenden. Beim ersten Testdurchlauf mit ANNIE und einer Korpusgröße von 25 Dokumenten brauchte das Framework für die 2627 XML-Dokumente 1508 Sekunden, um diese zu annotieren. Dieser Durchlauf wurde wie oben beschrieben mit einer unterschiedlichen Anzahl von Annotationsservern wiederholt. Dabei wurde bei jedem Durchgang eine signifikante Performance-Verbesserung festgestellt. Der zweite Testdurchlauf mit einer Korpusgröße von 50 Dokumenten ergab ein ähnliches Bild bezüglich der Performance. Jedoch mit zwei Ausnahmen: der Performance-Zuwachs auf Grund der erhöhten Korpusgröße war marginal und beim Ausführen des Tests mit acht Annotationsservern wurde festgestellt, dass die Performance-Messungen schlechtere Werte ergaben, als bei einem Test mit vier Annotationsservern. Die genauen Zeiten der beiden Testdurchläufe sind aus der Tabelle 4 und Abbildung 11 ersichtlich. Anzahl Server ANNIE 25 Zeit in sec ANNIE 50 Zeit in sec Minorthird 25 Zeit in sec Tabelle 4 : Annotationszeiten Die Ursache dieses Ergebnisses war schnell gefunden. Durch die hohe Korpusgröße warteten die Annotationsserver zu lange, bis sie den Annotationsvorgang starten konnten. Der Grund dafür war, dass das Framework eine nicht ausreichend hohe Durchsatzrate garantieren konnte. Somit wurde der Dokumentenkorpus nicht ausreichend schnell mit Dokumenten gefüllt. Dieses Ergebnis verdeutlicht, dass der Zusammenhang zwischen Korpusgröße und Anzahl der verwendeten Annotationsserver eine große Rolle spielt. Bei den Tests hat sich eine Korpusgröße von 25 Dokumenten und acht Annotationsservern als am praktikabelsten erwiesen.

50 7 Evaluation 45 Die Testdurchläufe mit Minorthird waren weniger zufrieden stellend. Die Laufzeit war im Vergleich zu den ANNIE-Durchläufen zu hoch. Auch die Qualität und Zuverlässigkeit der Annotationen sind als unzureichend zu bewerten 52. Tabelle 4 zeigt die genauen Laufzeiten der Durchläufe mit Minorthird. Abbildung 11 : Annotationszeiten im Vergleich 52 Fuchs, D.: Verteilte Annotation von Dokumenten Entwurf und Implementierung eines modularen Annotationsservers auf Basis von NLP-Technologien, Universität des Saarlandes, 2006.