Serviceorientierte Architekturen (SOA)

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Standardsoftware
2.1 Betriebswirtschaftliche Standardsoftware
2.2 Softwarearchitekturen für SSW
2.2.1 Mainframe – Architektur
2.2.2 Client-Server Architektur
2.3 Historische Entwicklung betriebswirtschaftlicher SSW
2.3.1 Material Requirement Planning (MRP)
2.3.2 Material Resource Planning (MRP II)
2.3.3 Enterprise Resource Planning (ERP)

3 Serviceorientierte Architektur – Ein neues Architekturkonzept
3.1 Bisherige Probleme
3.2 Vision
3.3 SOA- im Detail
3.3.1 Begriffsbestimmung
3.3.2 Aufbau und Kernelemente
3.3.3 Forderungen und Eigenschaften einer SOA
3.4 Umsetzung mit Web Services
3.4.1 Begriffsbestimmung
3.4.2 Kernelemente und Protokolle
3.5 Nutzen und Probleme

4 Integration
4.1 Allgemein
4.2 Enterprise Integration
4.3 Cross-Enterprise-Integration ( B2B & B2C)

5 Auswirkung auf betriebswirtschaftliche SSW
5.1 Web Services als Enabler für ERP II
5.2 Einführung einer SOA am Beispiel der SAP

6 Fazit
6.1 Paradigma
6.2 Ausblick

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

1 Die Schichten eines Informationssystems

2 Architektur eines Mainframes

3 Zwei-stufige Client-Server Architektur

4 Drei-stufige Client-Server Architektur

5 Entwicklung der Unternehmen

6 Aufbau einer Serviceorientierten Architektur

7 Kernelemente einer SOA

8 Forderungen und Eigenschaften einer SOA

9 Umsetzung einer SOA mit Web Services

10 Diskutierte und verabschiedete Web Service Standards

11 Cross-Enterprise-Integration mit Web Services

12 Enterprise Services Architecture

13 Technologieentwicklung bei SAP

14 Entwicklung von Web Services

15 Roadmap zu Real-time Enterprise

1 Einleitung

Vielfältige organisatorische Änderungen, u.a. die Prozessorientierung, verlangen Anpassungen der IT, um neuen Herausforderungen, wie unternehmensübergreifende Zusammenarbeit, gewachsen zu sein. Die Organisation gilt dabei als Treiber für die IT und umgekehrt.

Die Globalisierung und Konsolidierung der Märkte und die damit verbundenen Produktivitätssteigerungen der Unternehmen zwingen die IT, sich ständig zu wandeln. Im Gegensatz zu funktionsorientierter Software etablieren die meisten Unternehmen bereits das Prozessdenken. Außerdem sind Unternehmen immer mehr gefordert, flexibel auf Änderungen der Märkte zu reagieren, was ein hohes Maß an Integration, nicht nur im Unternehmen, sondern auch über Unternehmensgrenzen hinweg bedeutet. Mit den Einsatz einer Serviceorientierten Architektur (SOA) scheint dieser Quantensprung durch die Verwendung neuer Informationssysteme, wie ERP II, nun möglich zu sein. Dies wirkt sich auf die Informationsstrategie eines Unternehmens aus und trägt somit zur Weiterentwicklung bei. Die sich hinter einem Hype befindliche Web-Service Technologie beeinflusst den Trend der Service-Orientierung dabei maßgeblich.

Es gilt nun im Rahmen dieser Arbeit herauszustellen, ob es sich bei der Verwendung einer SOA um ein neues Paradigma für die Entwicklung von Standardsoftware (SSW) handelt.

Dazu werden im ersten Teil der Arbeit Begrifflichkeiten im Rahmen von SSW, sowie mögliche Architekturen und verschiedene Standardsoftwarekonzepte näher betrachtet. Im Anschluss daran wird im zweiten Abschnitt das Konzept einer Serviceorientierten Architektur erläutert und am Beispiel von Web Services näher gebracht. Daraufhin wird auf die Bedeutung von SOA in Bezug auf Integrationsmöglichkeiten eingegangen. Bevor die Betrachtung der SOA als Paradigma und der Ausblick für zukünftige Entwicklungen stattfindet, werden die Auswirkungen auf betriebswirtschaftliche SSW, deren Entwicklung in Richtung ERP II sowie die Entwicklung am Beispiel der SAP aufgezeigt.

2 Standardsoftware

2.1 Betriebswirtschaftliche Standardsoftware

In einem Unternehmen tritt das Thema Standardsoftware meist während der Systementwicklung, in der Phase des Erstellens eines Soll-Konzeptes, auf. Nach Abschluss dieser Phase muss die Firma in der Lage sein, eine Make-or-Buy Entscheidung für die Einführung eines Softwaresystems treffen zu können. Fällt die Wahl dabei auf Fremdbezug, wird in vielen Fällen Standardsoftware eingekauft und eingeführt. Dabei werden als SSW „fertige Programme bezeichnet, die auf Allgemeingültigkeit und mehrfache Nutzung hin ausgelegt sind.“^[1] Des weiteren ist SSW funktionsübergreifend und modular aufgebaut. Da jedes Unternehmen spezifische Prozesse aufweist, wird diese Software durch Parametrisierung oder so genanntes Customizing an die speziellen Prozesse des Unternehmens angepasst. SSW weist gegenüber Individualsoftware Vorteile, wie kürzere Einführungszeit, Kostenreduzierung sowie einfachere zwischenbetriebliche Integration auf. Außerdem treten Nachteile, wie die oben genannte Anpassung an das Unternehmen und Abhängigkeiten von spezifischen Anbietern, auf.

Betriebswirtschaftliche SSW ist SSW, welche alle wesentlichen betrieblichen Funktionsbereiche eines Unternehmens abdeckt und somit neue Formen von Geschäftsprozessen, Organisationen und Unternehmen unterstützt, beschleunigt und ermöglicht.^[2] Die wohl bekanntesten Anbieter von betriebswirtschaftlicher SSW sind SAP, ORACLE, Microsoft und Baan. Während der letzten 40 Jahre gab es verschiedene Architekturen, sowie Konzepte betriebswirtschaftlicher SSW auf die im folgenden kurz eingegangen wird.

2.2 Softwarearchitekturen für SSW

Eine Softwarearchitektur stellt eine Abstraktion zur Reduzierung der Komplexität in der Veranschaulichung eines Softwaresystems dar.^[3] „’Der grundlegende Ansatz zur Strukturierung von Softwaresystemen ist eine Zerlegung in Schichten.’ Sie führen zu kohärenten und schwach gekoppelten Strukturen und bieten auch die Basis für eine physikalische Verteilung auf verschiedene Rechner.“^[4]

Ein Informationssystem besteht aus folgenden drei Schichten: der Präsentations-, der Anwendungs- und der Persistenzschicht.

Abbildung in dieser Leseprobe nicht enthalten

Dabei sorgt die Persistenzschicht, auch Datenschicht genannt, für die dauerhafte Speicherung der Daten, welche heutzutage vorwiegend in relationalen Datenbanksystemen stattfindet. Diese Schicht ist für die Bereitstellung dieser Daten für die darüber liegende Schicht verantwortlich. Die Anwendungsschicht, auch als Geschäftslogik- oder Applikationsschicht bezeichnet, realisiert sämtliche fachliche Funktionalitäten der Anwendung. Auf die unter ihr liegende Persistenzschicht greift sie über definierte Schnittstellen zu. Des weiteren werden in dieser Schicht Operationen durchgeführt, welche schließlich ihre Ergebnisse zur Darstellung an die Präsentationsschicht weitergeben. Durch die Darstellung verschiedener Informationen mittels einer Benutzeroberfläche ( meist GUI), dient die Präsentationsschicht zur Kommunikation mit dem Menschen oder anderen Computern. Außerdem ist es möglich, auf entsprechende Ereignisse zu reagieren und somit eine Weiterleitung der entsprechenden Daten an die Anwendungsschicht auszulösen.^[5]

2.2.1 Mainframe – Architektur

Bei Mainframe-Systemen sind die drei genannten Schichten in eine einzige Schicht zusammengeführt, d.h. dass die gesamte Logik der Anwendungen, die Datenhaltung sowie die Präsentation in einer einzigen Applikation liegen. Aktivitäten finden i.d.R. zwischen dem System und einfachen Terminals statt. Diese Terminals bestehen meist nur aus Bildschirmen und Tastaturen. Durch diese Aufteilung ist es möglich, sich auf die optimale Ausnutzung der CPU-Leistung und somit auf eine optimale Performance zu konzentrieren. Dem gegenüber stehen auch Nachteile, wie die Kosten für die Anschaffung und den Betrieb, sowie die schlechte Portierbarkeit, aufgrund des Einsatzes herstellerspezifischer Schnittstellen und Systeme.

2.2.2 Client-Server Architektur

Abbildung in dieser Leseprobe nicht enthalten

Durch die Dezentralisierung der Datenverarbeitung dieser oben genannten proprietären Strukturen und durch den verstärkten Einsatz von PCs und Workstations, anstatt der einfachen Terminals, entstanden in den 80er Jahren die ersten offenen Rechnerkonzepte.^[6] Durch die Leistungssteigerung der PCs war es nicht länger notwendig, die Präsentationslogik zusammen mit den anderen Schichten auf einem Rechner zu halten. Man löste diese heraus, um sie in den Client zu integrieren. Damit ist die erste zwei-stufige Client-Server Architektur entstanden und man kann nun zwischen einem Serviceanbieter und einen Servicenutzer unterscheiden. Diese Ausgliederung hat zudem folgende Vorteile. Zum einen ist es möglich, die Benutzeroberfläche den entsprechenden Anforderungen anzupassen, den Server von der Verarbeitung von Oberflächen zu befreien und somit mehr Ressourcen für die Anwendungs- und Persistenzschicht zu schaffen. Zum anderen kann man zwischen Thin-Client und Fat-Client unterscheiden, je nachdem wo sich die Anwendungslogik befindet. Durch diese Unabhängigkeit der Präsentationsschicht sind Informationssysteme auf verschiedene Plattformen portierbar.

Ein großer Nachteil der zwei-stufigen Architektur offenbart sich darin, dass nur eine begrenzte Anzahl an Clients gleichzeitig mit dem Server kommunizieren können und somit das System nur begrenzt skalierbar und dadurch unflexibel ist. Um diese Nachteile zu beseitigen, wird eine neue Schicht, in die die Anwendungsschicht verlagert wird, eingeführt. Diese Schicht kann auch als Middleware bezeichnet werden. Dadurch wird die Architektur komplexer. Durch Verwenden verschiedener Server für die Schichten kann eine ausreichende Skalierbarkeit erreicht werden. Das wohl bekannteste Produkt, welches auf dieser drei-stufigen Architektur basiert, ist SAP R/3.

Abbildung in dieser Leseprobe nicht enthalten

Die dreistufige Architektur wird durch das Einbringen mehrerer Server in die Middleware-Schicht auf eine N-stufige Architektur skaliert.

2.3 Historische Entwicklung betriebswirtschaftlicher SSW

Im folgenden wird kurz auf die verschiedenen Standardsoftwarekonzepte der Vergangenheit eingegangen. Dabei erhebt diese Auflistung keinen Anspruch auf Vollständigkeit.

2.3.1 Material Requirement Planning (MRP)

Anfang der 70er wurden Systeme, als Nachfolger von einfachen Bestandsaufnahmesystemen, zur Planung des Materialbedarfs entwickelt und in Unternehmen eingeführt. Dadurch war es möglich, nicht nur eine Bestandskontrolle durchzuführen, sondern auch den Fluss von Komponenten und Rohstoffen zu steuern und voraus zu planen.^[7] Bereits in der Grundform war die Fertigungsstufen-orientierte Zerlegung der Mengenplanung möglich. Dies ermöglichte für jede Fertigungsstufe eine sukzessive Brutto- und Nettorechnung, Losplanung, Vorlaufsverschiebung und Bedarfsauflösung für die nächste Stufe und somit das sogenannte Master Production Scheduling. Als eine Erweiterung wurden auch Kapazitätsrestriktionen berücksichtigt, sowie der MRP-Kern in ein Regelkreissystem eingebunden.^[8] Software-architektonisch waren die MRP-Systeme als eine Mainframe-Anwendung aufgebaut.^[9] D.h. alle Applikationen und somit alle Daten waren zentral auf einem Großrechner angesiedelt. Eines der größten Probleme war die Unstabilität der Systeme, welche dazu führte, dass unterschiedliche Ergebnisse auf ein und dieselbe Anfrage ausgegeben wurden.

2.3.2 Material Resource Planning (MRP II)

Zu Beginn der 80er wurden MRP II - Systeme eingeführt, welche MRP plus neue Funktionalitäten, wie Shop Floor, Vertriebsmanagement sowie Termin- und Kapazitätsplanung zu einem geschlossenen, integrierten System zusammenführten. Ziel war es dabei, die Kapazitätsauslastung zu maximieren sowie die Durchlaufzeit zu verringern und somit den gesamten Produktionsprozess zu optimieren. Diese Systeme liefen, wie die MRP-Systeme, auf Mainframes, jedoch nun in Verbindung mit lokalen Netzwerken. Des weiteren beruhten diese Systeme auf einem hierarchischen Konzept, welches explizite, semantisch begründbare Planungsebenen beinhaltete.^[10]

2.3.3 Enterprise Resource Planning (ERP)

In den 90ern gab es dann erneut einen Trend und zwar in Richtung ERP-Systeme.

„ Unter ERP ( Abkürzung von engl.: enterprise resource planning) versteht man ein aus mehreren Komponenten bestehendes integriertes Anwendungspaket, das alle wesentlichen betrieblichen Funktionsbereiche abdeckt ( Beschaffung, Produktion, Vertrieb, Finanzwesen, Personalwirtschaft usw.). Die Integration wird dabei von einer zentralen Datenbank unterstützt, wodurch Datenredundanz vermieden und integrierte Geschäftsprozesse ermöglicht werden.“^[11]

ERP-Systeme werden des weiteren durch Dialogprogrammierung, Belegprinzip, Integration, Offenheit, Internationalität sowie Tele-Processing, um einige zu nennen, charakterisiert. Die Releasestrategie, das Partnerkonzept und die Mitarbeiter spielen ebenfalls eine wichtige Rolle. In diesen ERP-Systemen, welche die MRP II-Systeme um kaufmännische Funktionalitäten ergänzen, standen jedoch eine lange Zeit nur interne Prozesse im Mittelpunkt. Durch das Aufkommen des Internets, kamen erste Gedanken zur Integration der Geschäftspartner auf. Die Einbindung von Lieferanten- und Kundensystemen läuft bisher, u.a. aufgrund fehlender Standardisierung von Schnittstellen, nur schleppend. In der Vergangenheit wurde deshalb versucht, z.B. mittels Electronic Data Interchange (EDI), Daten verschiedener Systeme auszutauschen, was sich als äußerst kostenintensiv und aufwendig herausstellte.

Bei ERP-Systemen wurde in den letzten Jahren konsequent die Client-Server Technik eingesetzt, welche es durch leistungsstarke PCs ermöglichte, einheitliche grafische Oberflächen für den Anwender zu schaffen.

3 Serviceorientierte Architektur – Ein neues Architekturkonzept

3.1 Bisherige Probleme

Abbildung in dieser Leseprobe nicht enthalten

Mitte der 80er waren durch die generelle Funktionsorientierung in den Unternehmen starke Mauern zwischen den funktionalen Abteilungen entstanden. Jede Abteilung hatte eigene Software und Informationssysteme, welche meist durch Laien nebenher betreut worden sind. Als man sich Anfang der 90er an Geschäftsprozessen orientierte, gelang es auch, unternehmensweite Softwaresysteme, welche von sich neu bildenden IT-Abteilungen betreut wurden, einzuführen und somit die Grenzen zwischen den Abteilungen aufzuheben. Durch diese Prozessorientierung konnte man nun eine einheitliche Unternehmensdarstellung schaffen. Aufgrund des Aufkommens der Internettechnologie stellte man rasch fest, dass die aktuellen IT-Systeme bislang nur intern von Bedeutung waren und man hinsichtlich seiner Lieferanten und Kunden immer noch isoliert und schwer erreichbar war. Durch den Druck von Time-To-Market sowie Produktivitätssteigerungen bei gleichzeitiger Kostenreduzierung stellte sich bald heraus, dass die eigenen Systeme mit den Systemen der Geschäftspartner integriert werden müssen, um an den hart umkämpften Märkten weiterhin bestehen zu können. Zahlreiche Versuche der Integration schlugen fehl, da ein Konzept fehlte, welches u.a. die Anzahl der Schnittstellen reduzierte und somit die Komplexität verringern konnte. Des weiteren kamen Probleme bei der Integration von Altsystemen auf, da früher viele Systeme durch weitere Insellösungen ergänzt wurden sind, was die Anzahl der Schnittstellen erhöhte. Neben der Integration der Anwendungen und der Geschäftsprozesse der Geschäftspartner ist die Heterogenität, d.h. die Verschiedenheit der Systeme, ein zentrales Problem bisheriger Integrationsversuche.

Eines der größten Probleme waren jedoch fehlende Standards, da jedes Unternehmen versuchte, nicht nur technisch, sondern auch fachlich, eigene Standards zu definieren.

3.2 Vision

Beim ersten Sichten von Literatur über SOA wird man schnell auf folgende visionäre Vorstellung hinsichtlich einer solchen Architektur aufmerksam. Diese Vorstellung wird anhand einer Geschichte präsentiert^[12], in welcher ein Geschäftsmann eine mehrtägige Geschäftsreise mit diversen Kundenbesuchen, sowie die dazugehörigen Flug-, Mietwagen- und Hotelbuchungen vornimmt. Dazu verwendet er im voraus eine Web-Anwendung und gibt Daten, wie zu besuchende Kunden, sowie Beginn und Ende der Reise an. Automatisch erreichen ihn nach kurzer Zeit die notwendigen Flug-, Mietwagen- sowie Hoteldaten. Sein Online-Kalender wird automatisch mit den Kalendern der Kunden abgeglichen und ein entsprechender Termin vereinbart. Während der Reise kann er z.B. Kundendaten sowie Änderungen des Reiseverlaufs ständig über sein mobiles Endgerät überprüfen und bekommt zusätzlich Instant Messages geschickt. Selbst das Navigationssystem des Mietwagens ist bereits automatisch auf den zu besuchenden Kunden eingestellt. Dies ist nur ein kleiner Ausschnitt aus der Geschichte des vielreisenden Managers. Jedoch wird bereits deutlich, dass in diesem Fall die Systeme mehrerer Geschäftspartner stark miteinander verzahnt sind.

Zur Zeit ist diese Geschichte noch eine Vision, sie soll aber in naher Zukunft bereits Realität werden. Des weiteren hofft man folgendes umsetzen zu können: „make all your different application systems act as one huge virtual application that has full access to all the different capabilities in all the different application systems.“^[13] Somit ist es nicht verwunderlich, dass Analysten das Marktvolumen für SOA auf rund 43 Milliarden Dollar im Jahre 2010 schätzen.^[14]

3.3 SOA- im Detail

3.3.1 Begriffsbestimmung

Eine SOA ist eine Softwarearchitektur. „Ein wichtiger Aspekt von Software-Architektur ist, dass sie eine Abstraktion darstellt, die zur Reduktion der Komplexität in der Veranschaulichung eines Software-Systems wesentlich beiträgt.“^[15] Somit wird eine solche Architektur häufig als Bauplan für ein Software-System angesehen, in welchem die Systemkomponenten und ihre Interaktionen auf einem abstrakten Level beschrieben werden. Der Begriff der SOA ist nicht neu, sondern findet schon seit Ende der 80er, seit dem Aufkommen des Remote Procedure Calls (RPC), Verwendung. Daraufhin wurde mit proprietären Ansätzen versucht, eine solche Architektur z.B. mit DCOM^[16] oder CORBA^[17] umzusetzen. Dies war aber meist führenden Projekten mit visionären Softwarearchitekten und den notwendigen finanziellen Ressourcen vorbehalten.^[18] Durch den Boom von Web Services, auf dieses Thema wird später eingegangen, rückt SOA wieder in den Vordergrund der Interessen. Unter einer SOA versteht man folgendes: „an application architecture within which all functions are defined as independent services with well-defined invokeable interfaces which can be called in defined sequences to form business processes“^[19]. Nach dieser Definition ist das Prinzip einer SOA, die Bereitstellung von Funktionalitäten als wiederverwendbare Services mit aufrufbaren Schnittstellen zur Gestaltung von Geschäftsprozessen. Anders ausgedrückt, beinhaltet eine SOA das Zerstückeln von Prozessen in modulare Services, die durch standardisierte Schnittstellen nutzbar sind.^[20] Damit ist klar, dass das Kernelement einer SOA ein Service ist, welcher wiederum von der Gartner Group folgendermaßen definiert wird: „ Services are software modules that are accessed by name via an interface, typically in a request-reply mode.“^[21] Dabei findet die Kommunikation über nachrichtenbasierten XML-Transfer statt. Prinzipiell lässt sich diese Kommunikation synchron oder asynchron, durch die Kopplung an entsprechende Protokolle wie HTTP oder SMTP, realisieren. Des weiteren sollen die Schnittstellen plattformunabhängig, dynamisch aufrufbar und abgeschlossen sein. Bei Einhaltung des SOA Prinzips werden neue Anwendungen nicht mehr monolithisch sein, sondern aus einer Ansammlung von Services, welche lose gekoppelt sind, bestehen.^[22]

[...]

---

^[1] Hansen/ Neumann, 2001, S. 152

^[2] Vgl. Kästle, 2003, 11-4 ff.

^[3] Vgl. Dustdar/ Gall/ Hauswirth, 2003, S. 2

^[4] Dunkel/ Holitschke, 2003, S. 16, zitiert nach Buschmann et al., 1996, o.S.

^[5] Vgl. Dunkel/ Holitschke, 2003, S. 17 ff.

^[6] Vgl. im Folgendem Keller, 1999, S. 9 ff.

^[7] Vgl. Amor, 2000, S.165

^[8] Vgl. Galley, 2002, S.19

^[9] Vgl.Koss/ Bramer/ Peterson, 1998, o.S.

^[10] Vgl. Galley, 2002, S. 20

^[11] Hansen/ Neumann, 2001, S. 523

^[12] Vgl. im Folgendem Barry, 2003, S. 5 ff.

^[13] Fontana, 2003, o.S.

^[14] Vgl. Reiter, 2004, S. 8

^[15] Dustdar/ Gall/ Hauswirth, 2003, S. 2

^[16] DCOM= steht für Distributed Component Object Model und ist die Erweiterung des Windows Standards COM, welcher ein komponentenbasiertes Objektmodell darstellt. DCOM ermöglicht den Einsatz von COM in heterogenen Systemen.

^[17] CORBA= „ ist ein Standard zur Entwicklung objektorientierter Anwendungen in verteilten und heterogenen Systemen“ Hansen/ Neumann, 2001, S. 168

^[18] Vgl. Schulte, 2002, S. 2

^[19] Channabasavaiah/ Holley/ Tuggle Jr., 2003, o.S.

^[20] Vgl. Buchholz, 2003, S. 71

^[21] Natis, 2003, o.S.

^[22] Vgl. Mc Dowall, 2003, o.S.