Technical White Paper - esentri AG · Event-Driven SOA ... Verarbeitung anschließend fort. Jedoch möchte der Nutzer nach erfolgreicher Verarbeitung der Anfrage durch den Anbieter

AN 13-Services mit Oracle SOA Suite oder Java EE implementieren Technical White Paper, Seite 1 von 27

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

Technical White Paper - Services mit Oracle SOA Suite oder Java EE implementieren, Seite 2 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


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 Entwicklungser-fahrung 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 Daten-typen auf Basis WSDL und XSD der Contract First-Ansatz zum Einsatz kommt.


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 Infrastrukturkompo-nenten, wie z. B. eine Datenbank für Fachdaten, bereitzustellen. Diese Komponenten werden nach-folgend 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


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 Konfigurati-onsdaten der SOA Suite und alle installierten Composites gespeichert. Im Schema SOAINFRA wer-den 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 über-wacht und gesteuert werden. Diese Werkzeuge sind WebLogic Server Console und Fusion Middle-ware Control bzw. Cloud Control.

Ein SCA wird in Form einer *.jar zu einer installierbaren Einheit zusammengebaut. Der Aufbau ei-nes 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 instal-liertes 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 Imple-mentierung 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.


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 An-wendungen 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 Compo-nentes Nachrichten miteinander aus. Dabei ist die konkrete Implementierung einer Component zunächst unerheblich. In der SOA Suite werden folgende konkrete Implementierungen für Compo-nents 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


• 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 imple-mentieren. 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 Webs-ervices 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 Pro-grammiersprache 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 Nachrich-ten 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 Auf-gabe 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.


Mit dem Projekt METRO existiert eine Referenzimplementierung für JAX-WS. Weitere Implementie-rungen 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 An-bieters.

Abbildung 4: Request/ Response MEP


• 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äu-tert 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 assozi-iert 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 Ver-arbeitung fort. Der Anbieter verarbeitet die Anfrage und sendet seine Antwort durch Nut-zung einer Callback-Funktion an den Nutzer zurück.


• Publish/ Subscribe

Sofern mehrere Systeme über Zustandsänderungen etc. informiert werden möchten, kön-nen Sie sich auf bestimmte Ereignisse registrieren. Sie warten bzw. beobachten die eintref-fenden Ereignisse. Sobald eine Zustandsänderung in Form einer One-Way-Nachricht veröf-fentlicht wurde, erhalten alle registrierten Beobachter diese Nachricht und können ihre Ver-arbeitung entsprechend fortsetzen.

In der SOA Suite besteht die Möglichkeit einer Correlation mit dem MEP Request/ Callback auf Ba-sis einer intern, eindeutig erzeugten ID oder aufgrund von fachlichen Daten herzustellen. Die Nut-zung 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 Nut-zung 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 dargestell-ten MEP‘s manuell nachprogrammiert werden. Die Informationen über den Aufrufer und die Corre-lation-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 Vor-dergrund 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/ Sub-scribe 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 Entwick-lungsumgebung definiert werden. Darüberhinaus erfolgt die Definition, wann ein Ereignis bereitzu-stellen und konsumieren ist, deklarativ in der Entwicklungsumgebung. Eine gesonderte Program-mierung 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ückzugrei-fen 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 Anwendungsentwick-lung zu berücksichtigen. Die Integrationsaufwände sind im wesentlichen die Definition, Erzeugung, Bereitstellung und Konsumieren der Ereignisse.


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 Implementie-rung. 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 implementie-ren eine fachliche Basisfunktionalität. Typischerweise handelt es sich hierbei um Services, die kurz-laufend 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 erfor-derlich müsste zusätzlich noch ein Adapter vor den eigentlichen Java EE-Service hinzugefügt wer-den, 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 Da-tenmodell-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 Orchest-rierung 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 Com-posite-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 Ab-lauf 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 End-punkte 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.


Prozess-Services

Diese Servicekategorie implementiert komplette Geschäftsprozesse. In dieser Servicekategorie werden auch Services orchestriert, allerdings ist zu beachten, dass der Zustand zwischen den ein-zelnen Serviceaufrufen gespeichert wird.

In der SOA Suite können Services dieser Kategorie unter Einsatz verschiedener Komponenten de-klarativ erstellt werden. Ferner bietet die SOA Suite Funktionen für das Management und Überwa-chung von Services an. Der Zustand zwischen den einzelnen Serviceaufrufen wird in einer Daten-bank gespeichert.

Im Bereich Java EE gibt es keine Lösung für die Implementierung eines Prozess-Servie out-of-the-box. In diesem Fall muss auf ein Produkt oder Framework zurückgegriffen werden. Eine Eigenent-wicklung ist in den seltensten Fällen sinnvoll.


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 unter-scheiden sich die einzelnen Werkzeuge in Komfort und Geschwindigkeit. Üblicherweise bieten die Entwicklungswerkzeuge einen integrierten JEE-Applikationsserver an, der es ermöglicht, die entwi-ckelten 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 SCA-basierten Services kann zum aktuellen Zeitpunkt ausschließlich mit dem Oracle JDeveloper durch-gefü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ög-lichkeit, 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 Serviceoperatio-nen durch Schreiben von Java-Code. Die Struktur des Services wird durch Java-Klassen beschrie-ben. 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.


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 zentra-ler 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 an-schaulich visualisiert. Viele Wizzards unterstützen und vereinfachen die Entwicklung, z. B. XLST-Tranformer um Datenmodelle anzugleichen. Die Programmierung beschränkt sich auf die deklarati-ve Beschreibung und Konfiguration der Komponenten.

Abbildung 7: Composite-Editor im JDeveloper


Darüberhinaus steht mit dem MDS ein Werkzeug zu Verfügung, um WSDL und XSD-Artefakte um-gebungsunabhä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 trans-parent.

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. Bestehen-de POJO/ Spring- und EJB-Komponenten können einfach eingebunden werden. Somit können be-stehende 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 Kom-ponenten 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 wer-den. Die Strategie für das Werfen und Abfangen von Exceptions muss durch den Entwickler manu-ell 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 Fehlerbehand-lung ü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 be-stimmten Fehlersituationen zu erfolgen hat, ohne das der Entwickler im einzelnen Service dies be-rücksichtigten muss.


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 inter-nen 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 erfor-derlich Mocks für externe Services zu erstellen. Deklarativ können Testdaten als Ergebnis dieser Serviceaufrufe in der Entwicklungsumgebung definiert werden.


Abbildung 9: Unittest für Composite definieren


Lifecyclemanagement

Versionsmanagement

Im Rahmen der Bereitstellung von Services muss auch die Frage beantwortet werden, wie mit un-terschiedlichen Versionsständen von Services umgegangen werden soll.

Im Kontext einer Java EE-basierten Entwicklung von Services muss das Versionsmanagement aus-schließlich manuell durchgeführt werden. Die Versionierung bezieht sich nicht nur auf die Schnitt-stellenbeschreibung mit WSDL- und XSD-Dateien, sondern auch auf die Implementierung selbst. Insbesondere die Frage wie unterschiedliche Serviceversionen bereitgestellt werden, sind zu be-antworten. Es existieren eine Reihe von Bestpractices in diesem Umfeld, die manuell auf die eigene Serviceimplementierung angewandt werden können. Ferner ist zu beachten, daß Servicekonsumen-ten explizit die einzelnen Serviceversionen, durch Auswahl der entsprechenden URL, ansprechen müssen. Durch Einsatz zusätzlicher Infrastrukturkomponenten, z. B. Oracle Service Bus, kann die-ser Umstand jedoch vereinfacht werden.

In der SOA Suite unterliegen SCA’s automatisch einer Versionierung. Die Kennzeichnung der Versi-on kann jedoch individuell gestaltet werden. Die einzelnen Serviceversionen sind sichtbar und kön-nen 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.


Entwicklungsprozess

Oftmals ist es erforderlich die Implementierung umgebungsabhängig für die Installation vorzube-reiten (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.


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 eingegan-gen.

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 Deklarati-onen (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 Webser-viceumfeld. Die Umsetzung und Nutzung dieser Standards ist abhängig vom eingesetzten Frame-work 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 di-verse Serviceaspekte über Policies geschützt werden, z. B. SAML-Authentifizierung in Verbindung mit Nachrichtenverschlüsselung. Die Definition der Securityeinstellungen erfolgt deklarativ zur De-signtime im JDeveloper. Ferner besteht auch die Möglichkeit, die Security automatisch oder manu-ell 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


Management und Betrieb

Die Architektur eines Java EE-basierten Webservice ist einfacher zu überwachen und besteht oft-mals 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 EE-Containern 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 Log-ging-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 über-prü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


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 einheitli-che Fehlerbehandlung für alle installierten SCA-Services erfolgen.


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 ge-wä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 Ent-scheidungskriterien tabellarisch zusammengefaßt:

Kriterium/ Technologie SCA Java EE

Infrastruktur (Runtime) benötigt komplexe Infrastruktur: • Applikationsserver • Service Infrastruktur • Datenbank

Applikationsserver ausreichend

MEP

Synchron einfach zu implementieren einfach zu implementieren

Asynchron Nutzung empfehlenswert Nutzung nicht empfehlenswert

Serviceklassifizierung

Elementar Service einfach einfach

Composed Service Empfehlung • komplexe Logik mit Verzweigungen • mehr als 2 Services in einer Se-

quenz und Transformation der Da-tenmodell

Empfehlung

bis max. 3 Services in einer Sequenz und geringer Transformationslogik

Prozess Services Empfehlung: BPEL oder BPMN Nutzung nicht empfehlenswert

Event-Driven SOA Empfehlung: EDN Nutzung nicht empfehlenswert

Serviceentwicklung

Werkzeug nur JDeveloper jede Java EE-Entwicklungsumgebung + Frameworks

Entwicklung oft deklarativ, unterstützt durch viele Wizzards

Manuelle Entwicklungs, ggf. Wizzard-Unterstützung je nach Framework


und IDE

Integration XSLT-Mapper und Adapter, z. B. Da-tenbank, FTP etc. verfügbar

manuelle Integration notwendig

Lifecyclemanagement Versionierung von SCA’s durch Infra-struktur 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 Be-trieb

End-to-End Monitoring für alle SCA’s gleichermaßen möglich

End-to-End Monitoring muss manuell programmiert werden.


Glossar

BEGRIFFE UND BESCHREIBUNG ABKÜRZUNGEN

SOA Serviceorientierte Architektur Eine serviceorientierte Architektur ist ein Konzept für eine Syste-marchitektur, in welchen Funktionen in Form von wiederverwend-baren, voneinander unabhängigen und lose gekoppelten Services implementiert werden.

WSDL Webservice Description Language Auszeichnungssprache auf Basis XML für die Definition von Ser-viceschnittstellen.

SCA Service Component Architecture Ist eine Sammlung von Spezifikationen, die ein Modell für eine serviceorientierte Architektur beschreiben. Synonym: Composite

EJB Java Enterprise Beans Spezifiziert ein Komponentenmodell für die Entwicklung von ver-teilten 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.


ADF-BC Application Development Framework – Business Component Framework für die Erstellung von JEE-Anwendungen mit deklarati-vem 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 SOA-Applikationen.

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/)


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

Documents

Technical White Paper - esentri AG · Event-Driven SOA ... Verarbeitung anschließend fort. Jedoch möchte der Nutzer nach erfolgreicher Verarbeitung der Anfrage durch den Anbieter