Standards und Schnittstellen
Mit Schnittstellenbeschreibungen und standardkonformen Erweiterungen alleine ist es aber nicht getan. Wie erwähnt, muss ein SOA-Registry und -Repos- itory viele weitere Artefakte wie Policies oder Prozessbeschreibungen unterstützen. Hier kommen Standards wie WS-Policy zur Spezifikation von Quality- of-Service-Aspekten ins Spiel, darüber hinaus Prozessmodellierungs-Standards wie BPMN (Business Process Modeling Notation). IT-Hersteller kooperieren in verschiedenen Gremien, um die Interoperabilität im SOA-Bereich weiterzuentwickeln. ebXML wird in diesem Kontext beispielsweise von Sun und Infravio favorisiert; die stärker SOA-orientierte Registry der UDDI-Spezifikation unter anderem von der Software AG, Fujitsu und HP.
Business-Vorteile
Ist erst einmal ein gut gepflegtes SOA-Registry und -Repository im Einsatz, so bietet dies dem Unternehmen auf der Business-Ebene mehrere Vorteile. Beispielsweise ermöglicht es RoI-Berechnungen für die SOA. Grundlage dafür ist der Überblick über Status und Nutzung von Diensten. Zusätzlich werden Referenzinformationen, wie etwa eine Korrelation von Services zu Policies und Geschäftsprozessen, zur Verfügung gestellt. Weiterhin erhöht ein derartiges Governance-System die Sichtbarkeit von Daten, Prozessen und Compliance-Leveln: Ähnlich wie konventionelles Application-Monitoring liefert ein SOA-Registry und -Repository über die gesamte SOA-Architektur hinweg die für geschäftliche Entscheidungen wichtige Transparenz.
Anfoderungen an SOA-"Repistries"
-
Zentraler Pool für Informationen, Dokumente und Abhängigkeiten: Ein SOA-Registry und -Repository muss - direkt oder über Verweise - alle Informationen im Zusammenhang mit Services abfragbar bereitstellen. Die Daten reichen dabei von Schnittstellenbeschreibungen, Eigentümerverweisen und Policies bis hin zu Build-Artefakten und Projektinformationen.
-
Policy-Support: Zu unterstützen sind sowohl Policies zur Service-Design-time (zum Beispiel Architekturrichtlinien) als auch zu Run-time-Policies wie Service Level Agreements.
-
Reporting: Neben vordefinierten Abfragen sollte das System flexibel definierbare Reports über beliebige Informationen erlauben, um mit der SOA wachsen zu können.
-
Top-down und Bottom-Up Informationsbefüllung: SOA-Registries und -Repositories beinhalten sämtliche Architekturinformationen einer SOA - insbesondere Abhängigkeiten zwischen ihren Informationseinheiten. Diese Informationen können Top-down definiert oder Bottom-up aus bestehenden Systemen gewonnen werden.
-
Flexibler Service-Lifecycle: Ein Registry- und Repository sollte sich um eigene Prozesse und Rollen im Rahmen der Lifecycle-Überwachung von Services erweitern lassen.
-
Integration mit Monitoring- und Entwicklungsumgebungen: Gemeint ist die Unterstützung offener Schnittstellen zur Integration mit anderen Werkzeugen wie Run-Time-Monitoring und Entwicklungsumgebungen.
-
Erweiterbarkeit durch Plug-ins: Von Vorteil ist die Erweiterbarkeit eines Registry-Repository-Systems, beispielsweise durch standardisierte Tool-Plugins.
-
Moderne und flexible Oberfläche: Eine ansprechende Oberfläche - beispielsweise als Rich Internet Application auf Basis von Ajax - und eine einfache Benutzung sind wichtig, um die SOA-Beteiligten für die Nutzung des Werkzeugs zu gewinnen und zu binden.
Erhöhte Sichtbarkeit führt zu verbesserten Kontroll- und Steuerungsmöglichkeiten für das Management und die Fachbereiche. Das wiederum führt direkt auf das Ziel jeglicher SOA-Initiativen zu, nämlich mehr Flexibilität und Agilität des Unternehmens. Auch die IT-Governance kann dadurch leistungsfähiger werden: SOA-Assets werden mit Hilfe von Governance-Strukturen zu Wirtschaftsgütern, jedoch erst ein SOA-Registry und -Repository macht diese Assets greifbar. Damit wird ihr Einfluss auf die wertschöpfenden Unternehmensprozesse transparent und regelbar.