Service-Orientierte Architekturen

Transkript

1 Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 2: Einführung in Service-Orientierte Architekturen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda

2 (Vorläufiger) Aufbau der Vorlesung Kapitel Thema 1 Organisation, Einführung in Software-Architekturen 2 Einführung in Service-Orientierte Architekturen 3 Design Prinzipien von Service-Orientierten Architekturen 4 Web Services I (SOAP, WSDL) 5 Web Services II (UDDI, WS-Policies, Axis2) 6 Modellierung von Geschäftsprozessen (BPEL, BPMN) 7 Vertiefung Web Services (BAM, BPEL4People,...) 8 OSGi Service Plattform 9 Einführung in Swordfish 10 REST Architekturen 11 (22.6.) Exception Handling in SOA (Gastvortrag) 12 (29.6.) SOA Point of View von Accenture (Gastvortrag) Folie 2

3 Ziele dieser Veranstaltung Vermittlung der Grundlagen von Service-Orientierten Architekturen ohne Fokus auf eine bestimmte Technologie zur Umsetzung Service-Orientierung: Small View vs. Big View Kennenlernen von wichtigen Entwurfsprinzipien Folie 3

4 Definition Software-Architektur Eine Software-Architektur beschreibt die Dekomposition eines Software- s, die den Vorgaben eines zugehörigen Architekturstils genügt. Die Architektur-Beschreibung umfasst folgende Bestandteile: die grundlegenden Architektur-Elemente die Interaktionsbeziehungen zwischen den Architektur-Elementen die strukturellen und operativen Architektur-Direktive der Gesamtarchitektur die charakterisierenden Kennzahlen der Gesamtarchitektur Folie 4

5 Erläuterung des Begriffs Software Architektur Architektur-Elemente Meta-Modell Die Architektur-Elemente einer Architektur bestehen im Wesentlichen aus Subsystemen sowie Modulen, Interfaces und Interface-Objekten. Meta-Modell eines Architekturstil: Subsystem Design 1 0..n Module Design 1 0..n 0..n Interface Design isimplementedby Interface-Objekt Design Ein Metamodell ist ein Modell, das beschreibt, wie Modelle gebaut werden. Hier: ein Architekturstil! Folie 5

6 Gliederung dieser Veranstaltung Kapitel 2: Einführung in Service-Orientierte Architekturen 1 Kurze Wiederholung 2 Service-Orientierung als Architekturstil (Small View) 3 Service-Orientierung aus Unternehmenssicht (Big View) 4 Klassifizierung von Services 5 Qualitätsmerkmale von Services 6 Enterprise Service Bus 7 Zusammenfassung und Ausblick Folie 6

7 Was ist eigentlich SOA? SOA (Service-Oriented Architectures) ist ein Architekturstil für Software-Architekturen, mit dem Ziel, komplexe e, Software- Anwendungen, betriebliche Funktionen und Prozesse zu integrieren (Enterprise Application Integration, EAI) SOA umfasst eine Reihe von Richtlinien, Best Practices, Standards, Tool- Empfehlungen, Frameworks und Entwicklungsprozesse Kapselung von Ressourcen als Services, die über das Netzwerk (Internet und Intranet) verfügbar sind ( Verteilte Architektur) Achtung: SOA ist kein Produkt, das man (ver)kaufen kann

8 Definition einer Service-Orientieren Architektur SOA ist ein Architektur-Paradigma für den Umgang mit Geschäftsprozessen, die über eine große Landschaft von existierenden und neuen heterogenen en verteilt werden, wobei die e unterschiedliche Eigentümer haben [Josuttis, 2008] SOA ist ein Architekturmuster, das den Aufbau einer Anwendungslandschaft aus einzelnen fachlichen, d.h. geschäftsbezogenen Komponenten beschreibt. Diese sind lose miteinander gekoppelt, indem sie einander ihre Funktionalität in Form von Services anbieten [Hess et al., 2006] Folie 8

9 Definition des Begriffs Service Services sind eine IT-Repräsentation von fachlicher Funktionalität, die durch eine wohldefinierte Schnittstelle beschrieben werden (...). [Josuttis, 2008] Services realisieren Geschäftsfunktionen, die sie über eine implementierungsunabhängige Schnittstelle kapseln. Zu jeder Schnittstelle gibt es einen Servicevertrag, der die funktionalen und nicht-funktionalen Merkmale (Meta-Daten) der Schnittstelle beschreibt. Die Nutzung (und Wiederverwendung) von Services geschieht über entfernte Aufrufe [Starke und Tilkov, 2007] Services werden durch Service-Beschreibungen (service description) syntaktisch und semantisch beschrieben und können dadurch in einer Infrastruktur veröffentlicht werden. Folie 9

10 Architekturstil einer Service-Orientieren Architektur Return possible- Services Service Registry Discover aservice Publish aservice Service Consumer [RequestDescription aservice ] Service Bind / Interaction Service Provider Service aservice Ein Service Provider (Anbieter) ist ein Subsystem, das einen Service implementiert, so dass andere e diesen aufrufen können Ein Service Consumer (Nutzer) ist ein Subsystem, das einen Service aufruft und diesen nutzt (z.b. im Kontext eines Geschäftsprozesses) Eine Service Registry (Verzeichnis) ist ein Subsystem, welches Services zwischen einem Service Provider und Service Consumer vermitteln kann Folie 10

11 Definition des Begriffs Service Erweiterung des Meta-Modells eines Architekturstils Services knüpfen an das Interface eines Subsystems an: Subsystem Design 1 n Module Design 1 n Interface Design isimplementedby 0..n InterfaceObject Design Service isspecifiedby isimplementedby ServiceHandle isdescribedby ispublishedwith ServiceDescription Folie 11

12 Definition des Begriffs Service Erweiterung des Meta-Modells eines Architekturstils Services knüpfen an das Interface eines Subsystems an (Java): Subsystem Module 1 n (= Package) Design (= Class) Design 1 n Interface InterfaceObject isimplementedby Design (= Interface) Design (= Class, Handle) Service isspecifiedby (= kein direktes Pendant, z.b. Web Services) isimplementedby isdescribedby ispublishedwith ServiceHandle ServiceDescription (= kein direktes Pendant, z.b. WSDL) Folie 12

13 Aufbau eines Service Die Architektur-Elemente Subsysteme, Module, Interfaces und Service werden oft durch die Verwendung des Facade Pattern [Gamma, 1996] realisiert: Beispiel: Subsystem eines Compiler Service Service: Compiler Method: compile Description: This is a compiler ServiceDescription Subsystem Compiler Interface Compiler compile() InterfaceObject = Service Handle CodeGenerator create() Lexer gettoken() Module Parser createparsetree() Optimizer create() Folie 13

14 Aufbau eines Service In der Praxis werden Services meist auf Basis von Software-Komponenten realisiert Beispiel: Subsystem eines Compiler Komponente Service (Provided) Interface Compile-Interface Service: Compiler Method: compile Description: This is a compiler ServiceDescription <<component>> Compiler Compile-Interface <<servicehandle>> Compiler <<component>> Lexer InterfaceObject = Service Handle <<component>> CodeGenerator <<component>> Parser <<component>> Optimizer Module Folie 14

15 Modellierung eines Service UML bietet keine Möglichkeiten, Services zu direkt modellieren Häufig mit der Verwendung von Stereotypen. Beispiel: <<service>> Compiler Provided Interface ( Compile-Interface ): public Code compilecode( Code ); Komponente <<component>> Compiler Compile-Interface <<interfaceobject>> Compiler <<component>> Lexer InterfaceObject = Service Handle <<component>> CodeGenerator <<component>> Parser <<component>> Optimizer Module Folie 15

16 Gliederung dieser Veranstaltung Kapitel 2: Einführung in Service-Orientierte Architekturen 1 Kurze Wiederholung 2 Service-Orientierung als Architekturstil (Small View) 3 Service-Orientierung aus Unternehmenssicht (Big View) 4 Klassifizierung von Services 5 Qualitätsmerkmale von Services 6 Enterprise Service Bus 7 Zusammenfassung und Ausblick Folie 16

17 Typisches Szenario einer verteilten Architektur in einem Unternehmen Oracle DB2 SAP 2.0 FI Billing Siebel Archive CO Mail Server Siebel FI Banking Software MM Billing 2 Web Frontend Intercompany Module Sub-Tochter (eignes Intranet) SAP Netweaver BI Solution FI Workflow External Partner (Bank) Banking Software Externe Betreiber External Partner (Kunde) CR Software Folie 17

18 Typisches Szenario einer verteilten Architektur in einem Unternehmen Oracle DB2 SAP 2.0 FI Billing Siebel C++ Archive C FTP CO Mail Server HTTP Siebel FI Java Banking Software Java TCP-IP RMI MM Billing 2 Web Frontend Java Cobol Intercompany Module C++ Sub-Tochter (eigenes Intranet) SAP Netweaver BI Solution HTTP FI Workflow C External Partner (Bank) Banking Software External Partner (Kunde) CR Software Folie 18

19 Ziel einer verteilten Architektur aus Unternehmenssicht Ziel einer verteilten Architektur aus Unternehmenssicht: IT-seitige Unterstützung von (möglichst vielen!) Geschäftsabläufen: Integration einzelner Tätigkeiten wie Buchungen, Archivierung von Daten, Weiterleitung von Dokumenten und Arbeitsanweisungen, Verifikation... Ansatz SOA: Kapselung von bestehenden (technischen) Applikationen durch (fachlich definierte) Services Formulierung von höherwertigen Geschäftsprozessen auf Basis von fachlichen Services Folie 19

20 Ziel: Flexible Integration der verschiedenen Subsysteme über fachlich definierte Services und Prozesse Business Processes (IT-unterstützte Geschäftsprozesse) Prozess Archivierung von Rechnungen Business Services (Geschäftsfunktionen, fachliche Services) Service Pflege von Rechnungen Service CRM Archiv Service PDF : printinvoice( Invoice) Invoice: getinvoice( Client ) removeclient( ID ) getclient( ID ) savepdf( pdf) Applikationen (Alt-e, Legacy) SAP 2.0 FI CO Sub-Tochter (eignes Intranet) SAP Netweaver Oracle Siebel Siebel FI MM FI Mail Server Web Frontend Billing CRM-Solution DB2 Risk Banking Software Billing 2 Archiv Intercompany Module External Partner (Bank) Banking Software External Partner (Kunde) CR Software Folie 20

21 Ziel: Flexible Integration der verschiedenen Subsysteme über fachlich definierte Services und Prozesse Benutzerinterfaces (User Interfaces) IT-unterstützte Geschäftsprozesse (Business Processes) Prozess Archivierung von Rechnungen Fachliche Services (Business Services) SAP FI Service CR Service Archiv Service PDF : printinvoice( Invoice) Invoice: getinvoice( Client ) removeclient( ID ) getclient( ID ) savepdf( pdf) Applikationen (Alt-e, Legacy) SAP 2.0 FI CO Sub-Tochter (eignes Intranet) SAP Netweaver Oracle Siebel Siebel FI MM FI... Web Frontend

22 Komponenten- und Domänensicht nach Hess Interaktionskomponenten Prozesskomponenten Prozess Archivierung von Rechnungen Funktionskomponenten SAP FI Service CR Service Archiv Service SAP FI Komponente CR Komponente PDF : printinvoice( Invoice) Invoice: getinvoice( Client ) removeclient( ID ) getclient( ID ) Archiv Komponente savepdf( pdf) Bestandskomponenten (Alt-e, Legacy) SAP 2.0 FI CO Sub-Tochter (eignes Intranet) SAP Netweaver Oracle Siebel Siebel FI MM FI... Web Frontend Domäne 1 Domäne n