Professionelle Open Source SOA mit SOPERA 3

Transkript

1 Professionelle Open Source SOA mit SOPERA 3 Dr. Halil-Cem Gürsoy, CDI AG OOP 2009 München,

2 Der Referent Insgesamt ca. 10 Jahre Beratung, davor Entwicklung im Forschungsumfeld Senior Consultant - JEE Evangelist bei CDI AG Hauptsächlich EAI und SOA-Projekte im JEE Umfeld, aber auch klassische JEE-Projekte Autor und Referent auf Konferenzen 2

3 Agenda Historie Architektur von SOPERA Die SOPERA Toolsuite Beispielszenarien mit SOPERA Einen bestehenden WS einbinden und nutzen Einen WS implementieren und einbinden ESB-ESB Kopplung am Beispiel SAP XI Eclipse Swordfish Links 3

5 SOPERA - Historie 1999 Deutsche Post setzt sehr früh auf SOA und trifft die strategische Entscheidung, eine SOA aufzubauen 2001 Einführung Service Oriented Platform (SOP), einer offenen, modularen und verteilten SOA-Plattform 2006 ca. 160 Services sind bei der Deutschen Post in unternehmenskritischen Anwendungen aktiv 5

6 SOPERA - Historie 2007 Ankündigung der Deutschen Post, die SOA-Plattform Open Source zur Verfügung zu stellen, Gründung von SOPERA als unabhängigen Dienstleister Die Plattform erhält den Name SOPERA SOPERA wird Board Member der Eclipse Foundation und initiiert das Projekt SOA Runtime Framework Platform (Swordfish) 2008 Release der Version 3 6

8 SOPERA Advanced Services Framework SOPERA ToolSuite SOPERA ESB Runtime Framework ARIS Business Architect Service Editor Infrastructure Administration Business Applications Business Processes Business Data/ Legacy Systems Third Party ESB s Other UML Modelling Tools XMI Import Process Editor Policy Editor DevBox Code Generation SBB SBB SBB Distributed Service Bus SBB SBB SBB SBB SBB SBB SBB Service Monitoring Ressource Management Intelligent Deployment BPEL Server BPEL Tools Service Registries/ Repositories SOA Security Services Messaging/ Transport Services BPEL Server Eclipse SOPERA Advanced Services Framework Plug-Ins (Delivered with SOPERA) Runtime Platform (J2EE, J2SE,.Net) Third Party Components 8

9 SOPERA Plug-in Architektur von SOPERA ActiveMQ IBM Webspere MQ OpenUDDI Software AG Centrasite Apache ODE Oracle BPEL Process Manager Evidian Access Master HP OpenView Select Access Nagios HP OpenView Plug-In Messaging Plug-In Registry Plug-In BPEL- Engine Plug-In Security Monitoring/ Management JMS UDDI BPEL JAAS, SAML JMX, WSDM Vendor independent SOA Runtime Framework 9

10 Vendor independent SOA Runtime Framework SOPERA SOPERA Runtime Core SOPERA implementiert das Distributed Service Bus -Pattern Die SOPERA Runtime Core wird bei jedem Service Consumer oder Provider installiert Kein zentraler Hub, direkte P2P Kommunikation Java und.net-unterstützung SOPERA Runtime Core stellt alle benötigten Kernfunktionen zur Verfügung Message Mediation Service Discovery Transformation, Validation Security SOPERA Runtime Core ist nach der JBI-Spezifikation implementiert ( JBI over OSGi ) Plug-In Messaging Plug-In Registry Plug-In BPEL-Engine Plug-In Security Monitoring/ Management JMS UDDI BPEL JAAS, SAML JMX, WSDM 10

11 Verwendete Technologien JBI Messaging abstraction Message routing OSGi Component model Module deployment mechanism Classloading 11

12 Vendor independent SOA Runtime Framework SOPERA Runtime Platform SOPERA Participanten können auf verschiedenen Plattformen deployt werden Standalone (Java SE) Servlet Container (z.b. Apache Tomcat) J2EE Application Server via JCA Microsoft.NET 3.0 Zertifizierte Application Server für SOPERA Oracle Application Server BEA WebLogic Server IBM WebSphere Application Server SAP Netweaver (über JCA) JBoss Apache Geronimo Apache Tomcat Plug-In Messaging Plug-In Registry Plug-In BPEL-Engine Plug-In Security Monitoring/ Management JMS UDDI BPEL JAAS, SAML JMX, WSDM 12

13 Vendor independent SOA Runtime Framework SOPERA - Service Registries/Repositories Die Service Registry ist die zentrale Komponente einer SOA Interaktion mit Service Registry zur Runtime Mehrere Provider pro Service möglich (z.b. mit unterschiedlichen Konfigurationen) Dynamischer Service Provider Lookup und Binding basierend auf den Anforderungen der Konsumenten und den Möglichkeiten des Providers SOPERA unterstützt die Einbindung verschiedener UDDI Registrys als Plugins Plug-In Messaging Plug-In Registry Plug-In BPEL-Engine Plug-In Security Monitoring/ Management JMS UDDI BPEL JAAS, SAML JMX, WSDM 13

14 Vendor independent SOA Runtime Framework SOPERA - SOA Security Services / Transportprotokolle SOPERA unterstützt Sicherheitsmechanismen Authentifizierung, Authorisierung Verschlüsselung und Signierung auf Nachrichtenebene Verschlüsselung auf Transportebene SOPERA unterstützt verschiedene Transportprotokolle HTTP Messaging Systeme über JMS Andere Protokolle können integriert werden Plug-In Messaging Plug-In Registry Plug-In BPEL-Engine Plug-In Security Monitoring/ Management JMS UDDI BPEL JAAS, SAML JMX, WSDM 14

15 Vendor independent SOA Runtime Framework SOPERA Process Management Services SOPERA bietet Unterstützung für Business Process Management Prozesse definiert über BPEL 2.0 können ausgeführt werden (Einbindung der BPEL Engine als Plug in) Business Activity Monitoring (BAM) SOPERA integriert BPEL-Engines als plug-ins Apache ODE wird als Default-Implementierung verwendet Kommerzielle Alternative: Oracle Process Manager Plug-In Messaging Plug-In Registry Plug-In BPEL-Engine Plug-In Security Monitoring/ Management JMS UDDI BPEL JAAS, SAML JMX, WSDM 15

16 SOPERA Weitere Komponenten Service Monitoring Verschieden detaillierte Tracking-Level, durch Policys definiert Tracking-Daten umfassen round-trip Zeiten, Korrelations- Informationen und Service Metadaten Der zentrale Notification Receiver kann alle Informationen in einer Datenbank zur weiteren Auswertung speichern Eclipse BIRT-basierte Reports zur Auswertung System Management Management über JMX (jede JMX-Konsole kann verwendet werden) oder Web Integration in existierenden System Management Plattformen 16

18 SOPERA - Toolsuite Die SOPERA Toolsuite basiert auf Eclipse WTP Neue Perspektiven innerhalb von Eclipse Service Studio Wird vom Service-Entwickler verwendet Entwicklung von Service und Policy-Beschreibungen, Code- Generierung DevBox Komplette SOPERA Entwicklungsumgebung mit einer Laufzeitumgebung für Entwicklung und Entwickler-Tests Administration Tool Schnittstelle zur technischen Infrastruktur 18

19 SOPERA Toolsuite DevBox Stellt für den Entwickler eine lokale SOPERA-Umgebung zur Verfügung Alle benötigten Komponenten sind integriert JORAM (OSS JMS Server) Tomcat OpenDS 19

20 SOPERA Toolsuite Service Studio Editoren für alle Service- Artefakte Starke Einbindung der Registry Service Descriptoren Service Provider Descriptoren Policies 20

21 SOPERA Toolsuite Administration Tool Zugriff auf zentrale Administrationsdienste Service Registry, Konfiguration Service, Security-Komponenten Aufgabenbasierte Benutzerschnittstellen GUI für manuelle Inspektion und Modifikation CLI für Batch-Operationen 21

24 Beispiel-Szenario - WS nutzen Einen bestehenden Service nutzen Service ist nicht direkt mit ESB gekoppelt! Service soll in der Registry eingetragen und von einem Participant genutzt werden Business Consumer SBB SBB Service Registries/ Repositories Distributed Service Bus SBB SOA Security Services SBB Messaging/ Transport Services Business Application SBB Process Management Services 24

25 Beispiel-Szenario Import der WSDL eines bestehenden Services in die Developer Box Voraussetzungen: WS-I Basic Profile 1.1 compliant, document-literal binding Im Fall, dass die Codegenerierung verwendet werden soll, nur eine Fault-Message erlaubt Nur eine porttype-definition erlaubt Erzeugung der SOPERA-spezifischen Descriptoren sdx : Service Description spdx : Service Provider Description spx + spdx = wsdl 25

26 Descriptoren im Detail: Spezifikation eines Services in SOPERA sdx (Service Description) Abstrakte Beschreibung eines Services spdx (Service Provider Description) Beschreibung einer Service Provider Instanz Binding Service Endpoint opdx (Operation Policy Description) Quality of Service ppdx (Participant Policy Description) Vorgaben an Nutzer WSDL 26

27 Registrieren und nutzen des Services Deployment der sdx und spdx in die Service Registry Verwenden des Services durch Einen eigenen Client Selbst implementieren oder (zum größten Teil) generieren lassen Simple Client der Developer Box nutzen Nur für Testzwecke geeignet 27

28 Service nutzen Code-Generierung aus Developer-Box Export der sdx erzeugt neue Java-Projekte Beispiel-Request für Test im Simple Client (Payload der Request-Message): <?xml version="1.0" encoding="utf-8"?> <ns:retrieveemployee xmlns:ns=' <arg0>1</arg0> </ns:retrieveemployee> 28

29 Service aufrufe aus einem eigenen Client In erzeugtem Quelltext mainimpl implementieren: void mainimpl( String[] args ) { }... GetEmployee getemployeeobj = of.creategetemployee(); getemployeeobj.setarg0(requestedid); JAXBElement<GetEmployee> request = of.createretrieveemployee(getemployeeobj); JAXBElement<GetEmployeeResponse> response = retrieveemployee(request); GetEmployeeResponse employeeresponse = response.getvalue();... 29

31 Services implementieren Analoger Ansatz: sdx und spdx innerhalb der Toolsuite definieren Alternativ wsdl definieren und daraus sdx und spdx Service Provider muss implementiert werden Business Consumer Business Application SBB SBB Distributed Service Bus SBB SBB SBB SBB Service Registries/ Repositories SOA Security Services Messaging/ Transport Services Process Management Services 31

32 Definition sdx und spdx, Deployment Neues SOPERA-Projekt beginnen Service Description anlegen Operation und Typen definieren Fault hinzufügen spdx erzeugen Participant und Operation Policies erzeugen (Defaultwerte verwenden) Daten in Registry deployen 32

33 Service (Provider) implementieren Erneut Code durch Export generieren lassen Methode public JAXBElement<T> [operationname]( ) muss implementiert werden Kann erneut durch eigenen Consumer oder Simple Consumer der Developer Box getestet werden Sehr schnelle Implementierung von Services und Clients möglich 33

35 ESB-ESB Kopplung am Beispiel SAP XI Kopplung des SOPERA Distributed Service Bus an einen anderen ESB Kein unübliches Szenario Warum? z.b. Beispiel Konzernumfeld mit gewachsenen Strukturen oder Erweiterung durch Übernahmen Technologische Trennung, z.b. SAP XI für SAP-Systeme 35

36 SAP XI Details zu SAP XI (jetzt SAP PI) XI läuft als Applikation im SAP AS Hub & Spoke-System Anbindung von Systemen über Adapter für IDoc / BAPI-Calls, JDBC, JMS, File System Usw. Weitere Adapter über JCA möglich klassisches EAI System Spezialisiert für Integration innerhalb einer SAP-Landschaft Konfiguration sehr komplex 36

37 Zwei Welten verbinden Nachrichten aus der SAP- in die SOPERA-Welt und umgekehrt Nutzen von BAPI und zentraler Geschäftslogik aus SAP- Systemen in Java /.NET-Projekten SOA-Konform 37

38 SOPERA - SAP XI Implementierung eines JCA-Adapters zum Deployment innerhalb von SAP XI SAP XI unterstützt JCA 1.0 (J2EE Connector Architecture) Adapter als Gateway zwischen SAP XI und SOPERA Problemfall JCA schwache Spezifikation mit vielen Freiheitsgraden JCA 1.0 kann nicht mit ankommenden Nachrichten umgehen, aber Workaround vorhanden BAPI s können als Service über SOPERA aufgerufen werden 38

39 Implementierung des Adapters ist Komplex (Ausschnitt) 39

41 Eclipse Swordfish Eclipse Swordfish (Swordfish SOA Runtime Framework Projekt) SOPERA ist nicht Swordfish, aber SOPERA-Code wird in Swordfish eingebracht Mit einem der kommenden Releases wird SOPERA auf Swordfish basieren Swordfish noch in der Incubation Phase (Stand Anfang ), eine Milestone Release (M3) ist vorhanden 41

42 Aufbau Swordfish Framework plug-ins Framework core Service Discovery Message Processor Advanced Mgmt. Remote Config.... Framewor k Controller Equinox JBI SE JAX- WS JBI SE Java JBI SE BPEL JBI BC JMS JBI BC HTTP... JBI NMR Apache ServiceMix JBI components deployed as OSGi bundles 42

44 Links zu SOPERA SOPERA-Downloads (Toolsuite, Server, Doku) und ServiceMix-Tools unter SOA-Jobs bei CDI AG 44

45 Kontakt Dr. Halil-Cem Gürsoy +49 (0) halil-cem.guersoy@cdi-ag.de