Daten in Service-orientierten Anwendungen klassifizieren und repräsentieren

Bei der Erstellung einer SOA gibt es im Wesentlichen vier Arten von Daten, über die man sich Gedanken machen muss. Von außen nach innen sind dies: Meldungs-Daten, Nachschlage-Daten, Prozess-Daten und Geschäfts-Daten. Im folgenden Abschnitt werden diese Datentypen mit ihren jeweiligen Charakteristika beschrieben, gefolgt von Hinweisen, was man beim Umgang mit diesen Daten beachten muss.

Meldungs-Daten

Die Daten, die zwischen einzelnen Services ausgetauscht werden, heißen Meldungs-Daten. Diese Daten geben die Aufgabe oder die Operation an, die der Konsument des Services durchführen will (der Request), sowie das Ergebnis, das der Konsument vom Service zurück erhält (die Response). Dies ist die einzige Art von Daten, die zwischen Services ausgetauscht wird, und stellt somit die öffentliche Schnittstelle des Services dar. Dadurch können SOAs plattformunabhängig agieren.

Von daher erfordern Meldungs-Daten vom Prinzip her ein offenes Schema, so dass Konsumenten herausfinden können, wie ein Request formuliert werden muss und eine Response verarbeitet werden kann. Meldungs-Daten sind deshalb relativ stabil, was die Definition der Operationen betrifft, die der Service offen legt. Treten jedoch Änderungen auf, muss es eine Versionskontrolle geben. Zudem sind Meldungs-Daten unveränderlich insofern, als die Meldung nach ihrem Erstellen nicht mehr geändert wird.

Services verarbeiten Meldungs-Daten, indem sie eine eindeutige ID für jede Meldung erstellen – außerdem einen Zeitstempel, eine Versions-ID, Konversations-ID und die laufende Nummer innerhalb der Konversation (natürlich zusammen mit allen ggf. erforderlichen Sicherheits-Tokens). Diese zusätzlichen Informationen erlauben den Services, Meldungen, die nicht rechtzeitig ankommen, aufgrund des Zeitstempels zu verwerfen und sicherzustellen, dass alle Meldungen nur einmal und in der korrekten Reihenfolge bearbeitet werden. Der Service sollte alle Request- und Response-Meldungen speichern, damit eine mehrfach empfangene Meldung durch Rückgabe der bereits erzeugten und jetzt zwischengespeicherten Response beantwortet werden kann (was nebenbei auch die Performance steigert). Meldungs-Daten werden häufig zum Abrufen von Nachschlage-Daten verwendet.

Nachschlage-Daten

Die zweite Art von Daten, mit denen Services zu tun haben, sind Nachschlage-Daten. Diese Art von Daten wird verwendet, um innerhalb von Service-Requests Parameter an Operationen zu übergeben oder um die in einer Service-Response zurückgegebenen Daten zu interpretieren. Ein Konsument fragt zum Beispiel Nachschlage-Daten ab und verwendet diese dann zur Formulierung einer Request-Meldung. Eine Firma, die technische Schulungen anbietet, könnte etwa Nachschlage-Daten veröffentlichen, die Schulungsorte und Anbieter angeben, so dass Konsumenten dem Service gültige Werte übergeben, wenn sie einen Kursplan abrufen. Wie man sich denken kann, sind Nachschlage-Daten relativ statisch, aber bei Änderungen sollte es eine Versionskontrolle geben, so dass jede Version der Nachschlage-Daten unveränderlich ist. Wie Meldungs-Daten werden auch Nachschlage-Daten extern vom Service benutzt und erfordern von daher ein offenes Schema.

Services arbeiten mit Nachschlage-Daten, indem sie jeden Eintrag eindeutig identifizieren und ihn mit einer Versions-ID versehen (z.B. Quilogy – LocationCodes – v012004). Wenn Konsumenten einen Request abschicken, können sie auf diese Weise die Version der verwendeten Referenzdaten mit übergeben, so dass der Service die passende Response erstellen kann. Da Nachschlage-Daten irgendwann aktualisiert werden müssen, üblicherweise in bestimmten Zeitabständen, veröffentlicht der Service die neue Version an interessierte Abonnenten entweder als Push- (per E-Mail, HTTP oder sogar DVD) oder Pull-Service (per HTTP, FTP oder E-Mail).

Prozess-Daten

Innerhalb eines Services sind Prozess-Daten die erste Art von Daten, mit denen man es zu tun bekommt. Im Unterschied zu Meldungs- und Nachschlage-Daten sind Prozess-Daten private Daten des Services und vollständig innerhalb desselben eingeschlossen, so dass man hier nicht auf einen offenen Standard zurückzugreifen braucht. Prozess-Daten repräsentieren den Geschäfts-Prozess beziehungsweise die Funktion, die vom Service ausgeführt wird. Üblicherweise sind dies länger laufende Operationen, die irgendwann einmal zu einem Abschluss kommen. Beispiele für Prozess-Daten sind Warenkörbe, Bestellungen und Rechnungen. Prozess-Daten sind abhängig vom Client und der Konversation, so dass hier die Notwendigkeit eines gleichzeitigen Zugriffs vergleichsweise niedrig ist, da auf die Daten nur der Reihe nach durch einen einzigen Client zugegriffen wird. Im Unterschied zu Nachschlage-Daten können diese Daten auch durchaus während der laufenden Operation aktualisiert werden und erhalten nach Abschluss der Operation normalerweise Nur-Lese-Status. Im Verlauf der Zeit wird danach auf diese Daten immer seltener zugegriffen.

Services verarbeiten Request-Meldungen und führen Aktionen durch, die innerhalb des Services Prozess-Daten für die Konversation erstellen. Von daher müssen sie die Prozess-Daten zur Konversations-ID in Bezug setzen. Ein Service kann eine Vielzahl von Techniken zur Änderung von Prozess-Daten verwenden. Beispielsweise kann der Service, solange der Prozess aktiv ist, die Prozess-Daten in einem Objekt einschließen und im Speicher zwischenspeichern. Services müssen auch in der Lage sein, abgebrochene oder abgeschlossene Prozesse aus dem Speicher zu entfernen.

Geschäfts-Daten

Die letzte Art von Daten, die bei einer SOA verwendet werden, sind Geschäfts-Daten. An diese Art von Daten denken die meisten Leute, wenn es um Anwendungen geht: Kunden-Informationen, Produktlisten und Bankkonten zum Beispiel. Wie Prozess-Daten sind Geschäfts-Daten ebenfalls private Daten des Services und erfordern kein offenes Schema. Im Unterschied zu Prozess-Daten haben sie allerdings eine längere Lebensdauer als eine einzelne, über einen bestimmten Zeitraum laufende Operation und stellen hohe Anforderungen an gleichzeitigen Zugriff, da diese Daten durch mehrere Operationen simultan geändert werden können. Von daher sind Geschäfts-Daten äußerst unbeständig und eher transaktioneller Natur.

Der vielleicht wichtigste Grundsatz beim Umgang von Services mit Geschäfts-Daten ist, sich streng an das Prinzip eines einzigen Besitzers zu halten. Mit anderen Worten, Services übernehmen die Eigentümerschaft eines bestimmten Teils der Daten der Organisation. Ein Service ist zum Beispiel Besitzer der Kundendaten, während ein anderer die Mitarbeiterdaten besitzt. Wenn Daten ausgetauscht werden müssen, veröffentlicht jeder Service Änderungen für andere Services, welche diese dann zum internen Gebrauch zwischenspeichern. Jede Veröffentlichung der Daten eines Services sollte natürlich mit einer fortlaufenden Versionsnummer versehen werden. Nur der Besitzer des Services aktualisiert die Daten. Wenn also ein Nichtbesitzer eine Änderung verlangt, nimmt der besitzende Service diese Änderung vor und veröffentlicht die Daten für interessierte Abonnenten.