Diplomarbeit. Analyse und Evaluierung der Implementierung des Konzepts der Serviceorientierten Architektur durch SAP Netweaver

Transkript

1 UNIVERSITÄT HAMBURG FACHBEREICH INFORMATIK ARBEITSBEREICH SOFTWARETECHNIK Diplomarbeit Analyse und Evaluierung der Implementierung des Konzepts der Serviceorientierten Architektur durch SAP Netweaver Matthias Benjamin Stubbe Billwerder Billdeich Hamburg Matr.-Nr Studiengang Wirtschaftsinformatik Abgabedatum: 28. September 2006 Erstbetreuung: Dr. Guido Gryczan Arbeitsbereich Softwaretechnik (SWT) Zweitbetreuung: Prof. Dr. Norbert Ritter Arbeitsbereich Verteilte Systeme und Informationssysteme (VSIS)

2 INHALTSVERZEICHNIS I Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der Abkürzungen iv vi vii ix 1 Einleitung Motivation Entstehung der Arbeit Gang der Untersuchung Serviceorientierte Architektur Problemfeld Definition Serviceorientierte Architektur SOA Service Abgrenzung Ziele Eigenschaften Anwendung des SOA-Ansatzes Einordnung Klassifizierung von SOA Services Klassifizierung nach Granularität

3 INHALTSVERZEICHNIS II Klassifizierung nach Kommunikationsart Klassifizierung nach Rollen Anwendungsgebiete Technologische Abgrenzung Webservices CORBA Einblick in die Umsetzung der SOA innerhalb eines Unternehmens Zusammenfassung Entwicklung von Bewertungskriterien Betriebswirtschaftliche Anforderungen Technische Anforderungen Ableitung von Bewertungskriterien Zusammenfassung Enterprise Service Architecture SAP Einordnung der ESA in die SAP Entwicklung ESA Vision ESA Aufbau Webservices Enterprise Service Enterprise Service Repository Abgrenzung Webservice und Enterprise Service SAP Netweaver People Integration Information Integration Process Integration Application Plattform Software Life Cycle Management Composite Applications Framework Einordnung Zusammenfassung

4 INHALTSVERZEICHNIS III 5 SAP Web Application Server Klassisches SAP Basis-System Präsentationsschicht Anwendungsschicht Datenbank-Schicht Architektur ABAP Stack Schnittstellen Java Stack Service-Entwicklung Bewertende Zusammenfassung SAP Exchange Infrastructure Problemfeld Konzepte Aufbau Integration Server Integration Builder System Landscape Directory Einordnung in ESA-Konzept Bewertende Zusammenfassung Beispielszenario Komponenten IT-Landschaft Umsetzung Zusammenfassende Bewertung Bewertung Designzeitanforderungen Modellierungsunterstützung Verbreitungsgrad Komplexität Laufzeitanforderungen

5 INHALTSVERZEICHNIS IV Monitoring Flexibilität Ausfallsicherheit Bewertende Zusammenfassung Schlussbetrachtung Zusammenfassung Ausblick Literaturverzeichnis 103

6 ABBILDUNGSVERZEICHNIS V Abbildungsverzeichnis 2.1 Use-Case-Diagramm für die Mainframe-Anwendung Exemplarischer Geschäftsvorfall: Buchung eines Unfallersatzfahrzeugs Merkmale des SOA-Softwaredesignansatzes Modellierung der Service-Schnittstellen Beschreibung der Service Operationen Verändertes Use-Case-Diagramm durch Einsatz von Services Exemplarischer Geschäftsvorfall: Buchung eines Unfallersatzfahrzeugs Zwei-Schichten-Architektur (nach [LWZ01]) Drei-Schichten-Architektur (nach [LWZ01]) Service Granularität Rollenbasierte Klassifizierung Bewertungskriterien Abdeckung der Kundenanforderung durch Standardlösungen Abdeckung der Kundenanforderung durch ESA Service (nach [SAP05] S. 9) ESA Überblick (nach [SAP04] S. 6) Webservice Protokoll Stack (nach [BHM + 04]) Übersicht der WSDL-Komponenten Ausschnitt aus einem exemplarischen WSDL-Dokument Services und Service Operationen (nach [SAP05]) SAP Netweaver Startbildschirm eines SAP Enterprise Portals Architekturskizze des klassischen SAP R/3-Systems

7 ABBILDUNGSVERZEICHNIS VI 5.2 Architektur des SAP Web Application Servers Architektur von ALE (nach [EW05] S. 37) Architektur des SAP Java-Stacks Schematische Entwicklung vom Webservices Laufzeitumgebung für Webservice des SAP Web AS Beispiel IT-Landschaft IT-Landschaft mit Nabe-Speiche-Architektur Anbindung eines Endsystems über Proxy bzw. Adapter (nach [Jes05] ) Integrationsarchitekturen nach [KF06] S Phasen der Implementierung (nach [SO04] S.27 ) Entwicklung SAP Netweaver und SAP Exchange Infrastructure Verändertes Use-Case-Diagramm durch Einsatz von Services Service-Schnittstellen der Autovermietung WSDL-Dokument zum Service Buchung eines Mietfahrzeugs (Auszug) Service-Schnittstellen externer Anbieter Darstellung der Callcenter-Anwendung Beispiel IT-Landschaft Bewertung mittels Bewertungskriterien

8 TABELLENVERZEICHNIS VII Tabellenverzeichnis 2.1 Vergleich der Ansätze Domain Services und SOA Service Kommunikationsarten SAP AG Unternehmensdaten

9 VIII Verzeichnis der Abkürzungen ABAP ALE API ARIS AXIS BAPI CMS CORBA CRM DIAG EAI EJB ERP ESA ESB GUI HR HTML HTTP HTTPS IDL IDoc IEEE IT JDBC JMS JWSDP LKW MVC OASIS OMG ORB PDA PKW Advanced Business Application Programming Application Link Enabling Application Programming Interface Architektur integrierter Informationssysteme Apache extensible Interaction System Business Application Program Interface Content-Management-System Common Object Request Broker Architecture Customer-Relationship-Management Dynamic Information and Action Gateway Enterprise Application Integration Enterprise Java Beans Enterprise-Resource-Planning Enterprise Services Architecture Enterprise Service Bus Graphical User Interface Human Resources Hypertext Markup Language HyperText Transfer Protocol Hypertext Transfer Protocol Secure Interface Definition Language Intermediate Document Institute of Electrical and Electronics Engineers Informationstechnologie Java Database Connectivity Java Message Service Java Web Services Developer Pack Lastkraftwagen Model-View-Controller Organization for the Advancement of Structured Information Standards Object Management Group Object Request Brokern Personal Digital Assistant Personenkraftwagen

10 IX RFC ROI SAP BSP SAP BW SAP CAF SAP CAF SAP ICM SAP ITS SAP LCM SAP MI SAP SLD SAP Web AS SAP XI SCM SMTP SOA SQL TCO UDDI UML URI VM W3C WAP WSDL XML XSLT Remote Function Call Return on Investment SAP Business Server Pages SAP Business Information Warehouse SAP Composite Application Framework SAP CAF SAP Internet Communication Manage SAP Internet Transaction Server SAP Life Cycle Management SAP Mobile Infrastructure SAP System Landscape Directory SAP Web Application Server SAP Exchange Infrastructure Supply-Chain-Management Simple Mail Transfer Protocol Serviceorientierte Architektur Structured Query Language Total Cost of Ownership Universal Description, Discovery and Integration Unified Modeling Language Uniform Resource Identifier Virtuelle Maschine World Wide Web Consortium Wireless Application Protocol WebServicesDescriptionLanguage Extensible Markup Language Extensible Stylesheet Language Transformation

11 KAPITEL 1. EINLEITUNG 1 1 Einleitung Die Serviceorientierte Architektur, kurz SOA, ist das abstrakte Konzept einer Software- Architektur, in deren Zentrum das Anbieten, Suchen und Nutzen von Diensten über ein Netzwerk steht. Für die Nutzung dieser Dienste soll es dabei unerheblich sein, welche Hard- oder Software, Programmiersprache oder Betriebssysteme die einzelnen beteiligten Systeme verwenden. Erstmals prägte die Gartner Incorporation 1 (Marktforschungsanbieter im Sektor der Informationstechnologie) 1996 diesen Begriff (vgl. [Nat03]) und stellte die SOA als eine Weiterentwicklung dar, welche sich in die Evolution von Mainframe- zu Web-Anwendungen einreiht (vgl. [AA04]). Nachdem große IT-Anbieter wie IBM (vgl. [IBM06]), Microsoft (vgl. [Bur04]) oder Oracle (vgl. [Zir06]) diese Thematik aufgegriffen haben, entwickelten sich überschießende Erwartungen an die SOA. Dieser kann durch folgende Zitate aus der IT-Branche widergespiegelt werden. Bereits in zwei Jahren wird sich die Serviceorientierte Architektur zum dominierenden IT-Konzept entwickelt haben.... Rechenleistung kann nach Bedarf bereitgestellt werden, bei Änderungen der Geschäftsprozesse werden schnell die benötigten Anwendungen integriert. [CZ03] Zeit, Kosten und Komplexität von Integrationsprojekten lassen sich durch den Einsatz einer Serviceorientierten Architektur (SOA) deutlich reduzieren. [Sch04] By 2008, more than 75 percent of then-current application packages either will be natively SOA or will expose SOA interfaces through a wrapping layer of interfaces (0.8 probability). [Nat03] S. 4 Unternehmen erhoffen sich von dem Einsatz der Serviceorientierten Architektur flexibler, schneller und kostengünstiger auf neue und geänderte Wettbewerbsbedingungen reagieren zu können. Zusätzlich soll die SOA die Diskrepanz zwischen betriebswirtschaftlicher und technischer Sichtweise auf IT-Systeme verringern (vgl. [Dug02]). Die SOA ist kein allgemein anerkannter Standard oder eine Spezifikation und wird von verschiedenen Herstellern unterschiedlich umgesetzt. Der größte europäische Softwarehersteller SAP AG (vgl. [For06]) hat auch die Konzepte der SOA aufgegriffen. Mit der Enterprise Service Architecture (ESA) hat die SAP AG eine Umsetzung der SOA entwickelt. Die zukünftige Produktentwicklung dieses Softwarehauses wird stark von der Anwendung dieses Ansatzes beeinflusst. Die monolithisch anmutenden SAP-Anwendungen sollen mehr und mehr in fein granulare Services aufgegliedert werden. Netweaver stellt die technologische Plattform für die 1

12 KAPITEL 1. EINLEITUNG 2 Umsetzung der ESA und somit auch einer SOA dar. Die vollständige Umstellung der SAP- Unternehmensanwendungen auf eine Serviceorientierte Architektur wird jedoch mehr Zeit in Anspruch nehmen (vgl. [KTD05] S. 35). Die Markteinführung der technologischen Plattform Netweaver ist bereits vollzogen und viele SAP-Kunden besitzen somit bereits die Möglichkeit ihre IT-Infrastruktur serviceorientiert aufzubauen. Innerhalb dieser Arbeit werden die grundlegenden Konzepte der SOA beschrieben. Des Weiteren soll begründet werden, warum momentan ein starkes Interesse an diesem Thema besteht und alle großen Softwarehersteller wie Oracle, Microsoft, IBM und SAP diesen Ansatz zukünftig verwenden wollen. Die Umsetzung der SOA durch die SAP AG mit Hilfe der Enterprise Service Architecture soll genauer untersucht und bewertet werden. Dazu werden auch die Erwartungen erläutert, welche die SAP AG an die Anwendung des Ansatzes stellt. Die von diesem Unternehmen bereitgestellten technischen Werkzeuge zur Realisierung der SOA werden beschrieben. Die SOA soll die Integration von Anwendungen und Systemen verschiedener Hersteller vereinfachen. Die Arbeit beschreibt ein Beispielszenario, bei dem diese neuen Integrationsmöglichkeiten von SAP-Systemen auf Basis der SOA angewendet werden. Abschließend wird die Umsetzung der SOA durch die ESA und Netweaver mit Hilfe der innerhalb dieser Arbeit entwickelten Kriterien bewertet. 1.1 Motivation Die SAP AG gibt in [SAP06b] einen weltweiten Marktanteil von 62 % der SAP Produkte in dem Bereich der Unternehmenssoftware an. Dieser Anteil ist auf eine Peer Group bezogen, welche aus der Oracle Corp. (nur Segment Unternehmenssoftware), Microsoft Corp. (nur Segment Unternehmenssoftware) und Siebel Systems, Inc. besteht. Durch diese signifikante Position am IT-Markt besitzt die SAP AG die Möglichkeit neue Technologien und Produkte zu vertreiben, welche die Entwicklung innerhalb der IT-Branche beeinflussen können. Wie bereits dargestellt, sollen die zukünftigen Produkte der SAP AG auf dem Konzept der SOA basieren und vorhandene Anwendungen nach und nach serviceorientiert aufgegliedert werden. Dieser Ansatz verspricht, dass sich SAP-Anwendungen weniger als monolithische Systeme darstellen, sondern die Interoperabilität mit Produkten anderer Anbieter vereinfacht wird. In diesem Zusammenhang bezeichnet die SAP AG Netweaver als Integrationsplattform. Diese Arbeit soll untersuchen, wie durchgängig die Konzepte der SOA durch die SAP AG umgesetzt worden sind und wie sich dieser Ansatz auf die Integrationsmöglickeiten von SAP-Anwendungen auswirkt.

13 KAPITEL 1. EINLEITUNG Entstehung der Arbeit Die vorliegende Diplomarbeit ist in Kooperation mit einer Unternehmensberatung entstanden. Der Leistungsumfang der Beratung dieser Unternehmung umfasst: Die Entwicklung von IT- Konzepten, Prozessanalysen, Systemdesign, Softwareauswahl, Software-Implementierungen, Unterstützung bei der Einführung von Softwareprodukten und Wirtschaftlichkeitsanalysen. Die Beratungsdienstleistung ist primär auf Fragestellungen im Umfeld von SAP- Anwendungen ausgerichtet. Die SAP AG will das Konzept der Enterprise Service Architecture und die damit im Zusammenhang stehenden neuen Produkte vermarkten. Unternehmensberatungen im Umfeld der SAP AG müssen sich mit diesen neuen Technologien auseinander setzen, um ihre Dienstleistung bzgl. geänderter Kundenanforderungen erweitern zu können. In diesem Kontext entstand die Fragestellung für diese Arbeit. Die theoretischen Grundlagen der ESA sollten erarbeitet werden. Des Weiteren sollten die neuen Produkte in einem praxisnahen Beispielszenario angewendet werden. Auf dessen Grundlage sollen sich die Mitarbeiter der Unternehmung einen Überblick über die Interpretation der SOA durch die SAP AG verschaffen können. Als Grundlage für das Beispielszenario dient eine Integrationsproblematik einer Autovermietung (vgl. 2.1). Dieses Problemfeld entstammt aus Erfahrungen durch die Mitarbeit innerhalb eines Projektes dieser Autovermietung. 1.3 Gang der Untersuchung Zunächst wird innerhalb dieser Arbeit herausgestellt, was nach dem aktuellen Konsens der Fachwelt unter dem Konzept der SOA zu verstehen ist. Dazu stellt das Kapitel 2 verschiedene Definitionen vor, aus denen eine als Basis dieser Arbeit ausgewählt wird. Der Ansatz wird anhand eines praxisnahen Anwendungsbeispiels veranschaulicht. Die SOA wird durch einen Vergleich mit einem anderen Konzept, dem der Domain Services, in die Entwicklung der Softwaretechnik eingeordnet. Im Kapitel 3 erfolgt eine Definition von Kriterien, anhand derer die Umsetzung einer Serviceorientierten Architektur beurteilt werden kann. Diese werden aus betriebswirtschaftlichen sowie technischen Anforderungen abgeleitet. Kapitel 4 stellt kurz die SAP AG vor und beschreibt, welche Erwartungen diese Unternehmung mit der Umsetzung dieses Konzepts verbindet. Die Konkretisierungen der SOA durch die ESA werden erläutert. Netweaver wird von der SAP AG als Kompositionsplattform für ESA Services bezeichnet. Dieses Produkt-Paket wird vorgestellt und dabei ist zu erkennen, dass nicht alle Bestandteile einen direkten Bezug zur ESA haben. Diese Arbeit konzentriert sich auf die zwei Komponenten des Netweaver-Pakets: den SAP Web Application Server (SAP Web AS) und die SAP Exchange Infrastructure (SAP XI). Der Web AS bietet eine Entwicklungs- und Laufzeitumgebung für ESA Services. Die zukünftigen Services der SAP AG werden auf diesem System angeboten und Kunden der SAP können eigenständig Services definieren und auf Basis dieses Systems implementieren. Kapi-

14 KAPITEL 1. EINLEITUNG 4 tel 5 stellt die Entwicklung vom klassischen R/3-System zum SAP Web AS dar und zeigt, auf welchen Technologien dieses System basiert. Der vermehrte Einsatz von Services zur Integration von Systemen reduziert nicht zwingend die Komplexität von IT-Infrastrukturen. Kapitel 6 stellt diese Problematik dar und beschreibt wie SAP XI den Aufbau von Serviceorientierten Architekturen unterstützen kann. Im Gesamtkontext des Konzepts der ESA trägt die SAP XI eine entscheidende Rolle. Sie ermöglicht die Bereitstellung von Funktionalität in Form von Services, ohne diese neu als Webservice implementieren zu müssen (im Englischen Service-Enabling genannt). Des Weiteren unterstützt sie die Service-Orchestrierung: vorhandene sowie neu entwickelte Services zu Composite Applications zu verbinden. Das in dem Kapitel 7 beschriebene Beispielszenario greift das Anwendungsbeispiel des Kapitels 2 auf. Bei der Realisierung des Szenarios werden die Anwendungen der SAP AG zur Implementierung der ESA angewendet und mit einem Nicht-SAP-System integriert. Daraus soll abgeleitet werden können, inwieweit die Interoperabilität von SAP-Anwendungen durch die Einführung der ESA beeinflusst wird. Abschließend bewertet das Kapitel 8 die Umsetzung der SOA durch die ESA und Netweaver auf Basis der im Kapitel 3 entwickelten Kriterien und den Erfahrungen bei der Realisierung des Beispielszenarios.

15 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 5 2 Serviceorientierte Architektur In der Einleitung wurden kurz die Erwartungen, welche mit der Serviceorientierten Architektur (SOA) verbunden sind, beschrieben. Bei der Recherche, was eine SOA ist, ist es leicht, auf Unschärfen oder gar Widersprüche zu stoßen. Ein Bestandteil dieser Arbeit ist es, den aktuellen Konsens der Fachwelt zur Definition der SOA darzustellen. Im ersten Abschnitt dieses Kapitels wird exemplarisch ein Problemfeld beschrieben, für welches das Konzept der SOA einen Lösungsansatz bieten soll. Dieses Szenario wird innerhalb dieser Arbeit immer wieder verwendet, um die Konzepte der SOA zu konkretisieren und später die Umsetzung der SOA durch die SAP AG zu veranschaulichen. Anschließend werden verschiedene Definitionen der SOA vorgestellt und eine für diese Arbeit zweckmäßige ausgewählt. In den Abschnitten 2.3 und 2.4 werden die Ziele und Eigenschaften der SOA dargestellt. Nachdem die Konzepte der SOA beschrieben worden sind, wird dieser Ansatz auf das Beispiel angewendet, um die abstrakte Definition zu konkretisieren und deren Vorteile darzustellen. Die SOA wird oftmals als revolutionärer Ansatz dargestellt (vgl. Kapitel 1). Innerhalb des Abschnitts 2.6 wird die SOA mit einem anderen Konzept der Softwaretechnik verglichen. Damit soll aufgezeigt werden, dass die SOA eher als eine Evolution zu betrachten ist, welche bereits etablierte Ansätze beinhaltet und weiterführt. Im Zentrum der SOA stehen die Services: diese werden im Abschnitt 2.7 genauer klassifiziert, so sollen verschiedene Arten von Services voneinander abgrenzt werden. Die SOA ist ein Softwaredesignansatz zur Entwicklung und Integration von Unternehmensanwendungen. Der Einsatz der SOA wird nicht alle klassischen Schnittstellen-Techniken verdrängen. Im Abschnitt 2.8 wird erörtert, für welche Anwendungsgebiete die SOA prädestiniert ist und für welche sie weniger geeignet ist. Die SOA ist als Softwaredesignansatz technologie-unabhängig und kann durch verschiedene Techniken umgesetzt werden. Im Abschnitt 2.9 wird beschrieben, welche Technologien oft im Zusammenhang mit der SOA genannt werden. Somit werden häufige Unschärfen innerhalb der Diskussion um diesen Ansatz erläutert.

16 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR Problemfeld Innerhalb dieses Abschnitts wird ein IT-Szenario einer fiktiven international agierenden Autovermietung beschrieben 1. Anhand dessen wird der Anwendungskontext der SOA exemplarisch eingeführt. Es sollen die Probleme dargestellt werden, die entstehen, wenn eine IT- Infrastruktur aus verschiedenen Teilsystemen gewachsen ist. Die Probleme, welche durch die Analyse dieser IT-Infrastruktur aufgezeigt werden, sind keinesfalls branchenspezifisch, sondern können so oder in ähnlicher Form innerhalb vieler Unternehmungen gefunden werden. Die vereinfachte IT-Infrastruktur der Autovermietung besteht aus drei eigenständigen Systemen. Die Kernanwendung der Autovermietung ist ein Informations- und Reservierungssystem, welches als Terminal/Host-Anwendung auf Basis einer Oracle Datenbank implementiert ist (in dem folgenden Text wird diese Anwendung kurz als Mainframe-Anwendung bezeichnet). Innerhalb dieses Systems werden Reservierungen für Mietwagen durchgeführt und die Bewegungen und Vermietungen der Mietwagenflotte festgehalten. Dazu sind alle Stationen der Autovermietung an dieses System angeschlossen. Rechnungen werden ebenfalls durch diese Anwendung erzeugt, hierfür werden auch die aktuellen Tarifkonditionen zentral in diesem System gepflegt. Aufgrund der Organisationsstruktur wird die Mainframe-Anwendung zentral im Rechenzentrum am Hauptsitz der Autovermietung in England betrieben. Im zentralen Rechenzentrum wird eine weitere Anwendung betrieben, diese stellt ein später entwickeltes Internet-Portal für die Online-Preisauskunft und Reservierung dar (in folgendem Text wird diese Anwendung als Internet-Reservierungssystem bezeichnet). In der deutschen Landeszentrale wurde ein weiteres System eingerichtet: eine Anwendung zur Unterstützung der kooperativen Arbeit innerhalb eines Callcenters (in folgendem Text wird diese Anwendung als Callcenter-Anwendung bezeichnet). Dieses System ist eine Java-basierte Webanwendung und soll den für Autovermietungen lukrativen Markt der Unfallersatzfahrzeuge unterstützen. Es wird dann von einem Unfallersatzfahrzeug gesprochen, wenn ein Haftplichtversicherungsschadensfall eintritt, bei dem ein Versicherungsunternehmen ein Ersatzfahrzeug für den Geschädigten bezahlt. Die Prozesse für diesen Geschäftsfall unterscheiden sich von denen normaler Reservierungen und werden daher von dieser eigenständigen Software unterstützt, welche von der Landeszentrale selbständig entwickelt worden ist. Zusammenfassend enthält die dargestellte Infrastruktur drei verschiedene IT-Systeme: Ein zentrales Informations- und Reservierungssystem der Autovermietung (Mainframe-Anwendung) Ein Internet-Portal zur Online-Preisauskunft und Reservierung (Internet-Reservierungssystem) Eine Anwendung zur Unterstützung der kooperativen Arbeit des Callcenters in der Landeszentrale in Deutschland (Callcenter-Anwendung) 1 Das Anwendungsbeispiel basiert auf realen Projekterfahrungen.

17 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 7 Abbildung 2.1: Use-Case-Diagramm für die Mainframe-Anwendung Im Zentrum der IT-Landschaft steht die ältere Mainframe-Anwendung. Dieses kann als eine realistische Annahme betrachtet werden, denn zwei Drittel aller wirtschaftlich relevanten Daten lagern laut [Fen03] auf solchen Mainframe-Systemen. Die Abbildung 2.1 stellt die für die Betrachtung des Problemfelds relevanten Geschäftsabläufe dar. Als Darstellungsform wurde die Unified Modeling Language 2.0 (UML) der Object Management Group (OMG) gewählt (vgl. [Bal05]). Das Use-Case-Diagramm zeigt vereinfacht, dass drei Akteure mit der zentralen Mainframe-Anwendung kommunizieren. Die Akteure sind zum einen die technischen Systeme Internet-Reservierungssystem und die Callcenter-Anwendung. Diese Systeme interagieren stellvertretend für einen Kunden bzw. einen Callcenter-Mitarbeiter mit der Mainframe-Anwendung. Zum anderen ist der Callcenter-Mitarbeiter ein Akteur, der direkt mit der Mainframe-Anwendung arbeitet. Die Akteure kommunizieren über vier verschiedene Use-Cases. Jeweils zwei stellen jedoch die gleiche fachliche Funktionalität dar: die Ermittlung von Fahrzeugverfügbarkeiten und die Buchung eines Fahrzeugs. Die Use-Cases werden nun genauer beschrieben und es wird dargestellt, in wieweit sich die Use-Cases unterscheiden. Eine Online-Reservierung über das Internet-Portal erfordert, dass die Mainframe- Anwendung eine Schnittstelle anbietet, welche die aktuellen Vermietungskonditionen und Fahrzeugverfügbarkeiten bereitstellt. Bei Abschluss einer Reservierung muss diese durch eine entsprechende Schnittstelle in die Mainframe-Anwendung gebucht werden. Die beschriebene Callcenter-Anwendung unterstützt Geschäftsprozesse, welche ähnliche Schnittstellen zur Mainframe-Anwendung benötigen. Ein normaler Geschäftsprozess beschreibt sich folgendermaßen: zuerst ruft die Haftpflichtversicherung des Unfallverursachers an und meldet den Bedarf für ein Unfallersatzfahrzeug. Der Callcenter-Mitarbeiter nimmt die entsprechenden Daten des Geschädigten auf, prüft die Fahrzeugverfügbarkeiten in der entsprechenden Region mit Hilfe der Mainframe-Anwendung und versucht den Geschädigten anzurufen, um ihm ein Angebot für ein Ersatzfahrzeug anzubieten. Kann der Callcenter-Mitarbeiter den Geschädigten nicht erreichen, trägt dieser den Vorgang in die Ablage der Callcenter- Anwendung ein. Der Vorgang kann dadurch später von anderen Mitarbeitern bearbeitet werden. Wird der Geschädigte erreicht und nimmt das Angebot für ein Unfallersatzfahrzeug an, muss der Mitarbeiter des Callcenters eine Reservierung für ein Fahrzeug veranlassen. Die

18 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 8 Abbildung 2.2 beschreibt mit der Hilfe eines Aktivitätsdiagramms der UML die Aktivitäten des Callcenter-Mitarbeiters innerhalb eines exemplarischen Geschäftsvorfalls. Der Geschädigte nimmt innerhalb dieses Geschäftsvorfalls das Angebot eines Unfallersatzfahrzeuges an. Das Aktivitätsdiagramm zeigt einen häufigen Anwendungswechsel des Callcenter-Mitarbeiters. Abbildung 2.2: Exemplarischer Geschäftsvorfall: Buchung eines Unfallersatzfahrzeugs Bei der Betrachtung der beiden Geschäftsvorfälle, Online-Reservierung und Bereitstellung eines Unfallersatzfahrzeuges, ist erkennbar, dass diese ähnliche Teilprozesse besitzen, welche durch die Mainframe-Anwendung erbracht werden. Die Schnittstellen zur Mainframe- Anwendung wurden jedoch unterschiedlich implementiert. Dieses ist zum einen durch die verschiedenen technischen Möglichkeiten begründet, welche zum Zeitpunkt der Entwicklung der Schnittstellen bestanden, zum anderen durch die örtliche Trennung und die organisatorische Zugehörigkeit der verschiedenen Systeme. Das Internet-Reservierungssystem wurde in enger Kooperation mit dem zentralen Rechenzentrum am Hauptsitz der Autovermietung entwickelt. Die Schnittstelle zwischen Internet- und Mainframe-Anwendung, wird dadurch charakterisiert, dass das Internet-Reservierungssystem direkt auf die Datenbank des Mainframe- Systems zugreift. Diese Möglichkeit der Vernetzung zwischen der Mainframe- und der Callcenter- Anwendung gab es aufgrund der späteren Entwicklung, der örtlichen Trennung zwischen den Rechenzentren und der organisatorischen Zugehörigkeit der Anwendungen nicht. Der Geschäftsvorfall Ermittlung von Fahrzeugverfügbarkeiten wird dadurch erbracht, dass der Mitarbeiter sich per Terminal am Mainframe-System anmeldet und eine entsprechende Überprüfung durchführt. Sollte der Geschäftsprozess zu einer Reservierung führen, geschieht die Buchung durch eine Terminalemulation, bei der die Felder der Terminalmaske mit Werten aus der Callcenter-Anwendung gefüllt werden. Die beschriebenen technischen Gegebenheiten der Autovermietung begründen die Darstellung der vier Use-Cases, obwohl fachlich nur zwei verschiedene Use-Cases benötigt werden. Bei der Betrachtung dieser Schnittstellen und der Use-Cases sind mehrere Schwachpunkte dieser IT-Infrastruktur erkennbar. Es besteht eine enge Kopplung (diese Eigenschaft wird in dem Kapitel 2.2 definiert) zwischen den verschieden Systemen. Diese hat beispielsweise zur Folge, dass eine Änderung an der Mainframe-Anwendung zu einer notwendigen Anpassung aller vorhandenen Schnittstellen führen kann und somit auch der kooperierenden Systeme. Es besteht eine geringe Wiederverwendung von bereits implementierter Geschäftslogik. Dieses hat einen doppelt negativen Kosteneffekt für die Unternehmung. Zum einen wurde in die

19 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 9 Realisierung einer Geschäftslogik zweimal investiert, zum anderen müssen zwei Schnittstellen gewartet und getestet werden. Die Schnittstellen richten sich nach den technischen Gegebenheiten und daher besteht eine technische Abhängigkeit zwischen den Systemen. Die beschriebenen Schnittstellen befinden sich zwar auf einer niedrigen Abstraktionsebene, die Probleme der technischen Abhängigkeit ergeben sich aber auch, wenn Schnittstellen auf höheren Abstraktionsebenen benutzt werden, z.b. Remote Function Call (RFC). Diese stellen je nach eingesetzter Technik Anforderungen an die Kommunikationspartner. Dieser Schwachpunkt wird gravierender, wenn die Autovermietung ihre Dienstleistung unternehmensübergreifend anbieten will. Vorstellbar wäre die Kooperation mit Reiseveranstaltern, welche beim Verkauf ihrer Reisen zusätzlich die Vermietung von PKW anbieten wollen. Damit wäre die Reservierung eines Fahrzeuges Bestandteil eines größeren Geschäftsprozesses. Soll dieser effizient durch eine unternehmensübergreifende IT- Infrastruktur abgebildet werden, muss eine Schnittstelle zur Mainframe-Anwendung geschaffen werden, welche einen anonymeren Nutzerkreis besitzt und deren Definition möglichst allgemein gültig sein sollte. Bei den Geschäftsprozessen der Unfallersatzfahrzeuge kann außerdem ein häufiger Wechsel zwischen den Anwendungen beobachtet werden. Dabei müssen Daten oftmals redundant von Benutzern in verschiedenen Anwendungen eingegeben werden, dies ist zeitaufwendig und kann zu inkonsistenten Daten führen. Dieses Szenario hat die Problemfelder beschrieben, für die die SOA einen Lösungsansatz liefern soll. Im nächsten Kapitel wird nun eine Definition der SOA erarbeitet. 2.2 Definition Nachdem Kapitel 2.1 ein Problemfeld für die SOA exemplarisch beschrieben hat, soll die SOA nun dargestellt und definiert werden. Im folgenden Abschnitt werden verschiedene Definitionen der SOA vorgestellt und eine für diese Arbeit zweckmäßige ausgewählt. Daraus abgeleitet wird in dem Abschnitt eine Definition für SOA Services beschrieben. Die anschließende Abgrenzung soll aufzeigen, welche Bestandteile die ausgewählte Definition der SOA nicht umfassen soll Serviceorientierte Architektur Die SOA ist keine Spezifikation und kein Standard. Es gibt kein Entscheidungsgremium, welches die Kompetenz besitzt, die Definition der SOA eindeutig festzulegen. Viele verschiedene Definitionen sind in der Fachliteratur zu finden. Aus ihnen soll eine für das Verständnis dieser Arbeit zweckmäßige Definition ausgewählt werden. Dazu werden zunächst verschiedene Definitionen aufgeführt. Jede dargestellte Definition wird einen weiteren Teilaspekt der SOA einführen und so wird nach und nach eine zweckmäßige Definition der SOA aufgebaut. Das World Wide Web Consortium (W3C) 2 beschreibt die SOA als A set of components which can be invoked, and whose interface descriptions can be published and discovered. 2 Das World Wide Web Consortium ist eine non-profit Standardisierungsgesellschaft, deren Hauptziel die Weiterentwicklung der Internet-Standards und verwandter Protokolle ist.

20 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 10 (vgl. [HB04]). Diese Definition beschreibt die SOA nur unzureichend. Es werden Softwarekomponenten benannt, deren Schnittstellenbeschreibungen publiziert und gefunden werden können. Es werden keine Aussagen über die Schnittstellen getroffen und nach welchen Prinzipien die Services aufgebaut werden sollen. Dr. Hao He (Mitglied der Arbeitsgruppe Web Service Architecture des W3C) liefert mit seiner Definition der SOA weitere wichtige Aspekte. SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. (vgl. [He03]). Die SOA wird als Softwaredesignansatz beschrieben. Ein sehr wichtiger Aspekt wird eingeführt: Die lose Kopplung zwischen interagierenden Software Agenten. Eine Definition für die lose Kopplung liefert Das objektorientierte Konstruktionshandbuch von Prof. Heinz Züllighoven, innerhalb der vorliegenden Arbeit wird diese Definition verwendet. Definition: Lose Kopplung Eine Komponente ist dann lose an eine zweite gekoppelt, wenn der Klient nicht die gesamte Schnittstelle des Anbieters kennt, sondern auf der Basis eines Typs nur den Ausschnitt der Schnittstelle (und ihres Verhaltens), der die notwendigen Operationen für diese Kopplung beschreibt. (vgl. [Zül98] S.56) Des Weiteren werden zwei verschiedene Rollen beschrieben: Service-Anbieter und Service- Nutzer. Der Service-Anbieter erbringt eine Dienstleistung für den Service-Nutzer. Die Definition geht nicht auf die Schnittstelle zwischen Service-Anbieter und -Nutzer ein. Die Art der Dienstleistung und deren Leistungsumfang wird nicht definiert. Die im Rahmen dieser Arbeit verwendete Definition der SOA liefert die SOA Blueprints Initiative 3, welche Anfang 2004 von Bea Systems und The Middleware Company gegründet worden ist. An dieser Initiative beteiligten sich eine Vielzahl von Unternehmen, darunter z.b. Microsoft, IBM, Sun Microsystems, Hewlett-Packard und SAP (vgl. [Ull04] S.58). Das Ziel dieses Zusammenschlusses war es eine herstellerübergreifende Standardisierung der Konzepte und Terminologie um die SOA voranzubringen. Des Weiteren sollte ein Satz von Anforderungen an eine Referenzimplementierung definiert werden, anhand derer neue Lösungsverfahren der SOA aufgezeigt werden sollen (vgl. [Kid04], [WH04b] und [WH04c]). Definition: Serviceorientierte Architekturen (SOA Blueprints) A service-oriented architecture can be defined as a way of designing and implementing enterprise applications that deals with the intercommunication of loosely coupled, coarse grained (business level), reusable artifacts (services). Determining how to invoke these services should be through a platform independent service interface. (vgl. [WH04a] S. 4) 3

21 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 11 Die Definition führt zum einen den Begriff der Granularität der Services und zum anderen die Plattformunabhängigkeit der Service-Schnittstellen ein. Die Granularität beschreibt die Art und den Umfang der Dienstleistung. Ein fein granularer Service kann von einer Vielzahl von anderen Services verwendet werden und erbringt Dienstleistungen wie den Datenzugriff auf eine bestimmte Entität. Diese Services werden nicht über Systemgrenzen hinweg angeboten. Grob granulare Services erbringen einen Dienst entsprechend spezifischen betriebswirtschaftlichen Anforderungen. Ihre Dienstleistung können sie aus der Kombination verschiedener fein granularer Services erbringen. Jede Funktionalität kann technisch gesehen zwar als Service bereitgestellt werden, dies würde aber zur einer Vielzahl von Services führen, welche dann schwer zu beschreiben und zu pflegen sind (vgl. [Gup]). Die Herausforderung ist es die zweckmäßige Granularität der Services zu bestimmten, welche sich an den Geschäftsprozessen orientieren soll. Die lose Kopplung zwischen Service-Anbieter und Service-Nutzer sollen durch plattformunabhängige Schnittstellen geschaffen werden. Anhand dieser Schnittstellen soll der Service- Nutzer die Dienste des Anbieters in Anspruch nehmen können, ohne Annahmen über deren Implementierung treffen zu müssen. Es existieren eine Vielzahl weiterer Definitionen der SOA. Eine soll noch aufgeführt werden. Diese wurde durch das Forschungsunternehmen CBDI Forum 4 beschrieben, welches 1997 mit der Zielsetzung gegründet worden ist, Leitlinien für die Umsetzung einer Serviceorientierten Architektur zu liefern. Definition: Serviceorientierte Architekturen (CDBI) The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. (vgl. [SW04]) Diese Definition ist der aus den SOA Blueprints sehr ähnlich, welche die Basis dieser Arbeit ist. Jedoch führt das CDBI Forum das Finden eines Services als einen Aspekt der SOA auf. Es wurde eine Definition gewählt, welche diesen Aspekt nicht enthält. Viele enthalten zwar diesen Gesichtspunkt der SOA, die Konzepte wie eine automatische Suche von Services unterstützt werden kann, sind jedoch vage und deren technische Implementierung komplex. Deshalb ist die Definition aus den SOA Blueprints für diese Arbeit zweckmäßiger und wurde daher ausgewählt SOA Service Dieser Abschnitt stellt eine Definition für SOA Services vor. Durch eine konkretere Beschreibung der SOA Services soll eine präzisere Vorstellung über ihre Modellierung und ihre Abgrenzung zu anderen Softwarekomponenten geschaffen werden. 4

22 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 12 SOA Blueprints Initative beschreibt die SOA-Services folgendermaßen: Definition SOA Services An SOA Service or business-prozessing component is self-contained and platform-independent, and can be dynamically located and invoked. A client from any device, using any operating system, in any language, can access an SOA Service. (vgl. [WH04a] S.4) In der Definition der SOA (vgl. Kapitel 2.2) wurden die Eigenschaften von Services beschrieben. Ihr Leistungsumfang soll einen Teil eines Geschäftsprozesses entsprechen, die Nutzung eines Service ist unabhängig von anderen Services. Dieses bedeutet nicht, dass ein Service keinen anderen Service für die Erstellung seines Dienstes verwenden kann, sondern nur, dass ein Service-Nutzer dieses bei der Verwendung des Services nicht berücksichtigen muss Abgrenzung Nachdem die vorherigen Abschnitte die Definition der SOA und ihrer Services beschrieben hat, soll dieses Kapitel eine Abgrenzung zu anderen möglichen Auffassungen über diesen Ansatz darstellen. Die SOA soll die Flexibilisierung von Geschäftsprozessen unterstützen. Große Teile der Geschäftsprozesse werden durch Services erbracht. Durch die Zusammensetzung von mehreren Services können höherwertige Geschäftsprozesse erzeugt werden. Zur vollständigen Abbildung eines Geschäftsprozesses in einen IT-System gehört jedoch die Interaktion mit dem Menschen. Diese Interaktion wird in dieser Arbeit nicht genauer betrachtet. Es ist jedoch festzuhalten, dass eine SOA durch das Konzept der plattformunabhängigen Services eine für die Entwicklung von Benutzerschnittstellen gut nutzbare Schnittstelle liefert. Diese Eigenschaft kann aus dem Kapitel 2.6 abgeleitet werden. Dort wird ein anderer Softwaredesignansatz (Domain Services) beschrieben, welcher sehr ähnliche Lösungskonzepte zur SOA aufzeigt, jedoch ursprünglich aus dem Bereich der Entwicklung von Benutzerschnittstellen kommt. 2.3 Ziele Viele Ziele und Hoffnungen sind mit dem Ansatz der SOA verbunden. Dieses Kapitel versucht die einheitlichen Ziele aus verschiedenen Quellen heraus zu filtern. Es werden keine Ziele aufgeführt, welche aus zu hohen Erwartungen oder reinen Marketingversprechungen resultieren. So sollen nur die Ziele aufgeführt werden, welche als Konsens der aktuellen Diskussion über die SOA angesehen werden können. Als Grundlage der zu beschreibenden Ziele dienten [DJMZ05], [Uni05], [He03], und [Nat03]. Förderung der Wiederverwendung von Softwarekomponenten IT-Unterstützung der Prozess- und Serviceorientierung

23 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 13 Unterstützung der Integration von verschiedenen IT-Systemen durch Einsatz von Standard-Schnittstellen Schaffung eines Leitbildes für die Entwicklung von Schnittstellen Erhöhung der Flexibilität, der Schnelligkeit, Reduktion der Kosten und der Komplexität in der Umsetzung von Geschäftsprozessen und Integrationsprojekten Erhöhung der Nähe der Softwarekomponenten zum fachlichen Modell Weiterverwendung der Funktionalität von Alt-Systemen (im Englischen Legacy-Systems genannt) Diese Ziele der SOA begründen auch den Hype, welcher um diesen Softwaredesignansatz besteht, weil die SOA Lösungswege für Probleme aufzeigt, welche innerhalb vieler Unternehmungen aktuell bestehen (vgl. Kapitel 2.1). Aus den Zielen und der Definition können die Eigenschaften der SOA abgeleitet werden. Diese sollen in dem nachfolgenden Kapitel zusammengefasst werden. 2.4 Eigenschaften Die SOA ist ein Softwaredesignansatz und keine Spezifikation. Als Ansatz ist sie technologieneutral und es kann verschiedene Möglichkeiten geben, sie zu implementieren. Die wesentlichen Eigenschaften der SOA sollen in diesem Kapitel aufgeführt werden. Die Merkmale wurden in Anlehnung an die Definition aus Kapitel 2.2, [BHM + 04], [Uni05], [He03] und [Nat03] zusammengeführt und ausgewählt. Lose Kopplung: Die SOA legt eine lose Kopplung zwischen den einzelnen Teilsystem fest (vgl. Kapitel 2.2). Konzeptuelle Sicht auf Systeme: Die Systeme werden unter dem Blickwinkel betrachtet, was eine Komponente leistet, von ihrer Implementierung wird abstrahiert. Typischerweise ist dieses ein auf der Ebene von Geschäftsprozessen relevanter Dienst. Die interne Struktur des Service-Anbieters, sowie weitere Eigenschaften wie beispielsweise die verwendete Programmiersprache, werden durch die SOA gekapselt. Nachrichten-Orientierung: Ein Service wird formal über die Nachrichten definiert, welche zwischen Service-Nutzer und Service-Anbieter ausgetauscht werden, und nicht über die Implementierung des Services. Beschreibungsorientierung: Die Service-Nutzer beschreiben über Nachrichten ihre Anforderung, jedoch nicht wie sie zu erbringen ist. Die Beschreibung der Nachrichten sowie der Service erfolgt durch maschinenverarbeitbare Metadaten. Die Beschreibung eines Service enthält nur solche Details, die für die Verwendung des Services notwendig sind.

24 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 14 Abbildung 2.3: Merkmale des SOA-Softwaredesignansatzes Geschäftsprozess-Orientierung: Ein Service bietet tendenziell wenige Operationen mit relativ großen und komplexen Nachrichten an. Die Services sind grob granuliert und stellen eine auf der Ebene von Geschäftsprozessen relevante Operation dar. Ausrichtung auf verteilte Systeme: Services werden tendenziell zum Aufbau und zur Integration von verteilten Systemen genutzt. Dieses ist jedoch keine Voraussetzung. Plattformunabhängigkeit: Die Schnittstellen der Services und die Nachrichten werden standardisiert und plattformunabhängig definiert. Die SOA legt keine Techniken zur Implementierung fest und ist somit technologieneutral. Wiederverwendbarkeit: Die Kombination aller Faktoren erzeugt eine erhöhte Wiederverwendbarkeit von Softwarekomponenten. Über Services sollen weiterhin Alt-Systeme genutzt werden können. Services sollen für eine Vielzahl von verschiedenen Systemen eine verwendbare Funktionalität erbringen. Mehrere Services können sich zu einem komplexeren Service zusammensetzen lassen. Anwendungen sollen basiert auf Services entwickelt werden. Im Englischen werden solche Anwendungen Composite Applications bezeichnet. Die Abbildung 2.3 stellt die Eigenschaften der SOA grafisch dar. Eine erfolgreiche Implementierung dieses Ansatzes muss jedoch erst beweisen, ob sie die genannten Eigenschaften aufweist und die Erwartungen wie Kostenreduktion bei Integrationsprojekten und Verringerung der Komplexität von IT-Infrastrukturen erfüllen kann. Im anschließenden Abschnitt wird die SOA auf das Problemfeld aus Kapitel 2.1 angewendet. Dabei soll aufgezeigt werden, wie die Eigenschaften der SOA helfen sollen, die dort beschriebenen Probleme zu beseitigen bzw. zu verringern.

25 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR Anwendung des SOA-Ansatzes Das in dem Kapitel 2.1 beschriebene Problemfeld wird im Folgenden mit Hilfe des SOA Ansatzes betrachtet. Die Zielsetzungen und die Lösungsansätze der SOA sollen anhand dieses Beispiels dargestellt werden. Dadurch wird die abstrakte Definition weiter konkretisiert. Die Beschreibung der IT-Infrastruktur der Autovermietung führt zu einer eindeutigen Rollenverteilung der einzelnen Teilsysteme. Die Mainframe-Anwendung stellt sich nun als Service-Anbieter dar. Die Internet- sowie die Callcenter-Anwendung, als Service-Nutzer, benötigten Informationen über die Verfügbarkeit von Mietfahrzeugen. Des Weiteren brauchen die Anwendungen die Möglichkeit eine Reservierung eines Mietwagens für einen Kunden durchzuführen. Die Mainframe-Anwendung sollte für diese Anforderungen zwei Services anbieten. Einen Service, welcher die Verfügbarkeit von Mietfahrzeugen innerhalb einer Region liefert und einen anderen Service, der die Reservierung eines Mietfahrzeugs durchführt. Um die Services noch weiter zu konkretisieren, werden die Schnittstellen mit Interfaces des Moduls Klassen aus der UML-Notation beschrieben. Abbildung 2.4 stellt eine mögliche Schnittstelle-Definition der Services dar. Die Service-Operationen werden in der Abbildung 2.5 genauer beschrieben. (a) Service: Ermittlung von Fahrzeugverfügbarkeiten (b) Service: Buchung eines Mietfahrzeugs Abbildung 2.4: Modellierung der Service-Schnittstellen Die Definition der Operationen der Services ist nicht als vollständig zu betrachten, sie berücksichtigen nicht den Aspekt der Sicherheit. Des Weiteren werden keine Sonderfälle, wie fehlerhafte Werte der übergebenen Attribute, berücksichtigt. Weitere Operationen werden benötigt, z.b. eine Operation zur Änderung einer gebuchten Reservierung. Zur Veranschaulichung des SOA Konzeptes genügen diese zwei Services mit ihren zwei Operationen. Die Definition der SOA beschreibt die Services als grobkörnig, weil sie eine Dienstleistung auf Ebene von Geschäftsprozessen erbringen. Dieses spiegeln die Services des dargestellten Beispiels wieder, denn beide Services stellen einen für Geschäftsprozesse relevanten Teilprozess dar. Der Ansatz der SOA schreibt nun vor, dass die Services unter einer plattformunabhängigen

26 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 16 (a) Operation: ermittleverfuegbarefahrzeuge() (b) Operation: buchefahrzeug() Abbildung 2.5: Beschreibung der Service Operationen

27 KAPITEL 2. SERVICEORIENTIERTE ARCHITEKTUR 17 Schnittstelle angeboten werden sollen. Wie solche Schnittstellen technisch realisiert werden können, soll erst später betrachtet werden. Unter der Prämisse, dass es möglich ist, sie plattformunabhängig zu definieren, könnten die Internet- und die Callcenter-Anwendung die unter einer Schnittstelle implementierte Geschäftslogik gemeinsam benutzten. Die SOA legt keinerlei Vorgaben für die Implementierung des Services unter der Schnittstelle fest. Es ist möglich eine bereits implementierte Softwarekomponente als Basis für die Services zu benutzen. Der SOA Ansatz erfordert so keine radikale Änderung bereits vorhandener IT-Infrastruktur, sondern nutzt bereits vorhandene Ressourcen und unterstützt deren Wiederverwendung. Werden Services nach diesen Vorgaben realisiert und von der Internet- und der Callcenter Anwendung entsprechend benutzt, besteht nur noch eine lose Kopplung zwischen den Systemen. Sollten in der Mainframe-Anwendung Anpassungen notwendig sein, muss gegebenenfalls die Implementierung des Services anpasst werden. Unter der Voraussetzung, dass die Schnittstelle nicht angepasst werden muss, haben die Anpassungen keine Auswirkungen auf die Service-Nutzer, weil diese nur über die Service-Schnittstelle auf den Server-Anbieter zugreifen. Der Einsatz der beschriebenen Services vereinfacht das in Kapitel 2.1 dargestellte Use-Diagramm. Abbildung 2.6: Verändertes Use-Case-Diagramm durch Einsatz von Services Das Use-Case-Diagramm (vgl. Abbildung 2.6) beinhaltet nur noch zwei Use-Cases. Die technischen Akteure Internet-Reservierungssystem und Callcenter-Anwendung kommunizieren über dieselben Use-Cases mit der Mainframe-Anwendung, es besteht kein Bedarf diese auf Grund von technischen Gegebenheiten weiter aufzuteilen. Der Akteur Callcenter- Mitarbeiter ist nicht mehr Bestandteil dieses Use-Case-Diagramms, denn durch die Bereitstellung der Funktionalität Ermittlung von Fahrzeugverfügbarkeiten als Service, kann diese in der Callcenter-Anwendung integriert werden und somit die Funktionalität dieser Anwendung einfach erweitert werden. Sie würde sich damit zu einer sogenannten Composite Application weiterentwickeln. Die Tätigkeiten des Callcenter-Mitarbeiters könnten so von einer zentralen Anwendung unterstützt werden, welche auf den Services von verschiedenen Systemen basiert. Somit könnte der häufige Wechsel zwischen den Anwendungen reduziert werden. Dieses visualisiert das veränderte Aktivitätsdiagramm (vgl. Abbildung 2.7) aus dem Kapitel 2.1. Sind solche Services definiert, können sie bei Bedarf auch unternehmensübergreifend angeboten werden. Das resultiert daraus, dass die Schnittstelle plattformunabhängig ist und keine