Rich Internet Applications

Feature | 20. September 2004 von admin 0

Neulich bei der Buchbestellung: Anton Schusters Vorfreude auf eine neue CD wurde herb gedämpft, denn beim Bestellvorgang saß er vor seinem Browser und wartete minutenlang Seite für Seite, bis er all seine Adress-, Liefer- und Kreditkartendaten eingegeben hatte – wieder einmal. So wie Anton Schuster ergeht es täglich unzähligen Internetnutzern. Dabei sind endlose Browserwartezeiten kein unabänderliches Schicksal, sondern könnten sich mit Hilfe von Rich Internet Applications (RIA) vermeiden lassen. RIA-Anwendungen sind vom Server losgelöste Anwendungsdialoge, die in einem Webbrowser innerhalb einer einfachen HTML-Webseite laufen. Die Grundidee hinter RIA ist, die Ereignisverarbeitung und die Kontrolle über die Anwendung vollständig im Browser abzuwickeln. Das Backend auf dem Server dient nur noch als Datenlieferant. Die Schnittstelle zwischen Back- und Frontend lässt sich durch Web-Services erzeugen. Das bedeutet, die Anwendungsdaten werden per Web-Service im Backend angeboten oder gespeichert. Im Frontend läuft die RIA-Anwendung zwischenzeitlich weiter. Sie zeigt die übermittelten Daten an, ruft auf Wunsch aktuelle Informationen von den Backend-Servern ab oder übermittelt neue Daten zur Speicherung ans Backend zurück. Solange die RIA-Anwendung läuft, müssen keine aktualisierten Layout-Informationen aus dem Backend nachgeladen werden.

Internet-Shop auf Basis von RIA

Internet-Shop auf Basis von RIA

In einem Einkaufssystem, das auf RIA beruht, löst beispielsweise die Verschiebung eines Produktbildes auf ein Warenkorbsymbol ein Ereignis innerhalb der RIA-Anwendung aus. Das Warenkorbobjekt im RIA-Applet nimmt das neue Produkt intern in seine Liste auf. Dabei muss noch keine Verbindung zwischen dem Webbrowser und dem Webserver aufgenommen werden. Sobald der Anwender jedoch den Warenkorb auf das Objekt “Kasse” verschiebt, muss eine Verbindung zu einem serverseitigen Zahlungsservice hergestellt werden, damit beispielsweise der Warenkorb auf dem Server abgelegt und die Zahlungsinformationen des Kunden für die nächsten Dialogseiten nachgeladen werden können. Die Kommunikation erfolgt also nur dann, wenn Daten aus Transaktionsgründen geladen oder gespeichert werden müssen. Die Darstellung und Ereignisverarbeitung regelt der Client in der Zwischenzeit unabhängig vom Webserver.

Die Technologie hinter RIA

Mehr Infos zu RIA

Mehr Infos zu RIA

Technisch gesehen ist RIA ein Flash-, Java- oder Active-X-Applet, das in eine HTML-Seite eingebettet wird. RIA-Anwendungen lassen sich aus einer Kombination von Flash-Dialogen, Java-Applets oder einer Galerie aus JavaScript-Bibliotheken und Active-X-Anwendungen realisieren. Das bisherige HTML-Verarbeitungsmodell verlangt, bei einem Mausklick einen Web-Server einzuschalten, auf dem die Anwendungslogik hinterlegt ist. Bei RIA werden Frontend und Backend getrennt entwickelt. Die Frontend-Anwendung entscheidet anhand von Ereignissen, wann ein Server eingeschaltet wird. Obwohl der Anwender die Schaltflächen, Auswahllisten, Tabellen, MovieClips und andere Komponenten in seiner Browseranwendung benutzt, erfolgt manchmal minutenlang kein Zugriff auf die Web-Services, weil die Anwendung ohne neue Daten vom Server selbst weiterlaufen kann. Sobald ein gewünschtes Ereignis in der RIA-Anwendung auftritt, lassen sich sogar zeitgleich mehrere Web-Services auf mehreren Backend-Servern einschalten. Ereignisse sind im Falle von RIA-Anwendungen nicht allein Mausklicks, sondern auch die Bedienung verschiedener interaktiver Objekte, etwa von Bildsymbolen, Timerereignisse oder Sprach- und Videoaufnahmen mit Kamera und Mikrofon.
Im Unterschied zu klassischen HTML-Seiten ist eine RIA-Anwendung keinesfalls darauf beschränkt, in einem Webbrowser (Intranet oder Internet) abzulaufen. Beispielsweise ist eine mit Microsoft Excel oder Access erstellte Dialogmaske in der Lage, genauso auf Web-Services einer Anwendung des SAP Web Application Server zuzugreifen und die gleichen Datenquellen zu nutzen wie eine RIA-Webanwendung mit Flash oder Java. Office- oder Flash-Anwendungen, Webseiten, UMTS-Seiten, WAP-Seiten oder Java-Applets erreichen nur unterschiedliche Darstellungen der gleichen Datenwerte. Eine Webseite ist also nur ein Spezialfall vieler möglicher RIA-Anwendungsdialoge. Die freie Wahl der Frontend-Anwendungen bietet zahlreiche praktische Vorteile: So lassen sich Daten aus einer Web-Service-Quelle als Diagramm in Excel oder, alternativ dazu, mit Hilfe eines eingebetteten Flash-Films als grafisches Diagramm in einer HTML-Seite veranschaulichen. Die Nutzer verwenden dafür einfach die Oberfläche, die sich am besten für die jeweilige Fragestellung eignet. Aufgrund der Web-Services ist gewährleistet, dass die Applikationen die gleiche Datenquelle benutzen und identische Werte anzeigen.

Kein zentraler HTML-Server mehr

Zugriff auf mehrere Datenquellen

Zugriff auf mehrere Datenquellen

Ein weiterer wichtiger Aspekt der RIA-Architektur besteht darin, dass Anwendungsoberflächen nicht mehr über einen zentralen Webserver laufen müssen, sondern gleichzeitig auf Daten aus unterschiedlichen Systemen zugreifen können. Diese Daten lassen sich auf einer gemeinsamen Oberfläche darstellen. Beispielsweise können Daten aus einem Produktkatalog einer SQL-Datenbank und Stammdaten aus dem SAP-Materialstamm in einer Bedienoberfläche miteinander verknüpft werden, ohne dass die beiden Server voneinander wissen. Für den Anwender erscheinen die Daten in der Bedienungsoberfläche als homogene Einheit. Um dies zu realisieren, ist es lediglich notwendig, über Web-Services auf die Systeme zuzugreifen. Oberflächenwerkzeuge wie Java, Flash, oder .NET rufen – kontrolliert durch ein übergreifendes Berechtigungssystem – diese Datenquellen auf. Die RIA-Oberfläche übernimmt also die Aufgabe eines einheitlichen Darstellungsportals der Informationen für den Anwender.

Realisierung einer RIA-Anwendung mit SAP Web Application Server

Arbeitsweise von RIA

Arbeitsweise von RIA

Eine RIA-Anwendung besteht aus zwei Komponenten: Zum einen müssen die Daten auf SAP Web Application Server (SAP Web AS) mit Hilfe von Funktionsbausteinen als Web-Services zur Verfügung stehen. Zum anderen wird die Webanwendung selbst als eigenständiges RIA-Applet realisiert und nimmt im Bedarfsfall mit dem Server Kontakt auf. Die Anwender erstellen ein RIA-Applet wahlweise mit Java, Flash, Microsoft.NET, Active-X oder einer MS-Office-Anwendung. Alle Funktionsbausteine eines SAP-Systems lassen sich per Mausklick über die Option “Remotefähiger Funktionsbaustein” zu einem Web-Service umwandeln. Die bereits bestehende betriebswirtschaftliche Funktionalität von SAP-Lösungen steht nach einem einzigen Mausklick für RIA-Anwendungen zur Verfügung.

Symbiose zwischen RIA und BSP

SAP-Hefte

SAP-Hefte

Die Verwendung von RIA schließt HTML nicht aus – im Gegenteil. Da jedes RIA-Applet mit einigen wenigen Codezeilen in eine HTML-Seite eingebaut wird, lassen sich RIA-Anwendungen jederzeit mit Business-Server-Page-(BSP-)Tags vermischt verwenden. Anwender haben die Wahl, mehr Funktionalität in die HTML-Seite, die BSP oder in das RIA-Applet einzubauen. Für statische Anzeigen lassen sich am besten die Funktionalitäten von SAP BSP für Reports, Listen oder Tabellendarstellungen nutzen, denn BSP kommt für diese Art von Informationsdarstellung oft mit ein paar Zeilen Code aus. RIA-Anwendungen hingegen bieten vor allem für interaktive Kataloge, dynamische Charts, Produktbilder oder Konfiguratoren Vorteile – vor allem wegen der besseren grafischen Entwicklungswerkzeuge, der verfügbaren Darstellungskomponenten, der Dynamik in den Seiten und der integrierten Ereignisverarbeitung.

Grundsätzlich stellt jedes Produkt, das seine Daten aus einer Web-Service-Datenquelle bezieht, eine RIA-Oberfläche dar. Immer mehr Hersteller, so auch SAP oder IBM, nutzen die vom W3C-Konsortium angebotenen Standards im Backend: J2EE, Tomcat oder Apache-Server dienen häufig als Basis für Kombinationsprodukte. SAP bietet mit SAP Web Apppliaction Server, Release 6.3 eine J2EE-Engine als Installationsoption an. Das bedeutet, dass SAP-Kunden ihre Anwendungen wahlweise entweder mit Hilfe der gewohnten SAP-Bordmittel oder von Java-Standards erstellen können.
Von ihren Frontends aus haben die Kunden mittlerweile die Chance, auf kompatible Web-Services eines IBM-, eines SAP- oder eines anderen Webservers zuzugreifen: Diese Entwicklung ist ein gewaltiger Schritt in Richtung einheitlicher Benutzeroberflächen und Portale.

www.sap-hefte.de/794

Bernd Will

Bernd Will

Leave a Reply