Auf dem Weg zur serviceorientierten Architektur (SOA)

1. Auf dem Weg zur serviceorientierten Architektur (SOA) Thomas Güdelhöfer WLP Systems GmbHHamburgNovember 2006

2. Themenübersicht • Was bisher geschah • Definition • Prozess-Sicht und lose Kopplung • Arten von Services • Prozess-Integrität • Sicherheit, Skalierbarkeit und Verfügbarkeit • SOA-Projektmanagement • Fazit

3. Architektur-Ansätze • 80er: Unternehmensweites Datenmodell • Durch ein einheitliches Datenmodell soll eine Integration aller Aspekte eines Unternehmens gelingen. • 90er: EAI • Durch einen einheitlichen Software-Bus (z.B. CORBA) sollen alle System integriert werden.

4. Definition Eine serviceorientierte Architektur (SOA) ist eine IT-Strategie: • Die unternehmensweite Architektur gründet sich auf eine Zerlegung in Applikations-Frontends, Services, ein Service-Verzeichnis und einen Service-Bus. • Ein Service besteht aus einen Vertrag, einem oder mehreren Schnittstellen und einer Implementation.

5. Prozess-Sicht • Definition von Prozessen, nicht Applikationen • Systemgrenzen nicht ausfransen lassen • Insellösung vs. Eierlegendewollmilchsau • SOA bietet einen Dritten Weg • Lücken in der Prozessabdeckung schließen • Access-DB in jeder Abteilung • Fokus auf Nutzen, nicht auf Kosten

6. Lose Kopplung • Reduktion der künstlichen Abhängigkeiten. • Der Fön braucht Strom  echte Abhängigkeit • Der Fön braucht einen Adapter  künstliche Abhängigkeit • Neue Versionen der Schnittstelle ohne Störung alter Versionen. • Corba erfüllt diese Forderung nicht.

7. Lose Kopplung • Deskriptiver statt instruktiver Aufruf. • Unterschied zwischen Koch und Kellner: • Das Essen wird beim Kellner bestellt (deskriptiver Aufruf) ohne die Details der Zubereitung zu beschreiben. • Systeme müssen nicht gleichzeitig verfügbar sein. • Asynchrone Kommunikation, besonders wichtig über Unternehmensgrenzen hinweg. • Finden der Services zur Laufzeit. • Service-Verzeichnis

8. Design for Change • IT leistet geschäftlichen Nutzen nur dann, wenn aktuelle Bedürfnisse erfüllt werden • Minimierung der Soll-Ist-Lücke • Verkürzung des Zyklus Anforderung – Analyse – Design – Implementierung • Bei loser Kopplung haben Änderungen nur lokale Auswirkungen

9. Service-Wiederverwendbarkeit • Wird ein Service von genau einem Nutzer genutzt, dann ist es noch kein SOA! • Granularität der Services • Auffindbarkeit der Services • Bedarf steigt mit der Firmengröße

10. Service-Verzeichnis • Beschreibung aller Services • Service-Definition (z.B. WSDL) • Service-Vertrag (Beschreibung, Erlangen von Zugriffsrechten) • Verantwortliche für Betrieb und Weiterentwicklung • Die einfachste Ausführung eines Service-Verzeichnisses ist eine Papierliste. • Standard für Service-Verzeichnisse: UDDI • Ein Service-Verzeichnis ist notwendig, sobald viele Projekte Services nutzen sollen. • Credit Suisse Group hatte 2004 ca. 1000 Services im Unternehmen.

11. Arten von Services • Sichtbare Applikation • Sind im eigentlichen Sinne keine Services • Rufen die Services der SOA auf • Grund-Service • Grundbausteine einer SOA • Datenzentrierte Services • Geschäftslogik Services • Zwischen-Service • Technologische Adapter (z.B. Corba WebService) • Funktionsergänzungen (z.B. Verschlüsselung) • Rufen andere Services auf

12. Arten von Services • Prozess-Service • Kapselung der Prozess-Logik • Prozessausführung über verschiedene Endgeräte • Rufen andere Services auf • Öffentlicher Service • Unternehmensübergreifende Integration • Zwingend grobgranular und lose gekoppelt • Services teilen den Funktionsumfang vertikal auf • Sind nicht einer Applikation 1:1 zugeordnet

13. Geschäfts-Logik vs.Prozess-Logik • SOA trennt Geschäfts- und Prozess-Logik • Geschäfts-Logik: • Grundlegender Datenzugriff, Komplexe Berechnungen und Geschäftsregeln. • Benötigt Zugriff auf die Geschäftsdaten. • Einfache Schnittstelle. • Verwaltet eigene (kurze) Transaktionen • Prozess-Logik: • Verwaltet den Prozess-Status • Stützt sich auf die Geschäfts-Logik • Langlaufende Aktivität • Ändert sich häufiger als die Geschäfts-Logik

14. Prozess-Integrität • Datenintegrität: • Richtigkeit • Genauigkeit • Konsistenz • Wichtiges Mittel zur Sicherung der Datenintegrität: Transaktionen • Prozess-Integrität: • Behandlung aller möglichen Fehlersituationen in den Prozess-Schritten. • Prozesse erstrecken sich über lange Zeiträume und mehrere Systeme (manchmal sogar Unternehmen). • Transaktionen sind nicht geeignet zur Sicherung der Prozess-Integrität.

15. Prozess-Integrität • Technische Fehler • Geschäftliche Ausnahmen • Maßnahmen: • Logging und Auditing • Verteilt über mehrere Systeme, Log-Konsolidierung erforderlich • Transaktionsketten und kompensierende Operationen • Nicht jede Operation ist umkehrbar. • Volumen der Prozess-Instanzen bestimmt den notwendigen Aufwand für automatisierte Fehlerkorrekturen.

16. Prozess-Service • Ein Prozess-Service hat eine geringe Wahrscheinlichkeit auf Wiederverwendung. • Prozess-Services sind keine Grundbedingung für eine SOA

17. Sicherheit • Authentifizierung an der Applikation oder am Service. • Single-Sign-On: Hilfreich für zusammengesetzte Applikationen. • Verschlüsselung • Kanalverschlüsselung (SSL) • Nachrichtenverschlüsselung • Verfügbarkeit über Firewall-Grenzen hinweg • WebServices über https

18. Skalierbarkeit und Verfügbarkeit • Werden zwischen den Parteien (Service-Lieferant und Nutzer) in SLAs festgelegt. • Skalierbarkeit ergibt sich aus der verwendeten technische Plattform • WebService: Verteilung der Last über Load-Balancer auf mehrere Server • Kapazitäten müssen geplant und entstehende Kosten zugeordnet werden: • Wer einen Service für ein Projekt nutzen will, muss die Last angeben. • Wer Services anbietet, muss die Last durch die Nutzer messen. • Services müssen eine den Applikationen entsprechende Verfügbarkeit haben.

19. Motivation für SOA • Beweglichkeit (Agility) • Kostenreduktion in den Geschäftsprozessen • Kostenreduktion in der IT

20. SOA-Projektmanagement • Projekte sind keine voneinander separierte Aktivität mehr. • Sie liefern untereinander wichtige Funktionsbausteine. • Service-Design mit Blick auf Wiederverwendung. • Projektübergreifendes Management durch ein SOA-Board:

21. SOA-Projektmanagement • Nutzung eines Service durch viele Projekte: • Qualitätskontrolle für den Service gewinnt an Bedeutung: • Testen gegen den Service-Vertrag. • Automatisierte Testverfahren sind für die meisten Services erforderlich.

22. Das Kleingedruckte • Datenhoheit • Temporär, Abgleich und Replikation, Zugriff • Dubletten • „Was ist eine Dublette?“ • Identifizierung der Stakeholder • Außerhalb des Projektes • Prozessoptimierungen verändern das Machtgefüge

23. Fazit • SOA bedeutet eine andere Organisation des IT-Geschäftes: • Denken in Prozessen statt in Applikationen. • Denken über Projektgrenzen hinaus. • Die Abhängigkeit der Applikationen von der Funktionsfähigkeit der Services erfordert ein automatisiertes Testen. • Auch innerhalb des Unternehmens muss über SLAs gesprochen werden.