HTTP-Server. Servlet. JDBC OMNIS- Bibliotheks- System. (HTTP-Server)

Transkript

1 Published in: Cap. C. H. (Ed.): Proc. Java-Informations-Tage 1998 (JIT'98), in Frankfurt, Springer-Verlag, Informatik aktuell, 1998, pp Java, XML und Servlets zur Integration datenbankbasierter Applikationen im Web Albrecht Schmidt und G nther Specht TU M nchen, Orleansstr. 34, M nchen Albrecht.Schmidt@in.tum.de specht@in.tum.de Zusammenfassung Am Institut f r Informatik der Technischen Universit t M nchen werden zwei bestehende Technologien, digitale Bibliothekssysteme und multimediale Datenbanken, in einem Web-basierten Kontext integriert, d. h. ein Benutzer soll letztendlich ber einen der g ngigen WWW-Browser auf die schon vorhandenen digitalen Bibliotheken als auch auf multimediale Informationen zugreifen k nnen. Eine besondere Rolle spielt dabei die Verwendung von Java als Implementationssprachen und XML als (zun chst internem) Datenformat zum Zusammentragen der Information aus den verschiedenen Datenbanken. 1 Einf hrung und berblick An der Technischen Universit t M nchen l uft im DFG-Schwerpunktprogramm Verteilte Verarbeitung und Vermittlung digitaler Dokumente [DFG98] das Projekt OMNIS/2. Darin wird die Integration von Bibliothekssystemen und multimedialen Datenbanken untersucht. Da schon Vorarbeiten in umfangreichen anderen Projekten erbracht worden sind, stand am Anfang die Frage, wie man m glichst gro e Teile davon bernehmen k nne. Dabei ging es nicht nur um das Wiederverwenden von Programmcode, sondern vor allem um die Nutzbarmachung und Integration gro er Mengen an Datenbest nden, insbesondere Bibliotheksdatenbanken. Eine zweite Anforderung bestand in der Verwendung und Evaluierung von modernen Technologien. Nach einer Planungsphase und der Diskussion verschiedener Designvorschl ge kam der Entschlu, die ImplementationinJava durchzuf hren. Dabei spielte einerseits die Plattformunabh ngigkeit der Sprache eine gro e Rolle, andererseits auch die gute Einbettung in die vorhandene WWW-Architekur [Wor98b], insbesondere die M glichkeit HTTP-gest tzter Kommunikation durch URL-Klassen und Servlets [Sun98]. Eine weitere Anforderung bestand in der Integration bestehender Projekte. Da diese bereits ber einen WWW-Anschlu verf gten, lag die Idee nahe, diesen auch zu nutzen. Die bliche HTML-Ausgabe dient

2 aber lediglich der Darstellung berechneter Resultate. Insbesondere gehen durch Konvertierung der internen Datenstrukturen nach HTML viele semantische Informationen verloren, die f r eine Weiterverarbeitung sehr hilfreich w ren. Basierend auf der Idee, statt nach HTML in eine Sprache zu konvertieren, die auch Semantik in die Dokumentenstruktur miteinbezieht, wurde zus tzlich zur Standard-HTML-Ausgabe eine XML-Ausgabe [Wor98a] (mit modizierter URL) implementiert, in der die Daten die n tige semantische Tiefe besitzen. Die genannten Technologien entwickeln sich zudem immer mehr zu einem Standard, so da eine Vielzahl an Werkzeugen zur Verf gung steht, die deren Einsatz enorm erleichtert. Ziel dieses Papiers ist es zu zeigen, wie man unter Einbeziehung von XML, Java und Servlets als Kerntechnologien, mehrere Anwendungen in einer Plattform integrieren und an das WWW anschlie en kann. 2 Bibliothekssysteme Bei den in der Einf hrung erw hnten Bibliothekssystemen handelt es sich imwesentlichen um die verschiedenen Auspr gungen des an der TU M nchen entwickelten OMNIS-Systems [KVB97], das in einer Vielzahl an Projekten im Einsatz ist und f r das daher mehrere sehr umfangreiche Datenbanken existieren. Es verwaltet die typischen, im Bibliothekskontext auftretenden Dokumentenarten. Bei der Literaturrecherche hat man nicht nur Zugri auf die herk mmliche Attribute wie Autor, Titel, Verlag, sondern kann auch im Volltext der ersten Seiten eines Dokuments, also im Abstract und/oder Inhaltsverzeichnis suchen. Ist die Suche erfolgreich gewesen, so besteht die M glichkeit, sich noch einen optischen Eindruck von einer gescannten Version der gefundenen Dokumente zu machen und danach das Dokument herunterzuladen und auszudrucken, sofern es vollst ndig vorliegt. Ansonsten kann es je nach Version und Kontext evtl. bestellt werden. Intern arbeitet OMNIS mit drei verschiedenen Attributarten. Da gibt es die von traditionellen Bibliothekskatalogen her bekannten Strukturfelder wie Autor, Titel, Jahr, Verlag. Zus tzlich steht einteil des Dokuments im suchbaren Volltext zur Verf gung, der das Ergebnis eines mittels OCR analysierten Scannens ist. Bilddaten stellen das Dokument in seiner urspr nglichen Form dar. Sie k nnen sowohl als Bitmap als auch als Postscript vorliegen. In der aktuellen Version ist noch keine Suche und Verlinkung der in der Datenbank liegenden Quellen m glich. 3 Multimediale Datenbanken Multimediale Datenbanken unterscheiden sich von herk mmlichen Bibliothekssystemem in zweierlei Hinsicht. Zum einen k nnen sie mit neueren kontinuierlichen Medientypen umgehen, im wesentlichen Video und Audio. Dies allein ist schon eine w nschenswerte Eigenschaft, die vielen herk mmlichen Bibliothekssystemen fehlt. 260

3 Zum anderen unterst tzen sie auchverlinkungen zwischen Objekten, die ber die aus HTML bekannten Verfahren hinausgehen. So enthalten g ngige Modelle zu multimedialen Datenbanksystemen auch bidirektionale, getypte und n : m-links, wie es im Dexter-Modell [HS94], das unserer Planung zugrunde liegt, der Fall ist. Typische Anwendungsbereiche in unserem Kontext sind Literaturverzeichnisse, wo das als Referenz aufgef hrte Schriftst ck auf Maus-Klickverf gbar gemachtwerden kann, oder Zitate, die gleich auf die bezuggenommene Textstelle verweisen k nnen. Im allgemeinen werden sich die genannten Anforderungen nicht mit reinem HTML [Wor98c] erf llen, auchwenn die M chtigkeit dieser Sprache durch immer neue Standards und Entwicklungen weiter zunimmt. Soll es z. B. m glich sein, in einem Bild interaktiv einen Link durch Umrahmen der Anker che mit einem Polygon zu setzen, so erfordert dies den Einsatz von Java-Applets. Im Projekt MultiMAP, ebenfalls an der TU M nchen, wird ein solches multimediales Datenbanksystem entwickelt, das sowohl multimediale Objekte als auch die erw hnten komplexen Linkstrukturen basierend auf dem Dexter-Modell unterst tzt [HS94]. Auch hier gibt es schon eine Reihe an Anwendungs-Datenbanken. 4 Designziele Betrachtet man die Eigenschaften der beiden vorgestellten Systeme, so w rden sie sich in nat rlicher Weise zu etwas M chtigerem erg nzen dazu mu man jedoch M glichkeiten des einen in das andere bernehmen. Das w rde zum Beispiel die angesprochenen vernetzten Literaturverzeichnisse erm glichen, aber auch Annotationen, die ein Benutzer zu Schriftst cken einf gen k nnte, oder thematisch begr ndete Verbindungen. Somit ergibt sich als Designziel ein System, das die Eigenschaften von Bibliothekssystemen und multimedialen Datenbanken vereint. Eine einfache Code-Integration der Systeme OMNIS und MultiMAP war jedoch aufgrund jeweils eigener Datenformate und -strukturen nicht m glich. Die gew hlte Zielspezikation bestand aus einer Integrationsschicht ber beiden Einzelkomponenten, die auf die darunterliegenden Systeme zur ckgreift und leicht um weitere Module erweiterbar ist. Diese Integrationsschicht ben tigt aber mehr semantische Informationen, als die HTML-Ausgaben der beteiligten Systeme liefern. Da es aber verh ltnism ig einfach ist, einen WWW-Anschlu von einer HTML-Ausgabe auf eine XML-Ausgabe umzustellen in unserem Fall war nur reine textuelle Substitution im erzeugenden Code n tig wurde das OMNIS-System, das schon an das WWW angebunden war [CVW95], lediglich um eine XML-Ausgabe erweitert. Es hat sich herausgestellt, da es so m glichist, alle in den internen Datenbanken vorhandenen relevanten Informationen unserer integrativen Anwendung zug nglich zumachen. F r XML als zuk nftigem Standard gibt es mittlerweile eine ganze Reihe an Bibliotheken, Programmen, Parsern und Prozessoren, die sich an die W3C-Empfehlung halten und somit einen reibungslosen Datenaustausch erm glichen. 261

4 Ebenso sollte unsere integrative Anwendung selbst keinerlei propriet re Protokolle verwenden. Es wird oft noch viel Zeit und M he darauf verwendet, eigene Kommunikationsprotokolle zu entwerfen. Das ist bei Web-basierten Anwendungen in vielen F llen gar nicht n tig, da mit dem HTTP-Protokoll [Wor98d] bereits ein Standard zur Verf gung steht, der die g ngigsten F lle abdeckt. Weiterentwicklungen wie HTTP- NG [Wor98e] sollten bei l ngerfristigen Projekten auch in die Planung miteinbezogen werden, da sich so in Zukunft Sackgassen vermeiden lassen. Gerade die Java-eigenen URL-Klassen reichen oft vollkommen zur Kommunikation aus. Weiterhin sollte eine integrative Anwendung auch skalierbar sein. Der Einsatz einer objektorientierte Sprache wie Java bietet die M glichkeit, weitere Anwendungen in Modulen unterzubringen, die soweit sie XML als Ausgabe liefern sich leicht in die Gesamtarchitektur einbinden lassen. Die Initialisierung dieser Module k nnte in der init()-methode eines Servlets geschehen. F r weniger h ug gebrauchte Module ist sogar ein dynamisches Laden denkbar. Zusammmenfassend lassen sich unsere Designziele folgenderma en beschreiben: 1. Verwendung von standardisierten, plattformunabh ngigen Technologien 2. Modularit t und Skalierbarkeit 3. gr tm gliche Wiederverwendbarkeit bestehender Datenbanken und Applikationen 5 Architektur Diese Designziele bertragen sich auf nat rliche Weise in die Architekur, die in diesem Abschnitt vorgestellt wird. Da wir uns als Ziel gesetzt haben, m glichst nur ber Standard- Protokolle zu kommunizieren und einen WWW-Anschlu zur Verf gung zu stellen, liegt es nahe, den von uns benutzten und notwendigen HTTP- Server mit Hilfe von Servlets zu einem vollst ndigen Applikationsserver auszubauen. Da die zu implementierenden Methoden eines Servlets genau den verschiedenen HTTP-Anfragen (GET, PUT, POST etc.) entsprechen, k nnen wir unsere Kommunikation ohne gro en Mehraufwand ber das HTTP-Protokoll abwickeln. Diese berlegungen resultierten im linken oberen Teil unsere Applikationsschems, wie es in Abbildung 5 zu sehen ist: Browser und HTTP-Server kommunizieren nur ber einen Standard-HTTP-Port. Vom Browser eines Benutzers kommen Anfragen, die in den Servlets verarbeitet werden. Das k nnen Anforderungen des Browsers selbst sein, wie sie etwa durch Aktivieren eines Bookmarks oder Anforderung einer neuen URL ausgel st werden, m glicherweise sind sie auch von Java- Applets z. B. in interaktiven Bildern oder in HTML-Seiten eingebettete JavaScript-Teile gestellt. Diese Anfragen werden entsprechend ihrer Semantik aufgespalten und an die f r sie zust ndigen Module weitergereicht. Wenn es darum geht, 262

5 Browser HTTP-Server Servlet JDBC OMNIS- Bibliotheks- System (HTTP-Server) Socket-Server Applikations- Server Abbildung1. Unser Applikations-Schema einen Link zu verfolgen, wird in der Link-Datenbank das Linkziel bestimmt, eine neue Seite zusammengestellt und an den Web-Browser des Benutzers geschickt. Bei einer Stichwortsuche in einer Bibliotheksdatenbank werden die Suchbegrie in das entsprechende URL-Format bersetzt, abgeschickt, und die XML-Antwort interpretiert, mittels eines XSL-Prozessors [Wor97] nach HTML bersetzt und an den Browser zur ckgegeben. Diese Grundideen bersetzen sich auf nat rlich Weise in eine Java- Umgebung. Durch Servlets erweitert man den Web-Server um eigene Prozeduren. In der init()-routine werden allgemeine Initialisierungen vorgenommen wie das Anlegen von Datenbankobjekten, die wiederum Verbindungen zu Datenbanken aufbauen, oder die Instanziierung von H llklassen f r Datenquellen wie der OMNIS-Datenbank. Weniger h u- g ben tigte Module, wie etwa Autorenkomponenten, k nnen w hrend des laufenden Betriebs nachgeladen werden. Die Verbindung zu der erw hnten Linkdatenbank kann innerhalb eines eigenen Moduls ber einen JDBC-Anschlu und damit ebenfalls ber eine standardisierte Schnittstelle bewerkstelligt werden. Wenn traditionelle Internet-Socket-Server integriert werden sollen, so kann die Kommunikations-Verbindung ber Java-Sockets, einem weiteren Element derjava- API, hergestellt werden. In diesem Fall ist allerdings eine Emulation des von der integrierten Anwendung geforderten propriet ren Protokolls notwendig, was je nach Protokoll recht aufwendig werden kann. Handelt es sich beidemsocket-server um einen HTTP-Server, kann mit ihm ber die WWW-konformen Routinen in java.net.httpurlconnection kommuniziert werden. 263

6 Viele Datenbankhersteller [Inf98,Ora98] verfolgen brigens ein hnliches Konzept, nur da sie das Pferd quasi von der anderen Seite aufz umen. Sie integrieren in Datenbanken immer mehr Funktionen, die vorher vom Betriebssystem oder von Spezialapplikationen wie HTTP-Servern bernommen wurden, und vereinfachen so die konzeptuelle Projekt-Planung. JDBC ist unter diesem Gesichtspunkt ein Versuch der Vereinheitlichung auf Programmiersprachenseite. 6 Servlets Zwar sind Servlets in gewisser Weise ein Sprachelement von Java, jedoch ist es im Anwendungsszenario oft sinnvoll, sie als einfache M glichkeit zu sehen, einen speziell auf die eigenen Bed rfnisse zugeschnittenen HTTP-Server zu erstellen. Dies gilt in besonderer Weise, da Servlets mit Infrastruktur au erhalb der eigenen Programmumgebung sehr eng zusammenarbeiten. Insofern hat die Verwendung von Servlets gr ere Auswirkungen auf das Design des Gesamtsystems, als es bei der blo en Verwendung eines weiteren Teils der Java-API der Fall w re. Einerseits machen sie als Erweiterung des HTTP-Servers es ber ssig, einen eigenen Applikations-Server zu schreiben. Andererseits impliziert die oftmals als Vorteil angef hrte Tatsache, da Servlets als Threads und nicht als Prozesse laufen, da Teile des Systems Thread-sicher sein m ssen, d. h. sie sich gegen die Probleme absichern, die blicherweise entstehen, wenn mehrere Prozesse auf dieselben Ressourcen zugreifen. Insbesondere bei Datenbankanbindungen k nnen Probleme entstehen, da JDBC-Treiber von ihrer Architektur her nicht Thread-sicher sind und somit Thread-sichere H ll-klassen oder Container geschrieben werden m ssen. Eine m gliche L sung ist, in einem java.util.vector eine Liste von offenen Datenbankverbindungen zu halten. Wenn nun ein Thread eine Datenbankanfrage absetzen will, greift er ber eine sychronized-methode auf die Liste zu, holt sich eineverbindung und l scht dasentsprechende Element in der Liste. Sobald er seine Antworten erhalten hat, f gt er die Verbindung wieder in die Liste ein. Abbildung 6 zeigt einige Code- Fragmente, die dies verdeutlichen. Die einfache Handhabe von Threads ohne das explizite Setzen und Freigeben von Sperren macht es einfach, solche Konzepte schnell in Java umzusetzen. Im Gegensatz zu einer entsprechenden C- oder C++- Implementation ist der zus tzliche Programmieraufwand eher gering. Wohl aber ist der Planungsaufwand h her. 7 Java Der Vorteil, den der Einsatz von Java gebracht hat, ist neben der Plattformunabh ngigkeit die problemlose Einbettung in das WWW. Das in der Standard-API enthaltene Packet java.net stellt alle n tigen Kommunikationsroutinen zur Verf gung, ohne da ein Einbinden von Nicht- Standard-Bibliotheken erforderlich w re. 264

7 class DataBase {... public synchronized Connexion getconnexion() throws SQLException, ClassNotFoundException { if (Connexions.isEmpty ()) { // Vektor ist leer // evtl. tempor re Verbindung aufbauen... else { c = (Connexion) Connexions.elementAt(0) Connexions.removeElementAt(0) public synchronized void releaseconnexion(connexion c) { if (Connexions.size() >= MaxNumberOfConnexions) { // evtl. tempor re Verbindungen aufl sen... else { Connexions.addElement(c) Abbildung2. Datenbankzugri in Threads Durch diese auf transparente Kommunikation ausgelegten Sprachelemente bietet sich Java f r die Entwicklung von Anwendungen wie unserer an. Die Entwicklungzeiten waren kurz, schon bald stand ein Prototyp zur Verf gung. Ein weiterer Punkt ist die relativ billige Parallelit t durch mehrere Threads, die bei Verwendung von Servlets fast automatisch entsteht. Der Trade-O daf r sind die h heren Entwicklungskosten f r die ben tigten Klassen, die Thread-sicher sein m ssen. Diese Kosten w rden aber bei jeder Parallelarchitektur, die Threads benutzt, anfallen. Gerade die einfache Handhabe von Threads mittels synchronized-methoden stellt eine wesentliche Vereinfachung gegen ber den von C bzw. C++ bekannten POSIX-Threads dar. Auch f r Zugrie auf relationale Datenbanken stellt Java ein Standard- Sprachelement zur Verf gung. W hrend bisher Embedded-SQL-Code oder spezielle Bibliotheken verwendet werden mu ten, kann jetzt die Datenbank ber eine nicht mehr herstellerspezische JDBC-Schnittstelle angesprochen werden, die Zeitersparnis im Vergleich zu den anderen Techniken ist signikant. 265

8 8 XML und HTML Wie anfangs beschrieben, war die Umstellung einer HTML-Ausgabe auf XML ein wichtiger Punkt im Integrationsproze. Anhand eines Beispiels soll die Rolle von XML in unserem Kontext verdeutlicht werden. Abbildung 3 zeigt eine etwas vereinfachte HTML-Ausgabe eines WWW-Bibliothekssystems. Da ist einerseits die URL des Linkziels, wo das Dokument abrufbar ist, andererseits sichtbar am Bildschirm der Autor und der Titel. Zus tzlich ein Anker f r den Link, der zu dem Dokument f hrt. <A HREF= URL > M. Usterautor, Wie man in Java programmiert </A> Abbildung3. Ergebnis einer Suche in HTML <BUCH> <URL>URL </URL> <AUTOR>M. Usterautor</AUTOR> <TITEL>Wie man in Java programmiert</titel> </BUCH> Abbildung4. Ergebnis einer Suche in XML F r eine Applikation, die diesen HTML-Text als Eingabe erh lt, ist es sehr schwierig, auf die semantische Struktur zu schlie en, zumal diese noch von Anfrage-Ergebnis zu Anfrage-Ergebnis verschieden sein kann. Im Gegensatz dazu enth lt die XML-Version in Abbildung 4 zu jeder Ausgabe die Meta-Information, um welche Art von Daten es sich handelt. Der Name des Autors ist von einem AUTOR-Tag-Paar umgeben. Ebenso verh lt es sich mit URL und Titel. Zus tzlich ist der Block von einem BUCH-Tag umgeben, das als zus tzliche Information enth lt, da es sich bei dem umschlossenen Text um die Beschreibung eines Buches handelt. Wie oben beschrieben, ist ein Umstellen der Ausgabe einer bestehenden Applikation von HTML nach XML eine relativ billige L sung, da man oft lediglich die Ausgabe-Tags ver ndern mu. Besonders wenn Techniken wie Server-Parsed-HTML-Templates, wie es bei OMNIS der Fall war, zum Einsatz kommen, f llt eine Umstellung leicht. Wenn man weiter das HTTP-Protokoll benutzt, um seine Anfragen zu stellen, besteht die Haupt-Integrationsaufgabe darin, die entprechenden Anfragen in einer URL nachzumodellieren und diese dann abzuschicken. 266

9 Die Rolle von XML in unserer Anwendung kann noch weiter gefa t werden. Bei verschiedenen heterogenen Modulen, die in gr erem Ma e voneinander abh ngen, kann XML als intermodulares Austauschformat verwendet werden. XML selbst enth lt keine Informationen dar ber, wie es von einer Anwendung visuell oder akustisch dargestellt werden soll. Im Gegensatz zu HTML gibt es keine Konvention, da bestimmte Tag-Namen eine Bedeutung wie Drucke das folgende Wort kursiv haben. Zu diesem Problem gibt es mehrere m gliche L sungsans tze. Einerseits k nnen propriet re Methoden Einsatz nden, d. h. ein XML-Quelltext wird eingelesen, ein Parse-Baum wird aufgebaut, und aus diesem eine Ausgabe generiert. Andererseits kann man auch Standard-Techniken verwenden wie Style-Sheets oder XSL-Prozessoren [Wor97]. Style-Sheets bieten sich an, wenn die Struktur des XML-Textes im wesentlichen der Struktur der gew nschten visuellen Darstellung entspricht, da sie f r jedes XML-Tag die visuellen oder akustischen Attribute angeben. XSL-Prozessoren geben gr ere Freir ume, da sie ein (fast) beliebiges Traversieren des von der Dokumentenstruktur implizierten Syntaxbaums erlauben. Gegenw rtig l t sich die Tendenz ausmachen, bei Client/Server- Systemen die Darstellungslogik zu m glichst gro en Teilen in den Client zu verlegen. Wo die M chtigkeit von Style-Sheets bzw. XSL-Prozessoren nicht ausreicht oder die geforderte Interaktivit t nicht bietet, werden Java-Applets eingesetzt. 9 Zusammenfassung Wir haben gesehen, wie man Web-basierte Anwendungen integrieren kann, ohne gro e Ver nderungen an den Strukturen oder Quelltexten der beteiligten Module vornehmen zu m ssen. Dies geschah aus der Grundidee, einen WWW-Port, der auf Anfragen eine f r graphische Darstellung der Ergebnisse aufbereitete Antwort liefert, von einer HTML- auf eine XML-Ausgabe umzustellen und als generischen Zugang zu einer Applikation zu betrachten. Java leistet in diesem Zusammenhang besonders wertvolle Dienste, da es viele WWW-konforme Sprachelemente enth lt und die Entwicklungszeiten kurz sind. Literatur [CVW95] Alexander Clausnitzer, Pavel Vogel, and Stephan Wiesener. WWW-Interface to the OMNIS/Myriad Literature Retrieval Engine. In The Third International World-Wide Web Conference: Technology, Tools and Applications, Darmstadt, [DFG98] DFG. DFG-Schwerpunktprogramm: Verteilte Verarbeitung und Vermittlung digitaler Dokumente [HS94] F. Halasz and M. Schwartz. The Dexter Hypertext Reference Model. Communications of the ACM, 37(2):3039,

10 [Inf98] Informix. Developing datablade modules for informix dynamic server with universal data option [KVB97] Wolfgang Kowarschick, Pavel Vogel, and Rudolf Bayer. ELEK- TRA: An Electronic Article Delivery Service. In 8th International Conference on Database and Expert Systems, Tolouse, July [Ora98] Oracle, Inc. Cartridges [Sun98] Sun. Java Documentation [Wor97] World Wide Web Consortium. A Proposal for XSL. August [Wor98a] World Wide Web Consortium. Extensible Markup Language [Wor98b] World Wide Web Consortium. Homepage [Wor98c] World Wide Web Consortium. HTML 4.0 Specication [Wor98d] World Wide Web Consortium. HTTP Hypertext Transfer Protocol [Wor98e] World Wide Web Consortium. Hypertext Transfer Protocol - Next Generation