=Paper=
{{Paper
|id=None
|storemode=property
|title=Anforderungen an ein Metamodell für SOA-Repositories
|pdfUrl=https://ceur-ws.org/Vol-563/paper2.pdf
|volume=Vol-563
|dblpUrl=https://dblp.org/rec/conf/zeus/BuchwaldTR10
}}
==Anforderungen an ein Metamodell für SOA-Repositories==
https://ceur-ws.org/Vol-563/paper2.pdf
Anforderungen an ein Metamodell für SOA-Repositories
Stephan Buchwald1, Julian Tiedeken1,2, Thomas Bauer1, Manfred Reichert2
1
Abteilung für Daten- und Prozessmanagement, Daimler AG,
{stephan.buchwald, julian.tiedeken, thomas.tb.bauer}@daimler.com
2
Institut für Datenbanken und Informationssysteme, Universität Ulm
{manfred.reichert, julian.tiedeken}@uni-ulm.de
Abstract: Service-orientierte Architekturen (SOA) gewinnen in Unternehmen
zunehmend an Bedeutung. Insbesondere die lose Kopplung von Services ver-
spricht mehr Flexibilität. Durch die Vielzahl an Services und Prozessen in unter-
schiedlichen 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, wel-
che Services aktuell von wem benutzt werden. Zudem entstehen durch unter-
schiedliche Versionen von Services komplexe Abhängigkeiten, die durch eine
geeignete Informationsverwaltung im SOA-Repository beherrscht werden müs-
sen. Dieser Beitrag stellt die in diesem Zusammenhang bestehenden Anforde-
rungen an ein Metamodell dar.
1 Motivation
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. Gene-
rell 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. Informati-
onssysteme sollen fachliche Anforderungen exakter treffen als bisher.
In einer SOA wird die Geschäftsprozessmodellierung durch fachliche Services und
fachliche Datenobjekte unterstützt, deren Dokumentation aber abstrakt gehalten ist.
Sie werden auf Implementierungsebene ggf. durch mehrere technische Services und
Datenobjekte verfeinert. Das Zusammenspiel und die Beziehung zwischen fachlichen
und technischen Services, Prozessen und Datenobjekten sind in der Praxis meist nicht
ausreichend dokumentiert. Deshalb entstehen zahlreiche Probleme: So kann bei Au-
ßerbetriebnahme eines Services nicht immer nachvollzogen werden, welche Prozesse
oder Applikationen davon betroffen sind. Dadurch ist es schwierig, sicherzustellen,
dass die Abschaltung nicht zu unerwarteten Fehlern führt. Zusätzliche Komplexität
entsteht dadurch, dass sowohl fachliche als auch technische Services (und Datenob-
jekte) in unterschiedlichen Versionen existieren. Um die Metainformation zu all die-
sen Objekten sowie relevante Beziehungen zwischen ihnen beherrschen zu können, ist
ein Repository notwendig, welches die Daten speichert. Durch deren logisch zentrale
Verwaltung wird mehr Transparenz zu Objektabhängigkeiten geschaffen, was Inkon-
sistenzen nach Änderungen an Objekten (z.B. fachliche und technische Services oder
Datenobjekte) erkennbar macht sowie eine Reaktion darauf zulässt. Außerdem muss
die Entwicklung neuer Applikationen dahingehend unterstützt werden, dass relevante
Informationen in jeder Phase des Entwicklungsprozesses durch das SOA-Repository
bereitgestellt werden. Um möglichst schnell von fachlichen Anforderungen zu deren
IT-Implementierung zu gelangen, ist eine durchgängige Modellierungsmethodik [2]
notwendig, die ebenfalls durch das SOA-Repository unterstützt werden muss.
Dieser Beitrag stellt erstmalig und vollständig Anforderungen an das Metamodell
eines zentralen SOA-Repositories aus Praxissicht vor. Dies legt die Basis zur Ent-
wicklung eines Gesamt-Metamodells für SOA-Repositories. Dazu betrachten wir in
den Kapiteln 2 bis 4 Ziele einer SOA und leiten daraus Anforderungen an das Meta-
modell ab. Kapitel 5 diskutiert verwandte Arbeiten, bevor mit einer Zusammenfas-
sung geschlossen wird.
2 Nutzung angebotener Services
Eine zentrale Idee von SOA besteht darin, die Services verschiedener Anbieter ein-
heitlich 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 Servi-
ce-Nutzer die richtigen Services finden und anschließend verwenden können, müssen
Service-Informationen geeignet dokumentiert werden.
Anforderung 1: Service-Publikation und -Kontrakt
Bevor ein Service genutzt werden kann, sollte er in einem SOA-Repository publiziert
werden. Anschließend kann ein potentieller Nutzer im Repository nach Services su-
chen, z.B. unter Verwendung von Suchkriterien wie angebotene Funktionalität oder
verwendete Datenobjekte. Zur Ausführungszeit muss die physische Lokation eines
Services mittels des Repositories ermittelbar sein, damit der Service-Aufruf durchge-
führt werden kann. Der Einsatz eines Proxies (bspw. Enterprise Service Bus) ermög-
licht die Entkopplung des Service-Aufrufs, d.h. Service-Nutzer rufen nicht direkt den
konkreten Service, sondern einen Proxy-Service. Letzterer ermöglicht ein dynami-
sches Binden sowie eine Endpunktauswahl des tatsächlichen Services.
Für die Verwendung eines Services ist eine Nutzungsvereinbarung (contract) zwi-
schen Anbieter und Nutzer notwendig. Diese klärt Ansprüche und Pflichten und bein-
haltet Informationen zu Nutzungskosten, Antwortzeiten, Verfügbarkeit und Sicher-
heitsaspekten. Dem entsprechend sind die im folgenden ER-Diagramm in Min-Max-
Notation skizzierten Objekte und Beziehungen im SOA-Repository zu verwalten
(Attribute nur teilweise dargestellt):
(1,1) (0,N) (0,N) (0,N) name
Contract is consumer System provides Service description
…
(1,N) (0,N) endpoint
service used
Abbildung 1: Kontrakt zwischen Service und System (Anbieter und Nutzer)
Ein System (Service-Anbieter bzw. Service-Nutzer) innerhalb eines Unternehmens
kann sowohl ein Prozess oder eine Applikation (etwa J2EE [14]) sein, welches seine
atomaren Funktionalitäten in Form von Services anbietet oder benötigte Funktionali-
tät über Services konsumiert. Ein Contract ist dabei stets exakt einem System zuge-
ordnet, wohingegen ein System beliebig viele Contracts hält.
Anforderung 2: Domänen zur Strukturierung
Die Untergliederung eines Unternehmens in Domänen auf organisatorischer Ebene
dient u.a. dazu, einen Überblick über Funktionalität und Geschäftsobjekte verschiede-
ner Fachbereiche zu erhalten [6]. Dabei werden unternehmensrelevante Funktionen
sowie bestehende fachliche und technische Services der verschiedenen (Sub-) Domä-
nen erfasst. Dadurch wird transparent, welche Funktionalität durch welche (Sub-)
Domänen realisiert wird und wo Redundanzen bestehen.
Um Services auch Domänen-basiert suchen zu können, muss das SOA-Repository
explizit die Beziehungen zwischen (Sub-)Domänen und angebotenen Services spei-
chern. Damit sich Änderungen an Services effizient koordinieren lassen, werden Do-
mänenverantwortliche im Repository verwaltet.
… (0,1) (0,N) name
Service offered by Domain
service responsible domain responsible
Abbildung 2: Service-Zuordnung zu Domänen
Anforderung 3: Informationserzeugung und -verwendung
Bei der Entwicklung eines Services sind neben unterschiedlichen Personengruppen
verschiedene Werkzeuge im Einsatz. Diese dienen der fachlichen Beschreibung bzw.
technischen Implementierung von Services. Sie erzeugen neue Informationen, ver-
wenden aber auch existierende Dokumente aus dem SOA-Repository. Während der
fachlichen Prozessmodellierung etwa werden neue fachliche Services erzeugt und
bereits vorhandene weiterentwickelt. Diese verwenden Geschäftsobjekte, welche die
Ein- und Ausgabeparameter der fachlichen Services darstellen. Die fachliche Service-
Spezifikation (Fachspezifikation) bildet die Grundlage für die technische Service-
Implementierung.
business specification Business (0,N) (1,1) Business (0,N) (0,N) Business
offers has in-/output
… Service Operation Object
Abbildung 3: Fachliche Beschreibung von Services
Analog wird eine technische Service-Spezifikation (WSDL) inklusive technischer
Operationen und den verwendeten Parametern (Datenschemata z.B. als XSD) im
Repository gespeichert. Als Attribute werden zu einem technischen Service ein Nut-
zungshandbuch und nach der Implementierung und Installation ein Endpunkt bereit-
gestellt.
3 Gewährleistung der langfristigen Stabilität einer SOA
Auch im Kontext von Änderungen der Service-Landschaft müssen Service-nutzende
Applikationen zuverlässig funktionieren. Jede freigegebene Änderung an Repository-
Objekten sollte deshalb wieder zu einer gültigen Service-Landschaft führen: Es dür-
fen keine Inkonsistenzen entstehen, etwa durch Abschalten eines Services, für den
eine Nutzung noch vertraglich garantiert wird. Im Folgenden betrachten wir Anforde-
rungen an das Repository-Metamodell, welche die Stabilität einer SOA unterstützen.
Anforderung 4: Service-Lifecycle-Management
Während der Entwicklung einer Prozessapplikation durchlaufen Services unterschied-
liche Zustände. Sie beschreiben z.B., ob für einen Service bereits eine Fachspezifika-
tion vorliegt oder ob er bereits realisiert bzw. freigegeben ist. Die einzelnen Zustände,
die ein Service durchlaufen kann, werden in einem Service-Lebenszyklus (Service
Lifecycle) dokumentiert und beschrieben [9]. Ein Wechsel des Service-Zustands er-
folgt erst, wenn alle Vorraussetzungen an den Nachfolgezustand erfüllt sind, etwa das
Vorliegen einer Fachspezifikation oder eines Entwicklungshandbuchs. Die Kontrolle
und Überwachung der Zustandsübergänge wird durch Governance-Prozesse realisiert.
Sie regeln unter anderem das Änderungsmanagement von Services und Prozessen,
indem sie festlegen, von wem Änderungen zu genehmigen sind. Entscheidungsgrund-
lage dafür ist die im SOA-Repository gespeicherte Information.
… Business (0,N) (0,1) Technical
WSDL
realised by
state Service Service state
Abbildung 4: Speicherung von Service-Zuständen
Zur Sicherstellung der Qualität von Services werden Compliance-Prüfungen wäh-
rend ihrer Entwicklung durchgeführt, die eine korrekte und kontrollierte Realisierung
gewährleisten sollen. Die dazu notwendigen Dokumente, etwa Fachspezifikationen
oder WSDL-Beschreibungen, sind im SOA-Repository abzulegen.
Anforderung 5: Speicherung der Beziehungen zwischen Repository-Objekten
Fachliche und technische Artefakte, wie Service- oder Datenobjekte, stehen in direk-
ter Beziehung zueinander: Ein fachlicher Service wird durch einen oder mehrere
technische Services realisiert. Dabei verwendet eine Operation eines fachlichen Ser-
vices Business-Objekte, die technisch auf ein oder mehrere Datenobjekte abgebildet
werden. Um nach Änderungen an fachlichen Services, Operationen oder Business-
Objekten festzustellen, ob bzw. welche technischen Artefakte angepasst werden müs-
sen, sollten die Beziehungen zwischen diesen Objekten im Repository explizit ver-
waltet werden:
Business (0,N) (1,1) Business (0,N) (0,N) Business
offers has in-/output
Service Operation Object
(0,N) (0,N) (0,N)
realised by realised by realised by
(0,1) (0,1) (0,1)
Technical (0,n) (1,1) Technical (0,N) (0,N) Technical
offers has in-/output
Service Operation Object
Abbildung 5: Abhängigkeiten zwischen fachlichen und technischen Services
Anforderung 6: Service-Versionen und Plantermine
Services werden in einer SOA kontinuierlich weiter entwickelt, wodurch neue Servi-
ce-Versionen (sowohl fachlich als auch technisch) entstehen und veraltete „abgeschal-
tet“ werden müssen. Durch die Vielzahl Service-konsumierender Applikationen ist
eine Abschaltung jedoch nicht immer einfach durchzuführen, sondern macht für viele
Applikationen eine aufwendige Anpassung erforderlich. Um Inkompatibilitäten zwi-
schen Service-Anbieter und -Nutzer transparent zu machen, sollen neben den Abhän-
gigkeitsbeziehungen auch Plantermine für die Abschaltung von Service-Versionen im
Repository dokumentiert werden. Dadurch kann die Konsistenz überprüft und früh-
zeitig auf geplante Abschaltungen reagiert werden. Analog dazu können Plantermine
eingeführt werden, welche die Nutzbarkeit einer neuen Service-Version anzeigen.
Neue Service-Nutzer können dann z.B. prüfen, ob die neue Service-Version rechtzei-
tig zur Verfügung stehen wird oder ob eine ältere Version zu verwenden ist.
Technical (0,N) (1,1) Technical start date
realised by
Service Service Version sundown date
Abbildung 6: Versionierung von technischen Services
4 Permanente und durchgängige Speicherung von Modelldaten
Fachliche Prozesse und Services werden mit Werkzeugen (z.B. ARIS bzw. erweiter-
ten Ereignisgesteuerten Prozess-Ketten) modelliert, wohingegen technische Prozesse
häufig in CASE-Tools mit UML-Unterstützung dokumentiert werden. Infolge der
unterschiedlichen Kenntnisse von Fach- und IT-Personal, werden fachliche Anforde-
rungen oft unzureichend umgesetzt und es entsteht eine Lücke zwischen Fachbereich
und IT-Abteilung. Deshalb ist es unabdingbar, die modellierte Information dauerhaft
zu archivieren und diese Lücke zu schließen (Business-IT-Alignment [3]).
Anforderung 7: Langfristige Archivierung von Prozess- und Service-Modellen
Die langfristige Dokumentation von fachlichen und technischen Services sowie von
Prozessen auf den Ebenen Fachmodell und technischem Modell ist essentiell. Hier-
durch kann später nachvollzogen werden, welche konkreten Anforderungen und
Fachprozesse durch eine Applikation bereits realisiert sind. Diese Information ist die
Ausgangsbasis für eine Überarbeitung der Applikation (Application-Reengineering),
nachdem sich Anforderungen geändert haben.
Business (0,N) realised (0,N) (0,N) (0,N) Business
processes System provides
Process Service
business process model service model
…
Abbildung 7: Archivierung von Modellinformationen
Anforderung 8: Beziehungen zwischen fachlichen und technischen Aktivitäten
Werden im SOA-Repository einzelne Aktivitäten der fachlichen und technischen
Prozessmodelle und deren Beziehungen verwaltet, erhöht sich die Nachvollziehbar-
keit, da Beziehungsrelationen zwischen fachlichen Anforderungen, fachlichen Servi-
ces und ihrer Implementierung dokumentiert sind. Hierbei muss für jede Aktivität des
fachlichen Modells (und damit für ihre Eigenschaften und Anforderungen) dokumen-
tiert werden, durch welche Aktivität des technischen Modells diese realisiert wird [2].
Dadurch ist bei einer späteren Änderung fachlicher Aktivitäten leicht erkennbar, wel-
che technischen Aktivitäten bzw. Services angepasst werden müssen. Zudem ist die
Speicherung des Prozessmodells (Business Process Model) möglich, auch wenn die
eigentliche Systemauswahl noch nicht abgeschlossen ist.
(0,N) Business (1,N) (1,1) Business (0,N)
realised
contains
processes Process Model Process Activity
(0,N)
transformation type
System realised by
description
(0,N)
(0,N) Technical (1,N) (1,1) Technical (0,N)
realised
contains
processes Process Model Process Activity
Abbildung 8: Beziehung zwischen fachlichen und technischen Aktivitäten
5 Verwandte Arbeiten
Heutige Repositories legen ihren Schwerpunkt entweder auf die Speicherung und
Verwaltung technischer Artefakte (z.B. UDDI [12], WSRR [4]) oder Software- Kom-
ponenten [10, 11]. Eingeschränkt betrachtet werden dabei die Möglichkeiten zur kon-
sistenten und durchgängigen Modellierung sowie Dokumentation von fachlichen und
technischen Services. So ist etwa die ARIS-interne Datenbank [8] in der Lage, fachli-
che 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 Realisie-
rung eines umfassenden Metamodells. [7, 9] betonen die Notwendigkeit eines Reposi-
tories 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 Anforde-
rungen an ein SOA-Repository existieren, d.h. welche konkreten Objekte in einem
SOA-Repository verwaltet werden sollen und wie diese untereinander in Beziehung
stehen.
6 Zusammenfassung und Ausblick
In diesem Beitrag haben wir wichtige Anforderungen an ein SOA-Repository disku-
tiert, die für eine konsistente Modellierung, Dokumentation, Verwaltung und Speiche-
rung von fachlichen und technischen Services unverzichtbar sind. Aus diesen Anfor-
derungen werden wir im Projekt Enhanced Process Management by Service Orienta-
tion (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.
Literatur
1. S. Buchwald, T. Bauer, R. Pryss: IT-Infrastrukturen für flexible, service-orientierte An-
wendungen – Ein Rahmenwerk zur Bewertung; In. Proc. 13. GI-Fachtagung Datenbank-
systeme in Business, Technologie und Web, S. 524-543, Münster; 2009
2. S. Buchwald, T. Bauer, M. Reichert: Durchgängige Modellierung von Geschäftsprozessen
in einer Service-orientierten Architektur; In. Proc. GI-Fachtagung Modellierung’10, Kla-
genfurt, 2010 (forthcoming)
3. H.-M. Chen: Towards Service Engineering, Service Orientation and Business-IT Align-
ment; In. Proc. 41st Hawaii Inf. Conf. on System Sciences; 2008
4. C. Dudley et al.: WebSphere Service Registry and Repository Handbook; 2007
5. P. Dadam, M. Reichert: The ADEPT Project: A Decade of Research and Development for
Robust and Flexible Process Support. Springer, 2009
6. G. Engels et al.: Quasar Enterprise: Anwendungslandschaften serviceorientiert gestalten,
dpunkt.verlag, 2008.
7. T. Erl: SOA: Concepts, Technology, and Design; Prentice Hall, 2005
8. IDS Scheer: ARIS SOA Architect - Geschäftsprozesse als Grundlage für Service-
orientierte Architekturen; IDS Scheer, 2008
9. N. M. Josuttis: SOA in Practice; The Art of Distributed System Design. O'Reilly, 2007
10. B. Li et al.: Building Interoperable Software Components Repository Based on MMF,
Grid and Cooperative Computing (GCC) Workshops, 2004
11. M.J. Morel, J. Faget: The REBOOT Environment. Proceedings of the 2nd International
Workshop on Software Reusability Advances in Software, 1993
12. OASIS: Universal Description, Discovery, and Integration (UDDI), Version 3.0, 2002
13. M. Reichert, D. Stoll: Komposition, Choreograhpie und Orchestrierung von Web Services:
Ein Überblick. EMISA Forum, Vol. 24, No. 2, pp. 21-32, 2004
14. J. Keogh. J2ee: The Complete Reference. Osborne/McGraw-Hill, Berkeley, CA, USA,
2002.