verteilte annotation von dokumenten – architekturentwurf ... · 5 fuchs, d.: verteilte annotation...

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 29.05.2006

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 29.05.2006 Frank Stefan Fuchs

Inhaltsverzeichnis I

Inhaltsverzeichnis

1 Einleitung 1

1.1 Motivation .................................................................................................................. 1

1.2 Zielsetzung und Aufbau der Arbeit ............................................................................ 1

2 Architektur 3

2.1 Umfeld und Anforderungen ....................................................................................... 3

2.2 Plattformen ................................................................................................................. 4

2.2.1 .NET ................................................................................................................... 4

2.2.2 J2EE ................................................................................................................... 4

2.2.3 Beurteilung ......................................................................................................... 4

2.3 Bestandteile ................................................................................................................ 5

3 Verwendete Technologien 7

3.1 J2EE ........................................................................................................................... 7

3.1.1 Verteilte mehrschichtige Anwendungen ............................................................ 7

3.1.2 J2EE-Komponenten ........................................................................................... 8

3.2 Enterprise Java Beans................................................................................................. 9

3.2.1 Session Beans................................................................................................... 10

3.2.2 Entity Beans ..................................................................................................... 12

3.2.3 Message-Driven Beans..................................................................................... 13

3.3 Web Services............................................................................................................ 13

3.3.1 Begriffsbestimmung und Funktionsweise........................................................ 13

3.3.2 Web Services und J2EE ................................................................................... 16

3.4 Applikationsserver ................................................................................................... 17

Inhaltsverzeichnis II

4 Zentrale Koordinationskomponente 19

4.1 Aufbau und Architektur ........................................................................................... 19

4.2 AClientControllerBean............................................................................................. 20

4.2.1 Web Service Endpoint Interface ...................................................................... 20

4.2.2 Service-Implementierung ................................................................................. 21

4.3 Message-Queue und AMessageControllerBean....................................................... 22

4.3.1 Message-Queue ................................................................................................ 22

4.3.2 AMessageControllerBean ................................................................................ 23

4.4 AServerControllerBean............................................................................................ 24

4.4.1 Web Service Endpoint Interface ...................................................................... 24

4.4.2 Service-Implementierung ................................................................................. 25

4.5 AServerDataBean..................................................................................................... 25

4.5.1 Remote Interface .............................................................................................. 26

4.5.2 Home Interface................................................................................................. 27

4.5.3 Bean-Implementierung..................................................................................... 27

4.6 ADocumentDataBean............................................................................................... 29

4.6.1 Remote Interface .............................................................................................. 30

4.6.2 Home Interface................................................................................................. 31

4.6.3 Bean-Implementierung..................................................................................... 32

4.7 Datenbank-Schnittstelle ........................................................................................... 34

5 Beispiel-Implementierung eines Clients 36

6 Kommunikation 40

7 Evaluation 42

7.1 Versuchsaufbau ........................................................................................................ 42

7.2 Lastentest.................................................................................................................. 43

8 Zusammenfassung und Ausblick 46

Inhaltsverzeichnis III

A Installation 48

A.1 Framework ............................................................................................................... 48

A.2 Client ........................................................................................................................ 50

A.3 Annotationsserver..................................................................................................... 51

B Abbildungsverzeichnis 52

C Tabellenverzeichnis 53

D Quelltextverzeichnis 54

E Literaturverzeichnis 55

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 ANNIE2 oder Minorthird3.

Durch die hohe Anzahl von Dokumenten (die deutsche Wikipedia-Seite allein mit über

390.000 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änglich-

keiten beseitigt.

1.2 Zielsetzung und Aufbau der Arbeit

Ziel dieser Arbeit ist es, ein webbasiertes Framework für die verteile Annotation von Doku-

menten zu entwerfen und zu implementieren. Das Framework soll insbesondere die Integra-

tion 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 2001. 2 Cunningham, H. et al.: Developing Language Processing Components with GATE (a User’s Guide), University

of Sheffield, 2001-2006. 3 Cohen, W.: Minorthird: Methods for Identifying Names and Ontological Relations in Text using Heuristics for

Inducing Regularities from Data, http://minorthird.sourceforge.net, 2004.

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 J2EE4

(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 Kompo-

nenten 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 Annotationsservern5 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, http://java.sun.com/j2ee/1.4/docs/, 2004. 5 Fuchs, D.: Verteilte Annotation von Dokumenten – Entwurf und Implementierung eines modularen

Annotationsservers auf Basis von NLP-Technologien, Universität des Saarlandes, 2006

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ähr-

leisten, muss das Framework einige Kriterien an die zu verwendende Plattform stellen. Hier-

bei 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 Lastenver-

teilung unabhängig von der Implementierung der Anwendung konfiguriert werden

kann.

• Flexibilität

Bei einer Anwendung sollte die Möglichkeit bestehen, die Laufzeit- und Entwick-

lungsumgebung nach den Anforderungen der Anwendung zusammen zu stellen.

Für die Implementierung des Frameworks kommen grundsätzlich zwei Plattformen in Be-

tracht: .NET6 von Microsoft und J2EE7 von Sun Microsystems.

6 Microsoft Corporation: .NET Framework 1.0, http://msdn.microsoft.com/netframework/previous/v1.0/

default.aspx, 2002. 7 Sun Microsystems: J2EE v1.4 Documentation, http://java.sun.com/j2ee/1.4/docs/, 2004.

2 Architektur 4

2.2 Plattformen

2.2.1 .NET

.NET ist eine Implementierung des Common Language Infrastructure Standards8 für

Windows durch die Firma Microsoft. Sie besteht aus einem Framework von Klassenbiblio-

theken 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 Lauf-

zeitumgebungen signifikant unterscheidet, ist das berücksichtigte Nebeneinander mehrerer

Programmiersprachen.

2.2.2 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 mehr-

schichtiges verteiltes Applikationsmodell, wieder verwendbare Komponenten, ein vereinheit-

lichtes Sicherheitsmodell, flexible Transaktionskontrolle und Web Services-Unterstützung

durch den Austausch von integrierten Daten über XML-basierte offene Standards und Proto-

kolle.9

2.2.3 Beurteilung

J2EE und .NET sind zwei ähnliche Ansätze für die Entwicklung von Anwendungs-Frame-

works.

8 Microsoft Corporation: Common Language Infrastructure Standard, http://msdn.microsoft.com/netframework/

ecma/, 2002-2006. 9 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 1.

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 unter-

schiedliche 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 Anwendungs-

entwicklungs-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 ver-

teilten 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.12

2.3 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. 3. 11 Younis, S.: J2EE vs. .NET An Executive Look, 2003, S. 3. 12 Thielscher, J.: J2EE und .NET zwei konkurrierende Standards?, Computer Zeitung, Mai 2002, S. 4.

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


3 Verwendete Technologien

3.1 J2EE

3.1.1 Verteilte mehrschichtige Anwendungen

Die J2EE-Plattform verwendet ein verteiltes mehrschichtiges (multi-tier) Applikationsmodell

für Anwendungen. Die Anwendungslogik ist in Komponenten anhand ihrer Funktion aufge-

teilt. Die unterschiedlichen Anwendungskomponenten, aus denen die J2EE-Applikation be-

steht, können auf verschiedenen Rechnern installiert sein. Die Aufteilung erfolgt in

Abhängigkeit von der Schicht in der mehrschichtigen J2EE-Umgebung, der die Anwen-

dungskomponente 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 aus-

geführt.

13 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 2.


Abbildung 2 : Mehrschichtige Anwendungen14

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.15

3.1.2 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-Spezifikation16 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. 3. 15 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 2. 16 Sun Microsystems: J2EE Platform Specification 1.4, http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf, 2004.


• 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 Unter-

schied zwischen J2EE-Komponenten und „Standard“-Java-Klassen ist, dass J2EE-Kompo-

nenten 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 kom-

muniziert, 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 ent-

fernte 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 Ob-

jekte der Enterprise Java Beans. Dies wird realisiert, indem der Client mit den Beans über

17 Backschat, M.: Enterprise Java Beans, Spektrum Akademischer Verlag, 2002. 18 Sun Microsystems: Java Naming and Directory Interface (JNDI), http://java.sun.com/products/jndi/, 2002.


vom J2EE-Server generierte Stubs kommuniziert, die ihrerseits mit den entsprechenden Me-

thoden der Beans kommunizieren. Dazu besitzt jedes Enterprise Java Bean zwei zu imple-

mentierende 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-Spezifikation19 unterscheidet drei Arten von Enterprise Java Beans: Session Beans,

Entity Beans und Message-Driven Beans.

3.2.1 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.20

19 Sun Microsystems: Enterprise JavaBeans Specification 2.1, http://java.sun.com/products/ejb/docs.html, 2004. 20 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 858.


Abbildung 3 : Lebenszyklus eines Stateless Session Beans21

Eine klassische Anwendung für das Stateful Session Bean ist der Gebrauch eines Warenkor-

bes. 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 ei-

nes 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 Beans23

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. 875. 22 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 858. 23 In Anlehnung an: Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 874.


3.2.2 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 reibungs-

losen 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 Beans25

24 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.


3.2.3 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-API26 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 ähn-

lichen Lebenszyklus wie die Stateless Session Beans (siehe Abbildung 3).

3.3 Web Services

3.3.1 Begriffsbestimmung und Funktionsweise

Unter Web Services werden selbstbeschreibende, modulare Software-Komponenten verstan-

den, die dynamisch über Standard-Internettechnologien andere Komponenten im Web aus-

findig machen und benutzen können, um so eine komplette, umfangreiche Aufgabe zu erfül-

len.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 Anwendungs-

programme oder andere Web Services sein.

26 Sun Microsystems: Java Message Service, http://java.sun.com/products/jms/docs.html, 2002. 27 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 864. 28 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.


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 beschrie-

ben 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 kommuni-

zieren ü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. 75. 30 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. 24. 31 World Wide Web Consortium (W3C): SOAP 1.2 Specification, http://www.w3.org/TR/soap12-part1, 2003. 32 World Wide Web Consortium (W3C): Web Services Description Language (WSDL) 1.1,

http://www.w3.org/TR/wsdl, 2001. 33 OASIS Open: UDDI Version 2 Specifications, http://www.oasis-open.org/committees/uddi-

spec/doc/tcspecs.htm, 2002.


Die nachfolgende Abbildung 6 veranschaulicht den Zusammenhang zwischen diesen drei

Technologien.

Abbildung 6 : Zusammenhang zwischen UDDI, SOAP und WSDL34

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). An-

schließ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.35

34 In Anlehnung an: Hein, G.; Lewis, J.: Web Services Basics: Separating Hype and Reality, in: Burton Group,

Network Strategy, 2002, S. 24. 35 Kochmer, C.; Frandsen, E.: JSP and XML: Integrating XML and Web Services in Your JSP Application,

Addison-Wesley, 2002, S. 79.


3.3.2 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-RPC37 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-ba-

siertes Protokoll wie SOAP repräsentiert. Die SOAP-Spezifikation legt die Struktur, Kodie-

rungsregeln und Konventionen für die Darstellung sowohl der Remote Procedure Calls (Auf-

rufe) 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 automa-

tisch übernommen. Das System wandelt die API-Aufrufe in SOAP-Nachrichten und die Ant-

worten 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 spezifi-

ziert. 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 2.2.2 und 2.2.3 diskutierte Vorteil der Plattformunabhängigkeit der Java-Program-

miersprache 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. 319. 37 Sun Microsystems: Java API for XML-Based RPC, http://java.sun.com/webservices/jaxrpc, 2002. 38 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 319. 39 Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 319.


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 Technolo-

gien wie HTTP, SOAP40 und Web Service Description Language (WSDL)41.

3.4 Applikationsserver

Die Java System Application Server Platform Edition 8 unterstützt werkzeug-basiert die ef-

fektive Entwicklung und das schnelle Deployment von Anwendungen. Der Java-Applikati-

onsserver ist lizenzfrei und kostenlos für Entwicklung und Wiederverwendung in Applikatio-

nen aus dem wissenschaftlichen Bereich.

Die Sun Java Application Server Platform Edition 8 ist die erste vollständig kompatible Imp-

lementierung der J2EE 1.4 Plattform. Sie unterstützt zwei neue Technologien für die Ent-

wicklung der Web-Schicht von auf der J2EE-Technologie basierenden Anwendungen:

JavaServer Faces42, welche den Aufbau von Benutzerschnittstellen in Web-Applikationen

vereinfachen, und die JavaServer Pages (JSP) Standard Tag Library (JSTL)43, welche Basis-

funktionalitä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:44

40 World Wide Web Consortium (W3C): SOAP 1.2 Specification, http://www.w3.org/TR/soap12-part1, 2003. 41 World Wide Web Consortium (W3C): Web Services Description Language (WSDL) 1.1,

http://www.w3.org/TR/wsdl, 2001. 42 Sun Microsystems: JavaServer Faces Technology, http://java.sun.com/javaee/javaserverfaces, 2003. 43 Sun Microsystems: JavaServer Pages Standard Tag Library, http://java.sun.com/products/jsp/jstl, 2003. 44 Sun Microsystems: J2EE v1.4 Documentation, http://java.sun.com/j2ee/1.4/docs/, 2004; Ramsey, L.: Java

System Application Server Platform Edition 8, http://xml.coverpages.org/SunJavaSAServerJ2EE14.html, 2004.


• Vollständige Übereinstimmung mit dem J2EE-Standard: Web Services Interoperabili-

tät ist gewährleistet durch die Unterstützung des WS-I45 Basisprofils.

• Einen hoch-performanten Java Message Service (JMS)-Provider: für das Anbieten ge-

schä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 NetBeans47, zu deployen.

45 Web Services Interoperability (WS-I): http://www.ws-i.org, 2002-2006. 46 Sun Microsystems: Web Service API Specifications,

http://java.sun.com/webservices/reference/api/index.html, 2002-2006. 47 NetBeans: http://www.netbeans.org, 2006.


4 Zentrale Koordinationskomponente

4.1 Aufbau und Architektur

Die Zentrale Koordinationskomponente ist der Hauptbestandteil dieser Arbeit. Wie Middle-

ware 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 Appli-

kationsserver 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 Koor-

dinationskomponente, deren Aufbau und Architektur in Abbildung 7 verdeutlicht wird, be-

steht 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.


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.

4.2.1 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.


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

4.2.2 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 Datenhal-

tungsobjekt vom Typ ADocument. Dieses wird dann zur weiteren Verarbeitung als Nach-

richt auf eine Warteschlange (Message-Queue) vom Typ Topic (siehe Kapitel 4.3.1) gelegt.


Durch dieses Vorgehen muss der Client nicht auf das annotierte Dokument warten, sondern

kann sogleich ein weiteres Dokument zum Framework versenden oder andere Methoden auf-

rufen.

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 überge-

ben. 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 angege-

benen 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

4.3.1 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 Nachrich-

ten (Senden und Empfangen) zwischen unterschiedlichen Clients, die in der Programmier-

sprache 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, http://java.sun.com/products/jms/docs.html, 2002.


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 Unter-

schied zwischen denen ist der folgende: bei einer Queue werden alle Nachrichten vom Ab-

nehmer (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.

4.3.2 AMessageControllerBean

Das AMessageControllerBean ist ein Message-Driven Bean, das die Verteilung der

einzelnen Dokumente an die Annotationsserver bewerkstelligt. Das Bean implementiert hier-

bei die von der J2EE-Spezifikation geforderte Methode onMessage().

Diese Methode wird automatisch aufgerufen, falls eine Nachricht auf die Warteschlange ge-

legt wurde. Das in der Nachricht gespeicherte Objekt vom Typ ADocument wird dabei aus-

gelesen. 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 ausge-

wä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.


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 Back-

endsysteme, genauer der Annotationsserver, verantwortlich ist. Die Schnittstelle

AServerControllerIF definiert als Web Service Endpoint Interface des Beans die Me-

thoden, die aus der Clientsicht, in diesem Falle Annotationsserver-Sicht, aufrufbar sind. Diese

Methoden werden durch das AServerControllerBean implementiert.

4.4.1 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.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


4.4.2 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 Parame-

tern 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 Annotationsser-

ver 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 Annotations-

server 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.


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.

4.5.1 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 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


4.5.2 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 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)


public AServerData findByServer(String p_server, int p_port)


}

Quelltext 6 : AServerDataHome

4.5.3 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:


• findByPrimaryKey()

• findByAnnotationTyp()

• findByServer().

Für jede dieser Methoden implementiert das AServerDataBean die entsprechenden Me-

thoden mit dem Präfix ejbFind. Beispielsweise wird die zu findByServer() korres-

pondierende 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 je-

doch berücksichtigt werden, dass der Client lediglich die Methode findByPrimaryKey()

der Home-Schnittstelle ausführt und der EJB-Container die entsprechende Methode

ejbFindByPrimaryKey().


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 ge-

trennt 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 re-

lationalen Datenbank gespeichert. Die Datenbanktabelle annotations wurde mit der in

Quelltext 8 veranschaulichten SQL-Anweisung erzeugt.


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.

4.6.1 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.


package de.mpg.mpisb.aframework.ejb.adocumentdata;


import javax.ejb.EJBObject;

public interface ADocumentData extends EJBObject {

public String getProjectId()

throws RemoteException;

public String getName()


public String getSourceDocument()


public String getSourceAnnotations()


public String getResultDocument()


public String getResultAnnotations()


public String getAnnotationTyp()


}

Quelltext 9 : ADocumentData

4.6.2 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.


package de.mpg.mpisb.aframework.ejb.adocumentdata;


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)


public ADocumentData findByName(String p_projectId, String p_name)


}

Quelltext 10 : ADocumentDataHome

4.6.3 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-Anwei-

sung die mit den Parametern übergebenen Daten in die Datenbank ein. Der Aufruf wird er-

folgreich 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-


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);


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 SQL-Anweisung ejbCreate() INSERT ejbFindByPrimaryKey() SELECT ejbFindByName() SELECT ejbLoad() SELECT ejbRemove() DELETE ejbStore() 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.


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 Daten-

bank. Als Datenbankserver wird MySql49 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 aus-

gewählt werden und ihr kann eine virtuelle Datenbank zugeordnet werden. Dabei ist eine vir-

tuelle 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: http://www.mysql.com, 2006.


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-Applikati-

onsserver mitgelieferte Datenbank Pointbase50 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 zuge-

wiesen. Nach diesem Vorgehen konnte die MySql-Datenbank direkt eingesetzt werden.

50 Pointbase: http://www.pointbase.com, 2006.


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.


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.


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();


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-Funktionali-

täten aufgerufen werden. Zu diesem Zweck bietet die Benutzeroberfläche zwei Registerkar-

ten: für das Senden und für das Empfangen von Dokumenten (siehe Abbildung 9). Die Doku-

mente können mit Hilfe eines Datei-Auswahl-Dialogs bezüglich ihrer Projekt-Id zusammen-

gestellt werden. Über die Registerkarte „Senden“ können die Dokumente an das Framework

gesendet werden, während über die Registerkarte „Empfangen“ die gesendeten Projekte aus-

gewählt und empfangen werden können. Dabei werden die Dateien in das Verzeichnis abge-

speichert, das im Konfigurationsdialog eingestellt ist (siehe Abbildung 8).


Die Benutzeroberfläche wurde mit eigenen Modifikationen auf Basis der Bibliotheken

jlooks und jforms51 erstellt.

Abbildung 9 : Benutzeroberfläche AClient

51 JGOODIES Java User Interface Design: http://www.jgoodies.com, 2003-2006.

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 Bei-

spiel in Kapitel 5 implementiert wurde, eine Projekt-Id und eine Auflistung der vom Frame-

work 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 sen-

det 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-Verbin-

dung aufgebaut werden. Über diese Verbindung wird, mit dem in Abschnitt 4.3.2 beschriebe-

nen 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.

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.

7 Evaluation 42

7 Evaluation

Um die Leistung des Frameworks beurteilen zu können, wurde das Framework mitsamt ange-

schlossenen Client und Annotationsservern getestet. Im folgenden Kapitel wird der Ver-

suchsaufbau 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 Perso-

nal 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ößenklas-

sen 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.

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 An-

notationsservern 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 Zeitunter-

schied ist durch das höhere Datenaufkommen des Ergebnis-Arrays der Methode

getDocument() (siehe Abschnitt 4.2.2) zu erklären.

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

1 1508 1399 7712 2 763 708 2082 3 501 478 1688 4 388 378 954 8 279 460 624

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 Korpus-

größe von 25 Dokumenten und acht Annotationsservern als am praktikabelsten erwiesen.

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 bewerten52. 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.


8 Zusammenfassung und Ausblick

Die Bereitstellung von Ontologien im World Wide Web wird durch das Annotieren von Do-

kumenten durch NLP-Software-Werkzeuge wie ANNIE oder Minorthird ermöglicht. Diese

Werkzeuge sind allerdings ausschließlich als Einzelplatzlösungen konzipiert und sind dadurch

nicht in der Lage, die große Anzahl zu annotierender Dokumente webbasiert zu unterstützen.

Dies ist jedoch einer der wichtigsten Schritte in der Entwicklung zum Semantischen Web.

Dafür werden flexible und skalierbare Lösungen (Frameworks) benötigt, die die enorme Re-

chenlast entsprechend verteilen können und unterschiedlichen Annotationstools anbinden

können.

Im Mittelpunkt dieser Arbeit steht der Architekturentwurf und Implementierung eines Fra-

meworks auf J2EE-Basis, das die Integration unterschiedlicher Annotationstools ermöglicht.

Dazu wurde im ersten Teil der Arbeit das Umfeld des Frameworks erläutert und verschiedene

Umsetzungsalternativen bewertet. Als Architekturmodell wurde die J2EE-Spezifikation

wegen ihrer zahlreichen Vorteile und insbesondere ihrer Plattformunabhängigkeit gewählt.

Anschließend wurden die verwendeten Technologien (J2EE, Enterprise Java Beans, Web

Services) beschrieben. Auf Basis dieser Technologien wurden die Hauptbestandteile dieser

Arbeit und ihre Funktionsweisen dargestellt: die Zentrale Koordinationskomponente, ihre

Teilkomponenten sowie die Beispiel-Implementierung eines Framework-Clients. Des

Weiteren wurde die Kommunikation und das Zusammenspiel zwischen der Zentralen

Koordinationskomponente, den Clients und den Annotationsservern vorgestellt.

Die durchgeführten Lastentests haben die erwünschten Ergebnisse bezüglich der Rechenlast-

verteilung bestätigt. Das implementierte Framework ist in der Lage die verteilte Annotation

von einer großen Anzahl von Dokumenten zu unterstützen und dabei heterogene Annotati-

onstools zu integrieren. Die Performance der Gesamtlösung ist als gut zu bewerten. Jedoch

hängt das Ergebnis stark vom eingesetzten Annotationswerkzeug ab. Zusätzlich ist der

Zusammenhang zwischen Korpusgröße und Anzahl der verwendeten Annotationsserver zu

berücksichtigen.

Basierend auf dieser Arbeit können zukünftige Erweiterungen entwickelt werden. Zurzeit

werden die annotierten Dokumente per Zufall in der Gleichverteilung zu den Annota-

tionsservern gesendet. Das führt dazu, dass es eine gewisse Zeit in Anspruch nimmt bis der


Annotationsvorgang gestartet werden kann. Aus diesem Grund wäre eine denkbare Erweite-

rung des Frameworks, die Dokumente nicht gleichverteilt, sondern nach der eingestellten

Korpusgröße zu priorisieren. Dazu müsste eine Funktionalität den Annotationsservern zur

Verfügung gestellt werden, mit Hilfe derer sie ihre Auslastung dem Framework mitteilen

können (Rückkopplungskanal). Das Framework müsste dann bestimmte Ausweichstrategien

umsetzen, um eine bessere Auslastung der Annotationsserver zu gewährleisten und dadurch

eine weitere Performance-Verbesserung zu ermöglichen.

A Installation 48

A Installation

Die folgende Installationsanweisung bezieht sich auf die Systemspezifikationen des Ver-

suchsaufbaus (siehe Abschnitt 7.1) und hat als Ergebnis ein lauffähiges System zum Testen

des Versuchsaufbaus. Die Anleitung enthält somit auch die Installationsanweisung der An-

notationsserver.53

Für die Installation auf anderen Systemen ist insbesondere auf die entsprechende Anpassung

der build-Skripte zu achten.

Alle Komponenten des Frameworks liegen in kompilierter Form vor. Ist eine Neukompilation

erwünscht, so kann dies, ohne Anpassung der build-Dateien, nur mit einer vollständigen

J2SE- und J2EE-Installation erfolgen. Um zu Kompilieren gehen Sie in das entsprechende

Verzeichnis der Komponente (z.B.: server\AServer) und rufen Sie dort asant build

auf. Um nach einem Neukompilieren von AFrameWork die entsprechende EAR-Datei zu

aktualisieren, müssen die Dateien mit dem Deploytool aktualisiert und die Komponente auf

dem J2EE-Server redeployt werden.

A.1 Framework

Für die Installation und Konfiguration des Frameworks ist es wichtig, folgende Schritte in der

angegebenen Reihenfolge auszuführen:

1. Installieren Sie das Java SDK 1.4.2.10, welches sich auf der Installations-CD im

Verzeichnis install\j2se befindet, da der Sun Applikationsserver nur mit dieser

Version ausgeführt werden kann.

2. Installieren Sie den Sun Applikationsserver, welcher sich auf der Installations-CD

imVerzeichnis install\j2ee befindet und folgen Sie den Anweisungen auf dem

Bildschirm.



A Installation 49

3. Installieren Sie den MySql-Datenbankserver in der Version 4.1 aus dem Verzeichnis

install\database. Es wird empfohlen, die Programme im Verzeichnis

install\database\tools zu installieren.

4. Installieren Sie die Datenbank auf dem Datenbankserver, indem Sie die SQL-Anweisun-

gen in install\database\dbannotar.sql auf dem Datenbankserver ausführen.

5. Installieren Sie den Datenbanktreiber von MySql für den Applikationsserver, indem Sie

die Datei mysql-connector-java-3.1.8a.zip im Verzeichnis

install\database entpacken und die darin enthaltene Datei

mysql-connector-java-3.1.8-bin.jar Datei in das lib\endorsed

Verzeichnis des Applikationsservers kopieren.

Für die Konfiguration des Frameworks gehen Sie nach folgenden Schritten vor:

6. Starten Sie den Applikationsserver mit Start>Programme>Sun

Microsystems>j2ee 1.4sdk>start default domain.

7. Starten Sie die Adminoberfläche mit Start>Programme>Sun

Microsystems>j2ee 1.4sdk>admin console und loggen Sie sich als Appli-

kationsserver-Administrator ein.

8. Geben Sie unter Applications Server>JVM Settings>Path Settings bei

Classpath Suffix den Pfad zum dem in Punkt 5 installierten Datenbanktreiber an (z.B.:

C:\Sun\AppServer\lib\endorsed\mysql-connector-java-3.1.8-

bin.jar).

9. Erstellen Sie unter JDBC>Connection Pools eine neue Connection mit dem Namen

MySqlPool und Resource Type javax.sql.DataSource. Klicken Sie auf „Next“

und geben Sie unter Data Source Class Name

com.mysql.jdbc.jdbc2.optional.MysqlDataSource ein.

Klicken Sie nun wieder auf „Next“. Löschen Sie unter „Properties“ alle Eigenschaften,

fügen Sie dafür die folgende Eigenschaften ein und beenden Sie die Eingabe mit „Finish“:

Name Wert user <Benutzername Datenbank> password <Kennwort Datenbank> serverName localhost port 3306 databaseName annotator

A Installation 50

10. Erstellen Sie nun unter JDBC>Resources eine neue JDBC-Resource mit JNDI-Name

jdbc/dbannotator und wählen Sie als Pool-Namen MySqlPool aus.

11. Erstellen Sie unter Java Message Service>Connection Factories zweimal

eine JMS Connection Factory: eine mit dem JNDI-Namen

jms/DurableTopicConnectionFactory und eine mit dem JNDI-Namen

jms/TopicConnectionFactory. Bei beiden muss als Typ

javax.jms.TopicConnectionFactory ausgewählt werden. Die

jms/DurableTopicConnectionFactory bekommt unter „Eigenschaften“ als

Namen ClientId und als Wert MyId eingetragen.

12. Unter Java Message Service>Destination Resources erstellen Sie eine

neue JMS Destination Resource mit JNDI-Namen jms/Topic und Typ

javax.jms.Topic. Fügen Sie unter „Eigenschaften“ als Namen Name und als Wert

PhysicalTopic ein.

13. Fügen Sie unter Java Message Service>Physical Destinations eine

Physical Destination PhysicalTopic mit dem Typ topic ein.

14. Stoppen und starten Sie den Applikationsserver dann wieder.

Wir kommen nun zum Deployen des Frameworks in den Applikationsserver:

1. Kopieren Sie das Verzeichnis framework auf den Rechner.

2. Starten Sie das Deploytool unter Start>Programme>Sun Microsystems>j2ee

1.4sdk>Deploytool.

3. Öffnen Sie mit dem Deploytool die Datei

framework\AFrameWork\AFrameWorkApp.ear und geben Sie der Applikation

den Namen AFrameWorkApp.

4. Deployen Sie nun diese Applikation.

A.2 Client

Um den Client zu installieren, kopieren Sie das Verzeichnis client auf den Rechner und

ändern Sie die Datei build.properties, die sich im Verzeichnis client\common

befindet, wie folgt:

A Installation 51

1. j2ee.home muss auf den Pfad zum Applikationsserver angepasst werden.

2. aclient.home muss auf das Verzeichnis client\AClient gesetzt werden.

Zum Starten des Clients öffnen Sie die Eingabeaufforderung und wechseln Sie zum Ver-

zeichnis client\AClient. Rufen Sie dort asant run auf. Ist der Client gestartet, soll-

ten Sie die Konfiguration mit Hilfe des Konfigurationsdialogs ändern.

Dieses Vorgehen funktioniert nur, wenn der Client und der Applikationsserver auf dem selben

Rechner installiert sind.

Sollte der Client auf einem eigenen Rechner installiert werden, so ist das J2SE SDK zu in-

stallieren und die Bibliotheken der J2EE auf den Clientrechner zu kopieren. Diese Bibliothe-

ken und die Bibliothek client\AClient\dist\client.jar müssen im classpath

für den Client angegeben sein. Der Client wird dann mit dem folgenden Befehl gestartet:

java –classpath <HIER CLASSPATH> de.mpg.mpisb.aclient.AClient.

A.3 Annotationsserver54

Um den Annotationsserver zu installieren, gehen Sie wie folgt vor:

1. Kopieren Sie das Verzeichnis server von der CD auf den Rechner.

2. Installieren Sie GATE aus dem server\gate Verzeichnis. Minorthird wurde schon

beim Kopieren im Schritt 1 installiert.

3. Im Startskript start.sh müssen die Variablen MINORTHIRD, PATH und JAVA_HOME

angepasst werden. Des Weiteren muss beim java-Aufruf die Eigenschaft gate.home

angepasst werden.

Zum Starten führen Sie das Startskript im Verzeichnis server\AServer aus und passen

wiederum die Konfiguration mit Hilfe des Konfigurationsdialogs an.



B Abbildungsverzeichnis 52

B Abbildungsverzeichnis

Abbildung 1 : Überblick Framework ......................................................................................... 6

Abbildung 2 : Mehrschichtige Anwendungen ........................................................................... 8

Abbildung 3 : Lebenszyklus eines Stateless Session Beans .................................................... 11

Abbildung 4 : Lebenszyklus eines Stateful Session Beans ...................................................... 11

Abbildung 5 : Lebenszyklus eines Entity Beans...................................................................... 12

Abbildung 6 : Zusammenhang zwischen UDDI, SOAP und WSDL....................................... 15

Abbildung 7 : Framework-Architektur .................................................................................... 20

Abbildung 8 : Dialog Konfiguration ........................................................................................ 37

Abbildung 9 : Benutzeroberfläche AClient.............................................................................. 39

Abbildung 10 : Dokumentenverteilung.................................................................................... 43

Abbildung 11 : Annotationszeiten im Vergleich...................................................................... 45

C Tabellenverzeichnis 53

C Tabellenverzeichnis

Tabelle 1 : SQL-Anweisungen im AServerDataBean.............................................................. 29

Tabelle 2 : SQL-Anweisungen im ADocumentDataBean ...................................................... 33

Tabelle 3 : Technische Spezifikation Versuchsaufbau ............................................................ 42

Tabelle 4 : Annotationszeiten................................................................................................... 44

D Quelltextverzeichnis 54

D Quelltextverzeichnis

Quelltext 1 : AClientControllerIF ............................................................................................ 21

Quelltext 2 : Protokoll zum Senden von Dokumenten............................................................. 24

Quelltext 3 : AServerControllerIF............................................................................................ 24

Quelltext 4 : SQL-Anweisung zum Anlegen der Tabelle annotationserver............................. 26

Quelltext 5 : AServerData ........................................................................................................ 26

Quelltext 6 : AServerDataHome .............................................................................................. 27

Quelltext 7 : AServerDataBean.ejbFindByPrimaryKey()........................................................ 28

Quelltext 8 : SQL-Anweisung zum Anlegen der Tabelle annotations..................................... 30

Quelltext 9 : ADocumentData.................................................................................................. 31

Quelltext 10 : ADocumentDataHome ..................................................................................... 32

Quelltext 11 : ADocumentDataBean.ejbFindByName() ......................................................... 33

Quelltext 12 : Dynamic Proxy Generierung Teil 1 .................................................................. 36

Quelltext 13 : Dynamic Proxy Generierung Teil 2 .................................................................. 37

Quelltext 14 : Clientaufruf von getProjectId() ........................................................................ 38


E Literaturverzeichnis

4. Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004.

5. Backschat, M.: Enterprise Java Beans, Spektrum Akademischer Verlag, 2002.

6. Berners-Lee, T.; Hendler, J.; Lassila, O.: The Semantic Web, Scientific American, Mai

2001.

7. Clabby, J.: Web Services Explained: Solutions and Applications for the Real World,

Prentice Hall, 2002.

8. Cohen, W.: Minorthird: Methods for Identifying Names and Ontological Relations in Text

using Heuristics for Inducing Regularities from Data, http://minorthird.sourceforge.net,

2004.

9. Cunningham, H. et al.: Developing Language Processing Components with GATE (a

User’s Guide), University of Sheffield, 2001-2006.

10. Fuchs, D.: Verteilte Annotation von Dokumenten – Entwurf und Implementierung eines

modularen Annotationsservers auf Basis von NLP-Technologien, Universität des

Saarlandes, 2006.

11. Hein, G.; Lewis, J.: Web Services Basics: Separating Hype and Reality, in: Burton Group,

Network Strategy, 2002.

12. JGOODIES Java User Interface Design: http://www.jgoodies.com, 2003-2006.

13. Kochmer, C.; Frandsen, E.: JSP and XML: Integrating XML and Web Services in Your

JSP Application, Addison-Wesley, 2002.

14. Microsoft Corporation: .NET Framework 1.0,

http://msdn.microsoft.com/netframework/previous/v1.0/default.aspx, 2002.

15. Microsoft Corporation: Common Language Infrastructure Standards,

http://msdn.microsoft.com/netframework/ecma/, 2002-2006.

16. MySql: http://www.mysql.com, 2006.

17. NetBeans: http://www.netbeans.org, 2006.

18. OASIS Open: UDDI Version 2 Specifications, http://www.oasis-

open.org/committees/uddi-spec/doc/tcspecs.htm, 2002.

19. Pointbase: http://www.pointbase.com, 2006.

20. Ramsey, L.: Java System Application Server Platform Edition 8,

http://xml.coverpages.org/SunJavaSAServerJ2EE14.html, 2004.

21. Schmelzer, R. et al.: XML and Web Services Unleashed, Sams Publishing, 2002.


22. Sun Microsystems: Java API for XML-Based RPC,

http://java.sun.com/webservices/jaxrpc, 2002.

23. Sun Microsystems: Java Naming and Directory Interface (JNDI),

http://java.sun.com/products/jndi/, 2002.

24. Sun Microsystems: Java Message Service, http://java.sun.com/products/jms/docs.html,

2002.

25. Sun Microsystems: Sun Open Net Environment (Sun ONE), 2002.

26. Sun Microsystems: Web Service API Specifications,

http://java.sun.com/webservices/reference/api/index.html, 2002-2006.

27. Sun Microsystems: JavaServer Faces Technology,

http://java.sun.com/javaee/javaserverfaces, 2003.

28. Sun Microsystems: JavaServer Pages Standard Tag Library,

http://java.sun.com/products/jsp/jstl, 2003.

29. Sun Microsystems: Enterprise JavaBeans Specification 2.1,

http://java.sun.com/products/ejb/docs.html, 2004.

30. Sun Microsystems: J2EE Platform Specification 1.4, http://java.sun.com/j2ee/j2ee-1_4-fr-

spec.pdf, 2004.

31. Sun Microsystems: J2EE v1.4 Documentation, http://java.sun.com/j2ee/1.4/docs/, 2004.

32. Thielscher, J.: J2EE und .NET zwei konkurrierende Standards?, Computer Zeitung, Mai

2002.

33. Web Services Interoperability (WS-I): http://www.ws-i.org, 2002-2006.

34. World Wide Web Consortium (W3C): Web Services Description Language (WSDL) 1.1,

http://www.w3.org/TR/wsdl, 2001.

35. World Wide Web Consortium (W3C): SOAP 1.2 Specification,

http://www.w3.org/TR/soap12-part1, 2003.

36. Younis, S.: J2EE vs. .NET An Executive Look, 2003.

verteilte annotation von dokumenten – architekturentwurf ... · 5 fuchs, d.: verteilte annotation...

Documents