Verbindungsschicht für Datenbanken

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.

Das der Erfindung zugrundeliegende Verfahren erweitert und verbessert das Prinzip der einfachen physischen Lokalisierung der Ressource, wie beispielsweise des bekannten DNS-Systems, indem zusätzlich zum Auffinden der Datenbank ein universelles Verfahren beschreiben wird, um auf Daten einer Zielressource von deren Speicherstruktur unabhängig und effizient zugreifen zu können. Die Strukturunabhängigkeit geht sogar soweit, dass an der Zugriffsschnittstelle zusätzliche Daten angeboten werden können, ohne bestehende Zugriffe ändern zu

müssen. Diese Flexibilität erlauben z.B. WebServices nicht. Ferner ist die Zugriffstechnik für alle Applikationen, die das Verfahren einsetzen, identisch. Somit ergeben sich Vorteile im Hinblick auf vereinfachte Programmierung der Schnittstellen, deren Wart-, Erweiter- und änderbarkeit sowie Performance während der Laufzeit.

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:

Fig. 1 Eine schematische Darstellung des Zugriffs von einer aufrufenden

Applikation über die Verbindungsschicht auf eine datenhaltende Applikation;

Fig. 2 eine schematische Darstellung des Zugriffs von einer aufrufenden

Applikation über die Verbindungsschicht auf bestimmte Dateninhalte einer datenhaltenden Applikation;

Fig. 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 Figur 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 Figur 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 Figur 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 Figur 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 Figur 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.