Richtlinie: Servicedatenkapselung
Diese Richtlinie erweitert das Konzept der Kapselung, wie es in der objektorientierten Entwicklung eingesetzt wird, auf Services. Sie beschreibt außerdem, wie die Kommunikation mit einem Service durch Nachrichtenaustausch bewerkstelligt wird. Dabei wird für Services die Metapher "Fiefdom" eingeführt, die auf direktem Wege nur mit bekannten "Emissarys" interagieren können, die ihrerseits mit dem Konsumenten interagieren.
Beziehungen
Hauptbeschreibung

Einführung

Es war sowohl in der objektorientierten als auch in der komponentenbasierten Entwicklung üblich, mit einer Gruppe von Komponenten zu arbeiten, die persistente Entitäten in einer gemeinsamen Datenbank darstellen. Tatsächlich hatten viele IT-Abteilungen die Vision eines einzelnen Datenbankschemas, das alle im Unternehmen verwendeten persistenten Elemente enthält. Einige Organisationen hatten damit zwar einen begrenzten Erfolg, aber für viele wurde kein allgemeines Unternehmensschema entwickelt. Ein solcher Ansatz schlägt aus vielerlei Gründen fehl, von denen einige nicht technischer Natur sind, viele jedoch Anwendungen betreffen. Der Zugriff auf einen gemeinsamen Datenbestand, das Sperren und Ändern dieses Datenbestands sind sehr schwierige Fragen, die organisationsübergreifend gelöst werden müssen.

In dieser Richtlinie werden zwei Punkte behandelt, die sehr eng miteinander verbunden sind. Erstens geht es darum, dass ein Service die vollständige Kapselung der erforderlichen Daten darstellen sollte, und zweitens, dass die gemeinsame Nutzung von Informationen durch die Services ausschließlich über den Austausch von Nachrichten erfolgt.

Diese Richtlinie enthält detaillierte Informationen zum Thema Serviceidentifikation.

Services als Leihgüter

Bei der Beschreibung der objektorientierten Entwicklung ist "Kapselung" einer der am häufigsten verwendeten Begriffe, d. h., ein Objekt sollte seinen Zustand (private Daten) und seine Implementierungslogik kapseln. In der Welt der Services wird der Terminus Service (Implementierung) klar von der ihm zugeordneten Servicespezifikation getrennt. Dieser Abschnitt befasst sich mit dem Bedarf an Zustandskapselung. Dieses Konzept wurde verschiedentlich dokumentiert, zuerst von Helland und in neuerer Zeit von Sessions. Es konzentrierte sich auf die Entwicklung autonomer und somit einfacher zu entwickelnder Systeme.

Im Kontext beschriebene Abbildung

Die allgemein übliche Analogie nach Helland ist die Beantragung einer neuen Versicherung bei einem Versicherungsagenten. Der Versicherungsagent hilft beim Ausfüllen der Antragsformulare und greift dabei auf Daten zu, um Typ und Preis der Police zu ermitteln. Er agiert als Emissary des Fiefdom der Versicherungsgesellschaft. Die Versicherungsgesellschaft kann nur Anträge von einem anerkannten Agenten akzeptieren. Das Fiefdom ist für die Verteilung aktueller Informationen zu Policen, Raten und Formen an Agenten sowie die Verarbeitung von Anwendungen zuständig. Obwohl das Fiefdom dem Agenten die Informationen zur Police zur Verfügung gestellt hat und der Agent vom Fiefdom zertifiziert wurde, überprüft die Versicherungsgesellschaft den Antrag vollständig, d. h. das Fiefdom traut dem Emissary noch nicht.

Die folgenden Abschnitte umreißen die Rolle der zwei primären Elemente detaillierter. Das ist zwar kein konkretes Muster oder präskriptives Konzept, die enthaltenen Prinzipien sind bei der Untersuchung serviceorientierter Lösungen jedoch wichtig.

Die Rolle des Fiefdom

Das Fiefdom ist ein autonomer Service; es lässt Kommunikation nur über Nachrichten zu, die normalerweise nur von Emissarys, die für den Konsumenten tätig werden, erstellt werden. Das Fiefdom ist geschützt und autonom und definiert eine Datengrenze vollständig. Es werden keine Datenquellen oder anderen persistenten Daten von Leihgütern bzw. Leihgütern und anderen Softwareelementen gemeinsam genutzt. Es ist möglich, dass ein einzelner Datenbankserver mehrere Services zwecks Persistenz hervorhebt, aber verschiedene Tabellenbereiche oder Datenbankcontainer für die einzelnen Leihgüter gewährleisten die Datenintegrität, die Sicherheit usw.

Ein anderer wichtiger Aspekt des Musters ist, dass der Emissary als Agent angemessen agieren kann, d. h., dass er mit einem Mindestmaß an erforderlichem Kontakt zum Fiefdom mit dem Konsumenten kommunizieren kann und dass das Fiefdom Kopien bestimmter Referenzdaten an die Emissarys verteilen kann, damit diese sie lokal speichern und nutzen können. In dem oben genannten Beispiel mit der Versicherung wird der Katalog mit den verfügbaren Policen, ihren Anforderungen, Einschränkungen und Preisen regelmäßig an die Agenten verteilt. Natürlich ist es wichtig, dass der Agent diese Informationen nutzen kann, er muss sich jedoch darüber im Klaren sein, dass diese Informationen lediglich eine Kopie der Daten darstellen und nicht notwendigerweise mit den vom Fiefdom verwendeten Daten übereinstimmen, möglicherweise sogar veraltet sind. Sie können einmal pro Monat aktualisiert werden, und wenn die Aktualisierung empfangen wird, ist der Emissary möglicherweise nicht in der Lage, neue Anwendungen zu verarbeiten oder aber er verarbeitet sie auf der Basis der alten Daten.

Wie oben erwähnt, begründet die Tatsache, dass ein Emissary für ein Fiefdom tätig wird, kein Vertrauensverhältnis zwischen den beiden Parteien. Um sicherzustellen, dass der Emissary nicht von Unbefugten gesteuert wird, werden alle Nachrichten hinsichtlich Syntax, Semantik und Richtlinien überprüft.

Die Zuständigkeiten des Fiefdom lauten im Detail wie folgt:

  • Referenzdaten verwalten und an alle Emissarys verteilen und die effektiven Datumsangaben der Daten klar identifizieren.
  • Den Status von Transaktionsdaten verwalten; alle Transaktion werden in ihrer Gesamtheit intern verwaltet.
  • Die gesamte Kommunikation mit Emissarys validieren.

Die Rolle des Emissary

Der Emissary agiert als Agent und kann als Komponente pro Konsument, als internetbasierte Komponente oder als spezifisch implementierte Komponente lokalisiert werden. Entscheidend aber ist, dass er die Merkmale zur Verwaltung der Referenzdaten hat, die erforderlich sind, um Nachrichten, die an die Fiefdom-Prozesse gesendet werden, auszufüllen. Er ist auch zuständig für die Verwaltung lokaler Kopien von pro Transaktion verwendeten Nachrichten. So können sich z. B. Kunden als Inhaber einer vorhandenen Police identifizieren. Der Emissary kann das zuerst überprüfen, um das Formular mit einigen Informationen zu fülle. Diese Kopie der vorhandenen Police kann vom Emissary für die Dauer der Transaktion zum Ausfüllen des Antrags zwischengespeichert werden.

Im Allgemeinen wird ein Emissary verwendet, wenn die Kommunikation zwischen dem Fiefdom und dem Konsumenten eine komplexere Transaktion darstellt, die der Emissary jetzt effizienter handhaben kann, z. B. das Ausfüllen komplexer Anfragen wie im aktuellen Beispiel. Dieses Muster kann man heute in vielen Organisation finden, in denen das System für die Auftragsabwicklung, das Aufträge verarbeitet und ihre Lieferung plant, oft seit vielen Jahren installiert ist. Da diese Organisationen damit begannen, Produkte interaktiv über das Web zu verkaufen, agiert die Webanwendung als Emissary; sie hat eine lokale Kopie des Produktkatalogs und hilft dem Kunden, einen Auftrag vorzubereiten. Natürlich verarbeitet die Webanwendung den Auftrag nicht, sie übergibt die Aufträge an das vorhandene System. Da der Emissary diesen Auftrag basierend auf Referenzdaten ausführt, kann man erwarten, dass der Auftrag nicht wegen Ungültigkeit zurückgewiesen wird. Andererseits prüft das vorhandene Auftragssystem, wie oben erwähnt, den Auftrag, bevor es ihn akzeptiert.

Die Zuständigkeiten des Emissary lauten im Detail wie folgt:

  • Als Agent für den Kunden agieren, um Nachrichten zu verfassen und mit dem Fiefdom zu interagieren.
  • Eine logische Transaktion zur Abfrage von Referenzdaten ggf. verwalten, Nachrichten ausfüllen, Informationen im Namen des Kunden übergeben.
  • Eine lokale Kopie der Referenzdaten verwalten und nach Anweisung durch das Fiefdom aktualisieren.
  • Caching-Richtlinien zu zeitkritischen Daten laut Identifikation durch das Fiefdom verwalten.

Servicedatengrenzen

Normalerweise werden viele Anwendungen als vertikal integrierte Komponentengruppen entwickelt (weitere Informationen finden Sie im Konzept Serviceorientierte Architektur). Das führt oft zu Anwendungen, die wenige natürliche Integrationspunkte haben. Der am meisten verbreitete Ansatz für die Integration ist, hauptsächlich aufgrund seiner Einfachheit, folgender: Zwei oder mehr Anwendungen nutzen einen gemeinsamen Datenspeicher. Wenn also "Bestand" und "Bestellung" dieselbe Definition des Begriffs "Produkt" verwenden, greifen sie auf dieselben Tabellen in der Datenbank zu. Das führt zu einer Reihe potenzieller Konkurrenz- und Leistungsprobleme sowie zu Wechselbeziehungen, die diese Anwendungen jetzt verbinden und ihre individuelle Weiterentwicklung sowie die Fähigkeit des Unternehmens, eine der Anwendungen erneut zuzuordnen, erneut zu entwickeln oder einfach zu ändern, beeinflussen.

Im Kontext beschriebene Abbildung

Für die Entwicklung serviceorientierter Lösungen wird empfohlen, dass ein Service ein spezifisches, gebundenes und kohärentes Datenmodell verwaltet. So muss die Analyse der Verwendung der zwei oben gezeigten Anwendungen ermitteln, wie die Daten von ihnen genutzt werden und wie die Daten getrennt werden können, damit eine Verwaltung durch zwei autonome Services möglich wird. Das bedeutet nicht, dass es keine Verbindungen zwischen den Datenmodellen gibt, wenn sie getrennt werden. Beispielsweise benötigen die Services "Bestand" und "Bestellung" eine einheitliche Definition der Produkte sowie der Standorte, an denen der Bestand gelagert und bei Bestellungen bereitgestellt wird.

Ansätze zur Lösung dieses Problems bestehen darin, entweder einen dritten Service für das gemeinsame Konzept zu erstellen (hier wäre ein Produktkatalogservice wichtig) oder das Konzept in nur einem der neuen Services zu verwalten. Beispielweise würde der Standort logisch durch den Bestand verwaltet. Nachrichten, die von und zu einem dieser Services gesendet werden, müssen die ID für die gemeinsam genutzten Elemente enthalten, damit sie bei Bedarf abgefragt oder abgerufen werden können. Im Falle des Bestandes würde eine Abfrage der gegenwärtig von einem Standort verwalteten Produkte eine Liste von Produkt-IDs (es sind große Mengen zu erwarten) zurückgeben. Wenn die Details der Produkte erforderlich sind, würden sie vom Produktkatalogservice abgerufen.

Ein wichtiges Arbeitsergebnis bei der Analyse der Grenzen ist offensichtlich das Datenmodell. Datenmodelle müssen für die vorhandene Datenbank erstellt und im physischen oder vorzugsweise im logischen Datenmodell sorgfältig getrennt werden.

Servicenachrichten als Datensichten

Wenn alle Daten nur im Service gespeichert werden und der Zugriff allen Komponenten außerhalb des Service verweigert wird, muss die gesamte Kommunikation über in der Servicespezifikation identifizierte Nachrichten erfolgen. Es ist jedoch immer wichtig festzustellen, dass diese Nachrichten, da sie eine Abfrage darstellen und Daten von der Datenbank an den Konsumenten zurückgeben, spezifische Kopien der vom Service gespeicherten Daten sind. Im Grunde können sie einen veralteten Status des Service angeben. Wenn z. B. der Bestand des Produkts "234" abgefragt wird, wird eine Nachricht zurückgegeben, die angibt, dass Standort "562" den Bestand "12" hat. Die Operation wird allerdings fehlschlagen, wenn ein anderer Konsument 8 Artikel vom Lager nimmt und der ursprüngliche Konsument versucht, 12 Artikel anzufordern.

Praktisch handelt es sich um Probleme des Designs und des traditionellen Transaktionsmanagements, d. h., die Verwaltung des Transaktionsumfangs und der Transaktionsgrenzen, die aufgrund der losen Kopplung von Services und Servicekonsumenten ein wenig komplexer oder zumindest transparenter sind. Daher müssen Nachrichten nicht nur als Datensichten, sondern auch als Datenkopien betrachtet werden. Es wurden einige Anleitungen an verschiedenen Punkten geschrieben, z. B. in der SOA, um zu beschreiben, wie Nachrichten ihre Lebensdauer und Anwendbarkeit identifizieren können.

Eine weitere Auswirkung dieser Konvertierung in den nachrichtenbasierten Ansatz, der serviceorientierten Lösungen innewohnt, ist, dass die Idee eines allgemeinen Datenmodells für Anwendungen jetzt zu einer Idee eines allgemeinen Nachrichtenmodells für Integration wird. Das bedeutet, dass Nachrichten, die für Servicespezifikationen definiert sind, möglichst auf allgemeinen Strukturen basieren und eventuell in ein kohäsives, serviceübergreifend wiederverwendbares Schema gestellt werden. Dieser Ansatz ist insofern wesentlich flexibler für die Integration, als er auch der losen Kopplung der Services entspricht. Auch die meisten Technologien, die in der Serviceimplementierung verwendet werden, beinhalten entweder Technologien, Tools oder Laufzeiten, die Nachrichtenkonvertierungsfunktionen bereitstellen, wenn Nachrichtenschemata nicht genau übereinstimmen.

Nähere Informationen, insbesondere zum Nachrichten-Leasing und -Caching, finden Sie in der Beschreibung der Aufgabe Nachrichtendesign.

Referenzliteratur

[HELLAND] Fiefdoms and Emissaries, Pat Helland, Microsoft.

[SESSIONS] Software Fortresses: Modeling Enterprise Architectures, Roger Sessions, Addison Wesley, 2003.