-
Technisches
Gebiet
-
Die
Lösung
informationstechnischer Probleme erfordert in zunehmendem Maße die Zusammenarbeit
miteinander vernetzter Systeme. Dabei ist eine steigende Komplexität zu beherrschen,
die zum einen von den komplexer werdenden Aufgabenstellungen, aber
auch von dem wachsenden technischen Aufwand für die effiziente Realisierung
der Verteilung und Kommunikation der einzelnen Lösungsteile herrührt.
-
Um
diese Komplexität
zu beherrschen werden unter anderem Middleware und darauf aufbauende
Application-Server verwendet. Auf diese Weise wird die Entwicklung
der Lösungsteile
vereinfacht, die die Kommunikation zwischen den Anwendungsteilen
in einem Netzwerk betreffen.
-
Diese
Erfindung betrifft die Lösung
informationstechnischer Aufgaben mit Hilfe von Application-Servern.
Client-Programme, die die von einem Application-Server bereitgestellten
Dienste nutzen, müssen
diese Dienste zuerst finden und eindeutig identifizieren, um sie
nutzen zu können.
Die Identifikation dieser Dienstes unterscheidet sich bei jeder
Installation der Lösung,
da es von dem konkreten Netzwerk abhängt, wie Dienste gefunden und
genutzt werden. Dabei wird das Problem gelöst, dass die bisherigen, bekannten
Lösungsansätze für dieses
Problem aufwändig
sind. Durch die erfindungsgemäße Ausgestaltung
wird dieser Aufwand verringert.
-
Definitionen
-
Im
Sinne dieser Erfindung handelt es sich bei Code um eine Beschreibung
informationstechnischer Vorgänge
und Daten. Als Code bezeichnet werden insbesondere Daten im Speicher
eines Computers, die als Handlungsvorschrift für diesen Computer dienen, aber
auch die Struktur eines elektronischen Schaltkreises (anwendungsspezifische
Elektronik). Darüber
hinaus sind alle Darstellungen, die sich auf eine dieser beiden
Formen von Codes oder Mischformen davon eindeutig abbilden lassen,
Code.
-
Eine
besondere Art von Code ist Quellcode. Dabei handelt es sich um Code,
der nicht direkt maschinell ausgeführt werden kann, sondern dafür in anderen
Code übersetzt
werden muss. Code, der Hardware beschreibt, ist immer Quellcode,
da er erst in Hardware überführt werden
muss.
-
Ein
Programm ist im Sinne dieser Erfindung die Gesamtheit des zur Lösung eines
konkreten Problems oder einer konkreten Klasse von Problemen benötigten Codes.
Das ist zum Beispiel ein Software-Programm, das von einem Computer
ausgeführt werden
kann, oder ein konkreter elektronischer Schaltkreis.
-
Ein
Prozess ist im Sinne dieser Erfindung ein Programm, das gerade abgearbeitet
wird. Das ist zum Beispiel ein Software-Programm, dass von einem
Computer ausgeführt wird,
oder eine konkreter elektronischer Schaltkreis, der mit Energie
versorgt wird und seine spezifische Aufgabe erfüllt.
-
Eine
Anwendung ist im Sinne dieser Erfindung die Gesamtheit der zur Lösung einer
Menge logisch zusammenhängender
Aufgaben notwendigen Programme. Eine Einzelplatzanwendung wie zum Beispiel
eine Textverarbeitung besteht dabei aus genau einem Programm. Eine
verteilte Anwendung besteht aus einem oder mehreren Programmen,
zur Laufzeit jedoch immer aus mehreren Prozessen, die zusammenarbeiten.
-
Ein
Dienst ist im Sinne dieser Erfindung eine bestimmte, klar definierte
Leistung, die ein Stück Code
einem oder mehreren anderen Code-Stücken zur Verfügung stellt.
Zur Erbringung der Leistung ist üblicherweise
die Nutzung bestimmter Ressourcen wie Rechenleistung und/oder Speicherkapazität notwendig.
-
Eine
Schnittstelle im Sinne dieser Erfindung beschreibt einen Dienst.
Sie stellt damit einen verbindlichen Vertrag zwischen dem Anbieter
und dem Nutzer eines Dienstes dar. Welche Parameter zur Beschreibung
eines Dienstes von der Schnittstelle festgelegt werden, hängt von
der jeweils verwendeten Technologie zur konkreten Realisierung des Dienstes
ab.
-
Im
folgenden wird der Stand der Technik bei Application-Servern und
verwandten Technologien beschrieben.
-
1. Middleware
-
Die
technische Grundlage von Application-Servern ist Middleware. Middleware
erlaubt es den Prozessen, die zu einer verteilten Anwendung gehören, sich
zur Laufzeit gegenseitig Dienste zur Verfügung zu stellen. Das Konzept
des Dienstes ermöglicht
eine abstrakte und damit einfache Beschreibung der Interaktionen
zwischen den Anwendungsteilen.
-
Ein
Dienst wird durch eine oder mehrere Schnittstellen, das heißt eine
definierte Menge von Operationen, beschrieben. Diese Beschreibung
lässt normalerweise
keinen Rückschluss
auf die konkrete Implementierung des Dienstes zu. Damit können Implementierungen
ohne Modifikation anderer Anwendungsteile, die den jeweiligen Dienst
nutzen, ausgetauscht werden. Voraussetzung ist dabei, dass die geänderte Implementierung
einen Dienst mit der gleichen Schnittstelle bereitstellt. Im einfachsten
Fall besteht die Schnittstelle eines Dienstes aus genau einer Operation.
-
Der
zum Bereitstellen und Nutzen von Diensten über ein Netzwerk notwendige
Code wird bei Middleware entweder von Werkzeugen aus einer Beschreibung
des Dienstes erzeugt oder als standardisierte Teillösung bereitgestellt.
Eine Middleware wird entwe der durch die Werkzeuge und die Sprache
zur Beschreibung von Diensten oder den Code der standardisierten
Teillösung
realisiert. Sowohl der Code der standardisierten Teillösung als
auch der von einem Werkzeug aus einer abstrakten Beschreibung erzeugte
Code werden im folgenden als Middleware-Code bezeichnet.
-
Technisch
realisiert Middleware damit über einen
einfachen, bidirektionalen Kommunikationskanal zwischen zwei oder
mehreren Systemen, wie ihn ein Netzwerk bereitstellt, einen Multiplexer.
Dafür vermittelt
Middleware-Code zwischen dem anwendungsspezifischen Code und dem
Netzwerk.
-
Middleware-Code
ist dabei sowohl für
das einen Dienst anbietende Programm, das als Dienst-Server bezeichnet
wird, als auch für
das einen Dienst nutzende Programm, das als Dienst-Client bezeichnet
wird, notwendig. Da sich diese Zuordnung der Rolle des Programms
auf einen konkreten Dienst bezieht, kann ein Programm bezogen auf
einen Dienst Dienst-Server und bezogen auf einen anderen Dienst
Dienst-Client sein.
-
Die
Nutzung eines Dienstes erfolgt bei Middleware über ein Netzwerk, so dass Dienst-Server und Dienst-Client
von verschiedenen Systemen ausgeführt werden können. Die
Kommunikation zwischen ihnen erfolgt zur Laufzeit durch das gegenseitige
Zusenden von Datenpaketen. Der Middleware-Code des Dienst-Clients
fügt dem über das
Netzwerk zu übertragenden
Datenpaket neben den Parametern der Operation automatisch Informationen über den benutzten
Dienst und die Operation hinzu.
-
Der
Middleware-Code des Dienst-Servers nutzt diese Informationen, um
ebenfalls automatisch den Code der Operation des bezeichneten Dienstes mit
den übertragenen
Parametern auszuführen.
Liefert dieser anwendungsspezifische Code ein Ergebnis, so wird
dieses automatisch vom Middleware-Code des Dienst-Servers an den
Dienst-Client zurückgesandt.
Dort übergibt
der Middleware-Code des Dienst-Clients das Ergebnis an den den Dienst
nutzenden, anwendungsspezifischen Code.
-
Der
anwendungsspezifische Code, der den Dienst implementiert, muss beim
Middleware-Code des Dienst-Servers registriert sein, damit er ausgeführt werden
kann. Handelt es sich bei dem Dienst-Server um Software, so kann
das zum Beispiel mit Call-Back-Funktionen
erfolgen, die als Einprungspunkt in den anwendungsspezifischen Software-Code dienen. Handelt
es sich hingegen um Hardware, so kann der Middleware-Code zum Beispiel
Signalleitungen oder Busse bereitstellen, an die anwendungsspezifische
Schaltkreise angeschlossen werden.
-
Dienste
können
von der Middleware sehr unterschiedlich realisiert werden, müssen jedoch
in jedem Fall von einem Dienst-Client eindeutig identifiziert werden
können.
Bei einfachen Diensten, die lediglich eine Operation bereitstellen,
genügt
ein Identifika tionsschlüssel.
Besteht die Schnittstelle eines Dienstes aus mehreren Operationen,
so muss auch die jeweilige Operation eindeutig identifiziert werden können.
-
Die
Methode bzw. das Datenformat, mit dem Dienste und Operationen von
einem Dienst-Client identifiziert werden, definiert die jeweilige
Middleware. Einfache Middleware, wie zum Beispiel Remote Procedure
Call (RPC), erlauben einem Programm dabei die Bereitstellung einer
Reihe von Operationen, die zur Laufzeit einzeln aufgerufen werden
können.
-
Leistungsfähigere Middleware,
wie zum Beispiel CORBA (Common Object Request Broker Architecture)
oder DCOM (Distributed Component Object Model), erlauben einem Programm
die gleichzeitige Bereitstellung verschiedener Dienste, die jeweils von
eigenen Schnittstellen beschrieben werden.
-
Bei
Middleware wird kein Unterschied zwischen den verschiedenen, an
einer verteilten Anwendung beteiligten Programmen gemacht. So kann
ein Programm gleichzeitig einen Dienst anbieten und einen anderen
nutzen, ist also sowohl Dienst-Server als auch Dienst-Client. Bei
größeren Problemen
werden jedoch häufig
unterschiedliche Anforderungen an die verschiedenen Teile einer
verteilten Anwendung gestellt. Daraus resultiert eine Spezialisierung der
verschiedenen Programme zu Server- und Client-Programmen, kurz Server
und Clients.
-
Clients
haben dabei vorrangig die Aufgabe, mit dem Anwender zu interagieren.
Server stellen hingegen vorrangig Dienste bereit, die die Clients nutzen.
Dabei wird ein Client-Prozess
typischerweise von einem einzelnen Anwender benutzt, während ein Server-Prozess mehreren
Client-Prozessen gleichzeitig Dienste zur Verfügung stellt.
-
2. Application-Server
-
Application-Server
stellen eine Abstraktionsschicht oberhalb von Middleware bereit,
die auf die Entwicklung von Server-Programmen spezialisiert ist (siehe 1). Dabei wird die Skalierbarkeit
des Server-Programms erhöht,
indem die enge Verbindung von Middleware-Code und anwendungsspezifischem Code
aufgehoben wird. Bei Middleware bestimmt der Middleware-Code und
seine Konfiguration, die vom anwendungsspezifischen Code vorgenommen
wird, maßgeblich
die Skalierbarkeit eines Server-Programms. Skalierbarkeit bezeichnet
dabei die Anzahl der Client-Prozesse (1.1), die gleichzeitig die
Dienste (1.6) eines Server-Prozesses (1.5) nutzen können. Eine
hohe Skalierbarkeit bedeutet, dass eine große Anzahl von gleichzeitigen
Client-Prozessen von dem jeweiligen Server-Prozess unterstützt wird.
-
Application-Server
realisieren die Trennung von Middleware-Code und anwendungsspezifischem Code,
indem sie jeweils eine durch den Anwender, meist einen Systemadministrator,
konfigurierbare Laufzeitumgebung (1.3) bereitstellen, die den Midd leware-Code
enthält
und damit über
ein Netzwerk nutzbare Dienste bereitstellt. Diese Laufzeitumgebung
kann durch ihre Konfigurierbarkeit an die jeweiligen Laufzeitanforderungen
angepasst werden. Zur Laufzeitumgebung gehören außerdem auch Infrastruktur-Dienste,
die die Nutzung und Realisierung der Dienste unterstützen. Dazu
kann zum Beispiel ein Namensdienst gehören.
-
Der
anwendungsspezifische Code (1.4), das heißt die Implementierung des
oder der Dienste wird der Laufzeitumgebung in einem definierten
Format bereitgestellt und von dieser geladen und ausgeführt. Application-Server
setzen daher voraus, dass der anwendungsspezifische Code im Gegensatz
zur Laufzeitumgebung selbst als Software vorliegen muss. Das dabei
verwendete Format ist oft standardisiert, so dass durch den Einsatz
unterschiedlicher, auf verschiedene Einsatzszenarien spezialisierter
Laufzeitumgebungen die Skalierbarkeit eines Server-Programms an
die jeweiligen Anforderungen angepasst werden kann.
-
Die
Interaktionen zwischen anwendungsspezifischen Code-Stücken und
Laufzeitumgebung werden durch Schnittstellen beschrieben. Im Gegensatz zu
Middleware-Schnittstellen sind die von diesen Schnittstellen beschriebenen
Dienste nur innerhalb des Prozesses nutzbar, von dem die Laufzeitumgebung
und der anwendungsspezifische Code ausgeführt wird.
-
Eine
Laufzeitumgebung kann häufig
mehrere anwendungsspezifische Code-Stücken gleichzeitig laden und
ausführen.
Jedes Code-Stück
implementiert dabei einen oder mehrere Dienste. Der Application-Server
stellt neben der Laufzeitumgebung die notwendigen Werkzeuge bereit,
um diese anwendungsspezifischen Code-Stücke im entsprechenden Format
erzeugen zu können.
-
Der
entscheidende Vorteil von Application-Servern gegenüber Middleware
besteht damit in einer größeren Flexibilität. Das betrifft
insbesondere die Skalierbarkeit der verteilten Anwendung. Während die
Entscheidung über
die konkrete Skalierung einer Anwendung bei Middleware während ihrer
Erstellung getroffen werden muss, kann diese Entscheidung bei Application-Servern
auch erst bei der Installation der Lösung getroffen werden. Außerdem kann
sie später
vergleichsweise einfach revidiert werden, indem die Konfiguration
der Laufzeitumgebung geändert
wird oder eine andere Laufzeitumgebung zum Einsatz kommt.
-
Beispiele
für Application-Server
sind Webserver, die Web-Seiten dynamisch erzeugen. Dabei existieren
verschiedene Standards wie zum Beispiel ASP (Advanced Server Pages),
Java Servlets oder JSP (Java Server Pages), die jeweils andere Anforderungen
an den anwendungsspezifischen Code definieren.
-
Eine
für diese
Erfindung wichtige Gruppe von Application-Servern sind komponentenorientierte
Application-Server (siehe 2).
Bei diesen sind die anwendungsspezifischen Code-Stücken Komponenten
(2.4), die sich zu Anwendungen zusammenstellen lassen. Dafür stellt
der Application-Server Mechanismen bereit, mit denen die Komponenten
zur Laufzeit Dienste gegenseitig anbieten und nutzen können (2.7
oder 2.8). Das ist bei nicht-komponentenorientierten Application-Servern
nicht möglich.
Beispielsweise sind bei Webservern lediglich Webbrowser als Nutzer
von Diensten vorgesehen, aber nicht andere von der Laufzeitumgebung
ausgeführte
Code-Stücken.
-
Da
mehrere Client-Prozesse gleichzeitig den von einer Komponente angebotenen
Dienst nutzen können,
ist es bei zustandsbehafteten Komponenten oft notwendig, dass die
Komponente für
jeden Client-Prozess einen eigenen Zustand verwaltet. Dafür ist eine
Sitzungsverwaltung notwendig, die einige Application-Server automatisch
zur Verfügung
stellen. Steht diese Funktion nicht automatisch zur Verfügung, so
kann der anwendungsspezifische Code dies selbst realisieren, indem
alle den Zustand betreffenden Operationen einen Sitzungsschlüssel als
zusätzlichen
Parameter erhalten, der den jeweiligen Zustand eindeutig identifiziert.
-
Die
automatische Sitzungsverwaltung wird bei komponentenorientierten
Application-Servern häufig dadurch
realisiert, dass eine Komponente einen Komponententyp bereitstellt.
Daneben stellt die Komponente einen standardisierten Dienst bereit,
mit dem Instanzen dieses Komponententyps erzeugt und deren Lebenszyklus
kontrolliert werden kann. Jede Komponenteninstanz besitzt einen
eigenen Zustand und kann eindeutig identifiziert werden.
-
Beispiele
für komponentenorientierte
Application-Server mit automatischer Sitzungsverwaltung sind Enterprise
JavaBeans und Implementierungen des CORBA-Komponentenmodells. Webservice-Plattformen
sind hingegen ein Beispiel für
komponentenorientierte Application-Server ohne eine automatische
Sitzungsverwaltung.
-
Problemstellung
-
Ein
Application-Server stellt innerhalb einer verteilten Anwendung lediglich
Dienste bereit, die von Client-Programmen zur Laufzeit der Anwendung genutzt
werden. Dafür
müssen
diese Dienste eindeutig referenziert werden. Eine Dienstreferenz
enthält
in einer verteilten Anwendung notwendigerweise auch die Netzwerkadresse
des Systems, das den Dienst anbietet. Diese Netzwerkadresse ist
jedoch typischerweise bei jeder Installation einer verteilten Anwendung
unterschiedlich.
-
Bisher
sind für
dieses Problem drei unzureichende Lösungen bekannt:
- 1. Eine Lösung
besteht darin, die Referenzen der Dienste, die ein Client nutzt,
fest im Code des Clients zu hinterlegen. Ein solches Client-Programm kann
beliebig im Netzwerk des Application-Servers verteilt und ausgeführt werden.
Insbesondere Webservice-Plattformen stellen für das Erzeugen des entsprechenden
Client-Codes Werkzeuge bereit. Dabei stellt der Application-Server
eine Beschreibung bereit, aus der ein Code-Fragment generiert wird,
das fester Bestandteil des Clients wird.
Diese Lösung ermöglicht ein
einfaches Verteilen des Client-Programms, erfordert jedoch großen Aufwand,
wenn sich die Netzwerkadresse des Application-Servers ändern, da
damit alle im Client-Code hinterlegten Referenzen ungültig sind. In
diesem Fall ist die manuelle Modifikation des Quellcodes des Clients
erforderlich. Die Netzwerkadresse des Application-Servers ändert sich zum
Beispiel auf Grund von Wartungsarbeiten oder Umstrukturierungen
in seinem Netzwerk. Sie ändert
sich aber auch, wenn die verteilte Anwendung nicht nur in einem,
sondern in weiteren, zusätzlichen
Netzwerken installiert wird.
- 2. Eine weitere Lösung
besteht in der Konfiguration des Client-Programms für ein konkretes
Netzwerk. Dabei wird ein persistenter Speicher wie zum Beispiel
eine Konfigurationsdatei verwendet, der von dem Client-Programm
eingelesen und interpretiert wird. Dieser persistente Speicher enthält die notwendigen
Informationen, um die von dem Client benötigten Dienste zu referenzieren.
Mit
dieser Lösung
wird eine Änderung
des Quellcodes von Client-Programmen vermieden, so dass sich der
Aufwand für
die Anpassung einer Anwendung an eine neue Installation in einem Netzwerk
verringert. Im Gegenzug muss jedoch neben dem eigentlichen Client-Programm
auch der persistente Speicher mit den Konfigurationsdaten verteilt
werden. Das ist mit zusätzlichem Aufwand
verbunden und erschwert die spätere Wartbarkeit
der Clients. Insbesondere muss jeder persistente Speicher aufwändig manuell
geändert werden,
wenn sich die Netzwerkadresse des Application-Servers ändert.
- 3. Eine dritte Lösung
besteht in der Verwendung eines Verzeichnisdienstes. Dabei steht
im Netzwerk ein Standarddienst zur Verfügung, der Referenzen auf anwendungsspezifische
Dienste speichert. Diesen Standarddienst kann auch der Application-Server
selbst bereitstellen. Die von einem Application-Server angebotenen
anwendungsspezifischen Dienste werden in diesem Standarddienst unter
einem vorher vereinbarten Schlüssel
hinterlegt. Ein Client kann mit diesem netzwerkunabhängigen Schlüssel die
netzwerkabhängige
Dienstreferenz bei dem Standarddienst erfragen.
Mit dieser
Lösung
wird das Problem lediglich verkleinert, aber nicht gelöst. Die
Referenz des Standarddienstes muss nach wie vor bei jeder Installation
einer Anwendung in einem Netzwerk dem Client-Programm bekanntgemacht
werden. Dafür kommt
jede der beiden oben beschriebenen Lösungen zum Einsatz, ist jedoch
trotzdem mit den genannten Nachteilen verbunden.
-
Erfindung/Lösung
-
Die
Erfindung, mit der die beim Stand der Technik auftretenden Probleme
gelöst
werden, besteht aus einem Verfahren, das im folgenden beschrieben
wird. Dieses Verfahren wird entweder durch ein Programm oder durch
ein Code-Fragment, das Teil des Application-Servers ist, realisiert.
-
Dieses
Programm oder Code-Fragment des Application-Servers generiert erst
während
der Installation des Clients das eigentliche Client-Programm (siehe 3).
Dabei bettet dieser Code-Generator (3.1) die von dem Client benötigten Referenzen
(3.7) in den Code des Client-Programms (3.8) ein. Auf diese Weise
entsteht ein einfach verteilbarer Client, der auch automatisch,
zum Beispiel durch ein Netzwerk-Dateisystem, E-Mail oder eine ähnliche vorhandene
Technik zu den Client-Computern übertragen
werden kann, wo er einfach gestartet und ausgeführt werden kann.
-
Handelt
es sich bei dem generierten Client-Programm um eine Hardware-Beschreibung, muss
die Hardware zuerst nach der Beschreibung hergestellt werden. Diese
Hardware kann anschließend
einfach an das Netzwerk angeschlossen werden.
-
Der
Code-Generator benötigt
zum einen Daten (3.6) über
den Application-Server (3.5) und die von ihm angebotenen Dienste.
Eine vorteilhafte Ausgestaltung der Erfindung besteht daher darin,
den Code-Generator als Teil des Application-Servers zu realisieren.
In diesem Fall stehen dem Code-Generator durch den direkten Zugriff
auf die internen Verwaltungsdaten des Application-Servers alle benötigten Daten
zur Verfügung.
-
Wird
der Code-Generator als eigenständiges Programm
realisiert, erhält
er die benötigten
Daten indirekt. Ein solches erfindungsgemäßes Installationsprogramm für Clients
erhält
die Daten zum Beispiel durch die manuelle Eingabe der Daten durch
einen Anwender. Eine andere Variante besteht darin, dass der Application-Server
eine Beschreibung der Daten zum Beispiel in Form einer Datei bereitstellt, die
das Installationsprogramm einliest. Eine weitere erfindungsgemäße Ausgestaltung
ist die Verwendung von Middleware für die Kommunikation zwischen
dem Application-Server und dem Installationsprogramm für Clients,
wobei der Application-Server die benötigten Daten über eine
Middleware-Schnittstelle bereitstellt. Weitere Varianten, dem Installationsprogramm
für Clients
die benötigten
Daten bereitzustellen, sind möglich.
-
Neben
den netzwerkspezifischen Daten benötigt der Code-Generator den
netzwerkunabhängigen
Code des Clients (3.2). Bei der Entwicklung dieses netzwerkunabhängigen Codes
wird Code als Platzhalter (3.3) für den von dem Generator erzeugten
Code verwendet. Von einer erfindungsgemäßen Realisierung des Verfahrens
werden sowohl der Code-Generator als auch der dazu passende Platzhalter-Code
bereitgestellt.
-
Der
Platzhalter-Code stellt selbst keine Funktionalität bereit,
sondern dient lediglich dazu, Anforderungen an den während der
Installation des Clients auf ein Netzwerk von dem Code-Generator erzeugten
Code zu beschreiben, so dass dieser generierte Code den Platzhalter-Code
ersetzen kann. Eine mögliche
erfindungsgemäße Definition
dieser Anforderungen kann zum Beispiel durch eine Schnittstellenbeschreibung
erfolgen, die der netzwerkunabhängige
Code nutzt, und die später
von dem generierten netzwerkspezifischen Code bereitgestellt wird.
-
Mit
dieser Erfindung erfolgt die Entwicklung des Clients unabhängig von
dem konkreten Netzwerk, in dem die verteilte Anwendung später ausgeführt wird.
Eine Installation in verschiedenen Netzwerken ist damit einfach
möglich,
da der Quelltext des Clients nicht angepasst werden muss. Lediglich das
Installationsprogramm für
Clients, das auch Teil des Application-Servers sein kann, ist erforderlich.
-
Darüber hinaus
ist auch die Anpassung an Änderungen
an den von dem Application-Server
angebotenen Diensten zum Beispiel durch Wartungsarbeiten einfach
möglich:
Das Client-Programm muss lediglich neu generiert werden. Das kann
automatisch erfolgen, wenn der Client-Generator Teil des Application-Servers
ist und automatisch bei Änderungen
gestartet wird. Die Verteilung der Client-Programme kann ebenfalls
automatisch erfolgen, indem sie zum Beispiel mittels eines Netzwerk-Dateisystems
veröffentlicht
werden oder auch automatisch per E-Mail an die Anwender versandt
werden.
-
Eine
vorteilhafte Ausgestaltung der Erfindung besteht in der Verwendung
eines Verzeichnisdienstes. Dieser Dienst speichert die konkreten
Referenzen, die in dem jeweiligen Netzwerk verwendet werden. Deshalb
enthält
der generierte netzwerkspezifische Code lediglich die Referenz des
Verzeichnisdienstes. Sowohl der netzwerkunabhängige als auch der von dem
Code-Generator bereitgestellte Code kann so mit Hilfe des Verzeichnisdienstes
die Referenzen der anwendungsspezifischen Dienste des Application-Servers
verwenden.
-
Diese
Ausgestaltung hat mehrere Vorteile. Zum einen wird die Realisierung
des Code-Generators
vereinfacht, da in einem konkreten Netzwerk immer der gleiche Code
generiert werden muss. Lediglich die Referenz des jeweiligen Verzeichnisdienstes muss
korrekt eingefügt
werden. Zum anderen muss das Client-Programm nur neu generiert werden, wenn
sich die Referenz des Verzeichnisdienstes ändert. Ändern sich lediglich die Referenzen
anwendungsspezifischer Dienste, so werden diese im Verzeichnisdienst hinterlegt.
Der Client verwendet so auch ohne eine erneute Generierung die aktuellen Referenzen.
-
Eine
besonders vorteilhafte Ausgestaltung der Erfindung ergibt sich in
Verbindung mit komponentenorientierten Application-Servern. Bei
dieser Ausgestaltung erzeugt der Code-Generator das Client-Programm
unter Verwendung von Komponenten. Diese Komponenten werden vom Application-Server dynamisch
geladen. Werden Komponenten für
einen Client verwendet, erzeugt der Code-Generator Code, der die
Komponenten beim Start des Client-Programms statisch, das heißt automatisch
lädt.
-
Bei
dieser Ausgestaltung ist für
die Komponenten eine Laufzeitumgebung erforderlich, die wie die
Laufzeitumgebung des Application-Servers die Netzwerkkommunikation
der Komponenten per Middleware realisiert. Diese Laufzeitumgebung
wird bei dieser Ausgestaltung von dem Code-Generator ebenfalls generiert
oder in Form eines vorgefertigten Code-Fragments, zum Beispiel einer
Software-Bibliothek, durch den Code-Generator dem Client-Programm
hinzugefügt.
-
Damit
ist bei dieser Ausgestaltung die durchgehende Verwendung von einheitlichen
Komponenten für
die Entwicklung der gesamten Anwendung möglich, da sowohl der Server
als auch der Client aus der gleichen Art Komponenten zusammengestellt
wird. Im Gegensatz zu einem Server, der lediglich auf Anweisung
eines anderen Programms Anweisungen ausführt, definiert ein Client notwendigerweise
einen eigenen Hauptkontrollfluss, der die Ausführung des Programms steuert.
Dafür wird
dem Code-Generator ein Einsprungspunkt in eine der Komponenten des
Clients mitgeteilt, die den Hauptkontrollfluss definiert.
-
Beispielrealisierung
-
In
dem nachfolgenden Ausführungsbeispiel wird
die Erfindung am Beispiel des CORBA-Komponentenmodells implementiert.
Dabei erzeugt der Code-Generator, der Teil der Application-Server-Laufzeitumgebung
ist, aus CORBA-Komponenten ein Client-Programm, das automatisch die Dienste
des Servers nutzen kann.
-
CORBA-Komponenten
werden zu Anwendungen, so genannten Assemblies, zusammengestellt.
Ein solches Assembly wird von einem Assembly-Descriptor, einer XML-Datei, beschrieben.
Diese XML-Datei enthält
Daten darüber,
welche CORBA-Komponenten zu einem Assembly gehören, auf welche Laufzeitumgebungen
diese Komponenten jeweils installiert werden sollen, welche Komponenteninstanzen
bei der Initialisierung der Anwendung erzeugt werden sollen und
wie diese miteinander verbunden werden.
-
Das
Format eines Assembly-Descriptors wird wie bei den meisten XML-Dateien
vom Dokumenttyp definiert, der die erlaubte Struktur der Tags, die
die Informationen beschreiben, festlegt. In diesem Fall wird die
XML-Datei in die drei Abschnitte <componentfiles>, <partitioning> und <connections> untergliedert, die
jeweils weitere Tags umschließen.
-
Das
erste Tag <componentfiles> enthält für jede beteiligte
Komponente ein <componentfile>-Tag, das das Archiv
angibt, welches den anwendungsspezifischen Code und Metadaten der
Komponente enthält.
Metadaten sind zum Beispiel die Beschreibung der Schnittstellen
der Komponente und Lizenzbedingungen.
-
Das
für die
Beispielrealisierung der Erfindung entscheidende zweite Tag <partitioning> definiert Nebenbedingungen
für die
Installation von Komponenten. Für
jede zu installierende Komponente wird ein <homeplacement>-Tag angegeben. Wird ein solches Tag direkt
unterhalb des <partitioning>-Tags angegeben, so
kann diese Komponente auf eine beliebige Laufzeitumgebung installiert
werden. Auf diese Weise können
die Komponenten einer Anwendung während der Installation auf
verschiedene Server verteilt werden.
-
Werden
mehrere <homeplacement>-Tags in ein <hostcollocation>-Tag eingeschlossen,
so müssen
diese Komponenten alle auf die gleiche Laufzeitumgebung installiert
werden. Werden mehrere <homeplacement>-Tags in ein <processcollocation>-Tag eingeschlossen,
müssen
diese Komponenten alle im gleichen Prozess ausgeführt werden.
Bei einem <hostcollocation>-Tag steht die Verteilung
der Komponenten auf verschiedene Prozesse der Laufzeitumgebung frei.
Entsprechend können
auch mehrere <processcollocation>-Tags von einem <hostcollocation>-Tag umschlossen werden.
-
Um
nun die Komponenten zu kennzeichnen, die zu einem Client-Programm
gehören,
wird ein neues Tag <clientcollocation> eingeführt. Dieses
Tag kann wie <processcollocation> verwendet werden.
-
Der
Code-Generator erzeugt für
CORBA-Komponenten, die zu einem Client-Programm gehören, den
gleichen Infrastruktur-Code, wie ihn der Application-Server für die von
ihm ausgeführten CORBA-Komponenten
erzeugt. Daneben steht eine Client-Laufzeitumgebung zur Verfügung, die
Dienste bereitstellt, die unabhängig
von den konkreten Komponenten immer benötigt werden. Der Code-Generator
erzeugt aus dem generierten Infrastruktur-Code, der Client-Laufzeitumgebung
und den Komponenten ein Client-Programm.
-
Im
Unterschied zur Application-Server-Laufzeitumgebung, die die Komponentenimplementierung
und den generierten Infrastruktur-Code dynamisch lädt, wenn
die Komponente installiert wird, wird für das Client-Programm von dem
Client-Generator eine Hauptmethode generiert, die die beteiligten Komponenten
und den Infrastrukturcode statisch beim Start des Client-Programms
lädt. Dabei
werden die Tags, die innerhalb eines <homeplacement>-Tags angegeben werden, und zum Beispiel das
Erzeugen initialer Komponenteninstanzen oder das Registrieren von
Komponenteninstanzen bei einem Namensdienst veranlassen, in entsprechende Code-Fragmente
der Hauptmethode abgebildet. Diese Tags mit Anweisungscharakter
werden von der Laufzeitumgebung sonst dynamisch während der
Installation der Komponente interpretiert.
-
Die
Tags des dritten Bereichs-Tags <connections> beschreiben die Verknüpfungen
zwischen den Komponenteninstanzen. Sie haben damit ebenfalls Anweisungscharakter
und werden statisch auf Code-Fragmente für die Hauptmethode abgebildet.
-
Vorteile der
Erfindung
-
Bei
der Verwendung von Application-Servern sind neben dem Server-Programm,
dass aus einer vom Application-Server bereitgestellten Laufzeitumgebung
und dem anwendungsspezifischen Code besteht, Clients für eine verteilte
Anwendung notwendig.
-
Diese
Clients müssen
für jede
Installation an die konkrete Laufzeitumgebung angepasst werden. Das
kann beim Stand der Technik entweder durch eine Modifikation des
Codes oder eine Konfiguration jedes einzelnen Systems erfolgen,
das einen solchen Client ausführt.
Beide Varianten sind sehr aufwändig, können nur
eingeschränkt
automatisiert werden und sind jedesmal zu wiederholen, wenn sich
die Dienstreferenzen des Servers ändern.
-
Mit
dieser Erfindung ist dieser Aufwand überflüssig, da für den Client Code generiert
wird, der die notwendigen Daten enthält und somit die benötigten Dienste
des Application-Servers in einem Netzwerk lokalisiert werden können. Ein
auf diese Weise entstandener Client kann im Gegensatz zum Stand
der Technik einfach verteilt werden. So kann ein Software-Client
zum Beispiel über
ein Netzwerkdateisystem, wie es von den meisten modernen Betriebssystemen
standardmäßig unterstützt wird,
Client-Rechnern zur Verfügung
gestellt werden. Ein Hardware-Client nutzt die von der Laufzeitumgebung
bereitgestellten Dienste nach der Herstellung der Hardware aus der
generierten Hardware-Beschreibung, sobald er an das Netzwerk angeschlossen
wird.