Service-orientierte Architekturen erfordern fundamentale Veränderungen in den Design- und Entwicklungstechniken. Sie verlangen eine neue Dimension an projektteam- und abteilungsübergreifender Kooperation. Angesichts des Umfangs der Verhaltensänderungen, die beim Umsetzen eines SOA-Ansatzes notwendig werden, ist ein Governance-Programm entscheidend für den Erfolg jeder SOA-Initiative.
Produkte für SOA-Governance
• Stand-alone Registry
Eine Registry bildet die Grundlage für SOA-Governance. Sie ist zentraler Bezugspunkt für alle Services und Service-Artefakte in einer SOA-Umgebung. Sie unterstützt Erkennungsfunktionen und ermöglicht (sofern sie Standarddatenformate und -protokolle unterstützt) den Informationsaustausch. Sie stellt zudem eine Verbindung zwischen Entwicklungs- und Runtime-Governance- Tools her.
• Stand-alone Repository
Ein Stand-alone Repository unterstützt Erkennungsfunktionen. Es liefert Metadaten- und Content-Management und unterstützt typischerweise Lifecyle-Management- und Reporting-Funktionen. Ein Stand-alone Repository unterstützt aber nicht den Informationsaustausch zwischen Runtime-Systemen und ersetzt deshalb kein Registry-System.
• Registry/Repository
Ein Registry/Repository bündelt die Funktionen von Registry und Repository in einem einzigen Paket. Diese Kombination unterstützt Erkennungsfunktionen, Informationsaustausch, Metadaten- und Content-Management sowie Reporting-Funktionen. Viele Registry/Repository-Produkte sind zudem mit Lifecycle-Management-Funktionen ausgestattet. Fortschrittlichere Registry/Repository-Produkte beinhalten auch Genehmigungsprozesse, Vertrags-Management und Policy-Management.
• Stand-alone Vertrags- und/ oder Policy-Management- Systeme
Einige Anbieter bieten selbständige Produkte an, die Vertrags-Management und/oder Policy-Management unterstützen.
• SOA-Management-Systeme
Ein SOA-Management-System (auch als Web-Services-Management, WSM, bekannt) unterstützt die Runtime-Transparenz sowie Management und Mediation. Solche Systeme ermöglichen normalerweise auch das Definieren, Angliedern und Durchsetzen von Runtime-Richtlinien.
• XML-Gateways
XML-Gateways unterstützen leistungsstarke Runtime-Management- und Mediationsfunktionen.
• Enterprise Service Bus (ESB)
Ein Enterprise Service Bus wird typischerweise als Serviceplattform verwendet, kann aber auch Runtime-Mediationsfunktionen bieten.
Auswahl von Governance-Tools
• Einhaltung von Standards
SOA ist grundsätzlich von der Interoperabilität der Systeme abhängig: Das gilt für Governance ebenso wie für die Services selbst. UDDI und WS-Policy sind die wichtigsten Standards für SOA Governance.
• Verzahnung mit bestehenden Systemen
Um SOA-Governance so reibungslos wie möglich zu gestalten, sollten sich die Governance-Prozesse auch auf bestehende SDLC- und operative Prozesse erstrecken (SDLC = Software Development Lifecycle).
• Erweiterungsmöglichkeiten
Governance ist eine Sache der Unternehmenskultur. Dinge, die in einer Organisation gut funktionieren, können für eine andere völlig ungeeignet sein. Deshalb müssen sich Governance-Tools an die spezifischen Bedürfnisse eines Unternehmens anpassen lassen.
• Bedienkomfort
Mitarbeiter wehren sich normalerweise gegen neue Governance-Prozesse. Sollen diese Erfolg haben, müssen sie so "schmerzlos" wie möglich funktionieren. Ein Governance-Tool sollte die Dinge vereinfachen, nicht verkomplizieren.
Hier lesen Sie …
• was Werkzeuge zur SOA-Governance leisten sollten;
• welches die wichtigsten funktionalen Bausteine in der Designphase und im laufenden Betrieb sind;
• welche Auswahlkriterien für Verwaltungswerkzeuge wichtig sind.
www.computerwoche.de/
584528: SOA Software bringt Governance-Tool;
580733: Ein Plädoyer für Open-Source-SOA;
574933: Die besten Tools zur SOA-Verwaltung.
www.computerwoche.de/ soa-expertenrat
SOA-Initiative
SOA zwischen Reißbrett und Realität
Im Rahmen der SOA-Initiative 2007 zeigen erfahrene Experten, wie eine SOA entstehen kann - von der Planungsskizze bis zum soliden Bauwerk, das genügend Freiraum für die flexible Gestaltung Ihrer Geschäftsprozesse bietet.
SOA Initiative 2007 Die Fachkonferenz der computerwoche am 25. Januar 2007.
Informationen und Anmeldung: www.computerwoche.de/ soa2007.
Governance-Programm
Die Infrastruktur für SOA-Governance stellt Tools und Services zur Unterstützung eines solchen Programms bereit. Mit diesen werden Informationen über die Umgebung verwaltet, gepflegt und ausgetauscht. Darüber hinaus bieten sie Mechanismen, um in verschiedenen Phasen des Software Development Lifecycle (SDLC) Kontrollpunkte einzuführen, an denen eine Überprüfung der Services und/oder Projekte auf Einhaltung von SOA-Policies und -Richtlinien erfolgt. Ein SOA-Governance-Programm sollte Leitlinien für den gesamten Service-Lebenszyklus - also Erstellung, Tests, Konfiguration, Nutzung, operative Anwendung, Management und Versionsverwaltung von Services - bereitstellen.
In der Grafik ("Konzeptmodell SOA-Governance") wird ein Konzeptmodell für die Funktionskomponenten einer Governance-Infrastruktur dargestellt. Einige Infrastruktur-Komponenten beziehen sich auf die Governance in der Entwicklungszeit der Services (Development), andere auf den laufenden Betrieb (Runtime). Der Registry-Service verbindet Entwicklungs- und Runtime-Komponenten miteinander.
Registry-Service als Fundament
Ein Registry-Service (Registrierung) stellt das Fundament für SOA-Governance dar und schafft eine Verbindung zwischen Entwicklungs- und Runtime-Governance. Der Registrierungsprozess bietet einen Kontrollpunkt im Service-Provisioning, an dem das Unternehmen Compliance-Tests betreiben und Genehmigungsprozesse einrichten kann.
Der Registry-Service verwaltet einen Speicher mit Registrierungsdaten, der grundlegende Informationen über Services pflegt und Verbindungen zu Service-Metadaten und -Artefakten herstellt. Dieser Datenspeicher bietet einen zentralen Bezugspunkt (Single-Point-of-Reference) innerhalb der Umgebung. Die aktuellen Metadaten und Artefakte werden typischerweise in verschiedenen Repositories in der gesamten Umgebung gespeichert.
Eine Registry unterstützt zudem den Informationsaustausch. Ein Metadaten-Management-System kann aus der Registry Informationen über aktive Systeme herausziehen und sie in einem Repository hinterlegen. In vergleichbarer Weise kann eine Registry Runtime-Richtlinien in Runtime-Management- und Mediationssystemen hinterlegen, die für den laufenden Betrieb verantwortlich sind. Während der Laufzeit nutzen Serviceendpunkte, Mediationssysteme und Management-Systeme den Registry-Service zum Austausch von Informationen. Um den Informationsaustausch zu ermöglichen, sollte ein Registry-System den Standard Universal Description, Discovery and Integration (UDDI) v3.0 unterstützen.
Entwicklungszeit-Komponenten
Entwicklungszeit-Komponenten unterstützen Governance-Prozesse in den Lebenszyklusphasen der Serviceerstellung, -prüfung, -nutzung und Versionsüberwachung. Dazu zählen Aspekte wie beispielsweise Strategie-Management, Produktauswahl, Servicedesign und -entwicklung, Servicetests, Vertrags-Management und Change-Management.
Komponenten der Entwicklungszeit-Governance sollten mit konventionellen SDLC-Tools (Software Development Lifecycle) wie beispielsweise Anforderungs-Management, Modellierungs-Tools und Fehlersuchsystemen verknüpft werden. Sie sollten in der Lage sein, Metadaten, Codes, Test-Scripts und andere Artefakte mit konventionellen SDLC-Repositories auszutauschen. Und sie sollten die Transparenz in der Entwicklungsumgebung mit Hilfe konventioneller SDLC-Dashboards unterstützen. Zu den Funktionskomponenten der Entwick-lungszeit gehören Systeme für Policy-Management, Metadaten-Management und Vertrags-Management.
Policy-Management-System
Mit einem Policy-Management-System werden Governance-Policies verwaltet und gepflegt. Ein solches System behandelt eine Richtlinie als Artefakt und verwaltet den gesamten Policy-Lebenszyklus. Die Policy-Artefakte werden typischerweise in einem Repository verwaltet.
Mit Hilfe von Policies können sowohl Entwicklungsrichtlinien als auch Laufzeitbedingungen definiert werden. Beispielsweise könnte eine Entwicklungsrichtlinie Namespace-Konventionen definieren oder die Anforderung spezifizieren, dass alle Services mit dem Standard Web Services Interoperability Organization (WS-I) Basic Profile übereinstimmen müssen. Entwicklungsrichtlinien können mit einem oder mehreren Service-Artefakten verknüpft sein, wie beispielsweise einer Web Services Description Language(WSDL-) oder einer XML-Schema-Datei. Eine Runtime-Policy könnte eine Authentifizierungsanforderung oder ein Service-Level-Agreement (SLA) definieren. Runtime-Policies können mit einem Vertrag zwischen einem bestimmten Servicenutzer und einem Serviceanbieter verknüpft sein oder mit allen Abnehmern eines Service oder einer Gruppe von Services zusammenhängen. Ein Policy-Management-System unterstützt zudem Compliance-Tests. Es sollte mit konventionellen Entwicklungs-Tools und Runtime-Systemen verzahnt sein und so das Durchsetzen von Richtlinien so nahtlos und automatisch wie möglich gestalten.
Werden Services bereitgestellt, so können über die Registry Runtime-Policies in Runtime-Management- und Mediationssystemen hinterlegt werden. Um die Interoperabilität zu unterstützen, sollten Richtlinien mit Hilfe des Web Services Policy Framework (WS-Policy) kodifiziert werden.
Metadaten-Management-System
Mit einem Metadaten-Management-System werden zu SOA-Systemen gehörende Metadaten und Artefakte verwaltet und gepflegt. Ein Metadaten-Management-System implementiert ein Change-Management für Service-Metadaten und unterstützt Aktivitäten wie Release-Management und Service-Versioning (Versionsüberwachung). Die Metadaten-Artefakte werden typischerweise in einem Repository verwaltet.
Metadaten umfassen beispielsweise Informationen über Services, Service-Provider, Servicenutzer, Serviceversionen, Serviceschnittstellen, Nachrichtenformate, Runtime-Policies oder Interaktionsbeschreibungen. Service-Artefakte beinhalten Modelle, Code, Tests und Dokumentation. Ein Metadaten-Management pflegt auch Beziehungs- und Abhängigkeitsinformationen über Services.
Das Metadaten-Management-System bietet darüber hinaus einen Ort, über den an verschiedenen Stellen im Servicelebenszyklus Compliance-Tests und Genehmigungsprozesse eingerichtet werden können (Design, Entwicklung, Tests und Verbesserungen). Wenn Policies mit einem Policy-Management-System verknüpft sind, können sie verschiedenen Artefakten angefügt und während konventioneller SDLC-Aktivitäten auf Compliance getestet werden. Ein Metadaten-Management-System erfasst auch Parameter und bietet umfassende Reporting-Funktionen.
Vertrags-Management-System
Mit einem Vertrags-Management-System werden Verträge zwischen Servicenutzer und Serviceanbieter verwaltet und gepflegt. Ein Vertrag umfasst Metadatendefinitionen des technischen Service (beispielsweise Schnittstellen, Nachrichtenformate und Runtime-Policies), darüber hinaus SLAs, Support-Agreements oder Vergütungsvereinbarungen. Das Vertrags-Management-System behandelt einen Vertrag als Artefakt und verwaltet die gesamte Vertragslebenszeit. Die Vertragsprodukte werden typischerweise in einer Art von Repository verwaltet.
Ein Vertrags-Management-System unterstützt zudem den Prozess, in dem Servicenutzer und Serviceanbieter einen Vertrag verhandeln. Nachdem ein Vertrag verhandelt wurde, werden alle Vereinbarungen, die sich auf die Runtime-Infrastruktur auswirken, in der Registry erfasst und in den entsprechenden Service-Mediationssystemen und Service-Management-Systemen für den laufenden Betrieb hinterlegt.
Runtime-Komponenten
Runtime-Governance-Komponenten setzen Management- und Kontrollrichtlinien im laufenden Betrieb um. Dabei geht es beispielsweise um Richtlinien bezüglich Sicherheit, Routing, Versionsüberwachung oder Lastausgleich. Runtime-Governance-Komponenten sollten mit konventionellen IT-Management- und Governance-Systemen verzahnt werden. Zu den Komponenten für die Governance während der Laufzeit gehören Systeme für das Service-Management und die Service-Mediation.
Service-Management-System
Ein Service-Management-System verwaltet, überwacht und kontrolliert die SOA-Umgebung zur Laufzeit. Verwalten bedeutet dabei das Konfigurieren von Services, Servicerichtlinien und SOA-Infrastrukturkomponenten. Service-Konfigurationsinformationen sollten an IT-Konfigurationssysteme weitergeleitet und in der Configuration Management Database (CMDB) erfasst werden.
Service-Mediationssystem
Ein Service-Mediationssystem unterstützt Anforderungen einer SOA-Infrastruktur bezüglich Sicherheit, Leistung, Skalierbarkeit oder Transformation. Service-Mediationssysteme liefern und koordinieren Vermittler (Intermediaries), die den Nachrichtenverkehr nach festgelegten Richtlinien überwachen, optimieren und kontrollieren. Vermittler fungieren dabei als Policy Enforcement Points (PEPs), die den Nachrichtenverkehr an strategischen Punkten entlang dem Nachrichtenpfad unterbrechen und Richtlinien durchsetzen. Vermittler speisen zudem Runtime-Parameter in die Management-Systeme ein, um für zusätzliche Transparenz in Echtzeit zu sorgen.
Das Angebot an Produkten und Tools, die SOA-Governance unterstützen, ist groß. Leider passen SOA-Governance-Produkte nicht notwendigerweise direkt zu den im Konzeptmodell definierten Funktionskomponenten. Die verbreitetsten Tools sind im Kasten "Produkte für SOA-Governance" beschrieben.
Empfehlungen
Für viele Organisationen ist die große Vielfalt an neuen Governance-Produkten erst einmal verwirrend. Ein umfassendes Governance-Programm wird durch solche Tools zwar enorm verbessert. Es sollte jedoch bedacht werden, dass die Werkzeuge Governance-Prozesse lediglich unterstützen können. Sie sind keine Garantie für erfolgreiche Strukturen. Eine der wichtigsten Komponenten ist eine Unternehmenskultur, die gute Führungspraktiken unterstützt. Ohne organisatorische Unterstützung können Tools nicht zu einem leistungsstarken Governance-Programm führen.
Start small, think big
Die entscheidenden Aspekte einer SOA-Governance-Infrastruktur sind die, die die Entdeckungsprozesse für Services, den Informationsaustausch sowie Runtime-Management und -Mediation unterstützen. Diese Funktionen können mit Hilfe eines Registry- und eines SOA-Management-Systems erfüllt werden. Zu beachten ist jedoch, dass es Unternehmen ohne Repository wesentlich schwerer fallen wird, die sich im Laufe der Zeit weiter entwickelnden Services angemessen zu verwalten. Wer also die Entscheidung trifft, zunächst klein anzufangen, sollte sich darauf einstellen, das Governance-Programm mit der Zeit auszubauen. (wh)