Clojure. magazin. Java Mag. Quo vadis Clojure Zugriff auf relationale Datenbanken 32. Polyglotte Entwicklung mit Clojure und Java 24

Transkript

1 Der Tod der Java Application Server: Sind sie noch zeitgemäß? 55 Java Mag Deutschland 9,80 Österreich 10,80 Schweiz sfr 19,50 Luxemburg 11, magazin Java Architekturen Web Agile RoboVM ios-apps mit Java entwickeln 115 ServiceMix Schlanke Systemintegration 91 Erste Programminfos ab Seite 47! Clojure Quo vadis Clojure Zugriff auf relationale Datenbanken 32 Polyglotte Entwicklung mit Clojure und Java 24 istockphoto.com/sololos Fieldings Vermächtnis: Wer REST will, muss mit HATEOAS ernst machen 64 IoT mit Java 8 und Tinkerforge: Baukasten für große Kinder 38 Mächtig flexibel: Konzepte des Ceph-Storage- Clusters 103

2 ServiceMix Web Schlanke Systemintegration in der Praxis Integration lösen Wer Websysteme entwickelt, kennt die wachsenden Mühen und damit verbundenen Unwägbarkeiten bei einer zunehmenden Zahl an Systemintegrationen. In einem sich stetig wandelnden und beschleunigten Geschäftsumfeld sind aber weniger Anstrengungen und Risiken gefragt. Apache ServiceMix [1] ist ein Open Source Enterprise Service Bus (ESB), der heute für hochgradig skalierbare Systeme geeignet ist. Lesen Sie, wie er eingesetzt wird, um einen verteilten Geschäftsprozess zu realisieren, der von Kunden über das Web ausgelöst wird. von Daniel Takai, Raúl Kripalani und Matthias Rothe Stellen Sie sich vor, Sie arbeiten für ein Einzelhandelsunternehmen, das Produkte auf der ganzen Welt verkauft. Der Hauptsitz der Firma befindet sich in Deutschland, aber es gibt regionales Marketing sowie Finanz- und HR-Abteilungen in jedem wichtigen Markt (EMEA, APAC, US, LATAM etc.). Zudem betreibt die Firma pro Land eine eigene Logistik, Warenlager und Customer- Relationship-Management-Systeme (CRM). In diesem Beispiel nutzen Kunden die Website des Unternehmens zur Produktbestellung. Die Produkte werden dann von der jeweiligen Länderorganisation versandt. An der Ausführung dieses Shopping-Workflows ist eine Reihe von Systemen beteiligt: Product-Information-Management-(PIM-) und Inventory-Control-Systeme (ICS) werden eingesetzt, um einen Artikel zu finden; beide sind Java-Enterprise- Applikationen. Ein Warenkorbsystem (eine.net-anwendung) nimmt Artikel auf, während der Nutzer den Einkauf fortsetzt. Ein E-Commerce-Payment-Gateway (B2B-Transaktion) ist am Check-out beteiligt. Es handelt sich um eine SaaS-Anwendung. (Mainframe-)Logistiksysteme übernehmen dann das Zepter, um den Versand an den Kunden in Gang zu setzen. Versandpartner und ihre Tracking-Systeme sind ständig an der Auslieferung beteiligt (B2B). CRM-Systeme halten aktuelle Informationen während des gesamten Prozesses bereit. Betrachtet man das Szenario sorgfältig, dann sieht man eine Geschichte der Integration: Diverse Geschäftseinheiten, alle mit ihren spezifischen Applikationen, schließen sich zusammen, um eine Reihe von Geschäftstransaktionen zu erledigen. Dabei spielen die Orchestrierung und Choreografie der Applikationen eine Schlüsselrolle. Wir benötigen einen Dirigenten, der die Vorgänge koordiniert: Sowohl Datentransformationen sind auszuführen, als auch Validierung, Auditing, Security, Fehlerbehandlung etc. Wobei immer in Betracht zu ziehen ist, dass Systeme vermutlich mit heterogener Technologie gebaut wurden, etwa mit.net, Java, Cobol, Mainframe etc. Um diese vielfältigen Herausforderungen zu bewältigen, setzen wir auf Apache ServiceMix als ESB. Der Apache Integration Stack Apache ServiceMix ist eine Open Source und auf Standards basierende Integrationsplattform, zugeschnitten auf Echtzeitintegration in einem heterogenen Systemumfeld. Es wird durch mehrere Apache-Projekte unterstützt, die in der Middleware-Industrie als Best of Breed bekannt sind: Apache ActiveMQ, ein stabiler JMS-Broker [2]. Apache Camel [3], das bekannte Integrationsframework mit mehr als 200 Konnektoren und über vierzig unterstützten Datenformaten, basiert auf dem Konzept der Enterprise Integration Patterns [4]. Apache CXF, der Apache Web Services Stack [5]. Apache Karaf, ein OSGi Container als Laufzeitumgebung [6]. Abbildung 1 zeigt die Details des Technologiestacks. ServiceMix-Bausteine Wenn man Systemintegrationen in hoher Qualität herstellen möchte, dann ergibt es Sinn, eine Technologie einzusetzen, die hierfür entworfen wurde. Das Open- Source-Lizensierungsmodell und die schlanke, stabile javamagazin

3 Web ServiceMix Abb. 1: Der ServiceMix Technologie-Stack Abb. 2: Exemplarische Bausteine der Architektur Architektur von ServiceMix machen es zu einem guten Kandidaten in kleinen wie auch in größeren Systemen. Die Grundarchitektur, die wir hier zeigen möchten, besteht aus einem Consumer, einem Business- oder Data- Service sowie ServiceMix in der Mitte (Abb. 2). Innerhalb von ServiceMix nutzen wir drei Schichten, um unsere Integrationsziele zu erreichen. Die Trennung bewirkt eine klare Teilung der Verantwortlichkeiten und damit die Entkopplung der einzelnen Schichten. Wie immer ist das Ziel, dass Änderungen an einer Schicht nicht notwendigerweise Änderungen in anderen Schichten nach sich ziehen. Das Frontend-Servicemodul nimmt Anfragen vom Consumer entgegen und kann für jedwedes Protokoll geschrieben werden; gewöhnlich ist dies REST mit einer JSON Payload für die Nachrichten, da JSON mit dem JavaScript-Code im Browser kompatibel ist. Das Frontend-Modul validiert die ankommenden Requests und leitet sie an das richtige Businessmodul weiter. Es ist zudem verantwortlich für Authentifizierung und (soweit möglich) Autorisierung. Das Frontend-Modul transformiert außerdem eine hereinkommende Anfrage in das kanonische Datenmodell (siehe unten). Das Businessservicemodul wird benötigt, wenn eine anspruchsvollere Integration erforderlich ist. Das Modul kann eine Batchverarbeitung von Nachrichten durchführen, Nachrichten teilen oder ist sogar für Serviceorchestrierung zuständig. In den meisten dedizierten Integrationsschichten, denen wir während der Entwicklung von Websystemen begegnen, ist dies der Ort, wo wir auch den Geschäftsprozess ansiedeln. Somit ist der Businessservice oft auch damit beauftragt, qualifizierte Geschäftsfehler zu erzeugen, die im Error Catalogue dokumentiert werden (siehe unten). Ein Backend-Servicemodul sendet eine Anfrage an den externen Service und validiert die Antwort. Da es eng an das Backend-System gekoppelt ist, versteht es dessen Datenmodell und kann dieses in das kanonische Datenmodell übersetzen. Daher muss allerdings die Version genau passen, da Backend-Systeme sich meistens in andauernder Entwicklung befinden und sich auch ihre Schnittstellen verändern. Das Backend-Modul stellt in unserer Architektur die Zuverlässigkeit und Stabilität sicher. Synchrone Services, die versagen oder willkürlich antworten, machen die Architektur anfällig. Dieser Layer hat die Verantwortung, solches Verhalten zu erkennen und sicherzustellen, dass es nicht die Gesamtstabilität beeinträchtigt. Wer mit vielen unzuverlässigen Services zu tun hat, kann sich als Alternative überlegen, einen asynchronen Weg einzuschlagen, wenn dies der Geschäftsprozess gestattet. Semantische Integration Zwei bedeutende Artefakte werden für die Integration auf der semantischen Ebene benötigt: 92 javamagazin

4 ServiceMix Web Abb. 3: Verteilte ServiceMix-Architektur Das Canonical Data Model (CDM): Es ist für gewöhnlich eine Teilmenge des Domänenmodells der Zielorganisation. Es enthält die Konzepte, die an der Integration beteiligt sind, sowie ihre Beziehungen untereinander. Wir nutzen dieses Modell als gemeinsame Sprache unserer Integrationsgeschichten. Wenn sich eine Integration in dieser Sprache ausdrücken lässt, dann lässt sie sich auch implementieren. Jede eingehende Payload wird in Konzepte unseres Modells übersetzt und an Business- und Backend-Module weitergeleitet, die somit von den Consumer-Systemen entkoppelt werden: Sie arbeiten nur noch mit Nachrichten in unserer Sprache, die Sprache des Consumers spielt keine Rolle mehr. Dies ist eine Umsetzung des Normalizer Patterns, wie es in Enterprise Integration Patterns [4] definiert wird. Das Modell sorgt also für die konzeptuelle Integrität, die Frontend- und Businesskomponenten von Änderungen in den Backend-Systemen abschirmt (semantische Entkopplung). Zudem begünstigt das CDM die Datenwiederverwendbarkeit im Kontext der Serviceorchestrierung. Der Common Error Catalogue ist das zweite Artefakt, das wir benötigen. Der Katalog ist eine Systematik aller Fehlersituationen, die während des Integrationsprozesses auftauchen könnten, bspw. Business Errors, Validation Errors, Communication Errors etc. Das Backend-Servicemodul übersetzt alle Fehler jeglicher nativen Form (bspw. SOAP Fault, HTTP Status Code, TCP Byte Marker etc.) in Error-Catalogue-Codes, damit alle Upstream-Teilnehmer die Situation erfolgreich interpretieren können. Unter vielen Vorteilen erlaubt dies den Auslieferungskanälen (in Websystemen oft ein CMS) diesen Error-Code zu nutzen, um eine korrekt übersetzte und passende Antwort für den Endkunden zu erzeugen. Federated SOA mit ServiceMix Kehren wir nach diesem Ausflug in die Theorie nun in die Praxis zurück. Wir behalten unsere Basisarchitektur, erweitern diese aber nun noch um den Aspekt der weltweiten Verteilung und Multikanalfähigkeit (Abb. 3). Im Beispiel ist die Verteilung wichtig, da die Organisation ihre Bestände global bewirtschaftet. Ziel ist es, ein Produkt aus dem Warenlager in Atlanta an einen Schweizer Kunden schicken zu können, falls dieses im regionalen Lager nicht vorrätig ist. Doch dazu müssen verschiedene geografische Regionen miteinander kooperieren und ihre Daten hinsichtlich der verfügbaren Bestände teilen. ServiceMix erlaubt den Aufbau einer Föderation von Instanzen. Gelöst wird dies durch ein Broker-Netzwerk auf Basis von ActiveMQ. Im Beispiel stöbern die Kunden im globalen Store und geben ihre Bestellungen entweder über eine Website oder eine App auf. Dazu einige technische Details: Die Website und die Smartphone-Apps kommunizieren mit einem Cluster von ServiceMix-Instanzen mittels REST-Aufruf mit JSON Payload. Die ServiceMix-Instanzen enthalten jeweils einen ActiveMQ JMS Broker für die Verteilung von Nachrichten untereinander. Jede geografische Zone nutzt ServiceMix auf Regionen- und Länderebene. Sie sind miteinander in einer baumähnlichen Form verbunden, entsprechend der geografischen Hierarchie. Kernanwendungen (wie ein globales Abrechnungssystem) sind mit einer zentralen ServiceMix-Instanz verbunden, wohingegen regionale Applikationen mit regionalen ServiceMix-Instanzen verbunden sind. Die Integrationslogik wird mit Camel Routes umgesetzt. javamagazin

5 Web ServiceMix Eine Camel Route ist eine Abfolge von Schritten, die bei der Bearbeitung von Nachrichten angewandt wird. Zu dem Nachrichtenfluss gehören Routing-Regeln, Decisions, Transformations, Mediation, Security, Logging usw. Camel unterstützt über 200 Integrationstechnologien out of the box, dazu gehören WS-*, REST, JMS, TCP, FTP, File, Caches, SQL, NoSQL usw. Listing 1 from("restlet: stock?method=get") // (1).unmarshal().xmljson() // (2).to("validator:stock-availability.xsd") // (3).to("xslt:stock-availability-request.xsl") // (4).to("jms:organization.processes.stock.availability")) // (5).to("xslt:stock-availability-response.xsl") // (6).marshal().xmljson(); // (7) Listing 2 from("jms:organization.processes.stock.availability") // (1).onException(Exception.class).setBody(simple("<error>${exception}</error>")) // (2).end().multicast().parallelProcessing() // (3).aggregationStrategy(new MergeStockAvailabilityStrategy()).to("jms:organization.services.emea.germany.stock.availability")) // (4).to("jms:organization.services.us.atlanta.stock.availability")) // (5).to("jms:organization.services.apac.singapore.availability")) // (6).end(); Listing 3 from("jms:organization.processes.stock.emea.germany.availability").to("xslt:stock-availability-emea-germany-request.xsl").to("cxf: Beispiel 1: Lagerinformationen aus föderierten Warenwirtschaftssystemen Unsere erste Camel Route nimmt Einkäufe von der Website oder der App an, validiert diese und übersetzt sie in unser CDM, damit sie an das Businessmodul gesendet werden können (Listing 1). Mit nur wenigen Zeilen Code haben wir nun Folgendes erreicht: 1. Einen HTTP GET per Camel-Restlet-Komponente angenommen, in diesem Fall mit dem dynamischen Pfadparameter {productid}, der als Camel-Header weitergereicht wird 2. Transformation der Request Payload von JSON nach XML (Camel-XML-JSON-Datenformat) 3. Validierung des Inputs per XML-Schema (Camel- Validator-Komponente) 4. Normalisierung des Aufrufs in unser CDM (Camel- XSLT-Komponente) 5. Senden der Nachricht an unser Businessmodul via JMS (Camel-JMS-Komponente) 6. Übersetzung der Antwort des Businessmoduls in das spezifische Datenmodell unseres Channel-Systems (Camel-XSLT-Komponente) 7. Transformation der Antwort von XML nach JSON, damit sie im Browser oder der App gut ausgewertet werden kann Unser Businessmodul holt sich dann den Aufruf ab, der in Schritt 5 gesendet wurde und wendet eine Orchestrierung an, um die Daten aus drei verschiedenen Quellen einzusammeln (Listing 2). Und das geschieht dabei: 1. Wir nutzen einen Camel-JMS-Endpunkt, um die Nachricht aus der JMS Queue abzuholen. Hier im Beispiel verwenden wir einen trivialen Error Handler, um alle Fehler abzufangen. Tritt ein Fehler auf, so wird dieser 1:1 weitergeleitet. 2. Wir senden die Nachricht parallel an drei verschiedene JMS Queues und führen die individuellen Antworten in eine einzige aggregierte Antwort zusammen (Multicast Pattern). 3. (4), (5), (6) sind die Endpunkte, wo wir die Information einsammeln. Wie in obigem Diagramm unserer Lösungsarchitektur gezeigt, sind die Warenwirtschaftssysteme über verschiedene, regionale Instanzen von ServiceMix mit dem zentralen ESB verbunden. Deshalb routen die ActiveMQ Broker in unserer föderierten SOA die Nachrichten intelligent durch das Broker-Netzwerk zum Consumer. Das ist kein Versuchs-und-Irrtum-Routing, sondern ein sorgfältig durchdachter Routing-Plan, der in Betracht zieht, wo sich die Konsumenten im Netzwerk tatsächlich befinden. Innerhalb unseres Architekturmodells sind es die Back end-module, die letztlich mit den Backend-Systemen interagieren. Wir nutzen hier drei Stück: ein Modul 94 javamagazin

6 ServiceMix Web Abb. 4: Bestellprozess pro Warenwirtschaftssystem, wobei jedes System mit einer anderen Technologie kommuniziert, weil die Warenwirtschaftssysteme unterschiedlich sind. Das Backend-Modul übersetzt also vom CDM in die Sprache des Backend-Systems und führt den Aufruf durch. Das deutsche Warenwirtschaftssystem kommuniziert via SOAP 1.2 und HTTPS. Wir verwenden deshalb die Camel-CXF-Komponente (Listing 3). Der Backend-Service für das Warenwirtschaftssystem in Singapur ist eine Datenbank. Wir greifen über eine JDBC-Verbindung zu und nutzen hierfür ein Prepared Statement, dessen Parameter über Camel-Header gesetzt werden. Den passenden Header bestücken wir per XPath (Listing 4). Zu guter Letzt holen wir die Informationen aus dem Backend-Service für das Warenwirtschaftssystem in Atlanta, das ein proprietäres TCP-Kommunikationsprotokoll nutzt. Deshalb verwenden wir hier die Camel- Netty-Komponente (Listing 5). Jedes dieser Backend-Systeme normalisiert die Antwort des Warenwirtschaftssystems mit einer XSLT-Transformation zurück in unser kanonisches Datenmodell. Mit der sich daraus ergebenden Nachricht kümmert sich Camel dann um eine automatische Antwort an den Aufrufenden. Beispiel 2: Aufgabe einer Bestellung und Koordination der Systeme um einen Geschäftsprozess Wenn ein Kunde eine Bestellung aufgibt, wird der folgende Geschäftsprozess ausgeführt: Für jeden Artikel prüfen wir die Verfügbarkeit, da sich diese geändert haben könnte. Wir verwenden die obige Lösung wieder und ernten somit die Früchte unserer sauberen Architektur. Wir rufen den E-Commerce-Payment-Gateway auf, um die Zahlung zu bearbeiten. War dies erfolgreich, wird der Auftrag versendet. Als Nächstes wird das zentrale CRM über die Auftrags-ID, die Versanddetails und den Inhalt des Auftrags informiert. Der Geschäftsprozess ist in Abbildung 4 beschrieben. Aus Platzgründen zeigen wir hier nur ein Codebeispiel für das Businessmodul, das den Geschäftsprozess koordiniert. Freilich würde die Gesamtlösung auch die Frontend-Services und die Backend-Services umfassen. Listing 4 from("jms:organization.processes.stock.apac.singapore.availability").setheader("productid", xpath("/cdm:request/cdm:product/cdm:id").namespace("cdm", " available from STOCK where PID = :#productid").to("xslt:stock-availability-apac-singapore-response.xsl"); Listing 5 from("jms:organization.processes.stock.us.atlanta.availability").to("xslt:stock-availability-us-atlanta-request.xsl").to("netty:tcp://inv-stock-atl.orga.com:4567?textline=true").to("xslt:stock-availability-us-atlanta-response.xsl"); javamagazin

7 Web ServiceMix Der Businessservice ist eine schlanke Orchestrierung, die mit Camel-Routing-Logik implementiert ist. Er kommuniziert mit den Frontend- und Backend-Modulen einzig über JMS Endpoints und nutzt dabei immer das CDM. Da dieses auch Bedingungen an die Datenqualität erhält, muss sich das Businessmodul nicht mehr mit Validierungen oder Transformationen plagen, sondern kann sich auf seine eigentliche Aufgabe konzentrieren (Listing 6). Wir nutzen das Splitter Pattern, um die Bestellung in ihre einzelnen Positionen zu zerlegen, die wir individuell und parallel weiterverarbeiten. Die Ergebnisse werden von der konfigurierten Aggregationsstrategie zusammengeführt und dann weiterverarbeitet. Wir nutzen das Choice Pattern, um nun eine Entscheidung zu fällen. Falls wir nicht ausreichend Lagervorräte für einen Artikel haben, verursachen wir einen qualifizierten Geschäftsfehler und brechen den Prozess ab; andernfalls fahren wir fort. Wir benutzen einen Camel Direct Endpoint für eine bessere Codeorganisation, um die Route in kleinere Teile aufzubrechen. Wir rufen das Bezahlsystem auf; falls die Zahlung fehlschlägt, weisen wir eine weitere Business Exception an und brechen den Prozess ab (6). Wenn alles gut geht, lösen wir den Versandvorgang aus, indem wir eine JMS Message an den entsprechenden Geschäftsprozess senden. Wir zeichnen die Bestellung Listing 6 from("jms:organization.processes.order.create") im CRM-System auf. Doch machen wir dies asynchron, da wir den Kunden nicht länger warten lassen wollen. Das ist der Grund, warum diese Aktion mit dem Wire- Tap Pattern ausgeführt wird. Fazit Systemintegrationen werden ständig wichtiger und häufiger. ServiceMix unterstützt viele Protokolle und Formate out of the box und ist zudem sehr robust und schlank. Damit ist diese Technologie ein geeigneter Kandidat, diesen Herausforderungen zu begegnen. ServiceMix steht zudem unter der Apache-Lizenz und ist somit geschäftsfreundlich. Bei Bedarf ist ein Enterprise- Support erhältlich. Eher schwach ist die verfügbare ServiceMix-Dokumentation. Es gibt zwar einige Tutorials, aber diese decken nur einen kleinen Teil des Möglichen ab. Die Community ist jedoch sehr aktiv und Anfragen an das Forum werden zügig beantwortet. Die anderen Apache- Technologien sind besser dokumentiert. Wir durften ServiceMix bereits in verschiedenen Projekten einsetzen. Oft kommt die Lösung im Kontext eines bestimmten Systems zum Einsatz, zumeist CMS oder PIM, um die konkreten Integrationsanforderungen dieses Systems zu lösen. In einigen Fällen erfüllt Ser vice- Mix als einzige Integrationsschicht im Unternehmen seine Pflicht. In beiden Fällen aber zuverlässig und mit geringem Ressourcenbedarf. Daniel Takai ist Technologiemanager bei der Unic AG in Bern. Er ist dort für die Entwicklungsprozesse, Technologieentwicklung und verteilte Softwarearchitekturen verantwortlich..split(xpath("/order/item")).parallelprocessing() // (1).aggregationStrategy(new MergeItemAvailabilitiesStrategy()).to("xslt:order-create-item-check-availability.xsl").to("jms:organization.processes.stock.availability").end().choice() // (2).when(xpath("/order/item[@available = 0]")) Raúl Kripalani arbeitet als Integrationsarchitekt für die Unic AG in Bern. Er ist spezialisiert auf Open-Source-Integration und Messaging, SOA, Large-scale Java Enterprise Systems und Big Data. Er hat über fünfzig Kunden und Projekte weltweit beraten und ist PMC- Mitglied sowie Committer bei Apache Camel und anderen Open- Source-Communitys. Matthias Rothe arbeitet bei der Unic GmbH in München als Senior Application Engineer und Technical Project Lead auf umfangreichen Integrationsprojekten für einen namhaften deutschen Fahr zeug hersteller. Daneben schreibt und veröffentlicht er Open- Source-Software, schreibt Artikel und hält Vorträge zu Technik- und Projektmanagementthemen..throwException(new OutOfStockException()) // (3).otherwise().to("direct:payment.process") // (4).to("jms:organization.processes.shipping.start") // (5).wireTap("jms:organization.processes.crm.recordOrder") // (6).end(); Links & Literatur [1] [2] [3] [4] [5] [6] 96 javamagazin

8 JAVA 3 Jetzt abonnieren! Jetzt 3 Top-Vorteile sichern! 1 Alle Printausgaben frei Haus erhalten Intellibook-ID kostenlos anfordern ( 2 Abo-Nr. (aus Rechnung oder Auftragsbestätigung) eingeben 3 Zugriff auf das komplette PDF-Archiv mit der Intellibook-ID