Serviceorientierte Architektur (SOA)

Transkript

1 Serviceorientierte Architektur (SOA) Von der Geschäftsarchitektur zur IT-Architektur Folie 95

2 Geschäftsarchitektur (1) Zusammenhänge zwischen Strategie und Architektur Geschäft IT Anforderungen Geschäftsstrategie IT-Strategie Geschäftsarchitektur IT-Architektur (Anwendungslandschaft) Umsetzung (Geschäftsservices, Geschäftsprozesse, Geschäftsobjekte, Organisation etc.) Informationssystem- Architektur (IS) Architektur der technischen Infrastruktur (TI) Quelle: Quasar Enterprise Folie 96

3 Geschäftsarchitektur (2) Beschreibung der Architektur mit Hilfe standardisierter Architektur-Frameworks Beispiele: Zachman Framework TOGAF (The Open Group Architecture Framework) Integrated Architecture Framework (IAF) von Capgemini Quasar Enterprise von sd&m (abgeleitet aus IAF) Leitfaden für die Beantwortung beispielhafter Fragen Was sind die aktuellen und zukünftigen Geschäftsprozesse? Wie werden die Geschäftsprozesse durch die IT unterstützt? Welche Potentiale, ergeben sich für das Unternehmen aus der Umgestaltung von Geschäftsprozessen und der Anwendungslandschaft? Folie 97

4 Quasar Enterprise Landkarte von Quasar Enterprise mit Roadmap Quelle: Quasar Enterprise Folie 98

5 Begriffsdefinitionen (1) Geschäftsservice (business service) Ein Geschäftsservice stellt eine geschäftliche Leistung dar, die ein Servicegeber gegenüber Servicenehmern erbringt. Jedem Geschäftsservice liegt ein Vertrag zugrunde. Dieser legt die ein- und ausgehenden Informationen und Güter fest. Er beschreibt die durchzuführenden Schritte und ihre Reihenfolge. Die Schritte heißen Geschäftsserviceaktionen (business service actions) oder kurz Aktionen. Beispiele: Reisebüro - Verkauf von Pauschalreisen Bank Bearbeitung von Überweisungsaufträgen Folie 99

6 Begriffsdefinitionen (2) Geschäftsprozess Ein Geschäftsprozess (business process) ist eine funktions- und stellenübergreifende Folge von Schritten zur Erreichung eines geplanten Arbeitsergebnisses in einem Unternehmen. Diese Schritte heißen Geschäftsprozessaktivitäten (business process activities), kurz Aktivitäten. Beispiele: Reisebüro Schritte der Auftragsabwicklung für eine Pauschalreise Bank Einzelschritte einer Überweisungstransaktion Folie 100

7 Abgrenzung Geschäftsservice von Geschäftsprozess Geschäftsservices beschreiben die Außensicht eines Systems. Geschäftsprozesse beschreiben die Innensicht eines Systems. Außensicht des Systems erbracht durch Innensicht des Systems act Geschäftsprozess Pauschalreise verkaufen {Nutzungsvereinbarung} Service Verkauf Pauschal- Reise Flug reservieren Hotel reservieren Kunde Service Verkauf Individualreise Flug buchen Hotel buchen Bestätigung Folie 101

8 SOA als Brücke zwischen Geschäft und IT Geschäft Verantwortungsbereich IT z.b. ESB Aktivität Domäne verantwortet Integrationsplattform Abstraktion vernetzt verwendet verantwortet implementiert Logische AL-Komponente realisiert Physische AL-Komponente Enthält als Schritt Geschäftsservice erbracht durch automatisiert Anwendungsservice beschreibt bereitgestellt über exportiert z.b. SAP-CO exportiert Geschäftsprozess Service Beschreibung Logische Schnittstelle realisiert Physische Schnittstelle z.b. WSDL SOA-Brücke Abstraktion Folie 102

9 SOA-Vorstudie Überprüfen, ob das Geschäft eines Unternehmens so beschaffen ist, dass sich individuelle Serviceorientierung anbietet oder auf Standardsoftware zurückgegriffen werden kann. Gibt es Gestaltungsziele mit besonderer Priorität (z.b. Agilität)? Gibt es optimierte Prozesse, die beim Umbau auf Serviceorientierung ausgespart bleiben sollen (z.b. hochperformante Massendatenverarbeitung)? Ist das Unternehmen reif für die Serviceorientierung? Sind fachübergreifende Abstimmungen effektiv möglich? Stehen ausreichende Startbudgets zur Verfügung? Folie 103

10 Geschäftsarchitektur (1) Von Geschäftszielen zu Architekturleitlinien Ein Systemarchitekt benötigt Leitlinien, die er bei der Gestaltung der Geschäftsarchitektur berücksichtigen soll. Geschäftsziele Maximale Kundenzufriedenheit Abgeleitete Anforderungen Reduktion der Reklamationen Abgeleitete Leitlinien L Präventive Qualitätsverbesserung Detaillierte Leitlinien L L Überwachung der Qualität vor Ort Kundenbefragung Folie 104

11 Geschäftsarchitektur (2) Geschäftsservices der Ebene 1 = die intern und extern angebotenen Leistungen des Unternehmens, die es erbringt, um seinen Geschäftszweck zu erfüllen Kerngeschäftsservices Planung Einkauf Produktgestaltung Verkauf Abwicklung Unterstützende Geschäftsservices Rechnungswesen Berichtswesen Personalwesen Folie 105

12 Geschäftsarchitektur (3) Service-Ausschnitte verfeinern Analyse einzelner Service-Ausschnitte Verfeinerung der betrachteten Ausschnitte mit Blick auf die Ziele Beispiel: Individualreise verkaufen Wettbewerbs - fähige und wirtschaftliche Angebote Verkauf Gesicherte Zahlung Rechnungs- - wesen Sicher abwickelbare Aufträge Betrachteter Service - ausschnitt Individualreise verkaufen Pauschalreise Verkaufen genutzt von Zahlungsverkehr Zahlungs - verkehr Individualreise zusammenstellen Individualreise buchen Zahlung abwickeln Folie 106

13 Geschäftsarchitektur (4) Service-Ausschnitt funktional verfeinern Wettbewerbsfähige und wirtschaftliche Angebote Verkauf Gesicherte Zahlung Rechnungswesen Sicher abwickelbare Aufträge Betrachteter Serviceausschnitt Individualreise verkaufen Pauschalreise Verkaufen genutzt von Zahlungsverkehr Zahlungsverkehr Individualreise zusammenstellen genutzt von Individualreise buchen Individualreise buchen Zahlung abwickeln Leistungen empfehlen Leistungen selektieren Angebot individuell erstellen Verfügbarkeit prüfen Leistungen buchen Reiseauftrag pflegen Kunde pflegen Folie 107

14 Geschäftsarchitektur (5) Elementare Geschäftsservices fixieren Elementare Geschäftsservices werden von einer Rolle ausgeführt. Sie dienen dazu, den Ablauf eines Geschäftsservices exakt zu definieren. Leistungen empfehlen Leistungen selektieren Angebot individuell erstellen Verfügbarkeit prüfen Leistungen buchen Reiseauftrag pflegen Kunde pflegen Lager prüfen Lager buchen Kunde Mittler prüfen Mittler buchen Reiseberater Externer Mittler Reiseberater Folie 108

15 Geschäftsarchitektur (7) Geschäftsobjekte bestimmen Anhand der Informationen, die bei den einzelnen Geschäftsservices verarbeitet werden, lassen sich die Geschäftsobjekte ableiten Leistungen empfehlen Leistungen selektieren Verfügbarkeit prüfen Angebot Individuell erstellen Leistungen buchen Reiseauftrag pflegen Kunde pflegen Kundenwünsche inhaltliches Angebot inhaltlich abgestimmt. Angebot durchführbares Angebot bepreistes Angebot Reiseauftrag Kunde Leistungen Kombination von Leistungen Produkt Angebot Lieferant Folie 109

16 Gestaltung der Anwendungslandschaft Schrittweise Gestaltung Ebene 0: Die Anwendungslandschaft als Ganzes Ebene 1..n: Strukturierung in Domänen und Subdomänen Ebene n+1: Komponenten der Anwendungslandschaft Schnittstellen und Operationen Folie 110

17 Entwurf von Domänen (1) Domänen = Gruppierung von Komponenten einer Anwendungslandschaft nach fachlichen Gesichtspunkten Aufgabe von Domänen Festlegung von Verantwortungsbereichen Abbildung des Geschäfts eines Unternehmens Visualisierung einer Anwendungslandschaft ( Kartengrund ) Subdomänen Hierarchische Gliederung von Domänen Größe der AL Domänentiefe Anzahl Domänen Anzahl AL-Komponenten klein 1 < 10 < 30 mittel groß sehr groß >= 3 > 100 > Folie 111

18 Entwurf von Domänen (2) Mögliche Vorgehensweise für den Entwurf von Domänen Verschiede Aspekte einer Geschäftsarchitektur liefern Kandidaten Kerngeschäftsservices Verfeinerung nach Geschäftsdimensionen oder Teilservices Geschäftsobjekte Unterstützende Geschäftsservices der Ebene 1 Kerngeschäftsservices Planung Leistungseinkauf Produktgestaltung Verkauf Abwicklung Folie 112

19 Entwurf von Domänen (3) Verfeinerung nach Geschäftsdimension Die Verfeinerung nach Geschäftsdimensionen ist sehr individuell auf das Geschäft abgestimmt. Beispielhafte Geschäftsdimensionen: Kunden/Marken Produkte Kundenkanäle Produktgestaltung Produktgestaltung Pauschalreisen Kundenkanäle Reisebüro Produktgestaltung Individualreisen Internet Callcenter Folie 113

20 Geschäftsservices Entwurf von Domänen (4) Resultierende Domänen im Beispiel: Kundenkanal Reisebüro Internet Callcenter Planung Leistungseinkauf Produktgestaltung Pauschalreisen Produktgestaltung Individualreisen Verkauf Abwicklung Geschäftsobjekte Leistungsmanagement Kundenmanagement Reiseauftragsmanagement Unterstützungsprozesse Rechnungswesen Berichtswesen Personalwesen Folie 114

21 Entwurf von Anwendungsservices (1) Anwendungsservice = ein Geschäftsservice oder ein Teil davon, der mittels IT erbracht wird Identifikation von Anwendungsservices Geschäftsservices auswählen, die durch IT abgebildet werden sollen Kandidaten Analyse und Spezifikation der Kandidaten Anmerkung: In der Geschäftsarchitektur kann es Geschäftsservices geben, die nur manuell durchgeführt werden und nicht über IT abgebildet werden sollen bzw. können Folie 115

22 Entwurf von Anwendungsservices (2) Anwendungsservice spezifizieren (im Stil eines Use Case) Namensgebung Außensicht beschreiben Soweit erforderlich die Innensicht beschreiben Beispiel: Name Außensicht Servicenutzer Auslösendes Ereignis/Vorbedingungen Aktionen und Service-Protokoll Ergebnis/Nachbedingungen Nichtfunktionale Anforderungen Innensicht Prozess Leistungen empfehlen Reiseberater Kundenanfrage; Leistungskatalog liegt vor Kein Protokoll, da nur eine einzige Serviceaktion Ausgewählte Leistungen als inhaltliches Angebot Die Antwortzeit beträgt < 1 s Die Leistungen werden aus den Angeboten aller Lieferanten gewählt Folie 116

23 Entwurf von AL-Komponenten (1) AL-Komponente (Anwendungslandschaftskomponente) implementiert einen Anwendungsservice hat explizite und wohl definierte Schnittstellen für Operationen, die sie anbietet hat explizite und wohl definierte Schnittstellen für Operationen, die sie nutzt kann mit anderen AL-Komponenten gekoppelt werden AL-Komponenten sind in der Regel sehr umfangreich. Sie stellen nicht einzelne kleine Operationen sondern eine große Anzahl von inhaltlich zusammengehörende Operationen bereit. Beispiel: SAP-Modul Folie 117

24 Entwurf von AL-Komponenten (2) Kategorien (nach Quasar Enterprise) Bestand Funktion Prozess Interaktion Verwaltung von Datenbeständen IT-unterstützte Geschäftsservices mit algorithmischem Charakter IT-unterstützte Geschäftsprozesse Interaktion mit dem Anwender oder anderen Anwendungslandschaften Es gibt hier auch andere Kategorisierungen, die teilweise noch weiter verfeinert sind (z.b. von Thomas Erl). Folie 118

25 Entwurf von AL-Komponenten (3) Bestandskomponenten CRUD-Operationen (Create, Read, Update, Delete) Komplexe Pflegeoperationen für Geschäftsobjekte Views auf gespeicherte Geschäftsobjekte Berücksichtigung von fachlichen Konsistenzbedingungen Implementierung elementarer fachlicher Logik wie z.b. Buchung eines Umsatzes oder Historienführung Folie 119

26 Entwurf von AL-Komponenten (4) Funktionskomponenten Implementierung fachlicher Verfahren, z.b. Einplanung von Aufträgen, Erstellung von Abrechnungen Nutzung von Operationen weiterer Funktionskomponenten oder von Bestandskomponenten Folie 120

27 Entwurf von AL-Komponenten (5) Prozesskomponenten Unterstützung eines oder mehrerer Geschäftsprozesse Steuerung von Abläufen über verschiedene Funktions- und Bestandskomponenten hinweg Meist lang laufend Pausieren zwischen einzelnen Verarbeitungsschritten möglich Nutzung andere Prozesskomponenten sowie von Operationen von Funktions- und Bestandskomponenten Folie 121

28 Entwurf von AL-Komponenten (6) Interaktionskomponenten Anwenderzugang zu den Services einer Anwendungslandschaft Präsentation einer einheitlichen, kanalspezifischen Sicht (d.h. für unterschiedliche Plattformen und Endgeräte) Nutzung von Operationen beliebiger anderer Komponenten Folie 122

29 Entwurf von AL-Komponenten (7) Vorgehensweise 1. Anwendungsservices Domänen zuordnen 2. Anwendungsservices kategorisieren (Bestand, Funktion, ) 3. Kandidaten für Komponenten bilden 4. Komponentenschnitt verfeinern 5. Finalisieren Folie 123

30 Entwurf von AL-Komponenten (8) Domänenzuordnung und Kategorisierung Anwendungsservice Domäne Kategorie Individualreise verkaufen Reisebüro Interaktion Individualreise verkaufen Internet Interaktion Individualreise verkaufen Callcenter Interaktion Individualreise zusammenstellen Reisebüro Interaktion Individualreise zusammenstellen Internet Interaktion Individualreise zusammenstellen Callcenter Interaktion Leistungen empfehlen Produktgestaltung Individualreisen Funktion Leistungen selektieren Produktgestaltung Individualreisen Funktion Individualreise buchen Verkauf Prozess Verfügbarkeit prüfen Leistungsmanagement Prozess Lager prüfen Leistungsmanagement Bestand Leistung buchen Leistungsmanagement Prozess Lager buchen Leistungsmanagement Bestand Reiseauftrag pflegen Reiseauftragsmanagement Bestand Kunde pflegen Kundenmanagement Bestand Folie 124

31 Entwurf von AL-Komponenten (9) Kandidaten für Komponenten Zusammenfassung der Anwendungsservices einer Domäne und Kategorie Domäne Kategorie Anwendungsservices Komponentenkandidat Reisebüro Internet Callcenter Produktgestaltung Individualreisen Interaktion Individualreise verkaufen Individualreise zusammenstellen Interaktion Individualreise verkaufen Individualreise zusammenstellen Interaktion Individualreise verkaufen Individualreise zusammenstellen Funktion Leistungen empfehlen Leistungen selektieren Reisebüro-Buchung Reiseportal Callcenter-Buchung Individualreise- Konfigurator Verkauf Prozess Individualreise buchen Individualbuchungsprozess Leistungsmanagement Prozess Verfügbarkeit prüfen Leistung buchen Leistungsmanagement Bestand Lager prüfen Lager buchen Virtuelles Lager Lagermanagement Reiseauftragsmanagement Bestand Reiseauftrag pflegen Reiseauftragsmanagement Kundenmanagement Bestand Kunde pflegen Kundenmanagement Folie 125

32 Finale Anwendungslandschaft Legende Interaktion Bestand Funktion Prozess Quelle: Quasar Enterprise Folie 126

33 Entwurf von AL-Komponenten (10) Zusammenfassung der Regeln für den Entwurf von Komponenten Komponenten sollen eindeutig einer Domäne zugeordnet werden Komponenten sollen nach fachlichen Kriterien gebildet werden Alle Operationen einer Komponente sollen von genau einer Kategorie (Bestand, Funktion, Prozess, Interaktion) sein. Die Kopplungen zwischen AL-Komponenten unterschiedlicher Kategorien sollen einer Schichtung folgen Reihenfolge: Interaktion Prozess Funktion Bestand Keine zyklischen Kopplungen zwischen Komponenten Komponentenintern hohe Kopplung, zwischen Komponenten geringe Kopplung (das bedeutet nicht lose Kopplung!) Bestandskomponenten sollen Datenhoheit über die Geschäftsobjekte haben. Folie 127

34 Entwurf von Schnittstellen und Operationen (1) Schnittstellen Eine Schnittstelle fast Operationen zusammen Eine Schnittstelle wird spezifiziert durch einen eindeutigen Namen die Menge der zugehörigen Operationen ein Schnittstellenprotokoll im Sinne von Reihenfolgen und Restriktionen beim Aufruf der Operationen Operationen Operationen beschreiben das Verhalten von Komponenten Operationen werden spezifiziert durch Signatur: Name, Parameter, Rückgabewerte und deren Typen Semantik: Verhalten der Operation Nichtfunktionale Eigenschaften: Performance, Verfügbarkeit, etc. Folie 128

35 Entwurf von Schnittstellen und Operationen (2) Regeln für den Entwurf von Operationen Operationen sollen angemessen grobgranular sein Reduzierung der Komplexität Operationen sollen, falls fachlich sinnvoll und möglich idempotent sein mehrmaliger Aufruf mit denselben Parametern hat den gleichen Effekt wie der einmalige Aufruf Für alle Operationen sollen kompensierende Operationen angeboten werden, die deren Auswirkung fachlich rückgängig macht Operationen sollen minimales Wissen über den Aufrufkontext haben und auch möglichst wenige Annahmen darüber machen, z.b. Sessionkontext, Transaktionskontext, Batch-/Online-Betrieb Folie 129

36 Beispiele für Operationen Quelle: Quasar Enterprise Folie 130

37 Beispiele für Schnittstellen Quelle: Quasar Enterprise Folie 131

38 Serviceorientierte Archtitektur (SOA) Web-Services Folie 132

39 Eine Definition W3C-Definition A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Hier ist nicht die Rede von Mensch-Maschine-Interaktion. Benutzer (Menschen) nutzen Web Services nur mittelbar. Folie 133

40 Aufgaben von Web-Services (1) Aufgaben Aufruf von entfernten Prozeduren Übermittlung von Daten Beseitigung proprietärer Schnittstellen Beseitigung komplexer Kommunikationsprotokolle Herstellung einer losen Kopplung Reduktion der Herstellerabhängigkeit Folie 134

41 Aufgaben von Web-Services (2) Ausgangssituation RPC SUN-Server File-Transfer Windows-Server CICS Mainframe UNIX-Server Folie 135

42 Aufgaben von Web-Services (3) Transparente Kommunikation unabhängig von Hardware, Betriebssystem und Netzwerk SUN-Server SOAP Web- Service SOAP Windows-Server Mainframe SOAP UNIX-Server Folie 136

43 Aufgaben von Web-Services (4) Verbesserte Austauschbarkeit von Systemen Austausch von Web-Service-Providern Austausch von Web-Service-Consumern Web- Service Web- Service Web- Service Mainframe SUN-Server SUN-Server UNIX-Server UNIX-Server Windows-Server Folie 137

44 Grundlegende Standards für Web-Services Standards SOAP (Kommunikationsprotokoll) WSDL (Service-Beschreibung) UDDI (Verzeichnisdienst) Standardisierungsgremien W3C World Wide Web Consortium ( Web-Standards, z.b. XML, WSDL OASIS - Organization for the Advancement of Structured Information Standards ( erweiterte WS-Standards, z.b. WS-Security WS-I Web Services Interoperability Organization ( Standardprofile, z.b. Basic Profile Folie 138

45 SOAP (1) Technische Basis SOAP basiert auf XML Kommunikation in Form von SOAP-Messages Es gibt zwei Message-Typen SOAP-Request: Aufruf eines Service SOAP-Response: Antwort eines Service Standardisierte Struktur für Fehlermeldungen, die in einer SOAP- Response übermittelt werden (Fault Message) Aktuelle SOAP-Version 1.2 Folie 139

46 SOAP (2) Transport von SOAP-Nachrichten Grundsätzlich ist SOAP unabhängig vom Transportprotokoll In der Praxis wird fast immer HTTP verwendet Warum HTTP? Weit verbreitetes Standard-Protokoll Auf allen Plattformen verfügbar Einfach zu implementieren Firewall-freundlich (aber: Sicherheitsrisiko!) Nachteile von HTTP Synchrones Protokoll Folie 140

47 SOAP (3) Beispiel von Microsoft Quelle: So könnte eine SOAP-Kommunikationskette mit verschiedenen Transportprotokollen aussehen Folie 141

48 SOAP (4) Struktur einer SOAP-Nachricht SOAP-Envelope SOAP Header SOAP Body <SOAP-ENV:Envelope> <SOAP-ENV:Header> Kein zwingender Bestandteil der Nachricht Parameter, die die Kommunikation steuern Gegenstand vieler Erweiterungen des Standards, wie z.b. WS-Addressing </SOAP-ENV:Header> <SOAP-ENV:Body> Daten Funktionsaufrufe Funktionsparameter </SOAP-ENV:Body> </SOAP-ENV:Envelope> Folie 142

49 SOAP (5) Struktur eines SOAP-Request <soap:envelope xmlns:soap=" <soap:body> <x:transferfunds xmlns:x="urn:examples-org:banking"> <from> </from> <to> </to> <amount>100.00</amount> </x:transferfunds> </soap:body> </soap:envelope> Methode Aufrufparameter Es handelt sich um einen RPC-Style -Request, d.h. Aufruf einer Methode mit Parametern Folie 143

50 SOAP (6) SOAP im HTTP-Request POST /soap/handlefunds HTTP/1.0 Host: localhost:80 Content-Type: text/xml; charset=utf-8 Content-Length: 265 SOAPAction: "" HTTP <soap:envelope xmlns:soap=" <soap:body> <x:transferfunds xmlns:x="urn:examples-org:banking"> <from> </from> <to> </to> <amount>100.00</amount> </x:transferfunds> </soap:body> </soap:envelope> SOAP Folie 144

51 SOAP (7) Struktur einer SOAP-Response <soap:envelope xmlns:soap=" <soap:body> <x:transferfundsresponse xmlns:x="urn:examples-org:banking"> <balances> <account> <id> </id> <balance>33.45</balance> </account> <account> <id> </id> <balance>932.73</balance> </account> </balances> </x:transferfundsresponse> </soap:body> </soap:envelope> Rückgabewerte Folie 145

52 SOAP (8) SOAP-Styles (stark vereinfacht) Document style <soap:body> <m:purchaseorder xmlns:m="someuri">... </m:purchaseorder> </soap:body> RPC style <soap:body> <m:placeorder xmlns:m="someuri"> <m:purchaseorder>... </m:purchaseorder> </m:placeorder> </soap:body> Inhalt der Nachricht ist frei strukturierbar und muss durch Sender und Empfänger validiert werden, z.b. über ein XML- Schema. Verwendung eines Methodennamens Parameter können durch Standarddatentypen abgebildet und automatisch validiert werden. Im Standardschema sind bereits 40 Datentypen definiert. Folie 146

53 SOAP (9) SOAP-Header Wichtige Standardattribute encodingstyle Informationen, wie Daten in einer SOAP-Message serialisiert werden sollen role Spezifiziert Empfänger bzw. Zwischenstation, die dieses Header-Element verarbeiten darf mustunderstand Legt fest, ob ein Header-Element bei der Weiterleitung der SOAP-Message ausgewertet werden muss Individuelle Erweiterungen sind möglich Zahlreiche standardisierte Erweiterungen verfügbar, z.b. WS-Addressing, WS-Security Folie 147

54 SOAP (10) Beispiel für einen SOAP-Header <soap:envelope xmlns:soap=" <soap:header> <!-- security credentials --> <s:credentials xmlns:s="urn:examples-org:security" soap:mustunderstand="1"> <username>dave</username> <password>evad</password> </s:credentials> </soap:header> </soap:envelope> Das Beispiel stellt dar, dass der Empfänger dieser Nachricht die credentials <username> und <password> verstehen und auswerten muss. Folie 148

55 SOAP (11) SOAP-Fault <soap:envelope xmlns:soap=" <soap:body> <soap:fault> <faultcode>soap:receiver</faultcode> <faultstring>insufficient funds</faultstring> <detail> <x:transfererror xmlns:x="urn:examples-org:banking"> <sourceaccount> </sourceaccount> <transferamount>100.00</transferamount> <currentbalance>89.23</currentbalance> </x:transfererror> </detail> </x:transferfunds> </soap:body> </soap:envelope> <faultcode> und <faultstring> sind Pflichtinformationen <detail> ist optional Folie 149

56 SOAP (12) SOAP-Fault-Codes VersionMissmatch Ein Knoten (ein Kommunikationspartner in der gesamten Kommunikationskette) erwartet eine andere SOAP-Version MustUnderstand Ein Knoten kann eine Pflichtinformation im Header nicht auswerten DataEncodingUnknown Es sind Datentypen verwendet worden, die nicht in eine SOAP- Nachricht übersetzt werden konnten. Sender Die Nachricht konnte vom Sender nicht verarbeitet werden Receiver Die Nachricht konnte vom Empfänger nicht verarbeitet werden Folie 150

57 Message Exchange Patterns (1) Nachrichten werden in einer festgelegten Abfolge verschickt, sog. Message Exchange Patterns (MEP) Die wichtigsten Patterns sind: Request / Response One-Way Request / Callback Publish / Subscibe Folie 151

58 Message Exchange Patterns (2) Request / Response Consumer Provider request synchron response One-Way Consumer Provider request asynchron Folie 152

59 Message Exchange Patterns (2) Request / Callback Consumer Provider asynchron request Der Consumer benötigt eine Funktion zur Verarbeitung der Callbacks callback Publish / Subscribe Anmeldung für eine Dienstleistung Der Consumer benötigt eine Funktion zur Verarbeitung der Mitteilungen Consumer subscribe publish Provider Dienstleistung wird irgendwann erbracht. Folie 153

60 Message Exchange Patterns (3) Vergleichbare MEPs in der SOAP-Spezifikation In-Only: One-Way-Nachricht vom Consumer zum Provider Robust-In-Only: One-Way-Nachricht mit Eingangsbestätigung In-Out: Request mit erwarteter Response In Optional-Out: Request mit optionaler Response Beispiel: Robust-In-Only Stellt sicher, dass eine One-Way- Nachricht tatsächlich ankommt Doppelte Bestätigung erforderlich Consumer request confirm confirm Provider Folie 154

61 Servicebeschreibung (1) Beschreibung der Schnittstelle und Funktion eines Services Um Web-Services nutzen zu können, muss eine Beschreibung der Service-Schnittstelle vorliegen und bekannt sein, wie der Service aufgerufen wird. Beschreibung mit WSDL (Web Service Definition Language) Weit verbreitete Version 1.1, aktuelle Version 2.0 Eine WSDL-Datei enthält: Beschreibung der angebotenen Operationen Protokoll, mit dem der Service aufgerufen werden kann Adresse über die der Service erreichbar ist Anhand einer WSDL-Beschreibung kann automatisch das Gerüst einer SOAP-Nachricht generiert werden Folie 155

62 Servicebeschreibung (2) Struktur einer WSDL-Datei WSDL 1.1 WSDL 2.0 definitions types description types message port type operation input output interface operation input output binding binding service port verwendet service endpoint Folie 156

63 Servicebeschreibung (3) Bedeutung der einzelnen Elemente types Definition verwendeter Datentypen porttype bzw. interface Beschreibung der Operationen einer Schnittstelle binding Informationen über das zu verwendenden Protokoll service / port bzw. service / endpoint Adresse, unter der der Service erreichbar ist Quelle: Microsoft Nicht alle Informationen liegen zum gleichen Zeitpunkt vor. Folie 157

64 Servicebeschreibung (4) WSDL- Lebenszyklus Teil der WSDL-Datei Service-Schnittstelle Service-Detaillierung z.b. Types Protokollinformationen Adressinformationen Zeitpunkt der Integration Design, Entwurf Desing, Implementierung Implementierung, Systemkonfiguration Deployment Folie 158

65 Servicebeschreibung (5) Quelle: Josuttis, SOA in der Praxis Beschreibung eines Typs für den Aufruf Beschreibung eines Typs für das Ergebnis Folie 159

66 Servicebeschreibung (6) Aufzurufende Methode Aufruf- Parameter Ergebnis- Parameter Folie 160

67 Servicebeschreibung (7) Protokoll: SOAP mit HTTP MEP: Request / Response Adresse für den Aufruf Folie 161

68 Servicebeschreibung (8) Schwächen von WSDL WSDL ist primär für die technische Beschreibung des Services geeignet (Signaturen, Parameter, Adressen). Darüber hinaus gehende Eigenschaften wie z.b. Verfügbarkeit, Performance, Vor- und Nachbedingungen, Accounting, Zugriffsrechte sind nicht darstellbar. Verbesserungen in der Version 2.0 ermöglichen die semantische Erweiterung von WSDL-Dateien. Derzeit werden weitere Dokumente (DOC, PDF, EXCEL, ) für die Servicebeschreibung zur Verfügung gestellt. Folie 162

69 Verzeichnisdienste (1) Veröffentlichung von Service-Informationen über eine Registry 3. Servicebeschreibung übermitteln Registry 2. Service suchen 1. Servicebeschreibung veröffentlichen (WSDL) Service- Consumer 4. Servicedetails vereinbaren 5. Service nutzen Service- Provider Folie 163

70 Verzeichnisdienste (2) UDDI Verbreiteter Standard, derzeit Version 3.0 Speicherung von WSDL-Informationen und zusätzlichen Service- Beschreibungen Größter Schwachpunkt Detailinformationen zu Services werden nur unzureichend repräsentiert, z.b. Service Level Agreements (SLA) oder Sicherheitsanforderungen für komplexe SOA nicht geeignet Stattdessen Verwendung von sog. Registry/Repositorys wie z.b. ebxml, in dem detaillierte Informationen abgelegt werden können. Ein Verzeichnisdienst wird im Anfangsstadium einer SOA nicht zwingend benötigt, da Services noch überschaubar. Folie 164

71 Allgemeine Problemfelder für Web-Services Geschwindigkeit Durch Verwendung von XML viel Kommunikationsoverhead nicht für Kleinstoperationen nur eingeschränkt für performance-kritische Aufgaben Sicherheit Die Standardtechnologie beinhaltet keine Sicherheitsmechanismen. Diese müssen durch zusätzliche Maßnahmen realisiert werden. Management Regelung der Nutzung eines Service noch nicht vollständig gelöst Transparenz / lose Kopplung Kann aus technischen Gründen keine ausreichende Transparenz hergestellt werden, bringen Web-Services keinen Vorteil. Folie 165

72 REST (REpresentational State Transfer) Aufruf des Service über eine URL bzw. über die HTTP- Standardbefehle GET, POST, PUT, DELETE Alle Parameter sind in der URL bzw. dem HTTP-Request enthalten Keine Datentypisierung Format der Antwort ist beliebig (in der Regel aber XML oder JSON) Sehr einfach aufzurufen und zu nutzen Auswertung des zurück gelieferten Ergebnisses muss vollständig manuell codiert werden Folie 166

73 REST Beispiel Telefonsystemanbindung Abfrage einer Information über den Anrufer aus dem Verwaltungssystem zum Zweck der Anzeige in einem Telefonnotiz- Programm anhand der Telefonnummer Antwort in JSON { success: true, instances: [ { id: 112 kurzbezeichnung: "Unternehmensname: AEG, Zusatzbezeichnung: Vertrieb, Straße und Hausnummer: Exerzierstr. 11, Postleitzahl: 24582, Ort: Bissee, Bundesland: Schleswig- Holstein, Telefonnummer: , Telefaxnummer: , -Adresse: test@aeg.de, Kommunikation per ja, Kommunikation per Telefax: nein" }], morefound: false } Folie 167

74 REST Beispiel Schnittstelle Finanzbuchhaltung Übertragung von Buchungsdatensätzen aus einem operativen System an eine Finanzbuchhaltung mit Rückbestätigung des Empfangs Abfragen neuer und geänderter Debitoren mit einer GET-Abfrage Einzelbestätigung empfangener Debitorendaten mit GET-Abfragen Alternativ Sammelbestätigung aller Debitorendaten mit einem POST-Aufruf und JSON/XML-Daten Abfragen neuer Buchungssätze mit einer GET-Abfrage Einzelbestätigung der empfangenen Buchungssätze Alternativ Sammelbestätigung aller empfangenen Buchungssätze Folie 168

75 Alternative Web-Service-Technologien (1) XML-RPC Basiert ebenfalls auf XML Verwendet einfachere Strukturen Kennt nur wenige Datentypen Nicht standardisiert Nur für einfache Aufgaben geeignet Folie 169

76 Alternative Web-Service-Technologien (2) Spezialisierte Standards ebxml (enterprise business XML) als Erweiterung bzw. Ersatz für EDI im Industriebereich ACORD XML (Association for Cooperative Operations Research and Development ) Speziell für die Versicherungsbranche RosettaNet Speziell für Supply Chain Management Folie 170

77 Serviceorientierte Architektur (SOA) Enterprise Service Bus und Verzeichnisdienste Folie 171

78 Verzeichnisdienste (1) Serviceveröffentlichung und Servicediscovery mit einer Registry 3. Servicebeschreibung übermitteln Registry 2. Service suchen 1. Servicebeschreibung veröffentlichen (WSDL) Service- Consumer 4. Servicedetails vereinbaren 5. Service nutzen Service- Provider Folie 172

79 Verzeichnisdienste (2) UDDI (Universal Description, Discovery & Integration) Verbreiteter Verzeichnisstandard, derzeit Version 3.0 Vorläuferstandards noch im Einsatz Aufgaben Registrierung von WSDL-Informationen und Metadaten zu Services Recherchefunktionen für die Abfrage der WSDL- und Meta- Informationen Umsetzung Definierte Datenstrukturen Definierte API-Calls und die dazu gehörenden SOAP-Messages Folie 173

80 Verzeichnisdienste (3) UDDI-Strukturen Quelle: Erweiterungen in V3 subscription Möglichkeit, über Änderungen an Services informiert zu werden Folie 174

81 Verzeichnisdienste (4) Struktur der businessentity Die businessentity liefert Informationen über den Anbieter und dessen Angebot und ist evtl. der erste Einstieg, um einen Service zu finden. Wo gibt es weitere Informationen? Angebotene Services Suchbegriffe / Kategorien Quelle: UDDI Version 2.03 Data Structure Reference Folie 175

82 Verzeichnisdienste (5) Struktur des businessservice Der businessservice liefert allgemeine Informationen über einen Service und den Verweis auf das bindingtemplate. Allgemeine Information Verweis auf das binding Quelle: UDDI Version 2.03 Data Structure Reference Folie 176

83 Verzeichnisdienste (6) Struktur des bindingtemplate Das bindingtemplate liefert Informationen über die technische Erreichbarkeit des Services Adresse für den Service-Aufruf Quelle: UDDI Version 2.03 Data Structure Reference Detailinformationen über den Service Beispiel für accesspoint: Folie 177

84 Verzeichnisdienste (7) Struktur des tmodel Das tmodel liefert inhaltliche Informationen über Funktion des Services, z.b. die WSDL-Information. Kurzbeschreibung Detailinformationen über den Service Quelle: UDDI Version 2.03 Data Structure Reference Beispiel für overviewdoc: Folie 178

85 Verzeichnisdienste (8) Anmelden von Services Publishers API Erfordert Authentifzierung durch den Publisher Verwendung von SOAP über HTTPS Beispielnachricht für Registrierung eines Bindings (SOAP-Body) <save_binding generic="1.0" xnkbs="urn:uddi-org:api"> <authinfo>microsoft Corporation</authInfo> <bindingtemplate> <description xml:lang="en">production UDDI server, Publishing Interface</description> <accesspoint URLType="https"> <tmodelinstancedetails> <tmodelinstanceinfo tmodelkey="uuid:64c756d e00-ae83-ee12e38fae63"/> </tmodelinstancedetails> </bindingtemplate> </save_binding> Neben dem binding muss auch noch das tmodel veröffentlicht werden, auf das sich dieser Schlüssel bezieht Folie 179

86 Verzeichnisdienste (9) Abbildung von WSDL in UDDI WSDL-Struktur definitions types message port type tmodel name=[porttype local name] overvievurl = [wsdl location] categorybag type = porttype namespace = [namespace] tmodel name=[binding local name] overvievurl = [wsdl location] categorybag type = binding namespace = [namespace] porttype = [porttype tmodel] Protocol = SOAP Transport = HTTP binding service port businessservice name = [human-readable name] categorybag type = service namespace = [namespace] local name = [service local name] bindingtemplate accesspoint = [access point] porttype = [porttype tmodel] binding = [binding tmodel] local name = [port local name] Quelle: Using WSDL in a UDDI Registry, Version 2.0.2, Folie 180

87 Verzeichnisdienste (10) Abfragen des Verzeichnisses Browse Pattern Suche nach globalen Suchbegriffen und Verarbeitung der Suchergebnislisten (Zeitpunkt: Entwurf oder Implementierung einer Anwendung) Drill Down Pattern Suche mit exakten Datenstrukturschlüssel, z.b. ServiceKey (Zeitpunkt: Implementierung einer Anwendung) Invocation Pattern Suche des bindings und des tmodels eines bestimmten Services (Zeitpunkt: Implementierung einer Anwendung oder zur Laufzeit) Folie 181

88 Verzeichnisdienste (11) Nachricht um Daten zu einer Firma zu finden (SOAP-Body) Beispiele von <find_business generic="1.0" xmlns="urn:uddi-org:api"> <name>microsoft</name> </find_business> Antwort businesskey identifiziert den Anbieter von Services <businesslist generic="1.0" operator="microsoft Corporation" truncated="false" xmlns="urn:uddi-org:api"> <businessinfos> <businessinfo businesskey="0076b468-eb27-42e5-ac cff462a3"> <name>microsoft Corporation</name> <description xml:lang="en">empowering people through great software - any time, any place and on any device is Microsofts vision. As the worldwide leader </description> <serviceinfos> <serviceinfo businesskey="0076b468-eb27-42e5-ac cff462a3" servicekey="d2bc296a-723b-4c45-9ed4-494f9e53f1d1"> <name>uddi Web Services</name> </serviceinfo>... Liste angebotener Services Folie 182

89 Verzeichnisdienste (12) Nachricht, um einen Service einer Firma zu finden (SOAP-Body) <find_service generic='1.0' xmlns='urn:uddi-org:api' businesskey='0076b468-eb27-42e5-ac cff462a3'> <name>uddi Web Services</name> </find_service> businesskey in der Abfrage identifiziert den Anbieter Antwort <servicelist generic="1.0" operator="microsoft Corporation" truncated="false" xmlns="urn:uddi-org:api"> <serviceinfos> <serviceinfo businesskey="0076b468-eb27-42e5-ac cff462a3" servicekey="d2bc296a-723b-4c45-9ed4-494f9e53f1d1"> <name>uddi Web Services</name> </serviceinfo> </serviceinfos> </servicelist> servicekey identifiziert eindeutig einen Service Folie 183

90 Verzeichnisdienste (13) Nachricht, um Servicedetails abzufragen (SOAP-Body) <get_servicedetail generic='1.0' xmlns='urn:uddi-org:api'> <servicekey>d2bc296a-723b-4c45-9ed4-494f9e53f1d1</servicekey> </get_servicedetail> Antwort <servicedetail generic="1.0" operator="microsoft Corporation" truncated="false" xmlns="urn:uddi-org:api">... <bindingtemplates> <bindingtemplate bindingkey="313c2bf0-021d-405c fd969f7f0b" servicekey="d2bc296a-723b-4c45-9ed4-494f9e53f1d1"> <description xml:lang="en">production UDDI server, Publishing interface</description> <accesspoint URLType="https"> <tmodelinstancedetails> <tmodelinstanceinfo tmodelkey="uuid:64c756d e00-ae83-ee12e38fae63"> <description xml:lang="en">uddi SOAP Publication Interface</description> </tmodelinstanceinfo> </tmodelinstancedetails> </bindingtemplate>... servicekey in der Abfrage identifiziert den Service Liefert ein oder mehrere bindingtemplates, da ein Service mehrere Operationen anbieten kann Folie 184

91 Verzeichnisdienste (14) Defizite von UDDI V3 Die Meta-Informationen zu den Services werden nicht im Verzeichnis selbst abgelegt. Es gibt immer nur Verweise auf die Informationen. Zugriffsrechte nur sehr grob definierbar, feingranulare Einstellung teilweise aufwändig Eine Standardisierung der Taxonomie (categories) ist nicht durchsetzbar bzw. falsch Kategorisierung wird nicht unterbunden UDDI für einfache Infrastruktur hinreichend. Bei komplexen Infrastrukturen hat das Verfahren Grenzen. Stattdessen Verwendung von Registry Repositories möglich Folie 185

92 Verzeichnisdienste (15) Registry Repository Verwaltung von Services aus fachlicher Sicht Metainformationen werden im Gegensatz zu einer reinen Registry im Repository gespeichert. Neue Standards: z.b. ebxml-registry (OASIS/ISO-Standard) Herstellerspezifische Lösungen, z.b. WSSR von IBM Folie 186

93 Verzeichnisdienste (16) Alternative Lösungen Definiertes Verzeichnis im Filesystem, das Servicebeschreibungen enthält Webseiten, auf denen die Services dargestellt werden und auf die WSDL verwiesen wird Folie 187

94 Wiederholung zu Web-Services (1) Wesentliche Eigenschaften der Web-Services-Nutzung Nutzung von Web-Services über SOAP over HTTP WSDL-Beschreibungen von Services, die automatisiert verarbeitet werden können Hinterlegung der Servicebeschreibungen in Verzeichnisdiensten zur Abfrage bei Design und Laufzeit Ist damit das ursprüngliche Schnittstellenproblem gelöst? Nur TEILWEISE! Der Vorteil ist lediglich die Verwendung eines standardisierten Kommunikationsprotokolls. Folie 188

95 Wiederholung zu Web-Services (2) Wie sieht es mit der losen Kopplung aus? Keine lose Kopplung, da HTTP synchrones Protokoll Was ist mit Reduzierung der Schnittstellen? Kaum Reduzierung der Schnittstellen, da nach wie vor Punkt-zu- Punkt-Verbindungen Was ist mit Systemen, die man nicht direkt SOAPen kann? Adapter und Konvertierungsprogramme erforderlich Wie steht es mit der Sicherheit? Nur rudimentär bis überhaupt nicht gelöst Für komplexe IT-Landschaft braucht man eine Kommunikationsinfrastruktur, die diese Probleme vermindert. Folie 189

96 Enterprise Service Bus (1) Kommunikationsinfrastruktur Bei verteilten Systemen ist die nachrichtenorientierte Infrastruktur schon seit langem Standard Bisher waren die Lösungen in der Regel äußerst komplex und oft herstellerabhängig Der neue Ansatz setzt auf offene Standards und flexiblen Einsatz unterschiedlicher Technologien innerhalb der Infrastruktur Enterprise Service Bus (ESB) Grundsatz Alle Komponenten der Anwendungslandschaft kommunizieren nur über die Infrastruktur und nicht mehr direkt, wie z.b. bei Web-Services üblich. Folie 190

97 Enterprise Service Bus (2) Aufgaben eines ESB Inhaltsbezogenes Weiterleiten von Nachrichten (content based routing) Transformation von Daten Steuerung von Prozess-Schritten eines (Teil-)Geschäftsprozesses (service orchestration) Trennung der Transportlogik von der Schnittstellenimplementierung und der Anwendungslogik Monitoring von Schnittstellen und Geschäftsaktivitäten Sicherheitsfunktionen Sicherstellung eines Quality of Service Folie 191

98 Enterprise Service Bus (3) Ausgangslage Heterogene IT-Landschaft mit zahlreichen unterschiedlichen Schnittstellen Nicht alle Systeme können und sollen als Web-Services umgestaltet werden Aufgaben Schrittweise Umgestaltung der IT-Landschaft Punkt-zu-Punkt-Verbindungen der bestehende Anwendungen möglichst transparent durch die Infrastruktur austauschen Kommunikationsprotokoll vereinheitlichen Kommunikationssicherheit verbessern Quality of Service erhöhen Folie 192

99 SCM PoS Finance SFA Tracking SCM Enterprise Service Bus (4) Beispiel Quelle: D. Chapel, Enterprise Service Bus Theory in Practice IT-Landschaft mit unterschiedlichen Schnittstellentechnologien SOAP SOAP FTP Integration Broker Adapter Adapter CRM ERP CRM Zweigstellen Verkauf Back Office Externer Partner Folie 193

100 SCM PoS Finance SFA Tracking SCM Enterprise Service Bus (5) Veränderung der Einheit Verkauf Standard-Adapter FTP ESB WS Ad. Ad. SOAP Integration Broker Adapter Adapter Adapter CRM ERP CRM Zweigstellen Verkauf Back Office Externer Partner Individuelle Adapter Folie 194

101 SCM PoS Finance SFA Tracking SCM Enterprise Service Bus (6) Veränderung der Einheit Zweigstelle Verbindung mehrerer ESB ESB ESB WS Ad. Ad. Ad. Integration Broker Adapter Adapter Adapter CRM ERP CRM Zweigstellen Verkauf Back Office Externer Partner Folie 195

102 SCM PoS Finance SFA Tracking SCM Enterprise Service Bus (7) Veränderung der Einheit Back Office ESB ESB ESB WS Anbindung ganzer Infrastrukturlösungen Ad. Ad. Ad. Integration Broker Adapter Adapter Adapter CRM ERP CRM Zweigstellen Verkauf Back Office Externer Partner Folie 196

103 SCM PoS Finance SFA Tracking SCM Enterprise Service Bus (8) Einrichtung weiterer Web-Services nach Außen ESB ESB ESB Service für Anbindung des Partners WS WS Ad. Ad. Ad. Integration Broker Adapter Adapter Adapter CRM ERP CRM Zweigstellen Verkauf Back Office Externer Partner Folie 197

104 Enterprise Service Bus (9) Wichtige Aspekte eines ESB Mehrere ESBs können zu einem einzigen ESB verknüpft werden Innerhalb des ESB wird in der Regel ein einheitliches Kommunikationsprotokoll verwendet, in der Regel XML Der Datenaustausch muss über ein nachrichtenorientiertes Kommunikationssystem erfolgen, dass folgende wesentlichen Eigenschaften unterstützt: Sichere Zustellung von Nachrichten (reliable messaging) Synchrone und asynchrone Kommunikation Unterstützung verschiedener Message-Patterns Zwischenspeicherung von Prozesszuständen Anwendungen werden entweder über Standardschnittstellen (Standard-Adapter) oder individuelle Adapter angebunden. Folie 198

105 Enterprise Service Bus (10) Inhaltsbezogenes Weiterleiten von Nachrichten (content based routing) Daten sollen aufgrund bestimmter Dateninhalte unterschiedlich behandelt werden, z.b. werden Bestellungen von Auslandskunden an ein anderes CRM geschickt als Bestellungen von Inlandskunden Analyse der Dateninhalte durch X-Path-Querys Beispiel: <order> <customer> <name>google Inc.</name>... <country>usa</country>... </customer> <oderdetails>... </orderdetails> </order> Abfrage des Landes über X-Path-Ausdruck /order/customer/country Folie 199

106 Enterprise Service Bus (11) Transformation von Daten Passen eingehende Daten z.b. nicht zur Datenstruktur des Zielsystems, muss ein Mapping und ggf. Ergänzung der Daten vorgenommen werden Die Ergänzung der Daten kann durch Aufruf weiterer Services erfolgen z.b. die Ergänzung, welche Geolokalisationsdaten eine Adresse hat Bei XML-Nachrichten Verwendung von XSLT zur Transformation Beispiel: <address> <name>john Doe</name> <street>dungeon St. 10</street> <zip>123456</zip> <city>london</city> </address> street zip Transform Geocode longitude latitude <customer> <name>john Doe</name> <add>dungeon St. 10</add> <zip>123456</zip> <city>london</city> <long> </long> <lat> </lat> </customer> Folie 200

107 Enterprise Service Bus (12) Verminderung von Schnittstellen durch zentrales XML-Format Solange jede Einzelkommunikation zwischen Anwendungen individuell abgebildet wird, wird die Anzahl der individuell zu konfigurierenden Schnittstellen nicht geringer Abhilfe durch Schaffung eines firmenweiten XML-Dialekts, der die wesentlichen Dateninhalte definiert ( kanonisches XML ) Jede Nachricht wird vom ESB zunächst in dieses Format übersetzt und in dieser Form verschickt (Eingangstransformation). Der Empfänger entnimmt daraus die Informationen, die er braucht (Ausgangstransformation). Verringerung der Anzahl der individuellen Schnittstellen Verbesserte Übersichtlichkeit da Schnittstellen zentral definiert werden Evtl. Aufblähung des Datentransfervolumens und daraus resultierende Performanceprobleme Folie 201

108 Enterprise Service Bus (13) Steuerung von Prozess-Schritten eines (Teil-)Geschäftsprozesses (service orchestration) Die Schritte eines Geschäftsprozesses können über eine Abfolge von Services, die durch den ESB gesteuert werden abgebildet werden Verwendung von Business Rules Engines, die die Schrittfolge inhaltsbezogen steuern eine Nachricht triggert die nächste berücksichtigt keine Benutzerinteraktion Verwendung eines eigenen Orchestrierungsservice, der auch Benutzerreaktionen berücksichtigt Zwischenspeicherung von Prozesszuständen erforderlich (Persistenz erforderlich, z.b. XML-Storage) Mehr Details hierzu in Kapitel 7 der Vorlesung Folie 202

109 Enterprise Service Bus (14) Monitoring von Schnittstellen und Geschäftsaktivitäten Wichtige Schnittstellen müssen hinsichtlich Auslastung, Verfügbarkeit und Fehler ( Quality of Service) überwacht werden Für die Kostenrechnung könnte die Häufigkeit von Serviceaufrufen protokolliert werden Überwachung des Zustands von Geschäftsprozessen durch sog. Business Activity Monitoring (BAM) ESB Consumer Eingangstransformation Inhaltsbasiertes Routing Ausgangstransformation Provider Accounting Prozess- Zustand (XML-Store) Folie 203

110 Enterprise Service Bus (15) Sicherheitsfunktionen Sicherstellen, dass nur berechtigte Benutzer auf einen Service zugreifen Verwertung von Sicherheitsinformationen in der Nachricht ( WS-Security oder andere Methoden wie z.b. LDAP) Mehr Details hierzu in Kapitel 8 der Vorlesung ESB Consumer Prüfung der Berechtigung wenn berechtigt Inhaltsbasiertes Routing Provider LDAP Folie 204

111 Enterprise Service Bus (16) Sicherstellung eines Quality of Service Prüfung der Verfügbarkeit und Performance im Monitoring Vorrang für bestimmte Daten durch Priorisierung von Diensten Transparentes Routing zu Ersatzsystemen, wenn Services ausfallen Transparenter Verteilung der Last auf verschiedene Systeme Transparentes Hinzuschalten ergänzender Systeme, wenn die bestehenden Systeme die Last nicht mehr verarbeiten können Folie 205

112 Enterprise Service Bus (17) Hub & Spoke-Architektur versus verteiltes Routing Das Routing von Nachrichten kann entweder zentral oder dezentral gesteuert werden. Zentrales Routing bedeutet, dass für alle Nachrichten, die über den ESB geschickt werden, zentrale Instanzen die Routing- Entscheidungen treffen (sog. Hub & Spoke-Architektur). Hohe Belastung der zentralen Systeme evtl. unzureichende Skalierbarkeit Vorteil ist eine gute Kontrolle über das Gesamtsystem Beim dezentralen Routing (itinerary-based routing) enthält die Nachricht selbst die notwendigen (Routing-)Informationen, um zum nächsten Kommunikationspartner weitergeleitet zu werden. kein zentraler Engpass Optimierung der losen Kopplung Nachteil ist die verminderte Kontrolle über das Gesamtsystem Folie 206

113 Enterprise Service Bus (18) Wichtige Aspekte im Hinblick auf Web-Services Lösung des Synchronitätsproblems von HTTP Request-Nachrichten werden vom ESB akzeptiert und zwischengespeichert. Für den Consumer ist der Aufruf damit erledigt Der ESB sorgt dann dafür, dass die Nachricht zuverlässig an den Provider übermittelt wird reliable messaging Ermöglicht asynchrone One-Way-Nachrichten und damit auch Publish / Subscribe - Logik Entkopplung der Punkt-zu-Punkt-Verbindungen Zugangspunkte für die Web-Services sind nicht mehr die effektiven physischen Zugangspunkte der Services sondern Zugangspunkte des ESB Bereitstellung von fehlenden Funktionalitäten zur Zugriffskontrolle und Sicherheit Folie 207

114 Enterprise Service Bus (19) Demonstration ESB der ORACLE SOA-Suite Folie 208

115 Serviceorientierte Architekturen (SOA) Business Process Management Folie 209

116 Ausgangssituation Geschäftsprozesse Quelle: Reale Aufgaben und damit verbundene Tätigkeiten Beschreibung: Informell bzw. nicht dokumentiert z.b. durch Schulung und Anlernen halbformal dokumentiert, z.b. durch einfache Arbeitsanweisung formal dokumentiert, z.b. Ablaufplan für ISO-Zertifizierung formal und in elektronisch verwertbarer Form dokumentiert, z.b. mit Hilfe eines Modellierungswerkzeugs IT-Services und Anwendungen Bestehende Systeme und deren nach außen angebotene Services Folie 210

117 Ziel Matching von Geschäftsprozess und IT Geschäftsprozesse IT-gestützte Geschäftsprozesse IT-Services und Anwendungen Folie 211

118 Vorgehensweise (1) Top-Down Definition von Geschäftsprozessen und Entwicklung der dazu passenden IT-Services (siehe auch Kapitel 4) In komplexen IT-Umfeldern unrealistisch, da bereits viele Anwendungen vorhanden, die genutzt werden müssen/sollen Typischerweise Verwendung von Standardsoftware, die teilweise nicht zu den gewünschten Prozessen passt Bottom-Up Anpassung der Geschäftsprozesse auf Basis vorhandener Services und Anwendungen Gefahr, dass die Geschäftsstrategie nicht richtig abgebildet wird Gefahr, mit veralteten Methoden weiter zu arbeiten Folie 212

119 Vorgehensweise (2) Kombination aus Top-Down und Bottom-Up Was soll erreicht werden? Welche Services und Anwendungen sind bereits vorhanden? Was kann davon verwendet werden? Was muss neu gemacht werden? Welche technische Randbedingungen gibt es, z.b. nicht mehr modifizierbare Systeme? Welche Funktionen sollen wieder verwendbar sein? Kreativer, iterativer Prozess Folie 213

120 Business Process Management Systeme (BPMS) Referenzmodell der Workflow Management Coalition (WfMC) Folie 214

121 BPMS (2) Workflow- bzw. Prozess-Engines Verarbeitung von Prozessbeschreibungen Steuerung der angebundenen Dienste Speicherung von Prozesszuständen Überwachung und Protokollierung Was ist der Unterschied zwischen Prozess und Workflow? Ein Prozess beschreibt was geschehen soll. Ein Workflow beschreibt wie es durchgeführt wird. Diese Definition ist aber nicht durchgängig verwendet, so dass beides oft synonym verwendet wird. Folie 215

122 BMPS (3) Prozessbeschreibung (Process Definition) Ziel ist es, den Geschäftsprozess so zu beschreiben, so dass er sich auf einer Prozess- bzw. Workflow-Engine technisch ausführen lässt. Für die Beschreibung wurden verschiedene Standards entwickelt BPEL4WS BPEL4People BPML EPK/EPC XPDL UML Folie 216

123 BPMS (4) Schnittstellen für Client-Anwendungsprogramme Aufruf von Prozessen Statusabfrage Benutzerinteraktion Schnittstellen für die Anbindung aufgerufener Services Nachrichtenaustausch Mapping verschiedener Protokolle und APIs Session Management Folie 217

124 BPMS (5) Schnittstellen zu anderen Workflow-Engines Aufruf externer Prozesse Anbindung von externen Systemen Administrations- und Monitoring-Tools Benutzermanagement Rollenmanagement Protokollierung Ressourcenüberwachung Prozesszustände überwachen Folie 218

125 Modellierungssprachen (1) BPEL4WS bzw. WS-BPEL (Business Process Execution Language) Basierend auf XML Standardisierte Programmiersprache (OASIS-Standard) Modellierung entweder im XML-Code, in der Regel aber mit einer nicht standardisierten grafischen Notation BPEL ist in einer Workflow-Engine direkt ausführbar Breite Unterstützung in der Industrie XPDL (XML Process Definition Language) Standard der WfMC Wie BPEL direkt in Workflow-Engines ausführbar Standardisierte grafische Notation, Verwendung von BPMN Folie 219

126 Modellierungssprachen (2) BPML (Business Process Modeling Language) Basierend auf XML Standardisierte Modellierungssprache (OMG-Standard) BPMN (Business Process Modeling Notation) ist eine standardisierte grafischen Notation BPQL (Business Process Query Language) für Administration WSCI ( Web Services Choreography Interface) für Prozesssteuerung BPMN lässt sich auf BPEL abbilden UML (Unified Modeling Language) Standardisierte grafische Notation, aber nicht stringent auf Prozessmodellierung bezogen Abbildung auf Workflow-Engines problematisch Folie 220

127 Modellierungssprachen (3) Weitere Modellierungssprachen BPSS (Business Process Specification Schema) Modellierungssprache im Umfeld von ebxml EPK (Ereignisgesteuerte Prozesskette) Modellierungssprache im SAP-Umfeld und im ARIS-Konzept BPEL4People BPEL mit Berücksichtigung von Benutzerinteraktionen Folie 221

128 BPMN (1) Modellierungsobjekte Pools und Lanes (Verantwortungsbereiche) Events (Ereignisse) als Startpunkt zu beliebigen Zeitpunkten als Endpunkt Prozess, Sub-Prozess, Task Gateway Gateways erzeugen parallele Abläufe und fassen diese wieder zusammen Komplexe Entscheidungen Erzeugen und Zusammenfassen möglich Folie 222

129 BPMN (2) Sequence flow Abfolge innerhalb von Pools und Lanes Message flow Nur zwischen verschiedenen Pools bzw. Lanes verschiedener Pools Association Verbindung von Kommentaren oder Datenobjekten zu Elementen Datenobjekte Datenobjekte werden als Dokumente dargestellt und sind nur Annotation In eckigen Klammern kann ein Zustand angegeben werden Übersicht über alle Elemente unter Folie 223

130 BPMN (3) Beispiel Folie 224

131 Grenzen der Modellierung Modellierung berücksichtigt in der Regel keine nichtfunktionalen Anforderungen z.b. SLAs Komplexität steigt bei Berücksichtigung von Fehlerzuständen und deren Behandlung stark an Bei sehr komplexen Problemen, lassen sich nicht alle Aspekte adäquat abbilden Technische Details überfordern den Anwender in der Fachabteilung, der den Prozess aus Anwendungssicht definieren soll Zu grobe Beschreibungen aus Sicht der Anwender, sind nicht ausreichend, um die effektive Abbildung auf die technischen Services zu automatisieren Ohne exakte Kenntnis vorhandener Services ist die Modellierung evtl. nicht effizient genug Folie 225

132 Prozess-Orchestrierung versus Choreografie Prozess-Orchestrierung Zentrale Ablaufsteuerung aller Prozess-Schritte Gute Kontrolle über den gesamten Prozesse Evtl. schlecht skalierbar und Single Point of Failure Prozess-Choreografie Keine zentrale Ablaufsteuerung Jeder Service weiß, was er zu tun hat und welcher Schritt aus seiner Sicht als nächstes folgt Gut skalierbar und kein Single Point of Failure Prozesszustand ist schlecht kontrollierbar noch in der Entwicklungsphase Event Driven Architecture Folie 226

133 Verteilung von Anwendungslogik Die zentrale fachliche Logik sollte nur durch Funktions- oder Bestands-Services abgebildet werden. Prozess-Services sollen möglichst wenig fachliche Logik enthalten und nur die Koordination der erforderlichen Schritte nach definierten Regeln durchführen. Die Grenzen sind nicht immer ganz klar, da die Regeln für die durchzuführenden Schritte meisten auch eine gewisse fachliche Logik beinhalten. Prozess-Services müssen jedoch einen Prozesszustand verwalten. Folie 227

134 DB Bestand Funktion Prozess Beispiel: Bestellabwicklung Bestellung Kunde anlegen Auftrag anlegen Produktionsauftrag Rechnung Lieferung Produktionsprozess Kunden- Management Auftrags- Management Produktion Versand- Management read write read write read write read write Kundenmanagement Verkauf Produktion Logistik Folie 228

135 BPEL (1) Versionen von BPEL BPEL4WS 1.1 verbreiteter Standard WS-BPEL 2.0 seit 2007 Prinzipielle Struktur eines BPEL-Programms (Version 1.1) <process name="processname"> <partnerlinks>...</partnerlinks> <variable>...</variables> <correlationsets>...</correlationsets> <faulthandler>...</faulthandler> <compensationhandler>...</compensationhandler> <eventhandler>...</eventhandler> <!-- mindestens eine Activity --> </process> Folie 229

136 BPEL (2) DataHandling Ausdrücke Boolean Expressions Deadline-Valued Expressions Duration-Valued Expressions General Expression Variablen Ausdrücke mit Wahrheitswerten Ausdrücke mit Stichtagswerten Ausdrücke mit Zeitraumwerten Allgemeine Ausdrücke Temporäre Daten zur Auswertung der Geschäftslogik Typen: WSDL message type, XML Schema simple type, XML Schema element Wertzuweisungen Funktionen für Auswertung von Variablen, Eigenschaften oder Status von Verknüpfungen Folie 230

137 BPEL (3) Aktivitäten Invoke Aufruf von Services (synchron/asynchron) Receive Warten auf Aufruf und Ergebnisrückgabe mit reply Reply Rückmeldung von Ergebnissen Assign Wertzuweisungen Throw Auslösung von Fehlerereignissen Terminate Beendigung der Verarbeitung Wait wait for (warte Zeitspanne), wait until (warten bis) Empty Platzhalter Scope Gruppierung und Begrenzung der Fehlerausbreitung Compensate Fehlerbehandlung innerhalb eines Scopes Folie 231

138 BPEL (5) Kontrollstrukturen Sequence Folge von Aktivitäten While Wiederholung solange Bedingung gültig Switch Verzweigung Flow Parallele Aktivitäten Links Synchronisation von Aktivitäten Folie 232

139 BPEL (6) Prozessdefinion mit partnerlinks Bei der Modellierung der Prozesse wird auf die Schnittstellen von Services zugegriffen (Information aus WSDL). Die Schnittstelle ist im PortType festgelegt. Sollen evtl. mehrere gleichartige Services verwendet werden, z.b. Bestellung bei verschiedenen Lieferanten, könnten diese evtl. unterschiedlich benannte PortTypes aufweisen. Der BPEL-Prozess müsste für jeden PortType eine Regel verwalten. Da dies unkomfortabel und kompliziert ist, wird stattdessen ein partnerlink genutzt. Definition von partnerlinktypes in der WSDL, um PortTypes auf einheitliche Bezeichnung zu mappen. Durch Auswahl von Rollen wird der passende PortType gewählt. Folie 233

140 BPEL (7) Inhalt der WSDL <porttype name="soaorderbooking"> <operation name="initiate"> <input message="client:soaorderbookingrequestmessage"/> </operation> </porttype> <porttype name="soaorderbookingcallback"> <operation name="onresult"> <input message="client:soaorderbookingresponsemessage"/> </operation> </porttype> <plnk:partnerlinktype name="soaorderbooking"> <plnk:role name="soaorderbookingprovider"> <plnk:porttype name="client:soaorderbooking"/> </plnk:role> <plnk:role name="soaorderbookingrequester"> <plnk:porttype name="client:soaorderbookingcallback"/> </plnk:role> </plnk:partnerlinktype> Schnittstelle Schnittstelle Aliasname für alle Schnittstellen Abhängig von gewählter Rolle wird die tatsächliche Schnittstelle ausgewählt Folie 234

141 BPEL (8) Inhalt der BPEL-Datei <partnerlinks> <partnerlink name="client" partnerlinktype="client:soaorderbooking" myrole="soaorderbookingprovider" partnerrole="soaorderbookingrequester"/> </partnerlinks> name definiert einen Namen für den partnerlink partnerlinktype wählt den Partnerlink der WSDL myrole definiert die Rolle des Services in der Kommunikation, in diesem Fall SOAOrderBookingProvider partnerrole definiert die Rolle des Servicenutzers, in diesem Fall SOAOrderBookingRequester Folie 235

142 BPEL (9) Beispiele für BPEL-Engines ActiveBPEL Engine Oracle BPEL Process Manager Microsoft BizTalk Server Folie 236

143 Demonstration am Beispiel ORACLE Folie 237