Service-orientierte-Architekturen (SOA)

Transkript

1 Vorlesungsreihe Entwicklung webbasierter Anwendungen ervice-orientierte-architekturen (OA) Prof. Dr.-Ing. Thomas Wiedemann HOCHCHULE FÜR TECHNIK UND WIRTCHAFT DREDEN (FH) Fachbereich Informatik/Mathematik Gliederung Probleme heutiger IT trukturen Was ist eine OA Architektur (OA) Komponenten einer OA Notwendige tandards und Technologien einer OA Vorteile einer OA Offene Fragen und Probleme von OA Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 2 1

2 Aktuelle Anforderungen und Probleme der IT Neue Anforderungen im allgemeinen betrieblichen Umfeld mehr Wettbewerb im globalen Maßstab Zunehmende Firmenfusionen & Übernahmen erfordern Zusammenführung sehr heterogener IT-Landschaften Neue Gesetze und Regulierungen (OX/Basel II) verlangen nach neuen Abläufen speziell bei der Abwicklung der finanziellen Geschäftsprozesse daraus auch höhere Anforderungen an IT Governance & Compliance generell höhere Kundenerwartungen an Flexibilität und Leistungsvermögen (Anbindung Web, Web 2.0) neue IT-Technologien als Lösung und Auftrag gleichzeitig Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 3 pezielle technische Anforderungen und Probleme der IT Gewachsene trukturen im betrieblichen Umfeld viele IT-Umgebungen sind über die letzten 20 Jahre gewachsen (im Finanz-ektor teilweise bis zu 40 Jahre (Cobol-Programme etc.) sehr heterogene Landschaften unterschiedliche Hardware und Betriebssysteme verschiedene Entwicklungsumgebungen und prachen unterschiedliche Architekturkonzepte These: Eine komplette Neuentwicklung, auch nur von Teilen komplexer IT-Landschaften ist extrem teuer und kritisch. Das Budget großer Konzerne nur für die WARTUNG der oftware-ysteme und chnittstellen liegt teilweise über 1 Mrd. Euro! Es werden deshalb gefordert : Eine sanfte Zusammenführung und/oder Migration bei Beibehaltung der Lauffähigkeit des operativen Betriebs Die Anbindung neuer Technologien (Web / OAP / W), ohne das die Altsysteme störend oder bremsend auftreten! Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 4 2

3 Bisherige Integrationsansätze 1. Punkt zu Punkt-Verbindungen Jede Anwendung interagiert direkt mit einer anderen Anwendung über einen Verbindungspunkt bzw. eine spezielle chnittstelle. Die chnittstelle ist meist spezifisch für die beiden ysteme. ystem 1 ystem 2 ystem 3 ystem 4 Vorteile zu Beginn schnelle und einfache Kopplung chnittstellen passgenau und abgestimmt Nachteile Anzahl der chnittstellen wächst mit N * (N-1), also fast quadratisch Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 5 Probleme mit Punkt zu Punkt-Verbindungen Application 1 Application 2 Application 3 Application 4 Application 5 Application 6 Applikation 7 Application 8 In General : 10 applications require 90 connections Quadratisches Wachstum der chnittstellen (paghettisystem) 10 ysteme = 90 chnittstellen 50 ysteme = 2450 chnittstellen 100 ysteme = 9900 chnittstellen (= nicht beherrschbar) Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 6 3

4 Bisherige Integrationsansätze II 2. Hub & poke Kopplungen Alle Anwendungen sind verbunden über zentralen erver (Hub). Es ist ein zentrales Austauschformat definiert, in welche alle speziellen Formate transformiert werden müssen. Die Verteilung (das Routing) der Daten wird durch spezielle Regeln und/oder Algorithmen auf dem zentralen erver definiert. ystem 1 ystem 2 Zentraler erver (Hub) ystem 3 ystem 4 Vorteile geringe Anzahl (linear zur Anzahl ysteme) relativ lose Kopplung Nachteile tarke Abhängigkeit vom Hub (Kapazität, Ausfall?, Performance, Formate) Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 7 Bisherige Integrationsansätze - Message-Bus 3. Message-Bus-Architektur (auch Publish/ubscribe -Architektur) Alle ysteme sind in Reihe mit einem Kommunikationsbus verbunden und tauschen mit diesem direkt Daten aus. Jede Anwendung muss einen entsprechenden Adapter bereitstellen. ystem 1 ystem 2 Adapter Adapter Message-Bus Adapter Adapter ystem 3 ystem 4 Vorteile relativ störsicher gut skalierbar, auch durch Aufteilung / Bus- egmentierung Nachteile Für jeden konkreten Bus müssen die jeweiligen Adapter programmiert werden und sind meist nur für diesen passfähig Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 8 4

5 Typische Probleme bei der Änderung bestehender ysteme Die 3 Todsünden : eine Anwendung macht einen spezifischen Funktionsaufruf zu einer anderen Anwendung über ganz konkrete Parameter (bei einem Wechsel zu einer anderen, ähnlichen App. wird diese Funktion anders definiert sein ) Datentransformationen zu und von anderen Apps oder zum Bus sind innerhalb der aufrufenden Anwendungen kodiert Prozesslogik ist innerhalb der Anwendungen kodiert, d.h. das Routing ist mit der eigenen Logik meist untrennbar verbunden Anwendungen kennen die Details von anderen Anwendungen sie machen Annahmen sie sind fest gekoppelt ihre Granularität ist zu hoch Anwendungen wissen, wann sie andere Anwendungen aufrufen (fest kodiertes Prozessverhalten) Es gibt auch bei den Bussen und Hubs keine globalen tandards, sondern nur meist Lieferantenspezifische Quasistandards (nach IBM, Oracle, Microsoft etc.) Fazit: Das Hauptproblem ist die (zu) FETE Kopplung der ysteme! Ausweg : Lockere und flexiblere Kopplung der ysteme! Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 9 Alternativer Lösungsansatz mit OA Behebung der Probleme durch folgende Maßnahmen Lösung lose gekoppelte Dienste! anstelle stark gekoppelter Objekte, Komponenten und Anwendungen OA-Komponente Kopplung mit Enterprise-ervice- Bus (EB) grobe Granularität Prozess-Orientierung Ablauflogik aus der Businesslogik herausnehmen feiner Granularität Funktions-Orientierung sie in der Businesslogik zu implementieren grobgranulare ervices OA-Prozesse ervice- Orchestrierung im EB) standardisierte Dokumentstrukturen Produkt und Busspezifischer Dokumente Kanonische Dokumente Konfiguration Programmierung Mapping und Orchestrierung durch EB-Tools Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 10 5

6 ervice Contract Übergang zu einer OA Typisches Beispiel: Einkaufsprozess mit zusätzlicher Genehmigung durch Chef bei einem Einkaufswert > x ( x: Firma : , Uni : 100!) Bisher : Prozesslogik ist innerhalb der ervices kodiert Bestellantrag (x>1000) Genehmigung Lösung: ervices werden von außerhalb orchestriert! Bestellantrag D1 BA OA EB (x<=1000) (y=ok) Genehmigung D1 GN D1(x>1000) D2 D1(x<=1000) Bestellung Bestellung D1 B D2(y=ok) Physische Adressen Transformatoren Quelle der Grafiken : OCON Inc. Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 11 Definition OA - ervices OA - ervices sind grob granular (coarse grainded) lose gekoppelt über Messagebus (Message Oriented Infrastructure) verbunden durch Vereinbarung von chemas und Verträge (und nicht über konkrete Funktionen und Datentypen) The ABC of ervices Address Binding - Contract ervice Endpoint Address Binding ervice Implementation ervice Description Beschreibung Policy (ecurity Protocol, Qo) Quelle der Grafiken : OCON Inc. Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 12 6

7 OA - Kanonische Dokumente und Adapter Der Datenaustausch wird IM EB über universelle Zwischenformate realisiert sog. Kanonische Dokumente + Adapter im EB Zentrales Glossar ystem ID ystem Name IT Architektur Man. IT FIN Account Nr. Amount Description Y ID ervice VFBK RT Fin.yst.Nr. Reliabiliy Y Name FC Nr. Appl.ID Budget Maintenance Time Beschr. ystem ID Reliability Maintenance Time Account Nr. Glossar Variable ITAR MFIN FB LM ystem Name Account Nr. ystem ID Account ystem ID Y ID Appl. ID Y Nr. Anw. Nr. Description Y Canonical ystem Name Name Account Nr. FC Nr. Fin.yst.Nr. Anw. Name XML Document Amount Budget Betrag Description Beschr. Zweck Description Account ystem ID ystem ID ystem Name Maintenance Time ervice Reliabiliy VFBK Verfügbarkeit Reliability Maintenance Time RT Wartungszeit Zweck Betrag Anw. Nr. Wartungszeit Y Nr. Anw. Name Verfügbarkeit FB LM Quelle der Grafiken : OCON Inc. Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 13 OA - Kanonische Dokumente und Adapter Über entsprechende Translatoren (teilweise als Mappingtools vom EB bereitgestellt) werden die spez. Dokumente in kanonische Dokumente gewandelt. Die teuerung erfolgt im EB und wird durch eine spezielle Beschreibungssprache (BPEL) innerhalb einer ervice-flow-engine (=Regelinterpreter) konfiguriert! Publisher Kanonische Dokumente K1 und K2 Bestellantrag D1 Translator BA Prozess Modell X(K1)>1000 Enterprise K1 ervice K2 Bus ervice Flow Engine GN X(K1)<=1000) ID(GN) OD(GN) ID(B)) x(k1)>1000) (x(k1)<=1000) v (y(k2)=ok) Y(K2)=ok) ID(X): Input Dokument Genehmigung OD(X): Output Dokument Publisher & ubscriber Bestellung ubscriber B tandard Prozess-Beschreibung mit BPEL BPEL4W - Business Process Execution Language (BPEL) Quelle der Grafiken : OCON Inc. Process BPEL Description Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 14 7

8 Prozessmodellierung mit BPEL Umsetzung des Beispiels mit BPEL Bestellantrag (x>1000) (x<=1000) Genehmigung (y=ok) Bestellung BPEL mit tandard-upport von großen Herstellern beschreibt im XML Format: - den Ablauf der Anwendungen - Typen von verteilten Daten - wie Partner eingebunden werden - Handhabung von Fehlern - Beziehungen - Handhabung von Ereignissen Quelle der Grafiken : OCON Inc. partnerlinks definieren involvierte Partner sequence, switch - Prozessfluss invoke ervice Aufruf Weitere prachelemente: reply while pick wait empty throw terminate compensate Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 15 OA - Tools, Methoden und Akteure Tool Task Team Member Business Rule Editor Define Vocabulary Define Business Rules Business Analyst Business Process Designer Define Business Process Business Analyst Define chemas Business ervice Bus Editor Define Canonical Doc. OA Architect W Dev. Tool V 2008/Eclipse ecurity/end Point Configuration Tool Test/Deployment Tool Create Mappings Build/Include Web erv. Config. ecurity/eps Test/Deploy Process oftware Engineer Enterprise Architect Test/Deployment Engineer Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 16 8

9 OA Zusammenfassung und Bewertung Vorteile von OA Bessere, schnellere und flexiblere Integration, Prozess Orientiert Häufigere Wiederverwendung von composite ervices Einbindung von Legacy ystemen durch Wrapping (Hülle um td.-oftware) tandardisierte, Prozess Orientierte Daten Representation tandardisierte Business Prozess Representation (ggf. austauschbar oder abstimmbar über Firmengrenzen -> upply Chain Management) Transformation der IT vom Kostenfaktor zum strategischen Asset Zusammenrücken der Fach- und IT Bereiche -> chaffung agiler Unternehmen Nachteile und offene Fragen teilweise erheblicher Aufwand der Umstellung (allerdings ROI < 1..2 Jahre) OA ist kein tandard/konkrete Technologie, sondern ein Konzept! Die konkreten Eigenschaften sind (noch) stark von Lieferanten des EB abhängig (noch) Performanceprobleme durch XML-Datenaustausch Firmen-spez. EB doch wieder nicht kompatibel BPEL (noch) keine gute Unterstützung von Adhoc-Prozessen und Human- Interactions (aber in Entwicklung) Fazit : OA (oder Nachfolger) dürften die entscheidende Technologien der nächsten Jahre im Bereich komplexer IT-Architekturen sein! {Beobachten und Testen!} Entwicklung webbasierter Anwendungen - Prof. T.Wiedemann - HTW Dresden - Folie 17 9