SOA-Werkzeuge: Kommerzielle und Open Source Tools

08.08.2007 von Klaus Manhart
Für die Umsetzung von serviceorientierten Geschäftsanwendungen bieten kommerzielle Software-Hersteller wie IBM, SAP und BEA leistungsfähige Tools an. Alternativ lässt sich aber auch mit Open-Source-Werkzeugen eine Plattform für SOA-Anwendungen zusammenstellen.

SOA ist in erster Linie ein abstraktes IT-Konzept, das mit konkreter Software zunächst wenig zu tun hat. Das Erstellen einer SOA-Anwendung erfordert allerdings eine Vielzahl an Technologien. Dazu gehören zum Beispiel ein Enterprise Service Bus, eine Prozess-Engine, eine Regel-Engine, Unterstützung von SOAP-Webdiensten und vieles mehr.

Kommerzielle Software-Hersteller wie IBM oder SAP und SOA-Spezialisten wie BEA nehmen für sich in Anspruch, im Bereich SOA eine führende Rolle zu spielen und über ausgereifte Produkte zu verfügen. Auch im Open-Source-Segment gibt es eine Reihe von Tools, die für den SOA-Einsatz in Frage kommen. Ein paar ausgewählte Beispiele stellen wir Ihnen in diesem Beitrag vor.

Dabei sollte man die Vor- und Nachteile beider Ansätze immer im Hinterkopf haben. Kommerzielle Produktfamilien für SOA versprechen abgestimmte, leistungsfähige Technologien mit professionellem Support. Wenn alles aus einer Hand ist, kann man eine nahtlose Integration der SOA-Werkzeuge erwarten. Sollte ein Problem auftauchen, wird es meist vom Hersteller gelöst.

Allerdings hat der Einsatz von kommerziellen Produkten im Allgemeinen sehr hohe Lizenzkosten zur Folge. Vor allem unterliegen Anwender einem strategischen Risiko, da sie der Lizenz- und Versionspolitik des Herstellers ausgeliefert sind und eventuell durch proprietäre Produkteigenschaften eingeschränkt werden.

Grundlagenserie: Serviceorientierte Architekturen

Teil 1

Serviceorientierte Architekturen – Grundlegende Konzepte

Teil 2

Web Services – Grundlagen, Aufbau und Struktur

Teil 3

Nachrichten verschicken mit SOAP - Die SOAP-Spezifikation

Teil 4

Web Services implementieren mit WSDL

Teil 5

Verzeichnisdienste für Web Services

Teil 6

Sicherheit bei Web Services

Teil 7

SOA-Werkzeuge: Kommerzielle und Open Source Tools

SAP Software-Werkzeuge

SAP bietet eine vollständige Infrastruktur für SOA auf der Basis von Web Services an. Netweaver ist hier die zentrale Integrations-Plattform und Enterprise SOA der architektonische Überbau. Grundlage des SAP-Ansatzes ist der Enterprise Service Community Process – ein Modul, das als Basis für die Entwicklung der SAP Enterprise Services dienen soll.

SAP bietet mit seiner Java-J2EE-Infrastruktur – dem Web Application Server (WAS) 6.4 und dem Netweaver Developer Studio – SOA-Anwendern die Möglichkeit, Web Services zu entwickeln, zu testen und zu nutzen. WAS stellt eine Ablaufumgebung für Web Services bereit, so dass Nutzer auf etablierte Standards nicht verzichten müssen. Die Entwicklungsumgebung ist Eclipse-basiert, wobei SAP Enterprise Javabeans (EJB) 2.0 unterstützt.

SAP: Im Zentrum der SOA-Philosophie steht NetWeaver, das Unternehmen einen gleitenden Übergang zur Enterprise SOA ermöglicht.

SOA erweitert das Web Services Konzept um Businessfunktionen - die einzelnen Services stellen einen Teil eins Geschäftsprozesses dar. Entsprechende Benutzeroberflächen lassen sich schnell über einen in die SAP-Umgebung integrierten Wizard generieren. Der Code kann manuell bearbeitet werden, so dass Fehler leicht korrigiert werden können.

Für die Realisierung von xApps setzt SAP auf das Composite Application Framework (CAF) – ein Rahmen zur Erzeugung von Web Services, der eine schnelle Entwicklung von xApps erlaubt. Alle notwendigen Funktionen stellt Netweaver bereit.

IBM Tools – Websphere und Co.

Bei IBM bildet die Websphere-Produktpalette die zentrale Komponente zum Aufbau von SOA-Anwendungen. Geschäftsprozesse werden bei IBM mit dem Business Modeler abgebildet. Die Simulationskomponente erlaubt es, Zeit und Kosten für einzelne Prozessschritte in die Modelle aufzunehmen. Der Modeler ist einfach bedienbar, die Simulationen besonders komplexerer Prozesse sind allerdings sehr zeitintensiv.

Die mit dem Business Modeler simulierten Geschäftsprozesse können mit Websphere weiterverarbeitet werden. Hierfür wird BPEL (Business Process Execution Language) genutzt. BPEL ist eine XML-basierte Sprache zur Beschreibung von Geschäftsprozessen, die durch IBM, BEA und Microsoft im Jahre 2003 entstand. 2003 wurde sie der OASIS zur Standardisierung übergeben.

Die modellierten Geschäftsprozesse können mit BPEL in den Websphere Integration Developer oder in die Entwicklungsumgebung Websphere Rational Application Developer integriert werden. Möglich ist auch der Import in das IBM-eigene Case-Tool. Hier lassen sich die Anforderungen an die einzelnen Services darstellen.

Der Rational Application Developer ist eine integrierte Entwicklungsumgebung, die auf Eclipse und dem gleichnamigen Framework basiert. Er besteht aus einer abgespeckten Variante des IBM Application Servers und Funktionen für Test, Debugging und Profiling.

IBM: Mit dem Business Modeler lassen sich schnell grafische Modelle von Geschäftsprozessen erzeugen.

Zum Erstellen einzelner Web Services bietet IBM einen Wizard, der die Arbeit deutlich vereinfacht. Websphere erstellt im Hintergrund alle nötigen Hilfsklassen und Deskriptoren. Die erstellten Web Services können über eine Eclipse-integrierten Test-Client sofort geprüft werden.

BEA AquaLogic

Während SOA bei IBM und SAP nebenher läuft, versteht sich BEA als ausgewiesener SOA-Spezialist. Kernstück von BEAs SOA-Ansatz ist die AquaLogic-Produktfamilie. Die von Beginn an für SOA entwickelte Suite bietet ein breites Spektrum an Service-Infrastruktur-Produkten für den SOA-Einsatz.

AquaLogic User Interaction ist eine Sammlung von Tools für interaktive Lösungen wie Portale, die eine Service-Infrastruktur nutzen. AquaLogic Messaging liefert Funktionaliäten für die Erkennung, Vermittlung, das Management und die Governance von Services. Im Zentrum steht dabei der AquaLogic Service Bus, ein Produkt, das einen Enterprise Service Bus mit Servicemangement-Funktionen vereint. Die Implementierung von Services soll damit beschleunigt und das Management einer SOA-Architektur vereinfacht werden.

BEA: Der AquaLogic Enterprise Repository's Navigator bildet Beziehungen und Abhängigkeiten zwischen Projekten ab.

AquaLogic Messaging bietet zusammen mit AquaLogic Service Registry eine umfangreiche UDDI V3 Registry. Die Registry dient dabei als zentrale Verwaltung des Lebenszyklus von Services.

BEA AquaLogic Data bildet die Basis für die Integration von Daten. Sie besteht aus der Data Services Platform, die die Erstellung von Datenservices mit einheitlicher Echtzeitansicht aus verteilten Datenquellen erlaubt. Datenservices können damit einfach erstellt, angepasst und wieder verwendet werden.

Sicherheitsmanagement: Die AquaLogic Data Services Platform ermöglicht die Definition von feinkörnigen Zugriffsrechten auf die Informationen.

Zur Sicherung verteilter Anwendungen in einer SOA-Architektur dient schließlich AquaLogic Security. Kernstück ist AquaLogic Enterprise Security, das die Nutzung gemeinsamer Sicherheitsservices über eine heterogene Umgebung hinweg ermöglicht und damit zu optimierter Sicherheit beiträgt.

Open Source Werkzeuge

Ein Nachteil der kommerziellen SOA-Produkte: Sie sind nicht billig. Und man setzt sich der Willkür eines Herstellers aus. Wer sich einmal für ein Produkt entschieden hat, kann dies nur mit größerem Aufwand rückgängig machen.

Einen Ausweg bieten Open-Source-Produkte. Der Vorteil: Lizenzgebühren entfallen und der Quellcode steht zur Verfügung. Letzteres bedeutet vor allem dann ein Plus, wenn Anpassungen notwendig sind. Dies vermindert die Abhängigkeit von einem Hersteller.

Der Markt bietet inzwischen zahlreiche Open-Source-Komponenten, die dazu beitragen können, den Zwang zur Festlegung auf einen bestimmten Anbieter zu verringern und Lizenzkosten zu reduzieren. Deren Nachteil: Da nicht alle Kompenenten aus einer Hand kommen, fehlt die Integration zwischen den Anwendungen.

Um den Grad an Koppelung und Kohäsion zu erreichen, der für eine erfolgreiche IT-Architektur notwendig ist, ist es oft unerlässlich, Dienstleister zu konsultieren, die diese Aufgabe erfüllen. Ein wichtiges Instrument ist dabei die Ausarbeitung eines SOA-Entwurfs, der es dem Dienstleister ermöglicht, in Zusammenarbeit mit dem Auftraggeber die erforderlichen Dienste zu identifizieren und eine Roadmap für die Implementierung zu entwickeln.

Integration - JBoss Enterprise Middleware Suite

Das von Red Hat übernommene Softwarehaus JBoss offeriert mit der quelloffenen JBoss Enterprise Middleware Suite (JEMS) Java-basierende Entwicklungs-Werkzeuge, mit denen SOA-Anwendungen erstellt werden können. JEMS setzt im Wesentlichen auf der Java Enterprise Edition (JEE) auf und erweitert diese um Produkte, die für eine SOA notwendig sind.

Den bekanntesten Baustein von JEMS bildet der JBoss Application Server. Hierbei handelt es sich um ein vollständiges Open-Source-J2EE Middleware-Framework. Neben dem bewährten Application Server zählen zu der Suite eine Prozess-Engine (jBPM, jBoss Process), eine Regel-Engine (JBoss Rules) und der Enterprise Service Bus (JBoss ESB). Mit Seam und Eclipse IDE wird dieses Portfolio durch grafische Entwicklungswerkzeuge abgerundet.

Alle Produkte orientieren sich an den Standards der Java Enterprise Edition und eignen sich auch für komplexere Geschäftsanwendungen. Aufgrund ihrer Standardkonformität und dem modularen Aufbau lassen sie sich auch in unterschiedliche Systemlandschaften integrieren.

JBoss: JEMS setzt sich aus verschiedenen Open-Source-Komponenten zusammen.

Neben den von JBoss entwickelten und gepflegten Produkten enthält JEMS weitere Standardkomponenten aus dem Open-Source-Bereich, beispielsweise die JSF-Implementierung von Apache (JSF = Java Server Faces).

JBoss-Software kann bis auf sehr wenige Ausnahmen kostenlos inklusive Quelltexte heruntergeladen werden und steht unter der LGPL-Lizenz. Finanziert werden die Produkte durch die kommerziellen Dienstleistungen der Firma JBoss. Aktuell deckt JEMS allerdings einige SOA-Bereiche noch nicht zufriedenstellend ab, so dass Nutzer auf alternative Produkte wie Mule und ActiveBPEL ausweichen müssen.

Anwendungen - Java Business Process Management (jBPM)

jBPM verknüpft die Erstellung von Workflow-Anwendungen mit einer flexiblen und skalierbaren Prozess-Engine. Es kann in einer einfach strukturierten Umgebung ebenso eingesetzt werden wie in sehr komplexen Clustern. Obwohl Kernkomponente der JEMS-Suite, kann jBPM auch selbstständig oder auf einem beliebigen J2EE-Applikationsserver genutzt werden.

Hinter jBPM steckt eine Bibliothek, die Zugriff auf dauerhafte Prozesse ermöglicht. Sie lässt sich einfach in Anwendungen und in deren Transaktionsverwaltung integrieren. Da jBPM zusätzlich Anwenderaufgaben unterstützt, eignet sich das System gut für das Umsetzen von Anwendungsprozessen.

Der Ansatz, den JBoss mit jBPM für den Workflow verfolgt, konzentriert sich auf die Kernstruktur der BPM-Engine, die auf zwei Grundprinzipien basiert: zum einen ein sehr einfacher Mechanismus, über den eine schlichte „Status Engine“ gestartet wird. Das soll Java-Entwicklern die Einbindung von jBPM in ihre Projekte erleichtern.

Java Business Process Management: Mit jBPM lassen sich Prozesse und Workflows definieren.

Zum anderen sollen sich die Engine, aber auch komplexe Workflow-Strukturen skalieren lassen. Darüber hinaus nutzt die Engine die native jBPM Process Definition Language (JPDL), die bereits auf existierende Standards und Spezifikationen setzt, darunter BPEL, BPELJ, BPML, BPSS, ebXML, WSCI und XPDL.

Große Geschäftsanwendungen - Enterprise Javabeans

Speziell für große, skalierbare und sichere Geschäftsanwendungen konzipiert sind die Enterprise Javabeans (EJB). EJB sind standardisierte Komponenten innerhalb eines J2EE-Servers (Java Enterprise Edition). Sie vereinfachen die Entwicklung komplexer, mehrschichtiger verteilter Software-Systeme mittels Java. Mit Enterprise JavaBeans können wichtige Konzepte für Unternehmensanwendungen, beispielsweise Transaktions-, Namens- oder Sicherheitsdienste umgesetzt werden, die für die Geschäftslogik einer Anwendung nötig sind.

Enthalten die Geschäftsoperationen viele Geschäftsregeln, ist es sinnvoll, diese außerhalb der eigentlichen Programmlogik mit Hilfe eines Regelinterpreters zu entwickeln. JEMS enthält hierfür JBoss Rules. Dabei handelt es sich um eine Weiterentwicklung des bekannten Systems Drools.

Enterprise Javabeans : EJB vereinfacht die Entwicklung komplexer, mehrschichtiger verteilter Software-Systeme

Das Tool war bis zur Version 2.1 unter Entwicklern umstritten, da die Programmierung sehr kompliziert war und deshalb von vielen abgelehnt wurde. Mit dem folgenden Release EJB3 wurde das Framework auf den neuesten Stand der Technik gebracht und insbesondere das Programmiermodell erheblich vereinfacht.

Von EJB gibt es unterschiedliche Implementierungen von Sun, Oracle und JBoss.

Integration - ActiveBPEL

Von den Anwendungsprozessen sind Integrationsprozesse zu unterscheiden. Sie steuern das Zusammenspiel der verschiedenen Applikationen. In diesem Bereich hat sich für die Spezifikation von Geschäftsprozessen die Business Process Execution Language (BPEL) als Industriestandard etabliert, die oben bereits erwähnt wurde.

Schon länger am Markt verfügbar ist ActiveBPEL, eine komplette Toolkette für die Entwicklung und Ausführung von BPEL-Prozessen. Mit dem integrierten ActiveBPEL Designer steht ein Werkzeug zur Verfügung, mit dem beispielsweise Produktionsprozesse grafisch entwickelt werden können.

Für die Entwicklung und Inbetriebnahme von Geschäftsprozessen stehen Debugging- und Simulationsmöglichkeiten zur Verfügung. Das System lässt sich durch die beschriebenen Technologien jederzeit schrittweise erweitern.

ActiveBPEL wurde für eine Reihe von Technologien wie Java 5 oder Tomcat 5.5 optimiert und kommt mit einer überarbeiteten Konsole sowie Support für die XML-Datenbank Tamino daher. Außerdem wurden die Formate für die Process Deployment Descriptoren (PDD) aktualisiert und mit neuen Attributen versehen

Wird ein Geschäftsprozess im OMG-Standard Business Process Modeling Notation (BPMN) modelliert, lässt sich aus den grafischen Elementen der Diagramme direkt ein ausführbarer Prozess in Form von WS-BPEL-Dateien ableiten.

Objektrelationales Mapping – Hibernate

Objektrelationales Mapping wird am besten über das Open-Source-Tool Hibernate realisiert. Das Framework ermöglicht es, den Zustand eines Objekts in einer relationalen Datenbank zu speichern und aus entsprechenden Datensätzen wiederum Objekte zu erzeugen. Dies bezeichnet man auch als objektrelationales Mapping (O-R-Mapping, kurz ORM).

ORM befreit den Entwickler von der Programmierung von SQL-Abfragen und hält die Applikation unabhängig vom SQL-Dialekt der verwendeten Datenbank. Bei den Objekten handelt es sich um gewöhnliche Objekte mit Attributen und Methoden. Beziehungen zwischen Objekten werden auf entsprechende Datenbank-Relationen abgebildet.

Objektrelationales Mapping mit Hibernate: Links unten der Eigenschaftseditor für Objekte.

Hibernate ist ebenfalls in JEMS enthalten. Alternativ einsetzbar sind die EJB3 Entity Beans. Sie sind besser mit den anderen EJB3-Komponenten verbunden und bieten ein Programmiermodell, das Hiberante ähnlich ist.

Für die lokale Integration steht mit der Java Connection Architecture (JCA) eine JEE-Spezifikation für den Zugriff auf externe Geschäftsinformationssysteme zur Verfügung.

Enterprise Service Bus

Einen Enterprise Service Bus (ESB) enthält die JBoss-Suite mit JBoss EBS. Für den breiten Einsatz fehlen derzeit aber noch wichtige Funktionen. Schon lange erfolgreich im Einsatz ist hingegen Mule von der Open-Source-Gruppe Codehouse.

Mule ist ein Framework, um eine einheitlich Kommunikation zwischen verschiedenen Applikationen zu ermöglichen. Sämtliche Kommunikation ist Event-basiert, d.h. ausgetauschte Informationen, sei es nun innerhalb Mules oder mit anderen externen Services, werden von Mule als Ereignisse behandelt.

Mule verfolgt dabei nicht den Weg eines klassischen ESB. Die Mule zugrund liegende Enterprise Service Network (ESN) Architektur ist weitaus flexibler als die der herkömmlichen ESBs. Die jeweiligen Komponenten können auch über andere Topologien, wie beispielsweise Peer-to- Peer, Client/Server oder Pipeline kommunizieren.

ESB: Mule kann mit verschiedenen SOA-Technologien zusammenarbeiten.

Ein weiterer Punkt, der Mule zu einem sehr leistungsfähigen Werkzeug für SOA macht, ist die große Anzahl von Integrationsmöglichkeiten. Zum einen kann die Kommunikation über die verschiedensten Transportprotokolle stattfinden. Das erleichtert das Einbinden externer Services. Zusätzlich können mehrere Muleserver untereinander kommunizieren. Da es möglich ist, Muleinstanzen in anderen Frameworks wie z.B. JBI-Container oder J2EE Application Server zu deployen, können auch diese integriert werden.

Schließlich können mit Mule auch diverse andere Technologien genutzt werden, wie z.B. die Verwaltung von EJBs, die Integration von BPEL sowie die Nutzung diverser Skriptsprachen. Die komplette Liste sämtliche Integrationsmöglichkeiten ist auf der offiziellen Mule-Homepage zu finden.

Fazit

Kommerzielle SOA-Anbieter haben den Vorteil, dass man alles aus einer Hand bekommt und die Anwendungen nahtlos ineinander übergreifen. Von den drei großen SOA-Anbietern, den Allroundern SAP und IBM und dem Spezialisten BEA hat jeder seine Schwerpunkte. So hat IBM im Bereich Enterprise Service Bus und Betrieb die Nase vorn, während SAP mit der Nähe zu den eigenen Anwendungen punktet.

SOA-Spezialist BEA schreibt sich hingegen die Vorreiterrolle im zukunftsträchtigen Markt der vollständigen SOA-Suiten auf die Fahne. Mit AquaLogic bietet BEA ein komplettes Werkzeugpaket, das kaum Lücken erkennen lässt.

Eine Art SOA-Suite – allerdings mit größeren Leerstellen – gibt es auch im Open Source Bereich. Die JBoss Entrerprise Middleware Suite vereint eine Vielzahl quelloffener Tools und wird von Red Hat aus einer Hand angeboten. Die Toolsammlung bietet eine Menge gut harmonierender Techniken, die zukunftssicher sind und für die professioneller Support verfügbar ist. (ala)

Grundlagenserie: Serviceorientierte Architekturen

Teil 1

Serviceorientierte Architekturen – Grundlegende Konzepte

Teil 2

Web Services – Grundlagen, Aufbau und Struktur

Teil 3

Nachrichten verschicken mit SOAP - Die SOAP-Spezifikation

Teil 4

Web Services implementieren mit WSDL

Teil 5

Verzeichnisdienste für Web Services

Teil 6

Sicherheit bei Web Services

Teil 7

SOA-Werkzeuge: Kommerzielle und Open Source Tools