-
Die
Erfindung betrifft ein Verfahren zur Durchführung eines Zugriffs auf Datenbanken und/oder
Datenfelder und/oder Applikationen in einer Datenverarbeitungsanlage
und/oder in einem Netzwerk von Datenverarbeitungsanlagen, wobei
den Datenbanken und/oder Datenfeldern und/oder Applikationen eine
eindeutige Adresse zugeordnet ist, insbesondere eine IP-Adresse,
ein Servername, ein Pfadname und/oder ein Dateiname oder dergleichen
und eine Datenverarbeitungsanlage mit einer Applikation zur Durchführung des
Verfahrens.
-
Auf
Basis einer Plattform für
Datenbanken existieren mehrere Applikationen. Unter "Applikation" wird das tatsächliche
Programm sowie die von diesem Programm gespeicherten Daten verstanden. Die
Daten können
innerhalb der Applikation oder außerhalb gespeichert sein. Es
wird unterstellt, dass über
die Applikation der Zugriff erfolgt. Diese Applikationen sind für bestimmte
Funktionen miteinander verbunden, um so Daten einer anderen Applikation zu
verwenden. Die aufrufende Applikation muss also wissen, wo die aufzurufende
Applikation zu finden ist und wie die Daten abgefragt werden können. Da
sich im Zeitablauf eine Vielzahl an Applikationen mit einer Vielzahl
an gegenseitigen Verschränkungen
ergibt, ist eine Wartung jeder einzelnen Verschränkung nicht möglich. Ist
es erforderlich, die aufzurufende Applikation zu ändern (z.
B. anderer Server, anderer Datenbankname, andere Feldstruktur, etc.),
müssen Änderungen
an den aufrufenden Applikationen vermieden werden. Zudem sollen
die Zugriffe auf Applikationen möglichst
effizient geschehen, um die Anzahl der Zugriffe und damit die Serverbelastung
möglichst
gering zu halten. In vielen Fällen
werden Server- und Datenbanknamen aufzurufender Applikationen fest
im Programmcode der aufrufenden Applikation hinterlegt. Es sind
Lösungen
bekannt, um diese Server- und Datenbanknamen zu ersetzen. Das grundsätzliche
Problem der fixierten Zugriffswege ist damit dennoch nicht behoben.
Auch sind Lösungen
bekannt, in jeder Applikation Konfigurationen zu hinterlegen und
in dieser dann Server- und Datenbanknamen bzw. eine plattformeigene
Adresse für
abzufragende andere Applikationen anzugeben. Wird eine aufzurufende Applikation
geändert
(z. B. Übersiedelung
auf einen anderen Server), muss mit hohem Aufwand in jeder aufrufenden
Applikation die Konfiguration geändert werden.
Dabei besteht das Risiko, nicht alle aufrufenden Applikationen zu
kennen.
-
Der
Abruf der Daten selbst erfolgt mittels Zugriff auf Feldebene. Dazu
muss der gewünschte
Datensatz gefunden, geöffnet
und dann im Datensatz das Feld abgerufen werden. Dieses Vorgehen
ist – abhängig von
der verwendeten Plattform – hinsichtlich
der Performance nicht optimal. Bekannte Lösungen widmen sich dem Problem,
unterschiedliche Systeme und Datenbanken zu koppeln. Dabei steht also
eine "Übersetzung" jeweils spezifischer
Eigenheiten in eine allgemeinere Form bzw. in spezifische Eigenheiten
eines anderen Systems im Vordergrund.
-
Die
Aufgabe der Erfindung ist es, ein Verfahren und eine Datenverarbeitungsanlage
zur Verfügung
zu stellen, durch die die genannten Nachteile überwunden werden und es insbesondere
verhindert wird, dass es übersehen
werden kann, eine bestimmte Applikation in komplexen Systemen an
eine geänderte
Datenstruktur oder Serverstruktur anzupassen.
-
Diese
Aufgabe wird erfindungsgemäß durch ein
Verfahren gemäß Anspruch
1 und durch eine Datenverarbeitungsanlage nach Anspruch 10 gelöst.
-
Besonders
vorteilhaft ist dabei, dass bei dem Verfahren zur Durchführung eines
Zugriffs auf Datenbanken und/oder Datenfelder und/oder Applikationen in
einer Datenverarbeitungsanlage und/oder in einem Netzwerk von Datenverarbeitungsanlagen,
wobei den Datenbanken und/oder Datenfeldern und/oder Applikationen
eine eindeutige Adresse zugeordnet ist, insbesondere eine IP-Adresse,
ein Servername, ein Pfadname und/oder ein Dateiname oder dergleichen,
jeder Datenbank und/oder jedem Datenfeld und/oder jeder Applikation
ein Alias eineindeutig zugeordnet ist und zumindest eine Zuordnungsinstanz vorgesehen
ist, in der die Zuordnung von Alias zu Adresse gespeichert und von
dieser abrufbar ist, und dass eine Verbindungsinstanz vorgesehen
ist, die bei einem versuchten Zugriff auf Datenbanken und/oder Datenfelder
und/oder Applikationen unter Verwendung des Alias die Adresse aus
der Zuordnungsinstanz abruft und sodann unter Verwendung der von der
Zuordnungsinstanz erhaltenen Adresse auf die Datenbanken und/oder
Datenfelder und/oder Applikationen zugreift.
-
Das
erfindungsgemäße Verfahren
widmet sich nicht der Übersetzungsproblematik
unterschiedlicher Systeme, wenngleich eine Koppelung des Verfahrens
mit einem Übersetzungsverfahren
denkbar ist. Bei dem geschilderten Verfahren werden Applikationen
innerhalb eines Systems lediglich über ihren Alias identifiziert.
Unter "System" wird hierbei verstanden,
dass die Applikationen die gleiche Plattform benutzen, z. B. ihre
Daten in unterschiedlichen Datenbanken desselben Herstellers ablegen.
Die Datenbanken können
auf derselben oder auf einer anderen Hardware laufen. Je mehr Datenbanken und/oder
Server betroffen sind, desto größer wird
der Vorteil des Verfahrens. Eine Verbindungsschicht, d. h. eine
Verbindungsinstanz, setzt den Alias in eine physikalische Applikation,
d. h. die tatsächliche Adresse
um. Die Verbindungsschicht bietet den Applikationen bestimmte Schnittstellen,
um andere Applikationen abzufragen. In einer zentralen Konfiguration,
d. h. in einer Zuordnungsinstanz, ist hinterlegt, welche physikalische
Applikation sich hinter einem Alias verbirgt.
-
Weitere
vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.
-
Vorzugsweise
ist die Zuordnungsinstanz eine zentral abgelegte Instanz, insbesondere
in Form einer Datenbank. Alternativ kann die Zuordnungsinstanz durch
synchronisierte Vervielfältigungen
auf einer Mehrzahl von Datenverarbeitungsanlagen gebildet sein.
-
In
einer bevorzugten Ausführungsform
des erfindungsgemäßen Verfahrens
ist sowohl jeder zugreifenden Applikation als auch jeder Applikation,
auf die zugegriffen werden soll, jeweils ein Alias zugeordnet ist.
Die Zuordnung von Alias zu Applikation bzw. Adresse ist in der Zuordnungsinstanz
als zentrale Konfiguration hinterlegt und dort abfragbar.
-
Vorzugsweise
werden einzelne Datenfelder und/oder Datenfeldinhalte einer Datenbank
indiziert.
-
Es
ist möglich,
dass jede Applikation bei einem Start zunächst ihren eigenen Alias durch
Abfrage bei der Zuordnungsinstanz abfragt.
-
Bevorzugt
werden Dateninhalte einer Datenbank über die Verbindungsinstanz
an die anfragende Applikation zurückgegeben.
-
Die
Verbindungsinstanz kann eine Datenverarbeitungsinstanz aufweisen,
die geeignet ist, die erhaltenen Daten vor einer Übergabe
an die anfragende Applikation zu verarbeiten. Alternativ oder kumulativ
kann die Verbindungsinstanz einen Datenpuffer aufweisen, der geeignet
ist, die erhaltenen Daten zumindest zeitweise zu speichern.
-
Der
Verfahrensablauf in einer besonders bevorzugten Ausführungsform
ist nachfolgend beschrieben.
-
Für den Abgriff
einzelner Daten werden Indizes benutzt, so dass ein performanceoptimierter
Zugriff auf den Index genutzt werden kann und nicht auf Feldebene
erfolgt. Über
den Index können
die Daten zudem bereits in einer vorverarbeiteten Form zur Verfügung gestellt
werden, um so die Zugriffszeiten zu reduzieren. Der Zugriff auf
den Index erfolgt ebenfalls über
die Verbindungsschicht. Dabei werden die Daten mit einem Alias maskiert,
um eine Entkopplung der abfragbaren Datennamen von den zugrunde
liegenden Feldnamen zu erreichen. In einer zentralen Konfiguration
ist hinterlegt, welche Indizes mit welchen Datenaliasen zur Verfügung stehen.
-
Bei
dem geschilderten Verfahren rufen sich Applikationen gegenseitig über den
jeweiligen Alias auf. Bei Änderungen
z. B. am Server oder/und Namen einer Applikation ist lediglich an
einer Stelle (der zentralen Konfiguration) die Zuordnung
Alias – physikalische
Applikation (Adresse)
anzupassen, um sofort alle Aufrufe dieser
Applikation an die neue physikalische Applikation zu leiten. Dieser
Vorteil wird größer, je
mehr Applikationen miteinander kommunizieren.
-
Über den
Index und dessen Maskierung mittels Aliasen wird eine Entkoppelung
von den tatsächlichen
Feldnamen erreicht. Ändern
sich Feldnamen der aufzurufenden Applikation muss lediglich der
Indexaufbau angepasst werden. Der Alias, mit dem das Datenelement
nach außen
aufscheint, bleibt unverändert.
Somit sind an aufrufenden Applikationen keine Änderungen notwendig. Zudem
können
zum Index an beliebiger Stelle weitere Datenelemente hinzugefügt werden,
ohne bestehende Abfragen gegen den Index zu gefährden (die Aliasdefinition
muss natürlich
den Indexaufbau korrekt wiedergeben).
-
Das
Verfahren arbeitet mit doppelter Maskierung, d. h. der eineindeutigen
Zuordnung von Alias zu Applikation bzw. Adresse und Alias zu Datenelement: Applikationsmaskierung
und Datenmaskierung. Der Zugriff auf Applikationen und Daten erfolgt über eine Verbindungsschicht,
d. h. über
eine Verbindungsinstanz. Sämtliche
Angaben zur Maskierung sind in einer zentralen Konfiguration, d.
h. in einer Zuordnungsinstanz hinterlegt. Diese Konfiguration ist
so gespeichert, dass sie von allen Applikationen erreicht werden
kann, um daraus Daten zu lesen. Denkbare Ausführungsvarianten für diese
zentrale Konfiguration sind:
- – eine zentral
abgelegte Instanz
- – eine
synchronisierte Kopie auf allen Servern
- – algorithmisch
bestimmbare Instanzen
-
Da
es sich hierbei nur um eine Hintergrundapplikation handelt, ist
die einzige Einschränkung
die, dass alle Applikationen Zugriff haben müssen. Die zentralen Konfigurationsdaten
haben in nur geringen Umfang und sind wenigen Änderungen unterworfen. Deshalb
kann der Zugriff auf diese Konfigurationsdaten sehr schnell erfolgen,
so dass keine merkbaren Leistungseinbußen zu verzeichnen sind. Die gesamte
Implementierung der Maskierungen ist in der Zwischenschicht verborgen
und wird von jeder Applikation benutzt. Je nach dem, ob auf die
Applikation selbst oder auf die Daten zugegriffen werden soll, ist
die Maskierung entsprechend umzusetzen und zu konfigurieren. Die
Zwischenschicht bietet leistungsfähige Schnittstellen, über die
der jeweilige Zugriff auf die Daten bzw. die Applikation erfolgt.
-
Drei
Ausführungsbeispiele
des erfindungsgemäßen Verfahrens
oder Systems sind in den Figuren dargestellt und werden nachfolgend
erläutert.
Es zeigen:
-
1 Eine
schematische Darstellung des Zugriffs von einer aufrufenden Applikation über die Verbindungsschicht
auf eine datenhaltende Applikation;
-
2 eine
schematische Darstellung des Zugriffs von einer aufrufenden Applikation über die Verbindungsschicht
auf bestimmte Dateninhalte einer datenhaltenden Applikation;
-
3 eine
schematische Darstellung des Zugriffs von einer aufrufenden Applikation über die Verbindungsschicht
auf vollständige
Datensätze
einer datenhaltenden Applikation.
-
Die
Applikationsmaskierung erfolgt wie in 1 dargestellt.
Jede Applikation verfügt
in der zentralen Konfiguration einen Maskierungseintrag aus zwei
Elementen:
- – Alias der Applikation
- – Physikalische
Applikation (z. B. Server- und Dateiname oder andere geeignete Parameter,
die für den
Aufruf der Applikation notwendig sind)
-
Beim
Start einer Applikation ermittelt sie ihren eigenen Alias, indem
sie den zu ihrer physikalischen Lokation (tatsächliche Adresse) gehörenden Alias
abfragt. Damit ist es der Applikation möglich, ihre eigene "Identität" zu ermitteln und
z. B. in Nachrichten an andere Applikationen mitzugeben bzw. weitere
Konfigurationen, die sie selbst betreffen, aus der zentralen Konfiguration
zu lesen.
-
Möchte eine
Applikation eine andere Applikation kontaktieren, fragt sie anhand
des Alias der Zielapplikation die physikalische Applikation bei
der Zwischenschicht nach. Die Zwischenschicht liefert daraufhin
eine entsprechende Zugriffsmöglichkeit
zurück.
Diese Funktionalitäten
sind derart in der Zwischenschicht eingebaut, dass für die beteiligten
Applikationen nicht mehr direkt miteinander kommunizieren. Die Zwischenschicht
nimmt alle Anfragen und Antworten der beteiligten Applikationen
an und reicht sie an den jeweiligen Adressaten weiter. Ruft eine Applikation
eine andere Applikation auf, erfolgt der Aufruf wie in 1 dargestellt
nach folgendem Schema:
- 1. Die aufrufende Applikation
A stellt an die Verbindungsschicht V eine Abfrage, in der sie den
Alias der aufzurufenden Applikation C übergibt.
- 2. Die Verbindungsschicht V stellt eine Anfrage an die Zentrale
Konfiguration B, in der sie den Alias der aufzurufenden Applikation
C weitergibt.
- 3. Aus der Zentrale Konfiguration B wird die zum Alias gehörende physikalische
Applikation C zurückgeliefert
an die Verbindungsschicht V.
- 4. Die Verbindungsschicht V ruft die zum Alias gehörende physikalische
Applikation C auf.
- 5. Die Verbindungsschicht V liefert die aufgerufene Applikation
C z. B. als Objekt an die aufrufende Applikation A zurück.
-
In
der aufrufenden Applikation A müssen
somit keinerlei physikalische Daten der aufzurufenden Applikation
C hinterlegt werden. Die Kommunikation erfolgt ausschließlich über die
Verbindungsschicht V und kann vollständig hinter dem Alias maskiert
werden. Lediglich in der zentralen Konfiguration B ist auf die korrekte
Zuordnung von Alias und physikalischer Applikation zu achten. Ändert sich
die aufgerufene Applikation C, wird diese Änderung in der zentralen Konfiguration
abgebildet. Nach dieser Abbildung verwenden sofort alle aufrufenden
Applikationen die neue physikalische Applikation, ohne dass zusätzliche Änderungen
bei den aufrufenden Applikationen notwendig sind.
-
Die
Datenmaskierung ist schematisch in 2 dargestellt.
-
Die
Maskierung der Daten ist eine Erweiterung der Applikationsmaskierung.
Für jede
Applikation, die Daten für
andere Applikationen zur Verfügung stellt,
wird mindestens ein Index errichtet, der einen geeigneten Suchschlüssel sowie
zusätzlich
Daten enthält.
Ein Index ist somit nicht nur ein Zugriffsweg zur Identifikation
bestimmter Daten, sondern dient der Zwischenschicht dazu, die Daten
tatsächlich
aus der aufgerufenen Applikation zu lesen. Eine Applikation kann über mehrere
Indizes verfügen,
um z. B. die Performance der einzelnen Indizes zu verbessern oder
unterschiedliche Arten von Daten darstellen zu können.
-
In
der zentralen Konfiguration wird für jeden Index eine Abfragekonfiguration
hinterlegt aus folgenden Elementen:
- – Name der
Abfragekonfiguration zur Identifikation
- – Alias
der Applikation, aus der die Daten gelesen werden sollen
- – Name
des Index in der Applikation
- – Liste
mit Aliasnamen für
die einzelnen Datenelemente, die der Index darstellt
-
Um
Daten aus einer anderen Applikation abzufragen, muss bei der Abfrage
lediglich die zu verwendende Abfragekonfiguration, der Suchschlüssel sowie
der Alias des gewünschten
Datenelements angegeben werden. Ruft eine Applikation Daten aus
einer anderen Applikation ab, erfolgt der Aufruf wie in 2 dargestellt:
- 1. Die Applikation A ruft die Verbindungsschicht
V auf, um Daten aus Applikation C zu erhalten.
- 2. Die Verbindungsschicht richtet eine Abfrage an die Zentrale
Konfiguration B mit dem Namen der Abfragekonfiguration.
- 3. Die Zentrale Konfiguration B meldet den Alias der abzufragenden
Applikation C zurück.
- 4. Die Verbindungsschicht V richtet eine Abfrage an die Zentrale
Konfiguration B mit dem Alias der abzufragenden Applikation C.
- 5. Aus der Zentralen Konfiguration B wird die zum Alias gehörende physikalische
Applikation C zurückgemeldet.
- 6. Aus der Zentralen Konfiguration B wird der Name des Index
in der physikalischen Applikation C zurückgemeldet, der die gewünschten
Daten enthält.
- 7. Aus der Zentralen Konfiguration B wird eine Liste mit Aliasen
der im Index verfügbaren
Daten zurückgemeldet.
- 8. Die Verbindungsschicht V greift auf die physikalische Applikation
C aus (5) zu.
- 9. Die Verbindungsschicht V greift auf den Index aus (6) zu.
- 10. Die Verbindungsschicht V sucht den zum Suchschlüssel passenden
Datensatz im Index.
- 11. Die Applikation C liefert die gesamten Indexdaten des Datensatzes
aus (10) an die Verbindungsschicht V. Diese Daten werden im Datenpuffer
P abgelegt.
- 12. Die Verbindungsschicht V extrahiert aus den gesamten Indexdaten
im Puffer P aus (11) die Daten mit dem gewünschten Datenelementalias.
- 13. Die Verbindungsschicht V liefert die gewünschten Daten an die aufrufende
Applikation A.
-
Da
die Verbindungsschicht V die Daten für die aufrufenden Applikationen
A aus der Quellapplikation C abruft und dabei die gesamten Indexdaten liest
(vgl. Schritt 11), können
die abgerufenen Daten im Datenpuffer P der Verbindungsschicht V
zwischengespeichert werden. Erfolgt ein erneuter Abruf von Daten
für denselben
Datensatz, kann die Verbindungsschicht V die Daten unmittelbar,
d. h. ohne erneuten Zugriff auf die Zentrale Konfiguration B oder die
Quellapplikation C, zur Verfügung
stellen. Je mehr Daten also für
einen Datensatz abgefragt werden, desto deutlicher der Performancegewinn
gegenüber
eines Zugriffs ohne die hier dargestellte Technologie. Zudem sind
in der Verbindungsschicht V robuste Mechanismen hinterlegt, die
Datenfehler abfangen und so Abbruche in der aufrufenden Applikation
A verhindern.
-
Auf
Basis dieses Verfahrens sind weitere Technologien möglich. Dabei
werden – aus
Sicht der aufrufenden Applikation – vor der Datenabfrage weitere
Schritte in der Verbindungsschicht angeboten. Werden z. B. für verschiedene
Applikationen immer wieder dieselben Daten benötigt (z. B. für eine Kundenapplikation
Kundenname, – adresse
etc.), kann die Verbindungsschicht ein Verfahren zur Verfügung stellen,
das automatisch die gewünschten
Daten vollständig
liefert. Hierfür
wird in der zentralen Konfiguration eine Definition abgelegt, die
eine Datenmaskierung und eine Datenelementaliasliste aufweist.
-
Um
alle Daten der Liste zu erhalten, muss die aufrufende Applikation
eine Anfrage an die Verbindungsschicht stellen und dabei den Konfigurationsnamen
sowie den Suchschlüssel übergeben. Wird
dieses Verfahren eingesetzt, sind selbst umfangreiche Datenabfragen
mit minimalem Aufwand in der auf rufenden Applikation realisierbar.
Zudem lassen sich die Vorteile der Applikationsmaskierung sowie
die Vorteile der Datenmaskierung in vollem Umfang nutzen. Ruft eine
Applikation auf diese Weise Daten ab, erfolgt der Aufruf wie in 3 dargestellt:
- 1. Die Applikation A ruft die Verbindungsschicht
V auf und übergibt
Konfigurationsname sowie Suchschlüssel.
- 2. Die Verbindungsschicht V fordert die Konfiguration von der
zentralen Konfiguration an B.
- 3. Aus der zentralen Konfiguration B wird die entsprechende
Datenmaskierung zurückgeliefert.
- 4. Aus der zentralen Konfiguration B wird die entsprechende
Datenelementaliasliste zurückgeliefert.
- 5. Die Verbindungsschicht V iteriert über die Datenelementaliasliste.
Für jeden
Durchlauf ruft sie die Daten über
das oben beschriebene Verfahren zur Datenmaskierung ab (dargestellt
durch die gestrichelten Linien), wobei der Datenpuffer der Verbindungsschicht
V benutzt wird.
- 6. Die Verbindungsschicht V gibt die gesamten ermittelten Daten
an die aufrufende Applikation A zurück.
-
Darauf
aufbauend sind weitere Erweiterungen möglich. So kann die Verbindungsschicht
die Daten nicht nur an die aufrufende Applikation zurückliefern,
sondern bearbeiten und erst das Ergebnis retournieren. Dadurch kann
die Vermittlungsschicht zentral Werkzeuge zur Verfügung stellen,
die von mehreren Applikationen genutzt werden können, zentral wartbar sind
und die Vorteile der Applikations- und Datenmaskierung nutzen.