Serviceorientierte Architektur (SOA)

Question 1

Bedeutung “Service” im SOA-Kontext

Answer 1

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.

Question 2

Definition SOA

Answer 2

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.

Question 3

Verständnisse von SOA

Answer 3

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

Question 4

Geschäftsservice

Answer 4

• Funktionalität mit unmittelbarer geschäftlicher Bedeutung
• eindeutig definierte Nutzungsweise
• eindeutig definierte Reaktion und Wirkung
• im Kontext vertraglicher Pflichten/Nutzen
• idR an Organisationsgrenzen angeboten

Question 5

Anwendungsservices

Answer 5

-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

Question 6

Servicearten

Answer 6

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

Question 7

Grundidee

Answer 7

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

Question 8

SOA-Umsetzung: Kombination bekannter Techniken

Answer 8

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

Question 9

SOA: WebServices als mögliche Technische Basis

Answer 9

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).

Question 10

SOA-Basis: Integrationsplattformen

Answer 10

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

Question 11

SOA: Einsatz eines Enterprise Service Bus (ESB)

Answer 11

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”

Question 12

SOA und Orchestrierung

Answer 12

• 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

Question 13

Orchestrierung

Answer 13

Orchestrierte Anwendungsprozesse können selbst wieder als Service genutzt werden.
Enterprise Service Bus als universelle Middleware.
Komponenten als Lieferanten für orchestrierbare Services.

Question 14

SOA-Einführung: Anforderungen an Anwendungsservices

Answer 14

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

Question 15

Top-Down-Vorgehen: Vom Geschäftsprozess zum Service

Answer 15

1.Systematische Prozessanalyse
2.Modularisierung & Iterative Verfeinerung: Identifikation identischer ähnlicher Prozessmodule
3.Entwicklung von Geschäftsservices
(meist existiert jedoch keine grüne Wiese)

Question 16

Bottom-Up-Vorgehen (Harvesting):

Answer 16

1. Bestehende Systeme
2. Identifikation von Kandidaten für Basis- und höherwertige Anwendungsservices (Bereitstellung durch Wrapping)
3. Aggregation zu höherwertigen Services (Geschäftsservices)

Question 17

Muss sich die IT an Business anpassen oder umgekehrt?

Answer 17

Beides ist gleichzeitig richtig und falsch: SOA bietet einen optimalen Ansatz zur Entkopplung beider Aspekte!

Question 18

SOA-Einführung: Etablierung eines SOA Competence Centers

Answer 18

Genaue Strukturierung kann je nach Anwendungsfall unterschiedlich aussehen:
-Wichtig ist, dass die SOA-relevanten Aufgaben durchgeführt werden
Schrittweise Aufbau möglich und sinnvoll

Question 19

SOA-Einführung: Organisatorische und strategische Aspekte

Answer 19

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)

Question 20

SOA-Reifegradmodell

Answer 20

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

Question 21

SOA: Lösung einiger Strukturprobleme

Answer 21

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

Question 22

SOA: Chancen

Answer 22

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

Question 23

SOA: Herausforderungen

Answer 23

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

Question 24

SOA: Fazit

Answer 24

• 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