Inhaltsverzeichnis I

Inhaltsverzeichnis   

Abbildungsverzeichnis   III

Tabellenverzeichnis IV   

Quellcodeverzeichnis   V

Abk  ürzungsverzeichnis  VI

1  Einleitung.  8

1.1  Motivation und Ziel der Arbeit  8

1.2  Aufbau der Arbeit.  9

2  Grundlagen  11

2.1  Begriffsbestimmung  11

2.1.1  Architektur  11

2.1.2  Service  15

2.1.3  Komponente  15

2.2  Kommunikation in verteilten Systemen  16

2.2.1  Synchronität und Persistenz.  17

2.2.2  Remote Procedure Call  20

2.2.3  Nachrichtenorientierte Middleware  21

2.3  Anwendungsintegration.  24

2.3.1  Ebenen der Anwendungsintegration  25

2.3.2  Topologien der Anwendungsintegration.  26

2.3.3  Enterprise Application Integration  29

3  Service-Oriented Architecture.  31

3.1  Funktionsweise  32

3.2  Prinzipien der Serviceorientierung  33

3.3  Merkmale der serviceorientierten Architektur  37

3.4  Definition der serviceorientierten Architektur.  38

3.5  Lose versus enge Kopplung  40

3.6  Implikationen beim Einsatz einer serviceorientierten Architektur  42

4  Event-Driven Architecture.  44

4.1  Begriffsbestimmung  45

4.1.1  Ereignis  45

4.1.2  Ereignishierarchie.  46

4.1.3  Ereigniskausalität  47

4.1.4  Ereignismuster und Ereignismusterregeln  47

4.1.5  Ereignisgesteuerter Geschäftsprozess.  48

4.2  Komponenten einer ereignisgesteuerten Architektur  49

Inhaltsverzeichnis II

4.3  Arten der Ereignisverarbeitung.  51

4.3.1  Ereignisweitergabe  52

4.3.2  Einfache Ereignisverarbeitung  52

4.3.3  Ereignisvermittlung  53

4.3.4  Ereignisstromverarbeitung  54

4.3.5  Komplexe Ereignisverarbeitung  54

4.4  Merkmale der ereignisgesteuerten Architektur.  58

4.5  Definition der ereignisgesteuerten Architektur  59

5  Event-Driven Service-Oriented Architecture  60

5.1  Abgrenzung der ereignisgesteuerten Architektur von der  

serviceorientierten  Architektur  60

5.2  Enterprise Service Bus  62

5.2.1  Definition des Enterprise Service Bus  63

5.2.2  Merkmale und Fähigkeiten des Enterprise Service Bus  64

5.2.3  Komponenten des Enterprise Service Bus  66

5.3  Definition der ereignisgesteuerten serviceorientierten Architektur  69

6  Softwareprodukte im Bereich der EDSOA.  71

6.1  EDSOA-Softwareprodukte von Oracle.  71

6.2  EDSOA-Softwareprodukte von TIBCO.  76

6.3  Vergleich der Produkte von Oracle und TIBCO  79

6.4  Einordnung der Produkte von Oracle und TIBCO  80

7  Zusammenfassung und Fazit.  83

Anhang A:  Standards.  84

Literaturverzeichnis   96

Abbildungsverzeichnis   

Abbildungsverzeichnis   

Abbildung  2.1: Bestandteile der Unternehmensarchitektur  

Abbildung  2.2: Persistente und nicht-persistente asynchrone Kommunikation.  

Abbildung  2.3: Persistente und nicht-persistente synchrone Kommunikation  

Abbildung  2.4: Asynchroner RPC.  

Abbildung  2.5: Persistente Publish-Subscribe-Kommunikation  

Abbildung  2.6: Punkt-zu-Punkt-Topologie.  

Abbildung  2.7: Nabe-und-Speichen-Topologie.  

Abbildung  2.8: Multihub-Topologie  

Abbildung  2.9: Bus-Topologie  

Abbildung  3.1: Rollen und Operationen innerhalb einer SOA  

Abbildung  3.2: Wechselwirkungen zwischen den Prinzipien der  

Serviceorientierung   

Abbildung  4.1: Linearer aktivitätsbasierter Geschäftsprozess  

Abbildung  4.2: Ereignisgesteuerter Geschäftsprozess.  

Abbildung  4.3: Komponenten einer EDA.  

Abbildung  4.4: Durchdringung der Ereignisverarbeitung  

Unternehmenssoftware   

Abbildung  4.5: Ereignisweitergabe  

Abbildung  4.6: Einfache Ereignisverarbeitung  

Abbildung  4.7: Ereignisvermittlung.  

Abbildung  4.8: Ereignisstromverarbeitung  

Abbildung  4.9: Ereignisverarbeitungsnetzwerk  

Abbildung  4.10: CEP-Infrastruktur  

Abbildung  5.1: Schematische Darstellung des ESB  

Abbildung  5.2: ESB-Service-Container  

Abbildung  5.3: Managementdienste des ESB-Service-Containers  

Abbildung  5.4: Prozessgesteuertes und inhaltsabhängiges Routen innerhalb des  

ESB   

Abbildung  6.1: Oracle Real-Time Business Dashboard  

Abbildung  6.2: Oracle Process Designer  

Abbildung  6.3: Oracle Business Rules-Komponenten  

Abbildung  6.4: TIBCO Enterprise Message Service  

Abbildung  6 5: TIBCO Designer  

Tabellenverzeichnis IV   

Tabellenverzeichnis   

Tabelle 2.1:  Vergleich von traditionellen Integrationsansätzen und EAI.  30

Tabelle 3.1:  Vergleich von enger und loser Kopplung  41

Tabelle 5.1:  Vergleich von SOA und EDA  61

Tabelle 5.2:  Minimale Fähigkeiten und Dienste eines ESB  66

Tabelle 6.1:  Komponenten der EDA- und SOA-Suite von Oracle.  71

Tabelle 6.2:  EDSOA-Produkte von Oracle und TIBCO  79

Tabelle A 1:  Einfache und strukturierte Aktivitäten in BPEL4WS  93

Abkürzungsverzeichnis V

Quellcodeverzeichnis

Quellcode A.1: Dokument1.xml ................................................................ 84 Quellcode A.2: Dokument2.xml ................................................................ 85 Quellcode A.3: Validierung1.dtd................................................................ 86 Quellcode A.4: Validierung2.xsd ............................................................... 87 Quellcode A.5: SOAP-Anfrage ................................................................... 88 Quellcode A.6: SOAP-Antwort................................................................... 89 Quellcode A.7: HalloService.wsdl .............................................................. 91 Quellcode A.8: Echo.bpel ......................................................................... 94 Quellcode A.9: Echo.wsdl......................................................................... 95

Abkürzungsverzeichnis VI

Abkürzungsverzeichnis

ADF ......... Application Development Framework

AIX.......... Advanced Interactive Executive API .......... Application Programming Interface BAM ........ Business Activity Monitoring BPEL........ Business Process Execution Language BPEL4WS . Business Process Execution Language for Web Services BPM......... Business Process Management CEP ......... Complex Event Processing CORBA ..... Common Object Request Broker Architecture DTD......... Document Type Definition EAI.......... Enterprise Application Integration EDA ......... Event-Driven Architecture EDSOA ..... Event-Driven Service-Oriented Architecture EPA ......... Event-Processing Agent EPL.......... Event-Processing Language EPN ......... Event-Processing Network ERP ......... Enterprise Resource Planning ESB ......... Enterprise Service Bus GUI ......... Graphical User Interface HP-UX...... Hewlett Packard Unix HTTP ....... Hypertext Transfer Protocol IDE.......... Integrated Development Environment IEEE ........ Institute of Electrical and Electronics Engineers IIS ......... Internet Information Server IT............ Informationstechnologie JMS ......... Java Message Service JMX ......... Java Management Extensions LDAP ....... Lightweight Directory Access Protocol MOM........ Message-Oriented Middleware

OASIS...... Organization for the Advancement of Structured Information Standards QoS ........ Quality of Service RFID ........ Radio Frequency Identification RMI ......... Remote Method Invocation RPC ......... Remote Procedure Call SDK ........ Software Development Kit SGML....... Standard Generalized Markup Language SNMP....... Simple Network Management Protocol

Abkürzungsverzeichnis VII

SOA......... Service-Oriented Architecture

SOAP ....... Simple Object Access Protocol SSL ......... Secure Sockets Layer

UDDI ....... Universal Description, Discovery and Integration UDP......... User Datagram Protocol UML......... Unified Modeling Language URL ......... Uniform Resource Locator W3C ........ World Wide Web Consortium WSDL ...... Web Service Description Language XML ......... Extensible Markup Language

Einleitung 8

1 Einleitung

Die Fähigkeit, schnell und effektiv auf wechselnde Anforderungen und neue Chancen in einem zunehmend komplexeren Marktumfeld zu reagieren, wird immer mehr zu einer der relevantesten Qualitäten moderner IT-Systeme. Zum einen die historisch gewachsenen, oft heterogenen, Systeme und zum anderen die Notwendigkeit, sich schnell an zukünftigen Wandel anzupassen, erfordern eine flexible und skalierbare IT-Infrastruktur.

Die Integration der verschiedenen in Unternehmen vorhandenen Systeme ist ein viel beachtetes Thema der letzten Jahre geworden. Serviceorientierte Architekturen (Service-Oriented Architecture, SOA) bieten einen mittlerweile etablierten Best-Practice-Ansatz zur Schaffung einer flexiblen und skalierbaren Systemlandschaft [CeFP2005]. Hierzu werden vorhandene Softwareressourcen in wohl definierte und in sich geschlossene Einheiten transformiert, um so eine modulare und erweiterbare Infrastruktur zu schaffen.

Unabhängig von den Herausforderungen, die aus der Integration der Systeme entstehen, bestehen der Wunsch und die Notwendigkeit, Informationssysteme so zu gestalten, dass sie die Fähigkeit besitzen, agil und schnell auf Ereignisse innerhalb und außerhalb des Unternehmens zu reagieren. Ereignisgetriebene Architekturen (Event-Driven Architecture, EDA) verfolgen durch das Erkennen und systemweite Propagieren von Ereignissen dieses Ziel, auch vor dem Hintergrund, sinnvolle Korrelationen zwischen Ereignissen zu erkennen, um so auch auf zum Entwurfszeitpunkt ungekannte oder ungeahnte Szenarios reagieren zu können.

Führende Analysten sehen derzeit in der Kombination der beiden genannten Architekturen den wirtschaftlichsten und effektivsten Ansatz zum Entwurf der unternehmensweiten Informationssysteme [Mare2006; ScYe2006; Nati2003; Schu2004].

1.1 Motivation und Ziel der Arbeit

Im Zusammenhang mit der Forderung nach flexiblen und agilen Anwendungs-landschaften in Unternehmen wird zurzeit vermehrt über den Einsatz einer ereignisgesteuerten serviceorientierten Architektur (Event-Driven Service-Oriented Architecture, EDSOA) diskutiert. Dabei wird der Term der Ereignissteuerung beziehungsweise der Ereignisverarbeitung in Verbindung mit einer neuen Generation der SOA als Marketingschlagwort verschiedener Softwarehersteller verwendet [Orac2006f; TIBC2005a; SrRa2005, 18]. Allerdings herrscht parallel zu dem aufkommenden Interesse an der EDSOA kein einheitliches Verständnis über das Konzept der EDA und der SOA und folglich ebenso kein einheitliches Verständnis

Einleitung 9

über das Konzept der EDSOA [Etzi2006, 7]. Aus dieser Situation ergeben sich die Motivation und das Ziel dieser Arbeit, einen Beitrag zum Verständnis der EDSOA zu liefern. Dies impliziert, dass die jeweiligen Architekturen der SOA und EDA zunächst eingehend beschrieben, definiert und anschließend voneinander abgegrenzt werden müssen. Darüber hinaus soll auch ein vergleichender Überblick über Softwareprodukte im Bereich der EDSOA geliefert werden und eine Einordnung dieser Produkte in die Konzepte der EDA und SOA erfolgen.

1.2 Aufbau der Arbeit

Die Arbeit gliedert sich grob in drei Teile: in die Grundlagen, in die Erläuterungen zu der EDA, SOA und EDSOA und den abschließenden Überblick über Softwareprodukte im Bereich der EDSOA. Die Beschreibung der drei genannten Architekturen stellt dabei den Kern der Arbeit dar.

Innerhalb des Grundlagenkapitels werden zunächst die Begriffe Architekturinsbesondere Unternehmens- und Softwarearchitektur - sowie Service und Komponente definiert und voneinander abgegrenzt. Anschließend folgt ein Abschnitt zu der Kommunikation in verteilten Systemen. Das Grundlagenkapitel schließt mit der Betrachtung verschiedener Aspekte der Anwendungsintegration.

Auf die Grundlagen folgen die Betrachtung der SOA, EDA und EDSOA, denen jeweils ein eigenes Kapitel gewidmet ist. Das Kapitel „Service-Oriented Architecture“ beginnt mit einer Beschreibung der grundlegenden Funktionsweise einer SOA, gefolgt von einer ausführlichen Betrachtung der Prinzipien der Serviceorientierung. Aufbauend darauf werden die Merkmale der SOA erläutert und es wird eine Definition der SOA eingeführt. Das Kapitel schließt mit einer genaueren Betrachtung zu der Kopplung von Softwarekomponenten und zu den Implikationen bei dem Einsatz einer SOA. Innerhalb des Kapitels „Event-Driven Architecture“ werden zunächst grundlegende Begriffsbestimmungen vorgenommen. Anschließend werden die einzelnen Komponenten einer EDA erläutert und die verschiedenen Arten der Ereignisverarbeitung beschrieben. Im Anschluss daran werden die Merkmale einer EDA aufgezeigt und abschließend wird eine Definition der EDA gegeben. Das Kapitel „Event-Driven Service-Oriented Architecture“ beginnt aufbauend auf den beiden vorherigen Kapiteln mit einer Abgrenzung der EDA von der SOA. Dieser Abgrenzung folgt der Abschnitt über den Enterprise Service Bus, der die Grundlage einer EDSOA bildet. Abschließend wird eine Definition der EDSOA eingeführt.

Auf die Betrachtung der drei Architekturen folgen eine Beschreibung und Einord- nung von Softwareprodukten im Bereich der EDSOA. Hierzu werden zunächst

Einleitung 10

ausgewählte Produkte von Oracle und TIBCO vorgestellt, miteinander verglichen und anschließend in die Konzepte der EDA und SOA eingeordnet.

Die Arbeit schließt mit einer Zusammenfassung und einem Fazit. In dem Anhang zu dieser Arbeit werden verschiedene technologische Standards im Bereich der EDSOA beschrieben.

Grundlagen 11

2 Grundlagen

Hinsichtlich einer Einordnung und Abgrenzung der in dieser Arbeit zu behandelnden Architekturen werden innerhalb dieses Kapitels zunächst grundsätzliche Begrifflichkeiten wie Architektur, Service und Komponente erläutert und voneinander abgegrenzt. An die Ausführungen zu den Begrifflichkeiten schließt sich ein Abschnitt an, der die Kommunikation in verteilten Systemen zum Inhalt hat. In diesem werden die verschiedenen Kommunikationsverfahren erläutert und unter anderem auch die nachrichtenorientierte Middleware (Message-Oriented Middleware, MOM) vorgestellt, die als Grundlage für EDA, SOA und EDSOA dienen kann. Das Kapitel schließt mit einem Abschnitt über das Thema Anwendungsintegration, in dem unter anderem auf die verschiedenen Ebenen der Integration und mögliche Topologien eingegangen wird.

2.1 Begriffsbestimmung

Der Begriff der Architektur ist Element der Bezeichnungen der EDA, SOA und EDSOA. Im Hinblick darauf werden in dem folgenden Abschnitt zunächst der Begriff der Architektur und insbesondere auch die Begrifflichkeiten der Unternehmens-, IT- und Softwarearchitektur eingeführt. Anschließend werden die Begriffe Service und Komponente definiert und voneinander abgrenzt.

2.1.1 Architektur

Dem Begriff der Architektur unterliegen - je nach Zusammenhang, in dem er verwendet wird - verschiedene Bedeutungen und er folgt weder in der Wirt-schaftsinformatik noch im Allgemeinen einer einheitlichen Definition [Ai-Do2004, 80]. Der dem Griechischen entstammende Begriff lässt sich als „erstes Handwerk“ oder auch „erste Kunst“ übersetzten. Er findet seine Herkunft im Bauwesen und meint sowohl die Tätigkeit des Bauens als auch das Gebäude selbst [Scho2004, 8]. Unabhängig von dieser Betrachtung werden mit dem Begriff Architektur deskriptive, konstruktive und restriktive Aspekte assoziiert [LuVM2003, 3]. Das Verständnis von Architektur als Bauplan repräsentiert dabei den konstruktiven Aspekt, wobei die Anforderungen an das zu entwerfende System den restriktiven Aspekt widerspiegeln. Die deskriptive Sicht versteht Architektur als Beschreibung von Elementen eines Systems und deren Beziehungen untereinander. Das Institute of Electrical and Electronics Engineers (IEEE) definiert den Begriff der Architektur im Kontext der Informatik wie folgt:

„The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.“ [IEEE2000, 3]

Grundlagen 12

Architektur ist demnach die grundlegende Struktur eines Systems, verkörpert durch dessen Elemente und deren Beziehungen zueinander sowie zur Außenwelt, einschließlich der Prinzipien für den Entwurf und der Entwicklung eines solchen Systems.

Geht es um Architekturbetrachtungen innerhalb eines Unternehmens, existieren verschiedene Sichtweisen. Diese umfassen die Betrachtung der gesamten Unternehmensarchitektur, wie auch von Teilbereichen, etwa die Betrachtung der IT-Architektur oder der Anwendungsarchitektur (Softwarearchitektur). Die gemeinsame Zielsetzung dieser Architekturbetrachtungen liegt in der Herstellung einer abstrahierenden Sicht, welche die Erst- und Fortentwicklung des jeweiligen betrachteten Systems unterstützt [Platt2002]. Im Hinblick auf eine spätere Einordnung der in dieser Arbeit betrachteten Architekturen ist es notwendig, die verschiedenen Architekturformen innerhalb eines Unternehmens genauer zu betrachten. Im Folgenden wird zunächst der Begriff der Unternehmensarchitektur eingeführt.

Unternehmensarchitektur

Die Geschäftsstrategie und Geschäftsprozesse sowie die Organisation eines Unternehmens einschließlich der eingesetzten technologischen Infrastruktur und Systeme wird oft unter dem Begriff Unternehmensarchitektur subsumiert [Platt2002]. ZACHMANN greift in seiner Definition des Begriffes Unternehmensarchitektur die drei zuvor genannten - deskriptiven, restriktiven und konstruktiven - Aspekte auf und kommt zu der folgenden Definition:

„[Enterprise architecture is] that set of descriptive representations (models) that are relevant for describing an Enterprise such that it can be produced to management’s requirements (quality) as well as maintained over the period of its useful life (change).“ [Zach1997, 5]

Er sieht die Unternehmensarchitektur also als eine Menge von Modellen, die in jener Hinsicht relevant für die Beschreibung eines Unternehmens sind, als dass sie zur Umsetzung von Anforderungen dienen und über einen entsprechenden Zeitraum aufrechterhalten werden können. AIER UND DOGAN betonen in ihrer Betrachtung den konstruktiven Charakter einer Architektur und definieren den Begriff der Unternehmensarchitektur wie folgt:

„[Die Unternehmensarchitektur ist] eine abstrakte, ganzheitliche Betrachtung von Strukturen und Mustern mit Planungscharakter […] [sowie] das Zusammenwirken or-ganisatorischer, technischer und psychosozialer Aspekte bei der Planung und Entwick- lung betrieblicher soziotechnischer Informationssysteme.“ [AiDo2004, 81]

Grundlagen 13

Aufbauend auf dieser Definition differenzieren AIER UND DOGAN die Unternehmensarchitektur in die Bereiche Organisations- und IT-Architektur, dargestellt in Abbildung 2.1.

Abbildung 2.1: Bestandteile der Unternehmensarchitektur Quelle: [AiDo2004, 81]

AIER UND DOGAN stellen fest, dass die Begriffe Organisationsarchitektur und IT-Architektur in der Literatur unterschiedlich abgegrenzt sind. Sie nehmen daher eine Festlegung anhand der Unterteilung in technische und nicht-technische Elemente vor. Alle nicht-technischen Bestandteile der Unternehmensarchitektur finden sich demnach in der Organisationsarchitektur wieder. Eine Organisation wird dabei als „Instrumentarium zur Erreichung der Ziele sozialer Systeme“ [Ai-Do2004, 82] verstanden. Alle technischen Bestandteile wiederum, insbesondere die Informationssysteme, sind Betrachtungsgegenstand der IT-Architektur.

IT-Architektur

Über diese Differenzierung hinaus findet sich keine weitere Definition der Begrifflichkeiten in den Ausführungen von AIER UND DOGAN [AiDo2004, 82ff.]. Eine Definition der IT-Architektur liefert hingegen DERN:

^{„Eine IT-Architektur ist die strukturierende Abstraktion existierender oder geplanter In-formationssysteme. Die Abstraktion schafft die gemeinsame Kommunikationsplattform aller an der Gestaltung von Informationssystemen Beteiligten, um so die Planbarkeit und die Steuerbarkeit der Gestaltung realer, miteinander in Wechselwirkung stehender Entitäten der IT eines Unternehmens zu erhöhen.“ [Dern2003, S. 18]} Diese Definition betont den konstruktiven Aspekt der Architektur und stellt die abstrahierende Sicht auf die Informationssysteme als Unterstützung zur Entwick-

Grundlagen 14

lung dar. ALBIN sieht die IT-Architektur als Summe der System- und Softwarearchitektur und definiert den Begriff wie folgt:

„The IT architecture defines the hardware and software building blocks that make up the overall information system of the organization. […] The IT architecture should enable achievement of the business goals using a software infrastructure that supports the procurement, development, and deployment of core mission-critical business applications.” [Albi2003, 15]

IT-Architektur beschreibt hiernach alle Hard- und Softwarekomponenten der In-formationssysteme eines Unternehmens mit dem Zweck der Schaffung einer Infrastruktur, die auf die Erreichung der Geschäftsziele ausgerichtet ist.

Zusammenfassend kann die IT-Architektur als Entwurfsmuster für alle geplanten Informationssysteme angesehen werden, das gleichzeitig eine deskriptive Sicht auf die existierende Struktur aller Systeme bietet. Darüber hinaus richtet sie sich an der optimalen Erreichung der Geschäftsziele aus.

Die Softwarearchitektur als Teil der IT-Architektur und Thema des folgenden Abschnitts ist im Kontext dieser Arbeit von besonderer Relevanz, da eine SOA und mitunter auch eine EDA oft als solche verstanden wird.

Softwarearchitektur

Als Grundlage kann zunächst die verbreitete Definition von BASS ET AL. angeführt werden:

^{„The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.“ [BaCK2003, 21]} Diese Definition bestimmt Softwarearchitektur als Struktur oder Strukturen eines Systems von Softwareelementen, ihren nach außen sichtbaren Eigenschaften sowie ihren Beziehungen zueinander.

Die Einbeziehung von Entwurfsprinzipien, die auch ein elementarer Aspekt einer SOA sind, betont das Verständnis von Architektur als Entwurfsschema. Dieses Verständnis wird auch deutlich in der Definition von KRAFZIG ET AL.:

„A software architecture is a set of statements that describes software components and assigns the functionality of the system to these components. It describes the technical structure, constraints, and characteristics of the components and the interfaces between them. The architecture is the blueprint for the system and therefore the implicit high-level plan for its construction.” [KrBS2005, 56]

Als Essenz dieser Definition - wie auch der des IEEE - lässt sich ein Verständnis von Architektur als Strukturbetrachtung sowie als Entwurfsschema feststellen. Ausgehend von der bereits eingeführten Definition des IEEE wird Softwarearchi- tektur im Folgenden als die Organisation einer Anwendung, verkörpert durch

Grundlagen 15

deren Komponenten, deren Beziehungen zueinander und zur Umgebung einschließlich der Prinzipien zum Design und zur Entwicklung angesehen.

2.1.2 Service

Der Begriff Service ist ein häufig verwendeter Anglizismus innerhalb der Informationstechnologie und entstammt dem klassischen Client/Server-Prinzip, wobei ein Server dem Client einen Dienst, also einen Service, zur Verfügung stellt [Le-wa1998]. Ähnlich zu dem Begriff Architektur existiert auch für den Begriff Service eine Vielzahl unterschiedlicher Definitionen. Das World Wide Web Consortium (W3C) definiert den Begriff Service wie folgt:

„A service is an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of providers entities and requesters entities. To be used, a service must be realized by a concrete provider agent.” [W3CG2004]

Ein Service ist demnach eine abstrakte Ressource, die eine, aus der Sicht von Anbietern und Nachfragern, kohärente Funktionalität zur Verfügung stellt. KRAF- ZIGET AL. liefern eine Definition, die ähnlich zu der des W3C, die in sich geschlossene Funktionalität hervorhebt, darüber hinaus aber auch konkreter auf die Be-standteile eines Service eingeht.

^{„A service is a software component of distinctive functional meaning that typically encapsulates a high-level business concept. It consists of both data and business logic along with interfaces and their descriptions.” [KrBS2005, 59]} Dementsprechend ist ein Service eine Softwarekomponente, die eine bestimmte funktionelle Bedeutung hat und typischerweise Geschäftslogik kapselt. Ein Service besteht aus Geschäftsdaten, Geschäftslogik, Schnittstellen und deren Beschreibungen. Diese Definition nimmt Bezug auf den Begriff der Komponente und impliziert damit das Verständnis eines Service als eine spezielle Form der Komponente. Da der Komponente aber ein Verständnis als binäre Softwareeinheit zugrunde liegt - wie der folgende Abschnitt zeigen wird - bietet sich die Definition von KRAFZIG ET AL. hier nicht an. Daher wird im Kontext dieser Arbeit die Definition des W3C zugrunde gelegt.

2.1.3 Komponente

SZYPERSKI ET AL. definieren den Begriff der Komponente, indem sie die Merkmale einer Komponente beschreiben:

„A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed inde- pendently and is subject to composition by third parties.” [SzGM2002, 41]

Grundlagen 16

Eine Komponente ist demnach Gegenstand einer Komposition und besitzt vertraglich spezifizierte Schnittstellen und Abhängigkeiten. Sie kann unabhängig von anderen Komponenten eingesetzt und dabei von Dritten genutzt werden. Um die Unabhängigkeit einer Komponente zu erreichen, muss diese von ihrer Umwelt und anderen Komponenten klar abgegrenzt werden. Diese Abgrenzung geschieht durch die Kapselung der Implementierung einer Komponente. Die Trennung von Implementierung und Schnittstellendefinition und die damit einhergehende Abgrenzung zur Außenwelt sind die bestimmenden Merkmale einer Komponente [CrLa2002, 5].

D’SOUZA UND WILLS unterscheiden zwischen einer allgemeinen Definition des Begriffs und einer zweiten Definition, die eine Komponente als compilierten Code ansieht. Diese zweite Definition beschreibt wiederum sehr präzise die Merkmale einer Komponente:

^{„A coherent package of software Implementierung that (a) has explicit and wellspecified interfaces for the services it provides; (b) has explicit and well-specified interfaces for services it expects from others; and (c) can be composed with other components, perhaps customizing some of their properties, without modifying the components themselves. As a consequence of these properties, a component can be independently developed, delivered, and deployed as a unit.” [SoWi1999, 716]} D’SOUZA UND WILLS sehen eine Komponente als eine zusammenhängende Einheit, die über wohl definierte Schnittstellen zu den Diensten, die sie bereitstellt oder von anderen erwartet, verfügt. Darüber hinaus kann sie Kompositionen mit anderen Komponenten eingehen, die möglicherweise die Eigenschaften der Komponente verändern, nicht aber die Komponente an sich. Die Konsequenz dieser Eigenschaften ist, dass eine Komponente unabhängig entwickelt und implementiert werden kann.

Die Merkmale und Eigenschaften von Komponenten und Services sind eng ver-wandt. Als ein Hauptunterscheidungsmerkmal wird die binäre beziehungsweise kompilierte Form der Komponente im Gegensatz zu der abstrakten Erschei-nungsform eines Service angesehen, der nicht zwangsweise als binäre Einheit vorliegen muss [Vast2004; KaBu2003, 2]. Darüber hinaus sind Komponenten typischerweise feingranularer und stärker gekoppelt als Services [HelloJ].

Der nun folgende Abschnitt des Grundlagenkapitels befasst sich mit der interprozessualen Kommunikation in verteilten Systemen.

2.2 Kommunikation in verteilten Systemen

Die Grundlage eines verteilten Systems ist die Kommunikation zwischen entfern- ten Prozessen. Die Informationstechnologie kennt hierzu diverse Mechanismen,

Grundlagen 17

um Daten zwischen Prozessen eines verteilten Systems zu übertragen. In den folgenden Abschnitten wird zunächst auf die Synchronität und Persistenz bei der Kommunikation eingegangen. Darauf aufbauend werden mit dem Remote Procedure Call (RPC) und der MOM zwei - für serviceorientierte und ereignisgesteuerte Architekturen relevante - Methoden der Kommunikation behandelt.

2.2.1 Synchronität und Persistenz

Bei der Kommunikation in einem verteilten System wird zwischen synchroner und asynchroner sowie persistenter und nicht-persistenter Kommunikation unterschieden [TaSt2002, 99ff.]. Ein zugrunde liegendes Kommunikationssystem gewährleistet Persistenz, wenn es eine Nachricht so lange sicher speichert, bis diese zugestellt worden ist. Dies bedeutet, dass ein Sender eine Nachricht verschicken kann, ohne dass der Adressat der Nachricht aktiv sein muss. Die persistente Kommunikation findet beispielsweise bei der domänenübergreifenden Integration von Anwendungen in weit verteilten Netzwerken Anwendung. Die asynchrone Kommunikation ist dadurch gekennzeichnet, dass ein Sender direkt nach dem Versand einer Nachricht weiter operieren kann. Ein Beispiel für persistente asynchrone Kommunikation ist die E-Mail. Bei dem Versand einer E-Mail wird diese zunächst vom Host des Versenders an einen Server übertragen, der die Nachricht speichert und so Persistenz gewährleistet. Die Nachricht wird dann von diesem Server zu dem E-Mail-Server des Empfängers geroutet, der die Nachricht wiederum für den Empfänger-Host bereitstellt. Asynchronität ist gegeben, da der Versender der E-Mail nicht blockiert wird, bis diese zugestellt worden ist, sondern direkt fortfahren kann. Ein Beispiel für die nicht-persistente asynchrone Kommunikation ist das User Datagram Protocol (UDP), bei dem der versendende Host davon ausgeht, dass der Empfängerprozess zum Zeitpunkt des Empfangs der Nachricht aktiv ist [TaSt2002, 102]. Abbildung 2.2 veranschaulicht die persistente asynchrone Kommunikation (a) sowie die nicht-persistente asyn- chrone Kommunikation (b).

Grundlagen 18

(a) persistente

asynchrone Kommunikation

(b) nicht-persistente

asynchrone Kommunikation

Abbildung 2.2: Persistente und nicht-persistente asynchrone

Liegt eine synchrone Kommunikation vor, ist der Sender nach dem Versand so lange blockiert, bis er eine Bestätigung über das Zustellen der Nachricht erhält. Abbildung 2.3 zeigt die verschiedenen Varianten der synchronen Kommunikati- on.

Grundlagen 19

A sendet Nachricht und wird blockiert bis zum Erhalt der Bestätigung

(c) persistente

synchrone Kommunikation

Nachricht wird zur späteren

Zustellung gespeichert

(d) nicht-persistente synchrone

Kommunikation (schwächste Form)

(e) nicht-persistente synchrone

Kommunikation (stärkere Form)

A sendet Nachricht und wird blockiert bis zum Erhalt der Bestätigung

(f) nicht-persistente synchrone

Kommunikation (stärkste Form)

Abbildung 2.3: Persistente und nicht-persistente synchrone

Bei der persistenten synchronen Kommunikation (c) wird die Nachricht nach dem Versand an Host B bei diesem gespeichert, falls der adressierte Prozess nicht aktiv ist. Die nicht-persistente synchrone Kommunikation kann, je nach Stärke der Blockierung, in drei weitere Varianten unterteilt werden. Bei der schwächsten

Grundlagen 20

Form (d) wird der sendende Prozess so lange blockiert, bis er die Bestätigung über die Ankunft der Nachricht im lokalen Puffer des adressierten Prozesses auf Host B erhält. Bei einer stärkeren Form der Synchronität (e) ist der Sender so lange blockiert, bis er die Bestätigung über den Beginn der Verarbeitung der Nachricht vom Empfänger erhält. Bei der stärksten Form der nicht-persistenten synchronen Kommunikation (f) dauert die Blockierung so lange an, bis die Bestätigung vom Empfängerprozess über das Ende der Verarbeitung der Nachricht erhalten worden ist.

Thema des nächsten Abschnittes ist der Remote Procedure Call (RPC), der ein Beispiel für eine solche Art (f) der Kommunikation ist [TaSt2002, 102].

2.2.2 Remote Procedure Call

Der Remote Procedure Call (RPC) wurde 1983 von BIRRELL UND NELSON eingeführt mit dem Ziel, Zugriffstransparenz bei dem Aufruf von Prozeduren auf entfernten Systemen zu gewährleisten [BiNe1983; TaSt2002, 65ff.]. Die Methode basiert auf der Idee einen entfernten Prozeduraufruf durchzuführen, ohne dass ein für den Entwickler sichtbarer Nachrichtenaustausch stattfindet [TaSt2002, 66]. Wenn ein Prozess auf System A durch einen RPC eine Prozedur auf System B aufruft, wird der aufrufende Prozess auf A unterbrochen und die Ausführung der aufgerufenen Prozedur auf B begonnen. Dadurch, dass sich der Aufruf einer entfernten Prozedur für den aufrufenden Prozess nicht von einer Ausführung einer lokalen Prozedur unterscheidet, gewährleistet der RPC Zugriffstransparenz. Dies wird erreicht, indem der aufrufende Prozess zunächst einen lokalen Client-Stub aufruft, welcher den Aufruf wiederum als Nachricht an das lokale Betriebssystem übergibt. Das lokale Betriebssystem überträgt diese Nachricht dann an das entfernte Betriebssystem, welches die Nachricht an den entfernten Server-Stub übergibt. Der Server-Stub entpackt daraufhin die Aufrufparameter aus der Nachricht und ruft die gewünschte Prozedur auf. Nach Ausführung der Prozedur übergibt diese ihr Resultat wieder an den Server-Stub, welcher das Resultat als Nachricht an das entfernte Betriebssystem übergibt. Die Nachricht wird im Anschluss wieder an das lokale Betriebssystem gesendet und das aus der Nachricht entpackte Resultat vom Client-Stub an den lokalen Prozess übergeben. Dieses Verfahren entspricht der - unter (f) in Abbildung 2.3 dargestellten - stärksten Form der nicht-persistenten synchronen Kommunikation. Das durch dieses Verfahren implizierte Blockieren des aufrufenden Prozesses ist nicht immer wünschenswert, beispielsweise für den Fall, dass die aufrufende Prozedur kein Resultat zurückliefert. Für solche Situationen existiert eine asynchrone Variante des RPC, dargestellt in Abbildung 2.4.