SOA in der Praxis, Robert Meyer, 8.11.2007 1.consulting.solutions.partnership B Service-orientierte Architektur (SOA) in der Praxis Robert Meyer 8. November

SOA in der Praxis, Robert Meyer, 8.11.2007 1

.consulting .solutions .partnership

B


Service-orientierte Architektur (SOA) in der Praxis

Robert Meyer8. November 2007

msg systems ag, GS Chemnitz, Carolastraße 2, D-09111 Chemnitz [email protected], Tel. (0371) 67403-0

9. Informatik-Tag an der Hochschule Mittweida (FH)



B

1. Einführung und Aufgabenbeschreibung2. Einordnung in das Themengebiet SOA3. Beschreibung des Prototyps4. Einsatz des Model Driven Software Development5. Implementierte Services6. Zusammenfassung7. Ausblick

Agenda



B


Agenda



B

Einführung – AFIS / Produktmanager

Assekuranz-Finanz-Informations-System „AFIS“„Produktmanager“



B

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)



B

Zielstellung



B


Agenda



B

Einordnung in das Themengebiet SOA

SOA: Vorgehensweise und abstraktes Modell der Software-Architektur Abbildung von Geschäftsprozessen durch Orchestrierung von Services daher individuell ausgeprägt

Service-Identifikation

Service-Spezifikation

Service-Realisierung

Service-Komposition

Service-Implementierung

Welche Services werden benötigt?

Benötigte Schnittstellen, Protokolle?Rolle des Service im Gesamtkontext?

Welche Komponente der IT-Landschaft bietet welchen Service?

Abbildung von Geschäftspro-zessen durch Orchestrierung

Implementierung derServices



B


Agenda



B

Bestandteile der Arbeit

AFIS.SALESArchitektur

Domainobjekt-Modell

Schnittstellen

Persistenz

FehlerbehandlungLogging

Performance

Laufzeitumgebung

Abgrenzung Mathematik



B

Domainobjekt-Modell

Abbildung der realen Police im System strukturiert minimale Ausprägung im Rahmen des Diploms

Police

1

Leistung

*

Versichertes Objekt

1

*

Vertrag

1

*

Kapselung aller Verträge

Hausratversicherung, Schadenshaftpflicht, Feuerversicherung...

Gegenstand des Vertrages (Person, Tier, Sache)

Versicherungssumme, Beitrag



B

Schnittstellen der Services

Anforderungen Police-Daten strukturiert

Lösung 2 Schnittstellen

implementiertXML-Form,Objektform

Daten-Transfer-Objekte

DTOs

DOs

XML-ParserJAXB 1.0

DTOs

XML-String

SALES-ServicesDO ... DomainobjekteDTO ... Daten-Transfer-Objekte



B

Persistenz

Parallelbetrieb Grundlage bildet AFIS-Datenbank (DB2) vorhandene Persistenz-Frameworks ungeeignet

(Hibernate, Java Persistence API, …)

DOs

1 : 1DAO

DAODAO

DAOs

AFIS-DB

SALES-Services

Nutzung der Data Access Objects (DAO) DAOs kapseln Zugriffslogik (insert, select, delete, update) pro Domainobjekt (DO) ein DAO

Verbindung über JDBC



B

Abgrenzung fachlicher Mathematik

Versicherungsmathematik: Tarifierung (Beitragsberechnung) undMathematik: 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



B

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



B

Architektur

Value-Objekte Daten-Kapsel Initialisierung 1:1 mit

Domainobjekte



B

Laufzeitumgebung

Application-Server BEA WebLogic andere auf Kundenwunsch einsetzbar

Vorteile: Transaktionsmanagement Ausfallsicherheit ...



B


Agenda



B

Funktionsweise des MDSD

Model Driven Software Development

OAW... Open Architecture Ware



B


Agenda



B

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)



B

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



B


Agenda



B

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



B

1. Einführung und Aufgabenbeschreibung2. Einordnung in das Themengebiet SOA3. Beschreibung des Prototyps4. Einsatz der Model Driven Architecture5. Implementierte Services6. Zusammenfassung7. Ausblick

Agenda



B

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



B

Demo-GUI



B


Vielen Dank für Ihre Aufmerksamkeit!

Documents

SOA in der Praxis, Robert Meyer, 8.11.2007 1.consulting.solutions.partnership B Service-orientierte Architektur (SOA) in der Praxis Robert Meyer 8. November