Inhaltsverzeichnis

INHALTSVERZEICHNIS   

1.  EINLEITUNG  1

2.  ABGRENZUNG ENTERPRISE APPLICATION INTEGRATION.  2

2.1  EAI Integrationsarten.  2

2.2  EAI Architekturen  5

2.2.1  Point-to-Point  5

2.2.2  Hub Spoke  5

2.2.3  Bus-oriented  6

2.2.4  Distributed Objects.  6

2.3  Technologien einer EAI.  7

2.3.1  J2EE mit RMI  7

2.3.2  CORBA  8

2.3.3  Web-Services  8

2.3.4  Microsoft NET / DCOM.  9

2.4  Kommunikation innerhalb verteilter Anwendungen  9

3.  VERTIEFUNG SOA MIT WEB-SERVICES  11

3.1  Serviceorientierte Architektur  11

3.1.1  Begriffsklärung und Definitionen SOA  12

3.1.2  Merkmale und Funktionsweise SOA  13

3.2  Web-Services.  15

3.2.1  Begriffsklärung und Definition Web-Services  15

3.2.2  Merkmale und Funktionsweise Web-Services  16

3.2.3  Beschreibungssprache und Verzeichnisdienst der Web-Services  17

3.2.4  SOAP-Protokoll  19

3.2.5  XML-RPC Protokoll.  21

3.2.6  REST Protokoll  22

4.  BEGRIFFSDEFINITIONEN DER FACHLICHEN SICHT  23

4.1  Vorgehensmodelle der Anwendungsentwicklung  23

4.1.1  Wasserfallmodell  23

4.1.2  Inkrementelles und iteratives Modell  24

II

Inhaltsverzeichnis

4.1.3  Agile Programmierung in der Anwendungsentwicklung.  24

4.2  Business Process Modeling Notation  25

4.3  Business Process Execution Language.  25

4.4  XML Process Definition Language  26

5.  LEITFADEN ZUR GESTALTUNG EINER SOA  27

5.1  Schritt 0: Vorbereitung - Perspektive definieren  27

5.2  Schritt 1: Vorhandene IT-Landschaft analysieren  30

5.3  Schritt 2: Geschäftsprozessanalyse  32

5.4  Schritt 3: Architektur-Strategie festlegen  34

5.4.1  Strategie einer vollständigen Umsetzung  37

5.4.2  Strategie einer teilweisen Umsetzung.  38

5.5  Schritt 4: Servicemodell aufbauen  39

5.5.1  Services identifizieren  40

5.5.2  Services kategorisieren  42

5.6  Schritt 5: Technologiewahl.  43

5.6.1  Entscheidungsparameter einer Technologiewahl  43

5.6.2  Technologie festlegen  53

5.6.3  Umsetzung Web-Service Technologie  56

5.6.4  Messaging-Infrastruktur  58

5.7  Schritt 6: Komponentenmodell aufbauen  61

5.8  Schritt 7: Testen erster Realisierung der Services.  63

5.9  Schritt 8: Beschreibung der Services  65

5.10  Schritt 9: Registry einbinden  66

5.10.1  Perspektive des Clients: Serviceabfrage.  68

5.10.2  Service publizieren  71

5.11  Schritt 10: Services orchestrieren  75

5.12  Schritt 11: Testen orchestrierter Services  79

5.13  Schritt 12: Governance planen  80

5.13.1  IT-Governance im Allgemeinen  80

5.13.2  IT-Governance in Bezug auf das SOA-Projekt  81

III

Inhaltsverzeichnis

5.14  Schritt 13: Testen unter Einbeziehung des Policy-Modells  83

6.  SCHLUSSBEMERKUNG UND AUSBLICK  85

7.  LITERATURVERZEICHNIS  VIII

IV

Abbildungsverzeichnis   

ABBILDUNGSVERZEICHNIS   

Abbildung  1: Erweiterte Funktionsintegration.  

Abbildung  2: Prozessintegration  

Abbildung  3: SOA-Haus.  

Abbildung  4: Rollen einer Web-Services Technologie  

Abbildung  5: Verständnis geschäftsorientierter Implementierung,  

Abbildung  6: Aspekte und Abhängigkeiten einer Web-Service-Architektur  

Abbildung  7: SOA -Schichten.  

Abbildung  8: Rollen eines Servicemodells,  

Abbildung  9: Clientseitige Komponentengenerierung  

Abbildung  10: Verteilte Objekte und Firewalls.  

Abbildung  11: Kombinierte Technologien  

Abbildung  12: Web-Service-Technologie mit und ohne Integrationslayer  

Abbildung  13: Möglicher SOA-Architekturentwurf  

Abbildung  14: Schematischer Aufbau einer WSDL-Beschreibung.  

Abbildung  15: WSDL2UDDI-Mapping  

Abbildung16  : Architekturmodell Einordnung BPEL-Prozess.  

Abbildung  17: Service-Orchestrierung  

Abbildung  18: Zugriffe auf Daten mittels Wrapper-Services  

V

Tabellenverzeichnis   

TABELLENVERZEICHNIS   

Tabelle 1:  Definition des Begriffs Serviceorientierte Architektur  12

Tabelle 2:  Definition des Begriffs Serviceorientierte Architektur  15

Tabelle 3:  Vergleich Technologien einer verteilten Architektur  44

Tabelle 4:  UDDI-Informationsmodell (Auszug)  68

Tabelle 5:  UDDI-Knoten API (Auszug)  69

Tabelle 6:  Zugriffspunkt-URLs für Anfrage.  71

Tabelle 7:  Nachrichten der UDDI-API (Auszug)  72

Tabelle 8:  Zugriffspunkt-URLs für Veröffentlichungen  73

VI

LISTINGVERZEICHNIS

Listing 1: Schematischer Aufbau einer SOAP-Nachricht .................................... 20 Listing 2: XML-RPC Dokument ...................................................................... 21 Listing 3: Erzeugung einer Implementierungsklasse mit JAX-RPC ...................... 47 Listing 4: WS-Addressing in SOAP-Nachricht .................................................. 60 Listing 5: Anfrage UDDI .............................................................................. 69 Listing 6: BPEL-Datei .................................................................................. 76

ABKÜRZUNGSVERZEICHNIS

BPM Business Process Modelling BPMN Business Process Modelling Notation CORBA Common Object Request Broker Architecture EDI Electronic Data Interchange FTP File Transfer Protokoll HTTP Hypertext Transport Protokoll J2EE Java Platform Enterprise Edition (Java EE) JCA Java Connector Architecture JMS Java Message Service MMAP Mobile Message Access Protocol REST Representational State Transfer RMI (Java) Remote Method Invocation SMTP Simple Mail Transport Protokoll SOAP Simple Access Object Protocol SQL Structured Query Language UDDI Universal Description, Discovery and Integration UML Unified Modelling Language WSDL Web Services Description Language XML eXtensible Markup Language XPDL XML Process Definition Language

1. EINLEITUNG

Seit Ende der 80er Jahre verfügen Unternehmen zunehmend über ein heterogenes und dezentralisiertes IT-Umfeld, dessen Vorteile wie Schnelligkeit und Ausfallsicherheit bezüglich der Prozessverarbeitung aber auch neuen

Problemstellungen wie redundanter Datenhaltung, Datensynchronisation und Prozessintegration gegenüber standen. In der Softwareentwicklung spiegelte sich dies in neuen Abstraktionen wie Sockets, Remote Procedure/Function Calls (RPC/RFC) und CORBA zur Verteilung einer Anwendung auf heterogener IT-Umgebung wider. Es entstand eine Vielzahl von Schnittstellen, die einen hohen Realisierungs- und Wartungsaufwand erforderten.

Anstatt weiterhin aufwendige Punkt-zu-Punkt-Lösungen zu entwickeln, ging der Trend zu MOM (Message Oriented Middleware), bei der Daten in Pakete gepackt und als Nachrichten an eine Middleware übergeben werden. Um generische Aufgaben in einer MOM zentral zu realisieren, wurden Message Broker zur Verwaltung und zum Versand von Nachrichten eingesetzt, wodurch die Anbindung eines gegebenen Systems durch die einmalige Anbindung an einen solchen Präsentationshub durch einen Adapter gelöst werden konnte. Der Datenaustausch zwischen Unternehmen wurde auf Basis von VANs (Value Added Network) implementiert, mit anderen Worten, jedes Unternehmen musste ein Gateway (das der Spezifikation des VAN entsprach) implementieren. Es bildeten sich branchen- und länderspezifische Standards wie EDI (Electronic Data Interface) oder auf UN-Ebene EDIFACT heraus. Mit Einzug der Internettechnologie in die Unternehmenswelt entstanden vielversprechende Möglichkeiten zur Entwicklung generischer Plattformen und Produkte (wie J2EE oder DCOM/.NET), die den Datenaustausch über die TCP/IP Infrastruktur des Internets abzuwickeln vermochten.

Auch heute noch sind serviceorientierte Architekturen im Zusammenhang mit Web-Services sowohl in der Managerwelt als auch in der IT-Welt ein ausgesprochenes Hype-Thema, was unter anderem auch an der Unschärfe des Begriffs „SOA“ liegen dürfte. 1

¹ Vgl. [Channabasavaiah/ibm 2003 ], [Möller 2006] S.35ff, [jeckele.de], [servicearchitecture.com],[Melzer,Dostal,Jeckle,Zengler 2005]

1

2. ABGRENZUNG ENTERPRISE APPLICATION

INTEGRATION

Das primäre Ziel einer Enterprise Application Integration, folgend EAI genannt, ist die Verknüpfung existierender und neuer Applikationen in einer heterogenen IT-Landschaft. Diese Verknüpfung wird auf der Basis gemeinsamer Daten, Funktionen oder auch Geschäftsprozesse realisiert. So wird ein Datenaustausch zwischen den Applikationen ohne Medienbruch ermöglicht. Ein Integrationsserver stellt dabei ein Software-Paket, also ein EAI-Produkt, zur Realisierung einer beschriebenen Komponentenverknüpfung dar.

Die möglichen Formen einer Enterprise Integration unterscheiden sich in Bezug auf die Reichweite der zu realisierenden Geschäftsprozesse:

• A2A (Application to Application) - der Geschäftsprozess wird innerhalb des Unternehmens oder der Organisation realisiert,

• B2B (Business to Business) - der Geschäftsprozess wird zwischen verschiedenen Unternehmen bzw. Organisationen umgesetzt, beispielsweise über das Internet,

• B2C (Business to Customer) - in dieser Form einer Integration wird der Endkunde in den Geschäftsprozess integriert, beispielsweise ein browserbasierter Webclient.

2.1 EAI Integrationsarten

Die Integration innerhalb eines Systems wird in verschiedene Arten der Integration unterteilt:

Innerhalb einer Datenintegration nutzen Anwendungen denselben Datenbestand und tauschen Daten über ein festgelegtes Format aus. Eine beispielhafte Umsetzung einer Datenintegration wäre eine Schnittstelle für XML oder CVS.

Eine Dialog- bzw. GUI-Integration ermöglicht durch den Einsatz der Web-Technologie eine funktionale Trennung von Benutzereingaben sowie eine Zusammenfassung der Daten in Frames. Eine beispielhafte Umsetzung einer

Dialogintegration wäre die Realisierung eines Portals mit einem Portlet für Suchfunktionalität und einem weiteren Portlet für einen Blog auf einer Website.

Bei einer Funktionsintegration stellen die verschiedenen Anwendungen ein API (Application Programming Interface) zur Verfügung. Somit kann eine Anwendung die Funktion einer anderen Anwendung ausführen. Diese Art der Integration ist häufig, aber nicht zwingend, synchroner Natur, da diese auf Interaktion zwischen anfragendem Client und antwortendem Server stattfindet.

Eine Komponentenintegration stellt eine Erweiterung einer Funktionsintegration dar. Diese findet bei großen Applikationen Anwendung, wobei die Komponenten eine Bündelung von Funktionen darstellen, mit anderen Worten, die verteilte Funktionalität ist in unterschiedlichen Adressräumen (auf verschiedenen Servern) lokalisiert. Eine solche Integration kann beispielsweise auf Basis von COM/DCOM, CORBA oder EJB-Containern (J2EE) realisiert werden. Je nach Komplexität kann dies mittels eines einfachen Plug-ins, eines Integrationsservers (verwaltet alle Daten und Funktionsaufrufe, Verbindung über Scriptsprache) oder eines Containers umgesetzt werden. Eine beispielhafte Umsetzung einer Komponentenintegration wäre eine J2EE-Architektur mit EJB-Containern für die Datenverarbeitung und einem JSP-Container für die Dateneingabe/Oberfläche (verwenden EJB-Methoden). Folgende Abbildung verdeutlicht die möglichen Technologien zur Umsetzung einer erweiterten Funktionsintegration:

• RMI (Remote Method Invocation) des Herstellers SUN ist eine Art Java-RPC Mechanismus, um mit entfernten Objekten zu kommunizieren und deren Methoden aufzurufen (siehe J2EE) und nutzt keine nachrichtenbasierte Kommunikation, sondern direkte Verbindungen zur Client/Server-Kommunikation,

• CORBA (Common Object Request Broker Architecture) des Herstellers OMG ist ein Framework für verteilte Software-Komponenten für unterschiedliche Programmiersprachen (siehe CORBA) und nutzt einen nachrichtenbasierten Message Broker,

• DCOM (Distributed Component Object Model) des Herstellers Microsoft macht COM-Objekte über das Netz zugänglich (siehe .NET), unter Verwendung eines binären Protokolls über TCP/IP oder SOAP,

• RPC (Remote Procedure Call) ermöglicht entfernte Methodenaufrufe innerhalb eines Netzwerks,

• Web-Services unter Verwendung von SOAP, RPC-XML oder REST (im weitesten Sinne, konkrete Untersuchung folgt in folgenden Kapiteln) können einen nachrichtenbasierten Enterprise Service Bus, nachfolgend ESB genannt, nutzen.

Die letzte vorgestellte Art einer Integration ist die Prozessintegration. In diesem Fall durchläuft ein Prozess alle notwendigen Applikationen, die von einer Prozesssteuerung aufgerufen werden. Dabei werden Teilprozesse so gesteuert, dass die Daten und der Status des übergeordneten Prozesses an die nachfolgende Applikation weitergegeben werden. Die Steuerung wird von einer Zwischenschicht (beispielsweise einem ESB), nachfolgend als Middleware bezeichnet, übernommen, die Daten und Ablauf standardisiert und kontrolliert. Folgende Abbildung verdeutlicht das Konzept einer Prozessintegration innerhalb einer verteilten Umgebung ² :

² [Müller 2005], S.5, S.35ff, [Fletcher/Waterhouse], S.42ff.

4

Kapitel 5.11 beschreibt die Aspekte der Umsetzung einer Prozessintegration innerhalb einer dienstorientierten Architektur detailliert.

2.2 EAI Architekturen

Das folgende Kapitel erläutert die geläufigsten Architekturtechnologien Point-to-Point, Hub & Spoke, Bus-oriented sowie Distributed Objects.

2.2.1 Point-to-Point

Diese Form der Architektur unterscheidet nicht zwischen Client und Server, da die beteiligten Applikationen direkt miteinander verbunden werden, um (auch wechselseitig) auf benötigte Daten zuzugreifen. Unidirektionale und bidirektionale Schnittstellen werden häufig auf Basis von XML-Dokumenten, die manuell ausgetauscht werden, implementiert. Resultierend ergibt sich ab einem gewissen Grad an Komplexität des Systems eine hohe Anzahl an zu realisierenden Schnittstellen, deren Wartungsaufwand einen eindeutigen Nachteil darstellt.

2.2.2 Hub & Spoke

Das zentrale Element dieser Architektur ist ein Message Broker - ein Hub umgeben von Speichen (Spoke) -, der die Kommunikation über Schnittstellen zwischen

Message Broker und der Anwendung innerhalb des Systems verwaltet. Der Implementierungsaufwand ist für den Grad an Flexibilität des Systems überschaubar. Die Anzahl der Schnittstellen entspricht der Anzahl an beteiligten Anwendungen innerhalb des Systems. Als Nachteil gilt der so genannte Flaschenhalseffekt - die Leistungsfähigkeit des Systems ist abhängig vom Server. Diese Art der Architektur ist in der Unternehmenswelt weit verbreitet und wird in der Literatur oft als Best Practice bezeichnet.

2.2.3 Bus-oriented

Ein Bus stellt über Schnittstellen (zwischen Anwendungen und Bus) die zentrale Verbindung zwischen den beteiligten Anwendungen eines Systems dar. Hier werden durch Master/Slave-Kategorisierungen der Teilnehmer Daten und Funktionen ausgetauscht. Dies ermöglicht die Auflösung komplexer Strukturen sowie eine effiziente Lastenverteilung. Auch hier entspricht die Anzahl der Schnittstellen der Anzahl an beteiligten Anwendungen innerhalb des Systems. 3

2.2.4 Distributed Objects

Diese Form der Architektur im weitesten Sinne kennt kein zentrales Element, da autonome Objekte dezentral über das System verteilt werden. Diese werden ebenso autonom über Schnittstellen angesprochen. Hierzu kann eine komponentenorientierte oder nachrichtenorientierte Zwischenschicht (Middleware) verwendet werden. Komponenten-orientierte Middleware stellt ein erweitertes RPC-Konzept dar und ermöglicht den Datenaustausch mittels synchroner Kommunikation über standardisierte Schnittstellen und Protokolle.

Nachrichtenorientierte Middleware stellt weniger eine Anwendungsplattform dar, sondern tauscht Daten auf Basis von Nachrichten (Datenfolge, die von Anwendung gelesen wird) aus.

Verteilte Architekturen können grob betrachtet (Aspekt der Dienstverzeichnisse mit Schnittstellenbeschreibungen nicht betrachtet) als erste Realisierungen einer SOA betrachtet werden. 4

³ [Müller 2005],S.53 ff., [Arier/Schönherr],S.6

⁴ [Melzer,Dostal,Jeckle,Zengler 2005], S.37 ff, [Downdeswell/Lutteroth 2005],S.57 ff

6

2.3 Technologien einer EAI

Im folgenden Kapitel werden die möglichen Technologien zur Umsetzung einer EAI-Integration, und damit einer verteilten Architektur, vorgestellt. Die einzelnen Ausprägungen der Eigenschaften einer Technologie wie Objektorientiertheit, Interoperabilität, Kommunikation und Transport, Schnittstellenspezifikation, dynamische Stuberzeugung oder Prozessorientiertheit werden in Kapitel 5.6 ausführlich für die vorgestellten Technologien (ausgenommen .NET) untersucht. Dieses Kapitel soll einen Überblick über später untersuchte Technologien geben.

2.3.1 J2EE mit RMI

Java Enterprise Edition spezifiziert unterschiedliche Container und definiert vier verschiedene Schichtenmodelle für serverseitige Software-Komponenten. Die implementierten Systeme werden über das Intra- oder Internet verwendet. Die Datenschicht wird gewöhnlich durch eine relationale Datenbank realisiert, die über einen Message Service (JMS) oder eine datenbankunabhängige Schnittstelle mit den darüberliegenden Schichten Daten austauscht. Die Geschäftslogik der Anwendung ist innerhalb der Business Layer gekapselt. Die Methoden der Geschäftslogik werden über Protokolle (beispielsweise RMI-IIOP oder RMI-JRMP) aus der darüberliegenden Schicht (Web-Layer) aufgerufen. Der Web-Layer enthält die Präsentationslogik zur Darstellung der Geschäftslogik im Intra- oder Internet. Die oberste Schicht bildet der Client Layer - dieser realisiert die Darstellung sowie Eingabemöglichkeit der Anwendung gegenüber dem Nutzer über einen Web-Browser.

RMI steht für Remote Method Invocation und ist eine Art Java-eigenes RPC. RMI ermöglicht verteilten Java-Objekten über Methodenaufrufe miteinander zu kommunizieren. Auch hier (vgl. CORBA) kapselt der Client die Daten in Stubs und schickt eine Nachricht, die die aufzurufende Methode und benötigte Parameter enthält, an den Server bzw. das Serverobjekt. Dieses führt unter Verwendung von Skeletons die Methode aus und schickt das Ergebnis über den Stub an den Client zurück.

Wie im weiteren Verlauf der Thesis ersichtlich werden wird, muss eine J2EE-Architektur nicht unbedingt mit RMI implementiert werden, um entfernte Methoden

einer Javaklasse aufzurufen. Eine Implementierung von J2EE mit Hilfe von Web-Services ist innerhalb einer verteilten Architektur ebenso denkbar. 5

2.3.2 CORBA

CORBA (Common Object Request Broker Architecture) ist eine plattform- und sprachunabhängige Spezifikation, die eine Interaktion zwischen verteilten Objekten beschreibt. Diese Technologie funktioniert mittels ORB (Object Request Broker), CORBA-Facilities und CORBA-Services Der ORB stellt einen Kommunikationskanal zwischen den CORBA-Objekten dar. Der Client sendet eine Anfrage, die aus einem Methodenaufruf und den benötigten Parametern besteht. CORBA benötigt spezielle Netzwerkprotokolle, d. h. Nachrichten werden zunächst codiert und an den Server übermittelt. Dieser decodiert den Datenstrom, führt die Methode aus und sendet das Ergebnis auf dem gleichen Weg zurück an den Client (vgl. hierzu 5.6.1). Die Beschreibung der clientseitig zur Verfügung gestellten Methoden werden durch so genannte Stubs in der Beschreibungssprache IDL (Interface Definition Language) beschrieben. Analog dazu werden die serverseitig zur Verfügung gestellten Methoden als Skeletons beschrieben. CORBA verwendet das IIOP Protokoll für die Client-Server-Kommunikation. Das Interessante an CORBA ist die vergleichsweise frühe Entwicklung von - zwar noch spezifischen - aber immerhin schon rollenunabhängigen (Client/Server) Schnittstellen sowie die zentrale Registrierung verfügbarer Dienste in einem Interface Repository. Dieses Kernkonzept spielt bei Entwicklung von Web-Services eine zentrale Rolle. 6

2.3.3 Web-Services

Das Konzept von Web-Services liegt in der Bereitstellung autonomer, zentral verfügbarer, aber lose gekoppelter Dienste, die über das Intra- oder Internet aufgerufen werden. Der Schlüssel zur Umsetzung dieses Konzepts sind die Schnittstellen der angebotenen Dienste. Diese werden (im XML-Format) für eine Verwendung von SOAP und XML/RPC (Ausnahme bildet REST) in einer WSDL-Datei beschrieben und in einem zentralen Verzeichnisdienst UDDI registriert. Dabei ist es irrelevant, wo sich die aufrufbaren Interfaces befinden (innerhalb des Systems oder extern) oder welche Komponente hinsichtlich der Infrastruktur des Systems an der

⁵ Vgl. [informatik.uni-tuebingen],[galileocomputing.de],[Chapell/Jewell],S.193ff.,[Topley],S.447

⁶ [Channabasavaiah/ibm 2003 ], [Müller 2005],S. 71 ff.

8

Ausführung der Methode beteiligt ist. Kapitel 2 vertieft die Untersuchung von Web-Services.

2.3.4 Microsoft .NET / DCOM

Der Vollständigkeit halber soll an dieser Stelle die Microsoft .NET-Umgebung erwähnt werden, auf die aber im weiteren Verlauf der Arbeit nicht eingegangen wird. Diese Technologie erreicht ihre Sprachunabhängigkeit (beschränkt auf die vier Programmiersprachen Visual Basic, C#,J# und C++) durch das Interpretieren des Sourcecodes für die CLR (Microsoft Common Runtime Language) in Bytecode. Diese Umgebung besteht aus den Hauptbestandteilen Framework, Tools, Building Sockets, Enterprise Server und Mobile Device, welche Daten im XML-Fomat austauschen. Das .NET Remoting (für den Zugriff auf verteilte Objekte) basiert auf dem allgemein verwendeten RPC/RMI-Mechanismus und stellt über ein Remoting-Framework Anwen-dungsdienste bereit, welche den Lebenszyklus und den Zugriff auf Sockets (Channels) regeln. Bei einer Verbindung zwischen zwei .NET-Komponenten wird die Verbindung über ein binäres Protokoll direkt auf der Basis von TCP/IP realisiert, während bei einer Verbindung zwischen einer .NET-Komponente und einer beliebigen anderen Komponente als weitere

Abstraktionsschicht SOAP zum Einsatz kommt. Mit einer .NET Anwendung lassen sich also auch (eingeschränkte) Web-Services realisieren. 7

2.4 Kommunikation innerhalb verteilter

Anwendungen

Für einen effizienten Informationsaustausch innerhalb einer verteilten Anwendung ist es notwendig, sich auf ein Nachrichtenformat zu einigen. In den meisten Fällen wird dies durch die verwendeten Produkte (Integrationsserver bzw. Middleware) oder Technologien vorgegeben. Ein Standard, der sich mittlerweile für den Nachrichtenaustausch durchgesetzt hat, ist das XML-Format (neben binärer Datenübertragung wie beispielsweise bei CORBA oder RMI). Auch sollte eine Anwendung unbedingt über ein Repository als

Definitionsverzeichnis für Nachrichten, Nachrichtenversionen und Formate implementiert werden. Die signifikante Bedeutung eines zentral verfügbaren Repositories wird im Verlauf der Thesis im Zusammenhang mit der Registrierung der Web-Services deutlich.

⁷ Vgl [Fletcher/Waterhouse]S.47 , [Müller 2005],S.75 ff.

9

Kommunikationsarten werden in synchrone und asynchrone Kommunikation unterschieden. Synchrone Kommunikation bedeutet, dass der Nachrichtensender auf eine Bestätigung oder Antwort des Nachrichtenempfängers wartet. Bei dieser Art der Kommunikation besteht die Gefahr der Blockierung des Systems im Falle eines Nichtantwortens einer beteiligten Applikation. Dieses Risiko besteht nicht bei einer asynchronen Kommunikation, da der Nachrichtensender nach dem Versenden einer Nachricht weiterarbeitet und die Antwort des Nachrichtenempfängers (zunächst einmal aus der Sicht der reinen Kommunikation) ohne Vorgabe einer Zeitvorgabe gesendet wird. 8

⁸ [Müller 2005],S. 45 ff.

10

3. VERTIEFUNG SOA MIT WEB-SERVICES

Eine Alternative zur Umsetzung einer dienstorientierten verteilten Anwendung auf Basis standardisierter Schnittstellenbeschreibungen ist der Einsatz von Web-Services. Das folgende Kapitel soll theoretische Grundlagen dienstorientierter Architekturen sowie Web-Services vermitteln.

3.1 Serviceorientierte Architektur

In der Literatur scheint gegenwärtig keine einheitliche Definition bezüglich greifbarer Vorstellungen einer SOA zu existieren. Mit anderen Worten, die Anforderungen an eine dienstorientierte Architektur können, bedingt durch die Betrachtung aus verschiedenen Perspektiven, unterschiedliche Schwerpunkte setzen. Dennoch ergibt sich eine abzeichnende Schnittmenge an Anforderungen, die im Folgenden vorgestellt werden soll.

Einleitend sollte der Grundgedanke einer SOA vertieft werden. Im Zentrum dieser Architektur stehen - stärker als in anderen Architekturmodellen verteilter Anwendungen - Dienste bzw. Services. Dieser Grundgedanke sollte sowohl fachliche sowie technische Umsetzungen zu der Einnahme einer zentralen dienstorientierten Perspektive zwingen. Das bedeutet primär, bestimmte Aufgaben bzw. Abläufe der psychologischen Fähigkeit möglicherweise effizienter arbeitender Experten zu überlassen (anstatt detailliert selbst zu implementieren - Outsourcing-Prinzip), ist gefragt. Die Schlussfolgerung daraus bedeutet für die Implementierung, dass Methoden der Dienste (Programm oder Softwarekomponente - siehe hierzu Kapitel 3.2) gekapselt werden und somit der nutzenden Applikation oder dem Nutzer verborgen bleiben. Wenn der Aspekt der starren Schnittstelle oder Fassade (und der maschinellen Beschreibung dieser) bei dem Konzept der Plug-ins außer Acht gelassen wird, ist es legitim, Plug-ins als eine Weiterentwicklung von einer dienstorientierten Architektur zu bezeichnen. Mit anderen Worten, das Konzept einer komponentenbasierten oder hinsichtlich ihrer Funktionalität

„zusammensteckbaren“ Systemarchitektur wurde in Plug-in-Modulen bereits bedacht.

Bevor die Frage nach einer Technologie zur Umsetzung gestellt wird, ist es hilfreich, eine SOA zunächst als eine Abstraktion der Technologien zu begreifen. Eine Technologie, wie beispielsweise Web-Services (dynamischer Aufruf zur Laufzeit), ist

folglich eine konkrete Umsetzung der Abstraktion. Grundlegende Komponenten einer SOA sind Kommunikation, Dienstbeschreibung und Verzeichnisdienst ⁹ .

3.1.1 Begriffsklärung und Definitionen SOA

Folgende Tabelle veranschaulicht einen Auszug der Vielfalt existierender Definitionen einer serviceorientierten Architektur:

Tabelle 1: Definition des Begriffs Serviceorientierte Architektur

⁹ Vgl.[Melzer,Dostal,Jeckle,Zengler 2005],S.27ff., [Hae Ho 2003]

^{10 Vgl. [Melzer,Dostal,Jeckle,Zengler 2005],S.7 11} CIO der Deutschen Post, SOA-Pionier

12