Service-orientierte Architektur (SOA) - Identifizierung äquivalenter Services in Form semantischer semiautomatischer Unterstützung des EMEO-Layers

Inhaltsverzeichnis

1 Einleitung
1.1 Problemstellung und Ziel der Arbeit
1.2 Lösungsansatz
1.3 Aufbau der Arbeit

2 Grundlagen
2.1 Service-orientierte Architektur
2.1.1 Ziele einer SOA
2.1.2 Gestaltungsprinzip der losen Kopplung
2.1.3 Generisches Modell (logische Sicht)
2.1.4 Architektur integrierter Informationssysteme
2.1.5 Business Process Execution Language (BPEL)
2.1.6 Web Service
2.1.7 Enterprise Service Bus (ESB)
2.1.8 Enterprise Service Repository (ESR)
2.1.9 Service-Portfolio-Management
2.2 Entwurfsmuster Mediator
2.3 Semantische Web Services
2.3.1 Ontologien
2.3.2 Web Ontology Language (OWL)
2.3.3 Web Service Modeling Ontology (WSMO)
2.3.4 Semantic Markup for Web Services (OWL-S)
2.3.5 Web Service Semantics (WSDL-S)
2.3.6 Semantische Konzepte in einer SOA
2.4 Stand der Wissenschaft

3 Bestellanforderung (normalverfügbar)
3.1 Fachlicher Kontext Bestellanforderung (BANF)
3.2 Durchgängige Realisierung (Prototyp)
3.2.1 Ebene Geschäftsprozess-Modellierung
3.2.2 Ebene Software-Entwicklung
3.2.3 Realisierung im WebSphere Integration Developer
3.3 Abgeleitete generische Vorgehensweise TD+

4 Auftragsplanung Getriebe (höchstverfügbar)
4.1 Fachlicher Kontext Auftragsplanung Getriebe
4.1.1 Prozess Auftragsplanung Getriebe durchführen
4.1.2 Funktion Vorlaufrechnung Montage
4.2 Umsetzung der Top-Down-Vorgehensweise TD+

5 Vorteile und Grenzen

6 EMEO-Layer: Konzeption und Architektur
6.1 Entwicklung und Deployment
6.2 Architektur Semantik-Service-Finder (SSF)
6.3 Anreicherung semantischer Informationen
6.4 Semantik-Service-Finder (SSF-Algorithmus)
6.5 Verhalten bei Unverfügbarkeit
6.6 Domänenspezifische Ontologie
6.7 Verfügbarkeit der Service-Provider durch Redundanz

7 EMEO-Layer: Validierung
7.1 Anreicherung semantischer Informationen
7.1.1 MAS PLUS
7.1.2 BZM
7.1.3 Gegenüberstellung der Serviceoperationen
7.2 Ansatz zur domänenspezifischen Ontologie
7.2.1 Relationen.
7.2.2 Das abstrakte Konzept CommonThing
7.2.3 Das abstrakte Konzept AutomotiveThing
7.2.4 Das abstrakte Konzept DaimlerThing
7.2.5 Implementierung.
7.3 Mediator prototypisch in Java
7.4 Semantik-Service-Finder (SSF) in Java
7.5 Mediator im Enterprise Service Bus
7.6 Abgeleitete generische Vorgehensweise TD++
7.7 Nachweis verbesserter Verfügbarkeit

8 Fazit
8.1 Schlussfolgerungen
8.1.1 Kernelemente
8.1.2 Unterstützende Elemente
8.1.3 Entwicklungs- und Ablaufumgebung
8.2 Vor- und Nachteile
8.3 Zusammenfassung und Ausblick

Akronyme

Abbildungsverzeichnis

Tabellenverzeichnis

A Publikationen

B Inhaltsübersicht der beiliegenden CD

C Funktionalen Anforderungen an ein ESR

D ARIS-Haus

E Service-Portfolio-Management
E.1 Rollen
E.2 Applikationsbeschreibung.
E.3 Servicebeschreibung
E.4 Operationsbeschreibung

F Global-Datatypes (GDT)

G On-To-Knowledge

H SLK in OWL

I Bestellanforderung (BANF)

J ÜbersichtPowertrain

K Entwurfsmuster Mediator
K.1 Klasse Widget.java
K.2 Klasse WidgetBZM.java .
K.3 Klasse WidgetMASPlus.java
K.4 Klasse Mediator.java.
K.5 Klasse Main.java
K.6 Klasse JxFrame.java.

L Semantik-Service-Finder
L.1 Klasse Main.java
L.2 Klasse ESRServices.java .
L.3 Klasse RankServices.java .
L.4 Inferenz in Protégé

M SSF Konsolenausgabe

N Ontologie in OWL

O Exemplarische Implementierung
O.1 WebSphere Service Registry und Repository
O.2 WebSphere Integration Developer

P Service-Provider (WSDL-S)
P.1 MASPlus.wsdl
P.2 BZM.wsdl.

Kapitel 1 Einleitung

Die Service-orientierte Architektur (SOA) beschreibt ein Architekturmodell bzw. eine Software-Infrastruktur, in der die wesentlichen fachlichen Funktionen einer IT-Anwendung als Service repräsentiert werden. Kennzeichnend sind hier granu- lare und wiederverwendbare Services, die in neue Anwendungen integriert werden können. Zudem bestehen die Möglichkeiten, laufende Anwendungen durch den Aus- tausch einzelner Services anzupassen, zu erweitern und zu optimieren. Zwingen- de Abhängigkeiten der monolithischen Architekturen zwischen bestimmten Client- Serverarchitekturen sind damit aufgelöst. In dieser Dissertation werden innovative und zukunftsweisende Möglichkeiten Softwarelösungen zu entwickeln dargestellt. Basierend auf den Prinzipien einer SOA wird, mit Blick auf ein internationales Un- ternehmen, eine Implementierung dieses neuen Architekturmodells in der Domäne Automotive bei der Daimler AG vorgestellt.

1.1 Problemstellung und Ziel der Arbeit

Die verteilte Steuerung der Prozessabläufe setzt die Notwendigkeit menschlichen Eingreifens durch Know-how-Träger an den IT-Systemgrenzen voraus. Die dadurch potentiell entstehenden Gefahrenquellen sind auf Übertragungsfehler an den IT- Systemgrenzen sowie (in manchen Fällen) auf Unverfügbarkeit der Wissensträger zurückzuführen. Durch Anwendung der Konzepte einer SOA wird die Steuerung der Prozessabläufe zentralisiert. Somit werden die potentiellen Gefahrenquellen, wie Übertragungsfehler an den IT-Systemgrenzen und die Unverfügbarkeit der Wis- sensträger eliminiert. Die quasi-statische Bindung zwischen den einzelnen Prozess- schritten und den potentiellen Service-Providern ermöglicht eine partielle Ermitt- lung (IP-Adresse, Protokoll und Port) des Service-Endpunkts in der Ablaufum- gebung und mangelt somit an einer flexiblen Schnittstellenverarbeitung bei einer möglicher Unverfügbarkeit der Service-Provider.

Diese Arbeit zeigt die heutigen Realisierungsmöglichkeiten in Form einer durch- gängigen Top-Down-Vorgehensweise auf und schlägt den EMEO-Layer als einen semiautomatischen Ansatz zur Findung äquivalenter Services (Kandidaten) in der Entwicklungsumgebung vor. Schnittstellenbeschreibungen äquivalenter Services werden auf die Geschäftsobjekte abgebildet und mit der Mediation verbunden. In der Ablaufumgebung ermöglicht die Lookup-Komponente eine Ermittlung des Service- Endpunktes in Form IP-Adresse, Protokoll und Port. Durch die Mediation werden die bereits bestimmten Schnittstellenbeschreibungen gebunden und ausgeführt. Die redundante Industrialisierung der Services wird genutzt, um die Verfügbarkeit der Prozessabläufe bei geplanter Ausfallzeit zu erhöhen. Technisch wurde der EMEO- Layer durch die semantische Anreicherung der plattformneutralen Servicebeschrei- bung, der Mediation im Enterprise Service Bus und der partiellen Implementierung semantischer Konzepte validiert.

1.2 Lösungsansatz

Initiativen wie Bottom-Up Approach [93], Template Based Composition [147], OWL- S Composition Approach [146], SHOP2 [148], METEOR-S [2], SEMAPLAN [5] und WSMO Approach [144], basierend auf den semantischen Konzepten OWL-S [95], WSDL-S [4] und WMSO [126], forschen an einer loseren Kopplung zwischen den fachlichen Funktionen und der technischen Ausführung. Die beiden Initiativen SWORD [121] und Plængine [99] basieren nicht auf den semantischen Konzepten OWL-S, WSDL-S und WSMO. Die Grundlage von SWORD ist unabhängig von semantischen Konzepten und Plængine basiert auf einem integrierten Meta-Modell. Ziel aller aufgeführten Initiativen ist die Anreicherung der Services mit semantischen Informationen um die dynamische Einbindung von Services (in einen Prozess) in der Ablaufumgebung zu ermöglichen. Die Dissertation von Muhammad Ahtisham Aslam [3] unterstützt dieses Ziel durch das Abbilden technischer Aktivitäten auf semantische Konzepte in OWL-S in der Entwicklungsumgebung.

Der EMEO-Layer, gebildet aus Enterprise Service Bus (ESB), Mediation, Enter- prise Service Repository (ESR) und Ontologien, definiert eine logische Schicht (engl. Layer) zur Identifizierung äquivalenter Services (Kandidaten) durch semantische semiautomatische Unterstützung in einer Service-orientierten Architektur. Durch die Einbindung der Konzepte einer SOA (ESB, ESR) in Kombination mit einem Entwurfsmuster aus der Objekt-orientierten Programmierung Mediation und On- tologien stellt der EMEO-Layer einen nicht erforschten neuen Ansatz dar.

Der EMEO-Layer basiert, wie METEOR-S und SEMAPLAN, auf dem seman- tischen Konzept WSDL-S, grenzt sich jedoch durch die konzeptuelle Integration des semiautomatischen Ansatzes in die Konzepte ESB und ESR sowie durch ei- ne prototypische Implementierung in der Domäne Automotive von diesen ab. Der EMEO-Layer unterstützt keine nicht-funktionalen Anforderungen wie bspw. Ant- wortzeiten, geografische Lokationen etc., sondern Funktionen und Geschäftsobjekte der Funktionen (funktionale Anforderungen). Funktionen werden auf Serviceope- rationen, Vor- (P) und Nachbedingung (E) auf semantische Konzepte abgebildet. Geschäftsobjekte sind die Eingabe- (I) und Ausgabeparameter (O) der Funktion und somit der Serviceoperation. Serviceoperationen werden ebenfalls auf semanti- sche Konzepte abgebildet. Die funktionalen Anforderungen Eingabe- und Ausgabe-parameter sowie Vor- und Nachbedingung werden in dieser Arbeit als IOPE (engl. Input, Output, Precondition, Effect) bezeichnet. Die Arbeit findet ihre Anwendung in der Problemklasse plattformübergreifender Prozesse der Domäne Automotive unter der Randbedingung der Verfügbarkeitsklasse XH (höchstverfügbar).

1.3 Aufbau der Arbeit

In der vorliegenden Arbeit werden in Kapitel 2 die Grundlagen der Service-orien- tierten Architektur sowie Ontologien und semantische Konzepte als Basis zur Er- mittlung äquivalenter Services (Kandidaten) im EMEO-Layer vorgestellt. Metho- den wie die Architektur integrierter Informationssysteme, Technologien wie Web Services, Business Process Execution Language und Web Ontology Language sowie das Entwurfsmuster Mediator, die in den nächsten Kapiteln Verwendung finden, werden kurz zusammengefasst.

Die notwendigen fachlichen Anforderungen und Randbedingungen zur Anwendung der theoretischen Grundlagen in einer Service-orientierten Architektur werden in Kapitel 3 beschrieben. Hier werden der fachliche Prozess Bestellanforderung der Verfügbarkeitsklasse N (normalverfügbar), die durchgängige Realisierung, begon- nen bei der Modellierung bis hin zum ablauffähigen Prototyp sowie die abgeleitete generische Top-Down-Vorgehensweise (hier als TD+ bezeichnet) dokumentiert.

Die Erhöhung der Verfügbarkeitsklasse N (normalverfügbar) auf die höchste Verfüg- barkeitsklasse XH (höchstverfügbar) stellt eine Erweiterung der nicht funktionalen Anforderung dar. Kapitel 4 beschreibt einen neuen fachlichen Prozess der höchsten Verfügbarkeitsklasse XH (höchstverfügbar), die erneute Anwendung der Top-Down- Vorgehensweise TD+ und die Ergänzung um die Lookup-Komponente im Enterprise Service Bus.

In Kapitel 5 werden die Vorteile und Grenzen einer Service-orientierten Archi- tektur unter der Randbedingung der Verfügbarkeitsklasse XH in Kombination mit geplanter Unverfügbarkeit der Service-Provider erörtert. Dabei wurde die quasi- statische Bindung zwischen den einzelnen Prozessschritten und den potentiellen Service-Providern als zentrales Problem bei geplanter Ausfallzeit der Service-Provi- der identifiziert.

In dieser Arbeit wird in Kapitel 6 der EMEO-Layer vorgeschlagen, um durch einen semantischen semiautomatischen Ansatz (in der Entwicklungsumgebung) die Defizite der Service-orientierten Architektur bei geplanter Unverfügbarkeit der ServiceProvider zu lösen. Der EMEO-Layer ersetzt die quasi-statische Bindung zwischen den einzelnen Prozessschritten und den potentiellen Service-Providern (ServiceEndpunkte) durch eine flexible Schnittstellenverarbeitung.

Die Validierung des EMEO-Layers wird in Kapitel 7 illustriert. Zur Validierung wird das notwendige exemplarische Szenario und ein lauffähiger Prototyp vorgestellt. Das Szenario besteht aus zwei (Anreicherung der Services und Externalisierung des Know-hows) und der Prototyp aus drei Teilelementen (Mediator in Java, Algorithmus Semantik-Service-Finder und Ablaufumgebung).

In Kapitel 8 werden kausale Schlussfolgerungen abgeleitet sowie die Kernelemente des EMEO-Layers Mediation, Enterprise Service Bus, Enterprise Service Repository und Ontologien zusammengefasst. Der Ausblick zeigt weitere mögliche Entwicklungen auf Basis des EMEO-Layers auf.

Im Anhang werden Publikationen, fachliche Anforderungen, der Quell-Code der Prototypen, ein SLK in OWL, die komplette Ontologie in OWL und die Anreicherung semantischer Informationen der Service-Provider abgebildet.

2.1 Service-orientierte Architektur

Die Service-orientierte Architektur (SOA) beschreibt ein Architekturmodell bzw. eine Software-Infrastruktur, in der die wesentlichen fachlichen Funktionen einer ITAnwendung als Service repräsentiert werden. Kennzeichnend sind hier granulare wiederverwendbare Services, die in neue Anwendungen integriert werden können. Somit ist die SOA ein technologieneutrales Architekturkonzept basierend auf allgemein verwendbaren bzw. wiederverwendbaren Services.

In der Literatur wird die Service-orientierte Architektur nicht eindeutig definiert. Bieberstein definiert die Service-orientierte Architektur als einen Satz von Methoden zur Reduzierung bzw. Eliminierung der Enttäuschungen durch die Informations- technologie (IT), eine Messgröße zur Quantifizierung des Unternehmenswert der IT und eine agile, wettbewerbsfähige Geschäftsumgebung:

”Asetofbusiness,process, organizational, governance, and technical methods to reduce or eliminate frustrati- ons with IT and to quantifiably measure the business value of IT while creating an agile business environment for competitive advantage“ [16]. Die Definition von Erl basiert auf der Implementierung der Technologie Web Service (siehe Kapitel 2.1.6 auf Seite 27) und definiert technische Eigenschaften wie Offenheit, Erweiterbarkeit,

Interoperabilität sowie die Möglichkeit zur Wiederverwendung von Services:

”Con- temporary SOA represents an open, extensible, federated, composable architecture that promotes services-orientation and is comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reusable services, im- plemented as Web services“ [42]. Krafzig definiert die Service-orientierte Architek- tur als Software-Architektur basierend auf den Schlüsselkonzepten: Repräsentie- rung der Anwendung, Service, Service Repository sowie Servicebus. Er definiert den Service bestehend aus Vertrag, einer oder mehreren Schnittstellen und seiner Implementierung: ”AService-OrientedArchitectureisasoftwarearchitecturethatis based on the key concepts of an application frontend, service, service reposito- ry, and service bus. A service consists of a contract, one or more interfaces, and an implementation“ [89]. Das World Wide Web Consortium (W3C) definiert die Service-orientierte Architektur als eine Menge von Komponenten, die aufgerufen und deren Schnittstellenbeschreibung veröffentlicht und entdeckt werden können: ”AService-OrientedArchitectureisasetofcomponentswhichcanbeinvoked,and whose interface descriptions can be published and discovered“ [164]. Gartner definiert die Service-orientierte Architektur als Software-Architektur bestehend aus ei- ner Struktur von Schnittstellen, Implementierungen der Schnittstellen und Aufrufe der Schnittstellen sowie die Beziehung zwischen Service und Service-Consumer, die beide die Größe einer kompletten Geschäftsfunktion besitzen. Somit handelt es sich bei der Service-orientierte Architektur um Wiederverwendung, Kapselung, Schnittstellen und schließlich um Agilität:

”SOAisasoftwarearchitecturethatbuildsa topology of interfaces, interface implementations and interface calls. SOA is a re- lationship of services and service consumers, both software modules large enough to represent a complete business function. So, SOA is about reuse, encapsulation, interfaces, and ultimately, agility“ [97]. Software-Architekten und Forscher haben gemeinsam eine Definition als Richtlinie für die Daimler AG erstellt. Somit wird in der Daimler AG die Service-orientierte Architektur wie folgt verstanden:

Definition 1 Eine Service-orientierte Architektur (SOA) beschreibt ein technologieneutrales Architekturkonzept basierend auf allgemeingültigen (wieder-)ver- wendbaren Services. Dieses Konzept der Software-Architektur repräsentiert eine oder mehrere Geschäftsfunktionen als Service. Die Beschreibung der Service-Schnitt- stelle ist plattformneutral. Service-Implementierungen sind wiederverwendbar, gekapselt und lose gekoppelt. Die Kommunikation mit den Services wird über eine standardisierte Infrastruktur realisiert [67].

In der Literatur sowie in zahlreichen Praxisberichten wird die Service-orientierte Architektur mit der Technologie Web Service gleich gesetzt. Das aktuell abgeschlos- sene Forschungsprojekt der Daimler AG distanziert sich von der Gleichstellung der SOA mit der Technologie Web Services; es hebt aber Web Services als signifikante Technologie zur Realisierung einer SOA hervor (siehe Kapitel 2.1.6 auf Seite 27).

In diesem Forschungsprojekt wurden die Grundlagen der Service-orientierten Ar- chitektur erarbeitet. Gemeinsam mit den internationalen Unternehmen IDS Scheer AG, SAP AG und IBM Deutschland GmbH wurden vier SOA-Dimensionen (siehe Abbildung 2.1 auf Seite 17), ein internes Reifegradmodell (engl. maturity model) und die SOA-Roadmap beschrieben. Die Konzepte Enterprise Service Bus (siehe Kapitel 2.1.7 auf Seite 32) und Enterprise Service Repository (siehe Kapitel 2.1.8 auf Seite 34) wurden basierend auf dem generischen Modell (siehe Kapitel 2.1.3 auf Seite 22) definiert. Eine Aussage, bezogen auf die Anwendung der Konzepte einer SOA in einem Unternehmen, hat keinen booleschen Charakter. Somit besteht ein Bedarf zur Definition eines Reifegradmodells.

Hierzu wurde in Analogie zum Capability Maturity Model Integration (CM- MI) [77] ein Reifegradmodell erstellt, das sich dem SOA Maturity Model (SOA MM) [150] der Sonic Software stark ähnelt. Ziel des Reifegradmodells und der SOA-Roadmap ist es nicht, die höchste Stufe zu erreichern, sondern die internen Aufwände und Effekte der SOA-Initiative jederzeit ermitteln zu können. Das Rei- fegradmodell definiert sechs Stufen (Stufe 0 bis Stufe 5), den erwarteten Effekt

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Die SOA-Dimensionen auf Seiten der IT und auf Seiten des Fachbereichs. So definiert bspw. die Stufe 3 gemeinsam genutzte fachliche Services auf Seite der IT sowie die fachliche Wieder- verwendung der Services und eine fachliche Governance auf Seite des Fachbereichs. Die definierte SOA-Roadmap basiert auf einer Matrix, in der die SOA-Dimensionen die X-Achse und das interne Reifegradmodell die Y-Achse darstellen. Die SOA- Roadmap skizziert Maßnahmen in allen vier SOA-Dimensionen, um den geplanten Reifegrad zu erreichen. Das Reifegradmodell sowie die SOA-Roadmap sind als ver- traulich eingestuft und werden somit in der vorliegenden Arbeit nicht näher be- schrieben. Die vier SOA-Dimensionen werden in Abbildung 2.1 illustriert und im Folgenden erläutert:

- Die erste Dimension Organisation / Steuerung / Governance, im Folgenden als Governance bezeichnet, betrachtet das Service-Portfolio-Management (sie- he Kapitel 2.1.9 auf Seite 35), das Service-Lebenszyklus-Management, die Geschäftsdomänenstruktur, die Einhaltung der Vorgaben (engl. Compliance), das SOA-Bewusstsein (engl. SOA-Awareness), Key Performance Indikatoren (KPI’s), Verrechnungsmodelle sowie Budget- und Ressourcenzuteilung.
- Die zweite Dimension Methoden / Vorgehensmodelle betrachtet die Verwal- tung des Enterprise Service Repository’s, die Orchestrierung der Services und Prozesse, Methoden zur Fachklassen- und Servicemodellierung, die Service beschreibung, Business Process Management (BPM) und Business Activity Monitoring (BAM), Ablagestrukturen sowie ein Konzept zur Geschäftsprozessmodellierung.
- Die dritte Dimension Architektur / Technologie betrachtet die Implementie- rung eines Enterprise Service Repository’s, eine Security-Infrastruktur, die technische Service-Architektur, ein technisches SOA-Rahmenwerk (engl. SOA- Framework) sowie die Workflow-Engines.
- Die vierte und letzte Dimension Geschäftsprozesse betrachtet die Ableitung der Fachklassen und Services aus Domänen und Prozessen, den IT-Bebauungs- plan, Optimierungen der Prozessmodelle, domänenübergreifende Prozessmo-delle und das fachliche KPI-Monitoring.

Alle vier Dimensionen basieren auf dem Fundament der Standards. Dabei kon- zentriert sich das Unternehmen Daimler AG auf die Schnittmenge der Standards aller strategischen Lieferanten. Der Tenor dieser Arbeit liegt im Aufzeigen der heu- tigen Realisierungsmöglichkeiten einer SOA in einem internationalen Unternehmen der Domäne Automotive und fokussiert die SOA-Dimension Architektur/Technologie.

2.1.1 Ziele einer SOA

Die Globalisierung der Unternehmen ist geprägt durch permanente Marktverände- rungen und unterliegt einem starken Kostendruck. Heterogene IT-Landschaften bil- den sich u.a. durch Fusionen und Übernahmen (engl. Mergers and Acquisitions) sowie durch historisch wachsende Unternehmen [16]. Charakterisierend für hete- rogene IT-Landschaften sind bspw. COBOL-Anwendungen (engl. Legacy-Systeme), J2EE-Anwendungen und EAI-Lösungen [89]. Permanente Veränderungen am Markt erfordern eine höhere Flexibilität der IT-Landschaften sowie ein verbessertes

”Time- to-Market“-Verhalten der Unternehmen. Die aktuelle Studie Geschäftsmodelle[2010]

Services) [139]. Das Gestaltungsprinzip der losen Kopplung findet Anwendung im EMEO-Layer (siehe Kapitel 6 auf Seite 85) und wird im Folgenden diskutiert. Die lo- se Kopplung kann auf fachlicher und technischer Ebene stattfinden. Bspw. kann ein Geschäftsobjekt Adresse, im Gegensatz zur technischen Definition mit Integer und String, durch die fachlichen Eigenschaften Straße, Hausnummer, Postleitzahl und Ort definiert werden. Woods versteht die Abbildung der Services mit Blackbox- Charakter als lose Kopplung, da die Implementierung für den Service-Consumer, solange die fachlichen und technischen Anforderungen erfüllt werden, eine unter- geordnete Rolle spielt [171]. Erl versteht die Abstraktion der zu Grunde liegenden Implementierung auf die Serviceoperation der Serviceschnittstelle als feste vertrag- liche Bindung zwischen Provider und Consumer, aber technisch als lose Kopplung zwischen bereitstellendem und aufrufendem IT-System [42].

Bieberstein unterscheidet zwischen den beiden Gestaltungsprinzipien: loser Kopplung und Bindekraft (engl. cohesion). Die Faktoren Zeit (engl. time), Protokoll (engl. protocol), Datenformat (engl. format), Vertrag (engl. contract), Programmiersprache (engl. language), Plattform (engl. platform) und Standort (engl. location) (in zufälliger Reihenfolge) werden dem Gestaltungsprinzip der losen Kopplung zugeordnet. Datentypen (engl. types), Datenstruktur (engl. structure), Verbindungen (engl. relationships), Logik (engl. logic) und Vertrauen (engl. trust) (mit steigender Bindekraft) werden der Bindekraft zugeordnet[16].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Lose Kopplung nach Krafzig[89]und Josuttis[79]

Krafzig grenzt die Ebenen physikalische Verbindung (engl. physical connection), Kommunikationsart (engl. communication style), Kommunikationsformat (engl. ty- pe system), Interaktionsverhaltensmuster (engl. interaction pattern), Kontrolle der Prozesslogik (engl. control of process logic), Service-Bindung (engl. binding) und Plattform (engl. platform) zwischen fester und loser Kopplung voneinander ab [89]. Josuttis erweitert die Abgrenzung von Krafzig um die Ebenen Datenmodell (engl. data model), Transaktionsverhalten (engl. transactionality), Auslieferung (engl. de- ployment) sowie Versionsverwaltung (engl. versioning) (ohne Anspruch auf Voll- ständigkeit) [79] und wird in Tabelle 2.1 auf Seite 19 illustriert.

Auf der Ebene der physikalischen Verbindung wird die Punkt-zu-Punkt -Verbin- dung als feste und die Mediation (siehe Kapitel 2.9 auf Seite 38) als lose Kopp- lung verstanden. Punkt-zu-Punkt bezeichnet den direkten Aufruf der physikalischen Adresse des Services und somit den Service-Endpunkt (siehe Kapitel 2.1.6 auf Seite 30). Josuttis unterscheidet zwischen den zwei Arten der Ermittlung des Service- Endpunktes: vor dem Senden des Aufrufs und nach dem Senden des Aufrufs. Die erste Art wird funktional als Broker bezeichnet, die zweite nutzt symbolische Na- men, um bspw. im Enterprise Service Bus aufgrund technischer Anforderungen den symbolischen Namen durch den Service-Endpunkt zu ersetzen. Auf der Ebene Kom- munikationsart wird die synchrone Kommunikation als feste und die asynchrone Kommunikation als lose Kopplung verstanden. Bei der asynchronen Kommunikation ist, im Gegensatz zur synchronen Kommunikation, der Austausch von Nachrichten zwischen Provider und Consumer zeitunabhängig. Somit führt bei der asynchronen Kommunikation der Sender (Provider) seine Ablauflogik weiter aus, ohne auf eine mögliche Antwort des Empfängers (Consumer) zu warten. Im Gegensatz dazu war- tet bei der synchronen Kommunikation der Sender (Provider) auf eine Antwort und setzt nach Eingang mit seiner Ablauflogik fort [69]. Technisch kann die asynchrone Kommunikation der Nachrichten bspw. durch Warteschlangen (engl. Queues) mit MQSeries [166] realisiert werden. Die Mediation ist eine Form der losen Kopplung, hat ihren Ursprung in der Objekt-orientierten Programmierung und wird in Kapitel 2.9 auf Seite 38 ausführlich beschrieben.

Auf der Ebene Kommunikationsformat wird die technische Beschreibung als fes- te und die semantische Beschreibung als lose Kopplung verstanden. So kann bspw. die Operation einer Serviceschnittstelle durch die Signatur syntaktisch beschrieben werden. Durch explizite Datentypen der Ein- (I) und Ausgabeparameter (O) der Operation findet eine feste Kopplung zwischen Provider und Consumer statt. Im Gegensatz dazu stellt die Definition eines Datenaustauschformates auf syntaktischer und semantischer Ebene eine lose Kopplung zwischen Provider und Consumer dar. Ein weiteres Beispiel der festen bzw. losen Kopplung des Kommunikationsformates zwischen Provider und Consumer ist die Implementierung der Geschäftsobjekte. Die feste Kopplung definiert harmonisierte Geschäftsobjekte als Basis zur Kommu- nikation, die bei Bedarf erweitert werden. Die lose Kopplung dagegen bildet (engl. mapping) die heterogenen Geschäftsobjekte aufeinander ab.

Auf der Ebene Interaktionsverhaltensmuster wird die Navigation durch Ob- jektbäume (objektorientiert ) als feste und unabhängige Nachrichten (datenzentriert ) als lose Kopplung verstanden. In einer Infrastruktur verteilter Objekte wie bspw. der Common Object Request Broker Architecture (CORBA) [117], die einen Object Request Broker (ORB) als zentrale Komponente zum Datenaustausch vorsieht, wird u.a. das Serverobjekt aufgrund der angegebenen Objektreferenz lokalisiert, die Ein- gabeparameter an den Server übermittelt und die Rückgabeparamter an den Client zurückgeliefert [40]. Diese Interaktion zwischen verteilten Objekten impliziert die Navigation durch teilweise komplexe Objektbäume, eine adäquate Vorgehensweise bei der Navigation durch die Objektbäume und das Verständnis der logischen Struktur der Objekte. Die dadurch entstanden Abhängigkeiten werden als feste Kopplung zwischen Provider und Consumer verstanden.

Auf der Ebene Kontrolle der Prozesslogik wird die zentrale Steuerung als feste und die dezentrale Steuerung als lose Kopplung verstanden. Die zentrale Steuerung der Prozesslogik reduziert die Komplexität (bezogen auf Persistenz, Konsistenz etc.) und koppelt bspw. Unterprozesse fest aneinander. Die dezentrale Steuerung der Pro- zesslogik ermöglicht durch Ereignisse (engl. events) eine lose Kopplung, wie bspw. in einer Ereignisgesteuerten Architektur (engl. event-driven architecture (EDA)) zwischen den Unterprozessen, erschwert aber die Ermittlung eines definierten kon- sistenten Prozessstatus’.

Auf der Ebene der Service-Bindung wird die statische Bindung zwischen Provider und Consumer als feste und die dynamische Bindung als lose Kopplung verstanden. Die statische Bindung wird durch den direkten Aufruf des Service-Endpunkts realisiert. Die dynamische Bindung nutzt in der Entwicklungsumgebung symbolische Namen und ersetzt diese (in der Ablaufumgebung) durch die jeweils ermittelte Schnittstelle. Dabei werden die Einzelschritte: finden, auswählen, ggf. orchestrieren, binden und ausführen durchlaufen. Somit ist die dynamische Bindung eine Erweiterung der Mediation (physikalische Verbindung) und stellt einen hohen Grad einer loser Kopplung zwischen Provider und Consumer dar.

Auf der Ebene der Plattform wird die Verwendung spezifischer Datentypen als feste und die Verwendung neutraler Datentypen als lose Kopplung verstanden. Plattformspezifische Datentypen sind bspw. Blob (Binary Large Object) oder Packed Decimal, die Provider bzw. Consumer fest an die Plattform koppeln. Unter plattformneutralen Datentypen werden alle durch XML bereitgestellte Datentypen verstanden (vgl. Kapitel Abbildung der Datentypen auf Seite 31).

Auf der Ebene des Transaktionsverhaltens wird die Verwendung des Zwei-Phasen- Commits als feste und die Verwendung der Kompensation (engl. compensation) als lose Kopplung verstanden. Das Zwei-Phasen-Commit stellt die Transaktionssi- cherheit (atomar, konsistent, isoliert, dauerhaft (ACID)) über verteilte Ressourcen (bspw. Datenbanken) durch einen globalen Transaktionsmanager sicher und bindet somit fest. Die Kompensation definiert fachliche Undo-Operationen mit dem Ziel die vorangegangene Aktion oder Aktionen rückgängig zu machen. Der Mehrauf- wand durch die Implementierung der Undo-Operationen soll durch eine sinkende Latenzzeit beim Nachrichtenaustausch und eine höhere Flexibilität beim Zurück- setzen einer Teil-Transaktion kompensiert werden [151]. Die Ebenen Datenmodell, Auslieferung und Versionsverwaltung spielen eine untergeordnete Rollen und wer- den folglich nicht weiter diskutiert.

Somit konnten folgende Erkenntnisse des Gestaltungsprinzip der losen Kopplung in einer Service-orientierten Architektur identifiziert werden: Bei der losen Kopp- lung ist generell zwischen Entwicklungsumgebung und Ablaufumgebung zu unter- scheiden. Die lose Kopplung unterstützt die Flexibilität der Prozesse, findet auf technischer und fachlicher Ebene statt und muss mit Mehraufwand implementiert werden.

2.1.3 Generisches Modell (logische Sicht)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Generisches Modell (logische Sicht)

Abbildung 2.2 gibt ein generisches Modell einer SOA mit der Anpassung an die bei der Daimler AG vorhandenen strategischen Plattformen wieder. Es illustriert die lo- gische Sicht auf eine mögliche SOA-Landschaft. Die strategischen Plattformen sind SAP, J2EE/PAI, Host/Mainframe und .NET; wobei die Pro-Aktive-Infrastruktur (PAI) ein internes Projekt zur Integration der IBM-Produkte in die Security-Infra- struktur der Daimler AG darstellt. Der Infrastruktur Layer ist die logische Sicht auf Sicherheitsaspekte, wie bspw. Autorisierung, Authentifizierung, Verschlüsselung und Logging. Der plattform-spezifische Business Layer ist die logische Sicht auf plattformspezifsche Services, wie bspw. BAPI’s (Business Application Program- ming Interface). Der Enterprise Business Layer unterteilt sich in zwei Bereiche, den Prozessfluss im oberen und den plattformneutralen Bereich im unteren Teil. Der Prozessfluss-Bereich stellt die zentrale Steuerung ausführbarer Geschäftspro- zesse dar. Der plattformneutrale Bereich ist die logische Sicht auf plattformneutrale Services, wie bspw. Web Services (siehe Kapitel 2.1.6 auf Seite 27) beschrieben durch WSDL-Dateien. Der Präsentations-Layer stellt die grafische Benutzerober- fläche (Fat-Clients, Rich-Clients, Thin-Clients) dar und ist somit die für den An- wender sichtbare Repräsentation des abgebildeten fachlichen Prozesses. Die beiden letzten Bereiche, erweiterte Ereignisgesteuerte Prozessketten und Wertschöpfungs- kettendiagramme, bilden den Bereich der fachlichen Anforderungen durch das Do- mänenmodell und grafisch modellierte Kernprozesse der Daimler AG ab.

Die Diskussion über die Darstellung der Prozessabläufe in Petri-Netzen [122] oder in der Unified Modeling Language (UML) [112] ist nach Meinung des Verfassers obsolet, da die Durchdringung der eEPK-Methode (erweiterte Ereignisgesteuerte Prozessketten) im Fachbereich signifikant ist.

2.1.4 Architektur integrierter InformationssystemeARIS-Haus

Architektur integrierter Informationssysteme (ARIS) [133] wurde von Scheer in den neunziger Jahren theoretisch erarbeitet. Seit 1993 wird das ARIS-Konzept durch mehrere Tools praxisnah unterstützt. Das ARIS-Haus im Anhang D auf Seite 157 stellt die unterschiedlichen Sichten (Daten-, Steuerung-, Funktion- und Organisati- onssicht) auf eine betriebswirtschaftliche Problemstellung dar. Jede dieser Sichten besteht aus dem Fachkonzept, dem DV-Konzept und der Implementierung. Gene- rell können diese Sichten in Detaillierungsgrade unterteilt werden. Abhängig von der Sicht werden passende Modellierungsmethoden empfohlen. Bspw. für die Datensicht das Entity-Relationship-Modell (ERM), für die Steuerungssicht die erweiterte Ereig- nisgesteuerte Prozessketten (eEPK) und für die Funktionssicht der Funktionsbaum. Ein Wertschöpfungskettendiagramm (WKD) stellt Prozesse der strategischen oder oberen Unternehmensebenen dar. Ein Modell wird als Abbildung der betriebswirt- schaftlichen Realität verstanden und besteht im Wesentlichen aus den Merkmalen: Funktion, Daten, Organisationseinheit, Ereignis, Ressource und Leistung. Scheer definiert einen Geschäftsprozess als ”...die AbfolgevonFunktionen,diezusammen- genommen ein Produkt und/oder eine Dienstleistung für einen internen oder ex- ternen Kunden schaffen“ [133]. Somit wird aus Kundensicht eine Wertsteigerung erzeugt.

Erweiterte Ereignisgesteuerte Prozessketten (eEPK)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Übersicht der eEPK-Symbole

Folgend werden die für diese Arbeit relevanten Symbole (siehe Abbildung 2.3) einer Erweiterte Ereignisgesteuerte Prozessketten (eEPK) zur grafischen Abbildung von Prozessen, wie Geschäftsobjekt, Web Service, Ereignis, Funktion, Organisationseinheit und Kanten bzw. gerichtete Kanten, näher beschrieben.

Geschäftsobjekt. Geschäftsobjekte (engl. business objects) stellen die logische Sicht auf eine Menge von Daten (Cluster) in einem Datenmodell dar. Somit kann jede Art von Information durch ein Geschäftsobjekt wie bspw. Dokumente, Eingaben, Ausgaben etc. beschrieben werden. In dieser Arbeit symbolisiert das Geschäftsobjekt die Ein- (I) bzw. Ausgaben (O) einer oder mehrerer Funktionen.

Web Service. In der aktuellen Version der ARIS-Methode eEPK existieren mehrere Symbole, um die Implementierung einer Funktion durch einen Web Service auszudrücken. Die Abbildung 2.3 auf Seite 23 bildet das in dieser Arbeit verwendete Symbol ab. In Kombination mit dem Symbol einer Funktion drückt das Symbol Web Service die Ausführung der Funktion aus.

Funktion. Funktionen werden als Aufgaben (engl. tasks) verstanden, die eine körperliche oder geistige Aktivität darstellen. Modelle in der ARIS-Methode eEPK legen ihren Fokus auf die Dokumentation des Prozessziels. Im Gegensatz dazu wird in dieser Arbeit die Beschreibung des Prozessverhaltens fokussiert. Eine Funktion repräsentiert eine Aktivität, die Ein- (I) und Ausgabeparameter (O), die ggf. trans- formiert und verarbeitet werden müssen. Funktionen können solange gesplittet wer- den, bis der Fachbereich die Funktion als Aktivität wahrnimmt.

Ereignis. Ein Ereignis symbolisiert das Eintreten einer bestimmten Bedingung oder das Erreichen eines bestimmten Status. Ereignisse können Funktionen auslösen oder durch Funktionen ausgelöst werden. In dieser Arbeit wird das Ereignis zur Bestimmung der Vor- (P) und Nachbedingungen (E) einer Funktion genutzt.

Organisationseinheit. Die Organisationseinheit ist symbolierend für eine bestimmte Menge der aktuellen Mitarbeiter im Unternehmen und kann eine notwendige menschliche Handlung ausdrücken.

Kante. Eine Kante verbindet Geschäftsobjekte, Ereignisse, Funktionen, Web Ser- vices und Organisationseinheiten miteinander. Eine spezielle Form der Kante ist die gerichtete Kante, dargestellt durch einen Pfeil. Sie zeigt bspw. die Flussrichtung zwi- schen Geschäftsobjekt und Funktion. Kanten und gerichtete Kanten können bspw. die Werte: ist Eingabe für, hat Ausgabe, ändert, archiviert, erstellt, löscht, verteilt, erzeugt etc. annehmen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Konnektoren (XOR, UND, ODER) in einer eEPK

Prozessabläufe, dargestellt durch Ereignis und Funktion, sind selten linear und benötigen somit logische Verknüpfungen, sog. Konnektoren. Abbildung 2.4 illustriert die drei Grundformen logischer Konnektoren. Konnektoren teilen den Kontrollfluss und führen ihn wieder zusammen. Sie entsprechen ihrem jeweiligen Äquivalent aus der Logik. Der Konnektor XOR bietet die Möglichkeit alternative Abläufe, der Konnektor UND (Konjunktion) bietet die Möglichkeit parallele Abläufe und der der Konnektor ODER (Adjunktion) bietet die Möglichkeit parallele und alternative Abläufe grafisch darzustellen (vgl. Junktoren in Kapitel 2.3.1 auf Seite 39).

Generell wird zwischen Ereignis-Verknüpfungen und Funktions-Verknüpfungen unterschieden. Ereignis-Verknüpfungen verbinden durch einen Konnektor (XOR, UND, ODER) zwei oder mehrere Ereignisse miteinander. Funktions-Verknüpfungen verbinden ebenfalls durch einen Konnektor zwei oder mehrere Funktionen miteinan- der. Ermittelt man die Anzahl der prinzipiell möglichen Verknüpfungen (Ereignis, Funktion) mit den Konnektoren (XOR, UND, ODER) und beschränkt die Anzahl der Ereignisse (E) bzw. Funktionen (F) auf zwei, so erhält man zwölf Möglichkeiten (F1→ E1∧ E2; E1∧ E2→ F1; E1→ F1∧ F2; F1∧ F2→ E1; etc). Die beiden Funktions-Verknüpfungen E1→ F1 XOR F2 und E1→ F1∨ F2 (der prinzipiell zwölf Möglichkeiten) sind methodisch nicht zulässig, da in beiden Fällen das Er- eignis eine Entscheidung treffen müsste, generell Ereignisse aber nicht entscheiden können. Betrachtet man bspw. den Konnektor ODER verbunden mit vier einge- henden und einer ausgehenden Funktion in der Ablaufumgebung, so sind mehrere unterschiedliche Interpretationen möglich [34].

2.1.5 Business Process Execution Language (BPEL)

Die Business Process Execution Language for Web Services (BPEL4WS) [6] Ver- sion 1.1, im Folgenden als BPEL 1.1 bezeichnet, ist eine Vereinigung der Spezifi- kationen XLANG [160] von Microsoft und Web Services Flow Language (WSFL) [92] von IBM. Standardisiert durch das technische Komitee OASIS (Advancement of Structured Information Standards) [24] ermöglicht BPEL 1.1 die Definition ab- strakter sowie ausführbarer Prozessdefinitionen durch die Aufrufe von Web Services (siehe Kapitel 2.1.6 auf Seite 27). Eine abstrakte Prozessdefinition kann bspw. zu Dokumentationszwecken genutzt werden. Ausführbare Prozessdefinitionen werden erstellt, um sie in eine Workflow-Engine auszuliefern (engl. deployment).

Die Implementierung einer Workflow-Engine interpretiert ausführbare Prozess- definitionen durch die Erstellung einer oder mehrerer Prozessinstanzen in der Ablau- fumgebung. So ist die Erstellung ausführbarer Prozessdefinitionen mit dem Subjek- torientieren Ansatz [49] und auch mit BPEL 1.1 möglich. Der Subjektorientiere An satz beschreibt die Subjekte ”Prozessrollen“,”Prozessbeteiligte“und”Akteure“so- wie ihre zentralen Eigenschaften (Information) und ”miteinanderreden“(Kommunikation),”zuhören“ ”handeln“(Aktion).AnalogzurdeutschsprachigenGrammatik wird die Prozessdefinition als vollständiger Satz formuliert: Ein Mitarbeiter (Subjekt) erstellt (Prädikat) eine Bestellanforderung (Objekt). In der Ablaufumgebung sendet ein Subjekt Nachrichten an andere Subjekte, empfängt Nachrichten von anderen Subjekten oder führt Aktionen aus. Unabhängig von den jeweiligen Organisationen definiert jedes Subjekt seinen eigenen Ablauf. Die Koordination und Synchronisation findet ebenfalls über Nachrichten statt.

Im Gegensatz zum Subjektorientieren Ansatz hat die Prozessdefinition in BPEL fe (Web Services). Die WSDL-Datei (siehe Kapitel 2.5 auf Seite 30) beschreibt die Schnittstelle des Prozesses. Somit ist der BPEL-Prozess selbst ein Web Service. Muster (engl. Pattern) beschreiben beständig wiederkehrende Entwurfsproble-me und erläutern deren Problemlösung. Ziel ist es, die Entwurfsmuster als wie-derverwendbare Vorlagen zu etablieren, um Synergien zu erzielen. Bekannt unter dem Akronym GoF (

”GangofFour“)[[56]]wurdendreiundzwanzigEntwurfsmus- ter (vgl. Kapitel 2.9 auf Seite 38) für spezielle Herausforderungen in der Objektorientieren Software-Entwicklung erstellt. Analog zur Objekt-orientierten SoftwareEntwicklung wurden von den P4 (

”ProcessFour“)[[163]]zwanzigWorkflow-Muster (engl. Workflow Patterns) wie bspw. Sequenz (engl. Sequence), paralleler ProzessSplitt (engl. Parallel Split), exclusives Oder (engl. Exclusive Choice) etc. erstellt. Die Workflow-Muster der P[4]dienen heute als Grundlage zur Bestimmung der Mächtigkeit der Modellierungssprachen ausführbarer Prozesse[63].

Im Folgenden werden die grundlegenden Sprachelemente von BPEL 1.1 kurz beschrieben. Das Element<receive> ist eine Aktivität und erwartet auf eine ein- gehende Nachricht (engl. Message) via SOAP (siehe Kapitel 2.1.6 auf Seite 28). <pick>ähnelt<receive> und unterscheidet sich jedoch in der Erwartung mehre- rer eingehender Nachrichten.<reply> ist eine Aktivität, die synchrone Nachrich- ten (angestoßen von einem<receive>) seinem Aufrufer zurücksendet.<invoke> ruft einen Web Service (synchron oder asynchron) auf.<assign> kopiert bzw. transformiert Daten von Variable a nach Variable b.<terminate> sendet eine Fehlermeldung (engl. exception) und beendet die laufende Prozessinstanz sofort. <wait> ermöglicht analog zu Thread.sleep() in Java, das Warten einer Prozessin- stanz.<compensate> ermöglicht im Fehlerfall das Ausführen von Undo-Operati- onen. Im Gegensatz zur Transaktionssicherheit von Datenbanken (ACID) müssen in BPEL 1.1 Undo-Operationen definiert und implementiert werden.<validate> prüft Variablen gegen XML-Schema Definitionen.<sequence> definiert sequentielle und<flow> parallele zu verarbeitende Aktivitäten.<while>,<foreach> und<if> verhalten sich wie die analogen Konstrukte while, foreach und if in Java.

BPELj[18]ist eine standardisierte Java-Erweiterung von BPEL 1.1, mit dem Ziel Java-Code im XML-basierenden BPEL-Code zu nutzen. Die Erweiterung des Standards BPEL 1.1 um menschliche Aktivitäten (engl. Human Tasks (HT))[41]wurde durch BPEL4People[73]standardisiert. Unter ETTK (Emerging Technologies Toolkit) wird eine Unterstützung der UML2BPEL-Transformation durch die IBM in Form einer Open-Source Java-Entwicklung vorgestellt.

2.1. SERVICE-ORIENTIERTE ARCHITEKTUR 27

2.1.6 Web Service

Definitionen

In der Literatur wird Web Service [29] nicht eindeutig definiert und ist somit termi- nologisch unscharf. So definiert beispielsweise SUN einen Web Service als Software- System mit dem Ziel einer vollständig kompatiblen (engl. interoperable) Maschine- zu-Maschine Kommunikation über ein Netzwerk in einer heterogenen Umgebung: ”Webservicesaresoftwaresystemsdesignedtosupportinteroperablemachine-to- machine interaction over a network in a heterogeneous environment“ [142]. Zim- mermann definiert einen Web Service als auf eine XML-Nachrichten basierende verfügbare Kollektion von Operationen: ”AWebServiceimplementsaninterface that describes a collection of network-accessible operations through standard XML messaging“ [173]. Das World Wide Web Consortium (W3C) definiert die Technolo- gie Web Service mittels der Spezifikationen XML [12], SOAP [60] und WSDL [21] wie folgt:

Definition 2 A Web service is a software system designed to support interope- rable machine-to-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards. [168]

Uniform Resource Identifier (URI)

Der Uniform Resource Identifier (URI) [27] besteht aus einer Sequenz von Zeichen- ketten und identifiziert eine abstrakte oder eine physikalische Ressource. Die Syntax [13] definiert eine allgemein gültige Obermenge aller gültigen URIs mit dem Ziel, jeden möglichen Bezeichner, der keine Kenntnisse des spezifischen Schemata besitzt, parsen zu können. Der Internationalized Resource Identifier (IRI) [39] besteht eben- falls aus einer Sequenz von Zeichenketten und grenzt sich zu URI ab, indem eine IRI nur aus dem Zeichensatz Unicode/ISO 10646 bestehen kann. Uniform Resource Locator (URL) [15] ist eine Untermenge der URI und identifiziert eine Ressource über das verwendete Netzwerkprotokoll (http, ftp, telnet, file etc.). Im Folgenden werden URIs exemplarisch illustriert: telnet://192.0.2.16:80/, tel:+1-816-555-1212, http://www.ietf.org/dcx/getNumber etc. eXtensible Markup Language (XML)

Die eXtensible Markup Language (XML) [12] wird als Untermenge der Standard Ge- neralized Markup Language (SGML) [26] in Form einer Document Type Definition (DTD) definiert. XML ist eine stark verbreitete, textbasierende Beschreibungsspra- che. Als modularer Standard wird die plattformneutrale Strukturierung von Daten und Informationen lizenzfrei sehr gut unterstützt. Optional ermöglichen die DTD und das XML-Schema die Strukturdefinition der Dokumentinstanzen. DTD grenzt sich zu XML-Schema dadurch ab, dass die DTD selbst kein XML-Dokument ist und nicht die Ausdrucksmächtigkeit eines XML-Schema besitzt. Die XML-Familie ist ein wachsender Satz von Modulen; Bspw. wird im Modul eXtensible Stylesheet Language (XSL) [124] die grafische Darstellung des XML-Dokumentes definiert sowie im Mo- dul XSL Transformation (XSLT) [22] das Umstellen, Hinzufügen und Löschen von Elementen und Attributen ermöglicht. Basierend auf der XML-Familie vergrößert sich das Angebot an XML-Standards durch die Auswirkungen und Einflüsse von Internet, E-Commerce, Künstlicher Intelligenz, Multimedia, Objekt-Orientierung, Datenbanken etc. Alle Web Services Standards basieren auf der XML-Technologie. Im Folgenden wird eine XSL-Transformation dargestellt, die in Form einer Schleife alle<S-Klasse>-Elemente nach ihrem Verkaufs-Preis (VK) sortiert [72].

<xsl:for-each select="S-Klasse">

<xsl:sort select="VK"/>

</xsl:for-each>

SOAP

Auf XML basierend ist SOAP 1.2 [60] ein Protokoll, das den Austausch struktu- ierter Daten zwischen Service-Provider, Service-Consumer und Vermittler plattfor- mneutral ermöglicht. Bis zur Version 1.1 stand SOAP für Simple Object Access Protocol ; die aktuelle Version 1.2 distanziert sich von dieser Bezeichnung. Gene- rell ist SOAP unabhängig vom darunterliegenden Transportprotokoll. Dennoch ist HTTP das präferierte und mit Beispielen dokumentierte Transportprotokoll des W3C. SOAP gliedert sich in die drei Elemente SOAP-Envelope (dt. Umschlag), SOAP-Header (dt. Kopf ) und SOAP-Body (dt. Hauptteil). Das Element Envelope dient als Container für Header und Body. Das Element Header ist optional und transportiert Informationen über die Sicherheit, wie bspw. Verschlüsselung sowie über die Service-Güte (engl. Quality of Service (QoS)) wie bspw. Antwortzeiten. Das Element Body ist zwingend und transportiert die Nutzdaten in Form der beiden Kommunikationsarten: SOAP-Dokument-Style oder SOAP-RPC-Style. Im Folgen- den wird exemplarisch die Operation xmethodsBabelFish des Service BabelFish mit den beiden Übergabeparametern Translationsmode (Deutsch → English) und Quelle (Hallo Welt!) mittels SOAP-Request aufgerufen.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas..." xmlns:xsi="http://www.w3.org/..." xmlns:xsd="http://www.w3.org/...">

<SOAP-ENV:Body>

<ns1:BabelFish xmlns:ns1="urn:xmethodsBabelFish"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/..."> <transl... xsi:type="xsd:string">de_en</...ationmode> <source... xsi:type="xsd:string">Hallo Welt!</...data></ns1:BabelFish>

</SOAP-ENV:Body> </SOAP-ENV:Envelope>

2.1. SERVICE-ORIENTIERTE ARCHITEKTUR 29

Die Rückgabe erfolgt mittels SOAP-Response und dem Rückgabeparameter return mit dem Wert hello world!.

<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas..."

SOAP-ENV:encodingStyle="http://schemas..." xmlns:xsi="http://www.w3.org/2001/..." xmlns:SOAP-ENV="http://schemas.xmlsoap.org/..." xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>

<namesp1:BabelFishResponse xmlns: namesp1="urn:xmethodsBabelFish">

<return xsi:type="xsd:string">hello world!</return></namesp1:BabelFishResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Wie bereits im ersten Absatz erwähnt, ermöglichen die beiden Arten SOAPDokument-Style und SOAP-RPC-Style die Kommunikation zwischen Service-Provi- der, Service-Consumer und Vermittler. Der SOAP-Dokument-Style erlaubt eine vollkommen freie Strukturierung des Body-Elements passend zu einem XML-Schema. Der SOAP-RPC-Style erfordert die folgende Struktur für die Methodennamen sowie für die Ein- (I) und Ausgabeparameter (O) [173].

<env:Body>

<m:&methodName xmlns:m="someURI"> <m:&param1>...</m:&param1> <m:&param2>...</m:&param2> </m:&methodName>

</env:Body>

Web Service Description Language (WSDL)

Die Web Service Description Language 1.1 [21] wird in zwei Bereiche, die Schnitt- stellenbeschreibung (engl. abstract interface) und die Implementierung (engl. con- crete implementation), unterteilt. Im ersten Bereich werden die Elemente<defini- tions>,<types>,<messages> und<portTypes> definiert; der zweite schließt die WSDL mit den Elementen<binding> und<service> ab. Das Element<defini- tions> deklariert weltweit eindeutige Bereiche (engl. Namespaces) in Form einer URI (siehe Kapitel 2.1.6 auf Seite 27) sowie die Adresse (engl. TargetNamespace) des Services. Das Element<types> definiert komplexe XML Datentypen (engl. com- plex types) (bspw. Adresse, Fax-Nummer und Währung). Einfache XML Datenty- pen (engl. simple types) (bspw. xsd:integer, xsd:string und xsd:float) werden durch das XML-Schema deklariert und sind somit direkt nutzbar. Das Element <message> baut auf die Datentypdefinition auf und deklariert die einzelnen Ein- und Ausgabenachrichten (engl. messages), die zwischen dem Service-Provider und dem Service-Consumer ausgetauscht werden.

Das Element<portType> definiert Operatoren durch die Elemente<operation>, <input>,<output> und<fault>. Das Element<binding> definiert das Transport- protokoll zwischen Service-Provider und -Consumer und eine optionale Verschlüsse-

<definitions>np

KAPITEL 2. GRUNDLAGEN

<!-- Abstrakt -->

<types> ... </types> <message>

<part> ... </part> </message>

<portType>

<operation>

<input> ... </input>

<output> ... </output> <fault> ... </fault>

<documentation> ... </documentation></operation>

</portType>

<!-- Konkret --> <binding>

<operation>

<input> ... </input>

<output> ... </output> <fault> ... </fault></operation>

</binding>

<service>

<port> ... </port> </service>

</definitions>

Abbildung 2.5: Web Service Discription Language 1.1 lung der Nachrichten auf der Ebene der Operatoren. Das Element<service> ver- bindet das zuvor definierte Element<binding> mit dem Service-Endpunkt [173].

Service-Endpunkt

Der Begriff binding beschreibt die Anforderungen an eine physikalische Verbindung für die Kommunikation bzw. den Transport der Nachrichten wie das Transport- protokoll (i.d.R. SOAP) und den Dokument-Style. Der Term portType beschreibt abstrakt, in Form symbolischer Namen, die Operationen und die Ein- bzw. Ausga- benachrichten eines Services. Der Term port beschreibt eine Assoziation zwischen binding sowie einem Uniform Resource Identifier (siehe Kapitel 2.1.6 auf Seite 27) und kann somit als Service-Endpunkt bezeichnet werden [167] [37]. Zur Verbesse- rung der Transparenz wurde in der Spezifikation WSDL 2.0 der Term portType in interface und der Term port in endpoint umbenannt [42]. Der Standard Web Services Enpoint Language (WSEL) [149] verfolgt das Ziel, alle notwendigen und hinreichenden Charakteristiken eines Endpunkts zu beschreiben: QoS, Operations- typen (lesen, schreiben etc.), Kostenstrukturen und Sicherheitsanforderungen.

2.1. SERVICE-ORIENTIERTE ARCHITEKTUR 31

Abbildung der Datentypen

Interoperabilität zwischen den unterschiedlichen Implementierungen wie bspw. Ja- va, C#, COBOL (Common Business Oriented Language) etc. ist eine der aktuellen Herausforderungen. Das Web Services Apache SOAP-Framework AXIS [52] defi- niert Standard-Abbildungen (engl. standard mappings) der Datentypen in der Pro- grammiersprache Java. Primitive Datentypen werden mit ihren Wrapper-Klassen (Byte, Double, Boolean etc.) überschrieben. Im Folgenden wird die Standard-Abbil- dung für die Programmiersprache Java dargestellt (vgl. Tabelle 2.2):

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Abbildung der Datentypen von WSDL auf Java

Universal Description, Discovery and Integration (UDDI)

Der Verzeichnisdienst Universal Description, Discovery and Integration (UDDI) [23] stellt Informationen über Services, Service-Endpunkte und ihre Service-Provider zur Verfügung. Die Schnittstelle der UDDI ist via SOAP-Messages erreichbar. Generell werden die Informationen in die drei Teilbereiche White Pages, Yellow Pages und Green Pages untergliedert. White Pages geben Auskunft über das Namensregister, Kontaktinformationen und eine Auflistung der Detail-Informationen der Provider. Yellow Pages sind das Branchenverzeichnis und unterstützten das spezifische Su- chen in unterschiedlicher Taxonomien wie bspw. Service-Art. Green Pages informie- ren über das Geschäftsmodell und die Geschäftsprozesse des Providers sowie über technische Details zu den Web Services [107].

Service-Status

Der Lebenszyklus eines Services wird innerhalb der Operationsbeschreibungen im Feld Status dokumentiert und hat folgenden Verlauf (siehe Abbildung 2.6). Nach einer abgeschlossener Definition des Entwicklungsprozesses wird der Zustand Kan- didat gegebenenfalls in mehrere Zustände aufgesplittet: designed, implementiert und getestet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Service-Status

2.1.7 Enterprise Service Bus (ESB)

Der Begriff Enterprise Service Bus (ESB) wird von den Software-Herstellern teil- weise als Namensbezeichnung für ein oder mehrere Produkte benutzt. Dieser Tat- bestand führt, in Verbindung mit der nicht eindeutigen Verwendung in der Fachli- teratur, erneut (analog zu Web Service) zu einer unscharfen Terminologie, die es zu beseitigen gilt. Woods definiert den ESB als ein auf eine standardisierte Menge von Services basierendes Rahmenwerk, das seine Wiederverwendung in einer An- wendung im Enterprise Computing findet [171]. Bieberstein definiert den ESB als intelligente, verteilte, transaktionale, nachrichten-basierte Schicht, die dazu dient, Applikationen miteinander zu verbinden und das Verarbeiten unterschiedlicher Da- ten, die in der Regel innerhalb einer Enterprise Computing Infrastruktur verteilt sind, ermöglicht [16]. Der Standard Java Business Integration (JBI) [80] von SUN konkretisiert den ESB durch die aktuelle Spezifikation. So wird bspw. durch den definierten Zugriff auf Web Services ohne die Festlegung des Service-Endpunkts, eine Interoperabilität verschiedener ESBs untereinander ermöglicht. Dieser Stan- dard wird jedoch nicht von allen Herstellern unterstützt, dennoch sind bereits erste Implementationen u.a. in der Open Source Community verfügbar.

Diese Arbeit versteht den ESB als Konzept zur Kommunikation von Services über eine standardisierte Infrastruktur mit dem Ziel der Integration unterschiedli- cher Plattformen. Internationale, historisch gewachsene Unternehmen nutzen CO- BOL-Programme auf Legacy-Systemen (bspw. OS/390 oder z/OS [69]) sowie J2EE- Anwendungen auf Applikations-Servern. Somit muss ein ESB die Kommunikation unterschiedlicher Plattformen unterstützten. Im Folgenden wird die Definition ei- nes ESB bei der Daimler AG und das von der Definition abgleitete Konzept (siehe Abbildung 2.7 auf Seite 33) dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: Elementares Konzept ESB

Definition 3 Der Enterprise Service Bus (ESB) regelt die Kommunikation durch ein inhaltbasierendes Routing (engl. Content-Based Routing), Multi-Protokoll-Kom- munikation sowie Validierung und Transformation von Nachrichten der Services über eine standardisierte Infrastruktur. Er unterstützt das Reagieren auf Ereignisse, die Sicherheit, das Monitoring, bietet Adapter zu Legacy-Systemen an und verein- facht die Kommunikation mit dem Enterprise Service Repository [67].

Die rechte Seite in Abbildung 2.7 illustriert die bereits etablierte Kommunika- tion über synchrone bzw. asynchrone (bspw. Message Queuing via MQSeries [166]) binäre Nachrichtenformate. Die Transformation von Nachrichten sowie Adapter zur Unterstützung der Kommunikation für unterschiedlichen Plattformen sind elemen- tare Bestandteile eines ESBs. Die linke Seite in Abbildung 2.7 zeigt die synchrone und asynchrone standardisierte plattformneutrale Kommunikation über Web Ser- vices, die standardisierte Transformation der Nachrichten mit XSLT sowie die Un- terstützung der Web Service Security Standards. Beide Seiten unterstützen inhalts- basierendes Routing (engl. Content-Based Routing) durch die Verhaltensmuster: Beobachter (engl. Observer) (Synonym publiziere und abonniere (engl. Publish- Subcribe)), Anfrage-Antwort (engl. Request-Response) und das Reagieren auf Ereig- nisse (engl. Event-Handling). Transportprotokolle, wie bspw. HTTP/SOAP, HTT- PS/SOAP und JMS/SOAP werden komplett unterstützt, wobei hierbei die Haupt- aufgabe des EBS’s das Abbilden der Protokolle aufeinander (Service-Consumer und Service-Provider nutzen unterschiedliche Transportprotokolle) darstellt. Die Anwen- dung der standardisierten sicheren Kommunikation (Verschlüsselung, Autorisierung und Authentifizierung, Vertraulichkeitsstufen, Datenintegrität etc.) sind teilweise abhängig vom Reifegrad des Standards und von der proprietären Implementierung. Die rechte und die linke Seite des Konzeptes werden über einen Adapter miteinan- der verbunden, um eine geregelte Kommunikation Legacy-zu-Legacy, Web-Service- zu-Web-Service und Legacy-zu-Web-Service realisieren zu können [66]. Somit stellt das Konzept ESB eine Möglichkeit dar, Service-Consumer und Service-Provider standardisiert in einer verteilten Umgebung technisch lose gekoppelt miteinander zu verbinden. Geschäftsobjekte werden technisch als Service Data Objects (SDO) [58] bzw. Service Message Objects (SMO) [30] transportiert. SDO und SMO ba- sieren auf der selben Basisstruktur, definiert durch ein XML-Schema: Hauptteil (engl. Body), Kopf (engl. Header) und Kontext. Der Hauptteil der Nachricht bein- haltet die Ein- bzw. Ausgabewerte (bspw. getQuote.request.customerID) der Service-Operationen, der Kopf beinhaltet Informationen über das Transportproto- koll (bspw. messageUUID, version, messageType) und der Kontext beinhaltet spe- zifische Informationen zum Ablauf (engl. Flow) (bspw. correlation, transient) oder Fehler-Informationen (bspw. failInfo). SMO erweitert SDO um bspw. CO- BOL und weitere Datenstrukturen. Diese standardisierten Austauschformate sind mit XPath, XSLT und Java bzw. C++ manipulierbar. Die erweiterten Anforderun- gen an einen ESB sind die Erstellung und Auswertung von Metriken basierend auf Key Performance Indikatoren (KPI), die Ermittlung von Quality of Service (QoS) und die Mediation in der Ablaufumgebung. Die Mediation beinhaltet eine Logik, abgebildet durch den Ablauf (engl. Mediation Flow). Steuerelemente bestehen aus den Komponenten Logging, Lookup (Datenbank bzw. ESR), XSLT, Stopp, Fehler und Service-Endpunkt [30].

2.1.8 Enterprise Service Repository (ESR)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8: Konzept Enterprise Service Repository (ESR)

Die Abbildung 2.8 illustriert das Konzept Enterprise Service Repository (ESR) auf der höchsten Abstraktionsebene durch Aufzeigen der beiden Komponenten Registry und Repository im Infrastruktur-Layer. Auf Basis des unter Kapitel 2.1.6 vorgestell- ten Standards UDDI wurden bereits proprietäre Produkte der Software-Hersteller, wie bspw. IBM, SAP, Software AG (SAG) und Bea auf dem Markt positioniert. Der Standard UDDI legt Richtlinien für die Registrierung und die Aktualisierung der Metadaten sowie die maschinelle Suche und Zuordnung der Verantwortlichkeiten der Web Services fest (White Pages, Yellow Pages, Green Pages). Somit unterstützt der Standard UDDI nur eine Teilmenge der funktionalen und nicht-funktionalen Anfor- derungen (NFA) an ein ESR. ebXML [111] ist eine Spezifikation zur Beschreibung von Geschäftsprozessen durch die Definition des Datenformats, der Nachrichten und der Austausch-Mecha- nismen [61]. Diese Spezifikation ist unabhängig von einer technischen Realisierung, in der Web Services als Sonderfall eines Geschäftsprozesses betrachtet werden. Die ebXML Registry spezifiziert die Beschreibung und Speicherung von Information zur Integration von Geschäftsprozessen [11]. Implementierungen eines ESR unterstützen den Standard UDDI und erweitern die Anforderungen durch proprietäre Konzep- te. Bspw. integriert das Unternehmen Bea den ebXML-basierten Ansatz und das Unternehmen IBM den OWL-basierten Ansatz in Ihre Produkt-Suite.

Qualitätsmerkmale der Software-Produkte wie Zuverlässigkeit, Wartbarkeit, Ver- fügbarkeit, Performanz, Portierbarkeit und Sicherheit lassen sich auf nicht-funk- tionale Anforderungen der Services abbilden [125]. Im Projekt SOA for Automotive (SOAFA) [113] wurden weitere nicht-funktionale Anforderungen im Speziellen für ESRs abgeleitet: Nutzung offener und frei-verfügbarer Standards für Datenmodell und Zugriffsschnittstelle, Nutzung von Standards mit einem größtmöglichen Grad an technischer Reife und hohem Maß an Verbreitung zur Sicherung der Investiti- onssicherheit und Interoperabilität sowie Bereitstellung einer für die Nutzergruppen adäquaten Schnittstelle zum Zugriff auf das ESR [8]. Funktionale Anforderungen lassen sich in die Klassen Informationsregistrierung, Sicherheits- und Monitoringa- spekte, Informationsmanagement sowie Architekturbildung einteilen und beschrei- ben die zu erwartende Funktionalität des ESRs [115] [8]. Im Anhang C auf Seite 155 werden die funktionalen Anforderungen an ein ESR dargestellt.

2.1.9 Service-Portfolio-Management

Das Service-Portfolio-Management ist die organisatorische Instanz zur Planung, Ko- ordination und Verwaltung der funktionalen und nicht-funktionalen Informationen im Enterprise Service Repository (siehe Kapitel 2.1.8 auf Seite 34). Somit ist das Service-Portfolio-Management die Instanz zur Überwachung der Realisierung neuer Services, zur Prüfung redundanter Services, zur Verwaltung der Service-Versionen und zur Prüfung der Dokumentationspflicht vorhandener Services. Sie stellt weiter- hin die Eskalationsinstanz mit Entscheidungskompetenz bei Differenzen zwischen Service-Besitzer, Service-Nutzer und Service-Betreiber dar. Unter SOA Governance wird die Steuerung aller SOA-Aktiväten verstanden. Die Herausforderungen einer SOA Governance werden in der Praxis durch Rollen wahrgenommen. Die SOA Go- vernance & Management Methode (SGMM) der IBM unterstützt methodisch die Governance-Struktur eines Unternehmens. Im Anhang E auf Seite 159 werden Infor- mationen beschrieben, die als Entscheidungshilfe dienen und vom Service-Portfolio- Management eingefordert werden.

2.2 Entwurfsmuster Mediator

Entwurfsmuster (engl. Design Pattern) beschreiben in der Software-Architektur beständig wiederkehrende Entwurfsprobleme und erläutern eine Problemlösung. Ziel ist es, die Entwurfsmuster als wiederverwendbare Vorlagen (Schablonen) in der Software-Architektur zu etablieren, um Synergien in der Software-Entwicklung zu erzielen. In der Fachliteratur wird das Entwurfsmuster untergliedert in Erzeugungs- muster (Abstrakte Fabrik, Erbauer, Prototyp etc.), Strukturierungsmuster (Adap- ter, Brücke, Proxy etc.) und Verhaltensmuster (Beobachter, Iterator, Mediator etc.). Erich Gamma beschreibt in seiner Dissertation [55] einen Teil der heute bekannten Entwurfsmuster und stellt auf der OOPSLA 91 einen ersten Katalog vor.

Generell beinhaltet ein Entwurfsmuster die folgenden vier grundlegenden Ele- mente: Entwurfsmustername, Problemabschnitt, Lösungsabschnitt und Konsequen- zenabschnitt. Der Entwurfsmustername besteht aus ein oder zwei Worten, die das Entwurfsproblem, seine Lösung und Auswirkungen eindeutig benennt. Die Findung und die Akzeptanz des somit neu entstandenen Vokabulars stellt die erste Her- ausforderung dar. Aktueller Kontext und Entwurfsproblem werden im Problemab- schnitt adressiert. Hier werden Bedingungen definiert, die erfüllt sein müssen, um das Entwurfsmuster erfolgreich anwenden zu können. Das letzte Grundelement Kon- sequenzenabschnitt beschreibt die Auswirkungen (wie bspw. Ausführungszeit und Speicherplatzverbrauch) der Anwendung des Entwurfsmuster in Form einer Auflis- tung der Vor- und Nachteile.

Um die Anwendung zu vereinfachen, werden alle Entwurfsmuster konsequent durch ein einheitliches Format beschrieben. Mustername und Klassifzierung vermit- teln knapp, aber präzise den wesentlichen Inhalt des Entwurfsmusters. Die Klassi- fizierung besteht aus der vertikalen Dimension Aufgaben und der horizontalen Di- mension Gültigkeitsbereich. Die Dimension Aufgaben unterteilt sich in Erzeugungs-, Strukturierungs- und Verhaltensmuster. Die Dimension Gültigkeitsbereich unter- teilt sich in Klasse und Objekt. Der Abschnitt Zweck stellt kurz das Grundprinzip, die Aufgaben und den Zweck sowie spezifische Fragestellungen vor. Unter auch be- kannt als werden bereits bekannte Namen des Entwurfsmusters aufgelistet. Der Abschnitt Motivation besteht aus dem Szenario, dem Entwurfsproblem und der Klassen- und Objektstruktur. Die Anwendbarkeit beschreibt Situationen zur An- wendung des Entwurfsmusters. Der Abschnitt Struktur stellt die grafische Repräsen- tation des Entwurfsmusters in Form eines Klassen-, Objekt-, oder Interaktions- diagramms dar. Jedes Entwurfsmuster wird mindestens in Form eines Klassendia- gramms abgebildet. Die Klassen- und Objektdiagramme basieren auf der Object- Modeling-Technique (OMT) [128]. Die weiteren Diagrammtypen finden ihre An- wendung bei Bedarf [78]. Teilnehmer beschreibt alle am Entwurfsmuster beteiligten Klassen, Objekte und ihre Zuständigkeiten. Der Abschnitt Interaktionen beschreibt die Zusammenarbeit der einzelnen Teilnehmer mit dem Ziel der gemeinsamen Auf- gabenerfüllung. Im Abschnitt Konsequenzen werden Ziele sowie die Vor- und Nach- teile des Entwurfsmusters diskutiert. Implementierung stellt spezifische Techniken, mögliche Fallen sowie praxisnahe Tipps vor und zeigt ggf. programmiersprachen- spezifische Aspekte auf. Im Abschnitt Beispielcode werden Codefragmente veran- schaulicht diskutiert. Bekannte Verwendungen illustrieren bereits implementierte Entwurfsmuster in echten Systemen unterschiedlicher Anwendungsbereiche. Der letzte Abschnitt Verwandte Muster grenzt das bezeichnete Entwurfsmuster ab und diskutiert Kombinationsmöglichkeiten mit anderen Entwurfsmustern. Im folgenden wird das Verhaltensmuster Mediator (dt. Vermittler) im soeben dargestellten For- mat beschrieben [56].

Mediator. Der Mediator ist ein objektbasiertes Verhaltensmuster.

Zweck. Der Mediator definiert ein Objekt, um das Zusammenspiel zwischen ei- ner Menge von Objekten zu kapseln. Durch eine Unterbindung des direkten und expliziten Bezugs auf Objekte wird die lose Kopplung der Objekte gefördert.

Motivation. Die objektorientierte Software-Entwicklung fördert ein verteiltes Ver- halten zwischen Objekten. Somit können Objektstrukturen und ihre Beziehungen eine Komplexität von[1](n2− n) erreichen. Generell unterstützt die Unterteilung eines Kommunikation-Systems in Klassen und Objekte die Wiederverwendung. Durch komplexe Beziehungen der Objekte untereinander tendiert das System zu einem Monolithen. Der Mediator kapselt das Verhalten der Objekte und vermittelt als eigenständiges Objekt zwischen den beteiligten Objekten.

Anwendbarkeit. Das Mediator Verhaltensmuster ist anzuwenden, wenn

- eine Menge von Objekten auf komplexer Weise miteinander kommuniziert. Somit besteht die Gefahr von unstrukturierten und schwer verständlichen Abhängigkeiten.
- die Wiederverwendung eines Objektes schwierig ist, da dieses Objekt mit vielen anderen Objekten kommuniziert oder diese Objekte referenziert.

Struktur. In Abbildung 2.9 wird die generische Struktur des Mediator Verhal- tensmusters grafisch dargestellt. Ziel ist die lose Kopplung der Klasseninstanzen bei verteiltem Verhalten. Dabei kennt die Klasse Kollege, symbolisiert durch die gerich- tete Assoziation, die abstrakte Klasse Vermittler. Die Vererbungsbeziehung, zwi- schen der Oberklasse Kollege und den Unterlassen KonkreterKollegeA sowie Kon- kreterKollegeB, als auch zwischen der abstrakten Oberklasse Vermittler und der Unterklassse KonkreterVermittler, wird durch die Generalisierung symbolisiert. Die gerichtete Assoziation macht die beiden Klassen KonkreterKollegeA und Konkre- terKollegeB bei der Klasse KonkreterVermittler bekannt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: Generische Klassenstruktur Mediator[56]

Teilnehmer. Der Vermittler definiert als abstrakte Klasse die Interaktion mit den Kollegen-Objekten. Der KonkreteVermittler kennt, koordiniert und verwaltet die Kollegen-Objekte durch Implementierung des Gesamtverhaltens. Die KollegenKlassen kommunizieren über den Vermittler und nicht mit sich selbst.

Interaktionen. Der Vermittler koordiniert die Kommunikation zwischen den Anfragen und den Kollegenobjekten, indem er beim Senden und Empfangen der Anfragen an die Objekte vermittelt.

Konsequenzen. Durch die zentrale Kapselung des Verhaltens in der Klasse Ver- mittler sind die Kollegen-Klassen lose gekoppelt und können einfach wiederverwen- det werden. Zuvor bestandene n-zu-m Beziehungen wurden durch eine 1-zu-n Be- ziehung ersetzt, womit das Verwalten und Erweitern der Klassen vereinfacht wird. Durch Abbildung der Komplexität in der Klasse Vermittler kann diese selbst du einem Monolithen werden.

Implementierung. Bei der Implementierung wurde die abstrakte Klasse Ver- mittler nicht realisiert. Die Notwendigkeit, eine abstrakte Klasse Vermittler ein- zuführen, ist nur durch eine gegebene Kommunikation mit weiteren abstrakten Vermittler-Klassen sinnvoll. Ereignisse, die durch die Kommunikation der Objekte ausgelöst werden, müssen durch den Vermittler beobachtet werden. Das Beobachter- Verhaltensmuster [56] ist ein möglicher Ansatz bei der Implementierung.

Bekannte Verwendungen und verwandte Muster. Das Strukturierungsmus- ter Fassade (engl. Facade) dient zur Realisierung einer vereinfachten abstrakten Schnittstelle und wird bspw. zur Abstraktion von Datenbankzugriffen eingesetzt. Das Verhaltensmuster Beobachter (engl. Observer) dient zur Überwachung des Zu- stands eines Objektes, der Beobachter benachrichtigt und aktualisiert automatisch alle anhängigen Objekte.

2.3 Semantische Web Services

2.3.1 Ontologien

Der Terminus technicus Ontologie verweist etymologisch auf die altgriechische Phi- losophie: Aristoteles definierte zum ersten Mal rationale Komponenten des Verstan- des in Form einer exakten Menge von Gesetzen. Von diesem Verständnis ausgehend erlangte diese Wissenschaft von dem Seienden ihre philosophiegeschichtliche so emi- nente Rolle. Somit soll die Ontologie Grundstrukturen des Seins ermitteln: Was ist der Mensch? Gibt es Gott? Gibt es ein Anfang der Welt? Der Terminus Ontolo- gie wird in der Wissensrepräsentation (engl. Knowledge Representation (KR)) zum Speichern deklarativen Wissens in einer Wissensbasis (WB) genutzt.

Die Künstliche Intelligenz (KI) (engl. Artificial Intelligence (AI)) nutzt die Wis- sensrepräsentation und die Inferenz, um Agenten zu steuern. Die Philosophen unter- scheiden zwischen der schwachen und der starken KI. Die schwache KI untersucht die Hypothese ”KönnenMaschinensoagieren,alswärensieintelligent?“,diestarke

KI versucht (im Gegensatz zum simulierten Denken) mentale Denkprozesse abzubil- den [94]. Die KI selbst definiert den Terminus technicus Ontologie unterschiedlich, so definiert bspw. Gruber ”Anontologyisaformalspecificationofaconceptuali- zation“ [59]. Eine Konzeptualisierung ist eine abstrakte vereinfachte Sicht auf eine Domäne, die die Konzepte, Objekte und Beziehungen untereinander (innerhalb die- ser Domäne) beschreibt. Im Jahre 1997 wurde die Definition von Gruber um den Terminus shared ergänzt und wie folgt definiert:

”Anontologyisaformalspecification of a shared conceptualization“[19]. Im Jahre 1998 wird die Definition um den Terminus explizit ergänzt und wie folgt definiert: specification of a shared conceptualization“ [158].

”Anontologyisaformal,explicit In der Informatik wird unter dem Begriff der Ontologie die formale Repräsen- tation eines Systems von Begriffen mit zwischen diesen bestehenden Relationen verstanden [65]. Domänenspezifisches Wissen kann durch eine oder mehrere Onto- logien beschrieben werden. Somit beschreibt eine Ontologie auf eine formale Art und Weise Konzepte und Relationen dieser Konzepte innerhalb einer Domäne ein- deutig [154]. IT-Systeme nutzen implizite und explizite Konzeptualisierungen einer Domäne ihres Arbeitsgebiets [161].

[...]