Auf dem Weg zur serviceorientierten Architektur (SOA)

Präsentation zum Thema: "Auf dem Weg zur serviceorientierten Architektur (SOA)"—  Präsentation transkript:

1 Auf dem Weg zur serviceorientierten Architektur (SOA)
Thomas Güdelhöfer WLP Systems GmbH Hamburg November 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 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.