Technical White Paper

Transkript

1 Technical White Paper Services mit Oracle SOA Suite oder Java EE implementieren esentri AG Pforzheimer Straße 132 DE Ettlingen Tel +49 (0) 7243 / Fax +49 (0) 7243 / info@esentri.com August 2013 AN 13-Services mit Oracle SOA Suite oder Java EE implementieren Technical White Paper, Seite 1 von 27

2 Einleitung... 3 Voraussetzungen... 3 Architekturaspekte... 4 Service-Infrastruktur... 4 Komponentenmodelle... 6 Message-Exchange Patterns... 8 Event-Driven SOA Klassifizierung von Services Service-Entwicklung Entwicklungswerkzeuge Serviceschnittstellen Serviceprogrammierung Lifecyclemanagement Security Management und Betrieb Fazit Glossar Referenzen Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 2 von 27

3 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

4 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

5 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

6 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

7 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 SCA- Container 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 JAX- WS 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, PO- JO s oder EJB definiert. Anschließend erfolgt die Generierung der WSDL und XML- Schematas auf Basis der Java-Definitionen. Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 7 von 27

8 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

9 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 EE- Frameworks 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. Callback- Funktionen 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 WS- Adressing werden alle notwendigen Informationen für die Nachrichtenzustellung in den SOAP- Header 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

10 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

11 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

12 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

13 Service-Entwicklung Entwicklungswerkzeuge Die Entwicklung von JEE-basierten Services kann mit jedem beliebigen Java- Entwicklungswerkzeug, 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 IDE- Unterstü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 Java- Entwicklungsumgebung 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 Sourcecode- Analyse 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

14 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 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. XLST- Tranformer 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

15 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 XLST- Tools 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

16 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

17 Abbildung 9: Unittest für Composite definieren Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 17 von 27

18 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

19 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

20 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 EE- Server 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