HBRS: SOA

SOA ist ein Architekturstil der den Aufbau einer Anwendungslandschaft aus einzelnen fachlichen Komponenten beschreibt. Diese sind lose gekoppelt, indem sie einander Funktionalität in Form von fachlichen Services anbieten (nach Hess)

Ein Workflow ist ist ein IT-gestützter (Sub-Prozess) eines Geschäftsprozesses.

Geschäftsprozess: Menge logisch verknüpfter Einzeltätigkeiten, um ein betriebliches Ziel zu erreichen.

Service wird von Komponente angeboten.

fachlicher Service: lose Kopplung, (geringe) Abhänigkeiten.

fachliche Komponente: direkte Abhängigkeiten

Elemente:

• Interaktionskomponenten
• Prozesskomponenten
• Funktionskomponenten
• Bestandskomponenten

Vorteile:

• Sinnvolle Strukturierung
• Fördert wiederverwendbarkeit
• Fördert lose Kopplung
• Fördert einheitlichkeit der Schnittstellen (funktionale Services nur funktionale Operationen)

Herausforderungen:

• Schwierig Services in bestimmten Layer einzuordnen

Ausnahmebehandlung:

• Direkter Zugriff der Interaktionskomponente auf Anzeigedaten der Bestandskomponenten

- Direkte Programmierung des Prozesses in einer Programmiersprache (z.B. in Java, AXIS/JAX-WS)

- Implementierung als Service mithilfe einer Modelierungssprache (z.B. BPEL/BPMN)

Tags

• import: als Verweis auf Web-Services (WSDL)
• parnerLinks: Referenz auf PortType der Web Services
• variables: Verwaltung eines internen Zustands
• sequence: (strukturierte) Aktivitäten
  • invoke, recieve, reply
  • flow (parallel), if, while, scope, compensate

1. Der BPEL-Workflow wird in einer speziellen Laufzeitumgebung deployed.
2. Der Anstoß des Workflows wird über eine Nachricht durchgeführt.
3. Jeder BPEL-Workflow beginnt mit einem Receive, er wartet also auf eine erste eintreffende Nachricht um zu starten.

BPMN-Workflow Aufbau:

• Aktivitäten
  • Unterprozesse
  • Tasks
• Ereignisse (keine Bearbeitungszeit in Anspruch, nur Zeitpunkte definieren)

Unterschiede BPEL:

• BPMN hat graphische Modellierungsnotation
• BPEL hat nur Workflows
• BPEL hat keine manuellen Tasks

Ausführungssementik für BPMN:

• eine Abbildung auf BPEL
• explizite Ausführungssemantik von BPMN 2.0
• proprietäre Semantiken - versuchen sich an Standard zu halten

• mit Compensation Handlern - Transaktionsstrategie: Kompensation
• Kompensation des gesamten Scopes über das <compensation> Tag
• die Kompensation wird von extern angestoßen ("sich selber kompensieren geht nicht")

Laufzeitumgebung für Web Services, basierend auf SOAP und WSDL, sowie WS-* Erweiterungen. Wird auch als Servlet-Container angeboten.

Aufbau:

• Handlern: agieren wie eine filter chain vor dem “Eingang” sowie “Ausgang”
• Modulen die den Server Erweiterbar machen

AXIS2 ermöglich synchrone als auch Asynchrone Kommunikationen.

Asynchron ist eine Kommunikation mithilfe von offen gehaltenen oder getrennten HTTP-Requests möglich.

Bottom-Up: Komposition - Zusammenfassung von bestehenden Schnittstellen zu Services (bestehende IST Situation)

Top-Down: Zerlegen von Prozessen in fachliche Services

Meet in The Middle:

1. Ableiten von Use-Cases

2. Services identifizieren/modellieren (Welche bestehenden Systeme unterstützen diese?)

3. Architektur-Entwicklung (4 Sichten + Umsetzung)

Technologie-Framework für die Entwicklung und Integration von verteilten Systemen basierend auf der Meta-Sprache XML

besitzt

• URI
• Schnittstellenbeschreibung als XML-Artefakt

Contract-First: Zunächst Definition der Schnittstelle und anschließend ableiten von Client-Stubs und Service-Skeleton

Code-First: Entwickeln des Service als erstes und anschließend Generierung von WSDL und Client-Stubs.

1. SOAP ist einer der wichtigsten Web Services Standards. Es ist ein XML-basiertes Nachrichtenformat.

2. Aufbau: Bild “Dreieck” SOAP, WSDL, UDDI

3. HTTP (POST), SMTP, TCP, IP

4. Nein, ein Nachrichtenaustauschformat

1. Web Service Description Language ist eine Schnittstellensprache: ein XML-Format zur Schnittstellenbeschreibung
2. Eine abstrakte Schnittstellenbeschreibung wird benötigt, um die lose Kopplung unter den Services zu gewährleisten.
   1. Korrektheit durch eindeutige Beschreibung
   2. automatisches Testen
   3. automatisches aufrufen der Schnittstelle

• Keine Abhänigkeiten
• Einfache gemeinsame Datenmodelle
• Schwache Platformspezifika
• Der Grad der Kopplung kann z.B. als fachliche Entfernung angeben werden (Wieviele Domänen liegen zwischen den Services).
• geringes Vertrauen / wenig Wissen

Der ESB ist eine Mittlerkomponente zwischen Service-Consumern und Providern.

Übernimmt verschiedenste Aufgaben wie z.B.:

• Datentransformation (Mediation)

• Service Registry

• Enthält Adapter zur überbrückung technischer Unterschiede

• Enthält Integrationsdienste (Routing, SSO, BAM…)

• 4-Sichten Modell von Starke
  • Kontextsichten
  • Laufzeitsichten
  • Bausteinsichten
  • Verteilungssichten
• SoaML

Modell nach Libhart???

• Requirement-Analayse => Use-Cases

• Komponenten aus Use-Cases identifizieren

• Services und Service-Operationen von Komponenten ableiten

• Analyse von Bestandsystemen (Kann etwas wiederverwendet werden?)

• Interaktionskomponenten aus Use-Cases identifizieren

• Zuordnen der Komponenten zu spez. Domänen.

Nach Humm&Hess (Komponentenschnitt)

• R1: Komponenten sollen nach fachlichen Kriterien gebildet werden
• R2: Alle Operation (der Komponente) sollen von genau einer Kategorie sein (Bestand, Funktion, Prozess, Interaktion)
• R3: Komponenten unterschiedlicher Service-Kategorien sollen ausschließlich Abhängigkeiten laut der Referenzarchitektur haben
• R4: Keine Zyklischen Abhängigkeiten
• R5: intern engen Zusammenhalt --- untereinander gering gekoppelt
• R6: Bestandskomponenten haben Datenhoheit

• Durch hohen Einsatz von Loser Kopplung
• Entwurf nach Humm und Hess

• Neuen Geschäftsprozesse sehr schnell und kostensparend durch
  • Wiedervewendung von Services
  • Neu-Orchestrierung
• Cooperate Design --> geringe Schulungskosten
• Geringere Fehlerquoten (z.B. durch erhöhte Automatisierung)

• Skalierbarkeit ist die Fähgikeit einer Software-Architektur flexibel an Nutzungsraten angepasst zu werden. Etwas skaliert gut, wenn höhere Nutzungsraten durch einen steigenden Ressourcenbedarf bedient werden können.
• Horizontale vs. Vertikale Skallierung
• Skallierbarkeit kann durch verschiedene Dinge erreicht werden z.B.:
  • Klonen von Services (Loadbalancing)
  • Fachliche Teilung eines Services
  • Aufrufer in Kategorieren aufteilen
  • Statless Service (oder States auslagern)
  • Lokalisierung und Caching
• (Skallierbarkeit steht auch in verbindung mit Loser Kopplung)

Niemand! Einzelne Services/Komponenten können unterschiedlichen Personen gehören.

Stichwort: legacy system/ALT-System

Nein. Einführung kann sehr Aufwendig sein, politisch schwierig und auch nicht immer sinnvoll (Evtl. z.B. wenn niedrige Latenz wichtig ist).

Der Einsatz einer SOA rentiert sich, wenn es wirtschaftlich ist, also der Nutzen (die Einsparung, der Gewinn) höher ist als die entstehenden Kosten.

Meist bei großen. heterogenen Systemen um große Anwendungslandschaft zu vereinheitlichen.

Die BRE ermöglicht die zentrale Definition von flexiblen fachlichen Regeln (Business Rules). Die BRE ist sehr wichtig, da sich Geschäftsprozesse häufer und schneller Ändern können als die Entwicklung der Software (unterschiedliche Zyklen). Die BRE ermöglicht eine Anpassung auch zwischen verschiedenen SW-Realses.

Sichtwort: Flexibilität

Durch eine Business Activity Monitoring Komponente können Daten über das Laufzeitsystem und fachlichen Prozesse (zB. KPIs) gesammelt werden und Minutenaktuell überwacht werden.

ODER

Die Aufgabe ist die Überwachung von Geschäftsprozessen oder unternehmenskritischer Ressourcen. Eine BAM ermöglicht die Überwachung von KPI’s und kann Probleme im Betrieb der SOA aufdecken (z.B. überlaufene oder kaum genutzte Services).

• Eine SOAP-Nachricht kann über mehrer Zwischenknoten (Intermediaries) geleitet werden
• Intermediaries können in den Verarbeitungsprozess einer SOAP-Nachricht eingreifen
• Intermediaries sollten nur auf SOAP-Header zugreifen

One-way

Request-Response

Solicit-Request

Notification

WS-Addressing ermöglicht eine Detailiertere Addressierung von SOAP Nachrichten.

Metainformationen über die Nachrichten: Bezug zu früheren Nachrichten