Objektorientierung macht Komplexitaet und Altlasten ertraeglich BLKA entwickelt fuer bayerische Polizei ausgefeiltes DV-Konzept

08.04.1994

Die Komplexitaet einer Client-Server-Architektur laesst sich nach Erfahrung von Stefan Foertsch* am besten dadurch in den Griff bekommen, dass einzelne Softwarefunktionen als Methoden auf eigenstaendigen Objekten definiert werden. Er entwarf fuer die bayerische Polizei ein Client-Server-Konzept, das die Integration von Altsystemen und modernen Loesungen vorsieht.

Das Bayerische Landeskriminalamt (BLKA) entwickelt zur Zeit das Integrationsverfahren der bayerischen Polizei (IGV-P) auf der Basis einer neuen offenen und objektorientierten Client-Server- Architektur. Die DV-Umgebung besteht derzeit aus zwei BS2000- Mainframes, 500 Unix-Mehrprozessorsystemen, 8000 Arbeitsplatzrechnern sowie 2500 Druckern, die ueber Datex-P und ISDN miteinander kommunizieren. Ziel ist die Integration der Daten aus der Vorgangsverwaltung und bestehenden Anwendungen, um die Dienstkraefte und Fuehrungsdienststellen umfassender zu unterstuetzen.

Die Integration in einer heterogenen DV-Landschaft allein mit Standards bewerkstelligen zu wollen ist aufgrund der unterschiedlichen Realisierungsstrategien der Hersteller nur theoretisch moeglich. Diverse Werkzeuge unterstuetzen den Entwickler zwar bei der Definition und Erstellung von Client-Server- Anwendungen auf Basis von Remote Procedure Calls (RPC). Mit wachsenden Anspruechen an verteilte Anwendungen zeigt sich jedoch, dass selbst diese Hilfsmittel nicht ausreichen, um komplexe, komfortable Client-Server-Anwendungen zu realisieren.

Die Geschlossenheit der Systeme manifestiert sich nicht mehr auf der Ebene der Netz- und Kommunikationsprotokolle, sondern gewissermassen eine Etage hoeher, auf der Anwendungsschicht. Hier fehlen komplette Architekturen fuer die Zusammenarbeit verschiedener Applikationen.

Architektur muss freie Wahl des Herstellers gestatten

Altsysteme zu sanieren und zu portieren beziehungsweise grosse Summen in neue Systeme zu investieren macht nur dann Sinn, wenn das Resultat eine zumindest mittelfristige Ueberlebenschance besitzt. Eine zukunftsorientierte Systemarchitektur als Integrationsbasis ist deshalb anwendungsunabhaengig und erweiterbar zu gestalten. Sie darf der Entscheidung, von welchem Hersteller Hard- und Software kommt, nicht vorgreifen. Die Wahl fiel beim BLKA zugunsten der Client-Server-Technologie aus, weil diese DV- Struktur in den kommenden Jahren dominieren wird.

Das Client-Server-Prinzip basiert auf der logischen Arbeitsteilung zwischen dem Client, der Dienste anfordert, und dem Server, der Dienste liefert. Die Art der Arbeitsteilung kann sehr verschieden sein und haengt sowohl von der Leistungsfaehigkeit der miteinander verbundenen Geraete als auch von anderen Faktoren wie Kapazitaet des Netzes, Verfuegbarkeit von Tools etc. ab.

Bei der Verteilung von Daten ergeben sich jedoch insbesondere in einem WAN (Wide Area Network) viele Probleme, fuer die der Markt derzeit kaum fertige Loesungen anbietet - schon gar nicht fuer eine heterogene Umgebung. Bei relationalen Datenbanksystemen stehen zum Beispiel eine Vielzahl von Tabellen in komplexen Beziehungen zueinander. Da diese bei der Normalisierung verlorengehen, muss die Anwendung die Navigation durch die Tabellen uebernehmen. Die Pflege von referentiellen oder komplexen Integritaeten kann zum Alptraum werden. Ebenso ist bei Suchanfragen das Uebertragen von sehr umfangreichen Result-Sets (Treffermengen) meist unwirtschaftlich, um nicht zu sagen: nicht tragbar.

Nicht nur deshalb bewerten fuehrende Beratungsunternehmen das Distributed-Function-Modell als das flexibelste und effektivste. Hierfuer wird auch der Begriff des Cooperative Processing verwendet, der eher den integrativen Aspekt wiedergibt. Einzelne Softwarefunktionen muessen nur einmal installiert werden und sind mehrfach verwendbar, alle angeschlossenen Clients koennen ueber das Netz darauf zugreifen.

Werden Funktionen in Servern als ein eigenstaendiger Prozess mit definierten Schnittstellen zusammengefasst, erreicht man einen Grad der Modularisierung, der in herkoemmlichen Systemen nicht zu finden ist. Der Austausch eines Servers oder die Installation mehrerer Server mit einer Lastverteilung ist nur noch eine Frage der Portabilitaet dieser Software. Andere Teile des Softwaresystems sind nicht mehr betroffen, solange sie sich an das vereinbarte Protokoll halten. Verteilbarkeit zaehlt infolgedessen zu den neuen Qualitaetsmerkmalen von Programmen. Die Verfahren sind allerdings deutlich komplexer als bei zentralen oder dezentralen Stand-alone- Loesungen (Schaetzungen sprechen von einem Faktor 9).

Unsere vereinfacht dargestellte Client-Server-Architektur (siehe Abbildung 1) ist generisch beschrieben hinsichtlich Praesentation, Kommunikation, Objektmanipulation, Systemumgebung und Datenzugriff. Es kommt vor allem auf die richtige Menge von generellen Schnittstellen an, um unabhaengig von Hardware-, Systemsoftware- und Netzarchitektur zu werden.

Die Komplexitaet laesst sich allerdings nur mit einer als Single- System-Image definierten Client-Server-Loesung bewaeltigen: Verschiedene Einzelsysteme stellen sich dem Benutzer wie dem Anwendungsprogrammierer als ein System dar, die Lokalitaet der Daten beziehungsweise der Diensterbringer bleiben transparent.

Objektorientierte Konzepte bieten hierfuer den besten Ansatz. Sie betrachten das Netz zunaechst nicht als Ansammlung von Rechnern, die verschiedene Dienste anbieten, sondern als eine Reihe von Objekten. Diese verteilten Objekte lassen sich in einem heterogenen Netz mit den von ihnen bereitgestellten Methoden beliebig manipulieren, ohne dass Netztopologien, Rechnertypen, Ort und Lage der Verfahrensobjekte etc. zu beruecksichtigen sind.

Bei gaengigen Client-Server-Loesungen muss der Anwender beziehungsweise die Applikation, die einen Dienst anfordert, zumindest den zustaendigen Server kennen (zum Beispiel Namen und Internet-Adresse); die Verlagerung eines Dienstes ist dem Client mitzuteilen.

Die objektorientierte Client-Server-Architektur uebernimmt diese Aufgabe und macht Strukturen und Topologien eines DV-Systems vollstaendig transparent. Objekte und ihre Kommunikationsbeziehungen werden im heterogenen Netz implementiert, unabhaengig von der gerade gueltigen Netztopologie, den objektmanipulierenden Methoden und der Lage anderer Objekte. Applikationen und Methodenprogramme brauchen sich nur noch um den Inhalt der Kommunikation zu kuemmern.

Dieser Client-Server-Ansatz beseitigt damit ein entscheidendes Manko heutiger Standards: Sie definieren zwar Mechanismen fuer spezifische Anforderungen - oft nur fuer die reine Konnektivitaet -, es fehlt aber ein Rahmenwerk fuer die Zusammenarbeit verschiedener Applikationen, um die Komplexitaet zu bewaeltigen. Durch das objektorientierte Konzept koennen wir dagegen mit relativ geringem Aufwand aus Applikationen neuester Technologie auf inzwischen weitgehend veraltete Softwaresysteme zugreifen und umgekehrt.

Anwendungen werden in kleinere Objekte zerlegt und lassen sich so je nach Einsatzfall kon- figurieren. Wichtigste Voraussetzung fuer die Verteilung ist aber eine Software-Architektur, die auf einem Schichtenmodell beruht: Praesentationsebene (Benutzeroberflaeche), Anwendungsschicht und Daten- beziehungsweise Diensteebene muessen durch entsprechende Programm-Schnittstellen logisch voneinander getrennt sein. Nur so laesst sich die gewuenschte Granularitaet und Verteilbarkeit erreichen. Als schichtspezifische Objekte ordnet das BLKA

- die Dialogobjekte der Praesentationsschicht,

- die Anwendungsobjekte der Anwendungsebene sowie

- die Daten- beziehungsweise Diensteobjekte der Datenschicht zu.

Ein Objekt gilt als eine autonome, aktive Instanz, die mit anderen ausschliesslich ueber Nachrichten kommuniziert. Beim Entwurf der Benutzeroberflaeche traegt man dem gewoehnlich Rechnung, indem Eingaben des Benutzers als Nachrichten an auf der Oberflaeche sichtbare Objekte behandelt werden.

Eine Benutzeroberflaeche besteht aus

- Dialogobjekten mit Praesentations-Manager,

- Dialogsteuerung und

- Dialogkontrolle.

Der Praesentations-Manager bereitet zusammen mit den Dialogobjekten die Anwendungsdaten fuer den Benutzer und die Benutzerdaten fuer die Dialogsteuerung auf. Die physische Praesentation des Menues ist in den Objekten der Bedienoberflaeche verborgen. Erfolgt zum Beispiel die Auswahl ueber Funktionstasten, sind nur die Dialogobjekte betroffen. Die Anwendungsobjekte koennen unveraendert bleiben.

Mit Hilfe der Dialogkontrolle kann man pro Applikation bestimmen, welche Dialogfunktionen dem Benutzer zur Verfuegung stehen. Sie ist Bestandteil der Dialogsteuerung und laesst sich in Anwendungen mit Teilnehmer- beziehungsweise Teilhaberbetrieb einbinden oder als eigenstaendiger Dialog-Server implementieren.

Die Dialogsteuerung verwaltet alle eingehenden Informationen entsprechend den Vorgaben der Dialogkontrolle. Sie entscheidet, ob ein Dialog- oder ein Anwendungsobjekt aktiviert wird. Solange Nachrichten nur an Dialogobjekte gerichtet sind, etwa bei Help- und Menue-Funktionen, werden diese in direkter Kooperation mit dem Praesentations-Manager und gewissermassen ausserhalb der Applikation bearbeitet. Anwendungsrelevante Ereignisse loesen Nachrichten an die entsprechenden Anwendungsobjekte aus.

Zum Austausch von Informationen zwischen Dialogobjekten, Dialogsteuerung und Anwendungsobjekten wurden die Dialog- Schnittstelle und das Dialogprotokoll definiert und implementiert. Dies erlaubt die Entkopplung der unterschiedlichen Objektklassen auf der hoechstmoeglichen Abstraktionsebene. Das gleiche Anwendungsobjekt ist somit ohne Anpassungsaufwand sowohl innerhalb grafischer als auch alphanumerischer Oberflaechen verwendbar.

Der wesentliche Ansatz der Datenobjekte ist, dass nur bestimmte, genau definierte Methoden zugelassen sind, die das Modell in einem konsistenten Zustand zuruecklassen. Wo bisher Daten ohne ihre Semantik und ihre Methoden in einer Datenbank abgelegt wurden, soll die Funktionalitaet Teil der Datenobjekte sein. Dabei ist eine saubere Trennung zwischen Ablauffunktionen und essentiellen, an Daten gebundenen Funktionen, den Methoden, erforderlich.

Die Methoden stellen so eine zentrale semantische Schicht dar. Da mit jeder von ihnen auch das Pruefen von komplexen Integritaetsregeln verbunden ist, laesst sich ueber die Abbildung dieser Integritaeten im Datenmodell ein ansonsten redundantes Coding mit den verbundenen Nachteilen verhindern (erhoehter Entwicklungsaufwand, schlechte Wartbarkeit, Fehleranfaelligkeit etc.).

Als Teil des unternehmensweiten Datenmodells laesst sich so ein Applikations-uebergreifendes System von Geschaeftsregeln modellieren und in Servern implementieren. Ausserdem steigert diese Architektur die Performance, da einzelne Statements nur noch mit jedem Methodenaufruf zu einer Kommunikation zwischen Front-end und Server fuehren. Damit stellt diese Architektur per se die Loesung des Problems der verteilten Datenhaltung in einem WAN dar.

Die Geschaeftsvorfaelle, etwa bestimmte Arbeitsablaeufe in der Vorgangsbearbeitung, werden als Ablaufsteuerung in den Anwendungsobjekten und in der Dialogsteuerung implementiert. Da sich die Ablaufsteuerung einer Applikation haeufig aendert, werden mit dieser Aufteilung systemabhaengige und besonders dynamische Teile vom stabilen semantischen Datenmodell isoliert. Die Modellierung neuer oder geaenderter Geschaeftsvorfaelle laesst sich einfach als neue Kombination bereits vorhandener Methoden ansehen.

Die Datenzugriffsschicht neutralisiert eventuell DBMS-spezifische (Database Management System) Schnittstellen. Unsere neuen Applikationen brauchen infolge einheitlicher Aufruf-Schnittstellen nur die Methoden mit ihren Parametern zu kennen, nicht jedoch deren Implementierung, den zustaendigen Server, dessen Standort und wie die Kommunikation damit zustande kommt. Die Methoden sorgen bei Objektmanipulationen fuer die Integritaet und Konsistenz der Daten. Einmal entwickelte Funktionen stehen allen Applikationen zur Verfuegung.

Das Ziel eines Single-System-Images vor Augen, folgen alle Schnittstellen-Implementierungen der Grundimplementierung (siehe Abbildung 2). Die Anwendung erteilt einen Auftrag ueber eine servicespezifische, systemneutrale Anwendungs-Schnittstelle. Den nimmt der Auftraggeber (Client) entgegen, der den Auftragnehmer (Server) kennt und mit diesem ueber das Dienstzugangsprotokoll kommuniziert. Je nachdem, ob der Auftragnehmer lokal oder auf einem anderen Rechner implementiert ist, werden Kommunikations- Systeme mit einbezogen. Das geschieht transparent durch den Kommunikations-Server.

Der Kommunikations-Server bietet den Client-Server-Applikationen eine Kommunikations- oder auch Auftrags-Schnittstelle an, ueber die sie

- Auftraege erteilen, entgegennehmen und beantworten,

- Auftragsantworten abholen,

- Anwendungen im Teilnehmerbetrieb reservieren sowie

- Informationen einholen koennen.

Der Kommunikations-Server uebernimmt anstelle der Applikationen die Orientierung im Netz; er kennt die Topologie des Netzes auf Anwendungs-, nicht jedoch auf Objektebene.

Das Netz wird dabei in abstrakte, logische Einheiten unterteilt, die Konfigurationsbereiche. Teilen sich mehrere Organisationszweige einen Rechner, lassen sich fuer jede dieser Einheiten virtuelle Rechner auf Kommunikations- und Applikationsebene definieren.

Aus der Sicht des Kommunikations-Servers gibt es nur zwei Instanzen im Netz: Applikationen - sie koennen sowohl Auftraggeber als auch Auftragnehmer sein - und die fuer sie zustaendigen Kommunikations-Server. Jeder Auftrag ist netzweit eindeutig identifizierbar und wird durch die Kommunikations-Schnittstelle den beteiligten Applikationen gemeldet.

Eine einfache Moeglichkeit, Auftrags-Schnittstellen zu programmieren, bietet die synchrone Auftragsabwicklung. Ein synchroner Aufruf stellt aus Sicht des Programms einen Wartepunkt dar, der erst dann verlassen wird, wenn der Aufruf vollstaendig abgeschlossen oder ein Wartezeitablauf eingetreten ist.

Es gibt nun Anwendungsfaelle, fuer die die synchrone Auftragsabwicklung unguenstig waere, etwa wenn der Auftragnehmer seinerseits (Unter-)Auftraege an weitere Auftragnehmer vergibt. Dies wuerde sehr schnell zu einem Engpass fuehren. Der Flaschenhals laesst sich jedoch umgehen, wenn der entsprechende Auftragnehmer Multitasking-Faehigkeiten besitzt oder die Moeglichkeit besteht, Auftraege asynchron zu stellen.

Auftraege im Batch- oder Dialog-Betrieb versenden

Bei synchroner wie asynchroner Auftragserteilung ist zwischen zwei Nachrichtenarten zu waehlen:

- Dialog-Nachrichten werden unmittelbar dem Auftragnehmer zugestellt, eine Pufferung erfolgt nicht.

- Batch-Nachrichten werden im lokalen Kommunikationssystem auf Veranlassung des Kommunikations-Servers transparent fuer die Auftraggeberanwendung warteschlangenspezifisch gepuffert. Die Pufferung und das Weiterleiten obliegen dabei einer speziellen Pufferapplikation. Damit erhoeht sich die Autonomie des sendenden Konfigurationsbereichs. Die Auftraege werden bearbeitet, wenn der Auftragnehmer erreichbar ist oder zu einer vorgegebenen Zeit (etwa um Leitungskosten zu sparen).

Der Kommunikations-Server laesst sich fuer die jeweilige Umgebung spezifisch konfigurieren - bis hin zu den Kontrollmechanismen des Datenflusses. Mit Ausnahme der Speichereinteilung sind alle Werte im laufenden Betrieb dynamisch aenderbar. Der Kommunikations-Server besitzt als selbstheilende und reinigende Komponente den Timer- Prozess, der periodisch kontrolliert, ob der Server und die zu ueberwachenden Applikationen noch aktiv sind. Er startet die Anwendungen bei Bedarf neu, ueberprueft die Nachrichtenspeicher seines Konfigurationsbereichs, eliminiert Paketleichen, ueberwacht Verbindungen, stellt Timer-Nachrichten den lokalen Applikationen zu etc.

Der Objekt-Server dient zur Implementierung der Daten- und Diensteschicht (siehe Abbildung 3). Objekt-Server und Objekt-Link (der zur Applikation gebundene Auftraggeber-Repraesentant) kennen die Topologie der Objekte, nicht jedoch die des Netzes, der Anwendungen und der Kommunikations-Server. Name-Services sorgen dabei fuer die eindeutige Identifikation von Objekten und Methoden. Ausserdem erkennen sie die Mehrfachinstanzierung von Methoden im Falle redundanter Objektfuehrung bei voelliger Transparenz der Objektverteilung.

Mit dem Aufruf "REQMETH" (Request Method) fordert die Applikation ueber die Objekt-Schnittstelle die Anwendung einer Methode fuer ein oder mehrere bestimmte Objekte einer Objektklasse in den Modi Synchron, Asynchron oder Batch innerhalb oder ausserhalb einer Transaktion an. Die Inhalte der Programm-Schnittstelle werden nach vorheriger Pruefung in das Objektprotokoll konvertiert.

Der Auftragnehmer (Objekt-Server) enthaelt nur Steuerfunktionen und stellt Basisdienste zur Verfuegung. Die Services werden von den Methoden erbracht, die ueber die Methoden-Schnittstelle mit ihm kommunizieren. Sie koppeln die Anwendung so voellig vom verwendeten DBMS ab, weshalb selbst bei Austausch der Datenzugriffs- Schnittstelle hoechstens die Methoden zu aendern sind.

Bei einem Methodenmodul handelt es sich um die Implementierung einer bestimmten Methode fuer eine Objektklasse. Vererbung ist theoretisch ueber beliebig viele Hierarchiestufen moeglich. Allerdings kann eine Objektklasse jeweils nur eine uebergeordnete Objektklasse aufweisen. Ein Methodenmodul veranlasst wie die Applikation ueber die Objekt-Schnittstelle die Ausfuehrung von Methoden auf Objekte. Eine definierte Datenzugriffs-Schnittstelle - SQL fuer relationale DBMS, Data Base Access Method (DBAM) fuer nicht-relationale DBMS wie Adabas etc. - macht dabei unabhaengiger vom verwendeten Datenbanksystem.

DBAM ist eine Data-Dictionary-gestuetzte Eigenentwicklung des BLKA. Sie abstrahiert und optimiert Datenbankzugriffe, wobei verschiedene externe Sichten auf die jeweiligen internen Datenbankstrukturen moeglich sind. Neben einem Application programming Interface (API) stellt es Online-Services fuer die Analyse, die Dictionary-Pflege und den menuegefuehrten Zugriff auf die Datenbestaende bereit.

Die Zwischenspeicher-Schnittstelle unterstuetzt die Programmierung von asynchroner Methodenbearbeitung und von Mehrschritt- Transaktionen. Die Routing-Faehigkeiten der Objekt-Server ermoeglichen eine dynamische Lastverteilung ohne globale Bekanntgabe, da der neue Objekt-Server die Methoden ueber die Name- Services enthaelt. Die Implementierung einer neuen Applikation wird hinfaellig.

Erst wenn die Methodenanforderung ueber das Objektprotokoll eintrifft, ermittelt der Objekt-Server ueber die Implementierungsservices anhand der Objektklassen- und der Methoden- bezeichnung die Implementierungs-Informationen wie Modulname, Schnittstellen-Beschreibung etc. und versorgt damit die Methoden-Schnittstelle. Beim erstmaligen Ausfuehren des Methodenmoduls wird er dynamisch nachgeladen und mit Uebergabe der Methoden-Schnittstelle aufgerufen. Er ueberprueft ab dem zweiten Aufruf, ob die aktuelle Version des Methodenmoduls mit der zuletzt geladenen noch uebereinstimmt. Fehlerbereinigungen etc. lassen sich dadurch im laufenden Betrieb durchfuehren.

Die entscheidende Voraussetzung fuer den Betrieb der geschilderten Komponenten bilden das Konfigurations- und Versions-Management- System (KMS) und die Administrations-Server. Das KMS verwaltet konfigurations- und variantenspezifisch alle Versionen und Releases der Client-Server-, Objekt-Server- sowie anderer Konfigurationsobjekte.

Echtbetrieb ist fuer Anfang 1995 geplant

Im Vordergrund stehen hier vor allem die Laufzeitumgebungen, die sich lokal wie remote sowohl aus Datenbanken als auch aus Betriebssystem-Dateien importieren lassen. Versions- und Variantenfuehrungen werden ueber Konfigurations- und Variantenlisten beruecksichtigt. Die Verteilung neuer Versionen oder Releases auch auf Deltabasis erfolgt unter Nutzung der Objekt-Server-Dienste. Fast alle Updates sind im laufenden Betrieb realisierbar.

Der Administrations-Server steht pro Rechner und pro Konfiguration einmal zur Verfuegung. Er kontrolliert und steuert die lokalen, berechtigungsabhaengigen, aber auch die entfernten Konfigurationsbereiche. Seine Aufgabe ist es primaer, den Kommunikations-Server und die Applikationen zu ueberwachen. Eine eigene Kommunikationskomponente macht den Administrations-Server dabei unabhaengig von der Verfuegbarkeit der Kommunikations-Server.

Der Status der Kommunikationskomponenten laesst sich genauso auswerten und aendern wie bestimmte Systemwerte und die Warteschlangen der Pufferapplikation. Damit stehen fuer die Anwendungsentwicklung der bayerischen Polizei nicht nur eine moderne Architektur fuer die opti- male Geschaeftsprozess- Unterstuetzung, sondern auch die Werkzeuge, die fuer ihre Beherrschung notwendig sind zur Verfuegung.

Der fuer Mitte 1994 geplante erste Prototyp der integrierten Vorgangsbearbeitung und -verwaltung soll rechtzeitig erste Erfahrungen und Ansaetze fuer programmtechnische wie organisatorische Optimierungsmassnahmen aufweisen, bevor der landesweite Echtbetrieb Anfang 1995 aufgenommen wird. Ziel sind die Umstrukturierung und die Ueberfuehrung fast aller zentralen Verfahren auf die neue Architektur.