Datenbank-basierte Anwendungsentwicklung fürs Web Mit Rapid Application Development zu schnelleren Applikationen Von Michael Ihringer, InterSystems

Transkript

1 Datenbank-basierte Anwendungsentwicklung fürs Web Mit Rapid Application Development zu schnelleren Applikationen Von Michael Ihringer, InterSystems Die Realisierung Datenbank-basierter Web-Anwendungen erfordert zahlreiche Komponenten und weist deshalb eine hohe Komplexität auf. Klassische Programmierungsmethoden verzögern nicht nur den Entwicklungsprozess, sondern beeinträchtigen auch Management und Laufzeitverhalten der Anwendungen. Abhilfe verspricht Rapid Application Development. Bestanden Web-Auftritte bis vor wenigen Jahren praktisch nur aus statischen Seiten, sind heute Funktionalitäten gefragt, die eine klassische Anwendungsentwicklung erfordern. Aber auch Anwendungen für den unternehmensinternen Einsatz erhalten zunehmend Benutzeroberflächen, die auf Web-Technologie basieren. Einerseits wird dadurch die Konfiguration auf der Client-Seite einfacher meist genügt die Installation eines Web-Browsers. Andererseits steigen die Ansprüche auf der Server-Seite: Hier ist eine erhebliche Anzahl unterschiedlicher Komponenten erforderlich, die reibungslos miteinander arbeiten müssen, damit die Anwendung wie geplant funktioniert. Beteiligte Komponenten die Räder im Getriebe Vom Web-Browser des Anwenders aus betrachtet, ist die erste benötigte Komponente der Web-Server. Normalerweise beantwortet ein Web-Server Browser-Anfragen mit statischen Web-Seiten, die als HTML-Dateien fertig im Dateisystem vorliegen. Für eine Web-Anwendung ist der Ablauf zu ändern. So müssen Anfragen vom Browser, die eine Ausführung von Anwendungs-Code erfordern, erkannt und an die entsprechende Komponente zur Bearbeitung weitergeleitet werden. Hierfür ist der Applikations-Server zuständig. Dieser sollte zumindest über eine Skript-Sprache verfügen, in der die Geschäftslogik programmiert wird, und eine entsprechende Laufzeit-Engine besitzen, die den Code später ausführt. Er kann in ein Objekt-Framework wie J2EE,.NET oder CORBA eingebunden sein, das die Anwendungs- Funktionalitäten dann in einzelne Objekte zerlegt und für die Distribution und Ausführung in einer verteilten Umgebung sorgt. Sobald die Anwendung Zugriff auf gespeicherte Daten benötigt, kommt als weitere Komponente eine Datenbank ins Spiel. Meist greift man auf die verbreiteten relationalen Datenbanken zurück. Arbeitet die Anwendung objektorientiert, ist in diesem Fall noch ein zusätzliches objektrelationales Mapping erforderlich. Dies kann manuell oder durch entsprechende

2 Mapping- bzw. Middleware-Werkzeuge erfolgen, die dann eine weitere Komponente darstellen. Was sprichst Du? Schnittstellen und Engpässe Damit die verschiedenen Komponenten zusammenarbeiten und gemeinsam eine sinnvolle Geschäftslogik bilden können, sind entsprechende Schnittstellen zu bedienen. Dazu gehören http, das der Browser mit dem Web-Server spricht, spezifische Schnittstellen der Web- Server wie ISAPI oder Apache-Module, Framework-Schnittstellen wie EJB,.NET, COM/DCOM, CORBA etc. bis zu Datenbank-Schnittstellen wie ODBC, JDBC oder ADO. Bis eine Web-Anwendung eine einzige Browser-Anfrage bedienen kann, ist also die Ausführung von vier oder mehr Server-seitigen Komponenten und eine Kommunikation über eine entsprechende Anzahl unterschiedlicher Schnittstellen notwendig. Da die Komponenten jeweils über ihre eigene Entwicklungsumgebung und -methodik verfügen, muss der Entwickler ständig umdenken und verbringt viel Zeit mit der Programmierung von Schnittstellen statt von produktiver Geschäftslogik. Auch das Management des Gesamtsystems ist komplex. Es gibt keine zentrale Definitions- und Kontrollinstanz, jede Komponente muss getrennt gewartet werden. Entsprechend schwierig gestaltet sich die Fehlersuche. Zudem sind Nachteile zur Laufzeit offensichtlich: Jede beteiligte Komponente benötigt ihre Verarbeitungszeit und die Bedienung verschiedener Schnittstellen tut ein Übriges. Es geht auch schneller Rapid Application Development Unter dem Stichwort Rapid Application Development stehen heute Werkzeuge zur Verfügung, die Applikations- und Datenbank-Server in einem einzigen Produkt verbinden und den Einsatz von Frameworks und Middleware überflüssig machen. Ein integrierter Web-Server zumindest für Testzwecke rundet das Bild ab. Eine einzige Server-Komponente ist übersichtlicher zu verwalten und lässt sich ohne Schnittstellenproblematik leichter programmieren. Zudem wird die Partitionierung unabhängig von Produktgrenzen flexibler und die Objekte können innerhalb einer einzigen Laufzeitumgebung erheblich schneller und effektiver ausgeführt werden (siehe Abbildung 1)

3 (Abbildung 1). Ein Praxisbeispiel für den Einsatz von Rapid Application Development ist der INTRAPREND Purchase Manager. Hier handelt es sich um eine Internet-bezogene, mehrsprachige, intelligente und lernfähige Einkaufsplattform mit ausgeklügelten Suchstrategien und einer übersichtlichen und ausgereiften Projektverwaltung. Das Programm ermöglicht ein effizientes Business Process Outsourcing, das weit über einen klassischen WebShop hinausgeht. Hauptfunktion des Purchase Managers ist das Bestellwesen. Die Kunden können Artikel suchen, bestellen und sich online aus der Warenwirtschaft heraus den Status ihrer Bestellungen ansehen. Zudem lassen sich über das Internet Reklamationen, offene Rechnungen aufrufen und individuelle Einstellungen vornehmen, wie zum Beispiel Ansprechpartner und Lieferadressen erfassen. Als Basis für die Entwicklung der Applikation dient das postrelationale Datenbank-Managementsystem Caché von InterSystems. Das Bitmap- Indexing von Caché erlaubt ein schnelles Finden und Anzeigen von Artikeln. Der erste Test des Purchase Manager Prototypes mit zwei Millionen Artikeln auf einem alten 500 MHz Rechner mit Caché überzeugte durch eine Antwortzeit von weit unter einer Sekunde. Der Datenimport erfolgt über das Standard XML-Importformat BMEcat. Einen weiteren Vorteil bietet die Applikation durch die Verwendung der XML-http-Request-Funktion von Caché. Sie sorgt dafür, dass bei der

4 Webseite auf das ständige Senden und Neuladen der Seite verzichtet werden kann. Dies ist sehr wichtig, wenn zum Beispiel viele Artikel gleicher Art angeboten werden, wie etwa Glühbirnen mit unterschiedlichen Leistungen und Fassungen. Durch die Nutzung der XML-http-Request-Funktion ist nur noch eine Mengeneingabe erforderlich (Siehe Abbildung 2). (Abbildung 2) Um aus der Projektverwaltung des Bestellshops einen direkten Zugriff auf die Anwendungsdaten zu haben, wird ausschließlich Caché genutzt. Ein Link in das System mittels Caché Server Pages erzeugt durch Caché Object Script automatisch den entsprechenden DHTML-Code und sendet ihn an den Browser des Users. Auf einem INTRAPREND Gantt-Chart wird dies durch Balken, Linien und Texte dargestellt. Ein Klick auf diese genügt, um Funktionen wie beispielsweise die Anzeige von Kapazitäten aufzuzeigen (siehe Abbildung 3).

5 (Abbildung 3) Auch die direkte Datenkommunikation zwischen der ERP-Anwendung im Bestellsystem und der Projektverwaltung wird durch Caché sichergestellt. Durch die Hyper Events der Caché Server Pages ist es gelungen, alle nötigen Drag-and-Drop-Funktionen innerhalb des Bestellsystem durch INTRAPREND Gantt-Charts aufzuschlüsseln, über die auch alle nötigen dynamischen Änderungen dargestellt werden können. Ein weiterer Vorteil ist die direkte Verbindung des Gantt-Charts mit den Projektdaten: Ändern sich die Projektdaten auf dem Server, so werden diese beim nächsten Event wieder auf dem Chart im Bestellsystem aktualisiert. Dadurch sind die Ladezeit der Charts gering und die dargestellten Daten sind jederzeit aktuell. Weniger Komponenten mehr Leistung Rapid Application Development für Web-Applikationen kann also in erster Linie erreicht werden, indem man die Anzahl der beteiligten Komponenten und Schnittstellen verringert. Durch den Einsatz kombinierter Produkte lässt sich die Komplexität der Lösungen reduzieren. Dies ermöglicht erhebliche Produktivitätsvorteile bei der Entwicklung sowie Performancevorteile zur Laufzeit.

6 (7.880 Zeichen)