Service-orientierte Architekturen (SOA) gewinnen in Unternehmen zunehmend an Bedeutung. Insbesondere die lose Kopplung von Services verspricht mehr Flexibilität. Durch die Vielzahl an Services und Prozessen in unterschiedlichen Varianten sowie deren gleichzeitige Verwendung durch Service-Nutzer, entstehen hohe Kosten für Betrieb und Wartung. Services, die nicht mehr genutzt werden, sollten deshalb zeitnah "abgeschaltet" werden. Um solche nicht mehr benötigten Services identifizieren zu können, muss u.a. bekannt sein, welche Services aktuell von wem benutzt werden. Zudem entstehen durch unterschiedliche Versionen von Services komplexe Abhängigkeiten, die durch eine geeignete Informationsverwaltung im SOA-Repository beherrscht werden müssen. Dieser Beitrag stellt die in diesem Zusammenhang bestehenden Anforderungen an ein Metamodell dar.
Service-Orientierung ist ein wichtiges Architekturprinzip für Unternehmen. Die Ziele einer Service-orientierten Architektur (SOA) [1,7,9] sind vielschichtig. Sie reichen von einer Erhöhung der Flexibilität durch Adaptierbarkeit der Geschäftsprozesse an geänderte Rahmenbedingungen [5,13] bis hin zu kürzeren Entwicklungszeiten sowie reduzierten Kosten für Service-und Prozess-orientierte Informationssysteme. Generell beschreibt eine SOA nicht nur ein technisches Paradigma. Vielmehr versucht sie das Zusammenspiel zwischen Fachbereichen und IT-Abteilungen zu verbessern, was in der Literatur auch als Business-IT-Alignment bezeichnet wird [3]. D.h. Informationssysteme sollen fachliche Anforderungen exakter treffen als bisher.
In
Eine zentrale Idee von SOA besteht darin, die Services verschiedener Anbieter einheitlich zu nutzen. Services abstrahieren dabei Funktionalitäten, die von anderen Applikationen verwendet werden können. Durch ihre Nutzung entsteht eine lose Kopplung zwischen Anbieter (engl.: provider) und Nutzer (consumer). Damit Service-Nutzer die richtigen Services finden und anschließend verwenden können, müssen Service-Informationen geeignet dokumentiert werden.
Heutige Repositories legen ihren Schwerpunkt entweder auf die Speicherung und Verwaltung technischer Artefakte (z.B. UDDI [12], WSRR [4]) oder Software-Komponenten [10,11]. Eingeschränkt betrachtet werden dabei die Möglichkeiten zur konsistenten und durchgängigen Modellierung sowie Dokumentation von fachlichen und technischen Services. So ist etwa die ARIS-interne Datenbank [8] in der Lage, fachliche und technische Artefakte zu verwalten. Die Beziehungen zwischen fachlichen und technischen Services werden im Regelfall aber nicht explizit verwaltet. Einige existierende Repositories bieten Erweiterungsmöglichkeiten zur Realisierung eines umfassenden Metamodells. [7,9] betonen die Notwendigkeit eines Repositories in einer SOA und fordern Funktionalitäten, wie die Bereitstellung von Service-Endpunkten für einen Enterprise Service Bus (ESB) oder die Möglichkeit für das Suchen und Auffinden von Services. Nicht betracht wird, welche konkreten Anforderungen an ein SOA-Repository existieren, d.h. welche konkreten Objekte in einem SOA-Repository verwaltet werden sollen und wie diese untereinander in Beziehung stehen.
In diesem Beitrag haben wir wichtige Anforderungen an ein SOA-Repository diskutiert, die für eine konsistente Modellierung, Dokumentation, Verwaltung und Speicherung von fachlichen und technischen Services unverzichtbar sind. Aus diesen Anforderungen werden wir im Projekt Enhanced Process Management by Service Orientation (ENPROSO) ein umfassendes und in sich konsistentes Gesamt-Metamodell für SOA-Repositories ableiten. Bei der Realisierung eines SOA-Repositories sollten aufgrund der mannigfaltigen wechselseitigen Abhängigkeiten zwischen Objekten ggf. nicht alle vorgestellten Anforderungen in der ersten Version des SOA-Repositories realisiert werden. Eine Umsetzung kann etwa durch eine relationale Datenbank oder durch eine Erweiterung vorhandener SOA-Repositories (bspw. WSRR [4]) realisiert werden.