Architektur

SOA Suite 12c: erste Erfahrungen aus einem konkreten Proof of Concept

Markus Lohn
Markus Lohn

Im Juli hat Oracle das große Update seiner SOA Produkte mit der Version 12c veröffentlicht. Die einzelnen Module SOA Suite, Service Bus und Event Processing wurden verbessert und stärker integriert. Zusätzlich hat Oracle mit dem Enterprise Scheduler, Managed File Transfer und zusätzlichen Adaptern (z. B. Coherence, LDAP, SAP) das Portfolio sinnvoll ergänzt. Nun geht es um meine ersten Erfahrungen aus einem konkreten Proof of Concept (PoC). Der PoC wurde kurz nach Veröffentlichung des neuen Releases 12c gestartet und umfasste einen Zeitraum von 14 Tagen. Im Rahmen des PoC wurden verschiedene Aufgabenstellungen mit den neuen Produkten umgesetzt:

  • Installation und Konfiguration einer Entwicklungsumgebung für SOA Suite und OSB sowie Einarbeitung von Entwicklern beim Kunden vor Ort
  • Installation mehrerer Middleware-Umgebungen (basierend auf Netzwerkzonen DMZ etc.) als WebLogic Cluster
  • Design und Implementierung von definierten Anwendungsfällen des Kunden
  • Überprüfung Lastverhalten und Ausfallsicherheit

Zielsetzung des Kunden war die Auswahl einer geeigneten Plattform für die Modernisierung der bestehenden Middleware-Komponenten.

Installation und Konfiguration

Infrastruktur

Die Installation von insgesamt drei Umgebungen mit allen Produktbestandteilen der Suite benötigte nicht mehr als 2 Tage. Dabei ist zu beachten, dass 2 Umgebungen jeweils als WebLogic Cluster mit jeweils 2 Managed Server aufgesetzt wurden. Die prinzipielle Vorgehensweise zum Aufsetzen der Umgebungen hat sich nicht wesentlich zur Version 11g geändert. Zunächst muss mit dem RCU die entsprechenden Datenbankobjekte für SOA Suite etc. angelegt werden. Der RCU bietet in der Version 12c eine neue Option zum Erzeugen von SQL-Skripten, um die Datenbank für SOA Suite etc. vorzubereiten. Im vorliegenden PoC wurden SQL-Skripte erzeugt und an den Kunden vorab zur Vorbereitung der Datenbank zur Verfügung gestellt. Diese Vorgehensweise hat sich im PoC bewährt und erlaubt mehr Flexibilität beim Aufsetzen der Datenbank. In der Vergangenheit wurde die Nutzung vom RCU und Bereitstellung der erforderlichen Datenbankrechte immer kontrovers mit den DBAs vor Ort beim Kunden diskutiert. Diese Diskussion sollte in Zukunft hinfällig werden.

SOA 12c

Damit die Cluster-Kommunikation über Multicast funktioniert, musste noch IPv6 im JDK über den Parameter -Djava.net.preferIPv4Stack=true deaktivert werden. Zusätzlich musste auch der Parameter -Djava.security.egd=file:/dev/./urandom gesetzt werden. Im vorliegenden Fall beschleunigte das die Zeit zum Anlegen der WebLogic Domänen über den Wizzard. Der Parameter ist in der Dokumentation von Oracle beschrieben. Zusätzlich ist auffällig, dass nun jeweils ein NodeManager für eine WebLogic Domäne automatisch konfiguriert wird.

Ferner ist zu beachten, dass sich die Nomenklatur für die Ordnerstruktur im Vergleich zum 11g Release geändert hat. Der Begriff Fusion Middleware Home ist entfallen und wird durch Oracle Home ersetzt. Nachzulesen in New and Deprecated Terminology for 12c. Alles in allem hinterließ die Umgebung ein sehr stabilen und performanten Eindruck.

Entwicklungsumgebung

Mit dem SOA Quick Start Installer vereinfacht sich die Installation einer Entwicklungsumgebung drastisch. Lediglich die Größe der Installationsdatei von ca. 3 GB verursachte bei der Bereitstellung in der Kundenumgebung Schwierigkeiten. Ferner ist es erforderlich, dass auf dem Entwicklungs-PC Administrationsberechtigungen vorhanden sind. Beim Kunden vor Ort war das nicht der Fall und so musste der JDeveloper von einer bestehenden Installation kopiert werden. Dabei sind insbesondere die Installationspfade exakt gleich zu benennen, da sonst dieser Workaround spätestens beim Start des internen WebLogic Servers nicht mehr funktioniert.

Für die Nutzung vom JDeveloper inkl. dem gestarteten internen WebLogic Servers mit allen SOA Komponenten ist auf jeden Fall eine RAM-Ausstattung von mind. 8GB zu empfehlen. Beim Kunden vor Ort war die RAM-Ausstattung auf einigen Entwicklungs-PCs nicht ausreichend genug und so konnte der interne WebLogic Server nicht sinnvoll eingesetzt werden.

Im Rahmen der Entwicklung von Anwendungsfällen wurden vor allem verschiedene OSB-Projekte erstellt. Die Integration vom OSB im JDeveloper ist neu und sehr gut gelungen. Insbesondere der Aufbau des Designers erinnert stark an den Composite Editor der SOA Suite. Somit findet sich ein Composite Entwickler sehr schnell zu recht. Besonderes der integrierte OSB-Debugger vereinfacht die Entwicklung in SOA Projekten ganz erheblich. Im Rahmen des PoC war es auch erforderlich Java-Code direkt in OSB-Artefakten anzusprechen. Jedoch berücksichtigt der OSB-Debugger den integrierten Java-Code nicht. Wäre auf jeden Fall eine sinnvolle Erweiterung für ein folgendes Release. Zu beachten ist auch, dass OSB-Projekte ausschließlich in einer OSB-Application zugeordnet werden können. Das Hinzufügen zu anderen Application-Typen funktionierte nicht.

Oftmals zeigt sich in Projekten ein Akzeptanzproblem bei der Nutzung vom JDeveloper. Vor allem JavaEE Entwickler haben eine präferierte Entwicklungsumgebung und wechseln nicht gerne. Der besagte Kunde nutzt für die Java-Entwicklung ebenfalls eine weit verbreitete Entwicklungsumgebung. Vor Ort beim Kunden konnte der JDeveloper 12c als Entwicklungsumgebung überzeugen und es bleibt zu hoffen, dass dieser Punkt in der Zukunft nicht mehr zu endlosen Diskussionen führen wird.

Anwendungsfall 1: Datenintegration zwischen Systemen

Während der PoC-Phase wurden diverse Anwendungsfälle im Bereich der Integration umgesetzt. Ein Anwendungsfall war jedoch besonders interessant. Ausgangsbasis war eine JMS Queue, die eine verschachtelte Java Map von Objekten beinhaltete. Zum Auslesen von Daten aus einer JMS Queue wird üblicherweise der JMS Adapter genutzt. Generell sind die Adapter im Release 12c in einem OSB Projekt sehr einfach nutzbar. Jedoch kann der JMS Adapter lediglich mit Textdaten umgehen. Ein komplexes Java-Objekt kann mit dem JMS Adapter nicht gelesen und verarbeitet werden. Im OSB steht aber immer noch das Konzept der Transports zur Verfügung. Diese bieten vielfach die gleichen Schnittstellen wie das Adapter Framework. In diesem besonderen Fall konnte der JMS Transport hervorragend eingesetzt werden. Mit dem JMS Transport können auch komplexe Java Objekte aus einer Queue ausgelesen und verarbeitet werden. Im OSB Projekt kann dann durch die Integration von Java-Funktionalität das ausgelesene Java-Objekt verarbeitet werden. Somit ist es im OSB möglich auch nicht XML-Daten problemlos zu verarbeiten, wogegen in der SOA Suite ausschließlich mit XML gearbeitet werden muss.

Anwendungsfall 2: SAP-Integration

Im Release 12c wird ein neuer SAP Adapter zur Verfügung gestellt. Im PoC musste ebenfalls die Anbindung an das vorhandene SAP-System implementiert werden. Als Voraussetzungen müssen die SAP-spezifischen Client-Libraries (SAP JCo) auf der WebLogic-Umgebung konfiguriert werden. Diese Libraries werden von SAP für das jeweilige Betriebssystem geliefert. Sofern diese Konfiguration durchgeführt wurde, kann der SAP Adapter im JDeveloper konfiguriert werden. Der Adapter verbindet sich zum SAP-System und erlaubt die einfache Konfiguration von Idoc oder BAPI-Zugriffen.

SOA 12c

Die Integration des SAP-Adapters in einen BPEL-Prozess funktioniert dann sehr einfach als Serviceaufruf.

SOA 12c

Mit wenig Konfigurationsaufwand konnte somit dem Kunden ein sehr einfach und schneller Zugriff auf Daten im SAP implementiert werden.

Einsatz von Maven

Maven ist das Standard Build-Werkzeug in 12c. Im PoC wurde als Maven Repository Artifactory eingesetzt. Oracle liefert mit 12c ein Maven Plugin aus, dass alle relevanten Libraries in ein zentrales Maven Repository überführt. Die Planung, Installation und Konfiguration des Plugins wird im Handbuch “Develop applications using continuous integration“ beschrieben. Die Installation in das Maven Repository auf Basis Artifactory funktionierte ohne Probleme.

SOA 12c

Mein Fazit

Im Rahmen des PoCs wurden vorwiegend SOA Suite, OSB, JMS Adapter, File Adapter, Database Adapter und SAP Adapter genutzt. Aufgrund des engen Zeitrahmens war es leider nicht möglich Enterprise Scheduler und Managed File Transfer einzusetzen. In einigen Anwendungsfällen hätten diese Komponenten hervorragend genutzt werden können.

Die Entwicklung vereinfacht sich durch JDeveloper 12c und den integrierten SOA Komponenten erheblich. Insbesondere die Debugging-Möglichkeiten von OSB-Projekten direkt im JDeveloper sowie die Maven-Integration stechen besonders heraus. Vor allem durch den deklarativen Ansatz im JDeveloper und die hohe Anzahl von verfügbaren Adaptern ist wenig manuelle Programmierung erforderlich. Das hat der Kunde auch im Vergleich zum Mitbewerb positiv herausgestellt. Im PoC wurden 90% der Artefakte deklarativ erstellt. Bereits in dieser frühen Phase der Verfügbarkeit von 12c laufen die einzelnen Komponenten sehr stabil. Insbesondere die Fortführung und Verbesserung der vorhandenen Architektur sowie die Auslieferung von neuen Funktionen können einen baldmöglichsten Umstieg auf 12c interessant machen. Eine Übersicht aller neuen Features in 12c ist hier zu finden.

Schulungen rund um Oracle SOA Suite 12c

21.11. in Nürnberg: SOA Suite 12c – Deep Dive & New Features. Anmelden unter https://www.esentri.com/events/soa_suite_12c_schulung/