Serviceorientierte Architektur (SOA) Flashcards
Bedeutung “Service” im SOA-Kontext
Service im SOA-Kontext: Dienst, der von einer Software-Komponente zur Verfügung gestellt wird. SOA ist vor allem ein IT-Architektur-Thema, für die erfolgreiche Einführung müssen jedoch auch organisatorische und strategische Aspekte berücksichtigt werden.
Definition SOA
Service-Oriented Architecrute is an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
Verständnisse von SOA
Variante A:
-Konkrete Technologie (zB. WebServices)
-Software Engineering Konzepte, die Technologien zugrunde liegen
Variante B: Paradigma (im weiteren Verlaufe als SOA-Begriff verwendet)
-um zunächst Geschäft eines Unternehmens zu strukturieren
-von geschäftlicher Unternehmensarchitektur die Architektur der IT-Anwendungssystemlandschaft (AL) abzuleiten
Geschäftsservice
- Funktionalität mit unmittelbarer geschäftlicher Bedeutung
- eindeutig definierte Nutzungsweise
- eindeutig definierte Reaktion und Wirkung
- im Kontext vertraglicher Pflichten/Nutzen
- idR an Organisationsgrenzen angeboten
Anwendungsservices
-unterstützen Geschäftsservices wo sinnvoll nach Vertrag über ein-/ausgehende Informationen und Verhalten
-entkoppeln Geschäftsservices logisch von Anwendungen
-angeboten von Komponenten der AL
orientiert an Idealvorstellung der Geschäftsservices
Servicearten
Elementar/Basis: Elementare Operationen stellen einfache Basisfunktionalitäten bereit
Zusammengesetzt: Zusammengesetzte Operationen werden durch Aufrufe elementarer oder anderer zusammengesetzter Operationen implementiert
Orchestrierbar: Unter Orchestrierung verstehen wir die einfache Implementierung von Geschäftsprozessen auf der Basis von Operationen
Grundidee
Strukturierung einer AL nach Diensten (Services) in logischen Sichten basierend auf der fachlichen (Geschäfts-)Sicht
-Dienste-Anbieter stellen Funktionalität über definierte Schnittstellen und standardisierte Technologien bereit
-Dienste-Nutzer nutzen diese Dienste (inkl. Beschreibung) in einem Repository
Vorteile:
-Bessere Struktur der Gesamt-AL
-Gesteigerte Wiederverwendung von Diensten/Funktionalitäten
SOA-Umsetzung: Kombination bekannter Techniken
Strukturierte Programmierung: -Zerlegung monolithischer Architekturen Objekt-Orientierung: -Seperation of Concern -Information Hiding CORBA: -Ortsunabhängige und Technologieübergreifende Kommunikation von Objekten EAI: -Lose Kopplung -Legacy-Einbindung -Technologieunabhängige Kommunikation
SOA: WebServices als mögliche Technische Basis
Durch Entwicklung von WebServices und damit verbundenen Standards (SOAP, WSDL, UDDI, BPEL,..) existiert geschickte technische Implementierungsbasis für SOA (vor allem in B2B-Integration). SOA-Konzept ist jedoch unabhängig von konkret eingesetzter Technologie, kann also auch ohne WebServices implementiert werden (zB mit RMI).
SOA-Basis: Integrationsplattformen
Integration Bedienoberfläche: -Integrierte Bedienoberfläche -Kommunikation an der Bedienoberfläche -B2B-Kommunikatione Übergreifende Vorgangssteuerung: -Nutzung von Services der Anwendungskomponenten -Modellgesteuerte Prozesssteuerung(BPM) Transport: -Serviceaufruf -Routing Transformation: -Fachliche Formatierung -Datenanreicherung Adapter: -Technische Anbindung -Minimalinvasive Anbindung -Wiederverwendung -Fertigadapter
SOA: Einsatz eines Enterprise Service Bus (ESB)
Weitere Entkopplung der Dienste durch Einsatz einer Standard-basierten Integrationsplattform “Enterprise Service Bus”
- Funktionalitäten für die (graphische) Orchestierung von Services
- Synchrone & Asynchrone Kommunikation (EDA/CEP)
- Adapter an Fremdsysteme (z.B. SAP, eMail,FTP)
- Transformations- und Mapping Funktionalitäten
- Sicherheitsinfrastruktur
- Evtl. Integration von “Rule Engines”
SOA und Orchestrierung
- Geschäftsprozesse in einer SOA sind explizit als Anwendungsprozesse ausmodelliert, nicht in Anwendungssystemen verborgen
- Anwendungsprozess soll möglichst 1:1 den Geschäftsprozess widerspiegeln (ggf. über manuell anzupassende abweichende Prozesskette)
- Anwendungsprozess stellt den Prozessablauf dar, der von einem Prozessservice ausgeführt wird
Orchestrierung
Orchestrierte Anwendungsprozesse können selbst wieder als Service genutzt werden.
Enterprise Service Bus als universelle Middleware.
Komponenten als Lieferanten für orchestrierbare Services.
SOA-Einführung: Anforderungen an Anwendungsservices
Wiederverwendbarkeit: Anforderungen mehrerer Consumer erfüllen
Sinnvolle Granularität: klar definierte Funktionalität (fachlich/technisch)
Eindeutige Schnittstellen: Leistungen über wohldefinierte Schnittstellen anbieten (technische Beschreibung z.B. WSDL, nicht-funktionale Beschreibung: SLAs)
Klare Beziehungen: steht mit anderen Services über definierte (Kommunikations-) Beziehungen in Verbindung
Enscheidend –> ein guter Service Schnitt
Top-Down-Vorgehen: Vom Geschäftsprozess zum Service
1.Systematische Prozessanalyse
2.Modularisierung & Iterative Verfeinerung: Identifikation identischer ähnlicher Prozessmodule
3.Entwicklung von Geschäftsservices
(meist existiert jedoch keine grüne Wiese)
Bottom-Up-Vorgehen (Harvesting):
- Bestehende Systeme
- Identifikation von Kandidaten für Basis- und höherwertige Anwendungsservices (Bereitstellung durch Wrapping)
- Aggregation zu höherwertigen Services (Geschäftsservices)
Muss sich die IT an Business anpassen oder umgekehrt?
Beides ist gleichzeitig richtig und falsch: SOA bietet einen optimalen Ansatz zur Entkopplung beider Aspekte!
SOA-Einführung: Etablierung eines SOA Competence Centers
Genaue Strukturierung kann je nach Anwendungsfall unterschiedlich aussehen:
-Wichtig ist, dass die SOA-relevanten Aufgaben durchgeführt werden
Schrittweise Aufbau möglich und sinnvoll
SOA-Einführung: Organisatorische und strategische Aspekte
Vorgehen bei der Einführung:
-Finden von Sponsoren im Management bzw. in Fachabteilungen
-Balance Mittel- und langfristige Effekte vs. Quick Wins
Entwicklung wiederverwendbarer Dienste
-Architekturmanagement: SOA-Rahmenarchitektur und -vorgaben
-Verrechnungsmodell für gemeinsam genutzte Dienste
-Koordination der Weiterentwicklung (Versionsmanagement, Test/QS, Freigabe)
-Management der Beziehungen zwischen Diensten (Nutzer und Anbieter)
-Integration von Partnern und Zulieferern
Betrieb:
-Gewährleistung einer definierten Qualität über SLAs
-Monitoring der SLAs auf Service-Ebene (inkl. Leistungsanpassung)
SOA-Reifegradmodell
Ebene 0 (Initial): Gewachsene IT-Landschaft, keine SOA-Ansätzer erkennbar Ebene 1 (Dienste): IT-Landschaft bzw. einzelne Bereiche sind aus wohldefinierten Diensten zusammengefasst Ebene 2 (Prozesse): Services werden prozessgesteuert miteinander verknüpft Ebene 3 (Organisation): Anpassung von Organisationsstruktur und SOA Ebene 4 (Governance): Weiterentwicklung der SOA erfolgt nach klaren Leitlinien Ebene 5 (Optimierung): konitnuierliche Optimierung erfolgt
SOA: Lösung einiger Strukturprobleme
Heterogene “Netzwerke” von Einzelsystemen mit enger Kopplung haben von der Implementierung abhängige Schnittstellen in unterschiedliche Technik -> Definition fachlich wohldefinierter, allgemeiner Schnittstellen in Form von Services (Diensten)
Aus bestimmten Systemen haben sich fachliche “Datendrehscheiben” entwickelt, die fachliche Funktionalität mit Datenkommunikation vermischen -> Aufteilung nach technischen und fachlichen Komponenten; Festlegung der Datenverantwortung
“Hochintegrierte Systeme” bieten Funktionalität über mehrere betriebliche Funktionsbereiche hinweg und verhindern so gezielte, unabhängige Weiterentwicklung -> Aufteilung in durch ihre Services festgelegte, lose gekoppelten Komponenten
SOA: Chancen
Heterogene Prozesse -> Prozesse: Harmonisierung und Flexibilität
Keine fachliche Struktur der Anwendungen -> Struktur: Komponenten, Zuständigkeiten, Schnittstellen
Komplexe Anwendungslandschaft -> Infrastruktur: Entkopplung von Anwendungen
Vielzahl von Plattformen -> Plattformen: Konsolidierung und Effizienz
SOA: Herausforderungen
Es gibt kein SOA “out-of-the-box”
-Produkte/Eigenentwicklungen müssen zu individuellen Lösungen kombiniert werden
-Services müssen sinnvoll strukturiert werden
-Produkte sind teilweise relativ neu
-Best-Practices sind eine große Hilfe
Umsetzung einer durchgängigen Kette vom Geschäftsprozess zum Service:
-Top-Down vs. Bottom-Up
-Durchgängige Vision noch selten realisiert
Organisatorische Anpassung
-Entwicklung, Betrieb und Finanzierung von gemeinsamen Services (z.B.zentrales SOA Competence Center)
-Qualitätssicherung und Freigabe-Prozesse für Services
Commitment des Managements/der Fachabteilung
-SOA bringt wenig kurzfristige fachliche Mehrwerte
-Mittel- bis langfristige Amortisation
-Quick Wins müssen explizit geschaffen werden
SOA: Fazit
- ohne langfristige Vereinheitlichung der technischen Basis steigert SOA die Betriebskosten
- Aufgaben der Integration von IT-Systemen sind “eigentlich” wohlverstanden
- Einsatz von Webservices ist für eine “SOA im Großen” heute unverzichtbar
- Technologien und Produkte im SOA-Umfeld sind nicht “alle gleich”
- Einsatz einer SOA-Plattform allein garantiert noch keine gute Architektur
- -> bei klarer Verfolgung des Paradigmas ist SOA der beste bekannte Ansatz zur Beherrschung heutiger Anwendungslandschaften
