Xpert.press

Die Reihe Xpert.press vermittelt Professionalsin den Bereichen Softwareentwicklung,Internettechnologie und IT-Management aktuellund kompetent relevantes Fachwissen überTechnologien und Produkte zur Entwicklungund Anwendung moderner Informationstechnologien.

Dieter Masak

SOA?Serviceorientierung inBusiness und Software

Mit 82 Abbildungen und 39 Tabellen

123

Dieter Masakplenum Management ConsultingHagenauer Str. 5365203 Wiesbadendieter.masak@plenum.de

Bibliografische Information der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der DeutschenNationalbibliografie; detaillierte bibliografische Daten sind im Internet überhttp://dnb.ddb.de abrufbar.

ISSN 1439-5428ISBN 978-3-540-71871-0 Springer Berlin Heidelberg New York

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesonderedie der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen undTabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen We-gen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiserVerwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkesist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechts-gesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltendenFassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegenden Strafbestimmungen des Urheberrechtsgesetzes.

Springer ist ein Unternehmen von Springer Science+Business Media

springer.de

© Springer-Verlag Berlin Heidelberg 2007

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesemWerk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solcheNamen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachtenwären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurdenmit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebenefehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeineHaftung übernehmen.

Satz: Druckfertige Daten des AutorsHerstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, LeipzigUmschlaggestaltung: KünkelLopka Werbeagentur, HeidelbergGedruckt auf säurefreiem Papier 33/3180 YL – 5 4 3 2 1 0

Danksagung

. . . fur Christiane. . .

Dr. Dieter Masak

Inhaltsverzeichnis

1 Prolog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 SOC und SOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Heutiger Zustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Serviceorientierungsparadigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1 Paradigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Enterprise Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4 Zachman-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5 TOGAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6 Systemtheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Service Oriented Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1 Entwicklungsstadien einer Organisation . . . . . . . . . . . . . . . . . . . . 324.2 Virtuelle Enterprises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3 Service Oriented Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.4 Consumerorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.5 Providerorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.6 Brokerorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.7 Serviceadoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.8 Serviceentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.9 Serviceportfoliomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.10 Geschaftsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.11 Organisationsubergreifende Prozesskoordination . . . . . . . . . . . . 794.12 Reifegradmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.13 Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.14 Auswirkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

VIII Inhaltsverzeichnis

5 Service Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.1 SOA-Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.2 Eventarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.4 Servicemodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.5 Komposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.6 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.7 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.8 Servicearten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125.9 Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155.10 Prasentationsservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205.11 SOAbility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245.12 Reifegradmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.13 SOA-Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335.14 Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6 Service Oriented Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396.1 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1416.2 Broker Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436.3 Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466.4 Servicecontainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656.5 Service Information Management . . . . . . . . . . . . . . . . . . . . . . . . . 171

7 Geschaftsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1757.1 Geschaftsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1767.2 Geschaftsprozessmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1807.3 Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1817.4 Softwareunterstutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

8 Service Oriented System Engineering . . . . . . . . . . . . . . . . . . . . . . 1918.1 Evolution und Komplexitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1948.2 Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2028.3 Bricolage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2068.4 Language-Action Perspektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2088.5 SOS-Zyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2108.6 Organisationsubergreifende Komposition . . . . . . . . . . . . . . . . . . . 2128.7 Reengineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2138.8 Ahnlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2158.9 Entwicklungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2168.10 Taxonomien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2178.11 Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2188.12 OWL-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2248.13 WSMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2268.14 WSDL-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2288.15 Ausbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Inhaltsverzeichnis IX

9 Service Oriented Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2319.1 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2359.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2389.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2399.4 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2419.5 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2439.6 WSIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2469.7 BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2479.8 WSCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2539.9 BPML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2569.10 WS-CDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2579.11 Semantische Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2609.12 RosettaNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2629.13 ebXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2659.14 ebBPSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2679.15 Servicemodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2699.16 Wiederverwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2789.17 Servicemaintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2819.18 Servicekomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2829.19 Serviceinteroperabilitat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2879.20 Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2909.21 π-Kalkul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

10 Ultra Large Scale Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29710.1 Charakteristika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29910.2 Treibende Krafte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30210.3 Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

11 Systemtheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30511.1 Komplexe Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30811.2 Enge Koppelung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31311.3 Ashby-Conant-Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31511.4 Organisationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31811.5 Rekursionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31911.6 Selbstorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32011.7 Autopoiesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32211.8 Unbeherrschbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32311.9 SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32511.10 Skalenfreie Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

12 Viable System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33112.1 Viable System Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34112.2 VSM-Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34512.3 Kontrollerdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34812.4 Adaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

X Inhaltsverzeichnis

13 Epilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Metriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357A.1 Messbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358A.2 Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359A.3 Netzwerkmaße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359A.4 Komplexitatsmaße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360A.5 Koppelungsmaße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363A.6 Semantische Ahnlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

π-Kalkul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367B.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367B.2 Kongruenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368B.3 Abstraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369B.4 Reaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369B.5 Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370B.6 Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

1

Prolog

Think what you will, we seize into our handsHis plate, his goods, his money and his lands.

King Richard IIWilliam Shakespeare

1564 – 1616

Die Themen Serviceorientierung und Service Oriented Architecture sind einweites Feld; das vorliegende Buch erhebt keinen Anspruch darauf, in die letz-ten technischen Feinheiten vorzudringen, sondern will einen Uberblick zeigenund – vor allen Dingen – dem Leser1 Denkanstoße vermitteln. Die hier vermit-telten Details sind exemplarischer Natur und werden verwendet, damit demLeser ein Einstieg in die Materie der Serviceorientierung ermoglicht wird, nichtum alle Antworten auf alle Fragen zu liefern; insofern wird auch nicht der Ver-such unternommen, Serviceorientierung allumfassend zu beschreiben. Ziel desBuches ist es, dem Leser ein Verstandnis fur die Anforderungen und die mogli-chen Konsequenzen der Serviceorientierung zu vermitteln, hierzu ist aber auchein rudimentares Verstandnis der technologischen Grundlagen notig. Aber, wiebei allen neuen Technologien, sind die langfristigen Auswirkungen auf die Or-ganisationen und den einzelnen Menschen viel grundlegender als man es amAnfang vermutete. Diese Aussage trifft de facto auf jede Technologie zu undfuhrt zu dem sogenannten Hypecycle: Wir uberschatzen die kurzfristigen Er-folge und Einsatzgebiete einer Technologie und unterschatzen die langfristigenAuswirkungen kleinerer Anderungen. Besonders die Kapitel 10-12 beschafti-gen sich mit den langfristigen Veranderungen aus dem Blickwinkel der Sys-temtheorie und Kap. 4 mit den Auswirkungen von, und den Voraussetzungen,fur Serviceorientierung in Organisationen.

Das in diesem Buch vorzufindende ”Denglisch“ mag die Puristen der deut-schen Sprache befremden, aber es passt sich dem in der IT-Welt in Deutsch-

1 Die maskuline Form Leser, Softwareentwickler, Manager usw. wird in diesem Buchals Rollenbezeichnung benutzt; hierbei kann es sich im konkreten Fall auch stetsum eine weibliche Person handeln.

2 1 Prolog

land vorherrschenden Sprachgebrauch an.2,3 Diese Veranderung der deut-schen Sprache durch Reinterpretation bestehender oder die Einbeziehung neu-er Worter ist kein Defizit, sondern geradezu ein Beweis fur die Vitalitat derdeutschen Sprache.

In letzter Zeit ist das Thema SOA als ein Ausschnitt des ProblemkreisesServiceorientierung immer starker in den Mittelpunkt des offentlichen Interes-ses geruckt. Der Hauptgrund fur dieses Interesse liegt nicht darin begrundet,dass die Unternehmen einen unbedingten Handlungsbedarf im Umfeld vonSOA haben, sondern daran, dass man sich von SOA ein Milliardengeschaftverspricht. Die Forderer der SOA-Hype sind drei Gruppen: Softwareherstel-ler, Consultingunternehmen und Fachzeitschriften. Diese haben zusammen einreges Interesse daran das Thema Serviceorientierung im Markt prasent zu hal-ten und – mit zum Teil absurden – positiven Eigenschaften zu belegen. Zieldieses Buches ist es dem Leser die Fahigkeit zu vermitteln, selbst zu entschei-den wo Serviceorientierung Sinn macht und wo nicht.

2 Interessanterweise haben die selbsternannten Wachter der deutschen Sprachenur mit angelsachsischen Ausdrucken Schwierigkeiten, Fachausdrucke griechischeroder lateinischer Herkunft werden sofort akzeptiert.

3 Die meisten der Deutschpuristen benutzen bestimmt nicht solche schonen Aus-drucke wie Meuchelpuffer fur Pistole, Dorrleiche fur Mumie, Schweißloch fur Poreoder Geistesanbau fur Kultur. . .

2

Einleitung

Kuhner als das Unbekannte zu erforschenkann es sein, Bekanntes zu bezweifeln.

Alexander von Humboldt1769 – 1859

Heute ist die Software zu dem dominanten Trager von Information geworden.Diese Dominanz fuhrt zu einer immer starkeren Durchdringung der gesamtenLebens- und Arbeitswelt mit Software und damit zu immer großeren und kom-plexeren Systemen. Es gibt keine Unternehmen mehr, welche keine Softwareeinsetzen, in der Praxis gilt die Faustformel: Je großer das Unternehmen, des-to großer die Softwaresysteme. Diese großen Systeme sind fast immer dadurchgekennzeichnet, dass sie:

• sehr komplex sind,• sich nichtdeterministisch verhalten,• eine Mischung aus menschlichen Aktionen und Software darstellen.

Folglich wird es in der Zukunft nicht mehr ausreichen, allein die Softwarezu betrachten. Auch andere Wissenszweige wie Psychologie, Soziologie undSystemwissenschaften mussen bei der Beurteilung und Entwicklung solchergroßen Softwaresysteme zu Rate gezogen werden. Ein Mittel zur Strukturie-rung großer Systeme ist die Idee der Services.

Die Serviceorientierung ist im Grunde keine wirklich neue Idee. Gesell-schaften haben schon sehr fruh eine Blute entwickelt, in dem sie Spezialisie-rung von Aktivitaten und Fertigkeiten als Dienstleistung (Service) vorange-trieben haben; daraus entstanden im Laufe der Zeit einzelne Berufszweige wieSchmied, Muller oder Arzt.

Techniker und IT-Fachleute sind stets versucht, sich auf ”ihre“ Technikzuruckzuziehen und dementsprechend IT-Technologie, ihren Einsatz und ihreAuswirkung nicht in einem globaleren Kontext zu betrachten. Diese Heran-gehensweise fuhrt oft zu einer Art ”Blindheit“, denn Technologie hat immerauch Folgen fur den einzelnen Menschen und die Organisationen, in denener agiert. Speziell die Serviceorientierung ist ohne eine entsprechende Aus-richtung der gesamten Organisation und damit implizit auch des einzelnenMitarbeiters nicht moglich.

4 2 Einleitung

Die Serviceorientierung als ein zentrales Paradigma kann heute faktischuberall wiedergefunden werden. Auf der einen Seite kann die Serviceorientie-rung aus dem Blickwinkel der Organisation und auf der anderen Seite aus derSicht der IT betrachtet werden.

Zu den Visionen uber Services gehort auch die Vorstellung, dass es zu je-dem gesuchten Service stets mehrere Provider fur diesen Service geben wird.Eine andere Vision hinter der Serviceorientierung ist die Vorstellung, dass ineiner Welt aus kooperierenden Services neue Applikationen mit sehr kleinemAufwand aus bestehenden Services aufgebaut1 werden konnen. Diese hohe-re Geschwindigkeit bei der Entwicklung einer Applikation fuhrt zur echtenUnterstutzung einer sich rasch verandernden Organisation, die nun, software-technisch gestutzt, auf neue oder veranderte Marktanforderungen reagierenkann. Der heutige Mechanismus des einfachen Informationsaustausches imRahmen der Applikationsintegration2 kann auf Konzepte wie Zugang, Pro-grammierung und Integration bestehender Services und Applikationen ausge-dehnt werden, in dem die bestehenden Applikationen3 wiederum zu Serviceswerden. Ein wichtiges okonomisches Argument ist, dass durch den Einsatzvon Service Oriented System Engineering (s. Kap. 8) und Service OrientedComputing (s. Kap. 9) das dynamische Wachstum von Applikationsportfoli-os stark beschleunigt werden kann. Systeme, die z.Z. ein Silodasein als mehroder minder getrennte Applikationen fristen, konnen durch das Serviceorien-tierungsparadigma zu vollig neuen Applikationen kombiniert und so vereintwerden.

Aber nicht nur die Software wird durch das Serviceorientierungsparadigmaberuhrt werden, auch unsere Organisationen und Organisationsformen wer-den sich durch den erfolgreichen Einsatz von Serviceorientierung verandern.Servicetechnologien werden durch unsere Gesellschaft geformt und formengleichzeitig auch unsere Gesellschaft durch ihren Einsatz. Ohne die Idee derDienstleistungsgesellschaft, welche von Soziologen schon lange formuliert wur-de, ware ein Serviceorientierungsparadigma in der Technik nie entstanden.Umgekehrt wird das Serviceorientierungsparadigma die Fahigkeit der Orga-nisation zum Outsourcing (der Nutzung von externer Dienstleistung) auf glo-baler Ebene starken.

Aus Sicht der Organisation resultiert Serviceorientierung aus dem Ver-such heraus in der Lage zu sein, Dienstleistungen ”outsourcen“4 zu konnen.Sogar die IT selbst, ist aus diesem Blickwinkel betrachtet, ein Service, der imentsprechenden Sprachgebrauch einen ”customized“ Service eines Servicepro-viders darstellt. Dieser spezielle IT-Service ist fur die Fachbereiche interessant,weil die komplexen Details einer Losung vom Serviceprovider beherrscht5 und

1 Legoprinzip2 EAI, Enterprise Application Integration.3 Dies kann bei Legacysoftware zum Teil sehr aufwandig sein.4 An andere Organisationen auslagern zu konnen.5 hoffentlich. . .

2.1 Services 5

vor dem Kunden verborgen6 werden. Folglich muss eine serviceorientierte ITihre Produkte den Kunden so einfach wie moglich zur Verfugung stellen, mitder Folge, dass diese IT sich immer starker kundenorientiert aufstellen muss.Eine weitergehende Konsequenz aus dieser verstarkten Kundenorientierungist, dass die nachfolgende Entwicklung zu immer einfacheren und vor allenDingen flexibleren Softwarelosungen fuhren muss, um mit Hilfe der Softwaredie Kundenzufriedenheit zu erhohen.

Eine andere Sichtweise auf die Serviceorientierung ist die technische Blick-richtung. In den heutigen IT-Systemen spielt die Zielsetzung der moglichenIntegration eine wichtige Rolle, da große Systeme aus immer kleineren Kom-ponenten in beliebiger Art und Weise zusammengesetzt werden. Wenn dieseKomponenten in Form von Services zur Verfugung gestellt werden, so wirdauch hier die implementierte Komplexitat vor den Anwendern versteckt. Die-sem wird nur ein Interface fur die Nutzung nicht jedoch die Implementierungzur Verfugung gestellt. Diese Zielsetzung ist nicht neu, schon die Idee der Ob-jektorientierung als auch die Idee der Komponente haben dieselbe Zielsetzung,den Benutzer vor der Implementierungskomplexitat durch ein offentliches In-terface zu schutzen.

2.1 Services

Was ist ein Service? Ein Service ist eine Dienstleistung, welche einem Kun-den zur Verfugung gestellt wird. Wie jede Form von Dienstleistung habenServices als Charakteristika ein hohes Maß an Kundenbeteiligung in ihrerDefinition und Weiterentwicklung, sowie die Schwierigkeit der Standardisie-rung. Die Schwierigkeit hinter der Standardisierung liegt in dem Wunsch derKunden begrundet, ein hohes Maß an Individualisierung in den Services zuhaben. Dieses hohe Maß an Individualisierung schafft umgekehrt Problemefur die Standardisierung, dem genauen Gegenteil einer Individualisierung.

Die Geschaftswelt hat auf ihrem Weg zur Dienstleistungsgesellschaft7 eingewisses Maß an Erfahrung uber Services, deren Nutzung, Verwendung undEinsatz aufgebaut. Die IT-Welt und hierbei speziell die Softwarestruktur inForm von Services steht jedoch noch am Anfang einer solchen Entwicklung.8

Services in einer Software mussen dem Anwender eine wohldefinierte Funktio-nalitat in einem veranderbaren Kontext zu verifizierbaren Qualitatskriterienund ab initio festgelegten Preisen bieten konnen.

Eine interessante Eigenschaft von Services aus der Geschaftswelt wird sehroft bei der Einfuhrung von Services in der Software ubersehen: Erfolgreiche6 Idealerweise. . .7 Aus soziologischer Sicht die Phase nach der Industrialisierung.8 Wenn man bedenkt, dass im Rahmen der Organisationsform einer Softwareent-

wicklung das Prinzip der Softwarefactory, im Sinne der Industrialisierung vonSoftwareentwicklung, von einigen Consultingunternehmen empfohlen wird, solasst sich erkennen, wie weit die IT-Welt der Geschaftswelt hinterherhinkt.

6 2 Einleitung

Services werden stets aus der Sicht des Kunden definiert und nicht aus Sichtdes Providers! Im Gegensatz dazu entstehen die meisten heutigen Services inder Software aus Sicht des Providers, der sein bestehendes System in Serviceszerlegt und diese anbietet. Diese Form der Serviceentwicklung fuhrt zu großenHindernissen bei der Nutzung und Akzeptanz.

2.2 SOC und SOSE

Das Service Oriented Computing (SOC) und das Service Oriented SystemEngineering (SOSE) sind zwei Entwicklungsparadigmen, welche die Servicesals fundamentale Elemente zur Entwicklung von Applikationen und anderenServices einsetzen.

Das Paradigma der Serviceorientierung bezieht sich nicht nur auf Organisa-tionen und die Art und Weise, wie Software produziert wird, sondern auch aufdie Software selbst bzw. auf ihre Architektur. Technisch gesehen erzeugt dasService Oriented Computing keine neuen Losungsmoglichkeiten, da dieselbenLosungen auch mit CORBA (s. Abschn. 6.3.2) oder anderen Aufrufmechanis-men9 gebaut werden konnten. Aus diesem Grund ist die Einfuhrung eines Ser-viceorientierungsparadigmas auch eine viel starker philosophisch ausgerichteteFrage nach dem Gesamtkontext und der Veranderung aller Beteiligten dennein originar technisches Problem.

Etwas mehr Klarheit bei der Softwareproblemstellung erhalt man, wennman sich die Unterschiede zwischen der Serviceorientierung auf der einen undder Objektorientierung auf der anderen Seite betrachtet. Obwohl beide ahn-liche Zielsetzungen haben, in dem sie Funktionalitat hinter einem Interfaceverstecken und damit funktionale Kapseln sowie eine gemeinsame Messageori-entierung bilden, so zeigen sich doch Unterschiede. In der Objektorientierungwird die Funktionalitat durch Objekte oder Klassen gekapselt, welche die-se Funktionalitat als Methoden anbieten. Im Serviceorientierungsparadigmawird die Funktionalitat als Prozedur eines Services geliefert. Der großte Un-terschied ist jedoch die Behandlung von Zustanden. Objekte werden gebaut,um damit Zustande in ihren Attributen halten zu konnen. Aus diesem Grundsind fast alle Objekte in der Objektorientierung, bis auf triviale Ausnahmen,zustandsbehaftet. Im Gegensatz dazu werden Services nicht entworfen, umZustande zu halten, es wird stets versucht, sie zustandslos zu halten. Aber inder realen Welt macht es wenig Sinn, nur zustandslose Services zu haben, denndies wurde bedeuten, dass der Zustand jedes Mal beim Aufruf eines Servicesvollstandig mitgeliefert werden musste. Aus diesem Grund ist es sinnvoll, demService Zugang zu den Zustandsinformationen zu geben. Aber dieser Zugangsollte auch den allgemeinen Prinzipien der Serviceorientierung genugen. DieseServiceorientierung impliziert, dass die Services nach fachlichen Gesichtspunk-ten, relativ grobgranular, entstehen und alle voneinander unabhangig sind. Im

9 RPC, DCOM, RMI. . .

2.3 Heutiger Zustand 7

Gegensatz hierzu fuhrt die Objektorientierung durch das Prinzip, dass alles inForm von Objekten beschrieben wird, zu komplexen Netzen aus Objekten, indenen eine recht hohe Zahl von Relationen das fachliche Wissen zu einem ge-wissen Grad sogar externalisiert. In dem Serviceorientierungsparadigma sinddie Interfaces breiter und die ausgetauschten Messages großer, was wiederumstarker der ”Lebenserfahrung“ des Menschen entspricht.

In der Praxis ist jedoch oft eine Mischung aus beiden Paradigmen, Ob-jektorientierung und SOC zu beobachten. Oft werden die Services einer SOC,nicht aus fachlichen Gesichtpunkten konstruiert, sondern die Technik ist dietreibende Kraft. Es entsteht eine Art Wrappingschema, um bestehende Ob-jekte als Services darstellen zu konnen. Dieser Zugang fuhrt nicht wirklich zueiner SOA (s. Kap. 5) oder folgt der Grundidee des SOC da er generell dasPrinzip der losen Koppelung eklatant verletzt.10

2.3 Heutiger Zustand

Die heutigen Organisationen sind durch das Phanomen der gewachsenen Ar-chitekturen11 gepragt. Diese Architekturen sind meist nicht planvoll, sonderndurch ein zunehmendes Wachstum der Applikationen auf der einen Seite undsimultan durch die Einfuhrung immer neuer Architekturformen auf der an-deren Seite entstanden. Diese Abfolge der Architekturen legt sich uber dieOrganisation als Ganzes und erzeugt ein Muster, welches einer Abfolge vonerkalteten Lavastromen ahnelt.12 Neben den diversen Architekturen gibt esnoch eine Vielzahl von Kommunikations- und Integrationsformen, die sichuber die Organisation und alle ihre Partner verteilen. Integrationsformen ran-gieren von Diskettenaustausch, Tapetransfer uber FTP, E-Mail bis hin zuCORBA und Webservices.

Im Rahmen des Serviceorientierungsparadigmas mussen alle diese Archi-tekturen aufgebrochen und in Services uberfuhrt werden. Ein solches Unter-fangen bindet auf lange Zeit erhebliche Krafte in den Organisationen undverlangt sehr hohe Investitionen, schließlich wird die Gesamtmenge der Soft-ware, welche sich in den letzten 30 Jahren angehauft hat, verandert. Ob diestatsachlich sinnvoll ist, oder ob es nicht einfacher ware, Teile der bestehendenSystem einzufrieren und lange mit einer Koexistenz zwischen diversen Archi-tekturformen zu leben ist eine Frage, die sich nur im Einzelfall klaren lasst,dieser Ansatz kann betriebswirtschaftlich interessant sein, minimiert er dochdie notwendigen Investitionen. Aber wie bei jeder neuen Technologie verspre-

10 Obwohl es von Vertretern dieses Zugangs oft als Implementierung einer SOA ver-kauft wird. Speziell im CORBA-Umfeld ist dies technisch recht einfach moglich.Eine solche Implementierung sollte man allerdings nicht SOA, sondern

”CORBA

through Port 80“ nennen.11 Accidential Architecture12 Lava Flow Pattern

8 2 Einleitung

chen auch hier die Anhanger, dass die Einfuhrung einer Serviceorientierungalle Probleme der Vergangenheit losen kann.13

2.4 SOA

Technologien und Softwareparadigmen schlagen sich stets auch in der Archi-tektur nieder. Die aus dem Serviceorientierungsparadigma entstehende Archi-tektur wird als Service Oriented Architecture (SOA) bezeichnet. Eine solcheSOA ist die Folge und simultan auch die notwendige Voraussetzung fur dieZerlegung bestehender und den Aufbau neuer Applikationen aus Services.

Tabelle 2.1: Evolution der Architekturen

Gebiet 1960-70 1980-90 1990+ 1995+ 2000+ 2010+

Markt-impe-rativ

Markt-anteile

Effektivitat Dezentra-lisierung

Kunden-bindung

Real TimeEnterprise

ServiceOrientedEnterprise

Archi-tektur

Mainframe Module Client-Server

Applika-tionsserver

SOA SOA

Zielvor-stellung

Skalenoko-nomie

BusinessProcessReengineer-ing

BusinessApplikatio-nen

Kunden-bindung

Entflechtung Serviceoko-nomie

Treiber StatusQuo, keineSkalierung

sinkendeCPU-Kosten

PC undNetzwerke

WWW Webservices semantischeServices

In Veroffentlichungen wird sehr oft der Begriff SOA identisch zum Service-orientierungsparadigma gesehen, obwohl beide etwas vollig anderes beschrei-ben. Diese Vermischung verwirrt viele Leser. Selbst der Begriff SOA wird nichteinheitlich genutzt und diverse Autoren definieren ihn unterschiedlich, so z.B.:

• Arsanjani –SOA is not a product – it’s about bridging the gap between businessand IT through a set of business-aligned IT services using a set ofdesign principles, patterns and techniques.

13 Die Geschichte der Softwareindustrie ist voll von diesen Versprechungen, von de-nen in der Vergangenheit keines eingehalten wurde:Durch Objektorientierung wird alles billiger und schneller. . .Durch CASE-Tools wird alles billiger und schneller. . .Durch UML wird alles billiger und schneller. . .Mit MDA wird es billiger und schneller. . .Mit Java wird es einfacher. . .

2.4 SOA 9

Tabelle 2.2: Paradigmenwechsel

Zeitraum Revolution Computing Paradigma Architektur

1970-80 Mainframe Monolithisch Single Tier

1980-90 Midrange Abteilungsorientiert Single Tier

1990-95 Client/Server Power fur den Desktop 2 Tier

1995-2000 Web Portale und Backendsysteme 3 Tier

2000+ SOA servicebasiert servicebasiert

• Sprott und Wilkes –Service Oriented Architecture (SOA) is the policies, practices andframeworks that enable application functionality to be providedand requested as sets of services published at a granularity rele-vant to the service requestor, which are abstracted away from theimplementation using a single, standards based form of interface.

• Erl –SOA is a form of technology architecture that adheres to the prin-ciples of service orientation. When realized through the Web ser-vices technology platform, SOA establishes the potential to supportand promote these principles throughout the business process andautomation domains of an enterprise.

• Gartner Group –Essentially, SOA is a software architecture that builds a topology ofinterfaces, interface implementations and interface calls. SOA is arelationship of services and service consumers, both software modu-les large enough to represent a complete business function. Servicesare software modules that are accessed by name via interface, ty-pically in request-reply mode. Service consumers are software thatembeds a service interface proxy (the client representation of theinterface).

• van Zyl –Service based architecture [SOA] is a layered architecture that se-parates the usage and definition of software components, from theimplementation software architecture in order to define software-as-services using a common standard.

• W3C –A Service Oriented Architecture (SOA) is a form of distributedsystems architecture. [It consists of] a set of components which canbe invoked, and whose interface descriptions can be published anddiscovered.A service is an abstract resource that represents a capability ofperforming tasks that form a coherent functionality from the pointof view of providers entities and requesters entities.

10 2 Einleitung

• Gioldasis –Service-Oriented Architecture (SOA) refers to an application soft-ware topology according to which business logic of the applicationsis separated from its user interaction logic and encapsulated in oneor multiple software components (services), exposed to programma-tic access via well defined formal interfaces. Each service providesits functionality to the rest of the system as a well-defined inter-face described in a formal markup language and the communicationbetween services is platform and language independent.

• plenum –Eine Anwendungsarchitektur, in der die Funktionalitaten als un-abhangige Services mit wohldefinierten aufrufbaren Interfaces vor-liegen, so dass sie – in einer sinnvollen Reihenfolge aufgerufen –einen Geschaftsprozess abdecken.

Diese verschiedenen Definitionen einer SOA zeigen die unterschiedlich gesetz-ten Schwerpunkte des Serviceorientierungsparadigmas auf. Je nach dem zuuntersuchendem Aspekt ist es besser, folgende Begriffe zu unterscheiden:

• Service Oriented Computing (SOC) (s. Kap. 9) – Der Bau von Services.• Service Oriented Architecture (SOA) (s. Kap. 5) – Die aus der Nutzung

von Services resultierende Architektur.• Service Oriented Platform (SOP) (s. Kap. 6) – Die Infrastruktur fur den

Einsatz und die Entwicklung von Services.• Service Oriented System Engineering (SOSE) (s. Kap. 8) – Die Vorge-

hensweisen zum Bau und Einsatz von Services.• Service Oriented Enterprise (SOE) (s. Kap. 4) – Die Struktur der service-

nutzenden und -erzeugenden Organisation.

Die Modewelle SOA und Serviceorientierung wird jedoch nicht nur auf techni-scher, sondern auch auf personlicher Ebene Auswirkungen auf Einzelne haben:

More CIO’s14 will lose their job over SOA implementations than losttheir job over ERP15 implementations.

Jeff Schneider

Die Versprechungen von Unternehmen in Bezug auf SOA und Serviceorientie-rung sind immens, besonders gefordert wird dies durch die implizite Allianzvon Werkzeugherstellern und Consultingunternehmen; beide haben ein großesInteresse daran, an dem SOA-Hype zu partizipieren. Wie auch bei vergange-nen ”IT-Hypes“ ublich wird von den Herstellern und Consultingunternehmen

14 Chief Information Officer. Manche sind der Ansicht, es ware die Abkurzung furCareer is over . . .

15 Enterprise Resource Planing

2.4 SOA 11

stets versprochen, dass mit einer SOA16 alles besser wird. Es wird eine Revolu-tion mit immensen Einsparungen prognostiziert. Die Liste der Versprechungenliest sich wie ein Wunschzettel jeder Organisation, die massiv IT einsetzt:

• SOA wird es ermoglichen, schnell und einfach auf Veranderungen zu rea-gieren, nicht nur funktional, sondern auch geographisch und in Bezug aufdie gewahlte Plattform oder den Lieferant. – Funktionale Veranderungenwerden uber fachliche Anforderungen spezifiziert und fuhren zu einer Evo-lution der Software. Die Zeiten sind hier meist durch die Domane undnicht durch die Software bestimmt. Eventuelle Veranderungen in der Geo-graphie sind immer Veranderungen in der Organisation. OrganisatorischerWandel hat seine eigenen Gesetze und Geschwindigkeiten, die in aller Re-gel langer dauern als die Software. Der Know-how-Aufbau fur eine neuePlattform dauert relativ lange, da Lernkurven in neuen Technologien sehrflach sind. Außerdem verfolgen alle Lieferanten als Ziel ihrer Kundenbe-ziehungen niedrige Einstiegs- und hohe Ausstiegshurden damit der Kundenicht wechselt.

• Einfache Integration mit internen und externen Partnern. – Die Haupt-aufwande bei der Integration liegen nicht im Bereich der technischen, son-dern bei der semantischen Integration.

• Wiederverwendung wird vereinfacht. – Dieses Versprechen wurde schon beider Einfuhrung der objektorientierten Sprachen strapaziert und trat nichtein. Wiederverwendung muss antizipiert, d.h. aktiv angegangen werden.Reaktive Versuche zur Wiederverwendung sind mehr eine Art ”Software-salvaging“.

• Unterstutzung fur kurze Produktlebenszyklen. – Fur den Fall des massivenEinsetzens von Wiederverwendung ist dies theoretisch moglich. PraktischeErfahrungen zeigen jedoch, dass Produktzyklen starker vom Markt, demMarketing und einer organisatorischen Fahigkeit zum Wandel beeinflusstwerden als durch Software.

• Verbesserung des Return on Investment. Durch den Einsatz von austausch-baren Webservices soll sich der ROI verbessern. – Die Kosten fur einenESB (s. Abschn. 6.3) sind allerdings immens.

• Geschaftsprozesse werden direkt in die IT abgebildet. – Das Alignment istetwas komplexer als gemeinhin angenommen wird.17

• Reduktion von Entwicklungskosten. – Da es heute keine expliziten Modellefur eine Serviceentwicklung gibt, scheint es sich hierbei um Wunschdenkenzu handeln.

• Die Informationsarchitektur wird transparent. – Im Gegenteil, die zuneh-mende Verknupfung der Services fuhrt zu einem komplexen Gesamtsystem.

16 Oft mutiert dabei die eigentliche Architektur (SOA) zum Uberbegriff fur Service-orientierung.

17 Masak, D.: 2006, IT-Alignment, Springer.

12 2 Einleitung

• Die Benutzung von Standards sichert Interoperabilitat. – Die technischeInteroperabilitat ist ein relativ kleines Problem. Interoperabilitat zeigt sichheute primar auf der semantischen Ebene (s. Abschn. 9.19).

• Durch die Einfuhrung von SOA und Services wird sich die Datenqualitaterhohen. – Ein Trugschluss; Datenqualitat ist eine Folge von hoher Qua-litat bei der Entstehung von Daten. Erst wenn der Erzeuger von Dateneinen echten Anreiz hat, hohe Qualitat zu liefern, entsteht Datenqualitat.

• Die IT-Governance wird einfacher. – Durch die zunehmende Komplexitatwird dies ad absurdum gefuhrt. Außerdem konnen Ultra Large Scale Sys-teme entstehen, die sich der Governance verweigern (s. Kap. 10).

• Services, speziell Webservices18 benotigen keine Programmierung. – DieseVerheißung wird von Werkzeugherstellern genutzt, um ihre Generatorenzu verkaufen, die automatisch generierten Services fuhren fast immer zueinem chaotischen System.

Diese ganzen Versprechungen sind nicht zu halten, viel sinnvoller ist es, sichmit den Moglichkeiten, Chancen und Risiken des Serviceorientierungspara-digmas auseinander zu setzen und dann selbst zu urteilen. Der Trend zurServiceorientierung ist nicht aufzuhalten und wird in den nachsten Jahrenunsere Umgebung bestimmen. In gewisser Weise ist dies auch die Folge derzunehmenden Informationsmenge. Schon in den siebziger Jahren wurde dieFolge der Informationszunahme vorhergesagt:

What information consumes is rather obvious: it consumes attentionof its recipients. Hence a wealth of information creates a poverty ofattention and a need to allocate that attention efficiently among theoverabundance of information sources that might consume it.19

Daher muss die zunehmende Informationsmenge durch immer weniger Auf-merksamkeit bearbeitet werden, mit der Folge, dass Information zunehmendautomatisiert verarbeitet wird. Einer der Grunde fur die offentliche Aufmerk-samkeit fur Serviceorientierung und speziell fur SOA ist die Tatsache, dassdie Serviceorientierung eine hervorragende Metapher fur nicht technisch ori-entierte Menschen ist. Diese konnen nun auch den Wert einer Architekturverstehen und den Herausforderungen der Veranderung und Anpassung inOrganisationen und Technik begegnen. Der wirkliche Mehrwert einer SOAist, dass es die erste Architektur ist, die Software und Organisation transzen-diert. Langfristig gesehen muss die Serviceorientierung sowohl Auswirkungenauf die Betriebssysteme als auch die zur Verfugung stehende Hardware haben.Heutige Ansatze eines Hardware Abstraction Layers20 bauen auf der Idee einergenerischen Hardware auf, es ist z.Z. noch unklar, wie eine serviceorientierteHardware oder ein serviceorientiertes Betriebssystem konzipiert sein konnte.

18 s. Abschn. 5.419 Simon, H.: 1971, Designing Organizations for an Information-rich World, The

John Hopkins Press.20 So z.B. in Windows und Linux.

3

Serviceorientierungsparadigma

I have travelled the lengthand breadth of this country

and talked with the best peopleand I can assure you

that data processing is a fadthat won’t last out the year.

Editor Business-BooksPrentice-Hall

1957

Der Begriff ”Service“ wird in vielfaltiger Weise im IT-Bereich verwendet. IBMz.B. bietet seinen Kunden einen ”Service on Demand“. Webservices wurdenin letzter Zeit zumindest in der Presse sehr bekannt. Provider, welche Appli-kationen uber das Netz zur Verfugung stellen, werden auch als ApplicationService Provider bezeichnet (ASP). Es gibt also in jeder Organisation eineganze Reihe verschiedener Bereiche, in denen Services heute vorkommen. DerErfolg des World Wide Web (WWW) hangt unter anderem davon ab, dasses serviceorientiert aufgebaut ist. Wenn man es grob vereinfacht, so existiertim WWW hauptsachlich der Service ”Seite abrufen“. Dieser Service kannvon einer großen Nutzergruppe verwendet werden, er wird durch den Aufrufder entsprechenden Internetseite angefordert. Es spielt keine Rolle, welchenBrowser oder welches Betriebssystem der Nutzer verwendet1, um eine Sei-te abzurufen. Ebenso wenig ist die verwendete Webserversoftware oder dasverwendete Betriebssystem des Webservers von Bedeutung.

Ein Service in der Software zu definieren ist nicht ganz einfach, obwohles einem intuitiv klar erscheint, daher betrachten wir zunachst einmal, wasein Service nicht ist. Ein Service ist nicht das selbe wie eine Komponente,wie man sie aus der komponentenbasierten Softwareentwicklung her kennt,wenngleich viele Konzepte auch auf die serviceorientierte Softwareentwick-lung ubertragen werden konnen. Eine andere Vorstellung ist, dass ein Service

1 Zumindest in der Theorie. Es hat immer wieder Versuche von Microsoft gegebenihr eigenes Webserverprodukt IIS nur durch den Internet Explorer

”vernunftig“

darstellbar zu machen oder durch die Einbettung von ActiveX-Elementen dieseSeiten nur aktiv nutzbar zu machen, wenn der Nutzer den Internet Explorer vonMicrosoft einsetzt.

14 3 Serviceorientierungsparadigma

Abb. 3.1: Die unterschiedlichen Sichten auf einen Service

von einer Komponente implementiert wird und der Service damit nur das In-terface der Komponente darstellt. Diese Betrachtungsweise ist etwas zu eng.Ein Service beinhaltet zwar auch ein Interface, zusatzlich dazu existiert aberein Vertrag, welcher Eigenschaften enthalt, welche die Semantik betreffen unddie nicht uber ein Interface definiert werden konnen. Dazu gehoren Qualitats-eigenschaften wie Verfugbarkeit oder Performance, die auch im Sinne einesjuristischen Vertrages vereinbart werden konnen. Dafur reicht dann die Be-schreibung eines Interface nicht mehr aus, sondern es bedarf eines komple-xen Service Level Agreements (SLA), wie man es aus der IT-Infrastructure-Library (ITIL) kennt, in dem Rechte und Pflichten von Serviceprovider undServiceconsumer klar geregelt sind.

Die Nutzung unterschiedlicher Perspektiven ist wichtig fur das Verstandniseines Services. Hier gibt es zwei wesentliche Sichtweisen:

• Geschaftssicht – Die Geschaftssicht betrachtet einen Service als Teil einerGeschaftstransaktion, die in einem Vertrag beschrieben und die durch dieGeschaftsinfrastruktur durchgefuhrt wird. Was ein Service leistet, ist engverknupft mit den Erfahrungen des Geschaftsbereichs. Einen Service aufdieser Seite bezeichnet man mit dem Begriff Geschaftsservice (genau wieeine Dienstleistung). Typische Eigenschaften eines solchen Geschaftsser-vices sind:– Geschaftsvisibilitat – Ein Service muss etwas sein, wofur Kunden bereit

sind, etwas zu bezahlen. Die Kunden ihrerseits erhalten etwas, das fursie von Wert oder von Nutzen ist. In diesem Zusammenhang muss derBegriff ”Kunde“ weiter gefasst werden als im Bereich des Produktkaufs.

3 Serviceorientierungsparadigma 15

Als Kunden werden nicht nur externe, sondern auch interne Consumerdes Services bezeichnet.

– Technologie – Hierbei steht das, was implementiert werden soll im Fo-kus, nicht wie etwas implementiert werden soll.

– Kontext – Die Services werden durch ihren jeweiligen fachlichen Kon-text definiert.

• Techniksicht – Ein Service stellt eine mehr oder minder abgeschlosseneFunktionalitat bereit, wobei die Semantik eines Services in Form einesInterfaces beschrieben wird. Eigenschaften technischer Services sind:– Technologie – Bei technischen Services steht die Technologie, also wie

etwas implementiert werden soll, im Vordergrund.– Kontext – Ein Service ist eine vom Kontext gekapselte und abstrahierte

Funktionalitat.

Es existieren einige Unterschiede zwischen den Sichten und damit auch zwi-schen den daraus abgeleiteten unterschiedlichen Servicedefinitionen. Der we-sentliche Unterschied beider Sichten liegt in der Betrachtung des Kontextsbegrundet. Fur Geschaftsservices ist der Kontext von großer Wichtigkeit; al-le Organisationen arbeiten schließlich in einem dynamischen Marktumfeld.Werden Marktchancen ergriffen, so wird von dieser Seite erwartet, dass neueServices erstellt oder bestehende Services verandert werden. Die technischeSeite ist bestrebt, den Kontext moglichst statisch zu halten, da nur so dieForderung nach Effizienz und Wiederverwendbarkeit erreicht werden kann.Diese Differenzen lassen sich nicht wirklich uberbrucken. Die negativen Effek-te lassen sich aber abmildern, indem kommuniziert wird, welche Bedeutungein Service etwa auf organisatorischer Ebene hat oder wie wichtig Wiederver-wendung fur einen implementierten Service ist.

Zusatzlich zu den beiden Perspektiven Geschafts- und Techniksicht existie-ren auch eine Consumer- und eine Providerperspektive. Die Implementierungist Teil der Providersicht und muss fur den Consumer von geringem Interes-se sein. Die Providersicht uberschneidet sich mit der Geschaftssicht2 und dertechnischen Sicht3. Die Consumersicht ist mehr auf die Geschaftssicht fokus-siert. Wenn ein Consumer einen Service in Anspruch nimmt, muss fur ihn derWert des angebotenen Services schon vorab erkennbar sein. Ist dies der Fall,stellt der Service eine Schnittstelle zwischen Geschaftswert und Implementie-rung dar.

2 Was wird implementiert und warum?3 Wie wird es implementiert?

16 3 Serviceorientierungsparadigma

3.1 Paradigma

Die Verwendung von Services in Organisationen und in der Software folgeneinem gemeinsamen Grundsatz, dem ”Paradigma4 der Serviceorientierung“:5

Alle Funktionen in einem realen System, seien es Ablaufe in Organisa-tionen, Prozesse, Aktivitaten, Funktionen in Softwaresystemen, Appli-kationen, Teile von Applikationen oder Softwarefunktionen lassen sichals Services darstellen und aus Services aufbauen!

Oder kurzer formuliert:

Alles, was aus- oder durchgefuhrt werden kann ist ein Service!

Hierbei hat jeder Service mindestens einen Provider (den Lieferanten) undeinen Consumer (den Kunden oder Nutzer). Außerdem ist jeder Service inseiner Funktionalitat und seinen Randbedingungen vorab definiert und dieseBedingungen sind sowohl dem Provider als auch dem Consumer bekannt.

3.2 Service

Der Ursprung der Idee des Services liegt in den Dienstleistungen, dies hatzur Folge, dass es Unterschiede zwischen Produkten und Services gibt. Un-abhangig von einer exakten Definition des Begriffs Service teilen sich in derPraxis alle Services eine Reihe von Eigenschaften:

• Services stellen Fahigkeiten oder Funktionen zur Verfugung.• Services sind sofort nutzbar.• Services haben ein wohldefiniertes Verhalten.• Services haben definierte Ein- und Ausgaben.• Services werden ”gemanaged“, um nichtfunktionale Ziele zu erfullen.• Services werden aufgebaut und eingesetzt, damit ein organisatorisches Ziel

erreicht werden kann.• Services sind modellierbar.• Services sind zusammenbaubar6, um damit neue Services zu erzeugen.

Ein Service unterscheidet sich von klassischen Produkten7 durch folgendeMerkmale:

4 Paradigma aus dem Griechischen παραδειγµα aus παρα (neben) und δειγνναι(zeigen). Spotter behaupten ein Paradigma sei die Summe aller Vorurteile, dieuber etwas existiere.

5 s. auch Servicedefinition, S. 18.6 Servicekomposition, s. Abschn. 9.18.7 Die Debatte uber den Unterschied zwischen Produkten und Services (Dienstleis-

tungen) geht auf Adam Smiths The Wealth of Nations zuruck, welcher als erstereinen Unterschied postulierte.

3.2 Service 17

Abb. 3.2: Unterschiedliche Sichten auf Services

• Services sind nicht direkt greifbar8. Folglich konnen sie weder inventarisiertnoch patentiert werden und ihr Wert ist nur schwer quantifizierbar, wobeidie Nichtgreifbarkeit sich in zwei Dimensionen vollzieht. Zum einen sindServices physisch ungreifbar, d.h. sie konnen nicht beruhrt oder betastetwerden, zum anderen sind sie mental ungreifbar, d.h. sie konnen nichtmental als ein Gegenstand9 verstanden werden.

• Services sind heterogener und vielgestaltiger als Produkte, da sie oft vonMenschen direkt erzeugt werden. So sind Kategorien wie Wiederholbarkeitund Vorhersagbarkeit oft nur schwer anwendbar.

• Services werden fast gleichzeitig produziert und verbraucht, im Gegensatzzu Produkten, welche meistens eine Lagerhaltung haben. Zentralisierungund Massenproduktion sind fur Services problematisch. Dieses Kriteriumist nicht besonders trennscharf, da es viele Services gibt, die separat vomConsumer durchgefuhrt werden.10

• Services sind ”verderblich“11, nicht so Produkte, d.h. Services konnen nichtgespeichert werden, aber aus Sicht des Consumers kann das Ergebnis desServices durchaus unverderblich sein.

• Die Qualitat eines Services hangt von vielen sehr schwer kontrollierbarenFaktoren ab. Da ein Schwerpunkt der Services im direkten Kundenkontakt

8 intangible9 Ein Konto auf der Bank oder ein Lebensversicherungsvertrag sind zwar nicht phy-

sisch greifbar, stellen jedoch mental Gegenstande dar und sind somit Produkte.10 Paketdienste oder Reinigungen fuhren einen Großteil ihrer Tatigkeiten vom Con-

sumer separat durch.11 perishable

18 3 Serviceorientierungsparadigma

besteht, hat dies hat zur Konsequenz, dass die Qualitat des Services vonder Fahigkeit des Kunden determiniert wird, sich zu artikulieren bzw. derProvider in der Lage ist dem Kunden zuzuhoren.

• On-demand-Delivery – Die Services werden meistens direkt durch dieNachfrage nach ihnen ausgelost.

• Im Gegensatz zu Produkten ist die Preisbildung bei Services oft schwer.

Damit diesen unterschiedlichen Charakteristika Rechnung getragen werdenkann, muss eine umfassende Servicedefinition sehr abstrakt sein, die in diesemBuch verwandte Definition von Service ist daher:

Ein Service ist die Summe des beobachtbaren Verhaltens eines Systems(genannt Serviceprovider), gegeben durch die Menge aller moglichenInteraktionen und deren Relationen zwischen dem System und seinerUmgebung.

Diese Definition ermoglicht es, Services als systemtheoretische Gebilde (s.Kap. 11) zu fassen und dem Serviceparadigma folgend alles als Service auf-zufassen. Dieses Servicekonzept ist das Resultat der Trennung zwischen deminternen (Implementation) und externen (Interface) Verhalten eines Systems.Fur den Consumer (als Teil der Umgebung) ist nur der externe Teil inter-essant. Implizit lasst sich aus dieser Definition eine Reihe von Eigenschaftenfur die Services ableiten:

• Ein Service hat einen Grad an Autonomie, da ohne Autonomie ein Systemuberhaupt nicht identifizierbar ist.

• Services besitzen ein Interface (eine Schnittstelle), dieses wird durch dieGrenze zwischen System und Umgebung gebildet. Da der Consumer einTeil der Umgebung ist, bildet seine Umgebungsteilmenge das fur ihn wahr-nehmbare Interface. Der andere Teil der Grenze zur Umgebung bildet furden Service den Kontext.

• Da Systeme zu großeren Systemen zusammengesetzt werden konnen, gibtes auch die Moglichkeit zur Servicekomposition.

• Die funktionalen Eigenschaften sind die erwarteten Verhaltensmuster desSystems und ergeben sich aus dem Interface.

• Die nichtfunktionalen Eigenschaften sind die durch den Kontext (ohne denConsumer) ausgelosten Verhaltensmuster des Systems.

3.2.1 Funktionale Eigenschaften

Ein Service muss hinreichend gut beschrieben werden. Speziell dann, wennder Consumer den Provider nicht kennt, ist eine semantisch reichhaltige undstrukturell gute Beschreibung notwendig, damit ein Service auch entdeckt undnachfolgend eingesetzt werden kann.

Die funktionalen Eigenschaften eines Services beschreiben die fachlichgewunschten Funktionen, die der Service erfullen soll; das, was er tatsachlich

3.2 Service 19

fur seinen Kunden durchfuhrt.12 Die funktionalen Eigenschaften beschreibendie Wirkung, nicht die Implementierung des Services, folglich wird hier dieGrenze zur Umgebung und nicht die Substruktur des Systems beschrieben.Neben der Festlegung von dem, was durchgefuhrt werden soll, wird auch derInformationsfluss fur den Service beschrieben. Services, die durch Menschendurchgefuhrt werden, wie z.B. Reinigung, Outsourcing oder Reparaturen, wer-den im Allgemeinen auch als manuelle Services oder Dienstleistungen bezeich-net. Fur die manuellen Services sind wir in den meisten Fallen gewohnt, auskultureller Erfahrung die Funktion implizit zu definieren. Oft werden Serviceund Berufsbezeichnung13 austauschbar genutzt, und andere Services und de-ren Berufsbezeichnungen sind schon fast vollstandig verschwunden14. Bei die-sen Services herrscht eine kulturelle Ubereinkunft von dem, was auszufuhrenund zu liefern ist. Eventuelle Details uber die funktionale Definition dieser Ser-vices aus juristischer Sicht erfahren wir erst im Konfliktfall mit dem jeweiligenServiceprovider (Handwerker) oder beim Lesen der allgemeinen Geschaftsbe-dingungen.

Bei manuellen Services gestaltet sich der Informationsfluss in Form ei-nes Dialogs zwischen dem Kunden (Serviceconsumer) und dem ”Handwer-ker“ (Serviceprovider). Die starke menschliche Verflechtung und das iterativeVerhalten aller Beteiligten ermoglicht es, dass sich diese Services auf diverseKontexte einstellen konnen.15

Im Fall von Software werden die funktionalen Eigenschaften von Servicesdurch Interfaces (Schnittstellen), sowie den Vor- und Nachbedingungen spe-zifiziert. Services in der Software erzeugen ein eindeutiges syntaktisches Ver-halten auf Grund der Tatsache, dass die genutzten Programmiersprachen An-forderungen an den Typ der Information in Form von Datentypen stellen, imGegensatz zu manuellen Services.

3.2.2 Nichtfunktionale Eigenschaften

Eine Servicebeschreibung besteht neben der Funktionalitat des Services auchaus der Beschreibung der nichtfunktionalen Eigenschaften. Speziell das Fehlenvon Beschreibungen nichtfunktionaler Eigenschaften verhindert eine ”vernunf-tige“ Suche und Entdeckung von Services. Sinnvolle nichtfunktionale Eigen-schaften fur einen Service sind:

• Name des Providers – Provider mussen eine eindeutige und verifizierbare16

Identitat haben. Die logische Folge einer Identitat ist die Existenz eineseindeutigen Namens und die Zugehorigkeit zu einer Organisation.

12 Allerdings nur aus Sicht des Kunden.13 Heizungsbauer, Maurer. . .14 Kesselflicken, Hochzeitsladen, Dengeln. . .15 Viable System Services sind der Versuch, diese Flexibilitat auch auf Software zu

ubertragen, s. Abschn. 12.1.16 Die Verifikation kann auch uber Dritte, so z.B. Trustcenter, erfolgen.

20 3 Serviceorientierungsparadigma

• Zeit – Angaben uber die Servicezeiten oder auch Wochentage sind wichtigeGroßen fur den Consumer.17

• Ort – Obwohl es in den meisten Fallen transparent sein sollte, wo derService tatsachlich ausgefuhrt wird, kann der Ausfuhrungsort bezuglichrechtlicher Belange oder Sicherheitsaspekte durchaus relevant sein. Beinicht-IT-basierten Services kann es durchaus sein, dass der Service nur aneinem bestimmten Ort durchgefuhrt werden kann oder darf.Neben den klassischen Formen der Ortsangabe konnen Telephonnummernoder URI-Adressen bei SLA-Verletzungen Kontakte und Moglichkeitenzum Ausweichen anbieten.

• Verfugbarkeit – Unter Verfugbarkeit versteht man die Kombination ausden zeitlichen und ortlichen Aspekten der Services.

• Obligation – Stellt die Verpflichtungen von Provider und Consumer dar.• Preis – Neben dem Preis pro Serviceaufruf sind auch andere Formen von

Preismodellen moglich:– Flat Rate,– Bulk Rate,– Prime Rate.

• Zahlungsmodalitaten – Analog zum Preis der Services kann auch die Artund Weise der Zahlung relevant sein.

• Strafen – Werden Zahlungsmodalitaten oder Obligationen verletzt, so tre-ten die entsprechenden Strafen ein.

• Sprache.• Qualitat des Services (s. Abschn. 5.6).• Sicherheit.

Fur die Serviceconsumer sind die funktionalen und nichtfunktionalen Eigen-schaften von Services zum Teil nicht voneinander unterscheidbar, insofern isteine solche Unterteilung bis zu einem gewissen Grad willkurlich. Je bekannterund standardisierter die funktionalen Eigenschaften von Services sind, destostarker rucken die nichtfunktionalen Eigenschaften bei der Entscheidung desKunden fur einen spezifischen Serviceprovider in den Vordergrund.

3.3 Enterprise Architekturen

Was bedeutet es, eine Serviceorientierung zu haben? Oder ist eine ServiceOriented Architecture die Antwort auf alle Fragen? Um die Auswirkungendes Serviceorientierungsparadigmas auf die Architektur einer Organisationund einer Software beurteilen zu konnen sollte man versuchen, die Serviceori-entierung mit Hilfe von ”klassischen“ Architekturframeworks zu beschreiben.

Die Architektur ist die abstrakte Struktur einer Aktivitat. Die hier genutz-te Definition des Begriffs Architektur ist:17 Der Service Personentransport der Deutschen Bahn kennt Wochen- und Feier-

tagsfahrplane.

3.4 Zachman-Framework 21

Eine Architektur ist eine formale Beschreibung eines Systems, ein de-taillierter Plan des Systems und seiner Komponenten, die Struktur derKomponenten, ihre Wechselwirkungen, ihre Prinzipien und Richtlini-en, die ihren Entwurf, ihre Entwicklung und Implementierung steuern.

Innerhalb von Organisationen konnen durchaus mehrere unterschiedlicheArchitekturen parallel zueinander existieren. Die diversen Sichten auf das Ge-samtsystem Organisation, Prozesse und Software werden in ihrer Gesamt-heit als Enterprise Architektur bezeichnet. Eine solche Enterprise Architekturuberspannt auch immer mehrere technische Systeme. Eines der Ziele hintereiner Enterprise Architektur ist es, ein moglichst hohes Maß an Alignmentzwischen den fachlichen Prozessen und Strukturen auf der einen Seite und derIT auf der anderen Seite zu erreichen. Eine Enterprise Architektur besteht inihrer Gesamtheit aus vier separaten Teilbereichen:

• Geschaftsprozessarchitektur,• Applikationsarchitektur,• Informationsarchitektur,• Technologiearchitektur.

Die vier Architekturkategorien werden stets gemeinsam betrachtet, da eineexplizite Separation fur eine ubergreifende Betrachtung nicht besonders sinn-voll erscheint. Die Abhangigkeiten und Wechselwirkungen dieser verschiede-nen Teile sind viel zu groß. Der Einsatz einer Enterprise Architektur un-terstutzt jede Organisation, welche auf Informationstechnologie angewiesenist, in hohem Maße. Innerhalb einer Enterprise Architektur gibt es keine effek-tiven Grenzen bezuglich der Fahigkeit zum Informationsaustausch zwischenverschiedenen Organisationsteilen.

Nicht nur die reine Geschaftsprozessarchitektur hat Auswirkungen auf dieApplikationsarchitektur, die Architektur in Organisationen ist auch immerein soziales Phanomen, denn Konflikte in der Architektur reprasentieren oftKonflikte zwischen unterschiedlichen sozialen Gruppen. Der Konflikt ist abernicht die Frage der reinen Zusammenarbeit auf Bitebene, sondern der Konfliktresultiert aus der unterschiedlichen Semantik, welche die Beteiligten anwen-den. Die entstandenen Architekturen spiegeln die Abhangigkeiten und Kon-flikte der verschiedenen Beteiligten wider. Umgekehrt kann Software aber auchKommunikationskanale aufbauen, die vorher nicht vorhanden waren, mit derFolge, dass es zu einer wechselseitigen Beeinflussung kommt.

3.4 Zachman-Framework

Das Konzept von Enterprise Architekturen geht zuruck auf die achtziger Jah-re des letzten Jahrhunderts. Einer der fuhrenden Kopfe der Architekturbewe-gung, John Zachman, erkannte den Wert der Nutzung einer abstrakten Ar-chitektur fur die Integration von Systemen und ihrer Komponenten. Zachman