Service-orientierte Architektur (SOA) in der Praxis

Präsentation zum Thema: "Service-orientierte Architektur (SOA) in der Praxis"—  Präsentation transkript:

1 Service-orientierte Architektur (SOA) in der Praxis
.consulting .solutions .partnership 9. Informatik-Tag an der Hochschule Mittweida (FH) Service-orientierte Architektur (SOA) in der Praxis Robert Meyer 8. November msg systems ag, GS Chemnitz, Carolastraße 2, D Chemnitz Tel. (0371) -         vielen Dank Herr Prof. -         begrüße im Namen -         vielleicht noch kennen: Wirtschaftsinformatik -         Grund. – Zusammenarbeit – Rahmen Diplomarbeit – Erneuerung eines Altsystems – durch SOA -         Herrn Schindler – Top-Down-Ansatz -         Bottom-Up-Ansatz – existierenden System  SOA-Lösung

2 Agenda Einführung und Aufgabenbeschreibung
Einordnung in das Themengebiet SOA Beschreibung des Prototyps Einsatz des Model Driven Software Development Implementierte Services Zusammenfassung Ausblick -         zunächst Agenda -         Aufgabenstellung erläutern -         kurz in Themengebiet einführen -         aufzeigen mit SOA zu tun -         3-5 technische Umsetzung – Zusammenfassung – Ausblick

3 Agenda Einführung und Aufgabenbeschreibung
Einordnung in das Themengebiet SOA Beschreibung des Prototyps Einsatz des Model Driven Software Development Implementierte Services Zusammenfassung Ausblick -         Einstieg in Aufgabenfeld

4 Einführung – AFIS / Produktmanager
Assekuranz-Finanz-Informations-System „AFIS“ -         Assekuranz-Finanz-Informations-System „AFIS“ + „Produktmanager“ - Komplettlösung für VU -         Bewältigung Kernprozesse Versicherungsbranche – wesentlichen Verwaltungsaufgaben -         modularen Aufbau – fachliche Anforderung – entsprechende Komponente -         Modul „Partnerverwaltung“ – Verwaltung von Geschäftskontakten -         Modul „Leistung“ – Berechnung von Versicherungsleistungen -         Versicherungspolicen – Otto-Normal-Verbraucher – Fachjargon – Produkte -         Erstellung solcher Produkte – msg – Produktmanager -         2 Komponenten – Designer – Definition von Policen/math. Regeln für diese Produkte -         Runtime – Initialisierung/Ausführung -         Jahre – sukzessive erweitert/angepasst – unflexibler/starrer – Weiterentwicklungen -         Hauptbaustein – AFIS.PS – Verwaltung von Policen – Ausgangspunkt

5 Aufgabenstellung Aufgabe:
Flexibilisierung von AFIS.PS bezüglich neuer Anforderungen Prototyp-Implementierung als Nachweis Vorgaben: Nutzung aktueller Technologien Parallelbetrieb zu altem AFIS.PS (kein „Big Bang“) Minimierung von Entwicklungsaufwand Lösung: fachliche Logik als Dienste in einer service-orientierten Architektur Services als weitere Schnittstelle Einsatz des Model Driven Software Development (MDSD) SALES – Services Applied to Legacy Systems (deutsch: Dienste, angewendet auf Alt-Systeme) -         Flexibilität – neue Anforderungen – erhöhen -         Nachweis – Prototyp -         weitere Vorgaben o       aktuelle Technologien o       Minimierung Entwicklungsaufwand o       parallel zum AFIS.Policy-System – Big Bang – Risiko/Kosten -         Analyse Vorgaben – Entscheidung service-orientierte Architektur -         da sich SOA Vorgehensweise – Ablösung Altsysteme in Praxis etabliert -         Prinzip des MDSD + Code-Generatoren Aufwand Entwicklung minimal -         Akronym SALES – deutsch – folgend so bezeichnet.

6 Zielstellung - Schaffung – zusätzlichen Schicht
-         AFIS.PS-Funktionalitäten als Services

7 Agenda Einführung und Aufgabenbeschreibung
Einordnung in das Themengebiet SOA Beschreibung des Prototyps Einsatz des Model Driven Software Development Implementierte Services Zusammenfassung Ausblick -         Einordnung – Projekts – Themenfeld SOA

8 Einordnung in das Themengebiet SOA
Service-Identifikation Welche Services werden benötigt? Service-Spezifikation Benötigte Schnittstellen, Protokolle? Rolle des Service im Gesamtkontext? Service-Realisierung Welche Komponente der IT-Landschaft bietet welchen Service? Abbildung von Geschäftspro- zessen durch Orchestrierung Service-Komposition Implementierung der Services Service-Implementierung -         Ordnet – Arbeit – Prozess Aufbau SOA – Unternehmen -         kleiner Teil von dessen umgesetzt – hinter SOA - Implementierung -         da Bottom-Up-Ansatz – wegen Berücksichtigung des Altsystems – richtige Weg -         Diplomarbeit beschreibt – Näherung von technischer Seite -         Ergebnis – Grundlage Aufbau SOA -         diese erreicht man – Umsetzung aller Module in Services – Orchestrierung SOA: Vorgehensweise und abstraktes Modell der Software-Architektur Abbildung von Geschäftsprozessen durch Orchestrierung von Services daher individuell ausgeprägt

9 Agenda Einführung und Aufgabenbeschreibung
Einordnung in das Themengebiet SOA Beschreibung des Prototyps Einsatz des Model Driven Software Development Implementierte Services Zusammenfassung Ausblick -         Widmen – technische Umsetzung – Prototyps

10 Bestandteile der Arbeit
Domainobjekt-Modell Laufzeitumgebung Schnittstellen AFIS.SALES Architektur Persistenz Abgrenzung Mathematik Fehlerbehandlung Logging Performance -         Konzeption – verschiedene Gesichtspunkte -         neben Erstellung Domainobjekt-Modells – vor allem Themen o       Schnittstellen o       Persistenz o       Abgrenzung Versicherungsmathematik o       Fehlerbehandlung -         essentielle Rolle -         ebenso Konzeption Architektur Services – Laufzeitumgebung – Vorfeld -         Themen Logging/Performance prof. SE – Vortrages nicht beleuchtet

11 Domainobjekt-Modell Abbildung der realen Police im System strukturiert
minimale Ausprägung im Rahmen des Diploms Police 1 Kapselung aller Verträge Vertrag 1 * Hausratversicherung, Schadenshaftpflicht, Feuerversicherung... Versichertes Objekt 1 * Gegenstand des Vertrages (Person, Tier, Sache) -         Erster Schritt Konzeption Services – Erstellung DO-Modell -         Abbildung verarbeitende Police System -         Realität Urkunde Versicherungsnehmer – abgeschlossenen Versicherungen – Kapsel Verträge -         Haftpflichtversicherung – Hausratversicherung – Feuerversicherung -         setzen – Wesentlichen – verschiedenen Objekten – versichert -         Leistungen zugeordnet -         beinhalten Versicherungssumme – Schadensfall – Beitrag – periodisch -         Hilfe DO – fachliche Logik der Services realisiert -         Methoden – Einleitung Policen-Prüfung/Beitragsberechnung – Speicherung Leistung * Versicherungssumme, Beitrag

12 Schnittstellen der Services
Anforderungen Police-Daten strukturiert DTOs XML-String Daten-Transfer-Objekte XML-Parser JAXB 1.0 Lösung 2 Schnittstellen implementiert XML-Form, Objektform DTOs -         service-orientierten Architekturen – Schnittstellen – entscheidende Rolle -         da präsentiert/definiert -         Design – Frage – welche -         Wesentlichen – strukturierte Police -         Übertragung Strukturen – 2 Wege – XML-Form – Objektform -         beide realisiert – verschieden nutzbar -         XML denkbar – Web-Service -         andere Applikationen – Übertragung von Objekten – kein aufwendiges Parsen DOs DO ... Domainobjekte DTO ... Daten-Transfer-Objekte SALES-Services

13 Persistenz Parallelbetrieb  Grundlage bildet AFIS-Datenbank (DB2)
vorhandene Persistenz-Frameworks ungeeignet (Hibernate, Java Persistence API, …) DAO DAOs AFIS-DB DOs 1 : 1 SALES-Services Nutzung der Data Access Objects (DAO) DAOs kapseln Zugriffslogik (insert, select, delete, update) pro Domainobjekt (DO) ein DAO Verbindung über JDBC -         Parallelbetrieb – AFIS-Datenbank – Grundlage gemeinsame Verwendung Daten -         Untersuchung Frameworks – Hibernate/JPA – kein Einsatz -         da zu speichernde Objekte des Systems – eigene Tabellenstruktur -         Ansatz funktioniert – „grünen Wiese“ beginnt -         da DB-Modell existiert – gänzlich ungeeignet -         daher DAO -         Kapselung Zugriff – sprich SELECT...-Statements -         innerhalb DAO-Methoden – individuell – Tabellen

14 Abgrenzung fachlicher Mathematik
Versicherungsmathematik: Tarifierung (Beitragsberechnung) und Mathematik: Validierung (Datenüberprüfung) Zielstellung: stärkere Nutzung des Produktmanagers komplette Auslagerung beider Komponenten nach msg.PM Vorteil: Kunde kann selbst Regeln festlegen Anforderungen an SALES: Schaffung einer Schnittstelle  Produkt-Manager-Objekte (PMO) Verbindung, Initialisierung, Ausführung, Mapping Unabhängigkeit: bei Bedarf andere Produktmanagement-Systeme einsetzbar Anpassung der PMOs -         Versicherungsmathematik – Prüfung/Validierung – Berechnung periodisch vom VN zu zahlenden Beitrags/Tarifierung -         Ziel – stärkere Nutzung msg.PM – Auslagerung -         Vorteil – Kunde – Änderungen in Mathe – kein Eingreifen Entwickler -         Selbstverwaltung durch Kunde -         dazu – Schnittstelle – Produkt-Manager-Objekte -         Kommunikation – Initialisierung – Ausführung – Mapping -         theoretisch anderer Produktmanagement-Systeme – Anpassung PMOs

15 Fehlerbehandlung technische Fehler und Benutzerfehler
eingeteilt in 3 Kategorien: Kategorie Beispiel falsche Parameter (Benutzerfehler) falscher Datentyp eines Attributs fehlender Wert bei Pflichtattribut falscher Bereich (Geburtsdatum in Zukunft) Fehler bei der logischen Verarbeitung (Benutzerfehler) Auswahl eines „Eigenheims“ als versichertes Objekt im Rahmen einer Kasko-Versicherung technische Fehler fehlende Datenbankverbindung fehlende Verbindung zum Runtime-Server -         allen SE – Behandlung Ausnahmesituationen -         Unterscheidung technische Fehler/falsche Benutzereingaben -         dazu 3 Fehlerkategorien – sämtliche Ausnahmen -         fehlerhafte Parameter – Übergabe falschen/fehlende Init -         logische Fehler – syntaktisch richtige Police – semantisch falsch -         Objekt „Eigenheim“ – Gegenstand einer Kasko-Versicherung -         technische Fehler – Fehlen DB-Verbindung

16 Architektur Value-Objekte Daten-Kapsel
-         Beachtung techn. Details – 4schichtige Architektur -         Input/Output – implementierte Schnittstellen – Initialisierung DO -         Kapselung konkrete Daten – VO – kein Kopieren – Aufbau -         Integrationsschicht – Sicherstellung – Anbindung PM – Gewährleistung Validierung/Tarifierung -         Persistenzschicht – DB-Zugriff – DAO Value-Objekte Daten-Kapsel Initialisierung 1:1 mit Domainobjekte

17 Laufzeitumgebung Vorteile: Transaktionsmanagement Ausfallsicherheit
... -         Laufzeitumgebung – Application Servers -         Regelung Aufgaben – Transaktionsmanagement/Ausfallsicherheit -         Entwickelung BEA WebLogic-Server – Wahl Kunde -         denkbar – WebSphere oder JBoss -         erläuterte Service-Schnittstellen – RMI/Web-Services nutzbar -         RMI – vorrangig Initialisierung mit Daten-Transfer-Objekten -         Web-Services – Initialisierung mit XML Application-Server BEA WebLogic andere auf Kundenwunsch einsetzbar

18 Agenda Einführung und Aufgabenbeschreibung
Einordnung in das Themengebiet SOA Beschreibung des Prototyps Einsatz des Model Driven Software Development Implementierte Services Zusammenfassung Ausblick -         nach technisch Beschreibung – Ausflug Entwicklungsvorgehen

19 Funktionsweise des MDSD
Model Driven Software Development -         Minimierung Entwicklungszeit – Ansatz MDSD -         letztes Jahr – Informatiktage – Vortrag Rätz – Thema vielseitig beleuchtet -         modelgetriebenen Entwicklung – Funktionalitäten/Datenmodelle – abstrahiert – UML -         daraus – Code-Generatoren – generisch erzeugen -         Innovator – Modelle/Attribute hinterlegt – XMI-Export -         OAW-Framework (Open Architecture Ware) – Parsen – Objekte Stereotypen -         nun Erstellung Templates – anhand derer für jedes Objekt Stereotyps – Klasse -         Stereotyp „Domainobjekt“ – 10 Klassen – 10 Templates für „Domainobjekt“ -         insgesamt 20 Domainobjekte – über 10 Templates – 200 Klassen OAW ... Open Architecture Ware

20 Agenda Einführung und Aufgabenbeschreibung
Einordnung in das Themengebiet SOA Beschreibung des Prototyps Einsatz des Model Driven Software Development Implementierte Services Zusammenfassung Ausblick -         Vorstellung – Prototyp-Services

21 Service „AnlegenPolice“
Nachweis der Funktionsweise des Framework neben Ändern-Service größte Breite zu konzipierender Funktionalitäten Fachliches Ziel: Erfassung, Prüfung, Beitragsberechnung und Speicherung von Policendaten Nutzen: erfolgreiche Tests bescheinigen korrekte Funktionsweise aller Framework-Bestandteile (Hauptaugenmerk auf Kommunikation mit msg.PM) Parallelbetrieb mit AFIS.PS nachgewiesen (durch SALES erstellte Policen in AFIS.PS weiterverarbeitet) -         Nachweis Funktionsweise -         Wahl Anlegen – neben Ändern – größte Breite zu konzipierender Fkt. -         grundlegenden Verfahren – Initialisierung/Fehlerbehandlung – spezifische Mechanismen Validierung/Tarifierung/Schlüsselvergabe -         fachlich Erfassung, Prüfung, Beitragsberechnung, Speicherung – Police -         Erfolgreiche Tests – korrekte Funktionsweise – Bestandteile – Kommunikation PM -         Parallelbetrieb nachgewiesen – Policen fehlerfrei weiterverarbeiten

22 Service „TarifierenKFZVertrag“
Nachweis der Flexibilität im Umgang mit anderen Policen-Strukturen (Verarbeitung von Kfz-Policen) Fachliches Ziel: Erfassung, Prüfung und Beitragsberechnung von Policendaten Nutzen: Implementierung des Services in identischer Struktur wie „AnlegenPolice“ Framework lässt sich problemlos auf andere Strukturen übertragen Berechtigung des Codegenerators nachgewiesen -         Nachweis - flexibler Umgangs – andere Policen-Strukturen -         beispielsweise potentiellen Neu-Kunden -         Verarbeitung Policen KfZ-Versicherungen -         komplett andere Struktur – Schadens-/Haftpflicht-Policen –AFIS.PS-Systems -         benötigter Klassen – besitzen selbe Struktur -         abgesehen von der fehlenden Persistierung – arbeiten identisch – verschiedene Police-Strukturen -         Nutzen MDSD durch Service nachgewiesen – da nach Hinterlegung Modell – Generierung benötigter Klassen

23 Agenda Einführung und Aufgabenbeschreibung
Einordnung in das Themengebiet SOA Beschreibung des Prototyps Einsatz des Model Driven Software Development Implementierte Services Zusammenfassung Ausblick -         Zusammenfassung der Ergebnisse

24 Zusammenfassung Weg der Flexibilisierung von AFIS wurde durch Prototyp aufgezeigt Services leicht austauschbar bei neuen Anforderungen Kunde mit erhöhten Eingriffsmöglichkeiten durch msg.PM-Nutzung Grundlage zum Aufbau der SOA durch Services geschaffen Funktionsweise des MDSD wurde nachgewiesen Minimierung von Entwicklungszeit möglich Minimierung des Aufwandes bei Änderungswünsche in Zahlen: 189 Klassen für 9 Domainobjekte generierbar erspart manuelle Entwicklung von 21 Klassen pro Domainobjekt -         Prototyp-Impl. – ein Weg – Flexibilisierung AFIS aufgezeigt -         da Services – neue Anf. - leicht austauschbar -         und – Auslagerung Mathe – Kunde größerer Spielraum – eigene Veränderungen -         Grundlage Aufbau SOA -         Nachweis Funktionsweise MDSD – Minimierung Entwicklungsaufwand – Aufwand neue Anf. -         minimal abgebildetete Police – 198 Klassen generiert -         zusätzliche Policekomponente – 21 zusätzliche Klassen – Dank modellgetriebener Ansatz – per Mausklick

25 Agenda Einführung und Aufgabenbeschreibung
Einordnung in das Themengebiet SOA Beschreibung des Prototyps Einsatz der Model Driven Architecture Implementierte Services Zusammenfassung Ausblick -         Abschluss – kleiner Ausblick

26 Ausblick Vervollständigung des „AnlegenPolice“-Services
Police in kompletter Ausprägung Implementierung des Code-Generators Erstellung der fehlenden Services (Lesen, Ändern, ...) Anbindung weiterer Module aus AFIS -         nachdem – Anschluss DA Einstellung – Thema weiter bearbeiten -         Vervollständigung „AnlegenPolice“ – komplette Ausprägung – Code-Gen. -         Unterstützung fehlende Services -         Ausdehnung auf weitere AFIS-Module

27 Demo-GUI - Abschluss – Demo-Web-Oberfläche
-         Präsentation gegenüber österreichischen Kunden -         Schreibweise des Wortes Police – Österreich tatsächlich 2x z -         zunehmende Internationalisierung – Verwendung von Anglismen bedeuten

28 Vielen Dank für Ihre Aufmerksamkeit!
-         danke Aufmerksamkeit – Fragen .consulting .solutions .partnership