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.
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.
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.