1 / 23

Auf dem Weg zur serviceorientierten Architektur (SOA)

Auf dem Weg zur serviceorientierten Architektur (SOA). Thomas Güdelhöfer WLP Systems GmbH Hamburg November 2006. Themenübersicht. Was bisher geschah Definition Prozess-Sicht und lose Kopplung Arten von Services Prozess-Integrität Sicherheit, Skalierbarkeit und Verfügbarkeit

tocho
Télécharger la présentation

Auf dem Weg zur serviceorientierten Architektur (SOA)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related