Daten in Service-orientierten Anwendungen klassifizieren und repräsentieren

Sobald die unterschiedlichen Arten von Daten definiert sind, geht es um die Frage, welche Technologien man anwenden sollte, um mit ihnen zu arbeiten und sie zu speichern. Die drei großen Technologien XML, Objekte und SQL stellen den Kern der Lösung dar.

Meldungs-Daten

Offensichtlich sind Meldungs-Daten am besten dafür geeignet, mithilfe von SOAP modelliert zu werden, da sie einen offenen Standard verlangen und in heterogenen Umgebungen verwendet werden. Von daher kann man das Schema für Meldungen mithilfe von WSDL veröffentlichen. Darüber hinaus können einige der Features der Meldungs-Daten, die man implementieren möchte (beispielsweise Zeitstempel und Sicherheitsfunktionen), durch SOAP-Spezifikationen wie WS-* bereitgestellt und in Toolkits wie der Web Services Enhancements (WSE) 2.0-Technology von Microsoft implementiert werden.

Innerhalb eines Services lassen Meldungs-Daten sich zusammen mit ihren identifizierenden Attributen als XML in einer relationalen Datenbank speichern, um Idempotenz zu implementieren. Dies ist auch deshalb empfehlenswert, weil man wahrscheinlich die Daten nach bestimmten Attributen abfragen möchte, aber wegen der Unveränderlichkeit der Daten nur selten den Inhalt der Meldungen lesen und parsen wird. Außerdem ermöglicht das Speichern der Meldungen Audits und nachträgliche Analysen. Allerdings haben Meldungs-Daten qua Definition die kürzeste Lebensdauer und können deshalb schnell archiviert werden, falls man sie nicht noch für Analysezwecke benötigt.

Eine weitere Überlegung in Bezug auf Meldungs-Daten betrifft das Versenden von Meldungen zwischen Services untereinander. In einer Umgebung innerhalb einer Organisation, wo die Meldungsstrukturen, die von den Services jeweils benutzt werden, unabhängig voneinander entstanden sind, ist es sinnvoll, ein kanonisches oder standardisiertes Schema zu erstellen, nach dem eine Meldung übersetzt werden kann, ehe sie von einem Service verwendet wird. Dadurch umgeht man das Problem, dass jeder Service dieselben Nachschlage- oder Geschäfts-Daten auf seine eigene Weise repräsentiert, und es sind wesentlich weniger Transformationen erforderlich.

Nachschlage-Daten

Da Nachschlage-Daten öffentlich sind und ein offenes Schema verlangen, sollten auch sie als XML modelliert werden. Hier empfiehlt es sich, das Schema der Nachschlage-Daten mithilfe von WSDL zu veröffentlichen, wobei auch Versionsinformationen angeben werden sollten. In Bezug auf die Datenbank kann man die Nachschlage-Daten zur Performancesteigerung als XML in einer relationalen Tabelle speichern, da sie nur einmal geschrieben und direkt als XML abgerufen werden. Darüber hinaus erlaubt das Speichern der Nachschlage-Daten in einer relationalen Tabelle eine einfache Versionskontrolle. Intern kann der Service die aktuellen Nachschlage-Daten zusätzlich zwischenspeichern, um die Antwortzeiten zu verkürzen, wenn die Nachschlage-Daten von einem Konsumenten angefragt werden.

Prozess-Daten

Da Prozess-Daten für den jeweiligen Service privat sind, müssen sie nicht mit XSD veröffentlicht oder als XML repräsentiert werden. Daher werden diese Daten üblicherweise in normalisierten Tabellen einer relationalen Datenbank gespeichert und innerhalb des Services mithilfe einer Objekt-Persistenz-Schicht wie zum Beispiel dem ObjectSpaces-Framework von Visual Studio .NET „Whidbey“ eingekapselt. Dieser Ansatz erlaubt dem Service die Manipulation der Prozess-Daten im Speicher als vollständig identisches Objekt und nutzt die Vorteile von Caching-Technologien wie etwa der ASP.NET Caching-Engine. Wenn der Prozess abgeschlossen ist oder sich im Wartezustand befindet, kann das Objekt mithilfe der Objekt-Persistenz-Schicht wieder serialisiert und in der Datenbank gespeichert werden.

Da Prozess-Daten während einer einzigen Konversation nacheinander aktualisiert werden, kann man mit optimistischer Synchronisation auf sie zugreifen. Historische Prozess-Daten wird man zu Analysezwecken speichern wollen. Je älter die Daten allerdings sind, desto eher kann man sie archivieren.

Geschäfts-Daten

Ebenso wie Prozess-Daten sind Geschäfts-Daten privat für den jeweiligen Service und werden daher nicht als XML repräsentiert, außer natürlich wenn Teile davon in Response-Meldungen verwendet werden. Für diese Teile lassen sich kanonische XSDs erstellen und veröffentlichen, so dass andere Services die Daten im Besitz des Services interpretieren können.

Geschäfts-Daten werden daher in normalisierten relationalen Tabellen gespeichert und mithilfe von Komponenten eingekapselt, die durch einen Transaktions-Manager wie zum Beispiel Component Services (COM+) verwaltet werden, um pessimistische Synchronisation (Locking) während der Transaktion sicherzustellen. Die Komponenten selber bieten zustandslosen Zugriff auf die Daten wegen der hohen Unbeständigkeit und der Anzahl gleichzeitiger Zugriffe. Geschäfts-Daten werden außerdem zusammen mit Prozess-Daten zu Analysezwecken verwendet.

Ein Modell

Abbildung A fasst die hier diskutierten vier Arten von Daten zusammen. Dieses Konzept soll eine geistige Landkarte bieten, auf der man die Daten seiner Organisation einordnen kann, wenn man sich Gedanken über die Implementierung einer SOA macht. Dieses Diagramm hebt die vier Arten von Daten hervor, die in einer SOA verwendet werden, und zeigt, wie sie repräsentiert und verarbeitet werden können.

Das Konzept einer SOA.

Dan Fox ist Technischer Direktor bei Quilogy in Overland Park, Kansas (USA), wo er Vorträge und Artikel zu Technologiethemen veröffentlich, u.a. auf Veranstaltungen wie TechEd oder Developer Days.