Transkript

1 Fit for SO Ein evolutionärer Weg zur usrichtung der nwendungssysteme auf SO ieser Vortrag ist mit nimationen 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-1

2 Schwerpunkte des Fachvortrags Was bedeutet eigentlich usrichtung der nwendungssysteme auf SO? Überblick: nwendungstypen und ihre technologische Basis Was unterscheidet SO-fähige von nicht SO-fähigen nwendungssystemen? Software-Komponenten und ihre Bedeutung für SO-konforme nwendungssysteme ltsysteme auf Basis einer Komponenten-/Service- rchitektur evolutionär erneuern Überblick: nwendungstypen und ihre technologische Basis Obj ektori KK om pp on en ten -basi erte, Serv ii ceori nn wen dd uu nn gg en M on oli th i sch p roz ed u rale Wrapper & d apt er Enterprise Service Bus p p lic at io n S erv er S O I S E I I S Middleware Layer B as e I n f ras t ru c t u re Layer (OS, Network/Protocols, atabase ) H ardware Layer SO / EI -IS SO / EI -Infrastuktur 2

3 Ziel-Scenario: SO-Middleware und -nwendungen Obj ektori KK om pp on en ten -basi erte, Serv ii ceori nn wen dd uu nn gg en M on oli th i sch p roz ed u rale Wrapper & d apt er usblick: Integrierte Enterprise SO-IS Service als Bus p p lic at io n standardisierte pplikations-plattform S erv er S O I S für E I I S serviceorientierte nwendungssysteme Middleware Layer B as e I n f ras t ru c t u re Layer (OS, Network/Protocols, atabase ) H ardware Layer SO / EI -IS SO / EI -Infrastuktur Warum sind Services anders? ies 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 usführbarkeit ohne Erfordernis eines strukturellen Systemzusammenhangs, der i.d.r. durch programmatische/oo-technische Steuerung entsteht (Funktion kann erst ausgeführt werden, nachdem Funktion B erfolgreich beendet wurde). Services müssen stateless sein, d.h. sie dürfen keine bhä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 usfü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

4 Services - und sonst, keine weitere Struktur? och! Mit SO rückt auch ein altbekanntes Strukturierungs-Paradigma erneut in den Mittelpunkt: Software-Komponenten? hohe geringe Granularität uf OO-Basis implementierte Komponenten fassen Granularität in sich abgeschlossene Geschäftsfunktionalität zusammen. für SO 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 bhängigkeiten häufig zu einer engen Kopplung SO: Objekte versus Komponenten 1. ie Geschäftsprozess-Sicht (ussensicht) Objektklassen sind feingranulare rtefakte eines Systems und können einen vollständigen Geschäftsprozess nur im Zusammenspiel mehrerer (auch gemeinsam konzipierter) Klassen darstellen. SO jedoch lebt von der Unabhängigkeit und Verteilbarkeit der Geschäftsprozesse auf Basis von Services! - 8-4

5 SO: Objekte versus Komponenten bbildung von Geschäftsprozessen im Objektsystem: Prozess Prozess C Prozess B Zusammengehörig entwickelte, feingranulare Objektklassen bilden in ihrem programmierten Zusammenspiel die Geschäftsprozesse ab SO: Objekte versus Komponenten bbildung von Geschäftsprozessen mit Komponenten: E n terp ri se Serv i ce B u s pplication Server SO I S Prozess 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

6 SO: Objekte versus Komponenten 2. ie Innenansicht SO-Komponenten kapseln voneinander getrennte Serviceobjekte und atenobjekte eines in sich abgeschlossenen betriebswirtschaftlichen Funktionsbereichs. Objekte kapseln Funktionen feingranularer Klassen zusammen mit den zugehörigen aten. OO-System new (Customer) additem updateitem deleteitem Collection items Customer cust Serviceobjekte IF Provider Trennung! atenobjekte Service- Komponenten- System Manager 1 * IF Management atenobjekte Item InterFaces IF Processor Serviceobjekte Warum Trennung von Service- und atenobjekten? Klassische OO: Operationen auf Objekten: my.additem( ); my.calculate(); SO-fähige Services: Serviceausführung mit atenobjekten: Manager.addItemTo( ); Processor.calculate( ); ie Trennung ist Voraussetzung hierfür! Serviceobjekte sind stateless, d.h. sie beinhalten keine aten, sondern nur die betriebswirtschaftlich funktionalen Service-Implementationen. atenobjekte sind primär aten-container ohne betriebswirtschaftliche Funktionalität. Service- Komponenten- System IF Provider Manager 1 * IF Management atenobjekte Item InterFaces IF Processor Serviceobjekte

7 Eckpunkte einer evolutionären SO-usrichtung Weiter- und Neuentwicklungen vorhandener (nicht SO-fähiger) Systeme sollen möglichst in Form neuer SO-fähiger Services erfolgen Komponenten sind von Natur aus ideale Softwareelemente zur Umsetzung einer schrittweisen Evolution Überschaubare Grösse Wohldefinierte ufgaben und Schnittstellen Hohe Integrationsfähigkeit sukzessive Überführung der Geschäftslogik aus den ltsystemen in servicebasierte Komponenten er Startpunkt: Ein Service Map Blueprint uswahl eines Funktionsbereichs, in dem aufgrund bestehender nforderungen 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

8 Bestel l kal kul ati on Bedarfsvorhersage EK-aten VK- aten VK-Histori e er Service Map Blueprint Welche Services bieten die Komponenten als Provider an? Service Provider IF (Interface) Welche Services benötigen die Komponenten zur Erfüllung ihrer ufgaben? Service Consumer (ServiceRequest eclaration) Komponente für angrenzenden Funktionsbereich B Komponente für angrenzenden Funktionsbereich C Komponente für angrenzenden Funktionsbereich Neu zu schaffende Komponente für Funktionsbereich ie Implementation ltsystem EINKUF ltsystem VERKUF Konnektoren Prv Komponente für angrenzenden Prc Funktionsbereich Mng B Proc ata Neu zu schaffende ata Komponente Prov für Funktionsbereich ata Mng Service Provider IF Service Consumer (ServiceRequest eclaration) Serviceaufruf- Richtung aten-/result- Flussrichtung Komponente für Prv angrenzenden Prc Funktionsbereich C Mng Komponente Mng Prc für angrenzenden Prv Funktionsbereich

9 Bestel l kal kul ati on Bedarfsvorhersage EK-aten VK- aten VK-Histori e ie nächsten Stufen der Evolution Mng Prv Proc ata ltsystem EINKUF ltsystem VERKUF Prc Prov ata ata Service Provider IF Service Consumer (ServiceRequest eclaration) Serviceaufruf- Richtung aten-/result- Flussrichtung Mng Prv Prc Mng Prv Prc Mng Iterativer Prozess Gesteuert von den nforderungen an die nwendungsentwicklung werden im Service Map Blueprint sukzessive weitere Komponenten hinzugefügt. ie Implementation erfolgt in überschaubaren Schritten: Komponente für Komponente. ngrenzende 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 ltsysteme ab

10 W Wechselbeziehungen zwischen der SO-Infrastruktur und den nwendungssystemen Muss nicht für die Entwicklung SO-fähiger nwendungen zuerst eine entsprechende SO-Infrastruktur aufgebaut werden? ie SO-IS ist für die nwendungssysteme transparent Obj ektori K om p on en ten -basi erte, Serv i ceori M on oli th i sch p roz ed u rale ra p p er & d a p ter SO-IS: Beschreibung, Registierung, usblick: Integrierte Enterprise SO-IS Service als Bus p p lic at io n Finden von Services (Servicestandardisierte pplikations-plattform S erv er S O I S für Repository/-Registry) E I I S serviceorientierte nwendungssysteme Service-Orchestrierung (z.b. BPM) und -Routing (z.b. ESB) Middleware Layer B as e I n f ras t ru c t u re Layer (OS, Network/Protocols, atabase ) H ardware Layer

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

12 Zusammenfassung: Schlüsselfaktoren für SO-nwendungen Implementation der Geschäftslogik als SOkonforme Services mit folgenden Merkmalen: Keine strukturelle bhä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 Komponenten erfüllen wichtige Lose Kopplung Voraussetzungen für eine SO, insbesondere auch die Flexible Systemkonfiguration Umsetzung wesentlicher esign-patterns, wie z.b. die Trennung von Service- und aten-objekten SO Wie beginnen? Eine SO-Infrastuktur (SO-IS) kann ihre eigentlichen Stärken erst ausspielen, wenn die nwendungssysteme die Geschäftsfunktionalität als Services bereitstellen (keine SO ohne Services ). SO-fähig (als Services) implementierte nwendungssysteme erfüllen Ihre Funktion hingegen auch schon ohne SO-IS, sind dann aber bereits Unabhängig von Überlegungen zum ufbau einer SO-IS und diesbzgl. noch offenen Entwicklungen aus der weiteren Standardisierung, sollte die usrichtung der IT auf SO bei den nwendungssystemen beginnen!

13 Vielen ank für Ihr Interesse. Noch Fragen? Stefan Manzke Werum Software & Systems G Wulf-Werum-Str. 3, Lüneburg manzke@werum.de ndreas Zimmer Zitecs GmbH & Co. KG Haldenstr. 34, Fellbach ndreas.zimmer@zitecs.de Besuchen Sie uns auch im Internet: /