DE10106811A1 - Verfahren und System zur Erstellung und zum Betrieb einer komplexen Applikation in einem öffentlichen Datennetz - Google Patents

Abstract

Verfahren zur Erstellung und zum Betrieb einer komplexen, eine Mehrzahl von Funktionalitäten umfassenden Applikation in einem öffentlichen Datennetz, insbesondere dem Internet, wobei die Applikation unter Nutzung mindestens eines definierten, von einem ersten Dienstanbieter erstellten und betriebenen Basisdienstes von einem zweiten Dienstanbieter aufgebaut und gegenüber Anwendern als Applikation betrieben wird.

Description

Die Erfindung betrifft ein Verfahren zur Erstellung und zum Betrieb einer komplexen Applikation in einem öffentlichen Da­ tennetz, insbesondere dem Internet, sowie eine entsprechende Systemarchitektur.

Für die Erläuterung des Standes der Technik sowie der Erfin­ dung werden die folgenden Begriffe verwendet:

Dienst

Überbegriff für Funktionalität, die über das Internet zur Verfügung gestellt wird. Im folgenden wird zwischen Applika­ tionsdiensten und Basisdiensten unterschieden.

Applikationsdienst (Applikation)

Applikationsdienste sind Dienste, die ihre Funktionalität ü­ ber eine (graphische) Benutzerschnittstelle zur Verfügung stellen und von Anwendern genutzt werden können. Die graphi­ sche Benutzeroberfläche wird meist innerhalb eines Browsers dargestellt.

Basisdienst

Basisdienste sind Dienste, die ihre Funktionalität über eine offene, programmtechnische Schnittstelle zur Verfügung stel­ len. Dadurch können sie von anderen Dienstanbietern zu neuen Diensten integriert werden. Basisdienste sind die Bausteine zum Erstellen neuer Dienste.

Dienstanbieter

Stellen Dienste zur Verfügung

Dienstnutzer

Nutzen die von Diensten zur Verfügung gestellte Funktionali­ tät. Im Falle von Applikationsdiensten wird der Dienstnutzer als Anwender bezeichnet.

Anwender

Nutzen die von Applikationsdiensten angebotene Funktionali­ tät. Der Zugriff erfolgt meist mittels eines Browsers, der die graphische Benutzeroberfläche des Applikationsdienstes darstellt.

Internet

Das Internet als öffentliches Transportnetz verbindet Dienst­ anbieter und Anwender und stellt ihnen einen Kommunikations­ mechanismus zur Verfügung. Charakteristisches Merkmal des In­ ternets ist, daß die Übertragung von Information auf eine un­ sichere Art und Weise erfolgt. Informationen können daher verfälscht oder abgehört werden oder verloren gehen.

Der Erfolg des Internet liegt nicht zuletzt in der enormen Anzahl der verfügbaren Applikationen begründet. Beispiel für Applikationen im Internet sind Shopping-Malls, Gaming sites, Online-Auktionen, etc. Die große Anzahl der verfügbaren Ap­ plikationen ist (unter anderem) ein Ergebnis der offenen Ar­ chitektur des Internet. Im Prinzip ist es jedem möglich, Ap­ plikationen zu erstellen und somit zum Dienstanbieter zu wer­ den.

Jedoch stellt die Realisierung von anspruchsvollen Applikati­ onen, die über einfache Darstellung von Informationen hinaus­ gehen, insbesondere kleine Dienstanbieter vor Probleme.

So müssen Dienstanbieter Funktionalitäten realisieren, die nicht spezifisch für ihre spezielle Applikation sind. Ein Beispiel dafür sind Abrechnungsfunktionalitäten oder die Ver­ waltung von Anwender-Accounts. Die Umsetzung solcher Funktio­ nalitäten erfordert spezifische Kenntnisse, was die Realisie­ rung der Applikationsidee erschweren oder sogar verhindern kann. Zudem kann der Betrieb einer Applikation durch die von bestimmten Funktionalitäten benötigten Ressourcen (Hardware, Speicherkapazität usw.) unrentabel sein.

Applikationen im Internet werden derzeit überwiegend in einer zweischichtigen Client-Server-Architektur realisiert. Eine Benutzeroberfläche (Frontend) wird auf dem Client Host beim Anwender ausgeführt und kommuniziert über das Netzwerk mit einer Server Applikation (Backend) auf einem Server Host beim Dienstanbieter. Um eine bessere Skalierbarkeit der Applikati­ on zu erreichen, können funktionale Komponenten über mehrere Server Hosts verteilt werden.

Fig. 1 skizziert die Architektur. Sie ist selbsterklärend, so daß hier keine zusätzliche Erläuterung erforderlich ist.

Aus der zweischichtigen Architektur ergibt sich zwangsläufig, daß der Dienstanbieter alle von der Applikation benötigten Funktionalitäten selbst zur Verfügung stellen muß. Verein­ facht wird ihm die Realisierung im allgemeinen durch Funkti­ onsbibliotheken (z. B. Servlets) oder Laufzeitumgebungen (z. B. Enterprise Java Beans). Nachteil dieses Ansatzes ist, daß die angebotene Funktionalität nicht sehr spezialisiert ist und der Dienstanbieter dennoch den Betrieb (Installation, Updates, Kapazität, etc.) der Funktionalität übernehmen muß.

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren sowie ein System zur Realisierung komplexer Applikationen in einem öffentlichen Datennetz anzugeben, welches die Realisierung der Applikationen wesentlich vereinfacht und durch Verringe­ rung des Implementierungsaufwandes die Voraussetzungen für eine Erweiterung des Anbieterkreises schafft.

Gelöst wird diese Aufgabe durch ein Verfahren mit den Merkma­ len des Patentanspruchs 1 und ein System mit den Merkmalen des Patentanspruchs 9.

Vorteilhafte Ausführungsformen und Weiterbildungen der Erfin­ dung sind in den abhängigen Ansprüchen angegeben.

Die Erfindung hat im wesentlichen zwei Komponenten:

(1) Modell

Das Modell beschreibt eine Architektur, nach der neue Appli­ kationen erstellt werden.

(2) Infrastruktur

Die Infrastruktur stellt die Grundfunktionalitäten zur Verfü­ gung, die notwendig sind, um das Modell in einem Transport­ netz wie dem Internet anwenden zu können.

Eine zentrale Idee des vorgeschlagenen, in Fig. 2 schematisch dargestellten Modells ist es, neue Applikationen nicht (wie bisher) als "monolithischen Block" zu realisieren, sondern durch die Integration von definierten Basisdiensten. Diese Basisdienste werden von beliebigen, voneinander unabhängigen Dienstanbietern betrieben und zur Integration angeboten. Die Ausführung der Basisdienste erfolgt verteilt, wobei das In­ ternet als Kommunikationsmedium genutzt wird.

Die Hauptvorteile dieses Modells sind:

• - Da Dienstanbieter nur noch die Kernfunktionalitäten ihrer Applikation realisieren müssen und übrige Funktionalitäten (im Sinne eines outsourcing) von anderen Dienstanbietern nut­ zen können, vereinfacht sich das Erstellen neuer Applikatio­ nen erheblich.
• - Für Anbieter von Basisdiensten ergeben sich neue Geschäfts­ modelle.
• - Für den Betreiber der Infrastruktur (z. B. den Betreiber des Transportnetzes) ergibt sich die Möglichkeit, am Geschäft zwischen Anwender und Dienstanbieter zu partizipieren. Im bisherigen zweischichtigen Modell war seine schwerpunktmäßige Aufgabe der Transport von Daten.

Da von einem öffentlichen und unsicheren Transportnetz ausge­ gangen wird, sorgt eine Sicherheits-Infrastruktur für eine gesicherte Kommunikation zwischen den Teilnehmern. Sie stellt dabei in einer bevorzugten Ausgestaltung die folgenden zent­ ralen Funktionalitäten zu Verfügung:

• a) Teilnehmer können eindeutig identifiziert werden. Zum einen können Dienstanbieter eindeutig Dienstnutzer i­ dentifizieren. Dadurch wird z. B. eine Zugriffskontrolle oder Vergebührung ermöglicht. Zum anderen können Dienst­ nutzer eindeutig Dienstanbieter identifizieren. Dadurch ist sichergestellt, daß ein Anwender auch die Funktiona­ lität vom Dienstanbieter erhält, für die er vergebührt wurde.
• b) Gesicherte Datenübertragung zwischen den Teilnehmern. Die zwischen den Teilnehmern übertragenen Daten werden gegen Sicherheitsrisiken in öffentlichen Netzen ge­ schützt. Maßnahmen dazu sind z. B. Verschlüsselung und Authentifizierung.

Um ein dynamisches Zusammenspiel von Basisdiensten unter­ schiedlicher Dienstanbieter zu ermöglichen, bietet die Infra­ struktur insbesondere auch einen Mechanismus zum automati­ sierten Finden von (Basis-)Diensten. Dieser Mechanismus wird im folgenden Dienstregister genannt. Die Funktionsweise ist wie folgt:
Sobald ein Dienst aktiv ist und Dienstnutzern zur Verfügung stehen soll, so registriert er sich mit einer Dienstbeschrei­ bung beim Dienstregister. Eine Dienstbeschreibung besteht aus einem Satz von Attributen. Das Format einer Dienstbeschrei­ bung, bzw. welche Attribute sie enthalten kann, ist abhängig vom Typ eines Dienstes. Das Format ist sowohl Dienstnutzem als auch Dienstanbietern bekannt.

Dienstnutzer, d. h. Anwender oder Ersteller von Applikatio­ nen, können Suchanfragen an das Dienstregister richten und eine Liste von verfügbaren Diensten erhalten, deren Dienstbe­ schreibung auf die Suchanfrage passt.

Mit den vom Dienstregister erhaltenen Informationen können Dienstnutzer Verbindungen zu den Diensten herstellen.

Das Verbinden von Basisdiensten unterschiedlicher Dienstan­ bieter wird durch die folgenden Mechanismen realisiert:

• a) Es wird eine einheitliche Sprache zwischen Dienstnutzer und Dienstanbieter definiert. Dazu wird für jeden Dienst­ typ eine Schnittstelle spezifiziert, die sowohl dem Dienstnutzer als auch dem Dienstanbieter bekannt ist. Die konkrete Realisierung der Schnittstelle bleibt dem Dienstanbieter überlassen.
• b) Es wird ein programmtechnischer Mechanismus zur Verfügung gestellt, über den Dienstnutzer dynamisch Verbindungen mit Diensten herstellen können. Der Zeitraum, über den eine solche Verbindung zwischen Dienstnutzer und Dienst existiert, wird als Sitzung bezeichnet, der Mechanismus daher als Sitzungs-Management.

Den Anbietern von Diensten wird ein Mechanismus zur Verfügung gestellt, über den sie Dienstnutzer vergebühren können. Die­ ser Mechanismus unterstützt insbesondere die Abwicklung von sogenannten Micropayments.

Zur Unterstützung von Dienstanbietern wird ihnen eine Ent­ wicklungsumgebung angeboten, die das Integrieren von Basis­ diensten zu neuen Diensten vereinfacht.

In einer Erweiterung des Modells ist es auch möglich, neue Basisdienste aus einer Kombination bestehender Basisdienste zu erstellen. Basisdienste können dadurch spezialisiert und erweitert werden.

Diese können dann wiederum von anderen Dienstanbietern zur Erstellung neuer Applikationen integriert werden.

Vorteile und Zweckmäßigkeiten der Erfindung ergeben sich im übrigen aus den abhängigen Ansprüchen sowie der nachfogelnden Beschreibung aktueller Ausführungsbeispiele.

Zunächst sei als Ausführungsbeispiel für das Modell eine mög­ liche Umsetzung aus dem Bereich der E-Commerce-Dienste ge­ nannt.

Ein Dienstanbieter möchte eine virtuelle Bildergalerie anbie­ ten, über die Bilder verschiedener Künstler online vertrieben werden. Zur Realisierung integriert der Dienstanbieter dieser Applikation die Basisdienste der folgenden unabhängigen Dienstanbieter:

• 1. Dienstanbieter Shopping Mall:
  Um die virtuelle Bildergalerie nicht als Stand-alone Shop zu betreiben, integriert der Dienstanbieter den "Shopping Mall" Basisdienst eines Shopping Mall (virtuelles Kauf­ haus) Betreibers. Dieser bietet Funktionalitäten wie z. B. Warenkorb und Verwaltung von Benutzeraccounts (Adressen, Profile, etc.) an.
• 2. Dienstanbieter Abrechnungsverfahren:
  Zur Abrechnung von Kunden können die Abrechnungsdienste verschiedener Finanzdienstleister integriert werden, um den Kunden verschiedene Abrechnungsverfahren zu ermögli­ chen (Kreditkarte, etc.).
• 3. Dienstanbieter Content:
  Da der Betreiber der virtuellen Bildergalerie im allge­ meinen die Bilder nicht selbst erstellt, integriert er die Inhalte, die von verschiedenen unabhängigen Künstlern in Form von Basisdiensten angeboten werden.
• 4. Dienstanbieter Telefonie:
  Um seinen Kunden auch persönliche Beratung bieten zu kön­ nen, integriert er den Telefoniedienst, der vom Betreiber eines Telefonnetzes angeboten wird. Kunden können dadurch per Knopfdruck über das Benutzerinterface des Dienstes ein Telefongespräch zur persönlichen Beratung anfordern.

Als weiteres Ausführungsbeispiel wird ein System zur Reali­ sierung eines Internet-gestützten Konferenzdienstes genannt, den Anwender über einen Browser nutzen können.

Die erforderliche Infrastruktur für Dienstregister, Sicher­ heitsmechanismen, Sitzungs-Management und Vergebührung (Mi­ cropayment) wird auf einem zentralen Server bereitgestellt, der beispielsweise von einem ISP (Internet Service Provider) betrieben wird. Ebenso sind Basisdienste auf diesem Server realisiert. Als Basisdienste sind hier der Zugriff auf Steue­ rungsmechanismen für Telefonie-Netze, auf Unified Messaging Funktionen sowie auf ein Register für Anwenderprofile imple­ mentiert.

Der Konferenzdienst nutzt die angebotene Infrastruktur, um die Funktionalität der Basisdienste über offene Programmier­ schnittstellen in den Konferenzdienst zu integrieren. Die einzelnen Komponenten werden dabei vollständig mit der Programmiersprache JAVA erstellt wobei der Zugriff auf die Funktionen über JAVA-Methodenschnittstellen erfolgt. Dazu werden sowohl beim Dienstnutzer als auch beim Anbieter ent­ sprechende Teilkomponenten, die die erforderlichen Schnitt­ stellen bereitstellen, installiert.

Im folgenden werden spezielle Aspekte von Ausführungsbeispie­ len zur Realisierung der oben erwähnten Infrastrukturkompo­ nenten genannt:

Sicherheitsinfrastruktur

Die Sicherheitsinfrastruktur wird in einem Beispiel von der Dienstearchitektur getrennt, indem sie in die unteren Proto­ kollebenen eingebettet wurde. Die für die Ausführung der Dienste erforderliche Kommunikation setzt auf diesem gesi­ cherten Transportwegen auf. Es werden dafür zwei Realisie­ rungsmöglichkeiten vorgeschlagen:

• 1. Anwender und Dienstanbieter (hier der Konferenzdienst) sind über eine IP-basierte Tunneltechnologie mit dem zent­ ralen Server verbunden. Dieser fungiert somit als sog. Trusted Broker, da er die jeweilige Identität des Anwen­ ders bzw. Dienstanbieters kennt. Zusätzlich sorgt die Tun­ neltechnologie für die erforderliche Verschlüsselung der Daten.
• 2. Die Kommunikation zwischen Anwender und Dienstanbieter er­ folgt über SSL (Secure Socket Layer)-Technologie, wobei der zentrale Server wiederum als Trusted Broker agiert, indem er die Funktion einer sog. Certificate Authority zur gegenseitigen Authentifizierung und Verschlüsselung reali­ siert.

Mechanismus zum Suchen nach Diensten

Es wird ein Dienstregister auf dem zentralen Server implemen­ tiert, wobei die Beschreibung der Dienste sowie die Speiche­ rung im Register mit XML-Technologie erfolgt. Die Dienste werden dabei über festgelegte Diensttypen sowie weitere dienstspezifische Attribute beschrieben. Die Verwendung von XML erlaubt nun eine programmtechnische Suche nach Diensten (hier verwendet vom Konferenzdienst zur Suche nach Basis­ diensten) wie auch eine web-basierte interaktive Suche durch den Anwender (hier für die Suche nach einer Applikation - dem Konferenzdienst).

Kommunikationsmechanismen

Um einen Dienst für Dienstnutzer verfügbar zu machen, ist zu­ nächst eine Registrierung im Dienstregister - wie zuvor be­ schrieben - erforderlich. Wird nun ein entsprechender Dienst vom Dienstnutzer gesucht und gefunden, wird das zentrale Sit­ zungs-Management aufgerufen, um eine konkrete Instanz des Dienstes zu erzeugen. Dabei wird vom Sitzungs-Management die programmtechnische Referenz dieser Instanz an den Aufrufer vermittelt und die Überwachung der Sitzung gestartet.

Infrastruktur für Vergebührung

Implementiert werden die Möglichkeit der zeitbasierten Verge­ bührung (beispielsweise für die Dauer der Nutzung der Appli­ kation) wie auch der zeitunabhängigen Vergebührung einzelner Posten. Die entsprechenden Gebühren werden dabei dem Anwender belastet. Dazu werden Schnittstellen angeboten, um Start und Ende eines Intervalls sowie die zu vergebührende Rate pro Zeiteinheit zu definieren.

Die Infrastruktur (Sitzungs-Management) erlaubt nun nur dann einen Aufruf durch den Dienstanbieter (hier der Konferenz­ dienst), wenn dieser mit dem Anwender - für den vergebührt werden soll - eine aktive Sitzung hat. Als zusätzliche Siche­ rungsmaßnahme wird durch eine Rückfrage an den Anwender erst bei dessen Bestätigung die Vergebührung vorgenommen bzw. ge­ startet.

Entwicklungsmethodik

Um die programmtechnische Dienstentwicklung durch den Dienst­ anbieter (hier der Konferenzdienst) zu ermöglichen, wird ein JAVA SDK (Source Development Kit) mit allen erforderlichen Schnittstellen und der erforderlichen Dokumentation erstellt. Als nächster Schritt zu einer noch einfacheren Integration der Basisdienste kann eine graphische Entwicklungsumgebung zur Verfügung gestellt werden. Sie soll es Dienstanbietern ermöglichen, durch graphisches Verknüpfen von Basisdiensten neue Applikationen zu erstellen. Dies könnte das Erstellen neuer Applikationen insoweit vereinfachen, als daß sich ein Anwender selbst neue personalisierte Dienste erzeugen kann.

Claims (12)

1. Verfahren zur Erstellung und zum Betrieb einer komplexen, eine Mehrzahl von Funktionalitäten umfassenden Applikation in einem öffentlichen Datennetz, insbesondere dem Internet, dadurch gekennzeichnet, daß die Applikation unter Nutzung mindestens eines von einem ers­ ten Dienstanbieter erstellten und betriebenen Basisdienstes von einem zweiten Dienstanbieter aufgebaut und gegenüber An­ wendern als Applikation betrieben wird, wobei zur Integration des mindestens einen Basisdienstes in die Applikation mindes­ tens eine Schnittstelle mit einer vorbestimmten Spezifikation und eine einheitliche Protokollsprache bereitgestellt werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der mindestens eine Basisdienst im Rahmen der Applikation selbständig verteilt beim jeweiligen Dienstanbieter ausge­ führt wird bzw. werden.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Integration des mindestens einen Basisdienstes in die Ap­ plikation unter Einsatz einer standardisierten Entwicklungs­ umgebung erfolgt.

4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Kommunikation zwischen den an der Erstellung und dem Be­ trieb der Applikation beteiligten Dienstanbietern und Anwen­ dern unter Anwendung einer vorbestimmten, einheitlichen Si­ cherheits-Infrastruktur erfolgt.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß die Kommunikation zwischen den an der Erstellung und dem Be­ trieb der Applikation beteiligten Dienstanbietern und Anwendern unter Einsatz von Identifikationsdaten, insbesondere in kryptografischer Kodierung, erfolgt.

6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, daß die Kommunikation zwischen den an der Erstellung und dem Be­ trieb der Applikation beteiligten Dienstanbietern und Anwen­ dern unter Authentisierung seitens der Anwender gegenüber al­ len beteiligten Dienstanbietern, insbesondere unter Authenti­ sierung aller Beteiligten, erfolgt.

7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Basisdienste unter Hinterlegung einer Dienstbeschreibung, insbesondere in Form einer Dienstanbieter-Adresse und/oder eines Satzes von Attributen, in einem vorbestimmten Format in einem Dienstregister verzeichnet werden.

8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß ein Micropayment-Basisdienst zur Realisierung der Vergebüh­ rung kleiner Beträge integriert wird.

9. System zur Durchführung des Verfahrens nach einem der vo­ rangehenden Ansprüche, gekennzeichnet durch eine zumindest zeitweilige bidirektionale Datenverbindung im Datennetz zwischen dem ersten und zweiten und gegebenenfalls weiteren an der Erstellung der Applikation beteiligten Dienstanbietern in der Phase der Erstellung sowie eine zumin­ dest zeitweilige mehrseitige Datenverbindung zwischen einem Dienstnutzer und dem ersten und zweiten und gegebenenfalls weiteren am Betrieb der Applikation beteiligten Dienst­ anbietern während der Ausführung der Applikation.

10. System nach Anspruch 9, dadurch gekennzeichnet, daß im Datennetz eine standardisierte Entwicklungsumgebung imple­ mentiert ist.

11. System nach Anspruch 9 oder 10, dadurch gekennzeichnet, daß im Datennetz eine Sicherheits-Infrastruktur implementiert ist, die insbesondere Eingabe- und Verarbeitungsmittel zur Eingabe und Verarbeitung von Identifikationsdaten/Authenti­ sierungsdaten der Dienstanbieter und/oder Dienstnutzer auf­ weist.

12. System nach einem der Ansprüche 9 bis 11, gekennzeichnet durch ein Dienstregister zur Registrierung von zur Erstellung von Applikationen verfügbaren Basisdiensten.