Dr.-Ing. Iris Braun. Vorlesung "SOA Entwicklung verteilter Systeme auf Basis serviceorientierter Architekturen"

Transkript

1 Vorlesung "SOA Entwicklung verteilter Systeme auf Basis serviceorientierter Architekturen" 11. Entwicklung und Umsetzung

2 Gliederung Konzeption Abbildung von Geschäftsprozessen Entwicklung von Diensten Integration Frameworks zur technischen Umsetzung einer SOA ESB Enterprise Service Bus JBI Java Business Integration SCA Service Component Architecture Zusammenfassung Ausblick: Service Lifecycle, Management einer SOA Folie 2

3 Strategisches IT-Management Geschäftsmodell Geschäftsstrategie, mit der das Unternehmen am Markt bestehen will Produkte Produkte und Leistungen, die auf Basis der Geschäftsstrategie den Kunden angeboten werden Prozesse Geschäftsprozesse, die notwendig sind, um die Produkte und Leistungen für den Kunden zu erbringen Anwendungen Anwendungssysteme, die die IT-technische Umsetzung der Funktionalität der Geschäftsprozesse unterstützen IT-Infrastruktur IT-Infrastruktur (Hardware, Netzwerk, Betriebssysteme, Middleware), die zur operativen Nutzung der Anwendungssysteme notwendig ist Folie 3

4 Geschäftsprozesse im Internet Geschäftsprozess: Anzahl von Aktivitäten, die einen Mehrwert für den Kunden generieren Folie 4

5 Modellierung von Geschäftsprozessen Definierte Geschäftsprozess-Modellierung: Notwendig für die Zusammenarbeit von Business-Analysten und Softwareentwicklern Frühe Form: ER-(Entity-Relationship-)Diagramme Datenmodellierung, nicht für komplexe Prozesse geeignet Flussdiagramme: Darstellung als Abfolge von Aktivitäten Start Kunde E Flug anzeigen bucht R Preis OK Nein Start Sprung Ja Flug E Flug buchen Ende Folie 5

6 Modellierung von Geschäftsprozessen (2) Präzisere Notationen: basierend auf Petri-Netzen 1962 vom Mathematiker Carl Adam Petri vorgestellt Formales mathematisches Modell: gerichteter Graph Stellen (Places) und Übergänge (Transitions), die durch gerichtete Kanten verbunden sind Stellen können mit Marken belegt sein und eine Kapazität haben Mehrere Erweiterungen (verschiedene Marken, Zeit) komplex p1 p1 p3 p3 p2 t1 p2 t1 Folie 6

7 Modellierung von Geschäftsprozessen (3) Darauf basierende Notationen zur Modellierung: Aktivitäts-Diagramme in UML (Unified Modeling Language ) der Object Management Group (OMG) Zu eingeschränkt für die Modellierung komplexer Prozesse Yet Another Workflow Language (YAWL) Erweitert Petrinetze, relativ komplex Business Process Modeling Notation (BPMN) von BPMI.org Basiert auf Flussdiagrammen Mapping von BPMN auf BPEL Breite Unterstützung durch die Industrie Folie 7

8 Sicht der IT auf ein Unternehmen Unternehmen besteht aus Geschäftslogik und Anwendungslogik: Business Process Layer Business- Logik Services? Application Layer.NET- Anwendung JEE- Anwendung Legacy- Anwendung Anwendungs- Logik Folie 8

9 Zusammenhang Geschäftsprozesse - Dienste Schichtenmodell, aus Thomas Erl 2005: Business Process Layer Business- Logik Service Interface Layer Application Layer.NET- Anwendung JEE- Anwendung Legacy- Anwendung Anwendungs- Logik Folie 9

10 Klassifizierung von Diensten Business Process Layer Business- Logik Service Interface Layer Orchestrierungsdienste Business-Dienste Anwendungsdienste Application Layer.NET- Anwendung JEE- Anwendung Legacy- Anwendung Anwendungs- Logik Folie 10

11 Anwendungsdienste kapseln Anwendungslogik Typische Business Anwendungsdienste: Process Utility Services: generische, wie- Layer derverwendbare Funktionalität Bsp.: Load Balancing, Notification Wrapper Services: Funktionalität, die von Legacy-Anwendungen über eine Schnittstelle zur Verfügung Service gestellt wird Hybrid Interface Service: enthält Geschäftslogik Layer Business- Logik Orchestrierungsdienste Business-Dienste Anwendungsdienste Application Layer Anwendungs- Logik Folie 11

12 Business-Dienste Unterscheidung Business von Business-Diensten: Process Aufgabenzentriert: Dienst kapselt Geschäftslogik, wird benötigt wenn die Layer Logik nicht Teil der Orchestrierung ist Entitätszentriert: Dienst kapselt eine bestimmte business entity, z.b. eine Bestellung oder Rechnung Service Interface Layer Business- Logik Orchestrierungsdienste Business-Dienste Anwendungsdienste Application Layer.NET- Anwendung JEE- Anwendung Legacy- Anwendung Anwendungs- Logik Folie 12

13 Orchestrierungsdienste und Geschäftsprozesse Business Process Layer Business- Logik Service Interface Layer Orchestrierungsdienste Business-Dienste Anwendungsdienste Application Layer.NET- Anwendung JEE- Anwendung Legacy- Anwendung Anwendungs- Logik Folie 13

14 Rückblick: Orchestrierung in BPEL Client Partner Link porttype BPEL-Prozess receive invoke porttype Partner Link Web Service 1 invoke invoke porttype Web Service 2... reply Folie 14

15 Vorteile der Dienstklassifizierung Aufteilung ermöglicht unabhängige Weiterentwicklung von Geschäftsprozess-Logik und technologieabhängiger Anwendungslogik lose Kopplung Entwicklung der Anwendungslogik in Hinblick auf Service- Orientierung Geschäftsprozess-Logik lässt sich getrennt betrachtet leichter auf das Geschäftsmodell des Unternehmens abstimmen Agilität wird verbessert, indem Änderungen im Geschäftsprozess möglichst unabhängig von Implementierungen der Geschäftsund Anwendungslogik realisierbar sind (Ziel der Orchestrierung) Folie 15

16 Entwicklungsschritte einer SOA Serviceorientierte Analyse Serviceorientiertes Design Service-Entwicklung Service-Test Entwicklung von Service-Kandidaten für die Service Layers Entwurf der notwendigen Dienste Aspekte: Programmiersprache, Entwicklungsumgebung Sehr komplex, viele offene Fragen Service-Deployment Service-Administration Installation und Konfiguration Monitoring, Versionskontrolle, Wartung, Performance,... Folie 16

17 Analyse: Dienstmodellierung Grundlegende Schritte der serviceorientierten Analyse: 1. Umfang der Analyse festlegen Nur einzelne wiederverwendbare Dienste entwickeln oder vollständige Geschäftsprozesse auf Basis von Diensten? 2. Existierende Systeme identifizieren Welche davon können von Veränderungen betroffen sein? 3. Dienstkandidaten (service candidates) modellieren Geschäftsprozess zerlegen (z.b. mittels Flussdiagramm oder BPMN) Einordnen der einzelnen Operationen in logische Kontexte Wiederverwendbarkeit im Auge behalten Business-Analysten einbeziehen (für Business-Dienste) Folie 17

18 Design: Dienstentwurf Empfehlenswerte Vorgehensweise: Entitätszentrierte Businessdienste entwerfen Entities relativ unabhängig von anderen Diensten, bilden also gute Basis für deren Entwurf Anwendungsdienste entwerfen Abstraktion der technischen Umgebung, wichtigste Eigenschaft: Wiederverwendbarkeit Aufgabenzentrierte Businessdienste entwerfen Akkurate Abbildung der Geschäftsprozesslogik, Verwendung von Aktivitäts-/Sequenzdiagrammen üblich Geschäftsprozessdienste entwerfen z.b. mittels WS-BPEL Folie 18

19 Technische Umsetzung einer SOA: Überblick Process / Data Services, Orchestrierung, Komposition Standard-basierte Dienste Standard-basierte Dienste Packaged CRM Packaged ERP Custom MES Custom EJB Siebel SAP Mainframe SLA Wie sollte die Umsetzung aussehen? Zusätzliche Dienste? Folie 19

20 Technische Umsetzung einer SOA: Methoden Vorgehensweise Invocation (Aufruf) Methode Request- Response z.b. mit Java EE Mediation (Vermittlung) Vermittler Activation (Aktivierung) Komponenten Nachteile Fehlende Unterstützung für dynamische Integrations- Szenarien Kosten für die Vermittlung des Nachrichtenaustauschs, zentrale Koordination Bottleneck Folie 20

21 Enterprise Service Bus Ø Infrastruktur innerhalb einer SOA, über die Dienstanbieter und Dienstnutzer miteinander kommunizieren zentrale Eigenschaften eines ESB [Gartner Group]: Kommunikation via Message-oriented Middleware (MOM) z.b. JMS (Java Messaging Service) Konnektivität auf Basis von Web Services (SOAP, WSDL) Transformation von XML- und SOAP-Nachrichten inklusive Routing stellt weitere Fähigkeiten wie Sicherheits-, Single-Sign-On-, Registry- und Datenkonvertierungsdienste zur Verfügung Anforderungen: Unterstützung vieler Standardprotokolle = Integrationsfähigkeit Zuverlässiger Nachrichtentransport (über Messaging Middleware) Zentrale Überwachung weitere Features wie Skalierbarkeit, Transaktionsunterstützung, inhaltsbasiertes Routing, Adapter für alle gängigen Nachrichtenformate Folie 21

22 Enterprise Service Bus: Überblick Folie 22

23 ESB-Funktionen Funktionalität, die vom ESB angeboten wird: Kommunikationsinfrastruktur für Services (Messaging Middleware) Routing von Serviceanfragen und Auflösung von Versionskonflikten Datentransformation und mapping (Mediation) Service-Orchestrierung und -aggregation, Prozessmanagement Transaction Management Sicherheit Quality of Service, SLAs Service Registry und Metadatenverwaltung Erweiterbarkeit von Service Messages (semantisches Mapping) Monitoring und Management Unterstützung des Service Lifecycle (Deployment, Versionierung) Folie 23

24 Enterprise Service Bus: Beispiel App 1 App 2 lookup register App 3 CORBA JMS ESB Registry SOAP ESB Verteilung Infrastruktur Registry Komponentenarchitektur Orchestrierung Folie 24

25 JBI: Java Business Integration Begriff Enterprise Service Bus nicht standardisiert Angebote verschiedener Hersteller nicht kompatibel Java Business Integration: JSR-208 Ziele: Integrationsfähigkeit für Java Entwicklung eines Industriestandards Herstellerunabhängigkeit Aufbauend auf vorhandenen Standards Entwickelt durch viele Firmen, außer IBM und BEA Folie 25

26 JBI: Architektur JBI-Konzept lässt sich unterteilen in Service Engines: erweiterbare Geschäftslogik, z.b. EJB-Wrapper Binding-Komponenten: Proxy für Dienstnutzer und entfernte Dienste transportprotokoll-unabhängiger Zugriff Normalized Message Router: Versand und Routing von Nachrichten über einen Delivery Channel JBI Laufzeitumgebung Service Engine Normalized Message Router Binding-Komponente JBI Core Services Installation, Deployment, Lifecycle System Management Java-Umgebung Folie 26

27 JBI: Beispiel Orchestrierung (BPEL) Transformation (XSLT) J2EE Java App Normalized Message Router System Management WS-I Basic Profile (SOAP/HTTP) JMS SMTP CORBA J2EE-Umgebung Folie 27

28 JBI: Nachrichtenaustausch Umwandlung der protokollspezifischen Nachrichten in unkodierte Dokumente und zugehörige Metainformationen wie protokollspezifischer Kontext, Transaktionsinformationen usw. Client Nachricht HTTP/ OK soap env Dok SOAP Binding Komp. Nachrichtenaustausch Austausch-Nummer Normalisierte Nachricht war mal soap1.1 Dok Austausch# vonaddr nachaddr Dienst- Nutzer (extern) HTTP- Header SOAP- Header Payload (kodiert) erzeugt Nachrichten- Austausch Payload (unkodiert) Nachrichten- Metadaten Austausch- Metadaten Folie 28

29 JBI: Nachrichtenaustausch: Beispiel In-Out Basierend auf WSDL-2.0-Nachrichtenaustauschmuster JBI-Container SE NMR BC Dienst- Aufruf in-out +req Routing in-out +req Anfrage senden Fehlerbehandl. in-out +fault Routing in-out +fault Fehlerempfang Antwort verarb. in-out +resp Routing in-out +resp Antwortempfang SE: Service Engine NMR: Normalized Message Router BC: Binding Component Dienstanbieter Folie 29

30 JBI: Normalized Message Router Aufgaben des Normalized Message Router (NMR): Interoperabilität der Komponenten Routing der Nachrichten zu den passenden Endpunkten Austausch normalisierter Nachrichten (Payload + Metadaten) BC DeliveryChannel NMR DeliveryChannel SE Versand / Empfang Gebundene Nachrichten Protokoll, Kodierung, Transport Endpunkt ermitteln, (De-) Normalisierung Richtigen DC auswählen Normalisierte Nachrichten Abstrakter Payload + Metadaten Verarbeitung, Antwort Folie 30

31 JBI: Komponentenmanagement Portables Management und Administration Standard-Deskriptoren Standard-Packaging Verwendung von JMX (Java Management Extensions) für die Installation Deployment-Deskriptoren für Service Unit: High-Level-Beschreibung der Dienste, die von einer Komponente angeboten oder genutzt werden Service Assembly: Menge von Service Units und deren Verbindungen Folie 31

32 JBI: Zusammenfassung Infrastruktur zur Umsetzung von serviceorientierter Architektur Vendor Diversity Kunde ist nicht an einen Anbieter gebunden Unterstützung von Java SE, Java EE, WSDL 1.1 & 2.0, WS-I Basic Profile, JMX (Java Management Extensions) Nicht spezifiziert: Verteilung / Kopplung einer JBI-Umgebung Anbindung einer externen Registry Folie 32

33 SCA : Service Component Architecture Ziel der Service Component Architecture (SCA): Integration verschiedener serviceorientierter Architekturen Reduzierung des Aufwands bei der Entwicklung der Infrastruktur Vergleich mit JBI: Nicht Java-spezifisches, metadaten-basiertes Modell zur Komposition von Diensten Verteilte objektorientierte Anwendung Eng gekoppelte Sammlung aus Objektkomponenten, Interaktion über technologiespezifische Protokolle Verteilte serviceorientierte Anwendung Lose gekoppelte Zusammensetzung aus Servicekomponenten, technologieunabhängige Interaktion Folie 33

34 Existierende Komponentenmodelle + Integrierter Web- Services-Support - Komplex, steile Lernkurve - Viele technische APIs - Sprachabhängig JEE SCA + Sprachneutral - Keine standardisierte WS-Unterstützung - Zu komplex WS-* + Sprachneutral - Unabhängig vom Programmiermodell - Kein einheitliches Deployment-Modell + Weniger komplex - Entfernte Komponenten nicht unterstützt - Sprachabhängig + Viele Kommunikationsmöglichkeiten - Plattformabhängig - Kein Kompositions- Modell Folie 34

35 SCA: Überblick Erster Entwurf im November 2005, Veröffentlichung durch die Open SOA Collaboration (osoa.org) im März 2007 Zur Standardisierung an OASIS übergeben SCA definiert Syntax und Semantik für Konstruktion von Diensten (Implementation) Verbindung von Komponenten zu einem Prozess (Assembly) Deployment in ein Gesamtsystem (Activation) Folie 35

36 SCA: Spezifikationen und Abhängigkeiten Externe Spezifikationen W3C WS-Policy W3C WS-Policy Attachment Generische Spezifikationen (Technologieneutral) SCA Assembly Model SCA Policy Framework SDO (Service Data Objects) Technologieoder sprachabhängige Spezifikationen SCA Client + Impl. Model Java SCA Client + Impl. Model C++ SCA Client + Impl. Model BPEL SCA Binding Web Services SCA Binding for JMS Folie 36

37 SCA: Komponenten Komponenten repräsentieren Business-Funktionen Konfigurierte Instanz einer Implementation (beliebige Sprache) Funktion wird anderen Komponenten über Services angeboten Abhängigkeiten von anderen Komponenten über References Properties: Eigenschaften, die die Ausführung der Komponente beeinflussen können Folie 37

38 SCA: Kompositionen Fest verkoppelte Zusammensetzung von Komponenten, Referenzen, Diensten, Verbindungen und Eigenschaften Komponenten über verschiedene Technologien implementierbar XML-Konfigurationsdatei enthält strukturelle Details Folie 38

39 SCA: Vollständiges System Folie 39

40 SCA: Vorteile und Nachteile Vorteile: Trennung von Komponenten-Implementierung und Dienstnutzung Flexibilität und Wiederverwendbarkeit von Kompositionen Unabhängigkeit von Implementierungstechnologien Kein Vendor-Lockin (Abhängigkeit von einem Anbieter) Einfachere und schnellere Anwendungsentwicklung Nachteile: Nicht ausreichende Quality-of-Service-Unterstützung Unklarheiten in Teilen der Definitionen Keine Wiederverwendbarkeit von Kompositionsbestandteilen Apache-Implementierung Tuscany noch unzuverlässig und schlecht dokumentiert Folie 40

41 Produkt Beispiel: WebSphere IBM ESB Messag ing MQ interoperability J MS 1.1 Web S p h ere E n terp ris e S erv ic e B u s C ++ C lient C lients J ava and C /C ++ Web S ervices C lient Mediation Function.N ET- C lient WebS phere Integ ration Developer C ustom Mediation Messag e L og g er X S L T Messag e Router DB L ookup WebS phere A dapter S upport Web S p h ere A p p lic atio n S erv er Tivoli A ccess Manag er Edg e C om ponents U DDI DB2 U niversal Database Web S ervices G ateway S OA P/ HTTP S OA P/J MS S DO WS - * Web S ervices U DDI Reg istry 3.0 S C A S MO S C A Prog ram m ing Model Folie 41

42 WebSphere IBM ESB Mediation-Konzept Mediation Module Mediation Flow C om ponent S ervice C onsum er Exports Interfaces Request Flow Mediation Mediation Primitive Primitive Mediation Flow Partner References Im ports S ervice Prov ider S C A C lient S tand- A lone References Response Flow Mediation Mediation Primitive Primitive S ervice Prov ider Mediation Module: SCA-Komponente für die Mediation von Service-Aufrufen beinhaltet eine Mediation Flow Component und/oder mehrere Java- Komponenten Mediation Flow besteht aus Abfolge von Mediations-Primitiven (Formatumwandlung, Filterung, Logging, Fehlerbehandlung), jeweils für Request und Response getrennt Folie 42

43 Zusammenfassung Entwicklung der Anwendungen anhand der Geschäftsprozesse 1. Serviceorientierte Analyse der Geschäftsprozesse 2. Design der Anwendung, Identifikation der Business-Dienste 3. Design und Entwicklung der Anwendungsdienste 4. Deployment der Dienste, Bereitstellung der Infrastruktur 5. Kopplung der Dienste zu Geschäftsanwendungen 6. Wartung, Administration der Anwendungen und der einzelnen Dienste -> Service Lifecycle Management Schwierigkeit ist die geeignete Zerlegung der Prozesse und die Identifikation der Dienste -> mehrstufiger Prozess Technische Umsetzung einer SOA: Infrastruktur zum Nachrichtenaustausch, zur Dienstkomposition und Dienstverwaltung Beispiele: ESB, JBI, SCA Folie 43

44 Ausblick: Management einer SOA Aufgaben des Service Lifecycle Management/Service Governance: Standardisierung des Service Portfolio Vereinfachung und effizientes Management von Anforderung Genehmigung Bereitstellung Nachverfolgung Verrechnung von Diensten Probleme: Nutzung fremder Dienste Lose Kopplung Folie 44