Verteilte Annotation von Dokumenten – Architekturentwurf und

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
2
Einleitung
1.1
Motivation .................................................................................................................. 1
1.2
Zielsetzung und Aufbau der Arbeit............................................................................ 1
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
3
1
Bestandteile ................................................................................................................ 5
Verwendete Technologien
3.1
7
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
4
Zentrale Koordinationskomponente
II
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
8
7.1
Versuchsaufbau ........................................................................................................ 42
7.2
Lastentest.................................................................................................................. 43
Zusammenfassung und Ausblick
46
Inhaltsverzeichnis
III
A
48
Installation
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änglichkeiten beseitigt.
1.2 Zielsetzung und Aufbau der Arbeit
Ziel dieser Arbeit ist es, ein webbasiertes Framework für die verteile Annotation von Dokumenten zu entwerfen und zu implementieren. Das Framework soll insbesondere die Integration von Annotationstools wie ANNIE und Minorthird als Backendsysteme leisten. Dabei
stellt sich die Frage nach dem Senden, Empfangen und Verteilen einer großen Anzahl von
Dokumenten von den Clients an die Backendsysteme.
1
Berners-Lee, T.; Hendler, J.; Lassila, O.: The Semantic Web, Scientific American, Mai 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 Komponenten näher erläutert, ihre Funktion in der Gesamtarchitektur und ihre Bedeutung für das
Empfangen, Senden und Verteilen von Dokumenten dargestellt.
In Kapitel 5 wird auf die Beispiel-Implementierung eines Clients eingegangen, welcher über
Web Services mit dem Framework interagiert.
Auf den Kommunikationsablauf zwischen Zentraler Koordinationskomponente, den Clients
und den 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ährleisten, muss das Framework einige Kriterien an die zu verwendende Plattform stellen. Hierbei können folgende Kriterien von Anforderungen abgeleitet werden:
•
Integration bestehender Systeme
Selten wird eine neue Anwendung ohne Bezug auf bestehende Anwendungen
entwickelt. Meist ist diese mit einer bereits bestehenden heterogenen IT-Landschaft zu
verbinden. Dazu muss die Plattform Möglichkeiten der Integration bieten.
•
Skalierbarkeit
Gerade bei Anwendungen im weltweiten Netz ist es nicht möglich, die Last vorher zu
sagen, die die Anwendung auszuhalten hat. Daher ist es wichtig, dass die Lastenverteilung unabhängig von der Implementierung der Anwendung konfiguriert werden
kann.
•
Flexibilität
Bei einer Anwendung sollte die Möglichkeit bestehen, die Laufzeit- und Entwicklungsumgebung nach den Anforderungen der Anwendung zusammen zu stellen.
Für die Implementierung des Frameworks kommen grundsätzlich zwei Plattformen in Betracht: .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 Klassenbibliotheken und aus angeschlossenen Diensten, die gemeinsam eine Basis für Eigenentwicklungen
bieten.
Die Programme liegen ähnlich wie in Java in einem Zwischencode vor und benötigen daher
die .NET-Laufzeitumgebung. Was .NET von anderen auf Zwischencode basierenden Laufzeitumgebungen signifikant unterscheidet, ist das berücksichtigte Nebeneinander mehrerer
Programmiersprachen.
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 mehrschichtiges verteiltes Applikationsmodell, wieder verwendbare Komponenten, ein vereinheitlichtes Sicherheitsmodell, flexible Transaktionskontrolle und Web Services-Unterstützung
durch den Austausch von integrierten Daten über XML-basierte offene Standards und Protokolle.9
2.2.3 Beurteilung
J2EE und .NET sind zwei ähnliche Ansätze für die Entwicklung von Anwendungs-Frameworks.
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 unterschiedliche Services wie Objekt-Persistenz, Komponenten-Management, Transaktionen, Web
Services, asynchrone Kommunikation und Messaging.10
J2EE und .NET verwenden beide die Virtual Machine (VM)-Architektur. Die Anwendungsentwicklungs-Werkzeuge erzeugen Zwischencode anstatt plattform-spezifischen Binärcode.
Dies bedeutet, dass die VM den Code in Echtzeit interpretiert oder die so genannte Just-InTime (JIT)-Übersetzung vornimmt.
Beide Plattformen basieren auf mehrschichtige Architekturen.11 Für die Erstellung verteilter
Anwendungen stehen die so genannten EJB-Container in J2EE bzw. die .NET Managed
Objects in .NET zur Verfügung. In beiden Fällen wird die Verwaltung und Kontrolle der verteilten Objekte automatisch übernommen, ohne dass dies explizit implementiert werden muss.
Die Attraktivität von J2EE wird insbesondere durch die Portabilität über unterschiedlichste
Plattformen gestützt. J2EE ist ein offener Standard und eine Spezifikation, die unabhängig
von der jeweils verwendeten Plattform ist. Im Falle von .NET dagegen, handelt es sich um ein
konkretes Produkt und damit um einen einzigen Hersteller.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 FrameworkClients 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 DatenbankSchnittstelle 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 aufgeteilt. Die unterschiedlichen Anwendungskomponenten, aus denen die J2EE-Applikation besteht, können auf verschiedenen Rechnern installiert sein. Die Aufteilung erfolgt in
Abhängigkeit von der Schicht in der mehrschichtigen J2EE-Umgebung, der die Anwendungskomponente zugeordnet ist. Abbildung 2 zeigt zwei mehrschichtige J2EEApplikationen, die aus den im Folgenden beschriebenen Schichten bestehen:13
•
Client-Schicht-Komponenten werden auf Client-Rechnern ausgeführt.
•
Web-Schicht-Komponenten werden auf dem J2EE-Server ausgeführt.
•
Business-Schicht-Komponenten werden ebenfalls auf dem J2EE-Server ausgeführt.
•
Enterprise Information System (EIS)-Schicht-Software wird auf dem EIS-Server ausgeführt.
13
Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 2.
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 Unterschied zwischen J2EE-Komponenten und „Standard“-Java-Klassen ist, dass J2EE-Komponenten in einer J2EE-Applikation eingebunden, wohlgeformt und im Einklang mit der J2EESpezifikation sind und von einem J2EE-Server ausgeführt werden.
Da das Framework keine Web-Komponenten besitzt und mit Hilfe von Web Services kommuniziert, werden im Folgenden die Enterprise Java Beans und Web Services näher erläutert.
3.2 Enterprise Java Beans
„Enterprise Java Beans sind nach der EJB-Spezifikation entworfene, serverseitige SoftwareKomponenten, die in der vom EJB-Container zur Verfügung gestellten Umgebung ablaufen.
Sie realisieren die Geschäftslogik, auf die Anwendungen (als Clients bezeichnet) zugreifen.“17
Der EJB-Container stellt die Laufzeitumgebung für die Enterprise Java Beans im J2EE-Server
zur Verfügung und erfüllt hierbei verschiedene Dienste:
•
Verwaltet den Lebenszyklus der Enterprise Java Beans.
•
Stellt die Persistenz für Entity Beans (siehe Abschnitt 3.2.2) bereit.
•
Regelt den Sicherheitsmechanismus und damit den Zugriff auf die Enterprise Java
Beans.
•
Stellt Dienste bereit, um mit dem Java Naming and Directory Interface (JNDI)18 entfernte Objekte über ihren Namen zu finden.
•
Koordiniert verteilte Transaktionen.
•
Übernimmt die Remote-Kommunikation mit dem Client.
Damit der EJB-Container diese Dienste erfüllen kann, benötigt er die Kontrolle über die Objekte der Enterprise Java Beans. Dies wird realisiert, indem der Client mit den Beans über
17
Backschat, M.: Enterprise Java Beans, Spektrum Akademischer Verlag, 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 Methoden der Beans kommunizieren. Dazu besitzt jedes Enterprise Java Bean zwei zu implementierende Schnittstellen, eine Ausnahme hiervon bilden die Message-Driven Beans (siehe
Abschnitt 3.2.3) und Stateless Session Beans für Web Services (siehe Abschnitt 3.3):
•
Das Home Interface stellt Methoden zum Erstellen und Finden der Bean-Objekte zur
Verfügung.
•
Das Remote Interface stellt Methoden der Anwendungslogik für den Client bereit.
Die EJB-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
20
Sun Microsystems: Enterprise JavaBeans Specification 2.1, http://java.sun.com/products/ejb/docs.html, 2004.
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 Warenkorbes. Der Nutzer wählt eine Ware aus und legt diese in den Warenkorb. Hierbei muss sich das
Session Bean natürlich den Zustand des Warenkorbes merken. Somit ist der Lebenszyklus eines Stateful Session Beans komplizierter, da der EJB-Container beim nächsten Zugriff des
Clients das richtige Bean übergeben muss.22
Abbildung 4 : Lebenszyklus eines Stateful Session 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 reibungslosen Ablauf dieser Zugriffe zu gewährleisten, ist es wichtig, dass die Entity Beans mit einem
Transaktionsmechanismus ausgestattet sind. Dieser Mechanismus wird wiederum von dem
EJB-Container bereitgestellt. Damit die Entity Beans von den Clients auffindbar sind, besitzt
jedes Bean eine eindeutige Identifizierung. Der Lebenszyklus eines Entity Beans ist in
Abbildung 5 dargestellt.
Abbildung 5 : Lebenszyklus eines Entity 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 ähnlichen 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 verstanden, die dynamisch über Standard-Internettechnologien andere Komponenten im Web ausfindig machen und benutzen können, um so eine komplette, umfangreiche Aufgabe zu erfüllen.28 Im Gegensatz zu Anwendungen, die fest auf einem Rechner oder anderen ClientGeräten installiert werden, repräsentieren Web Services allgemein einen Geschäftsvorgang
oder eine Systemfunktionalität, auf die über das Web zugegriffen werden kann. Konsumenten
von Web Services können Personen sein, die auf den Service über einen Browser auf dem
Rechner oder einem mobilen Endgerät zugreifen können, es können aber auch Anwendungsprogramme oder andere Web Services sein.
26
Sun Microsystems: Java Message Service, 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 beschrieben und Nachrichten kodiert werden. Wichtig ist dabei vor allem, dass es bei XML-basierten
Web Services keine Rolle spielt mit welcher Technologie sie erstellt wurden. Sie kommunizieren über Standard-Internetprotokolle (zum Beispiel TCP/IP, HTTP, HTTPS, SMTP) mit
Hilfe ihrer XML-Schnittstellen und XML-Nachrichten, die alle Anwendungen verstehen
können.30
Im Gegensatz zum monolitischen Implementierungsstil früherer Web-Applikationen basieren
Web Services auf einer Reihe zusammenhängender Technologien: hierzu gehört insbesondere
das XML-basierte Simple Object Access Protocol (SOAP)31, welches für die Kommunikation
zwischen Dienstnutzer und Dienstanbieter zum Einsatz kommt. Mittels der Web Service
Description Language (WSDL)32 lassen sich Web Services in einer einheitlichen, ebenfalls
auf XML-basierten Sprache, beschreiben, die als Grundlage für die Registrierung von Web
Services mittels der Universal Description, Discovery and Integration (UDDI)33 dient.
29
Sun Microsystems: Sun Open Net Environment (Sun ONE), 2002, S. 5; Kochmer, C.; Frandsen, E.: JSP and
XML: Integrating XML and Web Services in Your JSP Application, Addison-Wesley, 2002, S. 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). Anschließend kann der Dienst in einem Verzeichnis für Web Services veröffentlicht werden. Ein
solcher Verzeichnisdienst wird von Universal Description, Discovery and Integration (UDDI)
spezifiziert. Der Web Service-Nutzer kann UDDI verwenden, um nach einem bestimmten
Service zu suchen und ihn in eigene Anwendungen zu integrieren. Die eigentlichen Aufrufe
an den Web Service finden dann im Allgemeinen über das Simple Object Access Protocol
(SOAP) statt.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 EJBApplikationen 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-ServerModell eingesetzt und ermöglicht den Clients Funktionalitäten auf unterschiedlichen
Systemen auszuführen. Ein Remote Procedure Call wird in JAX-RPC durch ein XML-basiertes Protokoll wie SOAP repräsentiert. Die SOAP-Spezifikation legt die Struktur, Kodierungsregeln und Konventionen für die Darstellung sowohl der Remote Procedure Calls (Aufrufe) als auch ihrer Antworten fest. Diese Aufrufe und Antworten werden in der Form von
SOAP-Nachrichten (XML-Dateien) über HTTP transportiert. SOAP-Nachrichten sind zwar
komplex, die JAX-RPC-API verbirgt jedoch diese Komplexität: SOAP-Nachrichten müssen
nicht generiert oder analysiert werden, dieser Prozess wird vom JAX-RPC-System automatisch übernommen. Das System wandelt die API-Aufrufe in SOAP-Nachrichten und die Antworten aus SOAP-Nachrichten um.38
Die Definition einer JAX-RPC-API besteht aus zwei Teilen. Auf der Server-Seite werden die
Remote Procedures durch das Definieren von Methoden in einer Java-Schnittstelle spezifiziert. Diese Methoden werden entsprechend in Klassen implementiert. Auf der Client-Seite
erstellt das Client-Programm ein Proxy-Objekt (ein lokales Objekt, welches den Service
repräsentiert) und ruft die Methoden dieses Proxy-Objekts auf.39
Bei der Verwendung von JAX-RPC kommt für Clients und Web Services der bereits in den
Kapiteln 2.2.2 und 2.2.3 diskutierte Vorteil der Plattformunabhängigkeit der Java-Programmiersprache zum Tragen. Außerdem ist JAX-RPC nicht restriktiv: ein JAX-RPC-Client kann
mit einem Web Service kommunizieren, der nicht auf einer Java-Plattform ausgeführt wird,
36
Armstrong, E. et al.: The J2EE 1.4 Tutorial, Sun Microsystems, 2004, S. 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 Technologien 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 effektive Entwicklung und das schnelle Deployment von Anwendungen. Der Java-Applikationsserver ist lizenzfrei und kostenlos für Entwicklung und Wiederverwendung in Applikationen aus dem wissenschaftlichen Bereich.
Die Sun Java Application Server Platform Edition 8 ist die erste vollständig kompatible Implementierung der J2EE 1.4 Plattform. Sie unterstützt zwei neue Technologien für die Entwicklung der Web-Schicht von auf der J2EE-Technologie basierenden Anwendungen:
JavaServer Faces42, welche den Aufbau von Benutzerschnittstellen in Web-Applikationen
vereinfachen, und die JavaServer Pages (JSP) Standard Tag Library (JSTL)43, welche Basisfunktionalitäten für auf JSP basierenden Anwendungen bündelt. Zusätzlich zu diesen neuen
Features enthält die Applikationsserver-Lösung von Sun Microsystems eine skalierbare und
zuverlässige
J2EE-Applikationsplattform,
die
durch
die
folgenden
Eigenschaften
gekennzeichnet ist: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 Interoperabilität ist gewährleistet durch die Unterstützung des WS-I45 Basisprofils.
•
Einen hoch-performanten Java Message Service (JMS)-Provider: für das Anbieten geschäftlicher Applikationsservices und Web Services.
•
Vollständige Web Services-Infrastruktur: enthält die Java API for XML Messaging
(JAXM), Java API for XML Processing (JAXP), Java API for XML Registries
(JAXR), Java API for XML-based RPC (JAX-RPC)46, SOAP und WSDL.
•
Unterstützung
der
neuen
J2EE-Connector-Architektur:
die
bi-direktionale
Connectivity für den Zugriff auf Geschäftsapplikationen unterstützt Standard-J2EEDeployment-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 Middleware dient sie als Bindeglied zwischen den Clients und den Annotationsservern. Dabei dient
die Zentrale Koordinationskomponente zur Lasten- und Dokumentenverteilung, ist webbasiert
und ist unter Verwendung der in Kapitel 3 beschriebenen Technologien realisiert. Als Applikationsserver wird der Sun Java System Application Server Platform Edition 8 von Sun
Microsystems eingesetzt (siehe Abschnitt 3.4).
Das Framework beinhaltet somit Softwarekomponenten zur Kommunikation mit den Clients
und den Annotationsservern, zur Datenhaltung und zur Lastenverteilung. Die Zentrale Koordinationskomponente, deren Aufbau und Architektur in Abbildung 7 verdeutlicht wird, besteht aus folgenden Komponenten:
•
Das AClientControllerBean ist ein Stateless Session Bean, das als Web
Service interagiert und für die Kommunikation mit den Clients verantwortlich ist.
•
Als Message-Driven Bean verteilt das AMessageControllerBean die zu
annotierenden Dokumente an die entsprechenden Annotationsservern.
•
Eine Warteschlange (Message-Queue) vom Typ Topic, die für den asynchronen
Nachrichtenaustausch
zwischen dem AClientControllerBean und dem
AMessageControllerBean zuständig ist.
•
Das AServerControllerBean ist wiederum ein Stateless Session Bean, das als
Web Service interagiert und für die Kommunikation mit den Annotationsservern
verantwortlich ist.
•
Das AServerDataBean ist ein Entity Bean, mit dessen Hilfe die Eigenschaften
der Annotationsserver in die Datenbank gespeichert werden.
•
Für die Datenhaltung der annotierten Dokumente ist das Entity Bean
ADocumentDataBean verantwortlich.
•
Über die Datenbankschnittstelle können die Entity Beans mit der Datenbank
interagieren.
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 Datenhaltungsobjekt vom Typ ADocument. Dieses wird dann zur weiteren Verarbeitung als Nachricht auf eine Warteschlange (Message-Queue) vom Typ Topic (siehe Kapitel 4.3.1) gelegt.
4
Zentrale Koordinationskomponente
22
Durch dieses Vorgehen muss der Client nicht auf das annotierte Dokument warten, sondern
kann sogleich ein weiteres Dokument zum Framework versenden oder andere Methoden aufrufen.
Mit Hilfe der Methode getDocument() erhält der Client ein annotiertes Dokument vom
Server zurück. Als Parameter werden die Projekt-Id und der Name des Dokumentes übergeben. Diese Methode ruft dann mit den Parametern die Finder-Methoden des Entity Beans
ADocumentDataBean auf. Wird ein solches entsprechendes Entity Bean gefunden, so wird
mit dessen Remote-Methoden das Ergebnis-Array gefüllt und an den Client zurückgegeben.
Das Ergebnis-Array vom Typ String[] enthält die folgenden Informationen in der angegebenen Reihenfolge:
•
Projekt-Id
•
Name des Dokumentes
•
Originalinhalt des Dokumentes
•
Originalannotationen des Dokumentes
•
Das annotierte Dokument
•
Die gefundenen Annotationen
•
Die Art, auf die das Dokument annotiert wurde.
4.3 Message-Queue und AMessageControllerBean
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 Nachrichten (Senden und Empfangen) zwischen unterschiedlichen Clients, die in der Programmiersprache Java geschrieben sind.
Bei der Warteschlange gibt es immer einen Abnehmer, der auf Nachrichten wartet und einen
Anbieter (Provider), der diese Nachrichten bereitstellt. Dabei werden die Nachrichten in der
48
Sun Microsystems: Java Message Service, 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 Unterschied zwischen denen ist der folgende: bei einer Queue werden alle Nachrichten vom Abnehmer (in diesem Falle ein Message-Driven Bean) gelesen und konsumiert. Im Gegensatz
dazu werden bei einer Topic nur die Nachrichten gelesen, die zu einer bestimmten Kategorie
gehören. Dies wird durch eine Topic (Überschrift) erreicht, die die Nachricht enthält. In dieser
Arbeit wurde eine Warteschlange vom Typ Topic verwendet. Diese Technologie wurde
wegen ihrer Flexibilität gewählt: sie könnte die Verwendung von kategorisierten Dokumenten
bei zukünftigen Erweiterungen des implementierten Frameworks unterstützen.
4.3.2 AMessageControllerBean
Das AMessageControllerBean ist ein Message-Driven Bean, das die Verteilung der
einzelnen Dokumente an die Annotationsserver bewerkstelligt. Das Bean implementiert hierbei die von der J2EE-Spezifikation geforderte Methode onMessage().
Diese Methode wird automatisch aufgerufen, falls eine Nachricht auf die Warteschlange gelegt wurde. Das in der Nachricht gespeicherte Objekt vom Typ ADocument wird dabei ausgelesen. Mit dem in der Datenstruktur ADocument gespeicherten Annotationstyp wird nun
die Finder-Methode findByAnnotationTyp() des Entity Beans AServerDataBean
aufgerufen. Als Ergebnis erhält das AMessageControllerBean eine Auflistung der
Annotationsserver, die diesen Annotationstyp unterstützen.
Aus dieser Auflistung wird ein Annotationsserver per Zufall in der Gleichverteilung ausgewählt. Über die Remote-Methoden des Entity Beans AServerDataBean werden dann die
entsprechenden Daten zum Aufbau einer Socket-Verbindung zum Annotationsserver gelesen.
Nach dem erfolgreichen Etablieren einer Verbindung wird das zu annotierende Dokument
über ein spezielles Protokoll an den Server gesendet. Quelltext 2 verdeutlicht den Aufbau des
Protokolls.
4
Zentrale Koordinationskomponente
ANNOTATOR:PUT
24
<Project-Id> <Name des Dokumentes> <Annotationstyp>
<Inhalt des Dokumentes>
Quelltext 2 : Protokoll zum Senden von Dokumenten
4.4 AServerControllerBean
Das AServerControllerBean ist ähnlich wie das AClientControllerBean für
die Kommunikation mit dem Framework verantwortlich. Der Unterschied besteht darin, dass
das Bean, zusammen mit dem AMessageControllerBean, für die Integration der Backendsysteme,
genauer
der
Annotationsserver,
verantwortlich
ist.
Die
Schnittstelle
AServerControllerIF definiert als Web Service Endpoint Interface des Beans die Methoden, die aus der Clientsicht, in diesem Falle Annotationsserver-Sicht, aufrufbar sind. Diese
Methoden werden durch das AServerControllerBean implementiert.
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 Parametern der Methode register()erzeugt.
Die Methode unregister() wiederum meldet einen Annotationsserver vom Framework
ab. Mit den Parametern dieser Methode wird die Finder-Methode findByServer() des
Entity Beans AServerDataBean aufgerufen und das dadurch gefundene Objekt gelöscht.
Um das Ergebnis einer Annotation an das Framework zu senden, benutzt der Annotationsserver die Methode addDocument(). Beim Aufruf dieser Methode wird mit deren Parametern
wiederum die Methode create() des Entity Beans ADocumentDataBean aufgerufen
und somit ein Objekt diesen Typs erzeugt.
4.5 AServerDataBean
Das Enterprise Java Bean AServerDataBean ist ein Entity Bean, das einen Annotationsserver repräsentiert. Der Status dieses Beans ist in der Tabelle annotationserver einer
relationalen Datenbank gespeichert. Die Datenbanktabelle annotationserver wurde mit
der in Quelltext 4 dargestellten SQL-Anweisung erzeugt.
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
•
findByPrimaryKey()
•
findByAnnotationTyp()
•
findByServer().
28
Für jede dieser Methoden implementiert das AServerDataBean die entsprechenden Methoden mit dem Präfix ejbFind. Beispielsweise wird die zu findByServer() korrespondierende Methode ejbFindByServer() genannt. Quelltext 7 veranschaulicht die
Bean-Implementierung der Methode ejbFindByPrimaryKey().
public Integer ejbFindByPrimaryKey(Integer primaryKey) throws
FinderException
{
boolean result;
try {
result = selectByPrimaryKey(primaryKey);
} catch (Exception ex) {
throw new EJBException("ejbFindByPrimaryKey: " +
ex.getMessage());
}
if (result) {
return primaryKey;
} else {
throw new ObjectNotFoundException("Row for id " +
primaryKey + " not found.");
}
}
Quelltext 7 : AServerDataBean.ejbFindByPrimaryKey()
Auf dem ersten Blick scheint diese Methode inkorrekt zu sein, da sie statt eines Objekts vom
Typ AServerData ein Objekt vom Typ Integer zurückgibt. An dieser Stelle muss jedoch berücksichtigt werden, dass der Client lediglich die Methode findByPrimaryKey()
der Home-Schnittstelle ausführt und der EJB-Container die entsprechende Methode
ejbFindByPrimaryKey().
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
ejbCreate()
ejbFindByPrimaryKey()
ejbFindByAnnotationTyp()
ejbFindByServer()
ejbLoad()
ejbRemove()
ejbStore()
SQL-Anweisung
INSERT
SELECT
SELECT
SELECT
SELECT
DELETE
UPDATE
Tabelle 1 : SQL-Anweisungen im AServerDataBean
Remote Interface-Implementierung
Durch die Implementierung der Methoden der Remote-Schnittstelle AServerData erhält
das Entity Bean seine Anwendungslogik. Die Methoden führen keine Datenbankabfragen aus,
womit sichergestellt ist, dass die Anwendungslogik von der Datenbankprogrammierung getrennt ist.
Die Methoden getName() und getPort() übergeben dem Client die IP-Adresse und den
Port des Annotationsservers, auf welchem dieser die zu annotierenden Dokumente erhalten
kann.
Beim Aufruf von getCorpusSize() wird die maximale Anzahl der Dokumente
zurückgegeben, die der Server in einem Annotationsdurchgang annotieren kann.
Mit der Methode getAnnotationsTyps() erhält der Client ein Array vom Typ
String[] mit den Annotationstypen, die der Annotationsserver zur Verfügung stellt.
4.6 ADocumentDataBean
Das Enterprise Java Bean ADocumentDataBean ist ein Entity Bean, das ein annotiertes
Dokument repräsentiert. Der Status dieses Beans ist in der Tabelle annotations einer relationalen Datenbank gespeichert. Die Datenbanktabelle annotations wurde mit der in
Quelltext 8 veranschaulichten SQL-Anweisung erzeugt.
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-Anweisung die mit den Parametern übergebenen Daten in die Datenbank ein. Der Aufruf wird erfolgreich mit der Rückgabe des entsprechenden Remote Interfaces an den Client beendet.
Die Finder-Methoden erlauben es einem Client die Entity Beans zu finden. Der Client kann
hierzu die folgenden zwei Methoden benutzen:
•
findByPrimaryKey()
•
findByName().
Für jede dieser Methoden implementiert das ADocumentDataBean die entsprechenden
Methoden mit dem Präfix ejbFind. Beispielsweise wird die zu findByName() korres-
4
Zentrale Koordinationskomponente
33
pondierende Methode ejbFindByName() genannt. Quelltext 11 veranschaulicht die BeanImplementierung der Methode ejbFindByName().
public Integer ejbFindByName(String p_projectId, String p_name)
throws FinderException {
Integer result;
try {
result = selectByName(p_projectId, p_name);
} catch (Exception ex) {
throw new EJBException("ejbFindInRange: " +
ex.getMessage());
}
return result;
}
Quelltext 11 : ADocumentDataBean.ejbFindByName()
Die Schnittstelle ADocumentDataHome erbt von der Basisschnittstelle EJBHome weitere
Methoden, die vom ADocumentDataBean implementiert werden müssen. Ähnlich wie bei
dem AServerDataBean dienen diese Methoden zum Speichern, Laden und Löschen des
Entity Beans (siehe Kapitel 4.5.3). Tabelle 2 veranschaulicht das Zusammenspiel dieser
Methoden und der entsprechenden Datenbank-Operationen.
Methode
ejbCreate()
ejbFindByPrimaryKey()
ejbFindByName()
ejbLoad()
ejbRemove()
ejbStore()
SQL-Anweisung
INSERT
SELECT
SELECT
SELECT
DELETE
UPDATE
Tabelle 2 : SQL-Anweisungen im ADocumentDataBean
Remote Interface-Implementierung
Durch die Implementierung der Methoden der Remote-Schnittstelle ADocumentData erhält
das Entity Bean seine Anwendungslogik. Die Methoden führen keine Datenbankabfragen aus,
womit die Trennung der Anwendungslogik von der Datenbankprogrammierung gewährleistet
ist.
4
Zentrale Koordinationskomponente
34
Die Methoden getProjectId() und getName() übergeben dem Client die Projekt-Id
und den Dateinamen des annotierten Dokumentes.
Beim Aufruf der Methoden getSourceDocument() und getResultDocument()
werden einmal der Originalinhalt und einmal der annotierte Inhalt des Dokumentes
zurückgegeben.
Mit den Methoden getResultAnnotations() und getSourceAnnotations()
erhält der Client die Annotationen mit Angaben zur Position im Dokumententext und Worttyp
(Person, Datum usw.).
Schließlich gibt die Methode getAnnotationTyp() den Annotationstyp zurück, mit dem
das Dokument annotiert wurde.
4.7 Datenbank-Schnittstelle
Für die Speicherung der Daten benutzt das Annotations-Framework eine relationale Datenbank. Als Datenbankserver wird 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 ausgewählt werden und ihr kann eine virtuelle Datenbank zugeordnet werden. Dabei ist eine virtuelle Datenbank ein Datenbank-Objekt, welches einen JNDI-Namen besitzt. Über diesen
JNDI-Namen können alle J2EE-Serverkomponenten Zugriff auf die Datenbank erhalten.
49
MySql: 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-Applikationsserver 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 zugewiesen. 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-Funktionalitäten aufgerufen werden. Zu diesem Zweck bietet die Benutzeroberfläche zwei Registerkarten: für das Senden und für das Empfangen von Dokumenten (siehe Abbildung 9). Die Dokumente können mit Hilfe eines Datei-Auswahl-Dialogs bezüglich ihrer Projekt-Id zusammengestellt werden. Über die Registerkarte „Senden“ können die Dokumente an das Framework
gesendet werden, während über die Registerkarte „Empfangen“ die gesendeten Projekte ausgewählt und empfangen werden können. Dabei werden die Dateien in das Verzeichnis abgespeichert, das im Konfigurationsdialog eingestellt ist (siehe Abbildung 8).
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 Beispiel in Kapitel 5 implementiert wurde, eine Projekt-Id und eine Auflistung der vom Framework
bereitgestellten
Annotationstools
anfordern.
Dazu
ruft
er
die
Methoden
getProjectId() und die getAnnotationsTyps()der Web Service-Schnittstelle des
Session Beans AClientControllerBean auf. Nun kann der Client mit der Methode
addDocument()und den entsprechenden Parametern Dokumente zum Annotieren an das
Framework senden. Wurde das Dokument an das Framework erfolgreich übertragen, so sendet des AClientControllerBean eine Nachricht mit den Dokumentendaten an die
Topic-Warteschlange.
Die Topic-Warteschlange wird von dem AMessageControllerBean abgehört. Falls
die Warteschlange eine Nachricht für das AMessageControllerBean enthält, wird
dessen Methode onMessage() ausgeführt. Beim Ausführen der Methode besorgt sich das
Bean über das AServerDataBean die Daten eines Annotationsservers aus der Datenbank,
mit dem das Dokument annotiert werden kann. Mit diesen Daten kann eine Socket-Verbindung aufgebaut werden. Über diese Verbindung wird, mit dem in Abschnitt 4.3.2 beschriebenen Protokoll, das Dokument an den Annotationsserver verschickt.
Hat ein Annotationsserver ein Dokument annotiert, so sendet er wiederum über die Web
Service-Schnittstelle des Session Beans AServerControllerBean das annotierte
Dokument an das Framework zurück. Dazu wird die Methode addDocument()aufgerufen,
die dann die erhaltenen Daten über das ADocumentDataBean in die Datenbank speichert.
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 angeschlossenen Client und Annotationsservern getestet. Im folgenden Kapitel wird der Versuchsaufbau beschrieben und die Ergebnisse der durchgeführten Lastentests dargestellt und
beurteilt.
7.1 Versuchsaufbau
Der J2EE-Applikationsserver von Sun Microsystems und der Client wurden auf einem Personal PC von Dell mit dem Microsoft XP Betriebssystem installiert. Die Annotationsserver
wurden auf dem Linux Cluster des Max Plank Instituts für Informatik (MPI) betrieben. Die
folgende Tabelle 3 gibt einen Überblick über die technischen Spezifikationen der Systeme.
Betriebssystem
CPU
Hauptspeicher
System
Client und J2EE-Server
Microsoft Windows XP Professional
Intel Pentium 4, 3.0 GHz
1 GB
System
Annotationsserver
Debian Linux
2 * AMD Opteron, 2.4 GHz
8 GB
Tabelle 3 : Technische Spezifikation Versuchsaufbau
Als Dokumentenbasis für das verteilte Annotieren dienten 2627 XML-Dokumente aus dem
Wikipedia-Verzeichnis. Durch die Verteilung der Dokumente in 5 verschiedene Größenklassen kann von einer heterogenen Dokumentenbasis bezüglich der Größe gesprochen werden
(siehe Abbildung 10). Hierbei war das kleinste 444 Bytes und das größte Dokument 104,69
Kilobytes groß. Die durchschnittliche Größe betrug 4,54 Kilobytes.
7 Evaluation
43
Abbildung 10 : Dokumentenverteilung
7.2 Lastentest
Beim Lastentest wurden drei Hauptdurchgänge durchgeführt. Dabei wurde zweimal mit dem
ANNIE-Annotationswerkzeug annotiert und zwar einmal mit einer Korpusgröße von 25
Dokumenten und einmal mit einer Korpusgröße von 50 Dokumenten. Des Weiteren wurde
einmal mit Minorthird annotiert, jedoch nur mit einer Korpusgröße von 25 Dokumenten.
Durch den hohen Speicherverbrauch und dem damit verbundenen Programmabsturz von
Minorthird, war ein weiterer Durchgang mit einer Korpusgröße von 50 Dokumenten nicht
möglich. Dieser Fall trat auch bei ANNIE auf, jedoch erst bei einer Korpusgröße von circa
100 Dokumenten.
Jeder dieser einzelnen Durchgänge wurde insgesamt fünfmal durchgeführt. So wurde jeder
Durchgang jeweils mit einem, zwei, drei, vier und acht an das Framework angemeldeten Annotationsservern bewerkstelligt. Insgesamt wurden somit 15 Annotationsvorgänge mit den
2627 Dokumenten ausgeführt.
Zum Senden der XML-Dokumente an das Framework brauchte der Client im Durchschnitt
151 Sekunden und zum Empfangen der annotierten Dokumente 412 Sekunden. Der Zeitunterschied ist durch das höhere Datenaufkommen des Ergebnis-Arrays der Methode
getDocument() (siehe Abschnitt 4.2.2) zu erklären.
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 ANNIE 25
Server Zeit in sec
1
2
3
4
8
ANNIE 50
Zeit in sec
1508
763
501
388
279
Minorthird 25
Zeit in sec
1399
708
478
378
460
7712
2082
1688
954
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 Korpusgröß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 Dokumenten 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 Rechenlast entsprechend verteilen können und unterschiedlichen Annotationstools anbinden
können.
Im Mittelpunkt dieser Arbeit steht der Architekturentwurf und Implementierung eines Frameworks 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 Rechenlastverteilung 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 Annotationstools 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 Annotationsservern 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 Erweiterung 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 Versuchsaufbaus (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 Annotationsserver.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-Anweisungen 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
im
mysql-connector-java-3.1.8a.zip
install\database
entpacken
und
mysql-connector-java-3.1.8-bin.jar
die
darin
Datei
in
Verzeichnis
enthaltene
das
Datei
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 Applikationsserver-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.8bin.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
com.mysql.jdbc.jdbc2.optional.MysqlDataSource
Class
Name
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
user
password
serverName
port
databaseName
Wert
<Benutzername Datenbank>
<Kennwort Datenbank>
localhost
3306
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
Bei
jms/TopicConnectionFactory.
javax.jms.TopicConnectionFactory
beiden
muss
ausgewählt
als
Typ
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 Verzeichnis client\AClient. Rufen Sie dort asant run auf. Ist der Client gestartet, sollten 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 installieren und die Bibliotheken der J2EE auf den Clientrechner zu kopieren. Diese Bibliotheken 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.oasisopen.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-frspec.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.