Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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 7
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.
3 Verwendete Technologien 8
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.
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 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.
3 Verwendete Technologien 10
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.
3 Verwendete Technologien 11
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 Verwendete Technologien 12
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 Verwendete Technologien 13
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.
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 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.
3 Verwendete Technologien 15
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 Verwendete Technologien 16
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.
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 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.
3 Verwendete Technologien 18
• 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 19
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.
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.
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.
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
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.
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 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.
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 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.
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 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.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
4 Zentrale Koordinationskomponente 25
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.
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.
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 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
4 Zentrale Koordinationskomponente 27
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 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
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:
4 Zentrale Koordinationskomponente 28
• 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().
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 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.
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.
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.
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
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.
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
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-
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 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.
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 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.
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-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 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.
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.
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-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).
5 Beispiel-Implementierung eines Clients 39
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 46
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
8 Zusammenfassung und Ausblick 47
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.
53 Fuchs, D.: Verteilte Annotation von Dokumenten – Entwurf und Implementierung eines modularen
Annotationsservers auf Basis von NLP-Technologien, Universität des Saarlandes, 2006.
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.
54 Fuchs, D.: Verteilte Annotation von Dokumenten – Entwurf und Implementierung eines modularen
Annotationsservers auf Basis von NLP-Technologien, Universität des Saarlandes, 2006.
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 55
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.
E Literaturverzeichnis 56
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.