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 2007 msg systems ag, GS Chemnitz, Carolastraße 2, D-09111 Chemnitz msgchemnitz@msg-systems.com, Tel. (0371) 67403-0 -         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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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