Service Oriented Architecture

Transkript

1 Seminararbeit im Studiengang M.Sc. IT-Management and Information Systems an der Fachhochschule der Wirtschaft (FHDW) Service Oriented Architecture Vorgelegt von: Sascha Kossmann, Björn Schrader und René Büst Prüfer: Prof. Dr. Eckhardt Koch Eingereicht am: 18. Juli 2009

2 Verzeichnisse i Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis I IV 1 Thematische Einleitung Thematische Gliederung Thematische Abgrenzung SOA Einleitung 2 3 Situationsanalyse Architektur vor der SOA Einführung Architektur nach der SOA Einführung Vergleich der Architekturen SOA Strategie Ziele einer SOA Strategie Betriebswirtschaftliche Analyse der SOA Strategie Besserer ROI für bestehende IT-Systeme Verbesserte Kundenzufriedenheit Bessere Abstimmung von IT- und Business-Zielen Technische Analyse der SOA Strategie Technische Eigenschaften Technische Vorteile nach Einführung einer SOA Erkenntnisse der SOA Strategie Bekannte Probleme bei der Einführung einer SOA Bekannte Missverständnisse zum Thema SOA "Wenn du SOA einführst, sind alle deine Komponenten automatisch kompatibel zu einander" [SoaThe] "Wenn du Web Services verstehst, hast du keine Probleme eine SOA aufzubauen." [SoaThe] "SOA löst fachliche Probleme" [SoaThe] SOA und der Bezug zu E-Business 13

3 Verzeichnisse ii 7 Unternehmen und deren SOA Einsatz Deutsche Post Brief Gründe Ziele Umsetzung Nutzen Wiederverwendung von Services und Vermeidung redundanter Softwareentwicklung Kürzere Projektlaufzeiten und schneller Time-To-Market Niedrigere Wartungskosten Bessere Reaktionsfähigkeit auf neue Geschäftsanforderungen SOA - Technologie 17 9 SOA & Sicherheit Anforderungen Authentifizierung Autorisierung Vertraulichkeit/ Privatsphäre Integrität Verfügbarkeit Risiken & Bedrohungen Replay Attacks XML Spezifische Angriffe WSDL- und Service Scanning Kompromittierung eines Service Unberechtigte Servicenutzung Konzepte Sicherheit auf Transportebene Sicherheit auf Nachrichtenebene XML-Firewalls/ XML-Gateways Sicherheit auf Fachlicher Ebene Applikationssicherheit Security as a Service Security as Infrastructure Standardisierte Sicherheitsmaßnahmen

4 Verzeichnisse iii XML-Security WS Security Security Assertion Markup Language Fazit Ausblick 27 LITERATUR 28

5 Verzeichnisse iv Abbildungsverzeichnis 1 Vergleich der Architekturen The Context of IT Investment Projects QM-Prozessmodell Requirements Management & Development Assurance SOA-based Business Services and Solutions level Erfolgreichen Prozess- und Organisationsoptimierung im Unternehmen Wichtige Eckpunkte der SOA E-Business/Service Providers Infrastructure Der Zugriff über Services auf Applikationsdomänen Der Service Kundenmanagement Eine XML Bomb XPath-Injection Sicherheit auf Transportebene Sicherheit auf Nachrichtenebene Security as a Service

6 1 THEMATISCHE EINLEITUNG 1 1 Thematische Einleitung 1.1 Thematische Gliederung Im ersten Teil der Diskussion über die serviceorientierte Architektur (SOA) werden wir uns sehr stark mit der Einführung und den betriebswirtschaftlichen Aspekten rund um die SOA Strategie beschäftigen. Nach der betriebswirtschaftlichen Diskussion wird ein technischer Abschnitt folgen, der abschließend um Empfehlungen aus praktischen Erfahrungen und bekannten Missverständnissen ergänzt werden soll. < Ausarbeitung durch Björn Schrader > Der zweite Teil soll ein praxisnahes SOA Beispiel geben. Wir haben uns für die Deutsche Post entschieden und werden Ziele, Umsetzung und auch den Nutzen der SOA Einführung analysieren. < Ausarbeitung durch René Büst > Technische Details der SOA werden den dritten Teil der Ausarbeitung bilden. Hier werden die bereits im ersten Teil erwähnten Web Services aufgegriffen und zusammen mit weiteren technischen Details diskutiert. < Ausarbeitung durch Sascha Kossmann > Sicherheitsaspekte und sich daraus ergebene Sicherheitsanforderungen sollen den vorletzten Teil bilden. Hier werden bekannte Risiken und Bedrohungen sowie Sicherheitskonzepte und -Maßnahmen genauer erläutert. < Ausarbeitung durch René Büst > Der letzte Teil wird eine kritische Würdigung geben, die sowohl Vorteile als auch Nachteile der SOA kritisch erläutert und abschließend die Thematik mit einem Ausblick in die Zukunft abrundet. < Ausarbeitung durch Sascha Kossmann >

7 2 SOA EINLEITUNG Thematische Abgrenzung Wir haben für die gesamte Ausarbeitung Schwerpunkte der SOA Thematik ausgewählt und diese intensiv untersucht. Eine Abdeckung aller Themengebiete rund um SOA ist an dieser Stelle nicht möglich, da dieses den vorgegebenen Rahmen der Ausarbeitung überschreiten würde. 2 SOA Einleitung "Eine service-orientierte Architektur ist einer der wichtigsten Wegbereiter für das Unternehmen des 21. Jahrhunderts" [SagSoC] SOA wird heute als Trend in weltweit agierenden Unternehmen vermarktet und ist am Markt als solcher akzeptiert. Als erfolgreiches Beispiel soll das SOA Konsortium erwähnt werden, das weltweit agierende, SOA unterstützende und betreibende Unternehmen bündelt und die SOA Strategie und das einheitliche Verständnis über die Thematik weiter vorantreibt. "Um die Vorteile der SOA zu nutzen sind signifikante Änderungen in der IT und im Business notwendig" [SagSoC] In dieser Ausarbeitung möchten wir das zentrale Statement herausarbeiten, dass SOA mehr als eine technische Architektur darstellt. Vielmehr handelt es sich um eine Strategie die signifikante Änderungen am Unternehmen sowohl auf Seite des Business Prozesses als auch auf Seite der technischen Architektur voraussetzt.

8 3 SITUATIONSANALYSE 3 3 Situationsanalyse Um den Wechsel der Strategien vor und nach der Zeit um die SOA Einführung zu beschreiben, sollen zum Einstieg sowohl die bestehende als auch die geplante Architektur auf einem abstrakten Level genauer analysiert und erläutert werden. 3.1 Architektur vor der SOA Einführung Vor der SOA Einführung wurden in Unternehmen oft separate Datensilos geschaffen, die sich schwer in bestehende Infrastrukturen integrieren ließen. Wenn man diese Datensilos einmal genauer untersucht, so stellt man fest, dass sie oft sehr schwerfällig und von anderen Systemen getrennt sind. Die logische Folgerung ist, dass sich die Systeme als sehr unflexibel darstellen und eine Interaktion bzw. Integration nur sehr eingeschränkt ermöglichen. Die eben beschriebenen "Silos" verwalten oft ganze Anwendungen und Daten kompletter Geschäftsprozesse. Eine fehlende Kompatibilität hat zur Folge, dass diese Daten bei Bedarf nicht weiter verwendet und somit aufwändig neu angelegt werden müssen. Resultierend war eine aufwändige bzw. teure Pflege. Zusätzlich ergab sich ein komplexer Wartungsprozesse der Systeme und deren Informationen. 3.2 Architektur nach der SOA Einführung Wenn wir über eine Zeit nach der gelungenen Einführung einer SOA Strategie sprechen, so analysieren wir gemeinsam genutzte Services über Systemgrenzen hinaus. Die Installation dieser Services erlaubt eine Zusammenarbeit bzw. Interaktion verschiedener Dienste untereinander. Auch die Integration bestehender Services in Neuentwicklungen ist mit der SOA problemlos möglich. Folgen der SOA Einführung sind, dass Funktionalitäten bzw. Geschäftsprozesse, die durch einzelne Funktionalitäten abgebildet werden, in Services ausgelagert werden. Diese Services sind in der Regel lose gekoppelt. Nach der Einführung von Services sollte zum Beispiel keine manuelle Datenintegration im Backend-Bereich mehr notwendig sein. Information werden von entsprechenden Diensten auf Anfrage zur Verfügung gestellt. Anfragende Komponenten werden in diesem Fall ebenfalls von Services abgebildet.

9 3 SITUATIONSANALYSE Vergleich der Architekturen Ein direkter Vergleich der Architekturen der Vergangenheit und der Zukunft zeigt den Wandel von geschlossenen, monolithischen System zu gemeinsam genutzten, kompatiblen und integrierten Services. Wurden in der Architektur vor der Einführung von SOA Zugriffe auf Informationsquellen bzw. Funktionalitäten separat und für jede Notwenigkeit neu implementiert, so können heute standardisierte Services einmalig implementiert und in der Zukunft wiederholt genutzt werden. Abbildung 1: Vergleich der Architekturen Quelle: (Juli 2009) Wieder verwendbare Abbildungen von Geschäftsprozessen erlauben es außerdem, bestehende Services zu neuen, übergreifenden Services zu kombinieren (siehe Abbildung 1). Die resultierende kurze Implementierungsphase bietet einen erkennbaren Mehrwert für den Kunden und damit einen Vorteil gegenüber Konkurrenzarchitekturen, die für wiederholte Kundenanfragen einen großen Aufwand generieren. Zudem zeigt die Abbildung eine klare Trennung in die verschiedenen Service Layer. Mit Hilfe dieser Trennung in Applikationsschichten lassen sich einzelne Services ganzer Applikationen leicht austauschen, kosteneffizient erweitern und anpassen.

10 4 SOA STRATEGIE 5 4 SOA Strategie Nach der Einführung in die Thematik und der abstrakten Analyse der Architekturen sollen die Ziele der SOA Strategie analysiert werden. Zudem werden sowohl betriebswirtschaftliche als auch technische Eigenschaften diskutiert. 4.1 Ziele einer SOA Strategie Ziel einer SOA Strategie ist die Bereitstellung fachlicher Dienste als Services und die Bereitstellung von Funktionalitäten über standardisierte Schnittstellen. "Die service-orientierte Architektur ist ein Systemarchitektur-Konzept, das die Bereitstellung fachlicher Dienste und Funktionalitäten in Form von Services vorsieht. Ein Service ist in diesem Kontext eine Funktionalität, die über eine standardisierte Schnittstelle in Anspruch genommen werden kann." [SOAErNu] Das SOA einführende Unternehmen untersucht im Rahmen der Einführung interne Prozesse und deren Abbildung in der Technologie. Anschließend wird über Anpassungen dieser Services die Möglichkeit geschaffen, komplette Business Prozesse über Services abzubilden. Vorteile dieser Architektur sind eine leichtere Verständlichkeit der durch komplexe Technologien umgesetzten Funktionalitäten für nicht Techniker (es handelt sich weiterhin "nur" um einen abstrakten Business Prozess) und eine flexiblere Ausrichtung des Unternehmens an die Anforderungen des Marktes. Im Idealfall bildet die SOA komplette Geschäftsprozesse mit Hilfe der IT ab. 4.2 Betriebswirtschaftliche Analyse der SOA Strategie Nach der Diskussion von Zielen einer SOA gilt es nun die betriebswirtschaftlichen Vorteile dieser Strategie genauer zu erläutern.

11 4 SOA STRATEGIE Besserer ROI für bestehende IT-Systeme Zu Beginn soll der bessere Return on Investment (ROI) für die bestehenden IT Systeme erwähnt werden. Abbildung 2: The Context of IT Investment Projects Quelle: (Juli 2007) Abbildung 2 zeigt die Abhängigkeit des ROI von den zugrundeliegenden Projekten aus den Business Prozessen. Aktuelle Erfahrungen zeigen, dass durch die Einführung einer SOA selten bestehende Anwendungen ersetzt werden. Vielmehr bietet sich die Möglichkeit Funktionen von Legacy-Programmen durch Transformation in Services in die neu angelegte Architektur zu integrieren und die Lebensdauer der Altsysteme zu erhöhen. Durch die Integrierung der Alt-Systeme werden somit historische Investitionen geschützt. Zusätzlich ermöglicht eine Integration bestehender Alt-System einen reibungslosen Übergang zwischen den Architekturgenerationen.

12 4 SOA STRATEGIE Verbesserte Kundenzufriedenheit Abbildung 3: QM-Prozessmodell Quelle: (Juli 2009) Nach heutigen Erfahrungen und statistischen Erhebung ist es für den Kunden immer wichtiger bestehende oder nach Kundenwünschen implementierte Geschäftsprozesse verstehen, analysieren und bewerten zu können. Abbildung 3 zeigt die Transformation von Kundenforderung in die zu erbringende Kundenzufriedenheit. Die Abbildung kompletter Geschäftsprozesse durch die IT ermöglicht eine leichtere Kundenanalyse und lässt eine offene Diskussion über Geschäftsprozesse und deren Implementierung zu. Zusammen mit der Flexibilität der SOA ermöglicht dieses eine schnelle Reaktion auf Kundenbedürfnisse und eine direkte Verbesserung der Kundenzufriedenheit Bessere Abstimmung von IT- und Business-Zielen Wie im vorherigen Kapitel beschrieben liefert eine SOA im Idealfall ein komplettes Abbild der gesamten Unternehmensprozesse. Durch die mögliche Abbildung der Schlüsselprozesse durch visuelle Hilfsmittel (z.b. die formale Methode der Modellierung von Systemen und deren Prozessen mit Hilfe von Petri-Netzen) wird es den Fachabteilungen und auch dem Kunden ermöglicht umgesetzte Prozesse besser analysieren zu können. Dieses beutet sowohl auf technischer Ebene als auch aus Sicht der Manager eine leichtere Umsetzung der Prozesse (siehe Abbildung 4).

13 4 SOA STRATEGIE 8 Abbildung 4: Requirements Management & Development Assurance Quelle: (Juli 2009) Ist eine bessere Verständlichkeit gegeben, so lassen sich Innovationsentscheidungen gegenüber Entscheidungsträgern besser argumentieren, was im Endeffekt zu einer Steigerung der Unternehmensdynamik beiträgt. In einer SOA sind die Chancen das Unternehmen durch Innovationen voranzutreiben in der Regel deutlich erhöht. Wenn zudem sowohl auf wirtschaftlicher als auch auf technischer Ebene über die gleichen Ziele und mit dem gleichen Verständnis der notwendigen Änderungen gesprochen wird, ermöglicht dieses eine bessere Abstimmung und Einhaltung der strategischen Unternehmensziele. 4.3 Technische Analyse der SOA Strategie Nach der Diskussion der betriebswirtschaftlichen Eigenschaft gilt es im nächsten Schritt die technischen Eigenschaften zu analysieren Technische Eigenschaften Die Einteilung der zu erbringenden Funktionalitäten in Services bietet betriebswirtschaftliche Vorteile. Aus technischer Sicht fördert diese Einteilung die architektonische Komponierbarkeit separierter Services zu einer Gesamtapplikation.

14 4 SOA STRATEGIE 9 Abbildung 5: SOA-based Business Services and Solutions level Quelle: (Juli 2009) Durch die Verwendung offener Standards wie XML, SOAP oder JMS (siehe Abbildung 5) wird die Möglichkeit der gezielten Wiederverwendung gefördert. Die Verwendung offener Standards erlaubt zudem die unternehmensübergreifende Nutzung entstandener Services Technische Vorteile nach Einführung einer SOA Zu den technischen Vorteilen nach der Einführung der SOA kann gesagt werden, dass durch die Einführung von Services eine verbesserte Integration bestehender Lösungen in die neue Architektur möglich ist. Die vereinfachte Integration mindert Kosten und stellt einen Wettbewerbsvorteil gegenüber Mitbewerbern dar. Die Investitionen in eine einheitliche Kommunikationsstruktur, ebenfalls abgebildet durch bestehende Standards, führen durch die sich erübrigende Diskussion der aufzusetzenden Kommunikationsstruktur zu einer Performanceverbesserung zu Projekt- / Produktionsbeginn. Services in einer SOA werden über bekannte Schnittstellen sowohl intern als unternehmensübergreifend genutzt. Der Vorteil der SOA ist, dass Clients unabhängig vom Aufbau bzw. der Realisierung des Services erstellt werden können und sich nur um den Aufruf, die Interaktion mit dem Service kümmern müssen. Wichtig ist "nur" die Einhaltung der Definition der Schnittstelle. Beim Aufruf bestehender SOA Services spricht man daher von dem Aufruf einer Blackbox.

15 5 ERKENNTNISSE DER SOA STRATEGIE 10 Abbildung 6: Erfolgreichen Prozess- und Organisationsoptimierung im Unternehmen Quelle: (November 2008) Auf Kostenseite erlauben standardisierte Schnittstellen bzw. festgelegte architektonische Richtlinien schnelle und kostengünstige Entwicklungen. Zusammen mit der erhöhten Verständlichkeit der zu erbringenden Lösung und der flexiblen (IT)-Prozessstrukturen ergibt sich ein Argumentationsvorteil in der Diskussion um eine SOA Einführung. Flexible und immer wieder angepasste (Geschäfts-) Prozesse bieten die Möglichkeit einen kontinuierlichen Verbesserungsprozess (siehe Abbildung 6) dauerhaft zu implementieren. 5 Erkenntnisse der SOA Strategie Nach der betriebswirtschaftlichen und technischen Analyse der SOA wollen wir uns mit der Praxis beschäftigen und bekannte Probleme der SOA Einführung und entstandenen Missverständnissen genauer erläutern. 5.1 Bekannte Probleme bei der Einführung einer SOA In den letzten Jahren ist SOA zu einem Schlagwort in Unternehmensstrategie(n) geworden. Bei der Einführung der SOA haben sich allerdings immer wieder Probleme ergeben (siehe Abbildung 7), die an dieser Stelle diskutiert werden sollen.

16 5 ERKENNTNISSE DER SOA STRATEGIE 11 Abbildung 7: Wichtige Eckpunkte der SOA Quelle: (Juli 2009) Ein häufig auftretendes Problem ist, dass die neu eingeführte Strategie immer nur so lange auf bekannten Standards aufsetzt, bis die Architektur an unternehmensspezifische Grenzen stößt. Wenn man an dieser Stelle den standardisierten Weg verlässt und unternehmensspezifische Anpassungen implementiert muss jeden Unternehmen bewusst sein, dass ein Großteil der Vorteile der SOA (z.b. unternehmensübergreifende Verwendung) nicht mehr genutzt werden kann. Lassen sich SOA Standards im Unternehmen nicht anwenden, so deutet dieses oft auf falsch definierte Prozesse hin. An dieser Stelle sollten zuerst bestehende Prozesse genauer analysiert werden, bevor über die strategische Entscheidung der unternehmensspezifischen Anpassung der SOA nachgedacht wird. Ein weiteres Problem ergibt sich in der Planung einer SOA Einführung. In dieser Planung wird oft ein hoher Aufwand in die technische Gestaltung der neuen Architektur gesteckt. Die Migration der Bestandsdaten bzw. bestehender Altsysteme wird vernachlässigt, so dass es bei der Einführung zu Problemen kommt. Diese Probleme können durch eine intensivere Situationsanalyse vermieden werden. Werden heute vornehmlich die technischen Vorteile der Architektur gesehen, so versäumt man in der Planung häufig die Anforderungen der SOA an Performance und Security zu berücksichtigen. Probleme ergeben sich in der Regel nicht auf den ersten Blick. Erst eine langfristige Analyse deckt schwächen der Umgebung auf. An dieser Stelle sollte auf Erfahrungen von Partnerunternehmen oder auf Fachpublikationen zurückgegriffen werden. Eine nachträgliche Änderung der Umgebung kann für ein Unternehmen sehr aufwändig und kostenintensiv werden.

17 5 ERKENNTNISSE DER SOA STRATEGIE 12 Erfahrungen haben gezeigt, dass durch eine intensive Planung zur Einführung der SOA die meisten (bekannten) Probleme vermieden werden können. Ein Unternehmen sollte gerade beim Thema SOA lieber möglichst viel Zeit in die Planung investieren als später über Monate die eingeführte Lösung auf Schwachstellen und Fehler zu analysieren. 5.2 Bekannte Missverständnisse zum Thema SOA Während den letzten Jahren halten sich in der Wirtschaft immer mehr Missverständnisse zum Thema SOA. Die zum Verständnis wichtigsten sollen an dieser Stelle genauer beleuchtet werden: "Wenn du SOA einführst, sind alle deine Komponenten automatisch kompatibel zu einander" [SoaThe] Laut Definition sind in einer SOA alle Komponenten kompatibel zu einander. Dieses bedeutet allerdings nicht, dass durch die Einführung von SOA alte, bestehende Komponenten problemlos kompatibel zu Neuentwicklungen nach SOA sind. Um dieses zu gewährleisten müssen die betroffenen Funktionalitäten und Schnittstellen der Alt-Systeme analysiert und in die SOA, also in Services transformiert werden "Wenn du Web Services verstehst, hast du keine Probleme eine SOA aufzubauen." [SoaThe] Sehr große und intensive Diskussionen gibt es immer wieder um Web Services und den Zusammenhang zur SOA. Wer in der heutigen Zeit mit WS arbeitet hat mit Sicherheit einen großen Vorteil gegenüber den Unternehmen, in denen dieses Know-how fehlt. WS beschreiben allerdings nur einen kleinen, wenn auch wichtigen Teil der SOA. Wichtig ist, dass ein Verständnis dafür besteht, wie die Business Prozesse mit der Applikationslogik zusammen arbeiten und wie dieses bestmöglich in die SOA integriert werden kann. SOA erfordert somit weit mehr als "nur" WS Know-how. Es geht darum ein Verständnis für das Geschäft und die IT aufzubauen. Zusätzlich ist das Know-how über die Verknüpfungsmöglichkeiten dieser Themengebiete zwingend erforderlich.

18 6 SOA UND DER BEZUG ZU E-BUSINESS "SOA löst fachliche Probleme" [SoaThe] Das wohl größte Missverständnis ist, dass SOA fachliche Probleme löst. Durch SOA alleine können keine fachlichen Probleme gelöst werden. SOA soll vielmehr als ein Denkanstoß gesehen werden, um fachlichen Prozesse zu überdenken und in Richtung SOA aufzustellen. In diesem Veränderungsprozess können bestehende Probleme in den Business Prozessen behoben werden. 6 SOA und der Bezug zu E-Business "E-Business ist die integrierte Ausführung aller automatisierbaren Geschäftsprozesse eines Unternehmens mit Hilfe von Informations- und Kommunikationstechnologie." [DeEbWi] Bei der SOA Strategie sprechen wir davon, einzelne Geschäftsprozesse in spezielle Services auszulagern und von einander lose zu koppeln. Wirtschaftlich versucht die SOA Geschäftsprozesse zu optimieren und diese aus technischer Sicht optimal in die Umgebungsarchitektur zu integrieren. Abbildung 8: E-Business/Service Providers Infrastructure Quelle: (Juli 2009) Wenn wir diese Zielsetzung mit der Definition von E-Business vergleichen, so ist die SOA optimal für den Einsatz im E-Business geeignet, da die Anforderungen (siehe Abbildung 8) des E-Business optimal umgesetzt werden können. Über die SOA lässt sich ein E-Business sehr gut konzipieren, betreiben, verwalten und gegebenenfalls gegen neue Anforderungen erweitern.

19 7 UNTERNEHMEN UND DEREN SOA EINSATZ 14 7 Unternehmen und deren SOA Einsatz 7.1 Deutsche Post Brief Die Deutsche Post Brief ist der größte Unternehmensbereich der Deutschen Post World Net und größter Briefdienstleister in Europa. Das folgende praxisnahe SOA Beispiel [SOAPuP] verdeutlicht, wie die Deutsche Post Brief ihre SOA entwickelt hat und zeigt dabei die Ziele, Umsetzung sowie den Nutzen dieser Einführung. 7.2 Gründe Die IS-Architektur der Deutschen Post Brief wurde mit Blick auf die Vergangenheit nicht zentral geplant. Das führte dazu, dass Kerninformationen wie Kundendaten, Kosten oder Informationen über den Wettbewerb nicht von jedem System gleichermaßen verarbeitet werden konnten und daher jedes Teilsystem über einen eigenen Datenbestand verfügte. Ein weiterer entscheidender Faktor war die immer komplexer werdende Anzahl von IT-Projekten. Diese Schlüsselfaktoren führten dazu, dass neue Geschäftsanforderungen zunehmend seltener in dem gewünschten zeitlichen Rahmen umgesetzt werden konnten. Eine mangelnde projektübergreifende Koordination und Planung sorgte des Weiteren für eine große Anzahl von spezialisierten sowie in sich geschlossenen Anwendungssystemen. Die Folge waren redundante Funktionen in Anwendungen sowie eine mehrfache Datenhaltung geschäftsspezifischer Informationen. Heterogene, schlecht dokumentierte Schnittstellen einzelner Anwendungen, deren Abhängigkeiten nicht nachvollzogen werden konnten, führten zu einem enormen Anpassungsaufwand und geringer Wiederverwendung bei neuen Projekten. Zu guter Letzt stiegen die Investitionen in die Wartung/ Bertrieb der historisch gewachsenen IS-Architektur und IT-Infrastruktur, wodurch nicht mehr ausreichend IT-Budget für die Neu-/ Weiterentwicklung der bestehenden Systeme zur vorhanden war. 7.3 Ziele Das aus den oben genannten Gründen abgeleitete Ziel der Deutschen Post Brief war eine zentral gesteuerte und geschäftsorientierte Applikationsarchitektur. Dabei sollte die

20 7 UNTERNEHMEN UND DEREN SOA EINSATZ 15 Applikationsarchitektur als eine Richtlinie zum Entwickeln von redundanzfreien Anwendungen hinsichtlich der Implementierung, Funktionalität und Datenhaltung dienen. Die Erwartung war eine bessere Wiederverwendbarkeit aller Funktionen zur Unterstützung neuer Prozesse und die Möglichkeit gezielt und isoliert neue Funktionen zu implementieren. Das Ergebnis aller Anforderungen war eine fachliche SOA, in denen voneinander isolierte Anwendungsdomänen und Schnittstellen die den Zugriff auf sämtliche Funktionen und Daten in diesen Domänen bereitstellen zum Einsatz kommen. 7.4 Umsetzung Nach der Identifizierung der Kern-Geschäftsprozesse wurde aufbauend auf dieser Analyse eine fachliche Applikationsarchitektur entwickelt. In dieser wurde die fachliche Funktionalität sowie die Daten prozessunabhängig und ohne Redundanzen in die jeweiligen Applikationsdomänen abgebildet. Abbildung 9 illustriert das vorgehen. Dabei finden sämtliche Zugriffe auf die jeweiligen Domänen über spezielle Serviceschnittstellen statt, die jeweils in der Lage sind mehrere Operationen auszuführen. Alle Services wurden objektorientiert nach den Geschäftsobjekten Kunde, Rechnung, oder Vertrag abgebildet und stellen Funktionen wie z.b. anlegen, suchen oder löschen bereit. Abbildung 9: Der Zugriff über Services auf Applikationsdomänen Quelle: [SOAPuP] Die Umstellung der Applikationslandschaft auf die SOA soll anhand des Service Kundenmanagement - siehe dazu auch Abbildung 10 - vorgestellt werden. Der Service stellt

21 7 UNTERNEHMEN UND DEREN SOA EINSATZ 16 u.a. den Call-Center- oder CRM-Systemen Operationen wie seek, get, create, update, delete, getchildnodes und checkadress bereit. Damit haben die Nutzer die Möglichkeit sämtliche Kundendaten zentral zu erfassen und zu verwalten. Die Menge an unterschiedlichen Anwendungen und ihrer lokalen Datenhaltung wurde zu einer zentralen Stammdatenbank migriert. Die bereits bestehenden Anwendungen sowie die neu implementierten verwenden diese Datenbank über die Serviceschnittstellen. Mobile Anwendungen, die nicht über einen dauerhaften Online-Zugang verfügen, speichern und arbeiten weiterhin mit lokalen Daten, welche aber regelmäßig mit der zentralen Datenbank synchronisiert werden. Abbildung 10: Der Service Kundenmanagement Quelle: [SOAPuP] 7.5 Nutzen Nach der erfolgreichen Umsetzung der Service Oriented Architecture identifizierte die Deutsche Post Brief folgenden Nutzen durch die Umstellung Wiederverwendung von Services und Vermeidung redundanter Softwareentwicklung Die Services werden im Schnitt zwei- bis dreimal von unterschiedlichen Systemen wiederverwendet. Auf Grund der Wiederverwendung und systemweiten Harmonisierung

22 8 SOA - TECHNOLOGIE 17 führte zu einer Reduzierung von Redundanzen und somit zu einer optimierten Datenkonsistenz Kürzere Projektlaufzeiten und schneller Time-To-Market Die Entwicklung neuer Anwendungen lässt sich mittels der Wiederverwendung vorhandener Services von vielen Monaten auf einige Tage bzw. Wochen verringern Niedrigere Wartungskosten Die Komplexität und Redundanzen der Applikationsarchitektur verringerten sich durch den Einsatz und die Bildung von Anwendungsdomänen sowie die bessere Kontrolle der Serviceschnittstellen. Das wirkte sich positiv auf die Kostenstruktur zur Wartung und Betrieb der IS-Architektur aus, wodurch ca. 7% mehr IT-Budget für die Entwicklung neuer Anwendungen zur Verfügung stehen Bessere Reaktionsfähigkeit auf neue Geschäftsanforderungen Mit der Entwicklung einer Domänen- und Servicearchitektur schaffte die Deutsche Post Brief einen Vermittler zwischen der Prozess- und der Applikationsarchitektur. Dabei werden alle Daten und Funktionen der Applikationsarchitektur von einer technischen in eine fachliche Sicht übersetzt, wodurch sich die Kommunikation zwischen dem Fachbereich und dem IT-Bereich deutlich verbessert. Des Weiteren erhält der Fachbereich damit mehr Verantwortung, da dieser nun auch für Daten und Services einzelner Anwendungsdomänen zuständig ist. 8 SOA - Technologie

23 9 SOA & SICHERHEIT 18 9 SOA & Sicherheit 9.1 Anforderungen Authentifizierung Soll die Verifikation einer Identität in einem System sicherstellen. Dabei kann es sich um eine Person, ein Gerät oder einen anderen Service handeln. Mittels der Authentifizierung kann kontrolliert werden, wer oder was einen bestimmten Service aufruft. In der Regel sollten Sicherheitsfunktionen wie eine Public Key Infrastructure, in der Zertifikate verwendet werden, zum Einsatz kommen. Damit können weitere Anforderungen wie die Integrität und Vertraulichkeit sichergestellt werden Autorisierung Dient der Prüfung, ob eine bestimmte Identität Zugriff auf eine Ressource erhalten darf. Dabei handelt es sich z.b. um eine Kontrollfunktion, ob ein bestimmter Service aufgerufen werden darf. In der Regel wird in diesem Kontext das Rollenkonzept verwendet. Darin werden Benutzer bestimmten Rollen und Gruppen zugewiesen, die dann mit Rechten ausgestattet sind Vertraulichkeit/ Privatsphäre Der Transport der Daten muss vertraulich behandelt werden. Das bedeutet, dass ein nicht autorisierter Zugriff auf die Daten in jedem Fall verhindert werden muss. Nur autorisierte und authentifizierte Identitäten dürfen auch Zugriff auf die Daten erhalten. Die Vertraulichkeit umfasst das Lesen, Verändern und Löschen von Daten und kann mittels kryptografischer Verfahren gewährleistet werden Integrität Integrität wird in Datenintegrität und Herkunftsintegrität unterteilt. Die Datenintegrität soll sicherstellen, dass die Daten während der gesamten Übertragung nicht manipuliert