Grundsteine für SOA-Bauten

Gerd Schneider ist Senior Director bei der Software AG.

Schon bald, nachdem Webservices aufkamen, war klar: Es muss Technologien geben, um sie zu verwalten. So entstand beispielsweise UDDI (Universal Description, Discovery und Integration). Dieser XML-basierende Standard für Verzeichnisinformationen macht es möglich, Dienste anhand von Beschreibungen zu identifizieren und zu verwenden. UDDI übernimmt hierbei die Rolle der «Gelben Seiten» für die Services.

Serviceorientierte Architekturen (SOA) benötigen ebenfalls einen zentralen Verwaltungsdienst. Bei einer SOA sollen mit Hilfe von Services Anwendungen integriert und Abläufe modelliert werden. Im Vergleich zu UDDI kommen jedoch viele weitere Aspekte hinzu, die über eine Schnittstellenbeschreibung hinausgehen. Dazu zählen Themen wie Sicherheit, Verfügbarkeit und Antwortzeit. Um SOA-Architekturen vollständig zu verwalten, kommen SOA-Registries und -Repositories zum Einsatz. Diese sollen Prozesse, Policies und Services zueinander in Verbindung setzen und organisatorische SOA-Governance-Prozesse unterstützen.

Eine Registry stellt, vergleichbar einem Branchentelefonbuch, ein Verzeichnis verfügbarer Dienste bereit, aus dem neben
der Adresse nur wenige zusätzliche Informationen, also Metadaten, über die Dienste hervorgehen. Ein Repository hingegen speichert und kategorisiert Dienste zusammen mit ihren Eigenschaften sowie zusätzlichen Artefakten.

Doch der Einsatz zweier getrennter Technologien für Registry und Repository erfordert eine aufwändige Synchronisation und birgt das Risiko inkonsistenter Darstellungen. Ganz abgesehen vom erhöhten Aufwand bei Einführung und Betrieb. Für SOA-Governance ist das reibungslose Zusammenspiel zwischen Registry und Repository unerlässlich. Denn nur so ist es möglich, Governance-Prozesse zu beschreiben, auszuführen und zu kontrollieren.

Geht es um die reine Serviceverwaltung, hat sich UDDI etabliert. Ein Vorteil gegenüber Standards wie EB-XML (Electronic Business XML) ist, dass das Zusammenspiel von UDDI mit den relevanten Werservices-Standards reibungslos klappt. Um jedoch auch Prozesse und Policies einer SOA zu verwalten, sind weitere Standards nötig, etwa WS-Policy, BPEL (Business Process Execution Language) oder BPMN (Business Process Modeling Notation). Diese lassen sich durch die flexiblen T-Modelle, so genannte Type Models, von UDDI ebenfalls einbinden und verwalten. Auf dieser Basis entstehen leistungsfähige Werkzeuge, um auch komplexe Beziehungen und Abhängigkeiten von SOA-Artefakten untereinander aufzuzeigen.

Bei der Beschreibung der SOA-Artefakte halten zunehmend Prinzipien des Web 2.0 Einzug: Ähnlich wie in Wikis können Benutzer an der Dokumentation bestimmter Services mitarbeiten, etwaige Fehler korrigieren und eigene Erfahrungen einbringen.

Innerhalb einer SOA dienen Policies als Richtlinien für die Definition und Ausführung von Anwendungen. Sie beschreiben zum Beispiel Laufzeitanforderungen, Sicherheit und Verfügbarkeit oder auch, ob ein Service dem WS-I-Standard (Webservices Interoperability) entspricht, wodurch sich seine Integration weiter vereinfacht.

Dabei spielt es keine Rolle, ob die Policies während der Laufzeit oder während der Entwicklungsphase überprüft werden. Vielmehr kommt es darauf an, beide Szenarien abzubilden und die entsprechenden Tools zu unterstützen. WS-Policy bietet zwar einen standardisierten Policy-Austausch zwischen unterschiedlichen Werkzeugen, jedoch gibt es noch keinen reifen Standard, wie die Policy innerhalb der Beschreibung strukturiert und aufgeschlüsselt sein soll. Dies führt dazu, dass viele Hersteller bilaterale Abkommen zum Policy-Format entwickeln. Übergreifende Standards sind -jedoch am Entstehen.

Aufgrund der verteilten Architektur muss es in einer SOA die Möglichkeit zur Impact-Analyse geben. Die Änderung an einem Dienst kann vielfältige Auswirkungen auf andere Services haben, so dass es notwendig ist, die Zusammenhänge zwischen Prozessen, Services und Policies zu modellieren. Die Abhängigkeiten der unterschiedlichen Artefakte lassen sich sehr gut mit einem Standard wie JAXR (Java API for XML Registries, siehe auch Lexikon Seite 25) beschreiben, der den dafür notwendigen Funktionsumfang bereits mitbringt.

Um auch komplexere Analysen -möglichst einfach durchzuführen, hilft die Abfrage-sprache X-Query (XML Query Language) weiter. Damit lässt sich zum Beispiel das Laufzeitverhalten von Services über einen bestimmten Zeitraum rasch analysieren. Die Artefakte sollten direkt in einer XML-Datenbank gespeichert werden, da dies eine flexiblere Verarbeitung der Daten ermöglicht und die aufwändige Konvertierung hin zu Relationen vermieden wird.

Registries für Werservices sind in vielen Anwendungslandschaften bereits vorhanden. Ergänzend bringen Entwicklungsumgebungen Repositories mit, die jedoch ihre Assets meist in einem proprietären Format beschreiben. Dies gilt nicht nur für den Code, sondern auch für Modelle, Beschreibungen von Webservices oder für Testfälle. Der Austausch von Artefakten ist dann nur über Import- und Export-Funktionen praktikabel. Als Standard hierfür dienen Formate wie XMI (XML Metadata Interchange), das den Datenaustausch auf Basis von Meta-Datenmodellen nach der Meta-Object Facility (MOF) ermöglicht. MOF schafft also eine allgemeingültige Grundlage für Metamodelle, so dass der Austausch von Metadaten innerhalb eines Repositories möglich wird.

Im Registry-Bereich ergeben sich aufgrund der umfangreichen Standards zusätzliche Optionen zum Datenaustausch, die über den Import/Export-Mechanismus hinausgehen. Die erste Variante ist der Onlinezugriff, bei dem für jede Anfrage eine Subanfrage an die entsprechenden Third-Party-Registries weitergeleitet wird. Der Vorteil hierbei: Die angeforderten Informationen sind stets aktuell. Je nach Art, Menge und Umfang der involvierten Registries kann sich das Verfahren aber negativ auf die Performance der Anwendungslandschaft auswirken. Bei der zweiten Variante sorgt ein Replizierungsmechanismus dafür, dass Daten redundant in den beteiligten Registries gehalten werden. Die Synchronisation kann beispielsweise mit dem UDDI-v3-Subscription-Mechanismus geschehen oder über ein zeitintervall-basiertes Pollen.

Das SOA-Management ist längst nicht mehr auf Technologie beschränkt. Unternehmen Bei der Aufbereitung solcher Business-Metriken helfen Business-Intelligence-Frameworks, wie etwa das Eclipse-basierte Birt (Business Intelligence und Reporting Tools). Beispielsweise lassen sich hiermit die Abhängigkeiten und Antwortzeiten von Services auswerten und darstellen.unter anderem, wie es um die Wiederverwendbarkeit von Services steht. Auch lassen sich Entwicklungszeiten von Services und Prozessen bewerten. Der SOA-Entwicklungsprozess wird dadurch für die Fachabteilungen messbar und gewinnt insgesamt an Transparenz.

Bei der Aufbereitung solcher Business-Metriken helfen Business-Intelligence-Frameworks, wie etwa das Eclipse-basierte Birt (Business Intelligence und Reporting Tools). Beispielsweise lassen sich hiermit die Abhängigkeiten und Antwortzeiten von Services auswerten und darstellen.

Die beschriebenen Technologien und Standards bilden also ein Grundgerüst für die Verwaltung serviceorientierter Architekturen. Da im Bereich SOA-Governance viele Komponenten und Technologien zusammenspielen, ist der Einsatz herstellerneutraler Standards wichtig. Auch ist das Thema Benutzerfreundlichkeit nicht zu unterschätzen: Wenn Fachabteilungen und IT bei diesem wichtigen Thema zusammenarbeiten sollen, muss die Akzeptanz auf Anwenderseite gewährleistet sein.

Weitere Informationen

- UDDI (Universal Description, Discovery and Integration) ist ein Register, vergleichbar dem Branchentelefonbuch, in das sich möglichst viele Firmen eintragen und beschreiben sollen, damit ihre Produkte und Dienstleistungen über das Internet zugänglich sein können. Diese können auch als Webservices definierte Software-Tools sein.

- EB-XML (Electronic Business Extensible Mark-up Language) bezeichnet einen Satz technischer Vorgaben, die das internationale Abwickeln von Geschäften, insbesondere für KMU, über das Internet sicher und zuverlässig machen sollen. Rückgrat des E-Business-Rahmen ist der Austausch von Daten im XML-Format.

- BPEL (Business Process Execution Language) ist eine von Microsoft, IBM und BEA im April 2003 beim Standardisierungsgremium Oasis eingereichte Spezifikation für die Koordination von Webservices-basierten Geschäftsprozessen. Damit sollen komplexe Geschäftsprozesse, die mehrere Webservices enthalten, definiert werden können. Zudem wird dabei die Kommunikation dieser Prozesse in und zwischen Unternehmen, die verschiedene Systeme einsetzen, unterstützt.

- XMI (XML Metadata Interchange). Für den Austausch von Nicht-HTML-Dateien und -Inhalten via Internet liegt mit XML ein Standard vor. Nicht aber für den Austausch von Programmdaten und Objekten. Sie können daher nicht über ein Netzwerk oder Internet miteinander kommunizieren. XMI möchte XML mit zwei OMG-Techniken verknüpfen, der Unified Modeling Language (UML), einer objekt-basierten Lingua franca für die Behandlung verteilter Objekte und Geschäftsmodelle, und der Meta Object Facility (MOF), einem Standard für verteilte Repositories. So soll XMI die Entwicklung objekt-basierter Programme erlauben, die via Internet zusammenarbeiten können, obwohl sie mit verschiedenen Entwicklungstools, Programmiersprachen und mit unterschiedlichen Objektbibliotheken erstellt wurden.

Mehr Begriffserklärungen auf: www. computerworld.ch/lexikon