SOA Zusammenfassung

Eine möglichst kurze Zusammenfassung zum Thema SOA, wird laufend ergänzt. Interessante Links zum Thema: – http://www.ibm.com/developerworks/library/ws-soa-design1/ Zusammenfassung basiert auf folgenden Quellen – SOA goes real, Daniel Liebhart

Die wichtigsten Ziele von SOA sind:

  • Verbesserung der Agilität des Business und der Produktivität der IT
  • Erhöhung der Anpassungsfähigkeit einer betrieblichen Informatik
  • Die Wiederverwendbarkeit bestehender Systeme
  • Unterstützung der fortlaufenden Prozessverbesserung eines Unternehmens
  • Ausrichtung der IT auf die Anforderungen des Business

Dienste statt Applikationen

Jeder Dienst (Service) besteht aus:

  • Service: Muss über einen (eindeutigen) Namen verfügen
  • Service Interface (Achtung: Ein Dienst kann ein oder mehrere Interfaces haben)
  • Service Contract: Informelle Spezifikation der Verantwortlichkeit, Funktionalität, Bedingungen und Einschränkungen, Verwendung des Services
  • Service Implementation: technische Realisierung, Umsetzung Business Logik

Service Layering

  • Basic Services: z.B QoS, Publication, Discovery, Binding etc
  • Composite Services: Diese Dienste sind für die Bereitstellung eines einzelnen zusammenhängenden Service notwendig
  • Managed Services: Alle organisatorische Aufgaben, Definition der Dienstleistung über SLA’s
Service Layering
Service Layering

Standards

Web Services

Quelle: Wikipedia

 

Der Erfolg von Web Services wurde geprägt durch zwei grundlegende Eigenschaften des Webs:

  • Einfachheit
  • Allgegenwärtig

Weitere Vor- und Nachteile von Webservices (Wikipedia)

 

Mit Webservices ist es möglich, elektronische Dienste öffentlich zugänglich zu machen, sodass sie für andere Anwendungen nutzbar werden.

Definition: Webservices sind eine neue Art von Web-Applikationen. Web Services sind modulare, sich selbst beschreibende Applikationen, die über das Internet publiziert, lokalisiert und aufgerufen werden können. Web Services führen ein beliebiges Spektrum von Funktionen aus, die von der Beantwortung einfacher Anfragen bin hin zur Ausführung komplexer Business Prozesse gehen. ([Tidwell 2000]

Architektur eines Web Services:

  • Listener
  • Business Interface: Schnittstelle zur eigentlichen Funktionalität; Aufbereitung Meldungen, Zwischenspeicherung von Anfragen, Authentisierung und das Accouting
  • Business-Logik: Funktionalität

Basistechnologie:

  • XML
  • HTTP

Web Services lassen sich als Schichtenmodell dargestellt werden:

  • Core Layers: XML und SOAP
  • Higher Levels: BPEL und WSDL

Verschiedene Arten von Web Services (Wikipedia)

SOAP und WSDL

SOAP ist ein einfaches Protokoll für den Austausch von XML-Daten über das Web. SOAP definiert einen Umschlag (Envelop), in den XML Daten verpackt werden können. Eine Meldung im SOAP Format besteht aus

  • SOAP Header: Informationen über Sicherheit, Routing und Zusatzinformationen (siehe oben „Verschiedene Arten von Web Services)
  • SOAP Body: zu transportierende XML Daten

 

Struktur einer SOAP-Nachricht:

<span class="sc3"><span class="re1">&lt;?xml</span> <span class="re0">version</span>=<span class="st0">"1.0"</span><span class="re2">?&gt;</span></span>
<span class="sc3"><span class="re1">&lt;s:Envelope</span> <span class="re0">xmlns:s</span>=<span class="st0">"http://www.w3.org/2003/05/soap-envelope"</span><span class="re2">&gt;</span></span>
    <span class="sc3"><span class="re1">&lt;s:Header<span class="re2">&gt;</span></span></span>
    <span class="sc3"><span class="re1">&lt;/s:Header<span class="re2">&gt;</span></span></span>
    <span class="sc3"><span class="re1">&lt;s:Body<span class="re2">&gt;</span></span></span>
    <span class="sc3"><span class="re1">&lt;/s:Body<span class="re2">&gt;</span></span></span>
<span class="sc3"><span class="re1">&lt;/s:Envelope<span class="re2">&gt;</span></span></span>

WSDL beschreibt, was ein Service tun kann, wo er zu finden ist und wie er aufzurufen ist, sowie den Zugriffspunkt auf bestimmte Services als eine Sammlung von Netzwerk-Endpunkten (Ports). WSDL stellt ein Vertrag zwischen den Services dar.

 

Ein WSDL Dokument besteht aus einem abstrakten und einem konkreten Teil, die beiden können in einem sogenannten Document Tree dargestellt werden; Der abstrakte Teil definiert sprach- und plattformunabhängige Typen, Nachrichten und Porttypen. Der konkrete Teil definiert Bindungen und Dienste.

Dienste:

  • Type: Container für Definition der Datentypen
  • Message: abstrakte Definition der auszutauschenden Daten
  • Operation: abstrakte Definition einer von einem bestimmten Service unterstützten Aktion
  • Port Type: abstrakte Menge von Operationen, die von einem oder mehreren Netzwerkendpunkten unterstützt werden
  • Binding: konkrete Beschreibung des Protokolls
  • Port
  • Service: Sammlung zusammenhängender Endpunkte

WSDL-Nachrichtentypen:

  • One-Way: Es wird nur eine Nachricht versandt und keine Antwort erwartet
  • Request/Response: Sender sendet Nachricht, Empfänger beantwortet sie
  • Solicit Response: Empfänger sendet Nachricht, Sender beantwortet sie
  • Notification: Ein Sender sendet an mehrere Empfänger

Beispiel WDSL: http://zuberonline.net/ws/employees.php?wsdl oder bei Wikipedia.

UDDI

Verzeichnis für Webservices, nicht zwingend notwendig für den Betrieb einer SOA. Bestandteile eines UDDI:

  • White Pages: Kontaktdaten, „Wer liefert was?“
  • Yello Pages: Service Typen
  • Green Pages: Schnittstellenbeschreibungen

REST

= REpresentational State Transfer

  • Verwendet kein SOAP
  • reines HTTP
  • CRUD Operation (POST, GET, PUT; DELETE)
  • Client/Server Rollen
  • Stateless

Business Process Execution Language (BPEL)

Mit BPEL lassen sich Prozesse beschreiben und abbilden. Im Unterschied zu anderen Techniken lassen sich Prozesse welche mit BPEL beschreiben sind, direkt zur Steuerung eiener Workflow Engine (BPEL Engine) verwenden. Es wird unterschieden zwischen dem Geschäftsprotokoll und dem ausführbaren Geschäftsprozess. Ein BPEL Prozess besteht aus einem Prozess-Interface (in WDSL definiert, das jeder BPEL Prozess selbst ein Web Service darstellt) und einem Prozess-Schema. BPEL basiert auf XML, es existieren eine Reihe von Basiselementen:

  • Partners: Dienste, mit denen ein BPEL-Prozess interagiert
  • Activities: Sequenz von Aktivitäten, welcher ein Prozess durchläuft
  • Variables
  • Correlation Sets: eine Menge von Eigenschaften, die allen Meldungen eines Prozesses gemeinsam sind
  • Fault Handlers: Aktionen, die im Fehlerfall ausgeführt werden müssen

BPEL unterscheidet zwischen atomaren und strukturierten Aktivitäten:

  • Atomic Activities: entsprechen einfachen Statements einer Programmiersprache, atomare Aktivitäten können nicht zur Gruppierung anderer atomarer Aktivitäten verwendet werden. (Assign, Invoke, Receive/Reply, Throw, Wait, Empty)
  • Structured Activities: steuern den Ablauf eines Prozesses, verwendet werden strukturierende Keywords (if, for, while etc.) Strukturierte Aktivitäten enthalten immer atomare Aktivitäten zur Ausführung der konkreten Instruktion in einem Prozessablauf. (Sequence, While, Switch, Flow, Pick)

Das SOA-Modell

…muss folgend drei Stärken von SOA abdecken:

  • Weiterverwendung bestehender Systeme vorsehen
  • Modellierung von ausführbaren Prozessen und Regeln erlauben
  • Zentrale Standards wie SOAP, WSDL und BPEL unterstützten

Architektur des SOA Modells

  • Presentation: User Interface
  • Orchestration: Ablauf der Applikation als Workflow
  • Services
  • Integration Architecture: Infrastruktur zur Verbindung der verschiedenen Dienste und zur Verbindung von Diensten mit bestehenden Applikationen/Systemen
  • Application:
  • Virtualized Infrastructure: gesamte zum Betrieb notwendige Infrastruktur

 

Dieses Modell ist jedoch nicht zwingend als geschichtetes Modell zu verstehen. z.B können Services andere Services aufrufen, oder Datenbanken über Triggerfunktionen Workflows aufrufen.

Das SOA-Modell sieht eine logische Teilung zwischen Applikationen, Integrationsmechanismen, Diensten und der Orchestrierung vor. Die Applikationen beinhalten bestehende oder auch neue Systeme und logische Datenspeicher. Die Dienste stellen Schnittstellen zu dein einzelnen Anwendungen dar. Die Orchestrierung dient zur Steuerung von Abläufen, die mittels Einbezug mehrerer Dienste durchgeführt werden. Die Kommunikation zwischen Diensten untereinander und deren applikatorischen Umsetzung erfolgt über eine Integrationsarchitektur. –> Die Wiederverwendung bestehender Systeme ist ein sehr wichtiger Bestandteil von SOA.

Der Service Layer wird unterstützt durch die beiden Standards SOAP und WSDL. UDDI ist nicht unbedingt notwendig, um SOA auf Unternehmensebene zu betreiben.

Die wichtigsten Ebenen für den Bau einer SOA:

  • Presentation: Realisiert als Portal, Office Application oder Client Application. Client Application können als Rich Client oder als Web Client umgesetzt werden. Im weitesten Sinne können Client Applications auch als Servicenehmer bezeichnet werden.
  • Orchestration: …bildet Geschäftsprozesse und Geschäftsregeln in einer SOA ab. Es kann zwischen der Dynamik auf Prozessebene und der Dynamik auf der Ebene von einzelnen Prozessschritten unterschieden werden. Geschäftsprozesse bilden Ablaufe ab, die sich aus einer Sequenz aufgerufener Services zusammensetzt, die gleichzeitig den Datenfluss zwischen Letzterem steuern. Geschäftsprozesse sind in BPM (Business Process Management) und BPEL (Business Process Execution Language) defininert. Sie stellen die Dynamik auf Prozessebene dar. Geschäftsregeln formulieren Steuerungsparameter für das Verhalten der Abläufe einer Anwendung. Diese Regeln werden mit einer Rule Engine modelliert. Diese stellen die Dynamik auf Stufe der einzelnen Prozessschritte dar.
  • Services: Mechanismen zur Verwaltung von Diensten. Wichtigsten Elemente: Verantwortlichkeiten, Klassifizierung, Lebenszyklen, Dienstplanung, Versionsverwaltung, Testszenarien, SLA und Verrechnungsmöglichkeiten.
  • Integration Architecture: Verknüpfung der verschiedenen Dienste und zur Verbindung von Diensten mit bestehenden Anwendungen oder Datenbanken, sowie zur Kopplung mit der Presentation Ebene. Ein ESB (Enterprise Service Bus) stellt die Kommunikation zwischen verschiedenen Services sicher.

Bei SOA ist ein Prozess ein ausführbarer Prozess, dies entspricht einem Workflow bei der WMFS Coalition.

Referenzmodelle

(ohne auf die einzelnen Modelle einzugehen)

  • OASIS Reference Model for Serivce Oriented Architecture
  • SOA Meta Model des W3C
  • GeneriCo (Generisches Unternehmen)
  • Echtzeitunternehmen
  • Real-Time Enterprise Architektur

Die Bestandteile von SOA

Das SOA Modell

Die Presentation Ebene

Portale und Portlets: … erlauben es, Funktionalität und Interaktion über standardisierte Erweiterungen von WSDL, den WSPR (Web Service for Remote Portlets) darzustellen. Geeignet für Tasks welche wenig menschliche Interaktion benötigen und so in einer Webseite integriert dargestellt werden können. Der Einsatz solcher Portal Services lohnt sich meist nur, wenn bereits eine solche Portal Infrastruktur vorhanden ist.

  1. Generation von Portalen: Portalen von ISP
  2. Generation: Suchmaschinen
  3. Generation: Unternehmensportale, welche alle relevanten Daten eines Unternehmens auf einer Plattform zusammenführen.

Mögliche Definition:

 

Ein Portal ist eine Infrastruktur, die sicheren, konfigurierbaren, personalisierbaren und integrierten Zugriff auf dynamische Inhalte erlaubt, wo auch immer dieser Zugriff benötigt wird. Dieser Inhalte stammen aus verschiedenen Quellen und sind in verschiedenen Formaten gespeichert.

Verschiedene Portale:

  • Employee Portale: HR Tasks
  • Business Portale: Marketing-, Vertriebs- und Serviceprozesse
  • Supplier Portale: Informationen für Lieferanten über Angebotsabgabe, Leistungsabname, Rechnungstellung etc.
  • Customer Portale: Marketing-, Vertriebs- und Serviceprozesse für den Endkunden

Office Business Applications: Direkt in die Anwendung (Word, Excel und Co.) eingebettet, oder das Dokumentenformat wird so erweitert, das die Beschreibung von Interaktion eingebettet werden kann. Die Schnittstelle zu einem Dokument als Web Service wird auch Content-Based Interface oder Ressource Centric Interface genannt.

 

Client Applications: Wichtigste Technologien: Java und .NET, jeweils als Rich Client oder als Webclient.

Orchestration-Ebene

Wiederholung: Es kann zwischen der Dynamik auf Prozessebene und der Dynamik auf der Ebene einzelner Prozessschritte unterschieden werden:

  • BPM und BPEL: Darstellung der Dynamik auf Prozessebene
  • Rule Engines: Darstellung der Dynamik auf der Ebene der einzelnen Prozessschritte

BPM: betrachtet das Unternehmen als Ganzes, als unabhängige Sammlung von Geschäftsprozessen, die auf externe und interne Ereignisse reagieren. Die Geschäftstätigkeit wird als Ganzes modelliert und strukturiert. Man nennt diese Strukturierung auch Prozesslandschaft, diese setzt sich aus Kern- und Unterstützungsprozessen zusammen und setzten sich aus Marko-, Mikro- und Teilprozessen zusammen.

 

Executable Processes: SOA versteht einen Prozess als automatisierbaren Prozess. Die Prozesse werden mit einem BPEL-Modellierungstool als Ablaufdiagramm graphisch dargestellt. Diese graphische Darstellung wird (als BPEL Definition) wird dann in eine BPEL Engine geladen und ausgeführt.

Business Rules: sind ein integraler Bestandteil des Geschäftsprozessmanagements, sie steuern das Verhalten von Prozessen. –> Umsetzung via Rules Engines.

WFMS – Technik für ausführbare Prozesse

Workflows sind automatisierte Abläufe, die Dokumente, Aufgaben und Informationen zwischen Teilnehmern austauschen. Workflow Management Systeme sind die technische Basis für jede Business Process Engine, die in BPEL modellierte Geschäftsprozesse ausführen kann.

 

Nicht alle Prozesse eigenen sich für die Modellierung / Steuerung über ein WFMS, anbei Kriterien für die Strukturierung:

  • Strukturiertheit
  • Art des Auftretens
  • Häufigkeit des Auftretens

Folgendes sind die drei wichtigsten Aufgaben eines WMFS:

  • Modellierung
  • Simulation
  • Instanziierung
  • Ausführung von Workflows
  • sowie deren Monitoring
  • und die nachträgliche Analyse

Generische Struktur eine WMFS:

  • Definition Tool: Modellierung
  • Process Definition: von Definition Tool generierte Process Definition, die den Ablauf, Eingangs- und Ausgangskriterien einzelner Prozess-Schritte sowie anderen Steuerungsinformationen enthält.
  • Organisations / Role Model Data: Organisation und ACL’s
  • Workflow Control Data: Statusinformationen der laufenden Prozesse sowie Point of Recovery Daten
  • WFM Engine: Steuerung eines einzelnen Prozess-Schrittes
  • Workflow Relevant Data: Alle im Zusammenhang mit einem Workflow relevanten Daten -> Case Data
  • Work List: Sämtliche Aufgaben, welche menschliche Interaktion erfordern
  • Worklist Handler: Überwachen der Work List und steuern des User Interfaces
  • User Interface

Die WfMC Workflow Reference Architecture: Ziel dieses Modell’s ist es, die Interoperabilität von WMFS von verschiedenen Herstellern zu gewährleisten.

 

Interfaces:

  • Workflow Definition Interchange (Interface 1): Datenaustausch zwischen Modellierungstools
  • Workflow Client Application Interface (Interface 2): Trennung zwischen Client und Engine
  • Invoked Applications Interface (Interface 3): Formale Schnittstelle zwischen den angesteuerten Applikationen
  • WAPI Interoperability Functions (Interface 4): Interface zwischen verschiedenen WF Engines
  • Administation & Monitoring Interface (Interface 5): Interface zu Amin. und Monitoring Tools

Business Process Management

Die Kombination von BPM und SOA verspricht die optimale Abbildung betrieblicher Anforderungen an die IT.  BPM bildet alle Prozesse eines Unternehmens ab, diese müsse nicht unbedingt alle von eine SOA ausgeführt werden können, dennoch ist SOA der Schlüssel zur Umsetzung betrieblicher Prozesse in technischen Systeme und eine Grundvoraussetzung für die Realisierung automatischer Workflows.

 

Business Process Management umfasst die kontinuierliche Verwaltung aller ablaufenden Prozesse inklusive der Betrachtung der Schnittstellen nach aussen.

Definition nach Hammer & Champy: Bündel von Aktivitäten. für das ein oder mehrere Inputs benötigt werden und das für den Kunden ein Ergebnis von Wert erzeugt.

Prozesse werden im Rahmen von BPM modelliert, als Modellierungswerkzeug steht zum Beispiel EPK oder UML zur Verfügung. Die Umsetzung der modellierten Abläufe in Informationssysteme erfolgte jedoch meist manuell, d.h. durch die Auscodierung der entsprechenden Anwendung.

Erweiterungen von BPEL

BPEL verfügt über folgende Schwachpunkte:

  • Mangelnde Prozessunterstützung für Prozessschritte, welche durch Menschen durchgeführt werden
  • Fehlendes Managementt (Lifecycle-Management, Compliance etc.)
  • Fehlende Sprungmöglichkeit innerhalb eines Prozesses

Verschiedene Hersteller liefern deshalb Erweiterungen für BPEL

Rules Engines

Formulierung von Regeln zur Steuerung von einzelnen Prozessschritten, getrennt von der restlichen Businesslogik.

 

Einsatzgebiete:

  • Validierung von Konsistenzregeln
  • Steuerung komplexer Aktionen, basierend auf Fakten (z.B Kreditwürdigkeit)
  • Steuerung von Reaktionen auf bestimmte Ereignisse

Deshalb sind Rules Engines für die sich ändernden Variablen eines Prozesses empfohlen. Der Einsatz von Rules Engines ist flexibler, als die Funktionalität auszuprogrammieren, ausserdem können Regelsätze wiederverwendet werden.

Aufbau einer Rule Engine

  • Working Container: Alle Fakten –> Daten aus Anwendungen oder Ergebnisse anderer Regeln, auch bekannt als „Fact Base“
  • Rule Base: Enthält sämtliche Regeln
  • Inference Engine: Regelinterpreter
  • Pattern-Matcher: Check anhand von Fakten und aller relevanter Regeln sowie deren Prämissen
  • Agenda: Sortierte Liste von Regeln, welche aufgrund der Fakten gefeuert werden
  • Execution Engine: Aufruf der Aktionen gemäss der Reihenfolge in der Agenda

Die Service Ebene

Ein Service ist:

  • ein wiederholbarer Arbeitsschritt
  • Kapselung der Funktion
  • Logische Sicht eines Systems (nach W3C)
  • ein Mittel, kein Ziel
  • Im Vordergrund stehen die Produktivität, die Wiederverwendbarkeit bestehender Systeme, Kosteneffizienz

Komponenten Service Management: Verantwortlichkeiten, Lebenszyklen, Dienstplanung, Versionsverwaltung, Testszenarien, SLA, Verrechnung sowie der Betrieb der IT durch ITSM

 

ITSM:

  • Incident Management: First Level Support (SPOC)
  • Problem Management: Second Level Support, ohne Änderung an der Konfiguration
  • Change Management: Planung und Ausführung Änderungen
  • Configuration Management: Identifikation, Überwachung, Statusnachweis und Verifikation sämtlicher Komponenten
  • Release Management: Planung, Dokumentation, Abnahme und Durchführung von Releases
  • Contingency Management: Eventuellfall-Planung
  • Capacity Management: Erfüllen von Kundenanforderungen
  • Availability Management: Sicherstellen der Verfügbarkeit
  • SLA Management: Abschluss und Kontrolle SLA
  • Cost Management: Kostenermittlung und Leistungsverrechnung

Service Interface: WSDL und SOAP:

 

Service Interface = Proxy für Service Requestor zum Service Provider

Interface Typen:

  • Method-Centric Interfaces: Aufruf von Funktionen und Methoden über ein verteiltes System hinweg –>RPC, Methodennamen sind selbstsprechend, es werden nur sehr wenig Daten übermittelt, geeignet für einfache Dienste
  • Message-Centric Interface: „process this“, auch bekannt als „Document Oriented Web Service“
  • Ressource-Centric Interface: Auch bekannt als „Content Centric Interface“, Alles via „GET, POST, PUT, DELETE“ was sehr gewöhnungsbedürftig, jedoch sehr mächtig ist. Eine Ressource kann als Dokument angesehen werden.

Merke: Ohne Web Services, kein SOA!

 

Spezialized Services: Querschnittsfunktionen wie Output Management und Transformation

Hierbei handelt es sich um Querschnittsfunktionen im weitesten Sinne, Mittel zur organisatorischen Zentralisierung bestimmter Aufgaben in einer IT.

Beispiele:

  • Conversion Service Management: Verwaltung der verschiedenen Formatumwandlungen. Wichtigste Bestandteile: Conversion Modelling Tool, Conversion Rule Storage, Conversion Engine
  • Output Management: Deckt ab: Erstellung von Dokumenten: Regelbasiert, Textbausteine. Verteilen von Dokumenten: Gemäss jeweiligem Geschäftsfall. Lieferung von Dokumenten: Medienspezifisch. Aufbereitung für Massenversand: Zweck Porto-Optimierung.

Integration Architecture Ebene

…ist zur Verknüpfung diverser Dienste und Verbindung von Diensten mit bestehenden Anwendungen oder Datenbanken sowie zur Kopplung von Services mit den Bestandteilen der Presentation Ebene zuständig. Es ist eine Integration mit oder ohne ESB (Enterprise Service Bus) möglich.

 

Verschiedene Integrationsebenen traditioneller Architekturen:

  • Kommunikationsebene
  • Datenbankebene
  • Objektebene: Kommunikation zwischen Systemen, Zugriff auf Objekte des anderen Systems.
  • Prozessebene: WMFS

EAI

Enterprise Application Integration, Ansatz zur Integration aus den 1990er Jahren.

 

EAI Topologien:

  • Hub and Spoke: Zentraler Server, es ist ein Failover System nötig, jedoch einfache Implementation
  • Bus Topologie: Komplex aber robust

Funktionen EAI-Infrastrukturen:

  • Development: Prozessmodellierung, Transformierungsspezifikation, Realisierung Interface
  • Prozess Management: Steuerung Ablauf Integration der beteiligten Systeme
  • Runtime: Distribution und Replikation von Prozessen sowie Monitoring
  • Transformation: Transformierung, Verteilung von Meldungen, Synchronisierung und Überprüfung von Meldungen
  • Connectivity: Unterstützung verschiedener Kommunikationsprotokolle, Verwaltung der Addressierung aller Systeme und Sicherheitsmechanismen
  • Interface

EAI wird meist als Middleware realisiert (=Kommunikationsinfrastruktur), deren Kommunikationsarten:

  • Conversational: Komponenten interagieren synchron –> Real-Time Systeme
  • Request / Reply: Gegenseitiger Funktionsaufruf
  • Message Passing: Austausch von Informationen über Meldungen, Kommunikation erfolgt nur in eine Richtung
  • Publish / Subscribe: Nachricht erhalten nur diejenigen, welche sie abonniert haben

EAI ist meist aufwändig und teuer, da die Middlewaresysteme eine sehr enge Anbindung an eine bestimmte Basistechnologie erfordern. SOA mittels Web Services kann EAI schnell und einfach umsetzten. Einschränkung dabei: Web Services sind nicht zur Übermittlung von grossen Datenmengen geeignet.

 

Vorteile SOA vs. tratitionelel EAI:

  • Einfachheit: Traditionelle EAI eignen sich für grosse Umgebungen, SOA ist auch für kleinere Unternehmen verwendbar
  • SOA verwendet Offene Standards
  • Flexibilität (durch offene Standards)
  • Preis
  • Scope: EAI betrachtet verschiedene Applikationen als Gesamtsystem, Services erlauben Aufteilung von grossen Applikationen in kleine Teile.
  • Effiziens: Integration einzelner logischer Einheiten zu dynamischen Applikationen ist sehr einfach
  • Dynamik: traditionelle Middleware ist meist sehr statisch

Logical Integration

= Implementierung ohne ESB, die dabei nötigen Infrastrukturbestandteile sind:

  • TCP/IP Netzwerk
  • Application Server
  • HTTP und DNS

Enterprise Service Bus

Aufgaben ESB:

  • Empfangen und Senden von Meldungen
  • Bereitstellen Schnittstellen zur Realisierung von Formatkonvertierung
  • Normalized Messaging Router
  • Installation von Komponenten
  • Deployment von Komponenten
  • Life Cycle Verwaltung von Komponenten
  • Kontrolle und Monitoring von Komponenten

EAI Patterns

  • Splitter: Aufteilen von Meldungen
  • Translator: Konvertieren von Meldungen
  • Content Enricher: …mit externen Daten anreichern
  • Aggregator: Sammeln von zusammengehörigen Daten
  • Normalizer: konsolidiert Meldungen verschiedenen Formats
  • Resequenzer: Filter welche Meldungen sammeln und in bestimmter Reihenfolge publizieren
  • Canonical Data Model:  Standardisierte Repräsentation von Meldungen

SOA einführen

Die Einführung von SOA hängt im Wesentlichen von der jeweiligen Situation des Unternehmens und seiner betrieblichen Informationssysteme ab. Deshalb hängt die erfolgreiche Einführung von SOA auch von der Einführungsstrategie ab. Und: Entgegen der Versprechen vieler Hersteller und Analysten löst SOA nicht alle Probleme die wir im Zusammenhang mit Informatikprojekten schon immer hatten. Eine Besonderheit von SOA ist, dass das System nicht mehr als ganzen modelliert wird, es besteht viel mehr aus einer Menge von Services, welche über die Orchestrierung gesteuert werden.

Präsention: Input Validation und Screen Flow

Die Qualität von Software zu bestimmen ist sehr schwierig. Faustregel: Wenn das GUI gut aussieht, ist der Rest sicher auch in Ordnung (nicht meine Meinung) Durch ein gutes (benutzerfreundliches) GUI können bereits bei der Eingabe Fehler vermieden werden. Bei Rich-Clients besteht die Möglichkeit, Geschäftsregel für die Input Validierung zu verwenden. Bei Web Clients besteht hier das Problem, dass bei der Überprüfung viel Traffic zwischen Client und Server aufkommen kann.

 

Im gewissen Sinne repräsentiert der Screen Flow den ausführbaren Geschäftsprozess. So könnte man die BPEL Engine dazu verwenden, den Ablauf der Fenster zu steuern. Ein solches vorgehen ist nur dann sinnvoll, wenn automatisierte Prozesse mit sehr geringer User-Interaktion vorliegen. Zwei weitere Gründe dagegen: Die Performance der Anwendung verschlechtert sich, wenn jedes mal die BPEL Engine aufgerufen werden muss und die Komplexität der Modellierung wächst stark.

Prozessmodellierung

Die Modellierung von Prozessen ist eine zentrale Aufgabe bei der Einführung einer SOA. Folgende Fragen müssen beantwortet werden, um ein Prozess richtig modellieren zu können:

  • Was soll mit dem Prozess erreicht werden?
  • Wie soll der Prozess umgesetzt werden?
  • Von wem sollen die einzelnen Prozess-Schritte umgesetzt werden?

Schritte der Prozessmodellierung:

 

Case Identification -> Process Definition -> LUW or Task Isolation -> Process Information Design -> Process Quality Control

Schritte der Prozessmodellierung siehe Tabelle 7.1 im Buch „SOA goes real“ auf Seite 152.

Prozessdokumentation: Diese kann sehr umfangreich ausfallen. Es kann Sinn machen, die BPEL Definition als Dokumentation zu verwenden. Da ausserdem jeder Prozess als Service dargestellt wird, kann die Prozessbeschreibung im Rahmen der Beschreibung eines Services dokumentiert werden.

Services: Gestaltungsprinzipien

Idealerweise deckt ein Service einen Schritt in einem Geschäftsprozess ab. Auf folgende Kriterien sollte geachtet werden:

  • einfache und verständliche Schnittstelle
  • vollständig unabhängig
  • kann vielseitig eingesetzt werden
  • wird stabil und robust realisiert

Es gelten im Grunde die selben Prinzipien wie bei der Objektorientierung: Information Hiding, Modularization und Separation of Concern.

 

Bezüglich der Gestaltung der Services stellen sich immer folgende Fragen:

  • Wie können Dienste isoliert werden?
  • Wie werden Services gebaut?
  • Was genau ist eine gute Service-Schnittstelle?

Es empfiehlt sich, die Anforderungen als Use Case zu modellieren, diese reflektieren die Geschäftsprozesse besser als das Objektmodell eines Systems. Anschliessend sollte jeder Use Case daraufhin untersucht werden, ob die Funktionalität als Service abgebildet werden kann.

 

Im realen Leben wird man selten auf der grünen Wiese beginnen können, so dass bestehende Systeme weiterverwendet werden müssen. Deshalb sollten in der Praxis zuerst die Dienste aufgrund der realisierenden Anwendung isoliert werden. In einem zweiten Schritt werden die Services den Möglichkeiten der bestehenden Anwendungen gegenübergestellt. Services welche bereits mit den bestehenden Anwendungen realisiert werden kann, sollte näher betrachtet werden. Anschliessend stellt man diesen Service demjenigen den die Anwendung benötigt gegenüber. So kann man für jeden Service bestimmen, ob die neue Anwendung oder die bestehende Infrastruktur angepasst werden soll.

Die einzelnen Services sollten in jedem Fall sehr robust realisiert werden. Ein Service muss immer und in jedem Fall ansprechbar sein und er darf auf keinen Fall in einen undefinierten Zustand kommen.

Die Qualität einer Software-Architektur hat Einfluss auf die allgemeinen Systemeingenschaften, diese können in zwei Gruppen aufgeteilt werden:

Eigenschaften welche zur Laufzeit gemessen werden können:

  • Performance
  • Security
  • Availability
  • Usability
  • Robustness

und solche welche nur indirekt gemessen werden können:

  • Scalability
  • Integrability
  • Portability
  • Maintainability
  • Testability
  • Reusability

Grundsätzlich: Gutes Software Design == Gute Qualität von SOA

 

Die wichtigsten Prinzipien guten Software Designs sind:

  • Modularität: Komponenten sind leicht austauschbar. Dieses Prinzip unterstützt die Arbeitsteilung wie auch die Wartbarkeit des Systems. Es kann davon ausgegangen werden, das gut modularisierte Systeme besser in eine SOA überführt werden können, als solche welche schlecht modularisiert sind.
  • Portabilität: Portable Software nimmt weniger Rücksicht auf die Umgebungsspezfika und ist somit robuster gegenüber Veränderungen der Umgebung. SOA unterstützt die Portabilität auf der Ebene der standardisierten Serviceschnittstelle. Die Serviceschnittstelle ist eine URL und kann von jedem beliebigen Betriebssystem mit jeder beliebigen Technologie aufgerufen werden solange der Informationsaustausch über SOAP erfolgt. Die Service Implementation muss nicht portabel realisiert werden, obwohl portabel realisierte Implementationen meist stabiler sind.
  • Formbarkeit: Jedes System wird mit der Zeit verändert, je formbarer das System ist, desto leicht fällt die Änderung. Jedoch: Generisch != Formbar. Formbarkeit kann die Trennung von fachspezifischen Funktionen zu allgemeinen Systemfunktionen erreicht werden. Durch die Modellierung mit grafischen Tools kann meist eine gute Formbarkeit erreicht werden.
  • Konzeptionelle Integrität: Diejenigen Teile eines Systems welche ähnlich Funktionen beinhalten, sollte auch ähnlich gestaltet werden. Erkenntnisse aus der Forschung und Praxis sollten unbedingt in die Gestaltung eines Systems einfliessen.
  • Intellektuelle Kontrolle: Das System ist unter intellektueller Kontrolle, wenn alle Designer von der Qualität der Lösung überzeugt sind. SOA unterstützt dieses Prinzip mit der Tatsache, dass das System nicht mehr ganzen entworfen wird.
  • Herstellbarkeit: Ein Software Design muss ein Zielsystem so spezifizieren, dass es von einem gegebenen Team innerhalb einer gegebenen Zeit realisiert werden kann.

Kopplung und Kohäsion

Kopplung: …wird bestimmt durch die Abhängigkeit der Module untereinander

 

Kohäsion: …beschreibt die Wechselbeziehung zwischen einzelnen Elementen innerhalb eines Moduls

SOA setzt voraus, das Services lose gekoppelt sind und somit eine geringe Kohäsion aufweisen.

Die gute Service-Schnittstelle

Die Bedeutung der Gestaltung von Schnittstellen wird häufig unterschätzt, Namensgebung der Schnittstellen ist sehr wichtig. Eine gute Service Schnittstelle ist selbsterklährend und hat eine ausgereifte Fehlerbehandlung. Folgende Fehler tretten am häufigsten auf:

  1. mangelhafte Fehlerbehandlung, 15%
  2. unzureichende Umsetzung der durch die Schnittstelle spezifizierte Funktionalität, 13%
  3. mangelndes Postprocessing, 10%
  4. Änderung der Datenstruktur, 10%

Wahl des richtigen Schnittstellentyps

Typ Kurzerklährung Vorteile Nachteile
Method-Centric Interfaces Call & Return, RPC-ähnlich – nache an Funktions und Methodenaufrufen. – kleinerer Implementierungsaufwand bei der Kapselung bestehender Systeme. – viele verschiedene Services notwendig – nur für einfache Parameter geeignet
Message-Centric Interfaces Tauschen strukturierte Daten als Meldungen aus – für komplexe Parameter geeignet – Schnittstelle bleibt stabiler – nahe am Messaging eines ESB – Service-Beschreibung komplexer – Änderungen der Meldung sind nicht als Änderung der Schnittstelle sichtbar. – Implementierungsaufwand
Resource-Centric Interfaces nur http Methoden (GET, POST, PUT) Abstraktionsfähigkeit durch implizierte Realisierung der Funktion. Verständlichkeit

Weiterverwendung von Systemen

Services sind gut in sich abgeschlossene und weitgehend unabhängige Komponenten, insofern unterscheiden sie sich von bestehenden Systemen, so das eine Reihe von Erweiterungen notwendig wird. Der Aufwand lohnt sich jedoch trotzdem da:

  • Systeme sind bereits im Einsatz und müssen nicht erst angeschafft werden –> Kostenersparnis
  • Die Systeme haben sich bereits im Einsatz bewährt

Die bestehenden Systeme können weiterverwendet werden, es müssen standardisierte Service-Schnittstellen geschaffen werden. In der Praxis ist es sinnvoll, möglichst nahe an den bestehenden Systemen zu realisieren um möglichst wenig am bestehenden System ändern zu müssen.

Geeignete Systeme

Lebensdauer von betrieblichen Informationssystemen: 12-15 Jahre, folgende Phasen werden dabei durchlaufen:

  • Build
  • Maintenance: Achtung, keine Integration von neuen Technologien in dieser Phase
  • Migration
  • Modernization: Durchführung grösserer Änderungen. In jedem Fall günstiger als Migration

Definition Legacy Systeme:

 

Legagy-Systeme sind grosse Software-Systeme, von denen wir nicht wissen, wie wir mit ihnen fertigwerden sollen, die jedoch lebenswichtig für unsere Organisation sind.

Typische Eigenschaften:

  • Geschrieben in einer alten Programmiersprache wie COBOL, PL1 etc
  • Wurde gemäss Software Engineering Standards entwickelt, welche bereits vor 1968 bekannt wurden
  • verrichten lebenswichtige Aufgaben
  • generell sehr gross
  • schwer zu verstehen = schwer zu warten

Diese Arten von Systemen sind eher Kandidaten für eine Migration statt einer Modernisierung.

 

Andere Betrachtung von Legacy Systemen:

Legacy Systeme sind soziotechnische Systeme, das Legacy Software enthält. Es stellt also nicht einfach ein technisches System dar, sondern spiegelt die Art und Weise, wie ein Unternehmen zu einem bestimmten Zeitpunkt arbeitet, weil es ja diese Arbeit unterstützt. Dies ergibt folgende Konsequenzen:

  • Ein Legacy System besteht aus Legacy-Software und einem Kontext. Nur weil die Technologie veraltet ist, heisst das noch lange nicht, das der Kontext ebenfalls nicht mehr aktuell ist.
  • Jedes System wird nach seiner Einführung ein Legacy System –> Kandidat für Weiterentwicklung…

Legacy Systeme wie EVA Systeme (Eingabe – Verarbeitung – Ausgabe) können in der Regel am längsten verwendet werden und auch einfach in eine SOA integriert werden.

 

Folgende Grundregeln sollten bei der Weiterverwendung in einer SOA beachtet werden:

  • Jedes System wird nach dessen Einführung ein Legacy System, eine Einbindung in eine SOA verlängert lediglich den Lebenszyklus. Falls das System bereits Service Schnittstellen hat, wird eine Ablösung jedoch sehr viel einfacher.
  • Die zentrale Motivation der Weiterverwendung ist die Senkung der Kosten, nicht die Lösung aller Probleme. Aus diesem Grund sollten die Services möglichst nahe am bestehenden System realisiert werden.
  • Die Abbildung neuer Anforderungen geschieht nicht auf der Ebene der alten Anwendung, sondern auf der Präsentation-, Orchestration-,  Integration- und Service-Ebene einer SOA.
  • WSDL und SOAP ist Pflicht…
  • Es sollten nur diejenigen Systeme weiterverwendet werden, welche sich sehr einfach mit einem Service Interface versehen lassen.
  • Vorsicht bei der Weiterentwicklung von Standardsoftware, welche Pläne hat der Hersteller?

HIER gehts hoffentlich bald weiter….

1 3
2 3