Java-Technologien zur Erstellung eines Rahmenwerkes für ein internetbasiertes Auskunftssystem

Transkript

1 Java-Technologien zur Erstellung eines Rahmenwerkes für ein internetbasiertes Auskunftssystem Martin KOCH und Dietrich SCHRÖDER Zusammenfassung Durch das Internet wird der Nutzung von Geodaten neue Möglichkeiten eröffnet. Die Daten können leicht und ohne zusätzliche Lizenzkosten für einen Auskunftsarbeitsplatz einem großen Anwenderkreis zugänglich gemacht werden. Voraussetzung dafür ist, daß keine herstellerspezifischen Lösungen auf Browser-Seite verwendet werden, die den Einsatz eines Plug-Ins erfordern. Als Alternative zu proprietären Plug-Ins haben sich heute Java-Applets weitgehend durchgesetzt. Zur Anbindung der GIS-Anwendung auf Server-Seite gibt es dagegen viele unterschiedliche Ansätze. Diese werden im folgenden diskutiert, bevor ein offenes, auf Java-Servlets basierendes, Framework zur Anbindung eines GIS vorgestellt wird. Konkretisiert wird das Rahmenwerk am Beispiel einer Auskunftslösung für Smallworld GIS. 1 Einleitung Klassische GIS-Auskunftsarbeitsplätze basieren auf proprietären Client/Server-Lösungen, d.h. für jeden zusätzlichen Auskunftsarbeitsplatz fallen weitere Lizenzgebühren an. Webbasierte Lösungen haben den Vorteil, daß sie weitgehend herstellerunabhängig sind und in einem beliebigen Web-Browser laufen, auf Client-Seite also keine zusätzlichen Kosten für die Einrichtung zusätzlicher Auskunftsarbeitsplätze entstehen. Eine typische Architektur eines web-basierten Auskunftsarbeitsplatzes mit den server-seitigen Komponenten ist der Abbildung 1 zu entnehmen. Die im Client zur Verfügung stehende Funktionalität ist im Prinzip beliebig erweiterbar und kann alle gewünschten GIS-Funktionen umfassen, von Attribut- und räumliche Abfragen, über Pufferungen und Überlagerungen bis hin zu Klassifikationen und sogar editieren des Datenbestandes. Allerdings ist die Erstellung einer solchen Anwendung heute noch mit einigem Aufwand verbunden. Es muß zum einen eine web-basierte Oberfläche erstellt werden, die dem Anwender die Möglichkeit bietet, die gewünschten Aktionen auszuwählen. Üblich sind hier heute HTML-Formulare bzw. Java- Applets. Zum anderen müssen auf der Server-Seite die entsprechenden Skripte erstellt werden, die die Aktionen ausführen und das aufbereitete Ergebnis an den Client zurück schicken. Einige GIS-Hersteller stellen bereits Beispielapplikationen zur Verfügung oder auch einfache Entwicklungsumgebungen, die den Anwender bei der Erstellung der Web-Oberfläche und der Skripte unterstützen. Diese Lösungen haben allerdings den Nachteil, das damit in der Regel sowohl der zu verwendete HTTP-Server als auch die Skript-Sprache festgelegt bzw. vorgegeben ist. Ein Wechsel des HTTP-Servers ist dann so gut wie ausgeschlossen. Um

2 Martin Koch und Dietrich Schröder den Programmieraufwand zu reduzieren wäre es außerdem wünschenswert, eine Art Rahmen als GIS-Schnittstellenprogramm zur Verfügung zu haben, der im Prinzip den Anschluß eines beliebigen GIS oder auch Datenbank ermöglicht. Client WWW Comput Browser Kommandos, Abfragen Internet Karten, Texte, HTML Server Computer HTTP Server GIS-spezifische Kommandos GIS- Schnittstellen- Programm Karten, Berichte, etc. GIS Daten GIS-Software mit Analyse- Skripten Abb. 1: Architektur eines web-basierten Auskunftsarbeitsplatzes mit einfachen Abfrageund Analysemöglichkeiten Ziel des Projektes war es, einen solchen Rahmen zu entwickeln, der möglichst wenig Vorgaben an die einzusetzende Hard- und Software macht. Es wurde daher die Programmiersprache Java verwendet, die ähnlich den client-seitigen Java-Applets auch auf Server-Seite die Möglichkeit bietet, eine komponentenbasierte Lösung zu entwickeln, mit Hilfe der sogenannten Java-Servlets. Java-Servlets besitzen selbst keinen komponentenbasierten Aufbau, die benötigte Infrastruktur muß deshalb Bestandteil des Frameworks sein. Software-Komponenten sind Erweiterungen des hinlänglich bekannten Prinzips der Software- Objekte. Komponenten weisen gegenüber Objekte gewisse Vorteile auf. Objekte sind meist gebunden an ihre jeweilige Umgebung (Hardware, Betriebssystem, Programmiersprache, Compiler), während Komponenten diese Schranken überwinden können. Damit können sie relativ einfach aus Anwendungen entfernt und durch andere ersetzt werden, sie können mit anderen Komponenten über Netzwerke und unterschiedliche Plattformen kommunizieren und mit anderen Komponenten interagieren, die von anderen Anbietern und mit anderen Programmiersprachen geschrieben sein können. Voraussetzung dabei ist, das den Komponenten eine entsprechende Infrastruktur zur Kommunikation zur Verfügung steht, also eine DCP (Distributed Computing Platform), und das es eine Möglichkeit gibt, die Schnittstelle anderer Komponenten zu erfragen, damit die von diesen angebotenen Dienste in Anspruch genommen werden können. Zunächst sollen kurz die verschiedenen heute verfügbaren technischen Möglichkeiten der Realisierung einer verteilten Anwendung vorgestellt werden, bevor auf die mit Hilfe von Java-Servlets umgesetzte Lösung näher eingegangen wird.

3 Erstellung eines Rahmenwerkes für ein internetbasiertes Auskunftssystem 2 Techniken zur Netzwerkkommunikation 2.1 CORBA CORBA (Common Object Request Broker Architecture) ist ein von der OMG (Object Management Group) festgelegter Standard, der eine Kommunikationsinfrastruktur spezifiziert. Die OMG ist ein Firmenkonsortium, dem heute fast alle großen Software-Firmen angehören. Das Ziel der Gruppe ist die Spezifikation einer Umgebung, die die Kommunikation zwischen Objekten ermöglicht, unabhängig davon wo diese sich befinden oder wie sie erstellt wurden. Damit können Komponenten nach dem Baukastenprinzip über ein Netz in Anwendungen integriert und benutzt werden. Kernstück der Spezifikation ist der Object Request Broker (ORB). Er stellt eine Art Middleware dar, die den Aufbau von Client/Server-Beziehungen zwischen Objekten ermöglicht. Der ORB akzeptiert zunächst die Anforderung eines Clients nach einer bestimmten Aktion eines Objektes. Er sucht danach nach einem Objekt, das die Anforderung erfüllen kann, wobei sich das Objekt auf dem lokalen oder einem entfernten Rechner befinden kann. Der ORB stellt sicher, das der Ort des Objektes, ebenso wie die Programmiersprache, das Betriebssystem, die Hardware vollkommen transparent für den Client sind. Er schickt nun die Parameter an das gefundene Objekt, ruft die entsprechende Methode des Objektes auf, und liefert das Ergebnis zurück. Damit diese Kommunikation funktioniert, sind die Schnittstellen der Objekte dem ORB bekanntzumachen, die anderen Objekten Dienste anbieten. Dies geschieht mit einer speziellen Schnittstellenspezifikationssprache der IDL (Interface Definition Language). CORBA selbst ist keine Implementierung, sondern eine Spezifikation. Es werden Implementierungen von verschiedenen Herstellern angeboten. Zur Realisierung des Projektes wurde CORBA aus verschiedenen Gründen nicht ausgewählt. Ein großer Nachteil von CORBA ist, das die Umgebung relativ komplex ist und damit einen nicht zu unterschätzenden zusätzlichen Aufwand mit sich bringt. Außerdem fallen zusätzliche Kosten an, da der Einsatz eines ORB mit Lizenzgebühren an den entsprechenden Hersteller verbunden ist. Des weiteren ist die Kommunikation durch Firewalls nicht ohne weiteres möglich, da die ORBs auf dem Protokoll TCP/IP basieren. Die Integration in einen bestehenden HTTP-Server ist daher nicht einfach zu realisieren, die Firewall des Servers müßte eventuell umkonfiguriert werden. 2.2 OLE/COM OLE/COM ist die Microsoft Lösung des Komponentenansatzes. OLE und COM erweitern das klassische Objektmodell, in dem sie die erforderliche Infrastruktur und Schnittstellen zur Verfügung stellen. Die Technik hat schon eine recht lange Entwicklungsgeschichte hinter sich, angefangen vom einfachen Ausschneiden und Einfügen über DDE (Dynamic Data Exchange) hin zu OLE (Object Linking and Embedding) in der ersten Version zu Beginn der 90er Jahre. Seitdem wurde OLE ständig fortentwickelt, ab der zweiten Version enthielt es auch COM (Component Object Model). COM soll die inter-objekt Kommunikation

4 Martin Koch und Dietrich Schröder ermöglichen, und stellt damit die Basis zur Entwicklung von Komponenten in der Microsoft- Welt dar. Im Gegensatz zu CORBA stellt OLE/COM sowohl eine Spezifikation als auch eine Implementierung dar. COM selbst ist von seiner Funktionalität mit einem Object Request Broker vergleichbar, allerdings beschränkt auf die Kommunikation zwischen Objekten auf einem Rechner. Erst die Erweiterung DCOM (Distributed Component Object Model) unterstützt die Kommu nikation zwischen mehreren Rechnern. COM funktioniert, in dem es zunächst die Anforderung eines Clients nach einer bestimmten Aktion annimmt. COM sucht dann nach einem Server-Objekt, das die Anforderung erfüllen kann, und liefert einen Zeiger auf das Server-Objekt zurück an das Client-Objekt. Das Client-Objekt kann dann über den Zeiger mit dem Server-Objekt kommunizieren. COM -Server sind im Prinzip Implementierungen, in der Form von DLLs (Dynamic Link Libraries) oder ausführbaren Programmen, die eine oder mehrere Objektklassen zur Verfügung stellen. OLE baut auf COM auf und stellt ein Rahmenwerk zur Verfügung, um Komponenten zu entwickeln. Ursprünglich aufbauend auf zusammengesetzten Dokumenten umfaßt OLE heute unter dem Begriff ActiveX noch weitere Konzepte, u.a. die Möglichkeit anderen Applikationen Objekte zur Verfügung zu stellen (ActiveX-Automation). Der große Nachteil von OLE/COM ist, daß es sich um eine proprietäre Lösung handelt, die Bestandteil der Betriebssysteme Windows NT bzw. Windows 98/2000 ist. Damit ist man weitgehend an die Microsoft-Betriebssysteme gebunden, mit allen Nachteilen, die sich daraus ergeben. 2.3 RMI RMI (Remote Method Invocation) ist eine Technik zur verteilten Programmausführung. Im Gegensatz zu CORBA ist RMI aber nicht unabhängig von der verwendeten Programmiersprache. RMI ist Java spezifisch, d.h. nur Java-Objekte in unterschiedlichen Java Virtual Machines können über diese Technik miteinander kommunizieren. Die Verwaltung der Schnittstellen übernimmt die RMI-Registry, bei der sich jeder RMI-Server anmelden muß. Ein Client-Objekt kann Informationen über einen Server von der Registry anfordern. Mit diesen Informationen kann der Client den Server direkt ansprechen. Wenn ein Client eine entfernt gelegene Methode aufruft, geschieht der Aufruf nicht direkt auf dem entfernten Objekt sondern auf einem lokalen Stellvertreter, einem Stub. Der Stub verpackt den Aufruf und sendet ihn an das Skeleton eines entfernt gelegenen Objektes. Das Skeleton packt die gesendeten Parameter aus und veranlaßt den Aufruf der Zielmethode. Ein weiterer wichtiger Bestandteil der RMI-Architektur, der zwar nicht unbedingt für die Kommunikation notwendig ist, stellt der Sicherheitsmanager dar. Dieser ermöglicht es, die Zugriffe auf den Server zu überwachen. Der große Nachteil von RMI ist, daß diese Technik nur bedingt internettauglich ist. Dadurch, daß die Kommunikation auf TCP/IP basiert, ist ein Zugriff durch eine Firewall nicht erlaubt. Um dieses Problem zu umgehen, ist es möglich, eine RMI-Verbindung über einen

5 Erstellung eines Rahmenwerkes für ein internetbasiertes Auskunftssystem HTTP-Aufruf zu verpacken. Dies würde das Antwortzeitverhalten aber verschlechtern, und einen nicht unerheblichen zusätzlichen Aufwand mit sich bringen. 2.4 Server-APIs Die Möglichkeiten eines HTTP-Servers beschränken sich im allgemeinen darauf, Dateien auszuliefern. Will man eine Anwendung realisieren, die darüber hinaus geht, wird eine Schnittstelle zwischen der Anwendung und dem Server benötigt. Zur Realisierung gibt es heute im Prinzip drei unterschiedliche Technologien: CGI (Common Gateway Interface): Enthält die Anfrage eines Clients eine entsprechende URL, wird ein CGI-Programm gestartet. Das CGI-Programm interpretiert die als Parameter übergebene Zeichenkette und startet gegebenenfalls ein weiteres externes Programm. Die Rückgabe wird dann vom CGI-Skript in eine HTML-Seite umgesetzt, die vom HTTP-Server an den Client zurückgesendet wird. Ein Vorteil dieser Lösung besteht darin, daß der Anwendungsprozeß sauber vom Serverprozeß getrennt ist. CGI ist allerdings recht ressourcenhungrig, da für jede Anfrage ein eigener Prozeß gestartet wird. Bei stark frequentierten Servern kann dies zu erheblichen Performance-Problemen führen. Proprietäres Server-API: Die Firmen Microsoft und Netscape haben zu ihren Webservern jeweils eine eigene API entwickelt. Netscape bietet NSAPI (Netscape Server Application Programming Interface) und Microsoft ISAPI (Internet Server Application Programming Interface) an. Mit diesen Schnittstellen können Programme direkt in den Prozeß des Servers eingebunden werden, d.h. es entfallen Prozeßwechsel zur Ausführungszeit. Außerdem wird nativer Code verwendet, der schneller ist als Java-Bytecode oder interpretierte Skripte. Die erstellten Erweiterungen sind allerdings nicht portabel. Außerdem kann durch die Integration ein Fehler in der Erweiterung den gesamten Server-Prozeß mit sich reißen. Servlet-API: Sun entwickelte eine Java-basierte Servlet-API, die einige Vorteile bietet. Servlets sind portabel und sehr effizient, da sie in der Regel im Speicher des Servers verbleiben und damit sehr schnell aufgerufen werden können. Da sie in Java geschrieben werden, kann die gesamte Java-Funktionalität ausgenutzt werden. Wie alle Java- Programme brauchen auch Servlets eine Ablaufumgebung, hier einen sogenannten Servlet-Engine. Der Servlet-Engine stellt unter anderem die Java Virtual Machine zur Verfügung. Er nimmt die Aufrufe, die für die URL eines Servlets bestimmt sind, vom HTTP-Server entgegen und ruft auf dem Servlet die Service-Methode auf. Der Engine ist somit die Schnittstelle zwischen Server und Servlet. Über den Servlet-Engine kann das Servlet auf die Umgebung des HTTP-Servers zugreifen. Spezielle Dienste ermöglichen es, z.b. die Konfiguration eines Servers abzufragen. Servlet-Engines werden heute von allen gängigen Web-Servern zur Verfügung gestellt. 2.5 EJB Bei EJB (Enterprise JavaBeans) handelt es sich um ein Konzept zum Einsatz von Komponenten in serverseitigen Enterprise-Programmen. EJBs laufen in einem speziellen Container, der wiederum in einen EJB-Server eingebettet ist. Die wesentlichen Aspekte, die bei der Programmierung von Enterprise-Anwendungen zu berücksichtigen sind, bringen EJBs von

6 Martin Koch und Dietrich Schröder Hause aus mit. Dies sind Dienste wie Transaktions- und Sicherheitsmechanismen, Netzwerkkommunikation und Ressourcen-Pooling. Hieraus ergibt sich ein relativ komplexes Framework, wobei bei der Verwendung eines EJB-Containers, die von verschiedenen Softwareherstellern angeboten werden, Lizenzgebühren anfallen. 3 Die realisierte Lösung Jede Verwendung einer herstellerspezifischen Technik sowohl auf Client-, wie auch auf Serverseite, erschwert eine breite Nutzung von Geodaten. Um zu einer offenen und portablen Architektur zu gelangen, wurde die gesamte Anwendung daher ausschließlich in Java erstellt. Es wurde eine Client-Server-Architektur programmiert, die einen von einem speziellen GIS unabhängigen Rahmen bereitstellt. Durch die Spezialisierung des Rahmens kann die Anpassung an ein spezielles GIS erfolgen. Die Client-Seite wird durch ein Java- Applet realisiert, das in jedem üblichen Browser lauffähig ist. Auf Server-Seite wird unter Verwendung von Java-Servlets ebenfalls eine weitgehend herstellerunabhängige Lösung realisiert. Konkretisiert wird der Rahmen durch die Anbindung von Smallworld GIS, implementiert wurde sie auf einem Apache-Web-Server. 3.1 Das Framework Servlet-Engine/WebServer Antwort Spezial- Komponente Anfrage Servlet Switch Antwort Standard- Komponente Smallworld GIS Abb. 2: Prinzip der Kommunikation im Framework Aus der obigen Diskussion ergibt sich, das für die angestrebten Ziele eine Realisierung mit Servlets am besten geeignet ist. Ansatzpunkt der Realisierung ist es, Funktionalitäten zu sinnvollen Komponenten zusammen zu fassen. Um Servlets nicht zu überladen, werden Servlets nur als Portal zu anderen Objekten verwendet, die sinnvoll mit den Servlets verbunden sind. Um den Grad der Wiederverwendung zu erhöhen, entsprechen die realisierten Objekte weitgehend den JavaBeans-Spezifikationen. Je nach Anwendung lassen sich Aggregate aus Standard - und Spezialkomponenten bilden, siehe Abbildung 2.

7 Erstellung eines Rahmenwerkes für ein internetbasiertes Auskunftssystem Ein Kernstück des erstellten Rahmenwerkes behandelt den Methodenaufruf, der von einem Client-Objekt angestoßen wird. Eine Anfrage eines Clients wird von einem Servlet entgegengenommen und an eine bestimmte Komponente weitergereicht. Diese Komponente arbeitet die Abfrage ab, leitet sie gegebenenfalls an eine andere Komponente weiter, bzw. sendet das Ergebnis der Bearbeitung an den Client zurück. Um dies zu erreichen, wird das ServletRequest-Objekt, das ServletResponse-Objekt und ein vom Client gesendetes Event- Objekt in einem MIEvent gekapselt. Da bestimmt werden muß, welche Komponente von dem Event benachrichtigt werden soll, verfügt das MIEvent über eine Methode getmieventlistener(). Hierzu muß in einer Konfiguration das Mapping eines Events auf die zugehörige Komponente und die aufgerufene Methode hinterlegt sein. Über den MIEventSwitch, bei dem alle MIEventListener registriert sind, wird das MIEvent an den richtigen EventListener ausgeliefert. Der MIEventListener führt dann die entsprechende Methode aus. Eine weitere Klasse in dem Framework ist der MIContext. Diese Klasse übernimmt die Verwaltungsaufgaben und stellt eine Schnittstelle zur Umgebung des Servlets dar. MIServlet service( ) buildmicontext( ) buildmicmdswitch( ) buildmicmdfactory( ) MIContext MICmdListenerNames MICmdNames buildmicontextobject( ) getcontextobject( ) log( ) MIEventFactory mmieventlisteners newmievent( ) MIEventSwitch mpool mmicontext executemievent( ) buildmieventlistener( ) 1..* MIEventListener name executemievent( ) buildmethodhash( ) MIEvent MIEventListener MethodName servletrequest servletresponse MIEvent( ) getmieventlistener() 3.2 Spezialisierungen Abb. 3: Ausschnitt aus dem Klassendiagramm Das vorliegende Rahmenwerk erlaubt recht unterschiedliche Realisierungen und Spezialisierungen. Im Hinblick auf die Anbindung von Smallworld GIS sind im wesentlichen folgende Erweiterungen vorgenommen worden: Event-Mechanismus, um beliebige parametrisierte Methoden verwenden zu können.

8 Martin Koch und Dietrich Schröder Skalierung, d.h. die Möglichkeit die Anzahl der möglichen Verbindungen an die Leistungsfähigkeit der Hardware anzupassen. Cache-Mechanismen, um eine ungewünschte die Laufzeit verschlechternde Garbage- Collection zu umgehen.

9 Erstellung eines Rahmenwerkes für ein internetbasiertes Auskunftssystem 3.3 Architektur der Smallworld GIS Auskunftslösung Client (Browser) MainGraphicBean Server MainGraphic ServerBean ObjectTreeBean ObjectTableBean ObjectTree ServerBean ObjectTable ServerBean MIContext GIS Abb. 4: Komponentenaufbau des Auskunftssystems Die Auskunfts lösung besitzt auf Client-Seite Funktionen zur Grafik- und Sachdatenausgabe. Das Client-Applet enthält daher zur Sachdatenausgabe bzw. -auswahl die zwei Hauptkomponenten ObjectTableBean und ObjectTreeBean, während die Ausgabe der Grafik in der Komponente MainGraphicBean erfolgt. Allen drei sind entsprechende Komponenten auf Serverseite zugeordnet, die Spezialisierungen der oben beschriebenen Framework-Komponenten sind. Der Zugriff auf Smallworld GIS erfolgt über MAGIE, eine in Java erstellte Kopplungssoftware, die von der Firma Mettenmeier, Paderborn, entwickelt wurde. 4 Literatur Hartman, R. (1997): Focus on GIS Component Software. Onword Press, Santa Fe, NM. Hunter, J. & W. Crawford: Java Servlet Programming. O'Reilly, Beijing. Koch, M. (1999): Realisierung einer internetbasierten Auskunftslösung für Smallworld GIS. Diplomarbeit an der Hochschule für Technik, Fachbereich Vermessung und Geoinformatik, Stuttgart. Roßbach, P. & H. Schreiber (1999): Java Server und Servlets. Addison-Wesley, Bonn.