Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.10.2006

Wie Repositories die SOA verwalten

Service-orientierte Architekturen versprechen Flexibilität, bergen jedoch die Gefahr wachsender Komplexität. Registries und Repositories sollen für Ordnung sorgen.
Ein Registry- und Repository-System unterstützt den gesamten Lebenszyklus eines SOA-Service. Dazu gehören die Entwurfs- und Implementierungsphase ("Design-time") ebenso wie der produktive Betrieb ("Run-time").
Ein Registry- und Repository-System unterstützt den gesamten Lebenszyklus eines SOA-Service. Dazu gehören die Entwurfs- und Implementierungsphase ("Design-time") ebenso wie der produktive Betrieb ("Run-time").
Governance-Strukturen sollten abhängig vom Reifegrad der SOA ein- gezogen werden, raten Experten. Typische Reifegradmodelle beginnen mit Pilotprojekten auf Basis weniger Services.
Governance-Strukturen sollten abhängig vom Reifegrad der SOA ein- gezogen werden, raten Experten. Typische Reifegradmodelle beginnen mit Pilotprojekten auf Basis weniger Services.

Wer mit einem kleinen SOA-Projekt startet, kommt in der ersten Phase vielleicht noch mit manuell erstellten Dokumenten und Excel-Tabellen aus, um die Services, ihre Artefakte und die Abhängigkeiten zu beschreiben. Schon ab zehn bis 20 Services aber ist die Verwaltung all dieser Komponenten manuell kaum mehr möglich. Denn eine SOA besteht aus mehr als nur Services: Prozessdefinitionen und Policies etwa sind fester Bestandteil einer solchen Architektur.

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.

Hier lesen Sie …

Registry versus Repository

Eine Registry stellt ein Verzeichnis oder einen Katalog verfügbarer Dienste bereit, analog einem Branchen-Telefonbuch. Aus ihm geht nur wenig mehr hervor als die Adresse und wenige zusätzliche Informationen (Metadaten) über Services. Registries sind meist für den Run-time-Einsatz optimiert und bieten nur rudimentäre Unterstützung für Design-Time oder Business-Intelligence. Ein Repository hingegen speichert und kategorisiert Services mit ihren zugehörigen Artefakten.

Repositories unterstützen Design-time-Aufgaben, scheitern häufig aber an für RoI- Betrachtungen so wichtigen Run-time-Auswertungen.

Registry und Repository- besser integriert?

Die Frage, ob Registries und Repositories besser als ein integriertes Produkt in der SOA eingesetzt werden sollen, ist umstritten. Einige Hersteller propagieren ein kombiniertes System, wie es etwa die Software AG mit "Centrasite" anbietet. Anfang Oktober kündigte IBM mit dem "Websphere Registry and Repository" ein ähnliches System an. Bea Systems dagegen ging mit dem Zukauf eines separaten Repositories von Flashline einen anderen Weg. Zwei getrennte Produkte erhöhen die Komplexität der gesamten Architektur, argumentieren die Kritiker dieses Ansatzes. Deshalb sei es sinnvoll, Registry und Repository in einem Produkt zu vereinen. Anne Thomas Manes, SOA-Expertin bei der Burton Group, widerspricht dieser Einschätzung: Die Vorstellung, ein zentrales Registry-Repository-System könne die komplette SOA steuern, hält sie für unrealistisch. In der Praxis würden Unternehmen stets mehrere Systeme auf unterschiedlichen Ebenen einsetzen. Wolfgang Herrmann

Fazit

• Service-orientierte Architekturen benötigt Governance: Diese stützt sich auf organisatorische Maßnahmen und passende Werkzeuge in Form von Registries und Repositories. Für die Kombination dieser Tools bildet sich der Begriff Service-Repistry heraus.

• SOA-Governance ohne Registry und Repository ist ineffizient und nur in sehr kleinen Organisationen handhabbar. Schon für mehr als ein paar Dutzend Services benötigt eine Organisation automatisierte und übergreifende Unterstützung.

• SOA-Governance ergänzt konven-tionelle Corporate- und IT-Governance. Unternehmen sollten Governance ganzheitlich betrachten statt nur die SOA zu regulieren: Wichtige Aspekte wie die Wiederverwendung sind übergreifend zu behandeln.

Mehr zum Thema

www.computerwoche.de/

574933: Die besten Tools zur SOA-Verwaltung;

582230: IBM startet Produktoffensive für SOA;

581620: Bea bastelt an neuem SOA-Konzept;

581226: Webmethods schnappt sich Infravio;

578652: Software AG gründet SOA-Forum

SOA-Expertenrat

www.computerwoche.de/ soa-expertenrat

Bereits in der Konzeptions- und Implementierungsphase, aber auch während der Einführung von Softwarekomponenten entsteht eine Fülle von Dokumenten: Aus der Analyse stammen Geschäftsprozesse, Business-Cases und weitere Anforderungsdo- kumente; später kommen Architekturentwürfe, Implementierungsbeschreibungen, Test- und schließlich Betriebsdokumentation hinzu. Diese und andere Komponenten besitzen einen langfristigen Wert für Nutzer und Betreiber von Services. Sie sollten in jedem Fall für andere Beteiligte der SOA zur Verfügung stehen.

SOA-Governance

Ein übergreifender Ansatz für SOA-Governance ist vor diesem Hintergrund unerlässlich. Dazu müssen Unternehmen im ersten Schritt organisatorische Aspekte klären. Es bedarf Rollen wie die von Facharchitekten, Service-Architekten und Service-Entwicklern. Notwendig sind auch Organisationseinheiten wie ein SOA-Governance-Team, das Anlaufpunkt und Kontrollinstanz für SOA-Fragen ist. Solche Rollen und das Governance-Team können schrittweise wachsen. Sie sind aber frühzeitig zu definieren, damit die SOA zum wirtschaftlichen Erfolg wird.

Services und zugehörige Artefakte folgen einem spezifischen SOA-Service-Lebenszyklus (siehe Grafik: "Service-Lebenszyklus"). Ausgehend von der Geschäftsprozessanalyse und -optimierung entwerfen Unternehmen Schnittstelle und Implementierung für einen Service. Danach wird getestet und schließlich geht der Service in den produktiven Betrieb. Ergänzend finden in den Servicedesign-, Implementierungs- und Testphasen Architektur-Reviews statt. Am Design einer Serviceschnittstelle beteiligen sich typischerweise folgende Rollen: Ein Service-Champion aus der Fachabteilung, dem der Service fachlich "gehört". Außerdem ein Architekt, der für das fachliche Design des Service verantwortlich ist, damit dieser in die Servicelandschaft integrierbar ist. Weiterhin sind die technisch orientierten Rollen Service-Designer und Service-Entwickler zu besetzen, die den Entwurf und die Implementierung der Dienste übernehmen.

Registry und Repository im Duett

Werkzeuge, die bei der Steuerung und Kontrolle einer wachsenden SOA helfen, sind als SOA-Registry und Service-Repository bekannt. Während einfache Service-Registries nicht viel mehr als Schnittstellenbeschreibungen von Diensten speichern, erlauben Repositories die Verwaltung zahlreicher weiterer Serviceinformationen. Die für den Erfolg von SOA-Initiativen wichtige IT- und SOA-Governance benötigt beide Kategorien von Informationen. SOA-Registry und -Repository lassen sich daher zu einer integrierten Einheit zusammenfassen, die in Fachkreisen teilweise als "SOA Repistry" bezeichnet wird.

SOA-Registry und -Repository unterstützen den gesamten Lebenszyklus von Prozessen, Policies und Services. Facharchitekten, Service-Designer und Entwickler stellen während der Entwurfs- und Implementierungsphase - häufig Design-time genannt - immer wiederkehrende Fragen: Welche Services existieren bereits? Wie sehen deren Schnittstellen aus? Welches sind die zugehörigen Geschäftsprozesse oder verantwortlichen Organisationseinheiten? Besonders wichtig sind die Beziehungen zwischen Services und beteiligten Artefakten wie Serviceschnittstellen, Anforderungs-, Architektur- und Testdokumentation sowie Service Policies und Service Level Agreements (SLAs).

Wiederverwendung messen

Serviceentwurf und -Implementierung stellen indes nur einen Teil der SOA dar. Ist zum Beispiel ein Service in den produktiven Betrieb übergegangen (Run-time), so stellen Betreiber, Facharchitekten und Manager Fragen zur effektiven Nutzung der Softwaremodule. Voraussetzung hierfür ist ein Monitoring von Serviceaufrufen zur Laufzeit. Damit lassen sich Nutzungs- und Zugriffsmuster sowie die Einhaltung von SLAs feststellen. Aus der Häufigkeit der Nutzung eines Services ergibt sich der Grad der Wiederverwendung. Damit verbunden ist eine mögliche Verrechnung oder ein Provisioning von Services. Nicht oder wenig genutzte Dienste sind damit ebenfalls rasch identifizierbar und lassen sich von den Verantwortlichen aus dem Produktivbetrieb entfernen oder ersetzen. Die meistgenutzten Dienste können als Best-Practice-Lösung für die gesamte Organisation dienen.

RoI und Effizienz

Frühere Topdown-Ansätze der Softwareentwicklung, etwa mit Hilfe von CASE-Tools, können einzelne Services nur unzureichend bewerten. Diesen Ansätzen bleibt die Betriebs- und Laufzeit der Applikationen weitgehend verborgen. In Service-orientierten Architekturen besitzen Unternehmen mit Registry und Repository jedoch Instrumente, um auch Laufzeitaspekte in die IT- und SOA-Governance einzubeziehen. Das ermöglicht eine fundierte RoI- und Effizienzbetrachtung sowie die Chance, das Serviceportfolio-Management systematisch zu betreiben.

Moderne SOA-Registries und -Repositories integrieren zudem bestehende Metadaten, Policies und Dokumente aus heterogenen IT-Landschaften in einer SOA. Sie unterstützen damit insbesondere die SOA-typische Kombination aus Top-down-Neuentwicklung von Services und "Bottom-up-Harvesting", sprich die Nutzung bestehender IT-Anwendungen als Services im Rahmen einer übergreifenden Verwaltung von SOA-Artefakten.

Aufgaben des Repository

Zu den Aufgaben eines SOA-Registry- und Repository-Systems gehört zunächst die Katalogisierung aller Serviceinformationen. Weiterhin gilt es, alle Beziehungen zu erfassen, die zwischen den Services und SOA-Artefakten bestehen. Dazu zählen sowohl Design- als auch Run-time-Abhängigkeiten. Derartige Artefakte sind zum Beispiel in der Business Process Execution Language (BPEL) spezifizierte SOA-Prozesse, grafische Prozessdarstellungen mittels der Business Process Modeling Notation (BPMN), Geschäftsregeln, Servicebeschreibungen oder Serviceaufruf-Policies. Ein SOA-Registry und -Repository regelt darüber hinaus die Zusammenarbeit von Management- und Monitoring-Werkzeugen, um mit deren Hilfe Run-time-Policies oder SLAs überwachen zu können. Dazu werten die Systeme Run-time-Daten automatisch aus.

Entsprechend eng muss das Service-"Repistry" sowohl mit dem Enterprise Service Bus (ESB) als auch mit den SOA-Management- und Monitoring-Werkzeugen verzahnt sein. Ein konkretes technisches Szenario wäre das Folgende: Der ESB steuert die Kommunikation innerhalb der SOA, sendet also beispielsweise Serviceaufrufe als Nachrichten eines Web-Service-Konsumenten an einen passenden Serviceprovider. Vor der Auslieferung der Nachricht wird der Aufruf durch den ESB unterbrochen und über Management-Protokolle wie SNMP (Simple Network Management Protocol) oder JMX (Java Management Extension) an ein Verwaltungswerkzeug gesendet. Das Tool sammelt Informationen über die Aufrufe und speichert die Daten mit Hilfe des SOA-Registry und -Repository. Dieses kann dann wiederum Statistiken wie beispielsweise "Zahl der Aufrufe von Service ,HoleKundenDaten’ in den letzten vier Wochen" erstellen und mit anderen SOA-Daten verknüpfen.

Hinter einer Service-"Repistry" verbergen sich eine Reihe von Techniken, darunter Servicekataloge gemäß dem Registry-Standard UDDI (Universal Description, Discovery and Integration). In ihnen sind Service-Schnittstellenbeschreibungen abgelegt, die abgefragt werden können. Interessant ist die Möglichkeit, UDDI standardkonform um semantisch reichhaltige SOA-Artefaktbeschreibungen zu erweitern. Einen ähnlichen Weg zur Speicherung und Abfrage geht der Standard ebXML (Electronic Business XML), der einen technischen Rahmen zur Nutzung von XML für elektronische Geschäftsprozesse bildet.

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.

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.

Technische Vorteile

Das Konzept eines SOA-Registry und -Repository bietet auch der Technikebene Vorteile. So können Entwurf und Entwicklung von Services deutlich effizienter ablaufen, da alle relevanten Informationen zentral für die Entwickler abrufbar sind. Die Integration in Entwicklungsprozesse minimiert den Overhead für Entwickler und Architekten. Vorteilhaft ist hierbei eine Integration in klassische Entwicklungsumgebungen, wie beispielsweise Eclipse.

Die Einführung von Governance und eines damit verbundenen SOA-Registry und -Repository sollte beginnen, sobald erste Services produktiv im Einsatz sind. Typische Reifegradmodelle für SOA starten mit Pilotprojekten, in denen SOA zunächst auf Basis weniger Services eingeführt wird (siehe Grafik: "SOA-Reifegrad und Governance"). Oft geschieht dies zunächst durch die Integration existierender Anwendungen, wie beispielsweise produktiver Mainframe-Applikationen. Spätestens wenn diese frühe Phase erfolgreich beendet und die Entscheidung für den künftigen SOA-Einsatz gefallen ist, sollte die systematische Fortentwicklung der SOA geplant werden, einschließlich umfassender SOA-Governance mit adäquaten Werkzeugen.

Einführung und Betrieb eines SOA-Registry und -Repository müssen in jedem Fall als eigenständiges Projekt angelegt sein: Kein Fachbereich möchte aus seinem eigenen Budget eine solch strategische Investition leisten. Deshalb sollten Unternehmen jedes Verwaltungssystem unter die organisatorische Kontrolle eines SOA-Governance Komitees stellen, das sich aus Vertretern unterschiedlicher Fachbereiche und der IT zusammensetzt. (wh)