Die Open Source SOA-Suite SOPERA

Transkript

1 Architektur, Komponenten und Realisierung Jörg Gerlach Technische Universität Dresden Fakultät Informatik Institut für Angewandte Informatik Lehrstuhl Technische Informationssysteme 11. Juni 2009

2 Gliederung 1 Einleitung 2 Architektur 3 Komponenten 4 Realisierung 5 Zusammenfassung Jörg Gerlach - Dresden, den 11. Juni /29

3 Gliederung 1 Einleitung 2 Architektur 3 Komponenten 4 Realisierung 5 Zusammenfassung Jörg Gerlach - Dresden, den 11. Juni /29

4 Gliederung 1 Einleitung 2 Architektur 3 Komponenten 4 Realisierung 5 Zusammenfassung Jörg Gerlach - Dresden, den 11. Juni /29

5 Gliederung 1 Einleitung 2 Architektur 3 Komponenten 4 Realisierung 5 Zusammenfassung Jörg Gerlach - Dresden, den 11. Juni /29

6 Gliederung 1 Einleitung 2 Architektur 3 Komponenten 4 Realisierung 5 Zusammenfassung Jörg Gerlach - Dresden, den 11. Juni /29

7 Motivation Motivation Was macht SOPERA innerhalb der ESB-Landschaft interessant? langjährige Geschichte (entwickelt seit 1999) Entwicklung durch die Deutsche Post, d. h. praxisnah modularer Aufbau (z. B. MOM: Active MQ, Joram, IBM Websphere MQ...) SOPERA ASF deckt kompletten Lebenszyklus eines Services ab Jörg Gerlach - Dresden, den 11. Juni /29

8 Geschichte Geschichte 1999 Deutsche Post - Entschluss für SOA 2001 Einführung Service Oriented Platform (SOP) 2006 ca. 160 aktive Services in kritischen Anwendungen genutzt 2007 Entschluss die SOP OpenSource zu stellen Gründung von SOPERA Eintritt in die Eclipse Foundation und Initialisierung des Swordfish-Projekts 2008 Release von SOPERA 3.0 als OpenSource Produkt 2009 Release der aktuellen Version 3.2 Jörg Gerlach - Dresden, den 11. Juni /29

9 Architektur Service Backbone (SBB) stellt den logischen Bus dar (JBI Konform) ermöglicht lose gekoppelte Kommunikation durch Java-Bibliothek bereitgestellt enthält Participant Application Programming Interface (PAPI) Jörg Gerlach - Dresden, den 11. Juni /29

10 Architektur Technical Service Participants (TSPs) stellen Grundfunktionen des ESB insgesamt neun TSPs Aufruf durch SBB-Bibliothek der Services Jörg Gerlach - Dresden, den 11. Juni /29

11 Architektur Jörg Gerlach - Dresden, den 11. Juni /29

12 Technical Services Abbildung: TSPs und Services in SOPERA Jörg Gerlach - Dresden, den 11. Juni /29

13 Technical Services ServiceRegistry Authentication Authorization UserAccountManagement PrivilegeManagement Configuration ConfigurationAdmin ElementManager NotificationReceiver Jörg Gerlach - Dresden, den 11. Juni /29

14 Technical Services Service Registry speichert Policies, Service und Service Provider Informationen ermöglicht zu Consumern besten Provider zu finden anhand des Servicenamen und den Policies gibt Provider und Agreed Policy zurück benötigt Verzeichnis Server (Standard OpenDS) hält sich an UDDI (Universal Description, Discovery and Integration)-Spezifikation Jörg Gerlach - Dresden, den 11. Juni /29

15 Technical Services Sicherheit arbeitet intern mit LDAP (Lightweight Directory Access Protocol) Verzeichnisdienst (Standard OpenLDAP) Authentifizierung (SAML (Security Assertion Markup Language)) Autorisation (SAML) Nutzerkontensteuerung Privilegmanagement (Zugriffe, Konten, Rollen, Resourcen) Schlüsselverwaltung (Signaturen und Verschlüsselung, XKMS (XML Key Management Specification)) Jörg Gerlach - Dresden, den 11. Juni /29

16 Technical Services Konfiguration ermöglicht remote Konfiguration der Service Participants hierarchische Struktur (XML) erstellen von Bereichen möglich Parameter eines Bereichs werden für alle Services übernommen Jörg Gerlach - Dresden, den 11. Juni /29

17 PAPI Participant Application Programming Interface Ist Schnittstelle um Services nutzen oder bereitstellen zu können! zwei Varianten: Typed enthält Code-Generator Service Java-Klasse Operation Methoden der Klasse Nachrichten, Anfragen, Antworten und Notifikation Argumente der Methode Datentypen Java-Klassen geeignet, wenn vorrangig auf Java-Objekte zurückgegriffen wird (statt XML-Dokumente) Jörg Gerlach - Dresden, den 11. Juni /29

18 PAPI Participant Application Programming Interface Untyped Zugriff auf spezielle PAPI-Eigenschaften differenzierte De-/Registration von Nachrichten-Handler auf operationeller Ebene differenzierte De-/Registration von Authentifikations-Handler auf Service, Nachrichten und Operationsebene In- Output als Streams von XML-Dateien Behandlung von Nachrichtenanhängen Parametisierung des Participants zur Laufzeit Jörg Gerlach - Dresden, den 11. Juni /29

19 Nachrichten- und Aufruftypen Nachrichtentypen JBI-Spezifikation definiert vier Nachrichtentypen (In-Only, Robust In-Only, In-Out, In-Optional-Out) Request-response (In-Out): Provider generiert Antwort One-Way (In-Only, Robust In-Only): Provider gibt Statusmeldung zurück Jörg Gerlach - Dresden, den 11. Juni /29

20 Nachrichten- und Aufruftypen Nachrichtentypen JBI-Spezifikation definiert vier Nachrichtentypen (In-Only, Robust In-Only, In-Out, In-Optional-Out) Request-callback (In-Optional-Out): zwei One-way-Nachrichten Consumer sendet im Request-Header eine Antwort-Adresse Antwort nicht garantiert beliebig viele Antworten Notification: Provider sendet Nachricht an Consumer Consumer müssen Notification-Handler bereitstellen Jörg Gerlach - Dresden, den 11. Juni /29

21 Nachrichten- und Aufruftypen Aufruftypen zwei Arten für Request-response Nachrichten Abbildung: Aufruftypen One-way, Request-callback Nachrichten sind nicht blockierend Jörg Gerlach - Dresden, den 11. Juni /29

22 Nachrichten- und Aufruftypen JBI-Interaktion Interaktion von Consumer und Provider (JBI-Spezifikation) Abbildung: Consumer Provider Interaktion One-way, Request-callback Nachrichten sind nicht blockierend Jörg Gerlach - Dresden, den 11. Juni /29

23 Aufbau von Services Aufbau von Services WSDL-Beschreibung getrennt in operationellen Teil und Provider Teil Service Description (sdx) Service Provider Description (spdx) Policies für den Consumer und Provider Operation Policy Description (opdx) Provider Policy Description (ppdx) Jörg Gerlach - Dresden, den 11. Juni /29

24 Aufbau von Services Abschnitte einer WSDL-Datei: Abstrakte Definitionen <types> verwendete Datentypen <messages> Definitionen der übertragenen Daten <porttype> durchzuführende Operationen Konkrete Definitionen <binding> konkretes Protokoll und Datenformat <service> Adressen für Verbindungen Diese Teilung erlaubt für einen Service verschiedene Provider zu erstellen. Jörg Gerlach - Dresden, den 11. Juni /29

25 Aufbau von Services Service Descriptions Service Description wie WSDL enthält <types>und <message>abschnitte zwei <porttype>abschnitte zusätzlich ein partnerlinktype-abschnitt, deklariert porttypes als Service und Callback (für internen Gebrauch z. B. für Request-Callback Nachrichten) Service Provider Description enthält die binding und service Informationen jede.spdx beschreibt genau einen Provider intern genutzt um Adresse des Providers zu ermitteln Jörg Gerlach - Dresden, den 11. Juni /29

26 Aufbau von Services Policies zentraler Bestandteil von Infrastruktur genutzt um Consumer geeigneten Provider zu zuordnen aus Policies vom Provider und Consumer wird Agreed Policy generiert (enthält Rahmenbedingungen) Jörg Gerlach - Dresden, den 11. Juni /29

27 Aufbau von Services Policies Enthalten: technische Anforderungen (z. B. Verschlüsselung, Transporttyp) wirtschaftliche Faktoren (z. B. Geschwindigkeit, Priorität/Zeitanforderungen, Kosten) anderweitig relevante Daten (z. B. Ort) Jörg Gerlach - Dresden, den 11. Juni /29

28 Komponenten Komponentenübersicht Abbildung: Übersicht Komponenten Jörg Gerlach - Dresden, den 11. Juni /29

29 unterstützte Standards Unterstützte Standards Messaging SOAP ( 1.1) HTTP (1.1) JMS (1.1) SSL/TSL (3.0) WS-Addressing (1.0) Security SAML (1.1, 2.0) WS-Trust (1.2) WS-Security (1.1) XKMS (2.0) JAAS XML Signature (RFC 3275) XML Encryption interne Architektur Java EE (1.4, 5) Java SE (5, 6 planned).net (3.0) JBI (1.0 FR) J2C (1.5) JAAS JMX (1.2) Jörg Gerlach - Dresden, den 11. Juni /29

30 unterstützte Standards Unterstützte Standards Integration Infrastruktur WSDL ( 1.1) UDDI (3.0.2) WS-Interoperability Basic Profile (1.1) Attachment Profile (1.0) BPEL (2.0) External Support JDBC (2.0) LDAP (v3) Verschiedenes JAXB (2.0) ECLIPSE RCP (3.3) Jörg Gerlach - Dresden, den 11. Juni /29

31 Realisierung Abbildung: SOPERA ASF (Advanced Service Framework) Jörg Gerlach - Dresden, den 11. Juni /29

32 Server Server Infrastruktur Server TSPs in Apache Tomcat Containern bereitgestellt Verzeichnis und LDAP-Server (Standardkonfiguration) Participant Server stellt SBB bereit Anmeldung am Infrastruktur Server ResourceAdapter, Integration von Business Participants eines J2EE Applikation Servers (optional) BPEL-Support-Server (optional) Jörg Gerlach - Dresden, den 11. Juni /29

33 ToolSuite ToolSuite basiert auf Eclipse WTP Perspektiven innerhalb von Eclipse (DevBox, Administration) Service Studio Entwicklung von Service und Policy-Beschreibungen Service Editor Code Generierung Entwickler Tool Entwicklungsumgebung Laufzeitumgebung Entwickler-Tests (z. B. XML) Administration Tool Schnittstelle zur technischen Infrastruktur Jörg Gerlach - Dresden, den 11. Juni /29

34 ToolSuite Entwickler Tool lokale SOPERA-Umgebung OpenDS Tomcat Active MQ Abbildung: Entwickler Tool Jörg Gerlach - Dresden, den 11. Juni /29

35 ToolSuite Service Studio Editoren für alle Services Service Descriptoren Service Provider Descriptoren Policies Abbildung: Service Studio Jörg Gerlach - Dresden, den 11. Juni /29

36 ToolSuite Administrations-Tool Zugriff auf Administrationsdienste: Service Registry Konfiguration Service Security-Komponenten Abbildung: Administrations-Tool Jörg Gerlach - Dresden, den 11. Juni /29

37 Zusammenfassung umfangreiche SOA Umgebung Unterstützung vieler Standards modularer Aufbau ermöglicht Schrittweise Integration in bestehende Systeme und Nutzung vorhandener Lösungen relativ viele eigene Konventionen Jörg Gerlach - Dresden, den 11. Juni /29

38 Vielen Dank! Jörg Gerlach - Dresden, den 11. Juni /29