Enterprise Service Bus - Arne Degenring Software Engineering
Werbung
Titelthema Alle Wege führen nach Rom Enterprise Service Bus Arne Degenring Integration der IT-Systeme wird für viele Unternehmen immer wichtiger. Die historisch gewachsenen Strukturen und Schnittstellen zwischen den Systemen sind schwer zu warten. Ein „Enterprise Service Bus“ ist eine Middleware, die besonders für den Aufbau Service-orientierter Architekturen geeignet ist, und außerdem Ideen aus der klassischen „Enterprise Application Integration“ (EAI) übernimmt. Die teilweise über Jahrzehnte gewachsenen Punkt-zu- Punkt-Schnittstellen zwischen den Unternehmens-Applikationen sind oft unübersichtlich und nur schwer zu beherrschen bzw. zu erweitern. Ein Ansatz zur Erhöhung der Transparenz ist die klassische Enterprise Application Integration (EAI), bei der ein so genannter Integrations-Broker die Applikationen verbindet. Charakteristisch ist hierbei eine Sterntopologie, das so genannte „hub-and-spoke“-Modell. Vorteile sind ein zentrales Routing der Informationen zwischen den Anwendungen und die Möglichkeit, den Code zur Integration mit anderen Umgebungen von dem eigentlichen Business-Code zu trennen. Die EAI-Produkte haben aber den Nachteil, tendenziell proprietär und monolithisch aufgebaut zu sein. Ein zentraler Integrations-Broker ist außerdem nicht sehr gut geeignet, über Abteilungs- oder Unternehmensgrenzen hinweg Applikationen zu verbinden. Wegen der Sterntopologie droht der Broker zum Flaschenhals zu werden. Ein anderes wichtiges Stichwort sind die in letzter Zeit viel zitierten Service-orientierten Architekturen (SOA): Sie sollen die Unternehmens-IT flexibler machen. Ein Service im Sinne einer SOA kapselt eine abgegrenzte Funktionalität und bietet klare, implementierungsunabhängige Schnittstellen. Services werden lose gekoppelt und kommunizieren über interoperable Protokolle. Die Granularität sollte nicht zu fein und nicht an der Technik orientiert sein, stattdessen sollte ein Service ganze Business-Funktionen bzw. -Prozesse abbilden. Als Kommunikationsprotokolle für Service-orientierte Architekturen werden oft die Web-Services-Standards, insbesondere SOAP und WSDL, vorgeschlagen. Das ist aber kein Muss. Die Service-Orientierung hat vor allem den Vorteil, dass hier die Business-Funktionalitäten im Vordergrund stehen. Die Services können als Bausteine wiederverwendet werden, um neue Geschäftsprozesse abzubilden, und erleichtern die unternehmensübergreifende Integration von IT-Systemen. Nach wie vor stellt sich aber das Problem der direkten Punkt-zu-PunktSchnittstellen zwischen den Services, die im Laufe der Zeit immer unübersichtlicher werden können. Enterprise Service Bus Das Konzept des Enterprise Service Bus (ESB) versucht, diese Herausforderungen zu lösen. Der Begriff wurde schon Ende 2002 erstmals genannt. Ein ESB soll gewissermaßen das Rückgrat für die Unternehmens-IT bilden, indem er eine Infrastruktur zur Verbindung von Applikationen bzw. Services bereitstellt. Eine abstrakte Sicht auf eine beispielhafte ESB-Struktur zeigt Abb. 1. Eine wichtige Eigenschaft für einen ESB ist die Unterstützung eines dokumenten-orientierten Verarbeitungsmodells – etwas was auch für SOA charakteristisch ist (vgl. Kasten „Dokumenten16 Abb. 1: Beispielhafter Enterprise Service Bus Dokumenten-orientiert vs. RPC-orientiert SOAP – das Kommunikationsprotokoll für Web-Services – wurde ursprünglich hauptsächlich als Plattform-unabhängiger Standard für den entfernten Methodenaufruf, den „Remote Procedure Call“ (RPC), verwendet. In Service-orientierten Architekturen – und im Enterprise Service Bus – liegt der Fokus aber auf dem dokumenten-orientierten Verarbeitungsmodell. Dieses wird von SOAP ebenso wie RPC unterstützt. Es werden nicht einzelne Methoden nacheinander aufgerufen, sondern ein ganzes Dokument übertragen, das den Geschäftsvorfall repräsentiert. Das führt zu einer viel loseren Kopplung zwischen den Anwendungen. Den Unterschied kann man sich gut mit Hilfe einer Analogie deutlich machen. Ein Telefongespräch mit einer Bestellhotline ist RPC-orientiert: A: Hier spricht Muster, ich möchte eine Bestellung aufgeben. Die Kundennummer ist 1234. B: Das ist die Firma XY, richtig? Was möchten Sie bestellen? A: 100 Exemplare JavaSPEKTRUM, Ausgabe 04/2005. B: Wir haben leider nur noch 30 Stück am Lager. A: ... Dagegen ist eine schriftliche Bestellung dokumentenorientiert. Alle für den Geschäftsvorfall nötigen Informationen sind im Dokument enthalten. Das Bestellformular ist gewissermaßen ein Schema, gegen das die Bestellung validiert werden kann. Als Antwort sendet der Auftragnehmer eine Auftragsbestätigung, auf der z. B. auch ausverkaufte Artikel vermerkt sind. JavaSPEKTRUM 4/2005 Titelthema orientiert vs. RPC-orientiert“). Die Verarbeitung sollte möglichst ereignisorientiert sein, d. h. Geschäftsvorfälle werden sofort (online) verarbeitet und nicht erst in nächtlichen Batch-Läufen. Nicht überraschend ist deshalb, dass Message-Queues eine wichtige Komponente in einer ESB-Infrastruktur darstellen: Message-Oriented Middleware garantiert die einmalige Zustellung von Messages an den richtigen Empfänger, ermöglicht die Verarbeitung unter Transaktionskontrolle und unterstützt unterschiedliche Messaging-Modelle: Bei einer Punkt-zuPunkt-Kommunikation über Queues wird eine Message von einem Sender produziert und von höchstens einem Empfänger aus der Queue gelesen. Beim „Publish-and-Subscribe“-Modell wird eine Message von einem Sender produziert, aber ggf. mehreren Abnehmern eines sog. „Topic“ zugestellt. Abb. 2: Beispiel für einen ESB-Prozess Kommunikation über ESB-Prozesse Auf einem Enterprise Service Bus sollten die Softwareapplikationen nicht direkt miteinander kommunizieren. Stattdessen übergibt eine Applikation die zu sendenden Daten an einen Prozess, der sich um die Weiterverarbeitung kümmert. Im einfachsten Fall gibt der Prozess die Daten direkt an eine bestimmte Applikation weiter. Der Prozess kann sich aber auch um Aspekte wie zum Beispiel die folgenden kümmern (vgl. auch Abb. 2): Intelligentes Routing auf Basis der Message-Inhalte – ggf. sogar mit dynamischer Auswahl eines geeigneten Service (etwa über UDDI), Validierung der Message-Inhalte, Transformation in andere technische Formate bzw. Übersetzung der Inhalte in andere fachliche Darstellungen, Anreichern der Daten um zusätzliche Informationen, Archivierung der Eingangsdaten, Berechtigungsprüfungen, Logging, Durchsatzüberwachung, Aufrufen der Applikation – ggf. über proprietäre Schnittstellen. Auch die Antwortdaten können dann wieder auf diese Weise aufbereitet und an den Aufrufer zurückgegeben werden. Die Verwendung von Prozessen kann auch verschiedene Interaktionsstile zusammenbringen: Wenn beispielsweise eine Applikation ausschließlich einen synchronen Aufrufstil versteht und unterstützt, kann sie über einen entsprechenden Prozess in asynchrone Umgebungen eingebunden werden. Viele dieser Aspekte sind heutzutage in den Applikationen selbst enthalten. Die Idee des Enterprise Service Bus ist, dass sich die Applikationen auf den eigentlichen Fachcode konzentrieren sollen. Der Integrationscode ist Teil des Busses – und kann für andere Services wiederverwendet werden. Prozesse werden idealerweise deklarativ beschrieben und sind somit schnell änderbar – und zwar ohne dass unbedingt die Fachanwendungen geändert werden müssen. Ein Enterprise Service Bus ist ein verteiltes System. Die Prozesse und Services müssen also nicht auf einem zentralen EAI-Server laufen, sondern können über mehrere Rechner verteilt sein, mit Vorteilen hinsichtlich Skalierbarkeit und Ausfallsicherheit. XML-Standards als Basis für ESB Die ESB-Architektur ist unabhängig von den verwendeten Kommunikationsprotokollen und Datenformaten. Beson- XPath XML Path Language: Sprache zur Navigation in XML-Dokumenten (Organisation: W3C) SOAP Protokoll für Web-Services (Organisation: W3C) WSDL Web Service Definition Language: Beschreibungssprache für Web-Services (W3C) UDDI Universal Description, Discovery, and Integration: Verzeichnisdienst für Web-Services (OASIS) JMS Java Message Service: API für Messaging (Java Community Process) JSR-208/JBI Java Specification Request #208 (Java Business Integration): Standard für Integrationskomponenten und - Services (Java Community Process) WS-CDL Choreography Description Language: Beschreibungssprache für die Kollaboration von Web-Services (W3C) WS-BPEL Business Process Execution Language: Ausführbare Beschreibungssprache von Geschäftsprozessen (OASIS) WSS Web Services Security: Sicherheitsfunktionalitäten für Web-Services (OASIS) WS-Reliability Garantierte Message-Zustellung, auch wenn vom Transportprotokoll nicht garantiert (OASIS) WS-Policy Festlegung von Kommunikationsgrundlagen zwischen Web-Services, z. B. hinsichtlich Sicherheit (IBM, Microsoft u. a.) WS-Atomic Transaction Transaktionskontrolle für Web-Services (IBM, Microsoft u. a.) Tabelle 1: Einige relevante Spezifikationen http://www.javaspektrum.de 17 Titelthema ders gut zu der Architektur passt aber XML – gewissermaßen als das native Datenformat für den ESB. Denn es existieren ausgereifte, auf XML aufbauende Standards, um die ESB-Architektur umzusetzen. So können XML Schema zur Validierung und XSLT zur Transformation verwendet werden. XPath-Ausdrücke können verwendet werden, um ein inhaltsabhängiges Routing von Messages umzusetzen: Ein Ausdruck wie /bestellung/[summe>100000] kann benutzt werden, um Großbestellungen anders zu behandeln (z. B. manuelle Kontrolle oder besondere Protokollierung). Am Markt stehen ausgereifte Werkzeuge zur Verfügung, um mit XML & Co effizient umzugehen. Die auf XML aufbauenden Web-Services sind dementsprechend eine Art nativer Kommunikationsstandard des ESB. Bezüglich der Definition von Prozessen gibt es mit BPEL und WS-CDL ebenfalls Standardisierungsbemühungen. Einige wichtige Standards bzw. Spezifikationsvorschläge für den Enterprise Service Bus zeigt Tabelle 1. Neben den dort genannten gibt es noch eine ganze Menge mehr Spezifikationen, die sich aktuell in Arbeit befinden und jeweils einen bestimmten Teilaspekt abdecken. ESB und die Praxis Ein kritischer Punkt für Service-orientierte Architekturen allgemein und für den Enterprise Service Bus im Speziellen ist die Performance. Ist das Konzept auch tragfähig, wenn sehr hohe Durchsatzzahlen erreicht werden müssen? Damit dies überhaupt aussichtsreich erscheint, sollten Web-Services und XML mit Bedacht eingesetzt werden, und zwar dort, wo man echte Vorteile von ihnen hat: an den Schnittstellen. Innerhalb einer Anwendung kann die lose Kopplung zur Performance-Bremse werden: Es ist zum Beispiel nicht sinnvoll, die Daten aus der Datenbankschicht zur Business-Schicht als XML zu transportieren. Eine engere Kopplung ist hier gefragt. Das ist aber auch kein Problem, denn diese Schnittstellen sind rein applikationsintern. Wenn Web-Services eingesetzt werden, ist HTTP als Transportprotokoll für SOAP häufig nicht die beste Wahl. Besser ist es, die SOAP-Nachrichten über eine Message-Oriented Middleware zu übertragen. Wenn eine solche Middleware den Java Message Service (JMS) unterstützt, spricht man auch von SOAP über JMS. Aufgrund seiner verteilten Natur unterstützt der ESB gut seine schrittweise Einführung. Die Unternehmens-IT muss nicht auf einen Schlag auf eine neue Architektur umgestellt werden. Ein ESB kann zunächst als Infrastruktur für ein einzelnes Software-Projekt verwendet werden. Im Laufe der Zeit können weitere Applikationen in die Infrastruktur integriert werden. Produkte Der Enterprise Service Bus ist zunächst nur ein Architekturkonzept. Aber natürlich gibt es eine ganze Reihe von Anbietern, die entsprechende Produkte anbieten bzw. mehrere Produkte zu einer „ESB-Suite“ zusammenfassen, zum Beispiel Sonic Software, IBM, BEA und viele mehr. 18 Bestandteil solcher Produkte sind Service-Container, die Services aufnehmen und z. B. über die Java Management Extensions (JMX) die Administration und Überwachung des Service ermöglichen. Das Konzept der Service-Container ermöglicht eine von anderen Services unabhängige Skalierbarkeit und Lastverteilung. Viele Hersteller integrieren eine einheitliche ManagementOberfläche, mit der die verteilten Prozesse und Services konfiguriert und administriert werden können. Über JMX können auch andere Management-Oberflächen angebunden werden. Konfigurationsinformationen werden z. B. bei Sonic in einem verteilten Verzeichnisdienst abgelegt. Damit steht einerseits ein zentraler Punkt zur Verfügung, an dem die Änderungen durchgeführt werden, andererseits handelt es sich aber um eine verteilte Infrastruktur, mit entsprechenden Vorteilen hinsichtlich Ausfallsicherheit. Fazit und weitere Informationen Der Enterprise Service Bus ist ein interessantes Konzept zum Aufbau Service-orientierter Architekturen und zur Integration der Unternehmens-IT. Es handelt sich um kein Produkt, sondern ein Architekturkonzept, das auf Standards aufbaut – selbst aber kein Standard ist. Eine Architektur aus lose-gekoppelten Services, die Geschäftsprozesse kapseln, kann die Flexibilität der Unternehmens-IT erhöhen. Ein Enterprise Service Bus stellt die hierfür notwendige Infrastruktur dar. Dieser Artikel konnte nur einen Vorgeschmack auf einige wichtige Aspekte des Enterprise Service Bus bieten. Weitere Informationen finden sich in Büchern wie [ChappelESB] und [IBMRedbook]. Auf der Homepage des Autors sind einige Links zum Thema genannt. Ein Interview mit Dave Chappell von Sonic Software zum Enterprise Service Bus ist im vorigen JavaSPEKTRUM [ChaInt] zu finden. Literatur [ChappellESB] D. A. Chappell, Enterprise Service Bus, O’Reilly, 2004 [ChaInt] Interview mit Dave Chappell, in: JavaSPEKTRUM, 3/2005, http://www.sigs-datacom.de/sd/publications/pub_article_show.htm?&AID=1591 [IBMRedbook] M. Keen u. a., Patterns: Implementing an SOA Using an Enterprise Service Bus, IBM Redbook, 2004, online verfügbar unter: www.redbooks.ibm.com/abstracts/sg246346.html Dipl.-Inform. Arne Degenring beschäftigt sich seit 1995 professionell mit Softwareentwicklung. Er ist als freiberuflicher IT-Consultant im Bereich Softwareentwicklung tätig, zurzeit in einem Banken-Projekt in Frankfurt am Main. E-Mail: [email protected]. Weitere Informationsquellen http://www.degenring.de/esb/ JavaSPEKTRUM 4/2005
