Enterprise Service Bus (ESB) in einer SOA

Transkript

1 Einleitung Enterprise Service Bus (ESB) in einer SOA Deutsche Oracle-Anwenderkonferenz (DOAG) Nov Jan Krüger Oracle Deutschland GmbH, Hamburg Ein Enterprise Service Bus (ESB) ist die zentrale Infrastrukturkomponente für Service- Oriented Architectures (SOA) und Event-Driven Architectures (EDA). Der ESB unterstützt und erhöht die Wiederverwendbarkeit und Flexibilität in einer heterogenen, message-oriented Umgebung. Als Teil der Oracle SOA-Suite übernimmt er die Aufgaben: Connectivity, Transformation und Routing. Die Entwicklung von ESB Projekten wird durch den JDeveleoper unterstützt, der durch grafische Wizards die Implementierung und das Deployment vereinfacht. Oracle SOA Suite Bild 1: Komponenten der Oracle SOA Suite Der Oracle ESB ist Bestandteil der SOA Suite, die neben dem ESB die folgenden Komponenten beinhaltet:

2 BPEL Process Manager Der BPEL Process Manager ist eine auf Standards basierende Prozess-Engine für die Integration von IT-Systemen und ermöglicht die sog. Orchestration verschiedener Dienste. Darüber hinaus beinhaltet der BPEL Process Manager eine Workflow-Engine. Business Activity Monitor (BAM) Der Business Activity Monitor ist eine Echtzeit Kontroll- und Überwachungsumgebung, die die Entwicklung von Dashboards, Reports und Alerts ermöglicht. Web Service Manager Der Web Service Manager ist in einer SOA für die Bereiche IT-Sicherheit und die Administration von Web Services und Diensten zuständig. Dabei werden sog. Security- und Identity Management Policies zentral administriert und global angewendet. Der Web Service Manager ermöglicht die Definition und die Überwachung von Service Level Agreements (SLA), mittels der die Eigenschaften und die Qualität eines Dienstes beschrieben werden. Service Registry Die Service Registry ist das zentrale Verzeichnis, in dem die Beschreibungen von Diensten abgelegt sind. Konsumenten können hier Dienste suchen und abrufen. JDeveloper Der JDeveloper ist die Entwicklungsumgebung für BPEL- und ESB-Prozesse sowie für Java, XML, Web Services und SQL und unterstützt den kompletten Entwicklungszyklus: Modellierung, Kodierung, Konfigurationsmanagement, Debugging, Testen und Deployment. IT-Architektur mit ESB Bild 2: IT-Architektur mit ESB

3 Der ESB ist die zentrale Komponente zwischen IT-Anwendungen (z.b. Portlets, Web Anwendungen) oder einem BPEL Prozess und den verschiedenen Diensten. Dabei sind die Dienste über WSDLs (Web Service Definition Language) beschrieben und ermöglichen den Zugriff auf z.b. SOAP Web Services, Datenbanken, Java Applikationen, ERP Systemen, Mainframes oder JMS Queues. Einer IT-Anwendung ist nur die WSDL bekannt. Das eigentliche IT-System, das durch die WSDL beschrieben ist, kennt die IT-Anwendung nicht und ist somit transparent. Connectivity, Transformation und Routing: Die Aufgaben des ESB Die Connectivity basiert auf SOAP oder Technologieadaptern. SOAP ermöglicht u.a. den Aufruf eines externen Web Service, der auf AXIS oder Microsoft.NET basiert. Umgekehrt kann ein ESB Prozess von einem SOAP Client aufgerufen werden. Technologieadapter ermöglichen den bidirektionalen Datentransfer mit fast allen IT-Systemen eines Unternehmens. Ein Adapter kann als Listener an einem System angemeldet werden. Somit kann der ESB auf Events in diesem System reagieren. Der ESB kann zudem via eines Adapters adhoc Daten aus einem System lesen oder Daten in ein System schreiben. Der ESB umfasst die folgenden Adapter: Advanced Queuing-, File/FTP-, Database-, JMS-, IBM s MQund Oracle E-Business Suite Adapter. Die Technologieadapter basieren auf der Java Connector Architecture (JCA). Die JCA Adapter der Hersteller iway Software oder Attunity, die u.a. Adapter für SAP, Tuxedo oder Siebel anbieten, können somit in den ESB integriert werden. Für die Definition der Transformationen von Daten beinhaltet der ESB einen auf Standards basierendem Data Mapper. Das grafische User-Interface definiert eine xslt Datei und somit eine Datentransformation von XML Schema zu XML Schema. Darüber hinaus unterstützt der ESB mittels Domain-Value Maps (DVM) die Zuordnung von spezifischen Kennungen. Z.B. kann in verschiedenen IT-System Euro mit EUR oder EURO gekennzeichnet sein. Mit einer DVM kann eine Zuordnung der beiden Kennungen definiert werden. Die DVM kann in einer Tranformation genutzt werden. Unter Verwendung von Routing Services verteilt der ESB in XML-Dokumenten beinhaltete Daten von einem Quellsystem zu einem Zielsystem. Dabei definieren Routing Rules die Services, die aufgerufen werden, wenn der Routing Service eine Nachricht erhält. Die Routing Roule des ESB unterstützt Content-Based Routing (CBR) und Header-Based Routing (HBR). Folgende Einstellungen können definiert werden: Filter Expressions, Transformationen (s.o.), snychrone oder asynchrone Verarbeitung und Prioritäts-Level. Routing Rules werden zur Designzeit via JDeveloper definiert und können zur Laufzeit via ESB Console geändert werden. Eine Synchronisation von Designumgebung und Laufzeitumgebung ist möglich.

4 Architektur des ESB Bild 3: Architektur des ESB Ein ESB Prozess wird mit dem JDeveloper entwickelt und in den ESB Server registriert, d.h. der Service ist in dem Metadata Server deployed. Der Metadata Server kommuniziert via JMS Topics mit dem JDeveloper, der ESB Console und dem Runtime Server. Darüber hinaus beinhaltet der Metadata Server Servlets, die u.a. die ESB Console, WSIL und WebDAV bedienen. Die Definition des ESB Prozesses wird in dem ORAESB Schema der Datenbank persistiert. Die XSD-, WSDL-, XSLT- und Map-Dateien werden in WebDAV Verzeichnissen gespeichert. Die Metadaten eines ESB Prozesses sind in dem Service Metadata Repository abgelegt. Der Metadata Server bezieht seine Daten von dort. Der Runtime Server ist an dem Control JMS Topic angemeldet und wird somit über Änderungen im Metadata Server benachrichtigt. Erhält der Runtime Server eine Nachricht belädt er seinen Cache neu. Der Kern des Oracle ESB ist der Runtime Server, der als Applikation in einem Application Server deployed ist. Oracle ESB kann in jeden J2EE basierenden Application Server (z.b. JBOSS, BEA WebLogic oder IBM WebSphere) deployed werden. Der Runtime Server unterstützt zahlreiche Protokolle (HTTP/SOAP, JMS, JCA, JDBC, RMI, WSIF und Java) und garantiert Reliable Message Delivery. Er ist skalierbar und unterstützt hochverfügbare IT-Architekturen.

5 Design mit JDeveloper Für das Design eines ESB Prozesses steht dem Entwickler der Oracle JDeveloper ESB Designer zur Verfügung. Dieser beinhaltet Wizards für die Konfiguration der Adapter sowie die anzuwendenden Routing Services. Weiterhin umfasst er das grafische User-Interface für die Entwicklung von XSLT-Transformationen sowie einen XPath Editor und unterstützt das direkte Deployment in die ESB Engine. JDeveloper ist ein Integrated Development Environment (IDE) für die Entwicklung von Anwendungen und Web Services unter Verwendung von Java, XML und SQL Standards. JDeveloper unterstützt den gesamten Entwicklungszyklus mit User-Interfaces, Editoren und Wizards für Design, Entwicklung, Debugging, Testen, Tuning und Deployment einer IT-Anwendung. ESB Control Das ESB Control ist ein Web User Interface für die Administration und das Monitoring des ESB. Es ermöglicht die Konfiguration der Prozesse sowie das Monitoring der Prozessinstanzen. Die Details einer Instanz können dargestellt und untersucht werden. Fehlerbehandlung des ESB Laufzeitfehler der ESB Prozess-Engine werden in der ESB Console visualisiert. Die Fehlerbehandlung eines ESB Prozesses ist abhängig von seiner Ausführungsart. Eine Fehlersituation in einem synchronen Prozess führt zu einem Rollback der geöffneten Transaktion und zu einer Benachrichtigung des Adapters, der den Prozess initiiert. Ein erneuter Aufruf des Prozesses ist nicht möglich. Ein Fehler in einem asynchronen Prozess führt zu einer Benachrichtigung und der Überführung des Prozesses in das sogenannte Error Hospital. Dort können Korrekturen vorgenommen werden und der Prozess erneut gestartet werden. BPEL + ESB: Usage Pattern BPEL Process Manager und ESB ergänzen sich und können gemeinsam eingesetzt werden. Dabei übernimmt der ESB als Infrastrukturkomponente die Verbindung von Endpoints, während der BPEL Process Manager die sog. Orchestrierung der Dienste ausführt. Mit dem BPEL Process Manager können langlaufende Prozesse ausgeführt werden, die ein Workflow sind und eine Interaktion durch Anwendern beinhalten können. BPEL kann unter Verwendung von Korrelationen asynchrone Prozesse ausführen. Ein ESB Prozess kann als Partner Link von BPEL verwendet werden und stellt aus der Perspektive von BPEL einen Service dar.

6 Kontaktadresse: Jan Krüger Oracle Deutschland GmbH Kühnehöfe 5 D Hamburg Telefon: +49(0) Mobile: +49(0) jan.krueger@oracle.com Internet: