Technical White Paper Services mit Oracle SOA Suite
Werbung
Technical White Paper Services mit Oracle SOA Suite oder Java EE implementieren esentri AG Pforzheimer Straße 132 DE – 76275 Ettlingen Tel +49 (0) 7243 / 354 90 0 Fax +49 (0) 7243 / 354 90 99 [email protected] www.esentri.com 02. August 2013 AN 13-Services mit Oracle SOA Suite oder Java EE implementieren Technical White Paper, Seite 1 von 27 Einleitung ................................................................................................ 3 Voraussetzungen ................................................................................... 3 Architekturaspekte .................................................................................... 4 Service-Infrastruktur ............................................................................. 4 Komponentenmodelle ............................................................................ 6 Message-Exchange Patterns.................................................................... 8 Event-Driven SOA ............................................................................... 10 Klassifizierung von Services .................................................................. 11 Service-Entwicklung ................................................................................ 13 Entwicklungswerkzeuge ....................................................................... 13 Serviceschnittstellen ............................................................................ 13 Serviceprogrammierung ....................................................................... 13 Lifecyclemanagement .............................................................................. 18 Security ................................................................................................ 20 Management und Betrieb ......................................................................... 21 Fazit ..................................................................................................... 23 Glossar .............................................................................................. 25 Referenzen ......................................................................................... 26 Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 2 von 27 Einleitung Mit der Oracle SOA Suite 11g steht ein mächtiges Werkzeug für die Entwicklung und den Betrieb von Services, auf Basis der Service Component Architecture (SCA) zur Verfügung. Services können sehr einfach, schnell und vor allem deklarativ mit der SOA Suite entwickelt und betrieben werden. Oftmals wird sehr kontrovers die Frage diskutiert, ob Services auf Basis von SCA mit der SOA Suite oder klassisch mit JEE-Technologien entwickelt werden sollten. Diese Frage ist nicht einfach zu beantworten. Ausgehend vom Anwendungskontext haben beide Varianten ihre Stärken und Schwächen. In diesem Dokument werden verschiedene Aspekte, z. B. Architektur, Management und Betrieb, betrachtet und jeweils die Vor- und Nachteile beider Technologien gegenübergestellt. Ziel dieses Dokumentes ist nicht einer Variante den Vorzug zu geben. Vielmehr sollen hier Kriterien aufgezeigt werden, um eine Entscheidung im jeweiligen Anwendungskontext zu erleichtern. Voraussetzungen • Grundsätzliches Verständnis von Application Server Architekturen und Entwicklungserfahrung im Bereich Webservices und JEE-Technologien. • Die nachfolgenden Betrachtungen gehen davon aus, dass Oracle WebLogic Server als Applikationsserver eingesetzt wird. • Ferner wird angenommen, dass bei der Entwicklung von Serviceschnittstellen und Datentypen auf Basis WSDL und XSD der Contract First-Ansatz zum Einsatz kommt. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 3 von 27 Architekturaspekte Service-Infrastruktur Nachfolgend wird kurz gegenübergestellt, welche Infrastruktur benötigt wird, um einen Service auf Basis von SCA oder JEE zu betreiben. Es werden lediglich die minimalen Anforderungen dargestellt. Im jeweiligen Anwendungsfall kann es durchaus notwendig sein, zusätzliche Infrastrukturkomponenten, wie z. B. eine Datenbank für Fachdaten, bereitzustellen. Diese Komponenten werden nachfolgend nicht betrachtet. Oracle SOA Suite Abbildung 1: Vereinfachte Systemarchitektur Oracle SOA Suite Oracle SOA Suite ist ein SCA-Container der in Form einer JEE-Anwendung im Applikationsserver installiert und betrieben werden kann. SOA Suite benutzt u.a. folgende technische Komponenten aus dem JEE-Standard: • EJB’s • Resource Adapter nach JCA • JMS • Webapplikationen Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 4 von 27 Ferner benötigt die SOA Suite eine Datenbank zum Speichern von Informationen. Diese Datenbank besteht mind. aus den beiden Schematas MDS und SOAINFRA. Im MDS werden alle Konfigurationsdaten der SOA Suite und alle installierten Composites gespeichert. Im Schema SOAINFRA werden alle Daten zu laufenden Instanzen von Composites gespeichert. Zu diesen Daten zählen u.a. Audit-Informationen, Prozessstati etc. Die Oracle SOA Suite kann mit den verfügbaren Werkzeugen der Oracle Fusion Middleware überwacht und gesteuert werden. Diese Werkzeuge sind WebLogic Server Console und Fusion Middleware Control bzw. Cloud Control. Ein SCA wird in Form einer *.jar zu einer installierbaren Einheit zusammengebaut. Der Aufbau eines SCA’s muß einer bestimmten Struktur folgen (diese Struktur wird in diesem Dokument nicht erläutert!). Die jar-Datei mit dem SCA wird durch Werkzeuge der SOA Suite installiert. Technisch erfolgt die Weitergabe der jar-Datei an ein Servlet in der SOA Suite. Das Servlet (DeployerServlet) übernimmt die Installation und Konfiguration des SCA’s. Im Falle eines Clusterdeployments erfolgt die Installation eines Composites immer auf genau einen Server. Die Mitteilung über ein neu installiertes Composite wird über Coherence an die anderen Server im Cluster verteilt. Die einzelnen Server im Cluster beziehen die Daten zum Composite aus dem MDS. JEE Abbildung 2: Systemarchitektur Java EE-Webservice Prinzipiell benötigt man für die Bereitstellung eines Java EE-Webservice einen Applikationsserver, z. B. WebLogic Server. Je nach dem, welche Java EE-Technologien (mit/ ohne EJB) für die Implementierung des Webservice eingesetzt werden, kann auch ein Servlet-Container für den Betrieb ausreichend sein. Diese Möglichkeit, wird allerdings in diesem Dokument nicht berücksichtigt. Ein Webservice wird typischerweise in Form einer ear-Datei zur Verfügung gestellt. Der Aufbau der ear-Datei ist ebenfalls in den JEE-Spezifikationen definiert und wird hier nicht näher betrachtet. Weitere Informationen können der JEE-Spezifikation entnommen werden. Die Installation der ear-Datei wird durch den Applikationsserver durchgeführt. Die Überwachung der Applikation erfolgt mit den Werkzeugen des Applikationsservers. Im WebLogic Server erfolgt die Überwachung mit der sog. WebLogic Server Console. Als Infrastrukturkomponente benötigt ein Java EE-Webservice zunächst einmal keine Datenbank. Ausgenommen sind natürlich Services, die Daten in einer Fachdatenbank verwalten. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 5 von 27 Komponentenmodelle Service Component Architecture (SCA) Abbildung 3: Komponenten in einem SCA SCA besteht aus einer Reihe von Spezifikationen die ein Model für die Implementierung von Anwendungen und Systemen in einer SOA beschreiben. An der Definition der Spezifikationen waren verschiedene Firmen, u.a. auch Oracle, beteiligt. Der SCA-Standard wird zur Zeit bei OASIS geführt und liegt in Version 1.0 aus dem Jahr 2007 vor. Ein wesentlicher Baustein in einem SCA ist das sog. Component. In einem SCA tauschen Componentes Nachrichten miteinander aus. Dabei ist die konkrete Implementierung einer Component zunächst unerheblich. In der SOA Suite werden folgende konkrete Implementierungen für Components angeboten. Diese Implementierungen werden auch als Service Engines bezeichnet. • BPEL • Decision Service (Rules Engine) • Mediator (Routing) • Human Workflow (Human Interaction) • Spring Context Überdies implementiert die SOA Suite folgende Binding-Komponenten: • Webservice (SOAP over HTTP) • JCA adapters (AQ, Database, FTP, JMS, MQ, Socket, etc.) • B2B binding component • ADF-BC service • Oracle Applications • BAM Adapter Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 6 von 27 • Direct binding service • HTTP binding Bei SCA handelt es sich zwar um einen Standard der durch OASIS verwaltet wird. Jedoch ist zu beachten, dass ein erstelltes Composite mit Oracle-Tools nicht ohne weiteres in einem SCAContainer eines anderen Herstellers installiert und betrieben werden kann! Java Enterprise Architecture (Java EE) Im Java EE-Umfeld existieren prinzipiell zwei verschiedene Möglichkeiten Webservices zu implementieren. Diese werden nachfolgend erläutert. Java-API for RESTful Web Services (JAX-RS) Es wird eine einheitliche Schnittstelle in der Programmiersprache Java zur Verfügung gestellt, um Webservices nach dem Architekturkonzept REST zu implementieren. Wie andere Schnittstellen im Java EE-Kontext benutzt JAX-RS Annotations um die Entwicklung und das Deployment von Webservices zu vereinfachen. Java-API for XML Web Services (JAX-WS) JAX-WS stellt ebenfalls eine einheitliche Schnittstelle für die Erstellung von Webservices in der Programmiersprache Java zur Verfügung. Wie andere Schnittstellen im Java EE-Kontext benutzt JAXWS Annotations um die Entwicklung und das Deployment von Webservices zu vereinfachen. JAX-WS ist Bestandteil der sog. Metro-Plattform und baut technisch auf JAX-RPC (Java-API for XML-based RPC) auf. Ein wesentlicher Unterschied zu JAX-RS ist die Nutzung von SOAP für den Austausch von Nachrichten zwischen Client und Server. SOAP ist ein Protokoll für den Nachrichtenaustausch auf Basis von XML. Für die Konvertierung der Datentypen zwischen Java-Objekten und XML delegiert JAX-WS die Aufgabe an JAXB (Java Architecture for XML Binding). Mit JAX-WS können Webservices auf folgende zwei Arten erstellt werden: • top-down (contract first) Zunächst wird eine WSDL und entsprechende Datentypen auf Basis von XML-Schematas entwickelt. Aufgrund der WSDL und XML-Schematas werden Java-Klassen generiert, die das Webservice-Interface beschreiben. Im Anschluß muß lediglich noch die Businesslogik für den Webservice integriert werden. • bottom-up In diesem Fall wird die Schnittstelle für den Webservice in Form eines Java-Interfaces, POJO’s oder EJB definiert. Anschließend erfolgt die Generierung der WSDL und XMLSchematas auf Basis der Java-Definitionen. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 7 von 27 Mit dem Projekt METRO existiert eine Referenzimplementierung für JAX-WS. Weitere Implementierungen dieser Spezifikation ist z. B: Apache CXF. Java Architecture for XML-Binding (JAXB) Ermöglicht das Transformieren von XML-Daten nach Java-Objekten und zurück. Ausgangsbasis ist eine XML-Schemabeschreibung, auf deren Basis entsprechende Java-Klassen generiert werden können. Durch die Nutzung von JAXB ist es nicht erforderlich sich direkt mit SAX oder DOM, bei der Verarbeitung von XML-Daten, zu beschäftigen. Message-Exchange Patterns Synchroner Service Ein synchroner Service entspricht im wesentlichen einem entfernten Funktionsaufruf (RPC). Mit Daten bzw. Parametern wird eine „entfernte“ Funktionalität aufgerufen. Der Nutzer wartet auf den Eingang der Antwort, um setzt danach erst die Weiterverarbeitung fort. Typischerweise wird der Ablaufzustand und Context während der Dauer der Verarbeitung gespeichert und nicht über die Verarbeitungsdauer der Anfrage hinweg. Die Basis MEP’s für synchrone Service’s sind: • Request/ Response Der Nutzer sendet eine Anfrage an den Anbieter. Der Anbieter verarbeitet die Anfrage und sendet eine Antwort an den den Nutzer zurück. Der Nutzer wartet auf die Antwort des Anbieters. Abbildung 4: Request/ Response MEP Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 8 von 27 • One Way (aka Fire & Forget) Im wesentlichen gleich zu Request/ Response, allerdings erfolgt hier keine Rückmeldung an den Nutzer. Der Nutzer wartet nicht auf eine Antwort vom Anbieter, sondern führt nach dem Aufruf seine Verarbeitung fort. Abbildung 5: One-Way MEP Daneben existieren noch eine Reihe von Ausprägungen für diese MEP’s, die aber nicht näher erläutert werden. Die Implementierung eines synchronen Service ist prinzipiell sehr einfach und wird durch Java EEFrameworks und die SOA Suite gleichermaßen sehr gut unterstützt. Asynchroner Service Bei einem asynchronen Service sendet der Nutzer eine Anfrage an den Anbieter und setzt seine Verarbeitung anschließend fort. Jedoch möchte der Nutzer nach erfolgreicher Verarbeitung der Anfrage durch den Anbieter eine Benachrichtigung erhalten. Hierzu werden meist sog. CallbackFunktionen angeboten. Damit der Anbieter die Rückantwort an den Nutzer senden kann, muss er eine Reihe von Informationen, z. B. Adresse des Nutzers etc. ermitteln. Ferner muss der Nutzer sicherstellen, dass eine „Callback-Nachricht“ vom Anbieter mit der ursprünglichen Anfrage assoziiert werden kann. Der Fachbegriff zu dieser Forderung lautet Correlation. Für Webservices wurde für diesen Zweck ein Standard mit Namen WS-Adressing definiert. Mit WSAdressing werden alle notwendigen Informationen für die Nachrichtenzustellung in den SOAPHeader eingetragen und übermittelt. Die Basis MEP’s für asynchrone Service’s sind: • Request/ Callback Der Nutzer sendet eine Anfrage an den Anbieter. Anschließend setzt der Nutzer seine Verarbeitung fort. Der Anbieter verarbeitet die Anfrage und sendet seine Antwort durch Nutzung einer Callback-Funktion an den Nutzer zurück. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 9 von 27 • Publish/ Subscribe Sofern mehrere Systeme über Zustandsänderungen etc. informiert werden möchten, können Sie sich auf bestimmte Ereignisse registrieren. Sie warten bzw. beobachten die eintreffenden Ereignisse. Sobald eine Zustandsänderung in Form einer One-Way-Nachricht veröffentlicht wurde, erhalten alle registrierten Beobachter diese Nachricht und können ihre Verarbeitung entsprechend fortsetzen. In der SOA Suite besteht die Möglichkeit einer Correlation mit dem MEP Request/ Callback auf Basis einer intern, eindeutig erzeugten ID oder aufgrund von fachlichen Daten herzustellen. Die Nutzung von fachlichen Daten für eine Correlation erfolgt durch Definition eines Correlation Sets. Dies geschieht deklarativ in der Entwicklungsumgebung. Technisch nutzt die SOA Suite WS-Adressing, um dies Correlation-Daten in der Nachricht zu übermitteln. Das MEP Publish/ Subscribe kann innerhalb der SOA Suite mit dem EDN realisiert werden. Die Nutzung von EDN erfolgt dabei ebenfalls deklarativ in der Entwicklungsumgebung. Eine besondere Programmierung ist nicht erforderlich. Mit einer Webservice-Implementierung auf Basis von JEE muß die Correlation für beide dargestellten MEP‘s manuell nachprogrammiert werden. Die Informationen über den Aufrufer und die Correlation-Daten müßen u.U. längerfristig gespeichert werden. Dies ist vor allem in einem komplexten Geschäftsprozeß-Szenario der Fall. Die Aufbewahrung der Correlation-Daten kann im Dateisystem oder in einer Datenbank erfolgen. Event-Driven SOA Bei Event-Driven SOA wird die Erzeugung und Verarbeitung von Ereignissen (Events) in den Vordergrund gestellt. Oftmals wird dieser Architekturstil auch als SOA 2.0 bezeichnet. Beim Einsatz von Event-Driven SOA ist vor allem der Umfang der Daten die in Ereignissen zur Verfügung gestellt werden sollen, zu betrachten. Aspekte wie Security etc. spielen dabei eine große Rolle. Unter technischen Gesichtspunkten kann der Nachrichtenaustausch mit den MEP‘s Publish/ Subscribe und One Way als Bereitstellung und Konsumierung von Ereignissen betrachtet werden. Eine Event-Driven SOA kann mit der SOA Suite mit dem sog. EDN realisiert werden. Das EDN ist nativ in SCA integriert. Der Umfang an Daten in einem Ereignis kann sehr einfach in der Entwicklungsumgebung definiert werden. Darüberhinaus erfolgt die Definition, wann ein Ereignis bereitzustellen und konsumieren ist, deklarativ in der Entwicklungsumgebung. Eine gesonderte Programmierung ist nicht erforderlich. Im Bereich Java EE gibt es keine Lösung für eine Event-Driven SOA out-of-the-box. In diesem Fall ist es notwendig, eventl. auch ein Produkt oder Framework mit dieser Funktionalität zurückzugreifen oder eine Eigenentwicklung durchzuführen. Die Eigenentwicklung könnte typischerweise auf Basis von JMS erfolgen. In beiden Fällen ist jedoch zusätzlich noch der Integrationsaufwand bei der Anwendungsentwicklung zu berücksichtigen. Die Integrationsaufwände sind im wesentlichen die Definition, Erzeugung, Bereitstellung und Konsumieren der Ereignisse. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 10 von 27 Klassifizierung von Services Anforderungen und Eigenschaften an Services können sich sehr stark unterscheiden. Aus diesem Grund ist es empfehlenswert Services nach diesen Kriterien zu unterteilen. In Abhängigkeit von der Klassifizierung ergeben sich dann automatisch auch Implikationen auf die technische Implementierung. Folgende grobe Klassifizierung trifft man sehr häufig in Unternehmen an. Die im Folgenden vorgestellte grobe Klassifizierung ist häufig in Unternehmen zu finden, die bereits eine erfolgreiche SOA Implementierung aufweisen. Weitere Klassifizierungsmöglichkeiten sind vorstellbar, werden aber in diesem Dokument nicht weiter betrachtet. Elementar-Services Diese Klassifizierung wird häufig auch als Basis- oder Daten-Service bezeichnet. Sie implementieren eine fachliche Basisfunktionalität. Typischerweise handelt es sich hierbei um Services, die kurzlaufend und zustandslos sind. Diese Services werden fast immer synchron aufgerufen. Services dieser Kategorie können sehr einfach als Java EE-Service zur Verfügung gestellt werden. Die Entwicklungsumgebung stellen gute Werkzeuge für die Generierung zur Verfügung. Falls erforderlich müsste zusätzlich noch ein Adapter vor den eigentlichen Java EE-Service hinzugefügt werden, wenn beispielsweise ein Mapping für das Datenmodell erforderlich ist. In der SOA Suite können Services dieser Art ebenfalls einfach erstellt werden. Die SOA Suite ist einem Java EE-Service nur dann vorzuziehen, wenn beispielsweise ein solcher Service nach dem ETL-Muster erstellt werden muss. In diesem Fall bietet die SOA Suite Komponenten an, das Datenmodell-Mapping deklarativ vorzunehmen. Composed-Services Composed-Services kombinieren Elementar- oder andere Composed-Services zu neuen neuen „höherwertigen“ Services. Die Komposition neuer Services aus bestehenden Services wird als Orchestrierung bezeichnet. Die Orchestrierung von Services erfolgt in der SOA Suite unter Einsatz der Komponente BPEL. In der Entwicklungsumgebung erfolgt eine Modellierung der Aufrufreihenfolge von Services. Im Composite-Editor können die Abhängigkeiten und Aufrufe von Services sehr einfach überblickt werden. Im Fall von Java EE ist die Komposition von Services manuell in Java zu programmieren. Der Ablauf ergibt sich nicht aus einem Modell und kann nur unter Betrachtung des Sourcecodes ermittelt werden. Auch die Transformation zwischen den verschiedenen Datenmodell ist im Wesentlichen manuell durchzuführen. Üblicherweise werden Webservices-Proxies für die einzubindenden Services erstellt, die dann im Rahmen des neuen Services entsprechend angesprochen werden. Auch die Verwaltung der Endpunkte für diese Services muss manuell vorgenommen werden. Wenn mehr als zwei Services zu einem neuen Services orchestriert werden, dann empfiehlt sich auf jeden Fall die Nutzung der SOA Suite. Bei weniger als zwei Services hängt es im Wesentlichen von den Anforderungen ab, z. B. ist eine Transformation notwendig etc. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 11 von 27 Prozess-Services Diese Servicekategorie implementiert komplette Geschäftsprozesse. In dieser Servicekategorie werden auch Services orchestriert, allerdings ist zu beachten, dass der Zustand zwischen den einzelnen Serviceaufrufen gespeichert wird. In der SOA Suite können Services dieser Kategorie unter Einsatz verschiedener Komponenten deklarativ erstellt werden. Ferner bietet die SOA Suite Funktionen für das Management und Überwachung von Services an. Der Zustand zwischen den einzelnen Serviceaufrufen wird in einer Datenbank gespeichert. Im Bereich Java EE gibt es keine Lösung für die Implementierung eines Prozess-Servie out-of-thebox. In diesem Fall muss auf ein Produkt oder Framework zurückgegriffen werden. Eine Eigenentwicklung ist in den seltensten Fällen sinnvoll. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 12 von 27 Service-Entwicklung Entwicklungswerkzeuge Die Entwicklung von JEE-basierten Services kann mit jedem beliebigen JavaEntwicklungswerkzeug, wie z. B. Oracle JDeveloper, Eclipse, NetBeans o.ä., erfolgen. Dabei unterscheiden sich die einzelnen Werkzeuge in Komfort und Geschwindigkeit. Üblicherweise bieten die Entwicklungswerkzeuge einen integrierten JEE-Applikationsserver an, der es ermöglicht, die entwickelten Services auf dem lokalen Entwickler-PC zu installieren und auszuführen. SCA ist im Vergleich zu JEE noch eine rechte junge Technologie. Insbesondere ist das an der IDEUnterstützung im Vergleich zu JEE-Entwicklung erkennbar. Viele Funktionen, z. B. im Bereich des Refactorings, stehen im Bereich SCA noch nicht zur Verfügung. Die Implementierung eines SCAbasierten Services kann zum aktuellen Zeitpunkt ausschließlich mit dem Oracle JDeveloper durchgeführt werden. Ein anderes Entwicklungswerkzeug kann nicht genutzt werden. Darüberhinaus muss eine Oracle SOA Suite Installation zur Verfügung stehen, um die entwickelten Services zu installieren und auszuführen. Serviceschnittstellen Serviceschnittstellen werden durch WSDL und XSD-Dateien beschrieben. In fast jeder JavaEntwicklungsumgebung gibt es mehr oder minder-komfortable Editoren für die grafische Anzeige und Veränderung von WSDL und XSD-Dateien. Sowohl bei der Entwicklung auf Basis Java EE und SCA können bestehende WSDL und XSD-Dateien als Ausgangsbasis genutzt werden („Contract First“). In beiden Fällen besteht jedoch auch die Möglichkeit, WSDL und XSD-Dateien automatisch generieren zu lassen („Code First“). Serviceprogrammierung Erstellung Im Kontext Java EE werden üblicherweise Interfaces und Klassen durch das jeweilige Framework generiert. Die Aufgabe des Entwicklers ist nun die konkrete Implementierung der Serviceoperationen durch Schreiben von Java-Code. Die Struktur des Services wird durch Java-Klassen beschrieben. Jedoch ist der Ablauf und die Beziehungen nicht sofort erkennbar. Erst durch SourcecodeAnalyse oder Nutzung eines zusätzliches Werkzeuges (Klassendiagramm, Sequenzdiagramme etc.) werden die Zusammenhänge teilweise sichtbar. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 13 von 27 Abbildung 6: Webservice mit Java-POJO Für die Referenzierung von WSDL- und XSD-Dateien während der Serviceprogrammierung muss ein Mechanismus für das Projekt definiert und umgesetzt werden. Beispielsweise könnte ein zentraler Apache HTTP-Server aufgesetzt werden, um WSDL und XSD-Dateien zur Verfügung zu stellen. Die Referenzierung erfolgt dann über die URI http://. Diese URL muss dann im Buildprozeß an die entsprechende Umgebung (Development, Test, Produktion) angepaßt werden. Ferner muss ein die Bereitstellung der WSDL und XSD-Dateien in den HTTP-Server definiert werden. Die Entwicklung von SCA-Services im Oracle JDeveloper erfolgt fast ausschließlich deklarativ im Composite-Editor. Die Abhängigkeiten der einzelnen Komponenten sind durch ein Diagramm anschaulich visualisiert. Viele Wizzards unterstützen und vereinfachen die Entwicklung, z. B. XLSTTranformer um Datenmodelle anzugleichen. Die Programmierung beschränkt sich auf die deklarative Beschreibung und Konfiguration der Komponenten. Abbildung 7: Composite-Editor im JDeveloper Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 14 von 27 Darüberhinaus steht mit dem MDS ein Werkzeug zu Verfügung, um WSDL und XSD-Artefakte umgebungsunabhängig zu organisieren und zu referenzieren. Das MDS speichert Artefakte in einer Datenbank oder im Dateisystem. Das dateisystem-basierte MDS ist im JDeveloper integriert und erlaubt die Referenzierung von WSDL und XSD-Dateien ohne komplexe Infrastruktur. Artefakte werden mit der URI oramds:// referenziert. Diese URI wird durch die Infrastruktur entsprechend aufgelöst, also in eine Datenbank oder auf das Dateisystem. Für den Entwickler ist das völlig transparent. Integration In Bezug auf Integrationsaufgaben muss das jeweilige System bzw. Komponente, im Falle eines Java EE-Services, manuell integriert werden. Systeme und Komponenten können beispielsweise Queues, Datenbanken, ERP-Systeme oder andere Services sein. Ferner muss das Mapping des Datenmodells, falls erforderlich, ebenfalls manuell programmiert oder durch Einsatz von XLSTTools erfolgen. Für viele Systeme und Komponenten gibt es bereits vorgefertigte Adapter in der SOA Suite die nur in den Service eingebunden und konfiguriert werden müssen. Beispielsweise existieren Adapter für Queues, Datenbank etc. Ein externer Webservice wird in Form einer Referenz verfügbar. Bestehende POJO/ Spring- und EJB-Komponenten können einfach eingebunden werden. Somit können bestehende Komponenten sehr einfach in eine SOA-Welt überführt werden. Die Plattform optimiert den Zugriff auf diese Komponenten! Für das Mapping von Datenmodellen ist in den diversen Komponenten ein XLS-Transfomer integriert. Die Mappingbeschreibung erfolgt ebenfalls deklarativ. Fehlerbehandlung Die Fehlerbehandlung erfolgt im wesentlichen durch das „Werfen“ (Throw) und „Abfangen“ (Catch) von Java-Exceptions. Die Java-Exceptions müssen dann noch in einen SOAP-Fault übersetzt werden. Die Strategie für das Werfen und Abfangen von Exceptions muss durch den Entwickler manuell entworfen und umgesetzt werden. Der Aufwand für die Überführung von Java-Exceptions in SOAP-Faults hängt stark vom eingesetzten Webservice-Framework ab. Die Fehlerbehandlung wird überlicherweise pro Service entwickelt. Eine einheitliche Fehlerbehandlung über die Servicegrenzen hinweg ist schwierig zu implementieren (Java-Library) und erfordert eine hohes Maß an Governance zwischen Entwicklungsteams. In der SOA Suite erfolgt das Werfen und Abfangen von Fehlersituationen deklarativ zur Designtime. Die Übersetzung in einen SOAPFault erfolgt ebenfalls deklarativ. Darüberhinaus steht mit dem Faultframework eine Möglichkeit zur Verfügung, das Fehlermanagement zu zentralisieren und zwar über die Servicegrenzen hinweg. Somit kann beispielsweise zentral definiert werden, was in bestimmten Fehlersituationen zu erfolgen hat, ohne das der Entwickler im einzelnen Service dies berücksichtigten muss. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 15 von 27 Abbildung 8: Deklarative Fehlerbehandlung in BPEL und Auszug aus fault-policy.xml File Die Aspekte des Fehlermanagements zur Laufzeit werden in einem separaten Kapitel betrachtet. Test Im Context einer Java EE-basierten Serviceentwicklung können Unit-Tests erstellt werden. Dabei gibt es eine Reihe von Frameworks, die genutzt werden können, um Services zu testen. Die internen Klassen können beispielsweise mit jUnit oder Ablegern überprüft werden. Den ablauffähigen Service kann man über SOAP UI oder Apache jMeter testen. Die SOA Suite erlaubt die Definition von Unit-Tests für SCA’s. In diesem Fall ist es auch nicht erforderlich Mocks für externe Services zu erstellen. Deklarativ können Testdaten als Ergebnis dieser Serviceaufrufe in der Entwicklungsumgebung definiert werden. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 16 von 27 Abbildung 9: Unittest für Composite definieren Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 17 von 27 Lifecyclemanagement Versionsmanagement Im Rahmen der Bereitstellung von Services muss auch die Frage beantwortet werden, wie mit unterschiedlichen Versionsständen von Services umgegangen werden soll. Im Kontext einer Java EE-basierten Entwicklung von Services muss das Versionsmanagement ausschließlich manuell durchgeführt werden. Die Versionierung bezieht sich nicht nur auf die Schnittstellenbeschreibung mit WSDL- und XSD-Dateien, sondern auch auf die Implementierung selbst. Insbesondere die Frage wie unterschiedliche Serviceversionen bereitgestellt werden, sind zu beantworten. Es existieren eine Reihe von Bestpractices in diesem Umfeld, die manuell auf die eigene Serviceimplementierung angewandt werden können. Ferner ist zu beachten, daß Servicekonsumenten explizit die einzelnen Serviceversionen, durch Auswahl der entsprechenden URL, ansprechen müssen. Durch Einsatz zusätzlicher Infrastrukturkomponenten, z. B. Oracle Service Bus, kann dieser Umstand jedoch vereinfacht werden. In der SOA Suite unterliegen SCA’s automatisch einer Versionierung. Die Kennzeichnung der Version kann jedoch individuell gestaltet werden. Die einzelnen Serviceversionen sind sichtbar und können entsprechend verwaltet werden. Insbesondere kann definiert werden, welche Version per Default mit der selben URL zur Ausführung kommt. Veraltete Serviceversionen können „deaktiviert“ werden. Abbildung 10: Version für ein Composite definieren Zu beachten ist in beiden Fällen, daß Services mit schreibenden Zugriff auf eine Datenbank eine besondere Betrachtung benötigen. Das zugrundeliegende Datenbankschema muss auf jeden Fall immer auch abwärtskompatibel zu allen noch verfügbaren Serviceversionen sein. Dieser Umstand wird durch keine Infrastruktur automatisch sichergestellt. Insbesondere mehrere Versionen eines Datenbankschematas zu verwalten ist nicht sinnvoll. Darüberhinaus ist eine Versionierung von WSDL und XSD-Dateien, die beispielwiese nach dem Contract First-Ansatz definiert wurden, immer eine manuelle Aufgabe und abhängig von den eingesetzten Entwicklungswerkzeugen. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 18 von 27 Entwicklungsprozess Oftmals ist es erforderlich die Implementierung umgebungsabhängig für die Installation vorzubereiten (Deployment). Diese Anpassungen sind beispielsweise Konfigurationseinstellungen oder URL’s. Im Java EE-Kontext erfolgt der Einsatz von Buildwerkzeugen, z. B. Apache ANT oder Apache Maven. Diese Werkzeuge bieten mehr oder minder komfortable Möglichkeiten diese Anpassung beim Buildprozeß durchzuführen. Einmal eingerichtet, erfolgt die Anpassung immer automatisch und schnell. Im Umfeld der SCA-Entwicklung erfolgen solche Anpassungen durch die Nutzung von Configplänen. Das Konzept folgt den gleichen Ansätzen wie z. B. bei ANT oder Maven. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 19 von 27 Security Das Thema Security ist sehr umfangreich und hat viele Aspekte. In diesem Abschnitt wird lediglich der Zugriff auf einen Webservice (Authentifizierung) und Absicherung der Nachrichten eingegangen. Ein Java EE-basierter Webservice wird in Form einer Enterprise Applikationen in einen Java EEServer installiert. Somit kann der im Java EE-Kontext die Authentifizierung alleine durch Deklarationen (Java EE-Rollen in web.xml) an den Java EE-Container delegiert werden. Das ist für den Webservice völlig transparent. Deneben existieren eine Reihe von Security Standards im Webserviceumfeld. Die Umsetzung und Nutzung dieser Standards ist abhängig vom eingesetzten Framework oder Produkt. Oftmals erfolgt die Definition der Securityeinstellungen über Annotationen in der Serviceimplementierung. Darüberhinaus ist festzustellen, daß der Oracle Webservice Manager auch für Java EE-basierte Services genutzt werden kann, sofern diese in einer WebLogic Server Infrastruktur verwaltet werden (siehe nächster Abschnitt). Der Oracle Webservice Manager ist in die Oracle SOA Suite integriert. Mit dem OWSM können diverse Serviceaspekte über Policies geschützt werden, z. B. SAML-Authentifizierung in Verbindung mit Nachrichtenverschlüsselung. Die Definition der Securityeinstellungen erfolgt deklarativ zur Designtime im JDeveloper. Ferner besteht auch die Möglichkeit, die Security automatisch oder manuell zur Laufzeit in der Infrastruktur zu definieren (Nutzung von PolicySets). Somit kann sich der Entwickler auf die Implementierung der Businesslogik im Service konzentrieren. Abbildung 11: Security-Policy zu einem Service hinzufügen Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 20 von 27 Management und Betrieb Die Architektur eines Java EE-basierten Webservice ist einfacher zu überwachen und besteht oftmals aus folgenden Komponenten: • eventl. einer Datenbank für die Anwendungsdaten • Java EE-Server • Enterprise Applikation für das Deployment (ear-Datei) Die Java EE-Technologie ist weit verbreitet und etabliert. Darüberhinaus gibt es eine Vielzahl von Best Practices in diesem Umfeld. Ein Java EE-basierter Webservice ist auf allen Standard-Java EEContainern grundsätzlich betreibbar. Jedoch ist zu beachten, daß ein End-to-End Monitoring nicht möglich ist. Die prinzipiell verfügbare Monitoring-Möglichkeiten hängen von der verwendeten Infrastruktur ab. Der interne Ablauf eines Java EE-basierten Webservices wird nicht visualisiert. Vielfach erfolgt die Analyse des Ablaufs durch Betrachtung der diversen Logfiles. Problematisch sind u.U. unterschiedliche implementierte Logging-Strategien in den diversen Webservices, z. B. log4j, java-logging,... Die SCA-Infrastruktur mit der SOA Suite erlaubt ein End-to-End Monitoring von SCA-Services. Im einzelnen besteht die Möglichkeit, den Zustand der einzelnen Serviceinstanzen zu überwachen. Ferner kann der Ablauf und Daten von einzelnen Serviceinstanzen jederzeit eingesehen und überprüft werden. Insbesondere kann der Prozessablauf grafisch visualisiert werden. Darüberhinaus können im Error-Hospital fehlerhafte Serviceinstanzen wieder angestartet werden. Abbildung 12: Monitoring von Composites im Enterprise Manager Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 21 von 27 Ein wichtiger Bestandteil in der SOA Suite ist das sog. Fault Framework. Mit diesem kann zentral das Fehlermanagement für SCA-Service deklarativ konfiguriert werden. Somit kann eine einheitliche Fehlerbehandlung für alle installierten SCA-Services erfolgen. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 22 von 27 Fazit Mit dem Java EE-Standard steht eine bewährte Technologie für die Servicentwicklung zur Verfügung. Daneben existiert mit SCA ein noch junger Standard, der noch nicht von allen Herstellern 100%ig unterstützt wird. Beide Technologien haben in Bezug auf die Entwicklung von Services ihre Stärken und Schwächen. Somit kann weder der einen noch anderen Technologie der Vorzug gewährt werden. Vielmehr ist der Einsatzzweck der entscheidende Faktor. Ferner ist festzustellen, daß es durchaus sinnvoll ist, beide Technologien im Rahmen der Serviceentwicklung zu nutzen. Ein mögliches Szenario ist beispielweise die Elementarservices auf Basis von Java EE zu entwickeln und aber der Ebene der Composed Services SOA Suite zu nutzen. Nachfolgend sind die möglichen Entscheidungskriterien tabellarisch zusammengefaßt: Kriterium/ Technologie SCA Java EE Infrastruktur (Runtime) benötigt komplexe Infrastruktur: • Applikationsserver • Service Infrastruktur • Datenbank Applikationsserver ausreichend Synchron einfach zu implementieren einfach zu implementieren Asynchron Nutzung empfehlenswert Nutzung nicht empfehlenswert Elementar Service einfach einfach Composed Service Empfehlung • komplexe Logik mit Verzweigungen • mehr als 2 Services in einer Sequenz und Transformation der Datenmodell Empfehlung Empfehlung: BPEL oder BPMN Nutzung nicht empfehlenswert Empfehlung: EDN Nutzung nicht empfehlenswert nur JDeveloper jede Java EE-Entwicklungsumgebung MEP Serviceklassifizierung Prozess Services Event-Driven SOA bis max. 3 Services in einer Sequenz und geringer Transformationslogik Serviceentwicklung Werkzeug + Frameworks Entwicklung oft deklarativ, unterstützt durch viele Wizzards Manuelle Entwicklungs, ggf. WizzardUnterstützung je nach Framework Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 23 von 27 und IDE Integration XSLT-Mapper und Adapter, z. B. Datenbank, FTP etc. verfügbar manuelle Integration notwendig Lifecyclemanagement Versionierung von SCA’s durch Infrastruktur bereitgestellt. Versionierung muss manuell definiert und umgesetzt werden. Security über Java EE und OWSM möglich über Java EE und OWSM möglich Management und Betrieb End-to-End Monitoring für alle SCA’s gleichermaßen möglich End-to-End Monitoring muss manuell programmiert werden. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 24 von 27 Glossar BEGRIFFE UND ABKÜRZUNGEN BESCHREIBUNG SOA Serviceorientierte Architektur Eine serviceorientierte Architektur ist ein Konzept für eine Systemarchitektur, in welchen Funktionen in Form von wiederverwendbaren, voneinander unabhängigen und lose gekoppelten Services implementiert werden. WSDL Webservice Description Language Auszeichnungssprache auf Basis XML für die Definition von Serviceschnittstellen. SCA Service Component Architecture Ist eine Sammlung von Spezifikationen, die ein Modell für serviceorientierte Architektur beschreiben. Synonym: Composite eine EJB Java Enterprise Beans Spezifiziert ein Komponentenmodell für die Entwicklung von verteilten Serveranwendungen, die in einem JEE-Container betrieben warden können. JCA Java Connector Architecture Definiert eine Architektur um Anwendungen in die JEE-Plattform zu integrieren. JMS Java Messaging Serv ABKÜRZUNGEN ice Definiert eine Programmierschnittstelle, um Nachrichten in Verbin dung mit einer Message Oriented Middleware (MOM) zu empfangen und zu senden. FMW Oracle Fusion Middleware Middleware-Plattform von Oracle MDS Master Data Services Zentraler Service, innerhalb der FMW, zum Verwalten von Konfigu rationseinstellungen und Customizations. Das MDS wird durch di verse FMW-Produkte, z. B. Oracle SOA Suite verwendet. BPEL Business Process Execution Language Eine XML-basierte Sprache zum Orchestrieren von Webservices. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 25 von 27 ADF-BC Application Development Framework – Business Component Framework für die Erstellung von JEE-Anwendungen mit deklarativem Ansatz. Business Component ist ein Modul innerhalb von ADF, daß den Zugriff auf Datenbanken kapselt. BAM Business Activity Monitoring Ermöglicht die Ermittlung und Darstellung von Kennzahlen zu SOAApplikationen. REST Represential State Transfer Beschreibt Architekturkonzepte für Netzwerke mit dem Ziel eines einfachen und zustandslosen Zugriffs auf Ressourcen. Häufig auf Basis des HTTP-Protokolls realisiert (GET, PUT, POST, DELETE). RPC Remote Procedure Call MEP Message Exchange Pattern EDN Event Delivery Network EDA Event Driven Architecture ETL Extract Transform Load OWSM Oracle Webservice Manager Referenzen • Open CSA bei OASIS (http://www.oasis-opencsa.org/sca) • JEE 6 Technologies (http://www.oracle.com/technetwork/java/javaee/tech/index.html) • SOA Suite Developer’s Guide 11.1.1.5 (http://docs.oracle.com/cd/E21764_01/integration.1111/e10224/toc.htm) • Webservices Adressing Working Group (http://www.w3.org/2002/ws/addr/) Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 26 von 27 Autor: Markus Lohn esentri AG Pforzheimer Straße 132 DE – 76275 Ettlingen Tel +49 (0) 7243 / 354 90 0 Fax +49 (0) 7243 / 354 90 99 [email protected] www.esentri.com © 2013 esentri AG Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 27 von 27
