Erhöhung der System-Stabilität und -Flexibilität durch ein SOA-Repository mit Analysefähigkeiten [original]

HNU Working Paper

Nr. 32

Thomas Bauer

Stephan Buchwald

Julian Tiedeken

Manfred Reichert

Erhöhung der System-Stabilität und -Flexibilität

durch ein SOA-Repository mit Analysefähigkeiten

Increasing System Stability and Flexibility

by a SOA Repository with Analysis Capabilities

04 / 2014

Dr. Thomas Bauer, Professor für Wirtschaftsinformatik mit Schwerpunkt Datenbanken,

Hochschule für angewandte Wissenschaften Neu-Ulm

University of Applied Sciences,

Wileystraße 1, D-89231 Neu-Ulm

Dr. Stephan Buchwald, T-Systems Int., Delivery Unit Automotive & Manufacturing Industries,

Olgastraße 63, D-89073 Ulm

Julian Tiedeken, Prof. Dr. Manfred Reichert,

Universität Ulm, Institut für Datenbanken und Informationssysteme,

James-Franck-Ring, D-89081 Ulm

Abstrakt

In einer Service-orientierten Architektur (SOA) werden bereitgestellte Services von Service-

nutzern, etwa fremden IT-Systemen konsumiert. Eine Serviceänderung bzw. -abschaltung

kann solche Servicenutzer schwer beeinträchtigen. Deshalb müssen diese vor einem solchen

Eingriff ermittelt werden, wozu das SOA-Repository genutzt werden kann. Allerdings ist bei

umfangreichen SOA-Repositories schwer erkennbar, welche IT-Systeme (evtl. indirekt) in

welchem Zeitraum betroffen sein werden. Da diese Problemstellung in der bisherigen SOA-

Literatur nicht betrachtet wird, stellen wir ein Lösungskonzept vor. Es ermöglicht automatisierte

Analysen, um in den Daten enthaltene Problemsituationen identifizieren zu können (Ist-

Analysen), und auch, um Auswirkungen zukünftig durchzuführender Serviceänderungen zu

simulieren (Planspiele).

Freie Schlagwörter:

Service-orientierte Architektur (SOA), SOA-Repository, Ist-Analysen, What-If-Analysen

Abstract

In a service-oriented architecture (SOA), provided services are used by service consumers;

e.g., foreign IT systems. A change or shut-down of a service may heavily affect such service

consumers. Therefore, they have to be identified before such a change. For this purpose the

SOA repository may be used. At large SOA repositories, however, it is difficult to figure out

which IT systems may be (perhaps indirectly) affected in which period of time. Since this issue

is not respected in current SOA literature, we present a concept for its solution. It enables

automatic analyses in order to detect problems already existing in the data (as-is analyses) as

well as to simulate service changes that will occur in future (what-if analyses).

Keywords:

Service-oriented architecture (SOA), SOA repository, As-is analyses, What-if analyses

JEL-Klassifikation: M15

1 Einleitung

Service-orientierte Architekturen (SOA) führen zu einer Erhöhung der Flexibilität [Jo07]. So

ermöglicht beispielsweise die lose Kopplung beim Service-Aufruf [Er05], schnell zur

Verwendung eines anderen Services zu wechseln. Dadurch dass ein Proxy (Enterprise Service

Bus, ESB) zwischen die aufrufende Applikation und den verwendeten Service geschaltet wird,

muss für diesen Wechsel lediglich der Proxy verändert werden, jedoch nicht die

konsumierende Applikation selbst. Wir nutzen im Projekt ENPROSO1 zahlreiche solcher

Mechanismen zur Erhöhung der Flexibilität [BBR11, Bu12].

Die hohe Flexibilität bei Service-Aufrufen kann jedoch zu einer Starre beim Betrieb der

Services führen: So werden manche Veränderungen an bereitgestellten (d.h. betriebenen)

Services erschwert. Dies gilt insb. für die Abschaltung von Services, da dies die Funktions-

fähigkeit der Servicenutzer (Consumer) beeinträchtigen kann. Ein solcher Fall muss unbedingt

vermieden werden, weil selbst ein Ausfall einzelner Funktionalitäten der Service-nutzenden

Applikationen meist nicht akzeptabel ist. Andererseits verursacht ein sehr lange andauernder

Weiterbetrieb sehr vieler veralteter Services hohe Kosten, die ebenfalls vermieden werden

müssen. Das bedeutet, dass ein Konzept entwickelt werden muss, um ungenutzte Services

zuverlässig identifizieren und dann abschalten zu können (Service Sun-down).

Die in der SOA-Literatur üblicherweise vorgeschlagene Methode zur Identifizierung solcher

Services ist die Nutzung von Informationen aus SOA-Repositories (auch (Service) Registry

oder Directory genannt) [Er05, Jo07]. Als Grundlage hierfür haben wir im Projekt ENPROSO

ein sehr umfassendes Metamodell für ein SOA-Repository konzipiert [BTBR10, Bu12, Ti10].

Dieses muss detaillierte Information zu Service-Versionen und -Installationen ebenso

bereitstellen wie zu Service-Nutzungsvereinbarungen (Contracts). Mit diesen und weiteren

Informationen ist erkennbar, welche konkreten Service-Versionen und -Installationen

tatsächlich genutzt werden, bis wann dies erfolgt und welche verzichtbar sind bzw. in Zukunft

abgeschaltet werden können. Damit kann der Anpassungsaufwand für die konsumierende

Applikation abgeschätzt werden.

Hierdurch ergibt sich ein umfangreiches SOA-Repository mit vielen verschiedenen Objekttypen

und zudem jeweils vielen -Instanzen. Kritisch daran ist, dass zu erwartende Problemsituationen

für menschliche Benutzer aufgrund der Datenmenge kaum mehr direkt erkennbar sind. Des-

halb werden automatisierte Analysemöglichkeiten benötigt: Basierend auf den existierenden

SOA-Repository-Daten müssen insbesondere zukünftig auftretende Problemsituationen ent-

deckt werden. Da es zu solchen automatischen Analyseverfahren bisher keine SOA-Literatur

gibt, stellen wir in diesem Beitrag entsprechende Verfahren vor, um z.B. Services zu finden,

deren Abschaltung vorgesehen ist, bevor ihre Nutzungsvereinbarung ausläuft.

Als Erweiterung zur Erkennung von solchen – aufgrund der existierenden Daten bereits „vor-

programmierten“ – Problemsituationen (d.h. Ist-Analysen) sollte ein SOA-Repository auch

Planspiele (What-if-Analysen) ermöglichen: Um einen geeigneten Zeitpunkt für eine Service-

Abschaltung wählen zu können, müssen die jeweiligen Folgen analysierbar sein. Dazu müssen

mehrere Abschaltzeitpunkte betrachtet werden, wobei jeweils die betroffenen Service-Consu-

mer und Lösungsalternativen identifiziert werden (Impact-Analysen). Da die Bewertung mehre-

1 Enhanced Process Management by Service Orientation, durchgeführt bei und finanziert von der Daimler AG.

rer potentieller Abschaltzeitpunkte basierend auf den SOA-Repository-Daten einen großen

Aufwand verursachen würde, stellen wir in diesem Beitrag (ebenfalls originäre) Verfahren für

automatisierte Impact-Analysen vor.

Als Grundlage für die Analysen stellen wir in Abschnitt 2 unser SOA-Repository-Metamodell

auszugsweise vor. Abschnitt 3 beschreibt exemplarisch einige Analysen basierend auf aktuell

existierenden Repository-Daten (Ist-Analysen). Planspiele und die zugehörigen Impact-

Analysen werden in Abschnitt 4 betrachtet. Eine Diskussion des aktuellen Standes der

wissenschaftlichen Literatur sowie existierende Plattformen für SOA-Repositories findet sich in

Abschnitt 5. Der Beitrag schließt mit einer Zusammenfassung und einem Aufblick.

2 Grundlagen

Für die Ermittlung der Anforderungen an ein SOA-Repository wurden in mehreren Geschäfts-

bereichen der Daimler AG Anforderungsanalysen durchgeführt [BTBR10, Bu12]. Hierbei ergab

sich außer dem Bedarf an Analysen (siehe Abschnitte 3 und 4) auch die Notwendigkeit zur

Speicherung diverser Objekt- und Beziehungstypen in einem SOA-Repository. Das ent-

sprechende Metamodell zur Datenspeicherung ist in Abbildung 1 als Entity-/Relationship-

Modell dargestellt. Zur Beschreibung von Kardinalitäten wird die (min,max)-Notation verwendet

[Ab74].

Das Metamodell umfasst sowohl fachliche (linke Hälfte) wie auch technische Objekttypen und

ist auch bzgl. der konkreten Objekttypen sehr umfangreich2. So werden u.A. fachliche und

technische DataObjectVersions3 berücksichtigt, weil auch diese für den Anwender z.B. beim

Suchen bzw. Browsen nach verwendbaren Services hilfreich sein können. Ziel dieses Meta-

modells ist, sehr viele der häufig in einer SOA benötigten Informationen abzubilden, jedoch

können abhängig vom jeweiligen Unternehmen und seiner SOA-Philosophie zusätzliche Ob-

jekt- und Beziehungstypen erforderlich werden bzw. dann irrelevante entfallen. Im Folgenden

erläutern wir aus Platzgründen nur die für das Verständnis dieses Beitrags erforderlichen

Objekt- und Beziehungstypen. Für eine Erläuterung der anderen und auch für eine Diskussion

der jeweils relevanten Attribute wird auf [Bu12, Ti10] verwiesen.

Zentrales Objekt in einer SOA ist der Service und findet sich dementsprechend auch im

Metamodell. Allerdings ist ein Service nur eine „Bündelung“ von unterschiedlichen Service-

Versionen, da sich ein „konkreter Service“ im Laufe der Zeit weiterentwickelt. Die entstehenden

Service-Versionen können unterschiedliche Ein-/Ausgabeparameter oder sogar Operationen

haben, weshalb sie für den Consumer inkompatibel sind. Wir unterscheiden zudem in fachliche

(BusinessServiceVersion, verbunden mit Beziehungstyp isBusinessServiceVersion) und

technische Service-Versionen (TechnicalServiceVersion, verbunden mit isTechnicalService-

Version).

2 Die im SOA-Repository gespeicherten Daten müssen nicht manuell eingetragen werden. Sie können über

entsprechende Systemschnittstellen automatisch aus IT-Systemen versorgt werden, in denen die benötigten

Informationen ohnehin existieren. Dies können z.B. (Prozess-)Modellierungswerkzeuge, Software-Entwicklungs-

umgebungen oder Systeme zur Steuerung der Governance-Prozesse sein. Durch diese Vorgehensweise entsteht

durch das sehr umfassende SOA-Repository nur ein moderater Mehraufwand für die Benutzer.

3 Versionen von Datentypen, die in Service-Operationen als Ein- oder Ausgabeparameter verwendet werden.

Contract

Service

System

Business-

Service-

Version

Technical-

Service-

Version

Technical-

DataObject-

Version

Technical-

Operation

Service-

Install

System-

Process-

Version

Source-

Business-

Activity

System-

Activity

Transfor-

mation

Business-

Process-

Version

Technical-

Process-

Version

Business-

Activity

(0,*)

(0,*)(0,*) (0,*)(0,*)

(0,*)(0,1)

(1,*)

(1,1)

(0,*)

(1,1)

(0,*)

Business-

DataObject-

Version

Business-

Operation

(1,*)

(1,1)

(0,*)

(1,1)

(0,*)

(1,1)

(0,*)

(0,*)(1,*)

(0,*)

(1,1)

(0,*)

(1,1)

(1,*)

(1,1)

(0,*)

(0,1)

(0,*)

(0,1)

(0,*)

(1,*)

(1,1)

(1,*)

(1,1)

Target-

System-

Activity

(0,*)(1,1)(0,*) (1,1)

(1,n)

(1,1)

(1,1) (1,1)

(1,1)

(0,*)

(1,1)

hasSource-

BusinessActivity

hasTarget-

BusinessActivity

belongs

ToBIMM

isABusiness-

Activity

isATechnical-

Activity

isASystem-

Activity

belongsToBusiness-

ProcessVersion

belongsTo-

BusinessProcessVersion

hasSystem-

ProcessVersion

hasBIMM

belongsToTechnical-

ProcessVersion

belongsTo-

TechnicalProcessVersion

technicalProcVersion-

BelongsToSystem

systemProcVersion-

BelongsToSystem

businessProcVersion-

BelongsToSystem

has

Provider

hasContract

isBusiness-

ServiceVersion

isTechnical

ServiceVersion

hasTechn-

ServiceVers-

Consumer

hasBusin-

ServiceVers-

Consumer

has-

Installation

hasTechnical-

ServiceVersion

hasInOutTechnical-

DataObjectVersion

hasTechnicalData-

ObjectVersionRealization

hasBusiness-

ServiceVersion

hasInOutBusiness-

DataObjectVersion

hasTechnService-

VersImplementation

offeredAs-

Business-

Service-

Version

uses-

Business-

Service-

Version

offeredAs-

Technical-

Service-

Version

uses-

Technical-

Service-

Version

Technical-

Activity

Business-IT-

Mapping-

Model (BIMM)

provides-

Service-

Install

(1,1)

(0,*)

Abbildung1:MetamodelldesSOA‐RepositoryalsEntity‐Relationship‐Diagramm

Fachlich wird ein Service so beschrieben, dass Anwender aus Fachabteilungen und Manager

den Zweck und groben Inhalt des Service verstehen und bewerten können. Erst nachdem eine

Realisierung der fachlichen Service-Version beschlossen wurde, entsteht eine technische

Service-Version inkl. einer detaillierten Spezifikation u.a. der Schnittstelle (WSDL [Jo07,

We07]). Eine fachliche Service-Version kann auf unterschiedliche Arten umgesetzt werden –

auch mehrfach – wobei sich die zugehörigen technischen Service-Versionen z.B. in den

Datentypen der Parameter oder der Anzahl der Operationen unterscheiden können.4 Da

technische Service-Versionen inhaltlich dieselbe Aufgabe erledigen, sich aber in technischen

Details unterscheiden, werden mehrere von ihnen mittels hasTechnServiceVersImplementation

derselben fachlichen Service-Version zugeordnet.

Nach Implementierung und Rollout (Deployment) einer technischen Service-Version entsteht

eine Service-Installation (ServiceInstall), die ihr zugeordnet wird. Da die Service-Installation

von einem konkreten IT-System bereitgestellt wird, ist sie zudem mit der Beziehung

providesServiceInstall genau diesem System zugeordnet. Die Beziehung hasProvider

beschreibt etwas „ungenauer“, dass das IT-System diesen Service bereitstellt, wobei ein

Service i.Allg. von unterschiedlichen IT-Systemen angeboten werden und mehrere

Installationen besitzen kann, die evtl. zu verschiedenen Service-Versionen gehören.

Soll ein Service tatsächlich verwendet werden, so muss zwischen dem Anbieter und dem

Consumer ein Nutzungsvertrag (Contract) geschlossen werden. Die Zuordnung des Contract

zu dem Consumer erfolgt mittels der Beziehung hasContract. Die Information zu diesem

Contract entsteht typischerweise sukzessive, so dass zuerst nur festgelegt wird, welche

fachliche Service-Version genutzt werden soll (Zuordnung mittels hasBusinServiceVers-

Consumer). Zu diesem Zeitpunkt muss noch gar keine technische Service-Version hierzu

existieren. Wird dann auch eine solche ausgewählt, so wird der Contract ergänzt (evtl. auch um

technische Service-Level-Agreements [Er05, Jo07]) und die Zuordnung zum Contract erfolgt

mittels hasTechnServiceVersConsumer.

Die soeben vorgestellten Entitäts- und Beziehungstypen werden wir im Folgenden verwenden,

wofür noch die Notation erläutert werden soll: e  E ist erfüllt gdw. im SOA-Repository die

Entität e in der Entitätsmenge E vorhanden ist. Für den Beziehungstyp b zwischen Entitätstyp

E und E' mit e  E und e'  E' liefert die Funktion b(e, e') wahr g.d.w. eine entsprechende Be-

ziehung zwischen e und e' im SOA-Repository existiert.

3 Analyse bereits existierender SOA-Repository-Daten

(Ist-Analysen)

Ist-Analysen basieren auf bereits im SOA-Repository vorhandenen Daten. Da Contracts jedoch

auch in der Zukunft liegende Termine für Beginn und Ende einer Service-Nutzung beinhalten,

können dadurch nicht nur bereits bestehende, sondern auch noch zu erwartende Problem-

situationen identifiziert werden. Deshalb ermöglichen bereits Ist-Analysen die rechtzeitige

Reaktion auf zu erwartende Problemsituationen. In diesem Abschnitt werden exemplarisch

einige Ist-Analysen vorgestellt, für weitere sei auf [Bu12, Ti10] verwiesen.

4 So kann z.B. zur Abfrage von Attributwerten eine einzige generische Operation verwendet werden, die den

Attributnamen als Eingabeparameter erhält, oder eine Operation je Attribut definiert werden. Da – fachlich betrachtet

– bei beiden Ansätzen dieselben Daten abgefragt werden, handelt es sich um dieselbe fachliche Service-Version

(die je nach Bedarf der Consumer unterschiedlich umgesetzt wurde).

3.1 Technische Service-Version ohne Installation bzw. fachliche

Service-Version

Ein sehr einfaches Analyseszenario ist die Identifikation von technischen Service-Versionen,

für die keine Service-Installation existiert. Dieser Fall ist interessant, da eine solche technische

Service-Version aktuell nicht nutzbar ist. Deshalb muss im Rahmen der SOA-Governance

entschieden werden, ob eine entsprechende Service-Implementierung und -Installation durch-

geführt werden soll oder die Service-Version nicht benötigt wird, also gelöscht werden kann.

Wie alle Analysen basiert die Ermittlung solcher technischer Service-Versionen TSV auf den

Daten aus dem SOA-Repository:

TSV = {tsv  TechnicalServiceVersion |  siServiceInstall mit hasInstallation(tsv, si)}

Enthalten gekaufte IT-Systeme technische Services (Schnittstellen) oder wurde bei einer

möglichst schnellen Migration hin zu einer SOA unsauber vorgegangen, so können auch

technische Service-Versionen entstehen, denen keine fachliche Service-Version zugeordnet

ist. Auf solche Situationen sollte reagiert werden, indem die Spezifikation der fachlichen

Service-Version nachgeholt wird. Evtl. muss auch nur ein fachlicher Service zugeordnet

werden, z.B. falls diese Eintragung im SOA-Repository vergessen wurde. In beiden Fällen führt

die Ergänzung dazu, dass der technische Service leichter aufgefunden und seine Funktions-

weise besser verstanden werden kann. Hierdurch erhöht sich seine Wiederverwendbarkeit.

Entsprechende technische Service-Versionen TSV werden durch folgendes Kriterium ermittelt:

TSV = {tsv  TechnicalServiceVersion |  bsv  BusinessServiceVersion mit

hasTechnServiceVersImplementation(bsv, tsv)}

3.2 Nicht nutzbare Service-Versionen

Mit ähnlichen Regeln ist basierend auf den SOA-Repository-Daten ebenfalls einfach

analysierbar, welche fachlichen und technischen Services aktuell nicht nutzbar sind. So kann

zu jedem Service ausgelesen werden, welche BusinessServiceVersion existieren (mittels

Beziehung isBusinessServiceVersion in Abbildung 1). In dem in Abbildung 2 dargestellten

Beispiel ergeben sich für ServiceX die fachlichen Service-Versionen BSV1, BSV2 und BSV3.

Falls einem dieser keine technische Service-Version zugeordnet ist, so ist dieser nicht nutzbar

(BSV3 bzw. das unten dargestellte Szenario 3c). Für BSV1 existieren die technischen Service-

Versionen TSV1a und TSV1b, für BSV2 existieren TSV2a und TSV2b. Ebenso ist erkennbar,

dass z.B. TSV1b keine Service-Installation zugeordnet ist, so dass diese technische Service-

Version nicht direkt nutzbar ist (siehe Szenarios 3a und 3b).

BusinessServiceVersion

TSV2b

ServiceX SI1a

Contract

isBusiness‐

ServiceVersion

TechnicalServiceVersion ServiceInstallService

hasTechnService‐

VersImplementation

hasInstallation

Con1

hasBusinService‐

VersConsumer

hasTechnService‐

VersConsumer

Con3

Con2

BSV1 TSV1a

BSV2 TSV2a

BSV3

TSV1b

Abbildung2:BeispieldatenausdemSOA‐RepositoryzuContracts,Services,etc.

Wir betrachten nun, wann eine nicht nutzbare fachliche bzw. technische Service-Version zu

Problemen führt und welche Maßnahmen zu deren Lösung ggf. ergriffen werden können. Die

Analyse kann hierbei automatisch erfolgen; das Festlegen von Maßnahmen bleibt

selbstverständlich eine intellektuelle Leistung, die z.B. von einem Governance-Gremium

übernommen wird. Wir unterscheiden folgende Szenarien:

Szenario 1 (Kein Contract für eine nicht nutzbare fachliche Service-Version): In Abbildung

2 ist BSV2 nicht nutzbar, weil ihm keine Service-Installation zugeordnet ist. Angenommen, für

BSV2 gibt es keinen relevanten Contract (z.B. weil das in Contract2 vereinbartes

Nutzungsende in der Vergangenheit liegt), dann besteht kein Problem für die Stabilität der

Service-Consumer. Allerdings ist BSV2 nicht nutzbar, so dass die aktuelle Situation verändert

werden sollte: Einerseits kann beschlossen werden, dass für TSV2a oder TSV2b eine Service-

Installation entwickelt wird. Andererseits kann BSV2 auch für unnötig befunden werden und

deshalb sein „Sun-down“ beschlossen werden (inkl. TSV2a und TSV2b). Dies ist z.B. der Fall,

wenn sich BSV2 als ungeeignet erwiesen hat, weshalb die zu TSV2a/b gehörenden Service-

Installationen bereits abgeschaltet und aus dem SOA-Repository entfernt wurden.

Szenario 2 (Kein Contract für nicht nutzbare technische Service-Version): Gibt es für eine

nicht nutzbare technische Service-Version (z.B. TSV1b in Abbildung 2) keinen gültigen

Contract, dann besteht wieder kein unmittelbares Problem. Das Governance-Gremium kann

entscheiden, ob für TSV1b eine Service-Installation erstellt werden soll (bzw. bereits in

Entwicklung ist) oder ob diese technische Service-Version verzichtbar ist, weil sie gegenüber

der alternativ verwendbaren TSV1a kaum oder keine Vorteile hat.

Szenario 3 (Contract für nicht nutzbare fachliche bzw. technische Service-Version):

Interessanter ist der Fall, wenn die in Abbildung 2 dargestellten Contracts noch nicht

abgelaufene Nutzungszeiten beinhalten. Dann existieren relevante Contracts für nicht nutzbare

Service-Version. Dieses Szenario unterscheiden weiter nach dem Kriterium, ob alternativ

nutzbare Service-Versionen existieren:

Szenario 3a (Technische Service-Version mit nutzbarer alternativer technischer Service-

Version): In Abbildung 2 existiert der Contract Con1 für TSV1b, so dass es für TSV1b auch

tatsächlich einen Consumer gibt bzw. geben wird. Dies ist problematisch, da TSV1b über keine

Service-Installation verfügt. Allerdings gibt es eine weitere technische Service-Version TSV1a,

die derselben fachlichen Service-Version zugeordnet ist und zudem nutzbar ist (wg. SI1a).

Solche technischen Service-Versionen TSV können mittels der Repository-Daten durch die

folgenden Kriterien automatisch erkannt werden:

TSV = {tsv  TechnicalServiceVersion |

 con  Contract mit hasTechnServiceVersConsumer(con, tsv) 

 si  ServiceInstall mit hasInstallation(tsv, si) 

 bsv  BusinessServiceVersion mit hasTechnServiceVersImplementation(bsv, tsv) 

 tsv'  TechnicalServiceVersion mit hasTechnServiceVersImplementation(bsv, tsv') 

 si'  ServiceInstall mit hasInstallation(tsv', si')

Als Lösung kann in diesem Szenario von der nicht nutzbaren technischen Service-Version

TSV1b zur nutzbaren TSV1a gewechselt werden. Dies ist sinnvoll, wenn TSV1b gegenüber

TSV1a kaum Vorteile hat, erfordert aber eine Anpassung von Con1 und der zugehörigen

Consumer-Applikation (falls diese bereits realisiert wurde). Alternativ kann auch die

Entwicklung einer Service-Installation für TSV1b beschlossen oder auf den Abschluss einer

ohnehin stattfindenden Entwicklung gewartet werden. Unterscheiden sich TSV1a und TSV1b

nur geringfügig (z.B. andere, aber ähnliche Datenstrukturen für Ein-/Ausgabeparameter), so

kann eine Service-Installation für TSV1b auch dadurch realisiert werden, dass SI1a mittels

eines Proxy (ESB) gerufen wird, der die Unterschiede zwischen Consumer und Service durch

geeignete Transformationen (der Datenstrukturen) ausgleicht. Eine solche Lösung nutzt die

durch eine SOA ermöglichte Flexibilität [BBR11].

Szenario 3b (Technische Service-Version ohne nutzbare alternative technische Service-

Version) In Abbildung 2 referenziert Con2 die nicht nutzbare technische Service-Version

TSV2a. Die einzige ebenfalls zu BSV2 gehörende technische Service-Version TSV2b ist als

Alternative nicht nutzbar, da sie über keine Service-Installation verfügt. Solche technischen

Service-Versionen TSV sind Szenario ist wie folgt erkennbar:5

TSV = {tsv  TechnicalServiceVersion |

 con  Contract mit hasTechnServiceVersConsumer(con, tsv) 

 si  ServiceInstall mit hasInstallation(tsv, si) 

 bsv  BusinessServiceVersion mit hasTechnServiceVersImplementation(bsv, tsv) 

 tsv'  TechnicalServiceVersion mit ( hasTechnServiceVersImplementation(bsv, tsv')

  si'  ServiceInstall mit hasInstallation(tsv', si') )

Selbstverständlich kann auch in diesem Szenario eine geeignete Service-Installation für TSV2a

realisiert werden. Soll dies vermieden werden, so sind die Lösungsmöglichkeiten

eingeschränkt: Da keine zur selben fachlichen Service-Version gehörende und zudem nutzbare

alternative technische Service-Version existiert, bleibt nur der Wechsel zu einer anderen

fachlichen Service-Version. Da diese nutzbar sein soll, muss dies in dem in Abbildung 2

dargestellten Beispiel BSV1 sein. Zu BSV1 kann gewechselt werden, indem Con2 und ggf. die

Consumer-Applikation entsprechend angepasst werden. Die Veränderungen für letztere sind

typischerweise deutlich umfangreicher als bei Szenario 3a, weil sich fachliche Service-

Versionen i.d.R. sehr viel stärker unterscheiden als technische.

5 Diese Regeln schließen bereits den Fall mit ein, dass es überhaupt keine ebenfalls zur selben fachlichen Service-

Version BSV2 gehörende technische Service-Version tsv' gibt, weil dann tsv=tsv' gelten muss, weswegen es kein si'

mit existierender Service-Installation geben kann.

Szenario 3c (Fachliche Service-Version ohne technische Service-Versionen): Für den

Contract Con3 existiert lediglich eine fachliche Service-Version, aber keine korrespondierende

technische Service-Version. Dies kann auftreten, wenn die zu realisierende technische

Service-Version noch nicht endgültig beschlossen oder spezifiziert wurde. Prinzipiell muss

dann auf eine entsprechende technische Service-Version gewartet werden, worauf hin der

Contract vervollständigt werden kann. Alternativ kann wie in Szenario 3b zu einer anderen

(bereits nutzbaren) fachlichen Service-Version gewechselt werden. Auf die formalen Kriterien

zur Erkennung dieses Szenarios verzichten wir aus Platzgründen.

4 Planspiele mit zukünftig möglichen Daten

(Impact-Analysen)

Die bisher vorgestellten Analysen betrachten ausschließlich die gegenwärtig im SOA-

Repository dargestellte Situation. Die im Folgenden exemplarisch (weitere in [Bu12, Ti10]) be-

schriebenen Impact-Analysen betrachten darüber hinaus Auswirkungen möglicher Änderungen

in der Zukunft. Mittels solcher Analysen können mehrere Szenarien verglichen werden, was

dann die Grundlage für Entscheidungen bildet. So kann z.B. analysiert werden, welche

Service-Consumer von einer Service-Abschaltung zu einem bestimmten Zeitpunkt betroffen

wären, und damit, welcher Abschaltzeitpunkt am günstigsten ist.

4.1 Indirekte Abhängigkeiten (Ripple-Effect)

Die hohe Wichtigkeit von Impact-Analysen ergibt sich aus der Tatsache, dass von z.B. der

Abschaltung einer Service-Installation nicht nur deren unmittelbare Consumer betroffen sind:

Diese Consumer sind IT-Systeme (System in Abbildung 1), die selbst Services bereitstellen

können. Muss ein solches IT-System verändert werden, weil etwa auf einen alternativen (zu

konsumierenden) Service ausgewichen werden muss, so können sich auch Veränderungen an

bereitgestellten Services ergeben. Gibt es keinen alternativen Service, dann können Services

evtl. überhaupt nicht mehr bereitgestellt werden. In beiden Fällen sind deren Consumer davon

betroffen, so dass sich die Änderung über mehrere Stufen zu indirekt abhängigen IT-Systemen

„fortpflanzen“ kann (Ripple-Effect ).

Solche indirekten Abhängigkeiten lassen sich mit den in Abschnitt 2 beschrieben Repository-

Daten automatisch erkennen. In dem in Abbildung 3 dargestellten Beispiel soll die Service-

Installation SI1 in naher Zukunft abgeschaltet werden. Sie sei die einzige Realisierung der

technischen Service-Version TSV1, wodurch aufgrund der Contracts Con1a, Con1b und Con1c

die IT-Systeme Sys1a, Sys1b und Sys1c nicht mehr funktionsfähig sind und deshalb rechtzeitig

angepasst werden müssen. Verändern sich dadurch z.B. die von Sys1b angebotenen Services

Serv2 und Serv3 bzw. deren technische Service-Version TSV2 und TSV3, so pflanzt sich die

Änderung fort: Die hiervon abhängigen Contracts Con2, Con3a und Con3b müssen ebenso

angepasst werden, wie die Service-konsumierenden IT-Systeme, die natürlich selbst wieder

Services anbieten können, etc.

Abbildung3:BeispieldatenausdemSOA‐RepositorymitRipple‐Effect

Die von einer abzuschaltenden oder zu verändernden Service-Installation si direkt betroffenen

IT-Systeme lassen sich mittels folgendem Kriterium automatisch ermitteln:6

AffectedSys(si) = {sys  System |  tsv  TechnicalServiceVersion mit

hasInstallation (tsv, si) für die gilt:  con  Contract mit

hasTechnServiceVersConsumer(con, tsv) und hasContract (sys, con) }

Indirekt betroffene Systeme lassen sich dann ermitteln, indem man mit der Beziehung

providesServiceInstall alle von einem System sys  AffectedSys(si) bereitgestellten Service-

Installationen AffectedSericeInstall ermittelt und dann für jedes si'  AffectedSericeInstall eine

entsprechende Menge AffectedSys(si') der nächsten Stufe berechnet, etc.

Wenn man lediglich die Beziehungen zwischen IT-Systemen (System) und Ausprägungen von

Services (Service-Install, etc.) betrachtet, dann können ungünstigerweise auch Abhängigkeiten

berechnet werden, die in Wirklichkeit überhaupt nicht existieren. Dass die Programmierung

eines IT-Systems (irgendwo) einen bestimmten Service aufruft, bedeutet noch nicht, dass

dieser für die Bereitstellung jedes angebotenen Services notwendig ist. So sind in dem

erläuterten Beispiel das System Sys1b und damit die bereitgestellten Service Serv2 und Serv3

von der abzuschaltenden Service-Installation SI1 abhängig. Fall 1: Angenommen, die

Implementierung des konkreten Services TSV2/Serv2 basiert auf TSV1 und SI1. Falls dann die

Anpassung der Implementierung von Sys1b zu einer Veränderung der angebotenen Service-

Schnittstelle führt, so hat dies Auswirkungen auf den Contract Con2 und die konsumierende

Applikation. Fall 2: Angenommen, die Implementierung von TSV3/Serv3 verwendet keinerlei

fremde Services oder zumindest nicht den abzuschaltenden SI1. Dann kann die technische

Service-Version TSV3 unverändert bleiben, so dass es keinerlei Auswirkungen auf die

Contracts Con3a und Con3b gibt. Da die konsumierenden IT-Systeme also nicht betroffen sind,

pflanzt sich die Veränderung auf diesem Weg nicht weiter fort. Die in heutigen SOA-

Repositories gespeicherten Informationen sind jedoch nicht detailliert genug, um diese beiden

Fälle unterscheiden zu können. Deshalb würde eine Analyse stets irrtümlich zu viele

Problemsituationen erkennen.

Das diesem Beitrag zugrunde gelegte SOA-Repository (vgl. Abbildung 1) ermöglicht es, die

beiden Fälle zu unterscheiden: Durch die Beziehung usesTechnicalServiceVersion ist es

möglich, exakt diejenigen Prozessschritte (TechnicalActivity) eines Geschäftsprozesses zu

bestimmen, die wegen eines entsprechenden Serviceaufrufs von einer abzuschaltenden

technischen Service-Version abhängig sind. Mittels belongsToTechnicalProcessVersion lässt

6 Hierbei wird vereinfachend der (in der Praxis sehr häufige) Fall angenommen, dass es für eine technische Service-

Version nur eine einzige Service-Installation gibt. Selbstverständlich kann mit den vorhandenen SOA-Repository-

Daten (Beziehung hasInstallation) auch überprüft werden, ob dies tatsächlich zutrifft, oder ob auf eine andere

Service-Installation ausgewichen werden kann – der Ripple-Effect also hier endet.

hasInstallation

Contract

Sys1b

SI1

Service TechnicalServiceVersion ServiceInstallSystem

has‐

Techn‐

ServiceVers‐

Consumer

Con1a TSV1

Con1b

Con1c

Technical‐

Service‐

Version

Sys1c

Sys1a

has‐

Contract

Serv3

Serv2

TSV3

TSV2

has‐

Provider

isTechnical‐

ServiceVersion

Contract

Con3a

Con3b

Con2

hasTechn‐

ServiceVersConsumer

…

sich die zugehörige TechnicalProcessVersion (der ausführbare Geschäftsprozess / Workflow)

ermitteln. Wird dieser wiederum als Service angeboten, so liefert die Beziehung offeredAs-

TechnicalServiceVersion die zugehörige TechnicalServiceVersion. Hat schließlich ein IT-

System hierzu einen Contract, so ist es tatsächlich von der Änderung betroffen, es liegt also

Fall 1 vor. Wir erhalten also das korrekte Analyseergebnis.7 Dadurch sind sehr viel bessere

Planungen und Entscheidungen möglich, als wenn nur Informationen über die insgesamt von

einem IT-System konsumierten und bereitgestellten Services im SOA-Repository existieren.

Die für das SOA-Repository benötigten Informationen entstehen bei Verwendung des

ENPROSO-Konzepts ohnehin durch die zugrundeliegende durchgängige Modellierung vom

fachlichen Geschäftsprozess, über technische Workflows, bis hin zu Services der SOA-

Applikationen [BBR12, Bu12]. Da diese Informationen automatisch ins SOA-Repository über-

tragen werden können, entsteht kaum Mehraufwand für die Datenerfassung. Wird nicht von

prozess-orientierten SOA-Applikationen ausgegangen, ist der Ansatz generell auch z.B. auf

UML-basierte Modellierung von Services, Service-Implementierungen und deren Consumer

übertragbar.

4.2 Analysen möglicher Szenarien für zukünftige Zeitpunkte

(Planspiele)

Wie stark die Auswirkungen einer in der Zukunft durchzuführenden Änderung sind, hängt vom

genauen Zeitpunkt ihrer Umsetzung ab. Dementsprechend soll der Zeitverlauf in die Analysen

einbezogen werden. Indem Analysen für mehrere Zeitpunkte durchgeführt werden, können

unterschiedliche Szenarien durchgespielt und analysiert werden. Solche Planspiele möchten

wir nun exemplarisch vorstellen.

Angenommen, es soll die aktuell einzige Service-Installation SI0 der technischen Service-

Version TSV0 aus Kostengründen abgeschaltet werden. Der Betreiber von SI0 strebt eine

Abschaltung in ca. 6 Monaten an. Es ist nun zu analysieren, ob dieser Termin aus Sicht des

Gesamtunternehmens günstig ist. Als ersten Schritt bietet es sich an, eine graphische

Übersicht der Service-Nutzungsverträge (Contracts) im Verlauf der Zeit zu erstellen (vgl.

Abbildung 4). Eine solche Darstellung kann aus den Daten des SOA-Repositories automatisch

generiert werden. Im Diagramm ist sehr einfach erkennbar, dass aktuell 4 Contracts für TSV0

existieren und dementsprechend 4 IT-Systeme von SI0 abhängig sind. Nach ca. 6, 10, 17 und

24 Monaten laufen Contracts aus. Diese Termine bieten sich als Abschaltzeitpunkte für TSV0

an, da dann jeweils weniger IT-Systeme betroffen sind.

Abbildung 4: Graphische Darstellung der Contracts für TSV0 im Zeitverlauf

7 Sind (noch) keine technischen Artefakte im SOA-Repository erfasst, so kann eine analoge Analyse auch auf Basis

von BusinessServiceVersion, BusinessActivity und BusinessProcessVersion (siehe linke Hälfte von Abbildung 1)

durchgeführt werden.

Con1

SystemContract

Sys1

Con2

Sys2

Con3

Sys3

Con4

Sys4

Zeit

heute 6Monate 10Monate 17Monate 24Monate

Die eben betrachtete Analyse berücksichtigt jedoch noch keine indirekten Abhängigkeiten

(Ripple-Effect), so dass die Menge der von der Abschaltung betroffenen IT-Systeme noch

unvollständig ist. Der in Abbildung 5a dargestellt Impact-Graph stellt auch solche Abhängig-

keiten dar, indem er jede Indirektionsstufe als separate Schale visualisiert. Hierbei werden die

zu einem bestimmten Zeitpunkt gültigen Contracts berücksichtigt, bei Abbildung 5a die in 6

Monaten noch gültigen Contracts. Auch dieses Diagramm lässt sich automatisch aus den

Daten des SOA-Repositories generieren, wobei die in Abbildung 5b dargestellten Abhängig-

keiten angenommen werden: Außer den wegen Con1, Con2, Con4 abhängigen Systemen

Sys1, Sys2, Sys4 gibt es noch eine indirekte Abhängigkeit zu Sys5. Das IT-System Sys4 bietet

nämlich die Service-Installation SI4 an. Diese implementiert als einzige die technische Service-

Version TSV4, die über Con5 an Sys5 gebunden ist. Eine Abschaltung von SI0 in 6 Monaten

würde also die 4 genannten IT-Systeme beeinträchtigen. Mit dieser Information kann auf die

Systemeigner zugegangen werden, so dass diese frühzeitig die Folgen der Service-Abschal-

tung abschätzen und ggf. ihre Systeme geeignet anpassen können.

Abbildung5:a)Impact‐Graphundb)AbhängigkeitenvonSI0in6Monaten



Erweist sich der Anpassungsaufwand für diese 4 Systeme im Vergleich zu den Betriebskosten

von SI0 als zu hoch, so sollte ein längerer Betrieb von SI0 in Erwägung gezogen werden. Als

nächster Abschaltzeitpunkt bietet sich heute in 10 Monaten an, weil dann Con4 ausläuft und

Sys4 nicht mehr betroffen ist (vgl. Abbildung 4). Dann kann auch das IT-System Sys5 nicht

mehr (indirekt) betroffen sein, weil dessen Abhängigkeit ausschließlich über Sys4 bestand.

Damit ergibt sich aus den in Abbildung 6 darstellten Beziehungen ein Impact-Graph mit

deutlich weniger abhängigen Systemen.

Abbildung6:a)Impact‐Graphundb)AbhängigkeitenvonSI0in10Monaten

a) Contract

Sys2SI0

Service‐

Install

Technical‐

Service‐

Version

Service‐

Install

System

hasTechn‐

ServiceVers‐

Consumer

has

Installation

Con1

TSV0 Con2

Con4

Technical‐

Service‐

Version

Sys4

Sys1

hasContract

SI4 TSV4

provides‐

ServiceInstall

Contract

Con5

hasTechn‐

ServiceVers‐‐

Consumer

Sys5

has‐

Contract

hasInstallation

System

SI0

Sys2 Sys1

Sys4

Sys5 b)



a) b)

SI0

Sys2 Sys1

Contract

Sys2SI0

Service

Technical‐

Service‐

Version

Service‐

Install

System

hasTechnService‐

VersConsumer

Con1

TSV0 Con2 Business‐

Service‐

Version

Sys1

hasContract

hasInstallation



SI0' TSV0'

Serv0

isTechnical‐

ServiceVersion

hasTechnService‐

VersImplementation

BSV0

In Abbildung 6b ist zudem erkennbar, dass es in 10 Monaten eine Service-Installation SI0' zur

technischen Service-Version TSV0' geben wird. Diese gehört zur selben fachlichen Service-

Version BSV0 wie TSV0, so dass wohl eine große Ähnlichkeit zwischen den beiden

technischen Service-Versionen besteht. Deshalb eröffnet sich die Alternative, die verbleiben-

den Contracts Con1 und Con2 auf TSV0' und SI0' umzustellen. Die technische Realisierung

dieser Änderung erfordert wegen der erwähnten großen Ähnlichkeit relativ wenig Aufwand. Sie

ist evtl. sogar ohne Änderung der eigentlichen IT-Systeme durch eine Anpassung des Proxies

(ESB) umsetzbar (vgl. [BBR11, Bu12]).

Vermutlich ist mit der Frist von 10 Monaten bereits das Optimum gefunden worden. Um dies zu

verifizieren, sollten die weiteren als sinnvoll erscheinenden Zeitpunkte für die Abschaltung (17

Monate und 24 Monate, vgl. Abbildung 4) auf dieselbe Art und Weise analysiert werden. Durch

die skizzierten Planspiele wird es möglich, abzuwägen, ob eine Service-Abschaltung eher früh

umgesetzt werden soll (geringere Betriebskosten), oder ob es aus betriebswirtschaftlicher Sicht

Sinn macht, länger zu warten (geringere Migrationskosten). Diese Entscheidung ist dann von

dem zuständigen SOA-Governance-Gremium zu treffen, das durch automatisch aus dem SOA-

Repository abgeleitete Informationen unterstützt wird. Weitere Planspiele werden in [Ti10]

erläutert.

5 Diskussion

In der wissenschaftlichen SOA-Literatur wird die Gestaltung eines umfassenden Metamodells

für ein SOA-Repository bisher nicht explizit adressiert (mit Ausnahme unserer Arbeiten

[BTBR10, Bu12, Ti10].). Auch zu den Themenkomplexen der Ist-Analysen und Planspiele auf

Basis der SOA-Repository-Daten findet sich keine Literatur.

Allerdings ist die generelle Problemstellung erkannt: [XQZ07] betrachtet Änderungen von

Geschäftsprozessen in einer SOA, wobei ebenfalls die „Fortpflanzung“ einer Änderung (vgl.

Ripple-Effect) betrachtet wird. Ausgangspunkt ist dabei stets eine Änderung im

Geschäftsprozess. Für diese werden notwendige Änderungen abhängiger Geschäftsprozess-

Elemente ermittelt. Hierzu wird eine Klassifikation mit Typen von Prozessänderungen (z.B.

zusätzlicher Task) und den jeweiligen Auswirkungen erstellt. Es werden auch Aufruf-Kaskaden

von Services betrachtet und damit indirekt von einer Änderung betroffene Services. Die Arbeit

behandelt aber nicht die Berechnung solcher abhängiger Objekte (z.B. im SOA-Repository),

sondern die Schätzung der Kosten notwendiger Anpassungen vom Programm-Quellcode.

In [WYZ10] wird zusätzlich zu einer Klassifikation von Prozessänderungen eine Klassifikation

von Serviceänderungen vorgestellt. Auch hier wird der Ripple-Effect berücksichtigt: Ausgehend

von einem bestimmten Typ von Prozessänderung wird für die bereitgestellten Services

ermittelt, welche Art von Serviceänderungen sich hierdurch ergeben. Diese erfordern wiederum

Änderungen an den diese Services konsumierenden Geschäftsprozessen, etc. Der Fokus von

[WYZ10] liegt also ebenfalls sehr stark auf Geschäftsprozessen in einer SOA und der

jeweiligen Prozessstruktur. Daten eines SOA-Repositories werden nicht verwendet.

Zur Realisierung von SOA-Repositories gibt es mehrere Standards und Produkte, wovon wir im

Folgenden einige ausgewählte diskutieren möchten. Dabei betrachten wir außer deren

Funktionalität auch, inwieweit sie als Basis für das vorgestellte Metamodell und die

beschriebenen Analysen dienen können.

UDDI [OA02] ist ein von der OASIS standardisierter Verzeichnisdienst, der insb. zum Auffinden

von Service-Endpunkten dient. Das zugrunde liegende Metamodell ist sehr eingeschränkt und

sieht auch keine Erweiterungen vor, da keine neuen Objekt- und Beziehungstypen definiert

werden können. Außer einigen vordefinierten Abfragen sind keine Analysen vorgesehen.

ebXML definiert Standards zum Austausch von Geschäftsdaten und verfügt auch über den Teil

ebRIM (Registry Information Model) [OA05]. Das entsprechende Metamodell dient ausschließ-

lich zur Verwaltung der technischen Sicht. Fachliche Objekttypen und Contracts werden

ebenso wenig adressiert wie Analysen.

Das Produkt IBM WSRR ermöglicht mit seinem „Basic Governance Profile“ [Sa07] die

Speicherung von technischen und fachlichen Objekten, wobei die fachliche Sicht gegenüber

unserem Metamodell stark eingeschränkt ist: Für fachliche Services ist zwar eine Beschreibung

vorgesehen, jedoch nicht die Spezifikation von Operationen oder deren Parameter. Allerdings

ist WSRR bzgl. der Objekttypen und Beziehungen erweiterbar, so dass es als Basis zur

Umsetzung des vorgestellten Metamodells verwendbar wäre. Es sind zwar nur rudimentäre

Analysen vorhanden (Visualisierung von Abhängigkeiten), jedoch sind auch diese um

benutzerdefinierte Analysen erweiterbar.

Ähnliches gilt für CentraSite Active SOA [Ro06] der Software AG, sowohl was die Objekttypen,

die Erweiterbarkeit als auch was die Analysen betrifft. Letztere bestehen aktuell lediglich darin,

dass Repository-Objekte und deren Beziehungen interaktiv visualisiert werden können.

Sowohl Oracle Enterprise Repository [Or08] wie auch HP SOA Systinet [He10] basieren auf

UDDI. Beide ermöglichen aber eine gegenüber dem UDDI-Standard erweiterte Speicherung

von Objekttypen, so dass auch fachliche Objekte und Contracts verwaltet werden können.

Zudem sind auch die Visualisierung von Abhängigkeitsdiagrammen bzw. entsprechende

Analysen vorgesehen, wobei deren Mächtigkeit jedoch weit hinter den in diesem Beitrag

vorgestellten zurückbleibt.

Auch das ARIS-Repository [ID08] ermöglicht die Speicherung von SOA-Artefakten. Da es sich

hierbei jedoch um die Datenbank eines Geschäftsprozess-Modellierungs-Werkzeugs handelt,

unterscheidet es sich deutlich von den bisher vorgestellten Produkten: So kann es z.B. nicht

während des Service-Aufrufs (Run-time) zur Auflösung von Service-Endpunkten eingesetzt

werden. Allerdings ermöglicht es die Speicherung von sehr vielen (insb. fachlichen) Objekt-

und Beziehungstypen der ARIS-Diagramme. ARIS unterstützt (eingeschränkt mächtige)

Analysen, die auch durch selbst realisierte Analysearten erweiterbar sind (vgl. [Bu12]).

Zusammenfassend lässt sich festhalten, dass bisher kein Standard oder Produkt ein ähnlich

mächtiges Metamodell vorsieht, wie das hier vorgestellte. Das liegt vor allem daran, dass der

Fokus jeweils sehr stark nur auf der fachlichen oder nur auf der technischen Seite liegt. Bzgl.

der Ist-Analysen wird von den Produkten nur ein sehr eingeschränkter Funktionsumfang

angeboten, die Möglichkeit für Planspiele findet sich in keinem der Produkte. Da die Produkte

bzgl. des zugrunde liegenden Metamodells wie auch durch die Implementierung zusätzlicher

Analysealgorithmen erweiterbar sind, eigenen sie sich jedoch als Basis zur Umsetzung der

vorgestellten Konzepte.

6 Zusammenfassung und Ausblick

Wir haben ein umfassendes Metamodell für ein SOA-Repository vorgestellt, das als Basis für

Analyse dient. So kann mit Ist-Analysen geprüft werden, ob aufgrund der gespeicherten Daten

mit Problemen (z.B. wegfallende Service-Installation) zu rechnen ist. Mit Impact-Analysen kann

simuliert werden, welche Auswirkungen zukünftige Änderungen haben werden, wobei auch die

Fortpflanzung von Problemen (Ripple-Effect) berücksichtigt wird. All dies geht deutlich über die

bisher in der SOA-Literatur erwähnte bzw. in Standards und Produkten vorgesehene

Funktionalität hinaus. Allerdings ermöglicht die Erweiterbarkeit vieler Produkte die Umsetzung

der vorgestellten Konzepte. So wurden insbesondere die Analyseverfahren mittels eines

technischen Prototyps getestet [Ti10]. Eine Erprobung des Ansatzes mittels einer Fallstudie in

einem Praxisprojekt wäre wünschenswert, konnte bisher aber noch nicht realisiert werden.

Literaturverzeichnis

[Ab74] Abrial, J.R.: Data Semantics. Proc. IFIP Working Conf. Data Base Management,

1974; S. 1-60.

[BBR11] Buchwald, S.; Bauer, T.; Reichert, M.: Flexible Prozessapplikationen in Service-

orientierten Architekturen - Ein Überblick. EMISA Forum, 31(3), 2011; S. 32-58.

[BBR12] Buchwald, S.; Bauer, T.; Reichert, M.: Bridging the Gap Between Business Process

Models and Service Composition Specifications. In (Lee, J.; Ma, S.-P.; Liu, A., Hrsg):

Service Life Cycle Tools and Technologies: Methods, Trends, and Advances. IGI

Global, Hershey, 2012; S. 124-153.

[BTBR10] Buchwald, S.; Tiedeken, J.; Bauer, T.; Reichert, M.: Anforderungen an ein Meta-

modell für SOA-Repositories. Proc. 2nd Central-European Workshop on Services

and their Composition, 2010; S. 17-24.

[Bu12] Buchwald, S.: Erhöhung der Durchgängigkeit und Flexibilität prozessorientierter

Applikationen mittels Service-Orientierung. Dissertation, Universität Ulm, 2012.

[Er05] Erl, T.: Service-Oriented Architecture – Concepts, Technology, and Design. Prentice

Hall, 2005.

[He10] Hewlett-Packard Development Company: HP SOA Systinet Software Data Sheet,

2010.

[ID08] IDS Scheer: ARIS SOA Architect - Geschäftsprozesse als Grundlage für Service-

orientierte Architekturen. IDS Scheer, 2008.

[Jo07] Josuttis, N.: SOA in Practice - The Art of Distributed System Design. O’Reilly, 2007.

[OA02] OASIS: Universal Description, Discovery, and Integration (UDDI). Version 3.0, 2002.

[OA05] OASIS: ebXML Registry Information Model. Version 3.0, 2005.

[Or08] Oracle: Oracle Enterprise Repository and Oracle Service Registry for the SOA-

Lifecycle. Oracle Data Sheet, 2008.

[Ro06] Rogers, S.: CentraSite: An Integrated SOA Registry and Repository. White Paper,

Software AG, 2006.

[Sa07] Sachdeva, N.: Customize the WebSphere Service Registry and Repository

Governance Profile. IBM developerWorks, 2007.

[Ti10] Tiedeken, J.: Konzeption und Realisierung eines logisch zentralen SOA-

Repositories. Diplomarbeit, Universität Ulm, 2010.

[WYZ10] Wang, Y.; Yang, J.; Zhao, W.: Change Impact Analysis for Service based Business

Processes. In: Proc. Int. Conf. on Service-Oriented Computing and Applications,

IEEE, 2010.

[XQZ07] Xiao, H., Quo, J., Zou, Y.: Supporting Change Impact Analysis for Service Oriented

Business Applications. In: Proc. Int. ICSE Workshop on Systems Development in

SOA Environments, IEEE, Minneapolis, 2007.

[We07] Web Services Description Language (WSDL), Version 2.0, Part 1: Core Language.

W3C Recommendation, 2007.