Fit for SOA Ein evolutionärer Weg zur Ausrichtung der Anwendungssysteme auf SOA

Transkript

1 Fit for SOA Ein evolutionärer Weg zur Ausrichtung der Anwendungssysteme auf SOA - 1 -

2 Dieser Vortrag ist mit Animationen und gesprochenem Vortragstext (Ton) auch als Flash-Präsentation online verfügbar: Für Fragen stehen wir Ihnen gerne zur Verfügung: +49 (0)711 / (normale Telefongebühren, erreichbar Montag bis Freitag von 8:00-19:00 Uhr) oder kontaktieren Sie uns per an: soa-info@zitecs.de - 2 -

3 Schwerpunkte des Fachvortrags Was bedeutet eigentlich Ausrichtung der Anwendungssysteme auf SOA? Überblick: Anwendungstypen und ihre technologische Basis Was unterscheidet SOA-fähige von nicht SOA-fähigen Anwendungssystemen? Software-Komponenten und ihre Bedeutung für SOA-konforme Anwendungssysteme Altsysteme auf Basis einer Komponenten-/Service- Architektur evolutionär erneuern - 3 -

4 A A B H AA Überblick: Anwendungstypen und ihre technologische Basis Obj ektori en ti erte n wen d u n g en KK om pp on en ten -basi erte, Serv ii ceori en ti erte nn wen dd uu nn gg en M on oli th i sch p roz ed u rale A n wen d u n g en Wrapper & A d apt er Enterprise Service Bus p p n S S O A I S E A I I S lic at io erv er Middleware Layer as e I n f ras t ru c t u re Layer (OS, Network/Protocols, Database ) ardware Layer SOA / EAI -IS SOA / EAI -Infrastuktur

5 A A B H AA Ziel-Scenario: SOA-Middleware und -Anwendungen Obj ektori en ti erte n wen d u n g en KK om pp on en ten -basi erte, Serv ii ceori en ti erte nn wen dd uu nn gg en M on oli th i sch p roz ed u rale A n wen d u n g en Wrapper & A d apt er Enterprise Service Bus Ausblick: Integrierte SOA-IS als p p lic at io n standardisierte Applikations-Plattform S erv er S O A I S für E A I I S serviceorientierte Anwendungssysteme Middleware Layer as e I n f ras t ru c t u re Layer (OS, Network/Protocols, Database ) ardware Layer SOA / EAI -IS SOA / EAI -Infrastuktur

6 Warum sind Services anders? Dies Es trifft geht auf um konventionell die Möglichkeit entwickelte der flexiblen Software, egal Wiederverwendung ob prozedural/monolithisch als Software oder objektorientiert, programmierter Geschäftsfunktionen in unterschiedlichen im Geschäftsprozessen/Kontexten Regelfall nicht zu: Wesentliche Merkmale von Services Ausführbarkeit ohne Erfordernis eines strukturellen Systemzusammenhangs, der i.d.r. durch programmatische/oo-technische Steuerung entsteht (Funktion A kann erst ausgeführt werden, nachdem Funktion B erfolgreich beendet wurde). Services müssen stateless sein, d.h. sie dürfen keine Abhängigkeiten zu Programm-/Objekt-State besitzen, der außerhalb ihrer eigenen Implementation liegt. Service-interner State ist nur einmalig und für jeweils eine Serviceausführung (und nur während dieser Ausführung) gültig. Services müssen transaktional ungebunden sein. Sie können eine abgeschlossenetransaktion für sich selbst bilden oder aber auch nur als Teil an einer übergeordneten Transaktion teilnehmen und diese beeinflussen

7 Services - und sonst, keine weitere Struktur? Doch! Mit SOA rückt auch ein altbekanntes Strukturierungs-Paradigma erneut in den Mittelpunkt: Software-Komponenten? hohe geringe Granularität Auf OO-Basis implementierte Komponenten fassen Granularität in sich abgeschlossene Geschäftsfunktionalität zusammen. für SOA angemessene Granularität Monolithische Systeme werden der Flexibilisierung per se nicht gerecht (z.b. wegen zu geringer Granularität). Komplexe, vernetzte Objektstrukturen tendieren in der Praxis (trotz gegenteiligen Bestrebens) durch Ihre OO-technischen Abhängigkeiten häufig zu einer engen Kopplung

8 SOA: Objekte versus Komponenten 1. Die Geschäftsprozess-Sicht (Aussensicht) Objektklassen sind feingranulare Artefakte eines Systems und können einen vollständigen Geschäftsprozess nur im Zusammenspiel mehrerer (auch gemeinsam konzipierter) Klassen darstellen. SOA jedoch lebt von der Unabhängigkeit und Verteilbarkeit der Geschäftsprozesse auf Basis von Services! - 8 -

9 SOA: Objekte versus Komponenten Abbildung von Geschäftsprozessen im Objektsystem: Prozess A Prozess C Prozess B Zusammengehörig entwickelte, feingranulare Objektklassen bilden in ihrem programmierten Zusammenspiel die Geschäftsprozesse ab

10 SOA: Objekte versus Komponenten Abbildung von Geschäftsprozessen mit Komponenten: E n terp ri se Serv i ce B u s Application Server SO A I S Prozess A Prozess B B u si n ess Process M an ag em en t (B PM ) L ay er Prozess C Unabhängig voneinander entwickelte Komponenten stellen wiederverwendbare Services bereit. Geschäftsprozesse entstehen über Komponenten(und damit auch technische) Grenzen hinweg durch Orchestrierung der Services

11 SOA: Objekte versus Komponenten 2. Die Innenansicht SOA-Komponenten kapseln voneinander getrennte Serviceobjekte und Datenobjekte eines in sich abgeschlossenen betriebswirtschaftlichen Funktionsbereichs. Objekte kapseln Funktionen feingranularer Klassen zusammen mit den zugehörigen Daten. OO-System Order new Order(Customer) additem updateitem deleteitem Collection items Customer cust Serviceobjekte IF Order Provider Trennung! Datenobjekte Service- Komponenten- System Order Order Management Order Manager 1 Datenobjekte * IF Item InterFaces IF Order Processor Serviceobjekte

12 Warum Trennung von Service- und Datenobjekten? Klassische OO: Operationen auf Objekten: myorder.additem( ); myorder.calculate(); Service- Komponenten- System IF InterFaces SOA-fähige Services: Serviceausführung mit Datenobjekten: OrderManager.addItemToOrder( ); OrderProcessor.calculateOrder( ); Die Trennung ist Voraussetzung hierfür! IF Order Provider Order Management Order Manager IF Order Processor Serviceobjekte sind stateless, d.h. sie beinhalten keine Daten, sondern nur die betriebswirtschaftlich funktionalen Service-Implementationen. Datenobjekte sind primär Daten-Container ohne betriebswirtschaftliche Funktionalität. Order 1 Serviceobjekte Datenobjekte * Item

13 Eckpunkte einer evolutionären SOA-Ausrichtung Weiter- und Neuentwicklungen vorhandener (nicht SOA-fähiger) Systeme sollen möglichst in Form neuer SOA-fähiger Services erfolgen Komponenten sind von Natur aus ideale Softwareelemente zur Umsetzung einer schrittweisen Evolution Überschaubare Grösse Wohldefinierte Aufgaben und Schnittstellen Hohe Integrationsfähigkeit sukzessive Überführung der Geschäftslogik aus den Altsystemen in servicebasierte Komponenten

14 Der Startpunkt: Ein Service Map Blueprint Auswahl eines Funktionsbereichs, in dem aufgrund bestehender Anforderungen sowieso nennenswerte Weiter-/Neuentwicklungen anstehen Erstellung eines Service Map Blueprint (SMB), für diesen Funktionsbereich und die angrenzenden Funktionsbereiche, wobei es sich i.w. um reine Schnittstellendefinitionen handelt. In einem SMB werden zusammengehörige Funktionsbereiche als Komponenten mit Ihren Service-Schnittstellen modelliert: Welche Services werden von der/den Komponente(n) den umliegenden Funktionsbereichen angeboten? Komponenten sind Service-Provider. Welche Services werden von der/den Komponente(n) von den umliegenden Funktionsbereichen benötigt? Komponenten sind gleichzeitig auch Service-Consumer

15 Der Service Map Blueprint Welche Services bieten die Komponenten als Provider an? Service Provider IF (Interface) Komponente für angrenzenden Funktionsbereich B Neu zu schaffende Komponente für Funktionsbereich A Welche Services benötigen die Komponenten zur Erfüllung ihrer Aufgaben? Service Consumer (ServiceRequest Declaration) Komponente für angrenzenden Funktionsbereich C Komponente für angrenzenden Funktionsbereich D

16 Die Implementation Bestellkalkulation Altsystem EINKAUF Bedarfsvorhersage Altsystem VERKAUF EK-Daten VK- Daten VK-Historie Konnektoren Prv Komponente für angrenzenden Prc Funktionsbereich Mng B Proc Data Neu zu schaffende Data Komponente Prov für Funktionsbereich A Data Mng Service Provider IF Service Consumer (ServiceRequest Declaration) Serviceaufruf- Richtung Daten-/Result- Flussrichtung Komponente für Prv angrenzenden Prc Funktionsbereich C Mng Komponente Mng Prc für angrenzenden Prv Funktionsbereich D D D D

17 Die nächsten Stufen der Evolution D D Prv Mng Proc Data Bestellkalkulation Altsystem EINKAUF Bedarfsvorhersage Altsystem VERKAUF EK-Daten VK- Daten D Prc Prov Data VK-Historie Data Mng Mng Service Provider IF D Prv Service Consumer (ServiceRequest Declaration) D D Prc Serviceaufruf- Richtung Daten-/Result- Flussrichtung Mng D Prv D D Prc

18 Iterativer Prozess Gesteuert von den Anforderungen an die Anwendungsentwicklung werden im Service Map Blueprint sukzessive weitere Komponenten hinzugefügt. Die Implementation erfolgt in überschaubaren Schritten: Komponente für Komponente. Angrenzende Funktionsbereiche werden jeweils bzgl. ihrer Service-Schnittstellen soweit erforderlich modelliert, inital aber nur als Konnektor-Komponenten implementiert. Konnektor-Komponenten können zu jedem späteren Zeitpunkt ausimplementiert werden, ohne dass sich dadurch Komponenten-/Service-Schnittstellen ändern. Insgesamt wachsen so der Service Map Blueprint und seine Komponenten-Implementationen in evolutionären Schritten und lösen hierbei sukzessive die Altsysteme ab

19 Wechselbeziehungen zwischen der SOA-Infrastruktur und den Anwendungssystemen Muss nicht für die Entwicklung SOA-fähiger Anwendungen zuerst eine entsprechende SOA-Infrastruktur aufgebaut werden?

20 A A B H A W Die SOA-IS ist für die Anwendungssysteme transparent Obj ektori en ti erte n wen d u n g en K om p on en ten -basi erte, Serv i ceori en ti erte n wen d u n g en M on oli th i sch p roz ed u rale A n wen d u n g en ra p p er & A d a p ter SOA-IS: Beschreibung, Registierung, Ausblick: Integrierte Enterprise SOA-IS Service als Bus p p lic at io n Finden von Services (Servicestandardisierte Applikations-Plattform S erv er S O A I S für Repository/-Registry) E A I I S serviceorientierte Anwendungssysteme Service-Orchestrierung (z.b. BPM) und -Routing (z.b. ESB) Middleware Layer as e I n f ras t ru c t u re Layer (OS, Network/Protocols, Database ) ardware Layer

21 A B H A Die Anwendungsentwicklung kann bereits auf Standards bauen! Obj ektori en ti erte n wen d u n g en K om p on en ten -basi erte, Serv i ceori en ti erte n wen d u n g en M on oli th i sch p roz ed u rale A n wen d u n g en Konnektoren J a va Enterprise Ed itio n ( J a va EE ) A ppl ica tio n Server E A I I S Middleware Layer as e I n f ras t ru c t u re Layer (OS, Network/Protocols, Database ) ardware Layer

22 A B H A Komponenten und Services benötigen eine unterstützende Software-Schicht! Obj ektori en ti erte n wen d u n g en K om p on en ten -basi erte, Serv i ceori en ti erte n wen d u n g en M on oli th i sch p roz ed u rale A n wen d u n g en Konnektoren Komponenten-/Service-Framework J a va Enterprise Ed itio n ( J a va EE ) A ppl ica tio n Server E A I I S Middleware Layer as e I n f ras t ru c t u re Layer (OS, Network/Protocols, Database ) ardware Layer

23 Zusammenfassung: Schlüsselfaktoren für SOA-Anwendungen Implementation der Geschäftslogik als SOAkonforme Services mit folgenden Merkmalen: Keine strukturelle Abhängigkeit von einem programmatischen/ootechnischen Systemzusammenhang Stateless-Eigenschaft Transaktionale Flexibilität ( ungebunden ) Komponenten als Voraussetzung für Iteratives, evolutionäres Vorgehen Überschaubare Entwicklungsschritte Hohe Integrationsfähigkeit Lose Kopplung Flexible Systemkonfiguration Komponenten erfüllen wichtige Voraussetzungen für eine SOA, insbesondere auch die Umsetzung wesentlicher Design-Patterns, wie z.b. die Trennung von Service- und Daten-Objekten

24 SOA Wie beginnen? Eine SOA-Infrastuktur (SOA-IS) kann ihre eigentlichen Stärken erst ausspielen, wenn die Anwendungssysteme die Geschäftsfunktionalität als Services bereitstellen (keine SOA ohne Services ). SOA-fähig (als Services) implementierte Anwendungssysteme erfüllen Ihre Funktion hingegen auch schon ohne SOA-IS, sind dann aber bereits Unabhängig von Überlegungen zum Aufbau einer SOA-IS und diesbzgl. noch offenen Entwicklungen aus der weiteren Standardisierung, sollte die Ausrichtung der IT auf SOA bei den Anwendungssystemen beginnen!

25 Vielen Dank für Ihr Interesse. Noch Fragen? Stefan Manzke Werum Software & Systems AG Wulf-Werum-Str. 3, Lüneburg Andreas Zimmer Zitecs GmbH & Co. KG Haldenstr. 34, Fellbach Besuchen Sie uns auch im Internet: /