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.
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.
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.
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.
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.
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.
[HELLAND] Fiefdoms and Emissaries, Pat Helland, Microsoft.
[SESSIONS] Software Fortresses: Modeling Enterprise Architectures, Roger Sessions, Addison Wesley, 2003.
|