ESB Produkte in.net. MSE Vertiefungsmodul II. Marko Marković. Student. Jörg Hofstetter. Advisor. André Rogger (HSLU, Wirtschaft) Experte

Größe: px
Ab Seite anzeigen:

Download "ESB Produkte in.net. MSE Vertiefungsmodul II. Marko Marković. Student. Jörg Hofstetter. Advisor. André Rogger (HSLU, Wirtschaft) Experte"

Transkript

1 ESB Produkte in.net Student Advisor Experte Marko Marković Jörg Hofstetter André Rogger (HSLU, Wirtschaft) Kompetenzzentrum Distributed Secure Software Systems (D3S)

2 Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig angefertigt und keine anderen als die angegebenen Hilfsmittel verwendet habe. Sämtliche verwendeten Textausschnitte, Zitate oder Inhalte anderer Verfasser wurden ausdrücklich als solche gekennzeichnet. Horw, Marko Marković Student: Marko Marković Seite 2 von 95

3 Management Summary Serviceorientierte Architektur (SOA) hat zum Ziel, die unterschiedlichsten Dienste so zusammen zu bringen, dass sie eine gemeinsame Aufgabe erfüllen können. Eine der Herausforderungen in diesem Zusammenhang besteht darin, diese Services möglichst einheitlich und einfach anzusprechen. Services können auf die unterschiedlichste Art und Weise realisiert werden. Moderne Dienste lassen sich in der Regel einfacher in eine neue Anwendung einbinden als alte. Heutzutage sind viele Softwarehersteller bestrebt, Systeme zu entwickeln, welche lose gekoppelte Services für die Erfüllung neuer Aufgaben möglichst einfach in einem geregelten Ablauf integrieren. In diesem Zusammenhang hat sich das Konzept des Enterprise Service Bus (ESB) durchgesetzt. Ein ESB soll genau diese Eingliederungsaufgabe der vorhandenen Unternehmensfunktionalitäten in einem einheitlichen Umfeld übernehmen. Neben der Integration der Dienste übernimmt ein ESB unter anderem auch deren Verwaltung. Weiter ermöglicht ein ESB einem Systemadministrator die eingebundenen Services zu überwachen und zu konfigurieren. Ein ESB gliedert die Services nicht nur ein, sondern sorgt auch dafür, dass die Kommunikation sicher und möglichst fehlerfrei durchgeführt werden kann. Bei einem ESB handelt es sich somit um eine komplexe Softwarekonstruktion. Um ein besseres Verständnis für dieses Softwarekonstrukt zu entwickeln, wurden die Einzelteile eines ESB genauer untersucht und zu Beginn dieser Arbeit aufgeführt. Weiter werden in dieser Arbeit verschiedene ESB Produkte im.net Umfeld untersucht. Der Fokus wird vorwiegend auf reine Open Source Projekte gelegt. Da es zum Zeitpunkt der Arbeit jedoch noch keine namhaften Open Source Projekte in der.net Welt gab, welche einen vollständigen ESB Implementation anbieten, wurden vielversprechende, kommerzielle Produkte ebenfalls mit einbezogen. So war es möglich einen Vergleich zwischen leichtgewichtigen Open Source Lösungen und kommerziellen Produkte durchzuführen. In diesem konkreten Fall wurden die beiden Produkte NServiceBus und Neuron ESB untersucht. Es wurde analysiert, wie die beiden Produkte zur Eingliederung von Services eingesetzt werden können und was für Funktionen sie dabei anbieten. Zur Analyse der Produktfunktionalität der beiden Lösungen wurden verschiedene Szenarien zusammengestellt. Diese enthaltenen Aufgaben, welche sich an alltägliche Probleme bzw. Herausforderungen im anlehnen. Die Produkte werden daran bewertet, inwieweit sie die Erfüllung der Aufgaben unterstützten. Je schneller und einfacher eine Aufgabe Dank dem Einsatz eines ESB Produktes umgesetzt werden kann, umso mehr spricht das auch für die Einführung eines solchen Integrationssystems. Zum Schluss werden die Vor- und Nachteile der jeweiligen Produkte zusammengefasst und ein Gesamtfazit gezogen. Es werden Aussagen darüber gemacht, ab wann sich der Einsatz eines Open Source Produktes lohnt, und ab wann eine kommerzielle Lösung eher zu bevorzugen ist. Student: Marko Marković Seite 3 von 95

4 Inhaltsverzeichnis 1 Ausgangslage Begriffe Das Enterprise Service Bus SOA Pattern Asynchronous Queuing Service Broker Data Model Transformation Data Format Transformation Protocol Briding Intermediate Routing Reliable Messaging Policy Centralization Rules Centralization Event-Driven Messaging ESB Produkte im.net Umfeld Überblick ESB.NET NServiceBus Simple Service Bus Neuron ESB NServiceBus vs. Neuron ESB Szenario 1: Mehrere Subscriber mit unterschiedlichen Parameter Realisierung mittels NServiceBus Realisierung mittels Neuron ESB Szenario 2: Hinzufügen weiterer Subscriber Realisierung mittels NServiceBus Realisierung mittels Neuron ESB Szenario 3: Änderung von Parametern Realisierung mittels NServiceBus Realisierung mittels Neuron ESB Szenario 4: Adressänderung Subscriber Student: Marko Marković Seite 4 von 95

5 5.4.1 Anpassung in NServiceBus Anpassung in Neuron ESB Szenario 5: Adressänderung Publisher Anpassung in NServiceBus Anpassung in Neuron ESB Szenario 6: Adressänderung ESB Anpassung in NServiceBus Anpassung in Neuron ESB Szenario 7: Einbindung einer Java Anwendung Realisierung mittels NServiceBus Realisierung mittels Neuron ESB Szenario 8: Load Balancing Realisierung mittels NServiceBus Realisierung mittels Neuron ESB Fazit Verzeichnis Abbildungsverzeichnis Tabellenverzeichnis Quellen Anhang I Einfache Nachrichtenübermittlung in NServiceBus Projekteinrichtung im Visual Studio Package: InfoMessages Package: Server Package: Client Testdurchführung Einfache Nachrichtenübermittlung in Neuron ESB Projekteinrichtung im Visual Studio Package: AnfrageSender Package: AnfrageEmpfänger Einstellungen im Neuron ESB Explorer Testdurchführung Student: Marko Marković Seite 5 von 95

6 9 Anhang II Risikomanagement Projektplan Sitzungsnotizen Sitzung Nr Sitzung Nr Sitzung Nr Sitzung Nr Sitzung Nr Sitzung Nr Student: Marko Marković Seite 6 von 95

7 1 Ausgangslage Im vorhergegangenen Vertiefungsmodul [1] wurden die Kernfunktionen eines ESBs wie folgt vorgestellt: Dienstlokalisierung Nachrichtentransformation Inhaltsabhängige Nachrichtenweiterleitung (Routing) Schutz des Datenverkehrs und der Dienstschnittstellen (Security) Überwachung und Management (Monitoring) Ein ESB besteht somit aus verschiedenen Einzelteilen. Diese Einzelteile sollen in dieser Arbeit genauer unter die Lupe genommen und das dahinterstehende Entwurfsprinzip vorgestellt werden. Da es unterschiedliche Definitionen zu einem ESB gibt, soll anhand der einzelnen Bausteine ein Grundverständnis über den Sinn und Zweck eines ESB entwickelt werden. Die dabei untersuchten Kernfunktionen sollen als Basis für die Bewertung der in dieser Arbeit vorgestellten ESB Produkte Verwendung finden. Kommerzielle Gesamtlösungen im ESB Bereich bieten sehr viele Funktionen, welche es grossen Unternehmungen erlauben, auf einfache Art und Weise ihre Dienste in einem System zu Integrieren und wiederzuverwenden. Es soll nun untersucht werden, ob solche All-in-one Lösungen auch für kleine Unternehmungen geeignet sind, bzw. ob Klein- und Mittelunternehmen ebenfalls eine solche Komplettlösung für ein erfolgreiches SOA System benötigen, oder ob auch leichtgewichtigere Varianten für die Dienstintegration ausreichen würden. In diesem Zusammenhang werden einige Open Source Projekte von ESB Implementationen im.net Umfeld untersucht. Eines dieser Projekte soll für einen genaueren Vergleich zwischen einer kommerziellen Lösung herangezogen werden. Dieser Vergleich soll einerseits als Grundlage für die Ermittlung der Vor- und Nachteile von leichtgewichtigen Open Source Lösungen gegenüber kommerziellen Produkten dienen, und andererseits soll eine Aussage darüber gemacht werden können, ob und unter welchen Umständen leichtgewichtige Varianten für die Serviceeinbindung ausreichen. Student: Marko Marković Seite 7 von 95

8 2 Begriffe Manche der verwendeten Begriffe werden von einigen IT Firmen oder Buchautoren unterschiedlich aufgefasst und interpretiert. In Zusammenhang mit dieser Arbeit sollen aber diejenigen in der Tabelle 1 aufgeführten Begrifflichkeiten gelten. Abkürzung BPEL BPM BPMN CRM ESB JMS MSMQ Bedeutung Business Process Execution Language Der Vollständigkeit halber wird in Zusammenhang mit BPEL die Abkürzung WS- BPEL für Web Service Business Process Execution Language verwendet. Bei WS-BPEL handelt es sich um eine auf XML basierende Modellierungssprache. Im Unterschied zu jpdl werden jedoch alle Aktivitäten bzw. Funktionen bei WS-BPEL durch Web Services ausgeführt. Business Process Management BPM ist ein zentraler Begriff und bezeichnet die Organisation und stetige Optimierung von Geschäftsprozessen innerhalb einer Unternehmung. Geschäftsprozesse werden benötigt, um die nötigen Arbeitsschritte, welche zur Erfüllung einer bestimmten Aufgabe (wie z.b. Herstellung eines Produktteiles, Abarbeitung einer Bestellung, Kreditantragbearbeitung usw.) festzuhalten. Business Process Modeling Notation BPMN ist eine Modellierungssprache ähnlich wie UML, jedoch speziell auf die Modellierung von Geschäftsprozessen ausgerichtet. Es gibt genau wie bei UML verschiedene Spezifikationen. jpdl und BPEL orientieren sich weitgehend an den von BPMN spezifizierten Standard, jedoch mit unterschiedlichem Erfolg. Customer-Relationship-Management Eine durch IT unterstütze Verbindung aller Unternehmensbereiche zu einer gesamtheitlichen Unternehmensstrategie, die auf Basis eines komplexen Prozess- und Informationsmanagements sicherstellt, dass jeder einzelne Kunde schnell, kompetent und individuell bedient wird. Enterprise Service Bus Es gibt viele unterschiedliche Definitionen was unter einem ESB zu verstehen ist. In Zusammenhang mit dieser Arbeit wird als ESB ein Kommunikationsmechanismus für IT Verarbeitungssystemen bezeichnet, der auf die Koppelung von IT Systemen für die Verarbeitung von firmenspezifischen Prozessen ausgerichtet ist und durch vielseitig nutzbare Schnittstelle diese Funktionalität zur Verfügung stellt. Java Message Service Bei JMS handelt es sich um eine Java API, welche den Austausch von asynchronen Nachrichten zwischen lose gekoppelte Systeme ermöglicht. JMS unterstützt zwei Kommunikationsmodelle: Point-to-Point (PTP) sowie Publisher- Subscriber. JMS wurde als integraler Bestandteil der Java Enterprise Edition (J2EE) eingeführt und dient seitdem für viele anderen Frameworks als Kommunikationsschnittstelle, u.a. auch für JBossESB. Microsoft Message Queuing MSMQ ist ein Windowsservice, welcher auch als Programmbibliothek zur Verfügung steht und es ermöglicht, Daten über eine Netzwerkverbindung und das Internet an einen Empfänger zu schicken, ohne dass dieser zu diesem Zeitpunkt erreichbar sein muss. Die Nachrichten werden in erster Linie in eine Queue nach dem FIFO Prinzip (first in first out) beim Empfänger abgelegt, bevor dieser die Nachricht lesen kann. Der Sender seinerseits hat ebenfalls eine Queue für allfällige Antworten des Empfängers. Student: Marko Marković Seite 8 von 95

9 REST SOA WCF WF WMQ Workflow XSLT WSDL Tabelle 1: Stichwortverzeichnis Representational State Transfer Der Begriff REST wurde von Dr. Thomas Roy Fielding im Jahr 2000 in seiner Dissertation geprägt. Er bezeichnet einen simplen Architekturstil für verteilte Anwendungen. REST verwendet dieselben Operatoren, welche bereits im HTTP definiert sind, wie zum Beispiel: GET, POST, PUT, DELETE. Service Oriented Architecture Durch SOA sollen dienstorientierte IT Landschaft erschaffen werden. Anwendungsschnittstellen sollen lose gekoppelt für die Erstellung von geschäftsspezifischen Prozessen zusammengesetzt und wiederverwendet werden. SOA ist technologieunabhängig und stellt lediglich das wesentliche Architekturkonzept dar. Windows Communication Foundation WCF ist eine Klassenbibliothek zur Entwicklung von servicebasierten, verteilten Systemen in.net. Es erlaubt die Erstellung von Kommunikationsanwendungen zum Fernaufruf von Code und zur Anwendungskopplung. WCF ist Teil des.net Framework 3.0 und wurde in.net 3.5 aktualisiert. Windows Workflow Foundation WF ist ein Framework, das Benutzern das Erstellen von system- oder benutzerbezogenen Workflows in ihren Anwendungen für die grafische Darstellung der betrieblichen Prozesse ermöglicht. Es kann sowohl in einfachen Szenarios, wie z.b. zum Anzeigen bestimmter Benutzeroberflächensteuerelemente in Abhängigkeit von Benutzereingaben, als auch in komplexen Geschäftsabläufen, z.b. Darstellung einer Bestellabwicklung eines Online Web-Shops, eingesetzt werden. WebSphere Message Queue Bei WMQ handelt es sich um eine Nachrichtenorientierte Middleware. WMQ wird dazu eingesetzt um asynchron über Systemgrenzen hinweg zu kommunizieren. Es dient dabei zur Lastverteilung und erlaubt es, Systeme anzusprechen, die nicht direkt per RPC/SOAP usw. aufgerufen werden können. Dabei bietet WMQ die Möglichkeit, transaktionsgesteuert nach dem push and forget Prinzip zu kommunizieren. Der WMQ-Client ist für fast alle Betriebssysteme verfügbar: Windows, Linus, Solaris, Unix usw. Human-Workflow Unter einem (Human-)Workflow wird eine Abfolge von Prozessschritten verstanden, welche menschliche Interaktionen, wie z.b. das Bestätigen eines Verarbeitungsschrittes, miteinschliessen. XSL Transformation XSLT beschreibt die Umwandlung einer XML-Nachricht in Form eines XML- Dokuments, in einer anderen Informationsanordnung oder in ein anderes Nachrichtenformat. Die resultierende Nachricht entspricht meist der XML- Syntax. Es können jedoch auch andere Zielformate wie z.b. HTML, Textdateien, CSV-Dateien oder Binärdaten angewendet werden. Web Service Definition Language Mittels WSDL werden die bereitgestellten Methoden, verwendete Protokolle und Datenstrukturen eines Web Services beschrieben. Die Beschreibung erfolgt in XML Notation und ist Plattformunabhängig. Neben den für die Nutzung des Web Services benötigten Schnittstellenangaben, können weitere Informationen wie z.b. Zugriffsrestriktionen oder Details zum Deployment spezifiziert werden. Student: Marko Marković Seite 9 von 95

10 3 Das Enterprise Service Bus SOA Pattern Das Enterprise Service Bus SOA Pattern [2] ist auf die Einrichtung einer einheitlichen Kommunikationsplattform für verschiedene Systemdienste ausgerichtet. Es unterstütz wichtige Funktionen wie Skalierung, zuverlässige Verbindungen und verschlüsselte Datenübertragung. Das Pattern setzt sich fundamental aus mehreren anderen wichtigen SOA Patterns zusammen. Dazu gehören Asynchronous Queuing, Intermediate Routing sowie das Service Broker Pattern. Weiter kann das ESB Pattern um die Entwurfsmuster Reliable Messaging, Policy Centralization, Rules Centralization sowie Even Driven Messaging erweitert werden. Eine Übersicht über alle Komponenten ist in der Abbildung 1 dargestellt. Enterprise Service Bus Asynchronous Queuing Intermediate Routing Policy Centralization Event Driven Messaging Service Broker Reliable Messaging Rules Centralization Data Model Transformation Data Format Transformation Protocol Briding Abbildung 1: Komponenten des Enterprise Service Bus SOA Patterns Die einzelnen Komponenten des ESB werden in den nachfolgenden Abschnitten kurz vorgestellt. Dadurch soll ein besserer Einblick in die theoretischen Möglichkeiten eines ESB verdeutlicht werden. 3.1 Asynchronous Queuing Beim Asynchronous Queuing Entwurfsmuster stellt sich die Frage, wie ein Dienst und seine Nutzer möglichst lose gekoppelt voneinander zusammenarbeiten können. Wenn die Nutzung eines Dienstes es erfordert, dass alle seine Anwender synchron mit diesem interagieren, entsteht automatisch eine starke Abhängigkeit. Ein Prozessverarbeitungsschritt wird bei einer synchronen Kommunikation erst dann weitergeführt, wenn eine Antwort auf eine Anfrage eintrifft. Bis dahin bleibt der Status des Dienstes blockiert und die Leistung wird dadurch automatisch gehemmt. Um diesem Problem entgegenzuwirken wird ein Buffer in Form einer Message Queue zwischen dem Dienstanbieter und den Dienstnutzer zwischengeschaltet (vgl. Abbildung 2). Dieser ermöglicht eine unabhängigere, asynchrone Kommunikation. Die Message Queue bringt weitere positive Nebeneffekte mit sich. Beispielsweise ist der Dienstnutzer so in der Lage Anfragen an mehrere Dienste parallel zu versenden und die eintreffenden Antworten nacheinander zu verarbeiten. Die Verarbeitungsgeschwindigkeit der einzelnen Parteien wird entkoppelt. Ein schneller Dienstnutzer kann während er auf die Antwort eines langsamen Dienstanbieters wartet in der Zwischenzeit anderen Tätigkeiten nachgehen. Student: Marko Marković Seite 10 von 95

11 Abbildung 2: Einsatz einer Message Queue Auch wenn eine Queue verwendet wird, bedeutet das nicht, dass schlecht programmierte, synchrone Dienste nun ebenfalls ohne weiteres asynchron laufen können. Durch die Einbindung der Message Queue erhöht sich sogar der Entwicklungsaufwand für Services, damit diese asynchron betrieben werden können. Doch diese Investition zahlt sich für den gewonnen Nutzen durchaus aus. 3.2 Service Broker Die Brokerarchitektur hat sich als ein bewehrtes Konzept der Middleware Plattformen für die Integration von entfernten Systemen etabliert. Mitunter ist dies auch der Grund, weshalb der Service Broker eines der Kernstücke eines ESB bildet. Das Service Broker Entwurfsmuster setzt sich essentiell aus den Mustern Data Model Transformation, Data Format Transformation und Protocol Briding zusammen (vgl. Abbildung 3). Service Broker Data Model Transformation Data Format Transformation Protocol Briding Abbildung 3: Service Broker Die eingebundenen Muster sind in den nachfolgenden Unterabschnitten genauer beschrieben Data Model Transformation Wie sollen Dienste miteinander kommunizieren, wenn diese für dieselben Daten unterschiedliche Datenformate verwenden? Diese Frage soll mit dem Data Model Transformation Pattern beantwortet werden. Jeder Dienst verwendet ein vordefiniertes Format für seine Datenparameter. In der SOA Welt sind diese meist im XML Format und besitzen auch eine XSD Datei, welche die Formatierung festlegt. Idealerweise orientieren sich diese an vordefinierten Normen. Doch in der Praxis sind die Eingangsparameter für einen Dienst meist ohne grosse Rücksicht auf mögliche Änderungen oder Erweiterungen festgelegt worden. Über das Data Model Transformation Pattern wird beim Datenaustausch zwischen zwei Diensten ein Zwischenschritt durchgeführt, welcher die Datentransformation an das jeweilige Datenmodell übernimmt. Dieser Zwischenschicht verhindert, dass Änderungen an den bestehenden Dienstschnittstellenmodellformaten vorgenommen werden müssen. Ein Beispiel einer solchen Datenmodelltransformation ist in Abbildung 4 dargestellt. Dabei wird das Format einer Allgemeinen Anfragen in das Format einer expliziten Versicherungsanfrage konvertiert. Student: Marko Marković Seite 11 von 95

12 Abbildung 4: Data Model Transformation Data Format Transformation Je nach Anwendungsfall ist es sehr wahrscheinlich, dass nicht nur das Datenmodell, sondern auch das gesamte Datenformat zwischen zwei Diensten unterschiedlich ist. Während der eine Dienst über XML Nachrichten kommuniziert, ist der andere auf die Entgegennahme von CSV Dateien eingerichtet. In einem solchen Fall kann das Data Format Transformation Pattern angewendet werden, das die Einschaltung eines Adapters vorsieht. Dieser Adapter übernimmt die Konvertierung der Nachrichten für einen reibungslosen Kommunikationsübergang. Dadurch müssen vorhandenen Dienstschnittstellen nicht mehr neu angepasst werden. Ein möglicher Anwendungsfall ist in Abbildung 5 beispielhaft verdeutlicht. Hier werden XML Nachrichten über einen Konvertierungsdienst in CSV Dateien transformiert und einer Legacy System API für die weitere Prozessverarbeitung übergeben. Abbildung 5: Data Format Transformation Der wesentliche Nachteil dieses Vorgehens besteht darin, dass für jede Konvertierung ein entsprechender Adapter entwickelt werden muss. Dies kann unter Umständen sehr schnell zu einer komplexen Systemarchitektur führen. Zudem führt die Zwischenschaltung weiterer Programmlogik automatisch zu einer Performancedämpfung. Je grösser die zu konvertierende Nachrichten, umso länger braucht die Transformation. Student: Marko Marković Seite 12 von 95

13 3.2.3 Protocol Briding Neben der Modell und Format Transformation spielt das Protocol Briding ebenfalls eine wichtige Rolle für die Realisierung einer flexiblen Systemkommunikation. Dienste müssen ebenfalls in der Lage sein unterschiedliche Portadressen ansprechen zu können. Dies ist vor allem dann der Fall, wenn ein Dienst von einem unverschlüsselten Port (z.b. 8080) auf einen verschlüsselten wechseln möchte (z.b. 443 für SSL). Weiter kann es vorkommen, dass vom selben Netzwerkprotokoll mehrere Versionen vorhanden sind und der Dienstnutzer eine andere Version verwendet als der Dienstanbieter (vgl. Abbildung 6). Abbildung 6: Protocol Briding Auch hier kann es je nach Nachrichtengrösse zu merkbaren Performanceeinbussen kommen. Ebenfalls gilt es zu berücksichtigen, dass je nach Hersteller nicht alle Protokollüberbrückungen unterstützt werden (Bsp. JMS kann i.d.r. nur von Java Applikationen empfangen werden). 3.3 Intermediate Routing Das Intermediate Routing deckt gleich mehrere, wichtige Funktionen für SOA Systemen ab: Regelbasiertes Routing Load Balancing 1 zu 1 Routing Bei der inhaltsabhängigen Nachrichtenweiterleitung steht vor allem das dynamische Routen von Nachrichten aufgrund ihres Inhaltes im Vordergrund. Je grösser und komplexer ein SOA System ist, umso schwieriger wird es, diese von Anfang an so zu konzipieren, dass alle möglichen Fälle abgedeckt werden. Die meisten Anforderungen werden erst dann präzisiert, wenn das System eine erste, stabile Struktur angenommen hat. Zudem kommen mit der Zeit immer neue Anforderungen hinzu, weshalb die Komplexität sowie der Umfang der SOA Systemen stetig steigen, da diese ständigen Veränderungen ausgesetzt sind. Damit die Handhabung von SOA Dienste trotzdem in einem vernünftigen Rahmen durchgeführt werden kann, können in bestimmten Fällen Sammelpunkte definiert werden, welche als eine Art Fassade für eintreffende Nachrichten fungieren. Diese Sammelpunkte untersuchen den Inhalt der Nachricht und leiten diese automatisch anhand ihres Inhaltes an den richtigen Zieldienst weiter (vgl. Abbildung Student: Marko Marković Seite 13 von 95

14 7). Abbildung 7: Regelbasiertes Routing Dadurch ist es auch möglich, bestehende Sammelpunkte zur Laufzeit um weitere Dienstanbieter zu ergänzen, ohne Anpassungen an den jeweiligen Dienstnutzer vornehmen zu müssen. Dies wird dank dem Einsatz einer Business Rules Engine möglich. Diese untersucht nicht nur den Inhalt einer eingehenden Nachricht, sondern kümmert sich neben der Nachrichtenverarbeitung ebenfalls um die Ausnahmebehandlung. Der genaue Verarbeitungsablauf wird in einem Business Rules Repository abgelegt, auf welches die Business Rules Engine Zugriff hat. Ein weiterer, sehr wichtiger Aspekt der Nachrichtenweiterleitung ist das Load Balancing. Um hochverfügbare Dienste überhaupt anbieten zu können, müssen diese redundant vorhanden sein. Das heisst, dass mehrere Serviceinstanzen vorhanden sind, die ein und denselben Dienst anbieten. Je nach Auslastung der bestehenden Dienstinstanzen muss eine Dienstanfrage der einen oder anderen Instanz weitergeleitet werden können. So können viele Anfragen parallel und somit auch schneller bearbeitet werden. Für diesen Zweck wird ein Load Balancing Router vor den jeweiligen Dienstinstanzen zwischengeschaltet. Dieser kann über einen Performance Monitor den Auslastungsgrad einer Dienstinstanz überprüfen und so eine eintreffende Anfrage an die passende Instanz weiterleiten. Falls eine der Dienstinstanzen ausfällt, wird die Anfragelast auf die übrigen verteilt. So bleibt der Dienst als solcher gesamthaft verfügbar, obwohl im Hintergrund vereinzelte Komponenten ausfallen können. Bleibt hingegen nur eine einzige aktive Dienstinstanz übrig, verkommt der Load Balancing Router unweigerlich zu einem Durchlauferhitzer, da dieser nun eintreffende Nachrichten immer nur an ein und dieselbe Schnittstelle weiterleitet. In diesem Fall spricht man auch von einem 1 zu 1 Routing, da der Router nun mehr als eine Art Wegweiser fungiert. Der Funktionsumfang, den das Intermediate Routing mit sich bringt, ist in der Abbildung 8 zusammengefasst. Student: Marko Marković Seite 14 von 95

15 Abbildung 8: Intermediate Routing 3.4 Reliable Messaging Durch das Reliable Messaging soll eine zuverlässige Kommunikation in einem unzuverlässigen Umfeld realisiert werden können. Da zur jeder Zeit ein Dienst ausfallen könnte oder sehr lange für die Beantwortung von Anfragen brauchen könnte, müssen die Nachrichten vor der eigentlichen Verarbeitung zwischengespeichert werden. Hierfür wird ein Message Repository verwendet, welches den Nachrichtenverkehr in einer Datenbank festhält. Damit der Dienstnutzer auch sicher sein kann, dass seine Nachricht den entsprechenden Dienstanbieter erreicht hat, wird zu jeder erfolgreich übermittelten Anfrage auch eine Bestätigungsmeldung (ACK für Acknowledge) zurückgegeben (vgl. Abbildung 9). Abbildung 9: Reliable Messaging Ein weiterer Vorteil der Message Repository besteht darin, dass nun der Kommunikationsverkehr nachvollziehbar zurückverfolgt werden kann. Alle übermittelten Nachrichten können nun von aussen Student: Marko Marković Seite 15 von 95

16 dank dem Message Repository einfach eingesehen und untersucht werden. Für allfällige Fehlerbehandlungen und Performanceanalysen ist diese Eigenschaft unersetzbar. Leider erweitert der Einsatz der Message Repository hingegen auch die Anforderungen an die zu verwendete Serverhardware der SOA Landschaft. Bei ungenügenden Systemressourcen könnte sich diese schnell als Flaschenhals entpuppen. Zudem muss die Message Repository zwecks Speichernutzung auch regelmässig gewartet werden. 3.5 Policy Centralization In einer SOA können alle möglichen Arten von Diensten angeboten werden. Für einige dieser Dienste möchte man Nutzungsrichtlinien festlegen. Bei Web Services wird dies mit einer sogenannten WS- Policy bewerkstelligt. Diese legt fest, unter welchen Bedingungen (wie z.b. Protokoll, Verschlüsselung usw.) ein Web Service aufgerufen werden darf. Die WS-Policy wird in der Regel innerhalb der WSDL des Web Services Verlink. Als anschauliches Beispiel soll ein Pizzabestelldienst dienen (vgl. Abbildung 10). Abbildung 10: Pizzabestellservice mit integrierter WS-Policy Die Bestellung einer Pizza über den Web Service soll nur mit einem verschlüsselten Aufruf gestattet werden. Es dürfen lediglich zwei Verschlüsselungsmethoden verwendet werden: Basic256 und 3DES. Hierfür wird eine entsprechende Policy Datei SichereBestellung.xml mit folgendem Inhalt vorbereitet: <wsp:policy xmlns:wsp="sicherebestellung"> <sp:transportbinding> <wsp:policy> <sp:algorithmsuite> <wsp:policy> <wsp:exactlyone> <!-- Nur diese Verschlüsselungsmethoden werden gestattet --> <sp:basic256rsa15 /> <sp:tripledesrsa15 /> </wsp:exactlyone> </wsp:policy> </sp:algorithmsuite> <sp:transporttoken> <wsp:policy> <!-- Web Service darf nur über HTTPS aufgerufen werden --> <sp:httpstoken> <wsp:policy/> </sp:httpstoken> </wsp:policy> </sp:transporttoken> Student: Marko Marković Seite 16 von 95

17 </wsp:policy> </sp:transportbinding> </wsp:policy> Auf die genaue Spezifikation von WS-Policy Dateien wird hier nicht weiter Bezug genommen. Die nun soeben erstellte Richtlinie soll nun in die WSDL Datei des Web Services Eingebunden werden. Dafür reicht bereits eine einfache Zeile: <definitions targetnamespace="http://www.hslu.ch/beispiel/pizzabestellung"...>... <!-- Einbindung der WS-Policy Datei --> <porttype name="ptpizzabestellen" ws:policyuris="pol:sicherebestellung.xml"> <operation name="pizzabestellen"> <input message="tns:msgpizzabestellenrequest"></input> <output message="tns:msgpizzabestellenresponse"></output> </operation> </porttype>... </definitions> Somit ist der Pizzabestelldienst soweit geschützt, dass er nur über verschlüsselte Verbindungen aufgerufen werden darf. Das entscheidende dabei ist, dass dieselbe WS-Policy Datei und die darin enthaltenen Richtlinien auch für andere Web Services wiederverwendet werden können. In einer Unternehmung gibt es Richtlinien, die für alle Dienste gelten. Andere wiederum gelten nur für einzelne Unternehmenssparten. Ein Dienst muss somit unter Umständen mehrere Richtlinien einhalten können. Mittels WS-Polcy Dateien spezifizierte Richtlinien können auch auf andere Richtliniendateien angewandt werden. Somit ist eine hierarchische Strukturierung der Unternehmensrichtlinien für Services möglich (vgl. Abbildung 11). Abbildung 11: Richtlinienhierarchie Dieser Umstand kann zu verschiedenen Problemen führen. Da alle Dienste die vorgeschriebenen Richtlinien einhalten müssen, kann es bei der Implementation zu Inkonsistenzen und Redundanzen kommen, da je nach Service Standort die Richtlinien kopiert werden müssen. Um die Übersicht über Student: Marko Marković Seite 17 von 95

18 die verschiedenen Richtlinien eines SOA Systems nicht zu verlieren, sollten diese global oder subsystemspezifisch an einem zentralen Ort definiert sein. Von diesem Ort aus sollen diese auf alle Services angewandt werden können. Die Rede ist von einer zentralen Richtlinenverwaltung. Um eine zentrale Richtlinienverwaltung einführen zu können, muss ein entsprechendes Framework bereitgestellt werden. Dieses soll bei der Entwicklung eines Dienstes genutzt werden um die Firmenrichtlinien einhalten zu können. Das Framework soll eine gewisse Flexibilität anbieten können, die es erlaubt, neue Richtlinienspezifikationen zur Laufzeit anfügen oder bestehende anpassen zu können. Sind die Unternehmensrichtlinien einmal festgelegt, können diese von Middle Tier Plattformen in Form von ESBs eingebunden werden (vgl. Abbildung 12). Abbildung 12: Durchsetzung der Unternehmensrichtlinien mit Hilfe von WS-Policies 3.6 Rules Centralization Neben den Geschäftsrichtlinien muss sich eine SOA Plattform auch an vordefinierte Geschäftsregeln halten können. Geschäftsregeln legen z.b. fest welche Mitarbeiter oder Dienste welche Aufgaben wahrnehmen dürfen. Man spricht in diesem Zusammenhang auch vom Rules Centralization Pattern. Das Rules Centralization Pattern hat vergleichbare Anforderungen wie die Policy Centralization. Wie bei der Policy Centralization muss die Rules Centralization ebenfalls zentral gehalten werden. Dies kann durch einen zentralen Dienst realisiert werden, der innerhalb der SOA Plattform angeboten wird und die entsprechenden Geschäftsregeln für die anderen Dienste verwaltet. Alle Dienste, welche regelspezifische Sicherheitsinformationen benötigen, beziehen diese von diesem zentralen Regeldienst (vgl. Abbildung 13). Abbildung 13: SOA Plattform Student: Marko Marković Seite 18 von 95

19 Dies bringt zwar die entscheidenden Vorteile, dass alle Regeln an einem Ort zur Laufzeit definiert und Redundanzen vermieden werden können, birgt aber auch viele Nachteile. Neben einer Reduktion der Performance entsteht zwangsläufig ebenfalls eine grosse Abhängigkeit vom Regeldienst. Diese Abhängigkeit stellt ein grosses Risiko dar, falls dieser ausfallen sollte. Eine Möglichkeit um das Risiko zu minimieren, wäre die Bildung von mehreren Regeldienstinstanzen. Dies ist dank dem bereits vorgestellten Intermediate Routing Pattern auch machbar. Unglücklicherweise vergrössert sich dadurch automatisch wiederum die Komplexität des SOA Systems, was sich negativ auf die Wartung auswirkt. 3.7 Event-Driven Messaging Für einige Anwendungsfälle ist es wichtig, dass ein oder mehrere Dienste über bestimmte Änderungen automatisch informiert werden. Dies kann zum Beispiel dann der Fall sein, wenn ein Firmenkunde seine Adresse ändert, ein Mitarbeiter nach vollzogener Heirat seinen Nachnamen ändert oder sich infolge geänderter Gesetzgebung der Mehrwertsteuersatz geändert hat. In allen beschriebenen Fällen sind Systeme betroffen, welche aus diversen Gründen aktuelle Daten für den Betrieb benötigen. Im Idealfall werden diese Daten, welche Änderungen unterzogen sind, an zentralen Orten aufbewahrt und administriert. Da sich im heutigen Zeitalter Unternehmungen in einem schnelllebigen Umfeld behaupten müssen, müssen auch ihre SOA Systeme flexibel auf Erweiterungen sowie Änderungen reagieren können. Neue Dienste müssen einfach der bestehenden SOA Plattform hinzugefügt werden können, ohne dass dafür grosser Aufwand betrieben werden muss. Diesen Herausforderungen stellt sich das Event-Driven Messaging Pattern. Um Polling zu vermeiden werden Änderungen über das Publish-Subscribe Prinzip propagiert. Ein Publisher Dienst ist mit einer Anwendung gekoppelt, welche die unternehmensweite Datenhaltung geschäftsbezogener Daten eines bestimmten Geschäftssegmentes abdeckt. Dies könnte z.b. ein ERP System oder ein Kundenverwaltungssystem sein. Der Publisher meldet diese Änderungen einem Event Manager Dienst. Der Event Manager führt eine interne Liste mit allen registrierten Subscriber Diensten. Sobald dieser eine Nachricht vom Publisher erhält, leitet er diese an die Subscriber weiter. Dieser Sachverhalt wurde in der nachfolgenden Abbildung 14 grafisch dargestellt. Service A (Subscriber) Event Manager Service X (Publisher) Applikation X DB Service B (Subscriber) Service C (Subscriber) Geändert Abbildung 14: Event-Driven Massaging Der Event Manager übernimmt in vielerlei Hinsicht eine massgebende Rolle. Bei Änderungen an den Subscriber muss nur die interne Liste des Event Manager angepasst werden. Auf den Publisher haben diese keinen Einfluss. Ändert sich beim Publisher die Adresse, muss auch diese Änderung lediglich nur im Event Manager nachgetragen werden. Die Subscriber bleiben unverändert. In SOA Systemen ist der Event Manager typischerweise eine Komponente des ESB. Student: Marko Marković Seite 19 von 95

20 Zur Realisation des Event Managers werden das Asynchronous Queuing sowie das Reliable Messaging Pattern implementiert. Mit deren Hilfe wird die zuverlässige Nachrichtenweiterleitung sichergestellt. Student: Marko Marković Seite 20 von 95

21 4 ESB Produkte im.net Umfeld Überblick Es gibt bereits einige kommerzielle sowie auch Open Source ESB Implementationen in der Java Welt, diese befinden sich jedoch zum grössten Teil noch in der Entwicklung. Noch weniger entwickelt und verbreitet sind diese Systeme in der.net Welt. Neben einigen kommerziellen Produkten gibt es nur wenige Open Source Projekte auf dem ESB Gebiet. In den folgenden Abschnitten sollen einige der bekannten in.net entwickelten Open Source Projekte vorgestellt werden. Der Fokus wird auf das vielversprechende Produkt NServiceBus gelegt. Bei Neuron ESB handelt es sich im Gegensatz zu den anderen Produkten um eine kommerzielle ESB Lösung. Zuerst folgt nun eine Beschreibung der Open Source Projekte ESB.NET Allgemein Bei ESB.NET handelt es sich um ein von der Firma Keystroke IT Australia lanciertes ESB Framework für alle.net Plattformen ab Version 2.0. Das Produkt befindet sich zurzeit noch in der Entwicklungsphase (Stand: Februar 2010). Eine Dokumentation über die einzelnen Funktionen ist nur Abbildung 15: ESB.NET Logo spärlich verfügbar. ESB.NET ist mehr auf die Bedürfnisse von Klein- und Mittelunternehmungen ausgerichtet und unterstützt daher von Haus aus nicht sehr viele Schnittstellenanbindungsmöglichkeiten. Obwohl es sich hierbei um ein Open Source Projekt handelt, stehen die Kernbibliotheken nicht öffentlich verfügbar. Interessenten können auf der Homepage der Entwicklungsfirma Gebote abgeben, welche Funktionen als nächstes entwickelt werden sollen (vgl. Abbildung 16). Höher gebotene Features werden mit einer höheren Priorität realisiert. Abbildung 16: Gebotsseite für die Entwicklung von neuen Funktionen für ESB.NET (Quelle: Student: Marko Marković Seite 21 von 95

22 Über einen Blog, welcher auch als RSS-Feed registriert werden kann, werden die neusten Entwicklungen des Projektes publiziert. Das Projekt kann frei von der CodePlex Open Source Community Plattform unter dem folgenden Link heruntergeladen werden: Diese Seite gibt zugleich einen Überblick über das Produkt selbst und den aktuellen Entwicklungsstand. Die CodePlex Open Source Community Plattform stellt standardmässig einen Diskussionsbereich für publizierte Projekte zur Verfügung. Dieses Forum ist sehr nützlich, da Lösungen zu allgemeinen Problemen dort beschrieben sind. Service Catalog Nach der Installation von ESB.NET können die enthaltenen Services über eine Web Management Console eingesehen werden (vgl. Abbildung 17). Über die Console lassen sich zwar neue Services erfassen, die Konfigurationsmöglichkeiten sind jedoch sehr beschränkt. Als Service können nur Dienste erfasst werden, welche über eine WSDL Beschreibung verfügen. Dies bedeutet, dass alle registrierten Dienste im Grunde genommen Web Services sind. Andere Anbindungsmöglichkeiten werden in der aktuellen Version (Stand: November 2009) nicht angeboten. Abbildung 17: Service Catalog in ESB.NET Was besonders augenfällig in der Web Management Console von ESB.NET ist, ist die unvollständig entwickelte Infrastruktur. In der Baumnavigation links in der ESB.NET Web Management Console, sind alle Funktionspunkte mit einem Symbol versehen: Funktionen oder Kategorien mit einem blauen Stern gelten als fertig implementiert (18 von 52) Funktionen mit einem E links vom blauen Stern gelten als sich noch in der Entwicklung befindend (9 von 52) Funktionskategorien mit einer Uhr gelten als noch nicht fertig gestellt (3 von 52) Student: Marko Marković Seite 22 von 95

23 Funktionen mit einem roten Strich wurden noch nicht begonnen (22 von 52) Doch diese vom Entwickler selbst festgelegte Markierung der Funktionen in ESB.NET ist nicht sehr zuverlässig. Klickt man durch die Funktionspunkte der ESB Menagement Console erscheint bei einigen eine Fehlermeldung wie sie auf der unten stehenden Abbildung 18 dargestellt ist. Abbildung 18: Eine der vielen Fehlermeldungen in ESB.NET Der Aufwand, bis man einen eigenen Dienst in den Service Catalog von ESB.NET aufnehmen kann, ist verhältnismässig hoch. Mangels Dokumentation und bedingt durch den unübersichtlichen Aufbau von ESB.NET ist ein Einstieg in dieses Produkt sehr zeitaufwändig. Fazit Bereits bei der Installation von ESB.NET stellt man sehr schnell fest, dass sich das Produkt noch in einer frühen Alpha Phase befindet. Es ist weder ein Setup noch eine vernünftige Installationsanleitung vorhanden. Bis das Produkt auf einem Rechner installiert ist, muss viel Aufwand betrieben werden. Die meisten Funktionen sind entweder fehlerhaft oder noch nicht gar implementiert. Die Entwicklung schreitet nur langsam voran und eine vollständige, stabile Version scheint noch in weiter Ferne zu liegen. Zumal nur ein einziger Entwickler sich um die Implementation kümmert. Für einen produktiven Einsatz ist deshalb von ESB.NET eindeutig abzuraten NServiceBus Allgemein Bei NServiceBus 1 handelt es sich nicht um einen ESB im eigentlichen Sinne, sondern viel eher um eine nach dem Publisher/Subscriber- Prinzip aufgebaute, asynchrone Kommunikationsplattform. Entwickelt wurde die Plattform von Udi Dahan, der auf seiner Homepage Abbildung 19: NServiceBus Logo 1 Bei der Schreibweise von NServiceBus sind sich die Autoren selber nicht ganz einig. Während Udi Dahan in älteren Versionen 1.x den Term nservicebus verwendet, wird ab Version 2.0 zunehmend die Schreibweise NServiceBus mit grossem Anfangsbuchstaben verwendet. Da die Beispiele in dieser Arbeit auf der Version 2.0 aufbauen, wird auch hier der Term NServiceBus verwendet. Student: Marko Marković Seite 23 von 95

24 in diverse Diskussionen die Vorteile vom eher leichtgewichtigen NServiceBus gegenüber schweren, kommerziellen Integrationslösungen hervorhebt. NServiceBus ist ein Open Source Projekt und kann von jedem frei heruntergeladen und eingesetzt werden. Funktionsweise Dadurch, dass NServiceBus auf asynchrone Kommunikation setzt, ist es möglich solide und flexible Programmschnittstellen zu entwickeln, welche unabhängig voneinander betrieben werden können. Mit Hilfe einer asynchronen Kommunikation kann ein Dienst einem anderen eine Nachricht zusenden ohne auf dessen Antwort warten zu müssen. Die Nachricht landet beim Empfänger in eine Queue, der die einzelnen Anfragen nacheinander ausführt. Dies ist insbesondere dann von Vorteil, wenn der Sender eine schnellere Datenverarbeitung aufweist als der Empfänger, was in den heutigen Systemumgebungen häufig der Fall ist. NServiceBus verwendet als Queue Implementation MSMQ. Entwickler, welche NServiceBus verwenden möchten, sind von vorne herein dazu verpflichtet, Systemschnittstellen asynchron zu implementieren. Wird dieses Prinzip jedoch nicht eingehalten und die Schnittstelle z.b. synchron ohne die Verwendung einer Queue implementiert, so stellt in diesem Falle NServiceBus keinen wirklichen Gewinn, sondern vielmehr einen Durchlauferhitzer dar, der ebenso gut gänzlich ausgelassen werden könnte. Kommunikationsmethoden Die Endpunkte von Diensten oder Anwendungen können über NServiceBus auf drei wesentlichen Arten angesprochen werden: Store & Forward (Fire and forget) Request / Response Publish / Subscribe Die wohl einfachste Art der Kommunikation ist das übermitteln einer simplen Nachricht oder Anweisung. Wenn dabei der Sender nicht einmal eine Antwort erwartet, spricht man vom sogenannten Store & Forward Prinzip (vgl. Abbildung 20). Umgangssprachlich hat sich auch der Begriff Fire & forget etabliert. Abbildung 20: Store & Forward Abbildung 21: Request / Response Wird hingegen eine Antwort vom Empfänger auf eine Nachricht erwartet, spricht man von Request / Response (vgl. Abbildung 21). Eine Erweiterung dieses Prinzips stellt das Publish / Subscribe Muster dar (vgl. Abbildung 22), welches bereits im Abschnitt 3.7 Event-Driven Messaging vorgestellt wurde. Hier können sich mehrere Empfänger (Subscriber) bei einem Sender (Publisher) registrieren. Sobald der Publisher eine neue Nachricht zu senden hat, wird diese an alle registrierte Subscriber weitergeleitet. Dieses Nachrichtenprinzip findet seine Anwendung in Systemen, in welchen die Empfänger einer Nachricht noch nicht bestimmt oder offen sind. Als Beispiel kann hier ein Kundenverwaltungssystem genommen werden. In diesem System werden alle Kundenspezifischen Daten zentral verwaltet. Wenn ein Kunde eine Adressänderung vornimmt, publiziert der Publisher diese Änderung allen Subscriber des Kundenverwaltungssystems. Sollten weitere Anwendungen oder Dienste zu einer bestehenden IT Infrastruktur hinzugefügt werden, können sich diese einfach als Subscriber bei Student: Marko Marković Seite 24 von 95

25 dem entsprechend Publisher registrieren lassen. Eine Anpassung des bestehenden Systemnetzes ist nicht nötig, sofern das gleiche Nachrichtenformat von allen Subscriber verwendet wird. Abbildung 22: Publish / Subscribe In allen Fällen der Nachrichtenkommunikation trägt NServiceBus die Verantwortung, dass eine Nachricht auch ihren Empfänger findet. Dem Entwickler wird damit diese Last von den Schultern genommen. Sollte es zu einem Netzwerkunterbruch kommen, wird von NServiceBus automatisch eine entsprechende Ausnahme (Exception) erzeugt. Diese kann vom Schnittstellenentwickler abgefangen und dem Endbenutzer in darstellbarer Form angezeigt werden. Implementation Bei der Verwendung von NServiseBus wird an einem bestehendem Dienst oder Applikation die Kommunikationskomponente zusätzlich angehängt. Das dadurch resultierende System erinnert vielmehr an ein Peer-to-Peer Netzwerk als an einen eigentlichen Bus mit zentraler Anlaufstelle. Abbildung 23: Busaufbau bei NServiceBus (Quelle: NServiceBus ist als ein Framework aufgebaut. Basierend auf diesem Framework kann man Senderwie auch Empfängerfunktionen implementieren. Das Framework beinhaltet viele Interfaces, von denen die meisten lediglich Marker sind. Klassen welche diese Marker implementieren werden zur Laufzeit von NServiceBus verwaltet. Die wichtigsten Interfaces sind in der nachfolgenden Tabelle kurz beschrieben. Interface IMessage Beschreibung Kennzeichnet eine Nachrichtenklasse, welche für den reinen Datenverkehr gedacht ist. Klassen, welche dieses Interface imple- Student: Marko Marković Seite 25 von 95

26 AsA_Client AsA_Server IConfigureThisEndpoint IHandleMessages<T> Abbildung 24: NServiceBus Interface Beschreibung mentieren, besitzen in der Regel keine logischen Methoden, sondern lediglich Properties. Kennzeichnet Klassen für die Konfiguration auf der Clientseite. Wird in Kombination mit IConfigrueThisEndpoint verwendet. Klassen, welche dieses Interface implementieren, implementieren i.d.r. keine weiteren Methoden. Sie bleiben vorwiegend leer. Bsp: class EndpointConfig : IConfigureThisEndpoint, AsA_Client { Kennzeichnet Klassen für die Konfiguration auf der Serverseite. Wird in Kombination mit IConfigrueThisEndpoint verwendet. Klassen, welche dieses Interface implementieren, implementieren i.d.r. keine weiteren Methoden. Sie bleiben vorwiegend leer. Bsp: class EndpointConfig : IConfigureThisEndpoint, AsA_Server { Kennzeichnet Klassen, welche eine Netzwerkkonfiguration übernehmen. Wird in Kombination mit AsA_Server oder AsA_Client verwendet. Die eigentliche Konfiguration übernimmt das Framework. Klassen, welche dieses Interface implementieren, verarbeiten übermittelte Nachrichten. Als Nachrichten sind alle Klassen möglich, welche das IMessage Interface implementieren. Bei der Verwendung von NServiceBus wird empfohlen, dass diejenigen Klassen, welche für die Kommunikation serialisiert und übermittelt werden, in einem separaten Package abgelegt werden. Dieses Package wird von allen Komponenten eingebunden, welche auf der Grundlage der darin enthaltenen Klassen kommunizieren möchten. Ein typisches Beispiel einer Klassenstruktur mit NServiceBus ist auf der Abbildung 25 dargestellt. Abbildung 25: Einfacher Aufbau einer Client-Server-Kommunikation in NServiceBus Wie man schnell erkennt, sind nur wenige Klassen auf der Client- sowie Serverseite notwendig um eine Kommunikation mit NServiceBus zu realisieren. Dies ist unter anderem auch der Grund, wieso sich NServiceBus einer so grossen Beliebtheit erfreut. Auf dieser Grundlage können bestehende Systeme sehr leicht ausgebaut und flexibel an das Kommunikationsnetz angeschlossen werden. Im Beispiel aus der Abbildung 25 wird auf der Client-Seite von der RequestSender Klasse eine Anfrage vom Typ InfoAnfrage an den Server gesendet. Auf der Serverseite implementiert die Klasse RequestDataMessageHandler das Interface IHandleMessages<InfoAnfrage> und ist dadurch auto- Student: Marko Marković Seite 26 von 95

27 matisch für die Nachrichtenverarbeitung zuständig. Der vollständige Code sowie die notwendigen Konfigurationseinstellungen sind im Anhang I unter 8.1 Einfache Nachrichtenübermittlung in NServiceBus auf Seite 80 aufgeführt. Sicherheit Einer der wichtigen Aspekte in Bezug auf SOA System ist die Sicherheit. Bezüglich der sicheren Nachrichtenübermittlung bietet NServiceBus eine Möglichkeit die verschickten Nachrichten einfach verschlüsseln zu lassen. NServiceBus implementiert den als hochsicher geltenden Verschlüsselungsalgorithmen AES 2. Um die verschlüsselte Nachrichtenübertragung zu aktivieren, wird der Schlüssel in der Konfigurationsdatei gesetzt. Ein möglicher Eintrag könnte wie folgt aussehen: <?xml version="1.0" encoding="utf-8"?> <configuration> <configsections>... <section name="rijndaelencryptionserviceconfig" type="nservicebus.config.rijndaelencryptionserviceconfig, NServiceBus.Core"/> </configsections>... <RijndaelEncryptionServiceConfig Key="gdDbqRpqdRbTs3mhdZh9qCaDaxJXl+e7"/> </configuration> Diese Einstellung regelt zwar den verschlüsselten Nachrichtenaustausch. Ein weiterer wichtiger Punkt betrifft das Policy-Management. Wann darf ein Benutzer bzw. eine Anwendung einen bestimmten Dienst nutzen? Leider hat für diesen Sachverhalt NServiceBus keine so einfache Lösung parat. Da es sich hierbei um ein einfaches Kommunikationsframework handelt, müssen geschäftsspezifische Sicherheitsmechanismen in den jeweiligen Programmschnittstellen explizit ausprogrammiert werden. Eine Rule- oder Policy-Konfigurationsmöglichkeit wird nicht angeboten. Sagas Einen der Kernkonzepte von NServiceBus stellen die Sagas dar. Eine Saga ist im Grunde genommen eine statusgebundene (stateful) Klasse. Diese ist für die Bearbeitung von mehreren in Abhängigkeit zueinander stehender Nachrichten zuständig. Eine Saga wird nicht im Arbeitsspeicher (RAM) aufbewahrt, sondern nach deren Generierung persistent in eine Datei oder Datenbank gespeichert. Dadurch ist es möglich parallel eine grosse Anzahl Sagas im Bus zu haben, ohne sich Gedanken über die Arbeitsspeicherkapazität zu machen. Zudem gehen die Nachrichten nicht verloren, sollte ein Dienst plötzlich ausfallen. Ein Prozess wird dadurch fehlertoleranter und skalierbar. Sagas beschreiben den Weg den NServiceBus entgegen dem Workflow Ansatz eingeschlagen hat [3]. Das Problem von Workflows in.net besteht darin, dass diese sehr restriktiv sind. Transaktionen sind dadurch schwieriger zu handhaben. Zudem benötigt man für einen sauberen Workflow allgemein mehr Zeit, als wenn man die Verarbeitungslogik in einem einfachen Stück Code festlegt. 2 AES steht für Advanced Encryption Standard. Es handelt sich hierbei um ein symmetrisches Verschlüsselungsverfahren, welches in einem vom National Institute of Standards and Technology (NIST) im Oktober 2000 lancierten Wettbewerb sich als Standard durchgesetzt hat. Der hinterlegte Rijndael-Algorithmus wurde nach seinen Entwicklern Joan Daemen und Vincent Rijmen benannt. Die korrekte Aussprache lautet Reindahl. Student: Marko Marković Seite 27 von 95

28 Um eine Klasse als Saga zu markieren, wird nicht das IMessage Interface, sondern das IContainSagaData Interface implementiert. Die entsprechenden Properties müssen anschliessend als virtual gekennzeichnet werden. Siehe nachfolgendes Beispiel: public class MySagaData : IContainSagaData { // Pflichtfelder gemäss IContainSagaData public virtual Guid Id { get; set; public virtual string Originator { get; set; public virtual string OriginalMessageId { get; set; // Nachfolgend können beliebe Eigenschaften hinzugefügt werden, solange // diese als virtual gekennzeichnet sind NServiceBus setzt NHibernate für die transparente Speicherung von Saga Daten in eine Datenbank ein. NServiceBus generiert hierfür automatisch das zu verwendete Datenbankschema. Diese Funktion kann jedoch vom Entwickler individuell auch deaktiviert werden. Hierfür wird als Interface nicht IContainSagaData angegeben, sondern IPersistSagas. Sobald die Saga Daten spezifiziert sind, kann die Prozesslogik in einer eigenständigen Saga Klasse genauer implementiert werden. In diesem Fall erbt die Klasse von der Basisklasse Saga<T> und implementiert pro verwendeter Saga Datenklasse jeweils das IHandleMessages<T> oder das IAmStartedByMessages<T> Interface. Das IAmStartedByMessages<T> Interface darf im Gegensatz zum IHandlemessages<T> Interface nur einmal implementiert werden. Das IAmStartedByMessages<T> Interface gibt die Saga Datenklasse an, welche den eigentlichen Saga Prozess startet. Beim Eintreffen einer solchen Message wird eine neue Instanz von der Saga Prozessklasse vom NServiceBus instanziiert. Folgendes Beispiel soll zur Veranschaulichung dienen: public class MySaga : Saga<MySagaData>, IAmStartedByMessages<Message1>, IHandleMessages<Message2>, IHandleMessages<Message3> { // Saga beginnt mit diesem Handler public void Handle(Message1 message) { this.data.id = message.id; // Code für die Nachrichtenbehandlung von Message1 public void Handle(Message2 message) { // Code für die Nachrichtenbehandlung von Message2 public void Handle(Message3 message) { // Code für die Nachrichtenbehandlung von Message3 public override void ConfigureHowToFindSaga() { Student: Marko Marković Seite 28 von 95

29 ConfigureMapping<Message2>(s => s.id, m => m.id); ConfigureMapping<Message3>(s => s.id, m => m.id); Man beachte, dass im Handler der Klasse Message1 die ID der aktuellen Saga Instanz übergeben wird. Dies gewährleistet, dass beim asynchronen Eintreffen einer Folgenachricht (z.b. Message2 oder Message3) die richtige Saga Instanz die eintreffende Nachricht bearbeitet. Die Methode Configure- HowToFindSaga übernimmt das benötigte Mapping. Wie mehrfach bereits erwähnt, baut NServiceBus auf einer asynchrone Kommunikationsgrundlage auf. Das heisst, dass das Eintreffen einer Antwort auf eine Anfrage durchaus eine gewisse Zeit in Anspruch nehmen kann. In den meisten geschäftsbezogenen Abläufen muss eine Prozessbearbeitung jedoch innerhalb einer nützlichen Frist abgeschlossen werden. Jeder Bearbeitungsschritt ist in gewisser Weise mit einem Timeout versehen. Dies macht durchaus Sinn, denn man möchte ja schliesslich nicht ewig auf das Ergebnis eines Prozesses warten. Auch für dieses Problem hat NServiceBus eine Lösung parat. Die Basisklasse Saga<T> implementiert die Methode Timeout, welche von den ableitenden Klassen überschrieben werden kann. Die Dauer des Timeouts kann entweder in der Konfigurationsdatei von NServiceBus oder innerhalb einer Nachrichtenmethode der betreffenden Saga Klasse festgelegt werden. Sobald ein Prozess zu lange für die Bearbeitung einer Anfrage braucht, wird die Timeout Methode von NServiceBus aufgerufen. Diese beinhaltet die entsprechende Geschäftslogik zur Rücknahme einer Anfrage sowie die allfällige Fehlerbehandlungen. Folgendes Quellcodebeispiel soll den beschriebenen Sachverhalt verdeutlichen: public class MySaga : Saga<MySagaData>, IAmStartedByMessages<Message1>, IHandleMessages<Message2>, IHandleMessages<Message3> { // Saga beginnt mit diesem Handler public void Handle(Message1 message) { this.data.id = message.id; // Setze Timeout auf eine Stunde ab Nachrichtenerhalt RequestTimeout(TimeSpan.FromHours(1), "irgendein Status"); // Code für die Nachrichtenbehandlung von Message1 public override void Timeout(object state) { // Code für die individuelle Geschäftslogik if (!Data.Message2Arrived) ReplyToOriginator(new TiredOfWaitingForMessage2()); public void Handle(Message2 message) { Data.Message2Arrived = true; Student: Marko Marković Seite 29 von 95

30 // Code für die Nachrichtenbehandlung von Message2 ReplyToOriginator(new AlmostDoneMessage { this.data.id = message.id );... Die Methode ReplyToOriginator wird ebenfalls von der Basisklasse Saga<T> implementiert und dient zur Rückmeldung von Meldungen an den Nachrichtenabsender. Im obigen Codebeispiel erfolgt eine Rückmeldung mittels ReplyToOriginator in zwei Fällen. In einem Fall, falls der Message2 Handler rechtzeitig eine Meldung erhält, und im anderen Fall, falls das Timeout abgelaufen ist. Je nach Ereignis wird entweder eine Nachricht vom Typ TiredOfWaitingForMessage2 oder AlmosDoneMessage zurückgegeben. Load Balancing Load Balancing wird in NServiceBus mit Hilfe eines sogenannten Distributors erreicht. Dieser führt eine eigene Distributor Queue und verteilt eingehende Nachrichten an die registrierten Arbeiterdienstinstanzen (nachfolgend Worker) (vgl. Abbildung 26). Sobald ein Worker bereit für die Nachrichtenverarbeitung ist, meldet er dies dem Distributor. Der Distributor führt ein internes Register über alle verfügbare Worker sowie deren Bereitschaftsstatus. Sind alle Worker besetzt, bewahrt der Distributor eintreffende Nachrichten in seiner Queue auf, bis einer frei wird. Abbildung 26: Load Balancing in NServiceBus Der Distributor wird über die Konfigurationsdatei NServcieBus.Distributor.dll konfiguriert. Diese kann beispielsweise folgenden Inhalt haben: <?xml version="1.0" encoding="utf-8"?> <configuration> <appsettings> <add key="numberofworkerthreads" value="1"/> <add key="errorqueue" value="error"/> <!-- Serialisierungsverfahren: Kann entweder "xml" oder "binary" sein --> Student: Marko Marković Seite 30 von 95

31 <add key="serialization" value="xml"/> <!-- Für XML Serialisierung muss ein Namespace angegeben werden --> <add key="namespace" value="http://www.hslu.ch"/> <!-- Distributor Einstellungen --> <add key="storagequeue" value="distributorstorage"/> <add key="datainputqueue" value="distributordatabus"/> <add key="controlinputqueue" value="distributorcontrolbus"/> </appsettings> </configuration> Auffällig sind die verschieden Queues, die für einen Distributor konfiguriert werden müssen. Die StorageQueue legt fest, in welcher Queue die Workerstatus gespeichert werden sollen. Vorzugsweisse sollte sich diese auf demselben Rechner wie der Distributor befinden. An die Queue DataInputQueue senden die Worker ihre fertig verarbeiteten Nachrichten zurück. An die Queue ControlInputQueue senden die Worker ihren operativen Verarbeitungsstatus, anhand dessen ihre Verfügbarkeit beurteilt wird. Dementsprechend müssen die Queues DataInputQueue sowie ControlInputQueue bei den Worker konfiguriert werden. Die Worker entnehmen ihre Konfigurationsinformationen aus der App.config der Anwendung. Eine entsprechende Einstellung könnte wie folgt aussehen: <UnicastBusConfig DistributorControlAddress="distributorControlBus" DistributorDataAddress="distributorDataBus"> <MessageEndpointMappings> <!-- Weitere Einstellungen --> </MessageEndpointMappings> </UnicastBusConfig> Es ist auch möglich für dieselbe StorageQueue mehrere Distributoren mit unterschiedlichen DataInputQueue und ControlInputQueue zu konfigurieren. So kann eine Mehrfachredundanz für die Gewährleistung von hochverfügbaren Systeme eingerichtet werden. Implementierte ESB Funktionskomponenten NServiceBus bietet viele Möglichkeiten eine Dienstinfrastruktur aufzubauen. Obwohl es sich hierbei nicht um einen ESB im eigentlichen Sinne handelt, können fehlenden ESB Funktionen theoretisch weitgehend selber ausprogrammiert werden, sofern benötigt. Eine Übersicht, wie NServiceBus die ESB Funktionskomponenten aus dem Kapitel 3: Das Enterprise Service Bus SOA Pattern umsetzt, gibt Tabelle 2. ESB Funktionskomponente Beschreibung Asynchronous Queuing NServiceBus baut auf der asynchronen Kommunikation mittels MSMQ auf. Diese ESB Komponente ist somit bereits vollständig in NServiceBus integriert. Data Format Transformation Das Prinzip der Datenformattransformation besteht darin, dass zwei Dienste mit unterschiedlichen Datenformaten trotzdem miteinander Kommunizieren können. Die Konvertierung übernehmen Adapter, welche in NServiceBus separat ausprogrammiert und in den jeweiligen Diensten zwischengeschaltet werden müssen. Data Model Transformation Gleich wie bei der Datenformattransformation muss auch bei der Datenmodelltransformation die Konvertierungsschicht separat aus- Student: Marko Marković Seite 31 von 95

32 Event Driven Messaging Intermediate Routing Policy Centralization Protocol Briding Reliable Messaging Rules Centralization Tabelle 2: ESB Funktionskomponenten in NServiceBus programmiert werden. Eine einfache Konfigurationsmöglichkeit bietet NServiceBus nicht an. NServcieBus unterstützt das Publish / Subscribe Nachrichtenprinzip bereits im Framework. Beim Intermediate Routing muss man zwischen zwei Aspekten unterscheiden. Intermediate Routing umfasst einerseits die Unterstütz der direkte Nachrichtenweiterleitung zu einem Dienst aufgrund des Nachrichteninhaltes, und andererseits das Load Balancing von Nachrichten zwischen zwei oder mehreren gleichwertigen Diensten. NServiceBus unterstützt beide Aspekte bereits im Framework von Haus aus. Das Konzept der Policy Centralization ist schwergewichtig auf Web Services ausgelegt. NServiceBus unterstützt zwar die Dienstanbietung mittels Web Service, aber lediglich auf rudimentärer Basis. Eine Polcy Centralization ist im Framework nicht vorgesehen. NServiceBus unterstützt die Kommunikation von Nachrichten auf unterschiedlichen Ports. Eigens für die zuverlässige Nachrichtenverarbeitung implementiert NServiceBus das Konzept der Sagas. Auch diese werden bei der Weiterverarbeitung in eine Datenbank zwischengespeichert. Regelbasierte Prozessverarbeitung kann nur genutzt werden, wenn ein entsprechender Dienst implementiert und konsequent auch verwendet wird. Unter Umständen kann dies relativ schnell komplex werden. NServiceBus unterstützt somit nur bedingt die wichtigsten ESB Kernfunktionen. Die Bemerkungen aus der Tabelle 2 wurden in Abbildung 27 für einen besseren Überblick nochmals anschaulich illustriert. NServiceBus Asynchronous Queuing Intermediate Routing Policy Centralization Event Driven Messaging Service Broker Reliable Messaging Rules Centralization Data Model Transformation Data Format Transformation Protocol Briding Legende Vom Framework unterstützt Muss selber anwendungsspezifisch implementiert werden Wird nicht unterstütz Abbildung 27: Von NServiceBus implementierte ESB Funktionskomponenten Fazit NServiceBus bietet sehr viele nützliche Funktionen für die Herstellung einer ausbaufähigen Kommu- Student: Marko Marković Seite 32 von 95

33 nikationsplattform. Es ist sehr leichtgewichtig, stabil und einfach zu implementieren. Bei Schwierigkeiten Hilft einem die online Dokumentation oder das Community Forum weiter. NServiceBus wird laufend weiterentwickelt und bietet mittlerweile bereits einfache Einbindungsmöglichkeiten für die- BizTalk Serverumgebung an. Somit lohnt sich eine vertiefte Untersuchung der Möglichkeiten, welche dieses Produkt anbietet. Welche Funktionen NServiceBus weiter bereitstellt und ob es sich auch der Einsatz in einem Firmenumfeld eignet, wird vertieft im Kapitel 5: NServiceBus vs. Neuron ESB beschrieben Simple Service Bus Allgemein Simple Service Bus stellt eine Erweiterung von NServiceBus dar. Es handelt sich hierbei ebenfalls um eine Open Source Lösung, welche sich jedoch immer noch im Alpha Stadium befindet. Die Entwicklung schreitet nur langsam voran. Das letzte Release wurde im Februar 2009 veröffentlicht. Simple Service Bus setzt den Fokus auf diejenigen Funktionen, welche gemäss dessen Entwickler bei NServiceBus vernachlässigt wurden. Dies betrifft das Endpunkt Management sowie das Monitoring. In der Tat kann der aktuelle Stand der Nachrichten Abbildung 28: Simple Service Bus Logo sowie der Servicestatus in NServiceBus nicht über eine einheitliche Konsole eingesehen werden. Es sei den man programmiert diese selber aus. Funktionsweise Der im Simple Service Bus hinterlegte Mechanismus ist für die Dienstverwaltung sehr praktisch und soll hier kurz erläutert werden. Als Beispiel soll das auf der Abbildung 29 dargestellt Modell dienen. Abbildung 29: Simple Service Bus Endpoint Managment & Monitoring System (Quelle: Student: Marko Marković Seite 33 von 95

34 In diesem Beispiel sind drei Endpunkte bzw. Services A, B und C aufgeführt. Diese senden in Regelmässigen Abständen Zustands- und Auslastungsinformationen an den Endpunkt Monitor Service. Der Endpunkt Monitor Service sammelt diese Angaben und publiziert diese an registrierte Subscriber. In diesem Beispiel gibt es nur einen Subscriber. Dieser ist ein Überwachsungsdienst, welcher auf dem Rechner des Systemadministrators läuft. Über den Überwachsungsdienst kann der Administrator auf einen Blick den Stand aller Services in der SOA Umgebung einsehen (vgl. Beispiel in Abbildung 30). Falls der Administrator weiterführende Informationen eines Dienstes benötigt, kann er diese direkt vom betreffen Dienst einholen und sich anzeigen lassen. Abbildung 30: Beispiel eines Dienst Monitoring in Simple Service Bus Fazit Leider bietet Simple Service Bus keine umfassend fertige Monitoring Applikation an. Die angebotenen Bibliotheken stellen zwar einen ersten Schritt in die richtige Richtung dar, weisen jedoch Defizite auf, was deren direkte Anwendung betrifft. Auch hier muss der Entwickler die bestehenden Funktionen um den gewünschten Funktionsumfang selber ergänzen, damit der Einsatz in einem produktiven Umfeld möglich wäre. Deshalb darf man Simple Service Bus (noch) nicht als Ersatz von NServiceBus in Betracht ziehen. Für die weiteren Untersuchungen im Bereich der leichtgewichtigen Frameworks wird daher NServiceBus bevorzugt. Nicht zuletzt auch weil NServiceBus einen wesentlich stabileren Entwicklungsstand gegenüber Simple Service Bus aufweist. Auf Simple Service Bus wird in dieser Arbeit kein weiterer Bezug mehr genommen Neuron ESB Allgemein Neudesic ist eine in Irvine (Kalifornien, USA) sesshafte und von Microsoft zertifizierte Firma. Sie ist eine der wenigen Unternehmen, welche eine in.net entwickelte ESB Implementation kommerziell vertreibt. Ihr Produkt wird unter dem Namen Neuron ESB vermarktet. Dieses ist speziell auf die Bedürfnisse von Mittel- und Grossunternehmen ausgerichtet. Das Produkt kann nur Abbildung 31: Neuron ESB Logo Student: Marko Marković Seite 34 von 95

35 auf Anfrage bestellt und bezogen werden. Die Kosten, mit welchen man bei der Anschaffung rechnen muss, bewegen sich im 5 bis 6 stelligen Bereich. Seit kurzem steht eine 30 Tages Demoversion zum Download zur Verfügung. Die Hauptmerkmale von Neuron ESB gemäss Hersteller sind: Implementation eines Enterprise Service Bus Aufbau nach dem Publisher / Subscriber Model Flexible konfigurierbare Integration von Systemschnittstellen Real-Time Integrationsüberwachung Nachrichtenbasierte Weiterleitung Spezielle Neuron Adapter, welche über Pipelines mehrfach verschachtelt werden können, ermöglichen einen flexiblen Datenaustausch zwischen den Schnittstellen. Die Adapter können so konfiguriert werden, dass nur wenn bestimmte Kriterien erfüllt sind, die Nachrichten an eine definierte Schnittstelle weitergeleitet werden. Weiter dienen die Adapter ebenfalls der Nachrichtentransformation. So kann eine eingehende Nachricht theoretisch an alle möglichen Schnittstellen weitergeleitet werden. Für die Nachrichtentransformation verwendet Neuron ESB XSL Transformationen. Neuron ESB realisiert alle unterstützen Funktionen durch die Verwendung von auf Microsoft Produkten basierenden Technologien. Dazu gehören unter anderem:.net 3.0/3.5 Windows Communication Foundation MSMQ Microsoft BizTalk Server 2006 R2 Microsoft SQL Server Ein Neuron ESB benötigt nicht zwangsläufig einen BizTalk Server. Wenn ein Unternehmen keinen BizTalk Server im Einsatz hat, bedeutet dies lediglich, dass die Vorteile, welche ein BizTalk Server mit sich brächte, von Neuron ESB nicht genutzt werden können. Neuron ESB ist so ausgerichtet, dass alle konfigurierbaren Einstellungen über ein GUI dem sogenannten Neuron ESB Explorer vorgenommen werden können. So kann der Entwicklungsaufwand für die Erstellung und Anpassung von ESB Schnittstellen wesentlich minimiert werden. Breite Schnittstellenunterstützung Neuron ESB unterstützt für Schnittstellen die folgende Ein- bzw. Ausgangsnachrichtenformate: Dateiübermittlungen REST Einfaches HTTP Mittels WSDL spezifizierte Web Services NetTCP MSMQ IBM WMQ Microsoft Dynamics (Great Plains, CRM) Microsoft SQL Server Student: Marko Marković Seite 35 von 95

36 Microsoft BizTalk Server 2006 R2 RFID Microsoft Office SharePoint Server 3.0 Compliant Microsoft WCF LOB Adapter Microsoft BizTalk WCF unterstützte Anwendungsadapter o mysap Business Suite o Oracle Database o Siebel ebusiness Applications Alle diese Formate werden durch spezielle Adapter realisiert. Weitere Schnittstellenanbindungen befinden sich noch in Arbeit. Messaging Neuron ESB unterstützt ähnliche Kommunikationsmethoden wie NServiceBus. Die drei grundlegenden Messaging Verfahren werden auch von Neuron ESB abgedeckt. Diese sind: Store & Forward (Fire and forget) Request / Response Publish / Subscribe Im Gegensatz zu NServiceBus werden die einzelnen Publisher- und Subscriber-Schnittstellen zentral auf dem Neuron ESB Server konfiguriert. Jede Schnittstelle kann drei Konfigurationsstatus einnehmen: Publisher Subscriber Publisher & Subscriber (Hybrid) In Neuron ESB werden alle Schnittstellen einem Topic (wie z.b. Web Shop oder Legacy System) untergeordnet. So kann eine bessere Übersicht über die einzelnen Dienste bewahrt werden. Zudem bietet Neuron ESB im Neuron ESB Explorer eine angemessene Darstellung der einzelnen Services in einem sogenannten ESB Diagram an. Ein Ausschnitt eines solchen Diagrammes ist auf der nachfolgenden Abbildung 32 dargestellt. Abbildung 32: ESB Diagramm im Neuron ESB Explorer Student: Marko Marković Seite 36 von 95

37 Dank dem ESB Diagramm erkennt man auf einen Blick, die Subscriber und Publisher eines SOA Systems. Die Kommunikationsschnittstellen werden einem Dienst in der Konfigurationsdatei App.config zugewiesen. Wie nachfolgendes Beispiel zeigt: <?xml version="1.0" encoding="utf-8"?> <configuration> <appsettings> <add key="esbclientid" value="kundenrabattcustomerupdatesubscriber"/> <add key="esbzone" value="enterprise"/> <add key="esbserviceaddress" value="net.tcp://localhost:50000"/> <add key="esbserviceidentity" value=""/> </appsettings> </configuration> Auffällig ist hierbei, dass keine weiteren Angaben über die Zieldienste benötigt werden, wie es bei NServiceBus der Fall ist. Alle Einstellungen werden über den Neuron ESB Explorer direkt auf dem Server vorgenommen. Am Dienst selbst oder an seiner Konfiguration sind keine weiteren Anpassungen erforderlich. Dies ermöglicht schnelle und flexible Anpassungen an der SOA Infrastruktur. Vor allem bei Änderungen, bei welchen gleich mehrere Dienste betroffen sind, ist diese Eigenschaft sehr praktisch. Sicherheit Neuron ESB unterstützt ebenfalls eine verschlüsselte Nachrichtenübertragung. Dafür gibt es ein spezielles Schlüsselregister, welche alle verwendeten Schlüssel verwaltet (vgl. Abbildung 33). Abbildung 33: Erzeugung eines Key zur verschlüsselten Kommunikation in Neuron ESB Es werden mehrere, bekannte Verschlüsselungsverfahren unterstützt. Dies sind: Student: Marko Marković Seite 37 von 95

38 3DES DES RC2 RIJ (bzw. AES) Sobald ein Schlüssel erstellt wurde, kann dieser einem Topic zugewiesen werden (vgl. Abbildung 34). Sobald ein Topic einen Schlüssel zugewiesen bekommt, erfolgt die gesamte Kommunikation unter diesem Topic verschlüsselt. Dies erhöht einerseits die Sicherheit im ESB System, andererseits hat diese Einstellung auch einen negativen Einfluss auf die Performance des Systems, da alle Nachrichten von Neuron ESB bei der Übertragung ver- und entschlüsselt werden müssen. Abbildung 34: Zuweisung eines Key zur Verschlüsselten Datenkommunikation innerhalb eines Topics Neben der Verschlüsselung des Nachrichtenkanals ist es auch möglich Benutzerkonten als sogenannte Credentials in Neuron ESB zu erfassen. Als Credential können fiktive Name einer Applikation oder eines Dienstes verwendet werden. Über Zugriffslisten können die Credentials zu Zugriffsrollen zusammengefasst werden. Diese Zugriffslisten können einem oder mehreren Services zugeordnet werden, so dass nur eine beschränkte Anzahl von Applikationen oder Diensten diesen zu nutzen vermag. An Stelle von Credentials ist es aber auch möglich Windows Benutzerkonten oder Benutzergruppen, welche in einem Active Directory erfasst sind, anzugeben. Dem Administrator einer mittels Neuron ESB eingerichteten SOA Infrastruktur stehen somit eine Vielzahl von Möglichkeiten zur Verfügung, wie die Frage der Zugriffssicherheit gelöst werden kann. Pipelines Pipelines sind ein sehr mächtiges Funktionskonzept von Neuron ESB. Es können mehrere durchzuführende Verarbeitungsschritte in einer Pipeline zusammengefasst werden. Pipelines werden in der Regel einem oder mehreren Services zugeordnet. Dieser ruft eine oder eine ganze Kette von Pipeli- Student: Marko Marković Seite 38 von 95

39 nes vor oder nach dem Eintreffen einer Nachricht auf (vgl. Abbildung 35). Dadurch können diverse Aktionen durchgeführt werden, welche für die effektive Nachrichtenverarbeitung benötigt werden. Abbildung 35: Pipeline Konzept in Neuron ESB Ein Überblick über die verschiedenen Pipelinefunktionen, welche von Neuron ESB angeboten werden, gibt die nachfolgende Tabelle 3. Pipelinefunktion Beschreibung Nachrichtenvalidierung Eine eintreffende Nachricht wird auf ihre Gültigkeit geprüft. Bei XML Nachrichten kann beispielsweise validiert werden, ob die XML Struktur einem vordefinierten XSD Schema entspricht. Nachrichtentransformation Nachrichten können transformiert werden. Dies wird insbesondere bei XML Nachrichten mittels XSLT angewandt. Nachrichten speichern Nachrichten können entweder in einer Message Queue oder in einer selbst spezifizierten Datenbank zwischengespeichert werden. Nachrichtenabfrage Bei gewissen Nachrichten müssen zu Validierungs- oder Weiterleitungszwecke Datenbankabfragen durchgeführt werden. Benachrichtigung Enthalten Nachrichte einen spezifischen Inhalt oder Status, können Benachrichtigungen an den Systemadministrator oder an einen anderen Dienst versendet werden (z.b. über ). Workflowausführung Die Einleitung eines komplexen Workflows ist mit Hilfe von Pipelines möglich. Richtlinien ausführen Sind Geschäftsregeln vorhanden, können diese ebenfalls in der Pipeline definiert werden. If Else End If Innerhalb einer Pipeline kann über bedingte Anweisungen firmenspezifische Geschäftslogik eingebaut werden. Dies wird vor allem für die Erstellung eines komplexen Workflows benötigt. Tabelle 3: Pipelinefunktionsübersicht in Neuron ESB Dank den umfangreichen Pipelinefunktionen können die einzelnen Verarbeitungsschritte bis zur Erstellung eines komplexen Workflows ausgedehnt werden. Im Neuron ESB Explorer stehen für jeden Verarbeitungstyp simple grafische Komponenten zur Verfügung. Über Drag-and-Drop können diese beliebig aneinander gesetzt werden. Auf Abbildung 36 ist als Beispiel ein Bestellprozess abgebildet, Student: Marko Marković Seite 39 von 95

40 welcher über eine Pipeline realisiert wird. Abbildung 36: Neuron ESB Explorer (Quelle: Die einzelnen Workflow Bausteine, welche innerhalb einer Pipeline zu einem komplexen Prozess zusammengesetzt werden können, sind auf der nachfolgenden Tabelle 4 beschrieben. Baustein Beschreibung Mittels Cancel wird die weitere Ausführung des Workflows abgebrochen bzw. beendet. Wenn Cancel aufgerufen wird, wird keine Meldung zum Bus weitergeleitet. Dies macht z.b. dann Sinn, wenn nach einer misslungenen XML Schemaprüfung (siehe Validate-Schema) die Nachricht nicht weitergeleitet werden soll. Durch den Code Baustein können benutzerdefinierte Befehlszeilen in den Workflow eingebaut werden. Es stehen jedoch nur die Standard.NET Assemblies für die Programmierung zur Verfügung. Externe Bibliotheken können nicht verwendet werden. Bei Decision handelt es sich um eine einfache Bedingung. Mit Hilfe vom Exception Baustein kann ein Abschnitt des Workflows mit einem Try-Catch-Finally Block versehen werden. In jedem Unterblock kann eine individuelle Ablauflogik eingebaut werden. Der Pop Baustein holt eine zuvor mittels Push abgelegte ESB Meldung aus dem internen Stack zur Weiterverarbeitung. Dieser Baustein darf erst nach einem Push Baustein eingesetzt werden. Über Publish können ESB Meldungen über ein Topic an registrierte Subscriber verteilt werden. Student: Marko Marković Seite 40 von 95

41 Der Push Baustein speichert die Referenz einer eintreffenden ESB Nachricht in einem internen Stack ab. Diese muss für eine spätere Verarbeitung mittels Pop wieder ausgelesen werden. Der Rethrow Baustein kann innerhalb eines Try-Catch-Finnaly Block dazu verwendet werden, um eine Exception an den Nachrichtensender zu verwerfen. Mit Hilfe von Retry kann ein fehlgeschlagener Verarbeitungsversuch wiederholt werden. Dies ist bei Aufrufen von langsamen Diensten hilfreich, bei denen hin und wieder eine Timeout-Exception geworfen wird. Über Rules - BizTalk kann eine Microsoft BizTalk Server Rule Engine Policy aufgerufen werden um den Inhalt einer ESB Meldung zu prüfen. Bei diesem Baustein wird ein WCF Service aufgerufen der das nötige IESBRulesService Interface implementiert. Über Rules - WF kann eine mittels.net Workflow Rules Engine definierte Regel zur Prüfung einer ESB Meldung aufgerufen werden. Mit Hilfe vom Service Baustein können andere Dienste aufgerufen werden. Bei den Diensten kann es sich hierbei um Web Services oder andere als Endpunkte im Neuron ESB Explorer konfigurierte Schnittstellen handeln. Der Set Property Baustein ermöglicht es bestimmte Headerinformationen einer ESB Meldung zu bearbeiten. Die Funktion des Split Bausteines hat viel mit einer for Schleife gemeinsam. Über Split kann eine eingehende Nachricht in verschiedene Teile zerlegt werden. Jeder dieser zerlegten Teile wird in einem Unterblock von Split nacheinander einzeln verarbeitet. Die Verarbeitungsschritte können als Unterprozess ebenfalls durch andere Workflow Bausteine definiert werden. Store wird dazu verwendet um Datensätze in eine Microsoft SQL Datenbank zu schreiben. Table Query führt Abfragen auf eine Microsoft SQL Datenbank aus. Durch den Trace Baustein können Debug Meldungen eines Workflows bei einem Testdurchgang ausgegeben werden. Mit Hilfe des Transaction Bausteines kann ein Unterprozess für Datenbankaktionen definiert werden, welche alle innerhalb derselben Microsoft SQL Datenbank Transaktion durchgeführt werden. Transform - Service ruft einen WCF Service auf, welcher das IESBTransformationService Interface von Neuron ESB implementiert. Die nötigen Transformationsschritte müssen in einem selbst definierten Adapter, welcher das IESBTransformationService Interface implementiert, programmatisch definiert werden. Mit Hilfe von Transform - Xslt können Nachrichten mit Hilfe von XSL Transformationen in ein anderes Nachrichtenformat konvertiert werden. Über Validate - Schema kann eine XML Nachricht darauf untersucht werden, ob sie einem vordefinierten XML Schema entspricht oder nicht. Validate - Service ruft einen WCF Service auf, welcher das IESBValidationService Interface von Neuron ESB implementiert. Innerhalb dieses Services können beliebe Schritte zur Validierung einer ESB Nachricht programmiert werden. Über den Workflow Baustein können.net Workflow aufgerufen werden. Mittels Xml Query können Daten, welche aus einer Microsoft SQL Datenbank ausgelesen wurden, als XML Daten einer Meldung hinzugefügt werden. Tabelle 4: Beschreibung der Neuron ESB Pipeline Workflow Bausteine Zonen In der Praxis hat sich vor allem bei Grossunternehmen gezeigt, dass ein zentraler ESB nur schwer Student: Marko Marković Seite 41 von 95

42 oder gar nicht realisierbar ist. Besonders schwierig wird es, wenn sehr viele Dienste verwaltet werden müssen und die Firma eine komplexe Organisationsstruktur aufweist, wie es z.b. bei Holding Unternehmen oft der Fall ist. Abhilfe kann das Federated ESB Pattern verschaffen. Statt einem zentralen werden mehrere, fachspezifische ESBs verwaltet, die untereinander verbunden sind (vgl. Abbildung 37) B2B ESB Finance ESB LOB ESB Services Abbildung 37: Beispiel einer Federated ESB Infrastruktur Jeder ESB verwaltet nur diejenigen Dienste, welche für eine bestimmte Gruppe von Aufgaben benötigt werden. Diese Partitionierung des zentralen ESB in separate Teil ESBs erfordert zwar einen gewissen Konfigurationsaufwand, bringt jedoch viele Vorteile mit sich. Zu einem wird der Single Point of Failure eliminiert, zum anderen kann jeder fachspezifische ESB für die Bewältigung seiner Aufgaben präzise und unabhängig Konfiguriert werden. Dies führt auch zu einer Erhöhung der Sicherheit. Zudem wird das System auch überschaubarer. So ist es zum Beispiel möglich einen B2B ESB zu definieren, dessen einzige Aufgabe darin besteht, externen Partnerfirmen bestimmte Services anzubieten. Alle sicherheitsrelevanten Einstellungen werden auf diesen B2B ESB vorgenommen. Die anderen ESBs im Bunde erfahren dahingegen keine Änderungen. Bei Neuron ESB spricht man statt von einem Federated ESB von so genannten Zonen. Eine Zone stellt einen logischen, fachspezifischen Teil ESB dar. Jede Zone kann einen oder mehrere ESB Servers enthalten. Ein ESB Server kann hingegen nur einer Zone zugeordnet sein. Die Darstellung der Zonen in Neuron ESB ist in Abbildung 38 illustriert. Abbildung 38: Bildung von Zonen in Neuron ESB Student: Marko Marković Seite 42 von 95

43 Jeder Service einer Unternehmung kann theoretisch in allen Zonen bzw. Teil ESBs mehrfach eingebunden werden. Möchte man hingegen aus sicherheitstechnischen Überlegungen einen Dienst nur über einen Teil ESB anbieten, müssen Brücken eingerichtet werden. Brücken gestatten es, dass ein Teil ESB auf einen Dienst eines anderen Teil ESB zugreift. So bleibt die Zugriffskontrolle auf diesen Dienst in der Hand des Anbieter ESBs. Folgendes Szenario soll die Sachlage etwas verdeutlichen: Angenommen man hat einen Teil ESB für Forschungsaufgaben, welcher einen Dienst ExperimentResults verwaltet. Die Informationen aus diesem Service möchte man einer Partnerfirma über einen B2B Teil ESB anbieten. Die Richtlinien der Firma verbieten es, dass der B2B Teil ESB Dienste direkt einbindet. Damit der ExperimentResults Service trotzdem über den B2B Teil ESB kontrolliert angeboten werden kann, wird eine Brücke zwischen dem Forschungs und dem B2B Teil ESB eingerichtet. Eine Brücke wird in Neuron ESB als Bridge bezeichnet. Farm Mode Eine andere Möglichkeit um das Risiko des Single Point of Failure zu minimieren und zugleich die Performance des ESB zu erhöhen, stellt in Neuron ESB der Farm Modus dar. Im Farm Modus unterhalten mehrere ESB Server Implementationen die ESB Infrastruktur aufrecht (vgl. Abbildung 39). Fällt ein Server aus, übernehmen die anderen, bestehenden Server Implementationen seine Aufgaben. Damit die notwendige Infrastruktur eingerichtet werden kann müssen verschiedene Anforderungen erfüllt werden. Zu einem wird ein Hardware oder Software Load Balancing System benötigt, das beim Ausfall eines ESB Servers die Nachrichten an die verbleibenden Server weiterleitet. Zum anderen muss eine MSSQL Datenbank eingerichtet werden, welche die Nachrichten sowie deren Verarbeitungsstatus zwischenspeichert und auf der alle Server Zugriff haben. So kann bei einer allfälligen Betriebsstörung eines Servers ein anderer dessen Aufgaben zur Laufzeit übernehmen. Der Dienstnutzer merkt von dieser Fehlerbehandlung gar nichts. Abbildung 39: Farm Mode in Neuron ESB Monitoring Dort wo Simple Service Bus sich um eine Erweiterung von NServiceBus bemüht, bietet Neuron ESB bereits eine fertige und vielfältige Monitoring Lösung für die Nachrichtenüberwachung an. So ist es zum Beispiel möglich auf einen Blick in Echtzeit die aktuelle Auslastung des ESB einzusehen. Hierfür wird für den Systemadministrator ein Balkendiagram aufbereitet, welche die Anzahl gesendeter und Student: Marko Marković Seite 43 von 95

44 empfangener Nachrichten anzeigt. Ein Beispiel eines solchen Balkendiagrams ist auf der Abbildung 40 dargestellt. Weiter sind auch Auswertungen über die Zeitachse möglich, in welchen die übermittelten Datenraten oder die Grösse der übermittelten Pakete ersichtlich sind. Auch ist es möglich den aktuellen Onlinestatus eines Endpunktes zu prüfen. Für Debug Zwecke ganz praktisch stellt Neuron ESB eine Möglichkeit bereit auf Datenbanken durchgeführte SQL Befehle einzusehen. So können allfällige Fehlimplementationen einfach ermittelt werden. Abbildung 40: Echtzeitauswertung der Nachrichtenverarbeitung in Neuron ESB Implementierte ESB Funktionskomponenten Bereits nach kurzem Browsen durch die vom Neuron ESB Explorer bereitgestellten Funktionen, stellt man fest, dass im Prinzip alle Komponenten eines ESB durch Neuron ESB abgedeckt werden. Wie bereits NServiceBus verwendet auch Neuron ESB MSMQ zur Realisierung asynchroner Kommunikation. Womit Asynchronous Queuing Eigenschaft bereits erfüllt wird. Transformationen von Datenmodell und -format sind genauso abgedeckt wie die Überbrückung von verschiedenen Transportprotokollen. Wodurch die Anforderungen eines Service Broker auch erfüllt sind. Die Intermediate Routing Eigenschaft wird über Pipelines und bereits durch die Verwendung des Farm Modus erfüllt. Neuron ESB verwendet für das Reliable Messaging eine SQL Datenbank. Die Policy Centralization kann über sogenannte Service Policies im Neuron ESB Explorer eingerichtet und verwaltet werden. Rules Centralization wird wiederum mittels Pipelines realisiert, da Regeldienste als Pipeline definiert und somit allen betreffenden Diensten zugewiesen werden können. Dadurch das Neuron ESB auch das Student: Marko Marković Seite 44 von 95

45 Publisher-Subscriber Muster implementiert, ist die Event Driven Messaging Komponente ebenfalls abgedeckt. Somit bleibt keine ESB Funktionskomponente übrig, welche Neuron ESB nicht auf irgendeine Art und Weise realisiert. Die einzelnen ESB Komponenten sind nochmals auf der nachfolgenden Abbildung 41 illustriert. Neuron ESB Asynchronous Queuing Intermediate Routing Policy Centralization Event Driven Messaging Service Broker Reliable Messaging Rules Centralization Data Model Transformation Data Format Transformation Protocol Briding Legende Vom Framework unterstützt Muss selber anwendungsspezifisch implementiert werden Wird nicht unterstütz Abbildung 41: Von Neuron ESB implementierte ESB Funktionskomponenten Fazit Obwohl dieser Abschnitt nicht alle Funktionen von Neuron ESB vorstellt und somit nur einen kurzen Einblick dieses Produktes gibt, lässt sich schnell erkennen, dass es sicher hierbei um eine mächtige Systemanwendung handelt. Von allen in dieser Arbeit vorgestellten Produkten ist Neuron ESB das einzige, welches als vollständige ESB Implementation im Sinne des Enterprise Service Bus SOA Pattern angesehen werden darf. Neben den vielen Funktionen beeindruckt Neuron ESB auch durch die Schnittstellenvielfalt, dass es anbietet. Dadurch ist es möglich eine Vielzahl von Diensten in einer Unternehmung anzubinden und zu integrieren. Neben einer guten Dokumentation mit vielen Beispielen bietet Neudesic einen 24h Supportservice an. Student: Marko Marković Seite 45 von 95

46 5 NServiceBus vs. Neuron ESB Wie bereits im vorhergehendem Kapitel 4 erwähnt, sollen die beiden vielversprechendsten Produkte Neuron ESB und NServiceBus einer genaueren Untersuchung unterzogen werden. Der Fokus soll hierbei auf die Flexibilität der beiden Produkte in Bezug auf alltägliche Probleme gesetzt werden. Wie Workflows mit den beiden Produkten in grafischer Form aufgestellt und ausgeführt werden können ist ein aufwendiges Unterfangen, das in dieser Arbeit bewusst ausgelassen wurde. Für eine bessere Bewertung von NServiceBus und Neuron ESB wurde eine Liste mit acht Szenarien ausgearbeitet. Jedes Szenario stellt entweder eine Aufgabe dar, die häufig auftritt, oder ein Problem, welches möglichst einfach gelöst werden soll. In jedem vorgestellten Szenario wird gezeigt, auf welche Art und Weise die beiden Produkte die Aufgabe lösen können und welches allfällige Alternativen sind. Anhand dieser Szenarien können ebenfalls Aussagen über die Wartungsfreundlichkeit der Produkte gemacht werden. Es wird nicht die vollständige Implementation der Szenarien aufgeführt, sondern immer nur die wesentlichen Teilaspekte. Eine vollumfassende Schritt für Schritt Anleitung, wie ein Projekt mit den beiden Produkten Neuron ESB und NServiceBus realisiert werden kann, ist im Anhang I auf Seite 80 beschrieben. Die vollständige Implementation der nachfolgend beschriebenen Szenarien kann in Form von Visual Studio und Eclipse Projekten auf dem Virtual Server markovic_esb eingesehen werden. Die entsprechenden Beispielprojekte sind im Ordner Szenarioliste auf dem Desktop zu finden. 5.1 Szenario 1: Mehrere Subscriber mit unterschiedlichen Parameter Das erste Szenario stellt eine recht simple und häufig auftretende Aufgabe in SOA Systemen dar. Es wird von einem Kundenkontoverwaltungssystem ausgegangen, das für die zentrale Verwaltung der Kundendaten zuständig ist. Daneben existieren diverse andere Applikationen, welche ihrerseits auch Kundendaten für Verarbeitungszwecke beinhalten, diese jedoch in einer separaten internen Datenbank speichern (vgl. Abbildung 42). Abbildung 42: Szenario 1 - Aufbau Student: Marko Marković Seite 46 von 95

47 In diesem Beispiel wären das, das Kundenrabattsystem, welches die jeweiligen Rabatte der Kunden berechnet, sowie das Firmen ERP System. Damit alle Kundendaten trotzdem auf dem aktuellsten Stand bleiben, sollen Änderungen im Kundenverwaltungssystem an die anderen Systeme weiterpropagiert werden. Man hat hier also einen klassischen Publisher-Subscriber Systemaufbau. Nun ist es meistens so, dass die Subscriber nicht alle Parameter benötigten, welche der Publisher anbietet. Die Subscriber haben somit unterschiedliche Schnittstellenanforderungen, welche der Publisher gerecht werden muss. Die Frage, die sich nun stellt, ist, wie einfach kann ein solches Szenario mit NServiceBus bzw. Neuron ESB aufgebaut werden? Realisierung mittels NServiceBus Da in diesem Szenario die einzelnen Subscriber unterschiedliche Eingangsformate aufweisen, müssen diese separat definiert werden. Somit ergibt sich für den Publisher und die jeweiligen Subscriber jeweils ein separates Packages, mit den Nachrichtenklassen. Der ESB wird als ein separates Package definiert, welches zur Weiterleitung der Nachrichten an die jeweiligen Subscriber zuständig ist. Dadurch egibt sich das in der nachfolgenden Abbildung 43 dargestellte Abhängigkeitsdiagramm der Packages. Abbildung 43: Szenario 1 - Aufbau der Packages in NServiceBus Dementsprechend sieht auch die Konfigurationsdatei vom ESB Package aus:... <MsmqTransportConfig InputQueue="ESB1InputQueueForKundenverwaltungssystem1" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5"/> <UnicastBusConfig> <MessageEndpointMappings> <add Messages="KundenrabattsystemMessages1" Endpoint="Kundenrabattsystem1InputQueue" /> <add Messages="ERPSystemMessages1" Endpoint="ERPSystem1InputQueue" /> </MessageEndpointMappings> </UnicastBusConfig>... Wie aus diesem Konfigurationsausschnitt zu lesen ist, definiert der ESB mehrere Queues. Die Eingangsqueue ESB1InputQueueForKundenverwaltungssystem1 dient als Eingangsadresse für den ESB. Diese wird ebenfalls im Kundenverwaltungssystem als Ausgangsadresse für die Updatemeldungen eingestellt. Die beiden Ausgangsqueues Kundenrabattsystem1InputQueue und Student: Marko Marković Seite 47 von 95

48 ERPSystem1InputQueue geben an, welche Meldung an welches Verarbeitungssystem weitergeleitet werden soll. Diese Queues werden vom jeweiligen Zielsystem als Eingangsqueue definiert. Aus diesem Aufbau ergibt sich das in der Abbildung 44 dargestellte Klassendiagram. Das Klassendiagram wurde zwecks besserer Leserlichkeit etwas vereinfacht. So wurden die Konfigurationsklasse EndpointConfig und das von einer Nachricht zu implementierten NServiceBus Interfaces IMessage nicht eingezeichnet Abbildung 44: NServiceBus Klassenstruktur in Szenario 1 Student: Marko Marković Seite 48 von 95

49 Ein Objekt der Klasse CustomerUpdateMessage aus dem Package KundenveraltungssystemMessages wird vom Kundenverwaltungssystem an den ESB bei Änderungen eines Kundeneintrages gesendet. Dieser Vorgang wurde mit einer (1) in der Klassendiagrammabbildung markiert. Der ESB empfängt die eintreffende Meldung und konvertiert diese in die jeweiligen Nachrichtenformate CustomerDiscountUpdateMessage und CustomerErpUpdateMessage um. Bei den hierbei verwendeten Adaptern handelt es sich somit um einfache Methoden im ESB Package. Nach der Konvertierung werden die Nachrichten nacheinander an die jeweiligen Zielsysteme weitergeleitet (2), (3) Realisierung mittels Neuron ESB Mittels Neuron ESB kann dieses Szenario grundsätzlich auf zwei verschiedenen Arten gelöst werden. Die eine Möglichkeit ist, dass der Publisher den vollen Nachrichtenumfang an die jeweiligen Subscriber sendet. Die Subscriber ihrerseits lesen aus den erhaltenen Informationen nur diejenigen herauslesen, die sie effektiv benötigen. Dies stellt die einfachste Variante dar, die ebenfalls in NServiceBus hätte verwendet werden können. In der zweiten Variante werden an Stelle von serialisierten Binärdaten XML Nachrichten verwendet. Diese Vorgehensweise ist wesentlich eleganter, da die Nachrichten gezielt auf ihre Empfänger zugeschnitten werden können. Für einen besseren Vergleich sollen beide Varianten genauer vorgestellt werden. Variante 1: Mittels serialisierten Binärobjekten Im Gegensatz zu NServiceBus müssen die Nachrichtenklassen nicht in separate Packages definiert werden. Diese können in den jeweiligen Programm Packages direkt enthalten sein. Die zentrale Schnittstelle zwischen dem Publisher und den jeweiligen Subscriber stellt der Neuron ESB Server dar. Daher fällt die zu verwendete Klassenstruktur der jeweiligen Systeme recht simpel aus. Diese ist in der Abbildung 45 auf der nächsten Seite abgebildet. Die Subscriber unterscheiden sich von der Klassenstruktur nur unwesentlich vom Publisher. Der auffälligste Unterschied stellt die OnReceive Methode dar. Diese wird aufgerufen, sobald eine neue Nachricht über den ESB eintrifft. Die einzelnen Teilsysteme müssen für den Neuron ESB Server mit einer Adresse versehen sein. Die Endpunktadressen in dieser Variante werden nach dem jeweiligen Package benannt. Als Beispiel sei hier die Konfiguration vom Publisher Package Kundenverwaltungssystem aufgeführt: <?xml version="1.0" encoding="utf-8"?> <configuration> <appsettings> <add key="esbclientid" value="kundenverwaltung" /> <add key="esbzone" value="enterprise" /> <add key="esbserviceaddress" value="net.tcp://localhost:50000" /> <add key="esbserviceidentity" value="" /> </appsettings> </configuration> Student: Marko Marković Seite 49 von 95

50 Kundenverwaltungssystem Program Attributes Operations + Main(args : string[]) : void CustomerUpdateMessage Attributes + Adresse : string + Anrede : Title + string + Kundennummer : long + Name : string + Ort : string + Tel : string + Vorname : string Operations «enumerat Title Literals Frau Herr Keine Kundenrabattsystem ERPSystem Program Program Attributes Operations + Main(args : string[]) : void + OnReceive(sender : object, e : MessageEventArgs) Attributes Operations + Main(args : string[]) : void + OnReceive(sender : object, e : MessageEventArgs) CustomerUpdateMessage «enumerat Title CustomerUpdateMessage «enumerat Title Attributes + Adresse : string + Anrede : Title + string + Kundennummer : long + Name : string + Ort : string + Tel : string + Vorname : string Operations Literals Frau Herr Keine Attributes + Adresse : string + Anrede : Title + string + Kundennummer : long + Name : string + Ort : string + Tel : string + Vorname : string Operations Literals Frau Herr Keine Abbildung 45: Neuron ESB Klassendiagram zu Szenario 1 - Variante 1 Nun da die Klassen vorhanden und die Schnittstellen konfiguriert sind, muss lediglich noch der Kommunikationskanal im Neuron ESB Explorer eingerichtet werden. Hierfür wird im Neuron ESB Explorer ein neues Topic HsluSzenario1 angelegt. Die jeweiligen Programmkomponenten werden als Publisher bzw. als Subscriber im Neuron ESB Explorer deklariert und dem Topic HsluSzenario1 zugewiesen. Das daraus resultierende ESB Diagramm im Neuron ESB Explorer ist in der Abbildung 46 dargestellt. Abbildung 46: ESB Diagramm im Neuron ESB Explorer zum Szenario 1 - Variante 1 Der Kommunikationskanal ist somit nun einsatzbereit. Es sei an dieser Stelle angemerkt, dass im Neuron ESB Explorer statt zwei separaten Subscriber theoretisch auch einer gereicht hätte. Beide Subscriber verwenden das gleiche Nachrichtenformat und in keinem ist eine separate Nachrichten- Student: Marko Marković Seite 50 von 95

51 behandlung mittels Pipelines angefügt worden. Jedoch dient es der besseren Systemübersicht, wenn jeder Subscriber separat aufgeführt wird. Weiter sind dadurch auch flexible Anpassungen der einzelnen Subscriber direkt über den Neuron ESB Explorer möglich. Variante 2: Mittels XML Nachrichten Bei dieser Variante sendet der Publisher zwar wie gewohnt alle Informationen an den ESB, dieser leitet hingegen nur die für den jeweiligen Subscriber relevanten Daten weiter. Die Subscriber haben in dieser Variante unterschiedliche Datenformate. Dies kann auch aus dem Klassendiagram aus der Abbildung 47 herausgelesen werden. Kundenverwaltungssystem Program Attributes Operations + Main(args : string[]) : void CustomerUpdateMessage Attributes + Adresse : string + Anrede : Title + string + Kundennummer : long + Name : string + Ort : string + Tel : string + Vorname : string Operations «enumerat Title Literals Frau Herr Keine Kundenrabattsystem ERPSystem Program Program Attributes Operations + Main(args : string[]) : void + OnReceive(sender : object, e : MessageEventArgs) Attributes Operations + Main(args : string[]) : void + OnReceive(sender : object, e : MessageEventA CustomerDiscountUpdat Attributes + Geschlecht : Sex + Kundennummer : long + Name : string + Vorname : string Operations «enumerat Sex Literals Männlich Unbekannt Weiblich Attributes CustomerErpUpdateMessage + Adresse : string + Anrede : Title + string + ID : long + Nachname : string + Ort : string + Telefon : string + Vorname : string Operations Abbildung 47: Neuron ESB Klassendiagram zu Szenario 1 - Variante 2 Anstelle von serialisierten Binärdaten werden nun XML Nachrichten gesendet. Das in diesem Beispiel vom Publisher verwendete Nachrichtenformat wurde mit dem folgenden Schema beschrieben: <xs:element name="customerupdatemessage"> <xs:complextype> <xs:sequence> <xs:element name="kundennummer" type="xs:long" /> <xs:element name="anrede" type="mstns:title" default="keine" /> <xs:element name="name" type="xs:string" /> <xs:element name="vorname" type="xs:string" /> <xs:element name="adresse" type="xs:string" /> <xs:element name="ort" type="xs:string" /> Student: Marko Marković Seite 51 von 95

52 <xs:element name="tel" type="xs:string" /> <xs:element name=" " type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> <xs:simpletype name="title"> <xs:restriction base="xs:string"> <xs:enumeration value="keine" /> <xs:enumeration value="herr" /> <xs:enumeration value="frau" /> </xs:restriction> </xs:simpletype> </xs:schema> Um eine Nachricht gemäss diesem Schema einfach herzuleiten, wird die Nachrichtenklasse CustomerUpdateMessage mit entsprechenden XML Annotation ergänzt: [Serializable] [XmlRoot("CustomerUpdateMessage")] public class CustomerUpdateMessage { [XmlElement("Kundennummer")] public long Kundennummer { get; set; [XmlElement("Anrede")] public Title Anrede { get; set; [XmlElement("Name")] public string Name { get; set; [XmlElement("Vorname")] public string Vorname { get; set; [XmlElement("Adresse")] public string Adresse { get; set; [XmlElement("Ort")] public string Ort { get; set; [XmlElement("Tel")] public string Tel { get; set; [XmlElement(" ")] public string { get; set; Dasselbe wird auch mit dem Enumerator Title vorgenommen: [Serializable] [XmlRoot("Title")] public enum Title { [XmlEnum("Keine")] [XmlEnum("Herr")] [XmlEnum("Frau")] Keine, Herr, Frau Nun können Objekte der Klasse CustomerUpdateMessage einfach in XML Nachrichten konvertiert werden. Diese werden vom Kundenverwaltungssystem an den Neuron ESB gesendet. Damit die Nachrichten im richtigen Format an das jeweilige Zielsystem ankommen, müssen diese mittels XSL Transformationen um konvertiert werden. Die Transformationsvorschriften können im Neuron ESB Explorer im Register Data hinterlegt werden. Als Beispiel sei hier die XSL Transformation für die Konvertierung von CustomerUpdateMessage XML Nachrichten in das für das Rabattsystem benötigte Nachrichtenformat CustomerDiscountUpdateMessage aufgeführt: <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/xsl/transform"> <xsl:template match="/"> <CustomerDiscountUpdateMessage> <xsl:for-each select="customerupdatemessage"> <Kundennummer> Student: Marko Marković Seite 52 von 95

53 <xsl:value-of select="./kundennummer" /> </Kundennummer> <Name> <xsl:value-of select="./name" /> </Name> <Vorname> <xsl:value-of select="./vorname" /> </Vorname> <Geschlecht> <xsl:choose> <xsl:when test="./anrede = 'Herr'"> Männlich </xsl:when> <xsl:when test="./anrede = 'Frau'"> Weiblich </xsl:when> <xsl:otherwise> Unbekannt </xsl:otherwise> </xsl:choose> </Geschlecht> </xsl:for-each> </CustomerDiscountUpdateMessage> </xsl:template> </xsl:stylesheet> Über diese Transformationsbeschreibung kann ein für das Rabattsystem verständliche XML Nachricht erzeugt werden. Ein Beispiel gibt die nachfolgende Abbildung 48. XML Nachricht vom Kundenverwaltungssystem <CustomerUpdateMessage> <Kundennummer> </Kundennummer> <Anrede> Herr </Anrede> <Name> Markovic </Name> <Vorname> Marko </Vorname> <Adresse> Thorenbergstrasse 21 </Adresse> <Ort> Luzern </Ort> <Tel> </Tel> < > </ > </CustomerUpdateMessage> - XSLT XML Nachricht für das Rabattsystem <CustomerDiscountUpdateMessage> <Kundennummer> </Kundennummer> <Name> Markovic </Name> <Vorname> Marko </Vorname> <Geschlecht> Männlich </Geschlecht> </CustomerDiscountUpdateMessage> Abbildung 48: Konvertierungsbeispiel zu einer XML Rabattsystemnachricht Student: Marko Marković Seite 53 von 95

54 Die XSL Transformation muss, damit sie einem Subscriber zugewiesen werden kann, innerhalb einer Pipeline definiert werden. Hierfür muss eine entsprechende Pipeline angelegt werden (vgl. Abbildung 49). In dieser Pipeline wird die vorhin beschrieben XSL Transformation importiert. Abbildung 49: Erstellung einer Pipeline zur XSL Transformation einer XML Nachricht Die somit einsatzbereite Pipeline wird dem Subscriber für das Kundenrabattsystem wie in Abbildung 50 angedeutet zugewiesen. Abbildung 50: Zuweisung einer Pipeline einem Subscriber Dieser Vorgang wird in ähnlicher Weise für das ERP System wiederholt. Das resultierende ESB Dia- Student: Marko Marković Seite 54 von 95

55 gramm des Neuron ESB Explorers (vgl. Abbildung 51) unterscheidet sich nur unwesentlich von demjenigen aus der ersten Variante. Dies überrascht auch nicht, ist doch die Anzahl der Publisher und Subscriber gleich geblieben. Abbildung 51: ESB Diagram im Neuron ESB Explorer zum Szenario 1 - Variante 2 Der grosse Vorteil dieser Variante besteht darin, dass die Nachrichten direkt vom ESB bearbeitet und weitergeleitet werden können. Dies ermöglicht ohne grossen Aufwand einen flexiblen Ausbau der bestehenden Kommunikationsinfrastruktur direkt im Neuron ESB Explorer, ohne die bestehenden Subsysteme zu verändern. 5.2 Szenario 2: Hinzufügen weiterer Subscriber Das zweite Szenario stellt nach dem ersten nicht wirklich eine grosse Herausforderung dar. Vielmehr interessiert hier der Aufwand, den man betreiben muss, um weitere Subscriber bei einem vorhandenen Publisher zu registrieren. Als Grundlage dient das bereits im Szenario 1 verwendete Modell. Dieses wird um einen Subscriber Web Shop erweitert (vgl. Abbildung 52). Dieser benötigt nur bestimmte Kundeninformationen. Abbildung 52: Szenario 2 - Aufbau Student: Marko Marković Seite 55 von 95

56 5.2.1 Realisierung mittels NServiceBus Wie bereits die zwei vorhandenen Subscriber stellt auch der neue individuelle Anforderungen an die zu übergebenden Parameter. Da NServiceBus Nachrichten auf der Grundlage der verwendeten Packages weiterleitet, wird für den Web Shop Subscriber ein Package WebShopMessages erstellt. Innerhalb dieses Packages wird eine Klasse CustomerWebShopUpdateMessage definiert, welche vom ESB Package verwendet wird, um Meldungen vom Kundenverwaltungssystem an den Web Shop zu senden. Die daraus entstehenden Abhängigkeiten sind auf der Abbildung 53 eingezeichnet. Abbildung 53: Szenario 2 - Aufbau der Packages in NServiceBus Damit der ESB die Nachrichten auch effektiv an den Web Shop weiterleiten kann, muss dessen Konfigurationsdatei dementsprechend noch um den Web Shop Eintrag erweitert werden:... <UnicastBusConfig> <MessageEndpointMappings> <add Messages="KundenrabattsystemMessages" Endpoint="Kundenrabattsystem2InputQueue" /> <add Messages="ERPSystemMessages" Endpoint="ERPSystem2InputQueue" /> <add Messages="WebShopMessages" Endpoint="WebShop2InputQueue" /> </MessageEndpointMappings> </UnicastBusConfig>... Wie sich schnell herausstellt, müssen einige Anpassungen an der ESB Komponente vorgenommen werden, damit ein neuer Subscriber, wenn er ein anderes Nachrichtenformat aufweist, dem System hinzugefügt werden kann. Neben Konfigurationseinstellungen muss auch ein gewisser Programmieraufwand betrieben werden, um das bestehende System zu erweitern. Änderungen am ESB Dienst führen automatisch zu einer Neukompilierung des Systems. Daraus kann man schliessen, dass Anpassungen an der bestehenden Umgebung nicht zur Laufzeit vorgenommen werden können Realisierung mittels Neuron ESB Anders sieht es dahingegen bei Neuron ESB aus. Hier können Änderungen zur Laufzeit an der bestehenden Infrastruktur vorgenommen werden, ohne die vorhandenen Komponenten zu beeinflussen. Variante 1: Mittels serialisierten Binärobjekten Geht man wieder von der ersten Variante, in welcher alle Parameter mitgegeben werden, aus, kann Student: Marko Marković Seite 56 von 95

57 ohne weiteres ein weiterer Subscriber WebShop über den Neuron ESB Explorer dem ESB hinzugefügt werden. Diese Anpassung wird über eine simple Konfiguration vorgenommen und bedarf keines Programmieraufwandes. Nachdem der neue Subscriber im Neuron ESB Explorer dem bestehenden Kanal bzw. Topic zugewiesen wurde, ergibt sich das auf der Abbildung 54 dargestellte ESB Diagramm. Abbildung 54: ESB Diagramm im Neuron ESB Explorer zum Szenario 2 - Variante 1 Sobald die vorgenommenen Einstellungen gespeichert werden, steht die Kommunikation mit dem neuen Subscriber schon. Variante 2: Mittels XML Nachrichten Möchte man nur einen bestimmten Teil der Updatemeldung als XML Nachricht an den neuen Subscriber senden, so muss die Nachricht wie bereits zuvor vorgängig noch Aufbereitet werden. Dies wird, wie auch schon bereits im Szenario 1 gezeigt, wieder über XSL Transformationen in einer Pipeline bewerkstelligt. Die Pipeline wird wieder dem neuen Subscriber zugewiesen. Das dabei verwendete XSLT Skript könnte wie folgt aussehen: <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/xsl/transform"> <xsl:template match="/"> <CustomerWebShopUpdateMessage> <xsl:for-each select="customerupdatemessage"> <Kundennummer> <xsl:value-of select="./kundennummer" /> </Kundennummer> <Anrede> <xsl:value-of select="./anrede" /> </Anrede> <Nachname> <xsl:value-of select="./name" /> </Nachname> <Vorname> <xsl:value-of select="./vorname" /> </Vorname> < > <xsl:value-of select="./ " /> </ > </xsl:for-each> </CustomerWebShopUpdateMessage> </xsl:template> </xsl:stylesheet> Student: Marko Marković Seite 57 von 95

58 Auch hier handelt es sich wiederum um reine Konfigurationseinstellungen beim ESB. Das resultierende ESB Diagramm, nachdem auch hier der Web Shop Subscriber dem entsprechenden Topic zugewiesen wurde, unterscheidet sich kaum vom demjenigen aus Abbildung 54. Der hier beschriebene Fall wurde bewusst sehr simpel gewählt. Der Sachverhalt wäre ein anderer würde man Subscriber mit anderen Dienstschnittstellen wie Web Services, MSMQ, SAP oder REST verwenden. In solchen Fällen müsste man der Pipeline noch eine Endpunkt-Dienstkonvertierung einbauen. Diese werden über Adapter realisiert. Unter Umstände kann es vorkommen, dass man einen eigenen Adapter entwickeln muss, wenn man beispielsweise ein firmeneigenes Legacy System an den ESB anbinden möchte. Leider gibt diesbezüglich die bestehende Dokumentation von Neuron ESB nur wenig Aufschluss über das exakte Vorgehen. Auch sind die genauen Konfigurationseinstellungen nicht aufgeführt, wodurch bewusst auf ein entsprechendes Einbindungsbeispiel in dieser Arbeit verzichtet wurde. 5.3 Szenario 3: Änderung von Parametern In diesem Szenario soll der Aufwand abgeschätzt werden, welchen man betreiben muss, um bestehende Schnittstellen um einige Parametern zu erweitern bzw. anzupassen. Auch hier soll dasselbe Modell wie aus dem ersten Szenario verwendet werden. Das System soll einige wenige Anpassungen erfahren. Neu benötigt das Kundenrabattsystem einen zusätzlichen Parameter Land. Das ERP System verwendet nun statt der Bezeichnung Kundennummer neu den Begriff ID. Abbildung 55: Szenario 3 - Aufbau Wie bereits zuvor, soll auch hier untersucht werden, wie viele Änderungen in den beiden Produkten vorgenommen werden müssen, um die neuen Anforderungen zu erfüllen Realisierung mittels NServiceBus Der Aufwand, welcher in NServiceBus für die Implementierung der Anpassungen betrieben werden muss, ist relativ hoch. Das Umbenennen des Parameters Kundennummer in ID für das ERP System führt dazu, dass das ERP System sowie der ESB Programmänderungen erfahren müssen. Diese Student: Marko Marković Seite 58 von 95

59 werden wiederum erst übernommen, nachdem diese Systemkomponenten neu kompiliert wurden. Das Problem mit dem neuen Parameter Land, geht noch weiter. Hier muss der Publisher selber ebenfalls noch angepasst werden, damit diese Information in die Update Meldung an den ESB mit einbezogen wird. Den neuen Parameter kann man auf zwei verschiedenen Arten hinzufügen. Die erste Variante ist naheliegend. Man fügt den neuen Parameter einfach der Message Klasse CustomerDiscountUpdateMessage hinzu und passt die durch diese Änderung betroffenen Komponenten entsprechend an. Die zweite Variante ist zwar etwas umständlich, bietet jedoch einen entscheidenden Vorteil. Für den Fall, dass man mehrere Subscriber, die das gleiche Message Package verwenden, hat, betreffe eine Änderung in der Kommunikationsklasse CustomerDiscountUpdateMessage konsequent alle Subscriber. Nun kann es durchaus sein, dass das neue Attribut Land in der Schnittstelle nicht von allen Subscriber benötigt wird. NServiceBus bietet für diese Situation eine elegante Möglichkeit. Anstatt die Message Klasse CustomerDiscountUpdateMessage zu ändern, wird eine neue Klasse Customer- DiscountUpdateMessage2 abgeleitet. Diese übernimmt alle neuen Attribute. Alle Subscriber, welche die neuen Attribute benötigen, implementieren nun neu CustomerDiscountUpdateMessage2 anstelle von CustomerDiscountUpdateMessage. So kann der Anpassungsaufwand etwas eingedämmt werden. KundenrabattsystemMessages NServiceBus Literals «enumeration» Sex Männlich Unbekannt Weiblich CustomerDiscountUpdateMessage Attributes + Geschlecht : Sex + Kundennummer : long + Name : string + Vorname : string Operations «interface» IMessage Attributes Operations CustomerDiscountUpdateMessage2 Attributes + Land : string Operations Subscriber_1 Subscriber_2 Receiver1 Receiver2 Attributes Operations + Handle(msg : CustomerDiscountMessage) Attributes Operations + Handle(msg : CustomerDiscountMessage2) Erfährt keine Änderungen Abbildung 56: Versionierung in NServiceBus über Vererbung Verweist auf neue Version zur Erfüllung der neuen Anforderungen Trotz der Möglichkeit der Versionierung der Nachrichtenklasse, bleibt der Änderungsaufwand weiterhin gross. Nichts desto trotz handelt es sich hierbei um ein wichtiges Konzept. Dank dem, dass verschiedene Versionen von Nachrichtenklassen erstellt werden können, können vorhandene Systemkomponente weiterhin betrieben werden, ohne Änderungen an diesen vornehmen zu müssen. Man muss jedoch aufpassen, dass man bei zu vielen Versionen von Nachrichtenklassen nicht den Student: Marko Marković Seite 59 von 95

60 Überblick verliert. Dies wäre wiederum kontraproduktiv Realisierung mittels Neuron ESB Variante 1: Mittels serialisierten Binärobjekten Spätestens jetzt rächt sich das vermeintlich einfache Konzept der vollständigen Nachrichtenübergabe. Da mit einfachen Binärobjekten gearbeitet wurde, müssen diese beim Publisher vollständig serialisiert und bei den Subscriber jeweils wieder deserialisiert werden. Nun da sich einerseits die Bezeichnung eines Parameter in ID geändert hat und andererseits ein neuer Parameter Land hinzugekommen ist, müssen diese Änderungen beim Publisher sowie bei allen Subscriber vorgenommen werden. Dies schliesst Subscriber, welche von den neuen Anforderungen nicht betroffen sind, mit ein. Anhand dieses Beispiels kann man erkennen, dass das Konzept der ersten Variante für die Erstellung eines flexiblen Systems nicht geeignet ist. Abbildung 57: Neuron ESB Klassendiagram zu Szenario 3 - Variante 1 Diese Vorgehensweise bringt nur einen kleinen Vorteil: die Einstellungen im Neuron ESB Explorer müssen nicht geändert werden. Student: Marko Marković Seite 60 von 95

61 Variante 2: Mittels XML Nachrichten Die zweite Variante über die XML Nachrichten reagiert wesentlich flexibler auf solche Änderungen. Im Falle vom ERP System muss lediglich die XSL Transformation so angepasst werden, dass statt Kundennummer neu das XML Tag ID verwendet wird: <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/xsl/transform"> <xsl:template match="/"> <CustomerErpUpdateMessage> <xsl:for-each select="customerupdatemessage"> <ID> <xsl:value-of select="./kundennummer" /> </ID> <Anrede> <xsl:value-of select="./anrede" /> </Anrede> <Nachname> <xsl:value-of select="./name" /> </Nachname> <Vorname> <xsl:value-of select="./vorname" /> </Vorname> <Adresse> <xsl:value-of select="./adresse" /> </Adresse> <Ort> <xsl:value-of select="./ort" /> </Ort> <Telefon> <xsl:value-of select="./tel" /> </Telefon> < > <xsl:value-of select="./ " /> </ > </xsl:for-each> </CustomerErpUpdateMessage> </xsl:template> </xsl:stylesheet> Ähnlich funktioniert dies auch beim Rabatt System. Zwar müssen auch hier die Subscriber die neue Nachrichtenstruktur übernehmen und der Publisher die neuen Landesinformationen liefern, aber diese Anpassungen können im Gegensatz zu NServiceBus nacheinander schrittweise erfolgen. Bestehende Subscriber, welche von diesen neuen Anforderungen nicht betroffen sind, erfahren hingegen keinerlei Änderungen. 5.4 Szenario 4: Adressänderung Subscriber Etwas, was sich bei Systemmigrationen neben den auszutauschenden Informationen ebenfalls ändern kann, sind die Server der Dienstsysteme selbst bzw. ihre Zieladressen. In diesem Szenario soll deshalb der Aufwand abgeschätzt werden, welcher betrieben werden muss, wenn ein Subscriber seine Zieladresse ändert. Student: Marko Marković Seite 61 von 95

62 Kundenverwaltung Kundenkontoverwaltungssystem (Accounting) ESB Kundenrabattsystem ERP System Kundenrabatt Umbenennung ERPSystem NeuesKundenrabattSystem Abbildung 58: Szenario 4 - Aufbau Anpassung in NServiceBus In NServiceBus muss bei der Adressänderung eines Subscriber einerseits die Konfigurationsdatei des Subscriber selbst und andererseits die Konfigurationsdatei des ESB angepasst werden. Neukompilierungen der einzelnen Komponenten sind nicht notwendig, da keine Programmänderungen vorgenommen wurden. Die notwendigen Anpassungen können aus den nachfolgenden Konfigurationsausschnitten herausgelesen werden App.config ESB... <UnicastBusConfig> <MessageEndpointMappings> <add Messages="KundenrabattsystemMessages" Endpoint="NeuesKundenrabattsystem4InputQueue" /> <add Messages="ERPSystemMessages" Endpoint="ERPSystem4InputQueue" /> </MessageEndpointMappings> </UnicastBusConfig>... App.Config Neues Kundenrabatt System... <MsmqTransportConfig InputQueue="NeuesKundenrabattsystem4InputQueue" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5" />... Somit stellt sich der aufzubringende Aufwand für diese Änderung als geringfügig heraus Anpassung in Neuron ESB In Neuron ESB fällt der Aufwand ähnlich aus. Über den Neuron ESB Explorer muss die neue Schnittstellenbezeichnung auf dem ESB Server konfiguriert werden. Zusätzlich muss die neue Bezeichnung ebenfalls in der Konfigurationsdatei des Rabatt Systems übernommen werden: <?xml version="1.0" encoding="utf-8"?> <configuration> <appsettings> Student: Marko Marković Seite 62 von 95

63 <add key="esbclientid" value="neueskundenrabattsystem"/> <add key="esbzone" value="enterprise"/> <add key="esbserviceaddress" value="net.tcp://localhost:50000"/> <add key="esbserviceidentity" value=""/> </appsettings> </configuration> Der Subscriber ist somit unter dem neuen Namen einsatzbereit. 5.5 Szenario 5: Adressänderung Publisher Nun soll der Aufwand abgeschätzt werden, wenn nicht ein Subscriber, sondern der Publisher selbst eine neue Bezeichnung erhält. Abbildung 59: Szenario 5 - Aufbau Anpassung in NServiceBus Interessanterweise, müsste diese Adressänderung in NServiceBus beim Publisher gar nicht zwangsweise vorgenommen werden. Der Publisher ist in diesem Beispiel ein reiner Sender. Es ist nicht vorgesehen, dass dieser Daten empfängt. Entsprechend sind auch keine anderen Sender vorhanden, die auf die neue Adresse Daten schicken sollen. Nichts desto trotz kann diese Umbenennung in der Konfigurationsdatei des Publisher ohne weiteres vorgenommen werden Anpassung in Neuron ESB Dahingegen sieht es bei Neuron ESB etwas anders aus. Hier müssen alle Adressänderungen zwangsweise mitgeführt werden. Genau wie beim Subscriber aus Szenario 4 muss die Konfigurationsdatei des Publisher angepasst und die Anpassung über den Neuron ESB Explorer auf dem Server vorgenommen werden. 5.6 Szenario 6: Adressänderung ESB Zuletzt soll ermittelt werden, zu welchen Problemen eine Adressänderung des ESB führen kann. Student: Marko Marković Seite 63 von 95

64 Abbildung 60: Szenario 6 - Aufbau Anpassung in NServiceBus In NServiceBus müssen lediglich die Publisher neben dem ESB selbst die Adressänderung übernehmen. Die Subscriber erfahren keinerlei Anpassungen. Bei einem System mit nur einem Publisher, einem ESB und vielen Subscriber ist der Umbenennungsaufwand somit minimal Anpassung in Neuron ESB Die Umbenennung des ESB Servers in Neuron ESB hat grossen Einfluss auf die bestehende Infrastruktur. Die Konfigurationsdateien aller Komponenten müssen ausnahmslos angepasst werden. Subscriber, welche keinerlei Daten an den ESB senden, müssen ebenso wie die Publisher neu konfiguriert werden. Je nach Grösse der bestehenden Infrastruktur will dieser Schritt deshalb gut überlegt sein. Eine entsprechende Konfigurationsdatei könnte für das Kundenrabatt System wie folgt aussehen: <?xml version="1.0" encoding="utf-8"?> <configuration> <appsettings> <add key="esbclientid" value="kundenrabattsystem"/> <add key="esbzone" value="enterprise"/> <add key="esbserviceaddress" value="net.tcp://newesb2server:50000"/> <add key="esbserviceidentity" value=""/> </appsettings> </configuration> 5.7 Szenario 7: Einbindung einer Java Anwendung In diesem Szenario geht es um die Integration bestehender Anwendungen und Dienste, welche nicht auf dem.net Framework basieren. Dies können diverse Applikationen und Services sein, welche mittels SAP, PHP oder C++ entwickelt wurden. Für dieses Szenario wird als Fremdsystem Java verwendet, da es zu einer der bekannteren Sprachen gehört. Es bestehen diverse Möglichkeiten, wie man eine Kommunikation zwischen einer Java und einer.net Anwendung herstellen kann. Eine Möglichkeit wäre zum Beispiel die Dateiübertragung über REST Dienste, oder eine andere über das Abhören von FTP Dateitransfers. Die eleganteste Variante wäre die Verwendung von Java Adaptern auf Basis von JMS, welche vom verwendeten Integrationssystem einfach eingebunden werden können. Leider bieten weder NServiceBus noch Neuron ESB solche Funktionen an. Eine andere Möglichkeit Student: Marko Marković Seite 64 von 95

65 wäre der Einsatz von Hybridplattformen wie JuggerNET for Java 3 oder J-Integra for.net 4, welche die Ansteuerung von.net Bibliotheken über eine Java Applikation ermöglichen. Jedoch sind diese Drittanbieteranwendungen kostenpflichtig und werden in dieser Arbeit nicht behandelt. Die meistverbreitete Vorgehensweise ist jedoch der Informationsaustausch über Web Services. Dies nicht zuletzt auch deshalb, weil Web Services plattformunabhängig sind und daher auch von anderen Technologien angesteuert werden können. Ohne einen ESB würde die.net Anwendung direkt auf den Web Service der Java Applikation zugreifen und umgekehrt. Nun soll untersucht werden, ob es möglich ist, einfach einen ESB zwischen den beiden Parteien zwischenzuschalten Realisierung mittels NServiceBus Bereitstellung eines.net Dienstes für eine Java Anwendung NServiceBus bietet eine einfache, jedoch etwas beschränkte Möglichkeit an, Dienste als Web Service direkt zur Verfügung zu stellen. NServiceBus unterstützt die Parameterübergabe einer beliebigen Nachrichtenklasse, welche das IMessage Interface von NServiceBus implementiert, an einen Web Service. Allerdings kann dieser nur einen vordefinierten Enumeratorwert als Antwortcode zurückgeben. Das heisst, dass bei Webdiensten, welche in NServiceBus direkt eingebunden werden, nur Prozesse mit einfachen Rückgabewerten wie OK, ACK, NAK, Error usw. eingebunden werden können. Dienste, welche einen variablen Rückgabewert haben (wie z.b. Zeit- oder Rechendienste), müssen über zusätzliche Adapter umständlich gekapselt werden, damit diese in NServiceBus eingebaut werden können. In diesem Beispiel soll auf der.net Seite ein einfacher Dienst mit vordefinierten Rückgabeparametern erstellt werden. Dieser Dienst testet, ob es sich bei einer übergebenen Zahl um eine Primzahl handelt oder nicht. Demzufolge kommen für diesen Service nur die folgenden zwei möglichen Rückgabewerte Zahl ist Primzahl und Zahl ist keine Primzahl in Frage. Da Programme auch Fehler enthalten können, wird ein zusätzlicher Rückgabewert Fehler definiert. Da diese Informationen über den NServiceBus gesendet werden sollen, werden diese wieder in einem separaten Nachrichtenpacke PrimMessages deklariert (vgl. Abbildung 61). Dieses Package wird wiederum wie bereits in den Szenarien 1 bis 3 vom ESB und dem Web Dienst Package als Grundlage der Nachrichtenübertragung verwendet. Abbildung 61: Messagemodel vom Prinzahlentestdienst in NServiceBus 3 Integration von.net Code in Java über JuggerNet. (Server Lizenzkosten: $1395. Entwicklerlizenz: $995.) Quelle: [Stand: Mai 2010] 4 J-Integra ist eine Java Bibliothek, welche.net Netzwerkklassen direkt implementiert und somit die Grundlage für einen möglichen.net ESB Adapter für die Integration von Java Anwendungen bildet. (Server Lizenzkosten: $999. Entwicklerlizenz: $399). Quelle: [Stand: Mai 2010] Student: Marko Marković Seite 65 von 95

66 Sobald die für die Anfrage benötigte Nachrichtenklasse PrimAnfrage sowie die Deklaration der Rückgabewerte mittels PrimAnfrageCodes festgelegt wurden, kann die Dienstschnittstelle implementiert werden. Diese Aufgabe stellt sich als sehr simpel heraus. Man leitet die eigene Dienstschnittstellenklasse PrimDotNetService einfach von der Webservice Klasse aus der NServiceBus Bibliothek ab und setzt für diese einen Namespace sowie das zu verwendende WS Protokoll: [WebService(Namespace = "http://ch.hslu.org/mse/vm2/primtest")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] [ToolboxItem(false)] public class PrimDotNetService : NServiceBus.Webservice<PrimAnfrage, PrimAnfrageCodes> { Damit steht die Serviceschnittstelle bereit. Startet man diesen Code als Web Anwendung so erhält man die auf Abbildung 62 dargestellte Seitenausgabe. Diese gibt an, dass der Web Service nur eine einzige Methode Process anbietet. Diese wurde von der zuvor abgeleiteten NServiceBus Klasse Webservice übernommen. Weiter ist auf der Seitenausgabe des Webdienstes ein Link zur WSDL Dienstbeschreibung aufgeführt. Dieser wird benötigt um den Web Service in die Java Anwendung zu importieren. Abbildung 62: Front-End des NServiceBus Webdienstes im Web nach Start Kommunikationskomponenten für Web Service Aufruf über Java. Abbildung 63: Import der WSDL Dienstbeschreibung in Eclipse Die Java Anwendung wird mit Hilfe der Entwicklungsumgebung Eclipse erstellt. Für die Einbindung Student: Marko Marković Seite 66 von 95

67 des Web Services wird das Axis2 Tools Plugin benötigt 5. Über dieses Plugin kann anhand der zuvor kopierten WSDL Dienstbeschreibung, die benötigte Klassenstruktur in Eclipse zur Interaktion mit dem Web Service generiert werden. Anhand der generierten Klassen kann der.net Dienst über den folgenden Java Code direkt aufgerufen werden: PrimDotNetService primdotnetservicelocator = new PrimDotNetServiceLocator(); PrimDotNetServiceSoap primdotnetservice = primdotnetservicelocator.getprimdotnetservicesoap(); long primzahl = ; long keineprimzahl = 45687; System.out.println(String.format("Primzahltest für %d: %s", primzahl, primdotnetservice.process(new PrimAnfrage(primzahl)))); System.out.println(String.format("Primzahltest für %d: %s", keineprimzahl, primdotnetservice.process(new PrimAnfrage(keinePrimzahl)))); Da auf.net Seite lediglich die Schnittstelle, jedoch noch kein Dienst vorhanden sind, wird dieser Aufruf eine Fehlermeldung erzeugt. Deshalb wird als nächster Schritt der Primzahlentestdienst implementiert. Da nun eine Webseite anstelle einer Windows Anwendung verwendet wird, unterscheidet sich das Vorgehen leicht zum gewohnten Verfahren. Die Buskonfigurationseinstellungen werden statt in der App.config nun in der Web.config vorgenommen. Die Bus Initialisierung wird in der Global.asax Datei der Web Anwendung vorgenommen: public class Global : System.Web.HttpApplication { public static IBus Bus { get; private set; protected void Application_Start(object sender, EventArgs e) { Bus = Configure.WithWeb().SpringBuilder().XmlSerializer().MsmqTransport().UnicastBus().LoadMessageHandlers().CreateBus().Start(); Nun da die Web Komponente für die Weiterleitung der eintreffenden Nachrichten bereit ist, kann die effektive Business Logik in das System eingebaut werden. Diese wird im ESB Package unter Verwendung des folgenden Codes vorgenommen: public class PrimAnfrageHandler : IHandleMessages<PrimAnfrage> { 5 Eine genaue Schritt für Schritt Installationsanleitung der benötigten Eclipse Plug-Ins kann unter dem folgenden Link gefunden werden: Student: Marko Marković Seite 67 von 95

68 public IBus Bus { get; set; public void Handle(PrimAnfrage anfrage) { try { if (istzahlprim(anfrage.zuprüfendezahl)) Bus.Return((int)PrimAnfrageCodes.ZahlIstPrim); else Bus.Return((int)PrimAnfrageCodes.ZahlIstNichtPrim); catch (Exception exc) { Console.WriteLine(exc.ToString()); Bus.Return((int)PrimAnfrageCodes.Fehler); // Prüfen auf eine Primzahl. Quelle: // c-primzahl-berechnen-optimiert-sid1075.aspx private bool istzahlprim(long zahl) { if (zahl < 2) return false; if (zahl % 2 == 0) return false; long upperborder = (long)math.round(math.sqrt(zahl), 0); for (long i = 3; i <= upperborder; i = i + 2) if (zahl % i == 0) return false; return true; Nun ist der Dienst einsatzbereit und kann, nachdem die Konfigurationseinstellungen für das ESB Package vorgenommen wurden, gestartet werden. Sobald der Dienst läuft, kann der vorhin vorgestellte Java Clientcode ausgeführt werden. Folgendes Ergebnis sollte dabei in der Konsolenausgabe erscheinen: Primzahltest für : ZahlIstPrim Primzahltest für 45687: ZahlIstNichtPrim Zur besseren Übersicht wurde der gesamte Vorgang nochmals in einem Sequenzdiagramm festgehalten (vgl. Abbildung 64). Ein weiterer Vorteil von Web Services besteht wie bereits erwähnt darin, dass diese nicht nur von Java und.net Anwendungen, sondern auch von vielen anderen Programmiersprachen und Plattformen verwendet werden können. Diese Tatsache macht den Client einerseits austauschbar, andererseits können diverse andere Dienstnutzer auf den ESB Dienst zugreifen, ohne sich vorgängig beim ESB registrieren zu müssen. Ob man diesen Sachverhalt wünscht, ist situationsbedingt. Da es sich in diesem Beispiel um einen allgemeinen Rechendienst handelt, spielt es keine Rolle, wer die Clients sind. Verwendet man hingegen einen sicherheitsrelevanten oder betriebskritischen Dienst, so muss eine angepasste Vorgehensweise gewählt werden. In diesem Fall muss der anzubietende Dienst mit zusätzlichen Schutzmechanismen versehen werden. Hierfür können verschiedene Vorkehrungen in Frage kommen. Ein erster und effizienter Schritt zur Sicherung der eigenen Webdienste besteht darin, dass man die Darstellung der Dienstbeschreibung auf dem Server deaktiviert. So können keine WSDL Informationen mehr vom Web Service bezogen werden, welche für dessen Nutzung benötigt werden. Weiter kann der Dienst mit WS-Policy Dateien zusätzlich geschützt werden. So kann zum Beispiel konfiguriert werden, dass die Datenkommunikation nur verschlüsselt erfolgen darf usw. Student: Marko Marković Seite 68 von 95

69 Abbildung 64: Sequenzdiagramm der Nachrichtenverarbeitung zwischen dem Java Client und dem Primzahlentestdienst Bereitstellung eines Java Dienstes für eine.net Anwendung Möchte man Java Dienste in NServiceBus einbinden, muss eine entsprechende Zwischenkomponente eingebaut werden. Bei dem in diesem Beispiel verwendeten Java Dienst handelt es sich um einen Temperaturkonverter, welcher Temperaturen von Celsius in Fahrenheit und umgekehrt berechnen kann. Dieser Dienst wird in Eclipse entwickelt und mittels Apache Tomcat als Web Service zur Verfügung gestellt 6. Die Programmlogik fällt bewusst sehr bescheiden aus: public class Converter { public float celsiustofarenheit(float celsius) { return (celsius * 9 / 5) + 32; public float farenheittocelsius(float farenheit) { return (farenheit - 32) * 5 / 9; Eclipse generiert aus diesem Stück Code genau wie Visual Studio zuvor eine WSDL Dienstbeschreibung. Diese wird diesmal vom Visual Studio verwendet um die nötige Klassenkommunikationsstruktur in.net herleiten zu können. Die erzeugten.net Web Service Aufrufklassen werden in einem Package JavaBinding untergebracht. Dieses Package wird wiederum mit einem zentralen ESB Package verbunden (vgl. Abbildung 65). Das ESB Package stellt den neuen Dienst dem effektiven Dienstnutzer TempConverterClient zur Verfügung. Dieser kann nun über den künstlich erzeugten ESB auf den Java Web Dienst wie gewohnt über die Verwendung von Nachrichtenklassen zugreifen. 6 Wie man Web Services in Eclipse mittels Apache Tomcat realisiert kann ist nicht Bestandteil dieser Arbeit, kann aber unter folgendem Link nachgelesen werden: Student: Marko Marković Seite 69 von 95

70 TempConverterClient 1 ConverterMessages 1 ESB 1 JavaBinding 1 ServiceConverterMessages 1 Abbildung 65: Packageanordnung NServiceBus Szenario 7 Aufruf eines Java Web Dienstes Die in diesem Szenario verwendeten Nachrichtenklassen lauten FtoCServiceAnfrage (für die Konvertierung von Fahrenheit nach Celsius) und CtoFServiceAnfrage (für die Konvertierung von Celsius nach Fahrenheit). Beide Klassen besitzen die Eigenschaften TemperaturInFarenheit sowie TemperaturInCelsius. Über diese Eigenschaften wird zugleich der Anfrage- sowie der Antwortwert übermittelt. Im Package JavaBinding wurde ein Handler für die Bearbeitung beider Nachrichtenanfragetypen definiert. Bei diesem Handler handelt es sich um die Klasse TempConvertAnfrageHandler und diese hat folgenden Inhalt: public class TempConvertAnfrageHandler : IHandleMessages<FtoCServiceAnfrage>, IHandleMessages<CtoFServiceAnfrage> { public IBus Bus { get; set; public void Handle(FtoCServiceAnfrage neueanfrage) { Converter javatempconverter = new ConverterClient(); neueanfrage.temperaturincelsius = javatempconverter.farenheittocelsius(neueanfrage.temperaturinfarenheit); Bus.Reply(neueAnfrage); public void Handle(CtoFServiceAnfrage neueanfrage) { Converter javatempconverter = new ConverterClient(); neueanfrage.temperaturinfarenheit = javatempconverter.celsiustofarenheit(neueanfrage.temperaturincelsius); Bus.Reply(neueAnfrage); Die Klasse TempConvertAnfrageHandler empfängt somit eingehenden Konvertierungsanfragen und leitet diese direkt an den Java Web Service weiter. Die Antwort des Web Services wird anschliessend an den Bus zurückgesendet. Wie sich schnell erkennen lässt, ist das Einbinden von externen Diensten keine grosse Schwierigkeit, wenn man eine entsprechende Zwischenkomponente, in diesem Fall das JavaBinding Package, einschaltet. Die Entwickler von NServiceBus warnen jedoch auf ihrer Homepage vor dem hier gewählten Ansatz. Das Problem liegt darin, dass langsame Web Dienste erst nach einer gewissen Zeit antworten oder sogar eine HttpTimeoutException werfen. Dies geschieht alles innerhalb der Handle Methode der Verarbeitungsklasse, was nachfolgende Nachrichten ebenfalls abbremsen könnte. Aus diesem Grund empfehlen die NServiceBus Entwickler, einen zusätzlichen Adapter zwischen der Handle Methode und dem Web Service Aufruf zwischenzuschalten. Möchte man diese Regel strickt befolgen, erweist sich das Einbinden von externen Web Diensten doch noch als aufwändige Angelegenheit. Vielleicht wird in einer späteren Version von NServiceBus ein Mechanismus mitgeliefert, welcher Student: Marko Marković Seite 70 von 95

71 eine elegante Lösung dieses Problems zulässt. Bis dahin bleibt die Integration von externen, nicht.net Diensten in die bestehende Infrastruktur eine umfangreiche Aufgabe Realisierung mittels Neuron ESB Wesentlich angenehmer kann dieses Problem in Neuron ESB gelöst werden. Hier können die jeweili- gen Web Dienste einfach in eine Service Endpoint Registry eingetragen und sofort unter einem selbst gewählten Synonym verwendet werden. Das hier von Neuron ESB verfolgte Konzept sieht vor, dass eine Clientanwendung statt die effektiven Web Service Adresse, nur die im ESB intern registrierte Proxyadresse aufruft. Der ESB nimmt schliesslich die Clientanfrage entgegen und leitet diese an den Zieldienst weiter (vgl. Abbildung 66). Dieser Vorgang ist vollkommen von der verwendeten Clienttechnology gekoppelt, da der Client wie gewohnt nur einen Web Service aufruft. Potentielle Dienst- nutzer können somit.net, Java, C++ oder PHP Anwendungen sein. Auch hier kann wie bereits bei NServiceBus zuvor eine Zwischenkomponente zur Abstrahierung des Web Dienstes es eingebaut werden. Jedoch stellt sich auch hier die Frage, wie mit langsamen Web Diensten umzugehen ist, damit die Message Queue der Zwischenkomponente nicht allzu früh voll wird. Die Hersteller von Neuron ESB geben in ihrer Dokumentation allerdings keine Vorschläge. Client Adresse: /Axis2WSTest/ services/converter Effektive Web Service Adresse: /Axis2WSTest/ services/converter Weiterleitun von Client Adresse auf effektive Web Service Adresse wird von Neuron ESB übernommen Abbildung 66: Service Endpoint Konfiguration in Neruon ESB Was den Aspekt der Sicherheit anbelangt, so bietet Neuron ESB bereits vorgegebene Einstellungs- möglichkeiten. Über diese können zuvor definierte Policies einem Service Endpunkt zugewiesen und bestimmte Verschlüsselungsverfahren vorgeschrieben werden. Da in Neuron ESB die lokalen Web Services alle über einen IIS bereit gestellt werden, kann für firmeninterne Netze die Impersonation Option aktiviert werden. Über diese können die Sicherheitseinstellungen so konfiguriert werden, dass nur bestimmte Benutzer einer Netzwerkdomäne Zugriff auf eine Dienstschnittstelle erhalten. So kann die Zugriffssteuerung auf die verwendeten Windows Accounts in einem internen Netz ausgeweitet werden. 5.8 Szenario 8: Load Balancing In diesem Szenario soll untersucht werden, wie Hochverfügbarkeit in einem ESB für einen bestimm- ten Dienst erreicht werden kann. Um dies testen zu können, werden drei Dienste erstellte, welche alle die Fibonacci Folge bis zu einem übergebenem Parameter berechnen. Die Fibonacci Folge wird Student: Marko Marković Seite 71 von 95

72 bei allen Diensten innerhalb einer rekursiven Funktion berechnet. Dieses Vorgehen eignet sich besonders gut, wenn man einen Prozess einige Sekunden lang beschäftigen möchte. Die Aufgabe des ESBs besteht nun darin, Anfragen für die Fibonacci Folgen an den nächsten freien Dienst weiterzuleiten. Um zu testen, ob der ESB eintreffende Anfragen nicht einfach der Reihe nach den Prozessen zuteilt, wurde einem der Dienste (Fibonacci 3) ein zusätzliches Timeout von einigen Sekunden eingebaut. Durch dieses Timeout wird der betreffende Dienst langsamer als die anderen beiden. Die schnelleren Dienste müssten folglich bei einer begrenzten Anzahl Anfragen mehr Folgen berechnen als der langsamere Dienst, da diese schneller wieder bereit sind. Abbildung 67: Szenario 8 - Aufbau Realisierung mittels NServiceBus Das Load Balancing Konzept in NServiceBus wurde bereits im Unterabschnitt Load Balancing im Abschnitt über NServiceBus auf Seite 30 vorgestellt. Aus diesem Grund werden hier lediglich die notwendigen Konfigurationseinstellungen beschrieben, welche benötigt werden, um das auf der Abbildung 67 dargestellte System zu konstruieren. Als Beispiel sei hier ein Ausschnitt aus der App.config Datei des ersten Fibonacci Dienstets aufgeführt:... <MsmqTransportConfig InputQueue="Fibonacci1InputQueue" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5"/> <UnicastBusConfig DistributorControlAddress="distributorcontrolbus" DistributorDataAddress="distributordatabus"> <MessageEndpointMappings> </MessageEndpointMappings> </UnicastBusConfig>... In diesem Ausschnitt erkennt man, dass neben der Input Queue nun auch die Distributor Busadressen angegeben werden müssen. Beim Distributor handelt es sich um einen Host Dienst, der entwe- Student: Marko Marković Seite 72 von 95

73 der auf dem Zielrechner als Windows Dienst installiert 7 oder innerhalb eines Konsolenfensters gestartet werden kann. Die letztere stellt die einfachere Variante dar. Im Installationsverzeichnis von NServiceBus im Ordner distributor kann der betreffende Host Dienst NServiceBus.Host.exe in einem freien Windows Befehlseingabefenster gestartet werden. Sobald die Worker Dienste gestartet werden, werden diese vom Distributor registrieren und stehen somit allfälligen Dienstnutzern zur Verfügung. Als nächstes muss der Dienstnutzer so konfiguriert werden, dass dieser seine Anfragen an den Distributor richtet. Dies wird wie gewohnt wieder in der App.Config des Dienstnutzers eingestellt:... <UnicastBusConfig> <MessageEndpointMappings> <add Messages="Scenario7_MessageDeclaration" Endpoint="distributordatabus"/> </MessageEndpointMappings> </UnicastBusConfig>... Damit wären allen Grundvoraussetzungen für ein Load Balancing geschaffen. Nun kann der Systemaufbau gestartet werden. Innerhalb einer for Schleife werden nacheinander 40 Anfragen an den Fibonacci Dienst gesendet. Die Fibonacci Folge wird bis zu der 35 Sequenz berechnet. Die Anfragen landen zuerst in die Distributor Queue bevor diese nacheinander an den nächsten freien Worker weitergeleitet werden. Das Ergebnis der Anfrageverarbeitung ist auf der nachfolgenden Abbildung 68 dargestellt. Wie sich aus dem Ausgabefenster herauslesen lässt, haben die schnelleren Worker mehr Anfragen verarbeitet als der langsame. Somit ist erwiesen, dass der Distributor von NServiceBus die Anfragen in einem effektiven Load Balancing an die vorhandenen Worker verteilt. Schnelle Worker langsamer Worker Abbildung 68: Fibonacci Load Balancing Ergebnis in NServiceBus Realisierung mittels Neuron ESB Neuron ESB löst die Frage des Load Balancing nicht ganz so elegant wie NServiceBus. Um Load Balancing in Neuron ESB zu aktivieren müssen die Endpunkte wie bereits im vorherigen Szenario 7 in die Service Registry von Neuron ESB Explorer eingetragen werden. Da die Service Endpunkt Konfiguration für NET.TCP und MSMQ Dienste im Neuron ESB Explorer recht umfangreich ist, wurden die Diens- 7 Installationsanleitung unter [Stand: April 2010] Student: Marko Marković Seite 73 von 95

74 te der Einfachheit halber als Web Services entwickelt. Web Services können sehr einfach über eine integrierte Importfunktion in den Neuron ESB Explorer registriert werden. Mit Hilfe der Importfunktion werden die Fibonacci Web Dienste nacheinander in den Neuron ESB Explorer eingelesen und alle mit der gleichen Client Adresse (http://localhost:3999/fibbwservice.asmx) versehen (vgl. Abbildung 69). Abbildung 69: Redundante Service Endpunkte mit identischer Client Adresse Der Dienstnutzer richtet seine Anfrage wie bereits im Szenario 7 an die Client Adresse und wird so auf einen der drei verfügbaren Worker weitergeleitet. Leider hat sich nach ein paar Testdurchgängen herausgestellt, dass Neuron ESB die Aufgabenverteilung eher nach dem Zufallsprinzip als nach einem effektiven Load Balancing Verfahren vornimmt. Die Auslastung der Worker hat keinen Einfluss auf die Verteilung. So kam es in einigen Durchläufen vor, dass nur jeweils ein Worker alle Anfragen alleine bearbeitet hat und die anderen ungenutzt blieben. In anderen Durchläufen wurden die Anfragen nur auf die ersten beiden Worker verteilt, nicht jedoch auf den dritten Worker (vgl. Abbildung 70). In der Dokumentation von NServiceBus findet man keinerlei Auskunft über die genaue Strategie des Load Balancing bei mehreren Worker Diensten. Vielmehr wird beschrieben, wie man Neuron ESB in Farm Mode redundant einrichten und einsetzten kann. Eine Distributor Komponente wie bei NServiceBus ist für solche Zwecke jedoch nicht vorhanden. Schnelle Worker langsamer Worker Abbildung 70: Fibonacci Load Balancing Ergebnis in Neuron ESB Student: Marko Marković Seite 74 von 95

75 5.9 Fazit In diesem Kapitel wurden zwei Produkte analysiert, welche sich das Ziel gesetzt haben, verteilte Dienste so zusammen zu koppeln, dass die Geschäftsprozesse einer Unternehmung möglichst einfach umgesetzt werden können. Dabei verfolgen beide Programme zwei komplett verschiedene Ansätze. Während sich NServiceBus auf eine schnelle, unkomplizierte und zugleich leichtgewichtige Umsetzung von Dienstintegrationen fokussiert, bietet Neuron ESB als kommerzielle Lösung ein breites, vollumfängliches Rundumpacket mit allen nötigen Funktionen, welche vor allem von Grossunternehmen für eine erfolgreiche SOA Implementation benötigt werden. Vergleicht man bei den vorgestellten Szenarien den Aufwand, um eine bestimmte Aufgabe mit einem der beiden Produkte zu lösen, stellt man schnell fest, dass bei Neuron ESB ein wesentlich geringerer Programmieraufwand betrieben werden muss, als es bei NServiceBus der Fall ist. In Neuron ESB können bestimmte Aufgaben über einfache Konfigurationen gelöst werden, während in NServiceBus praktisch alles von Hand programmiert werden muss. Einer der Fragen, welche durch diese Arbeit verfolgt wurden, war, ob NServiceBus den Einsatz eines schwergewichtigen ESB Produktes, wie es Neuron ESB ist, ersetzen könnte. Immerhin hat sich gezeigt, dass sich eine NServiceBus Umgebung um die meisten der von einem ESB geforderten Konzepte (siehe Kapitel 3: Das Enterprise Service Bus SOA Pattern ) ausbauen lässt. Dies bedingt aber auch, dass die jeweiligen ESB Konzepte von Hand nachträglich vom Entwickler eingebaut werden müssten. Dies erfordert viel Zeit und Geduld. Angesichts des damit verbundenen Aufwandes ist von einem künstlichen Aufbau einer ESB Umgebung auf Grundlage von NServiceBus jedoch abzuraten. Dies nicht zuletzt auch deshalb, da alle Änderungen kompiliert und daher nicht zur Laufzeit durchgeführt werden können. Der Systembetrieb müsste für jede vorzunehmende Anpassung kurzzeitig unterbrochen werden. Dieser Umstand kann vor allem für heikle Geschäftsanwendungen nicht in Frage kommen. Da helfen erweiterte Open Source Produkte wie Simple Service Bus auch nicht weiter. Eine kurze Zusammenfassung der Vor- und Nachteile von NServiceBus gibt Tabelle 5. Vorteile Schnelle Umsetzung einer einfachen Dienstkommunikation Einfacher und schneller Einstieg Keine Lizenzkosten erforderlich Viele Beispiele im Internet auffindbar Unterstütz viele der SOA Designpatterns Ausbaufähig Tabelle 5: Vor- und Nachteile NServiceBus Nachteile Keine eingebauten Mechanismen zur Überwachung der Prozessabläufe vorhanden Kein GUI mit einer Auflistung aller Prozesse Ein ESB muss künstlich programmiert werden (aufwändig) Änderungen zur Laufzeit sind nur an bestimmten Subscriber möglich Keine eingebauten Mechanismen zum Schutz der Dienste vorhanden (ausser der Nachrichtenverschlüsselung) Kommunikation über mehrere Parteien kann relativ schnell unübersichtlich werden Anders sieht das ganze bei Neuron ESB aus. Dieses Produkt integriert wie bereits erwähnt alle geforderten ESB Funktionen vollumfänglich. Der Systemarchitekt kann sich völlig auf die Systemintegration konzentrieren und muss sich nicht um die Implementierung von nebensächlichen Funktionen wie Student: Marko Marković Seite 75 von 95

76 Monitoring, Security, Service Policy usw. kümmern. Diese werden ihm bereits durch das verwendete Produkt mitgeliefert. Der Systemarchitekt definiert vielmehr die Servicearchitektur, statt diese von Grund auf zu programmieren. Dies spart Zeit und Integrationsaufwand. Den Rest übernimmt Neuron ESB. Eine kurze Zusammenfassung der Vor- und Nachteile von NServiceBus gibt Tabelle 6. Vorteile Erfüllt alle an einem ESB gestellten Anforderungen Vollumfängliche Übersicht über alle Geschäftsprozesse und Schnittstellen Einfache Steuerung der vorhandenen Systemprozessen über ein einheitliches GUI Eingebaute Monitoring Mechanismen erlauben Einsicht in den aktuellen Nachrichtenverkehr des ESB Einfache Einbindung von WCF und Web Services möglich Einbindung von BizTalk Rules möglich Konzept der Pipelines ermöglichen flexible Nachrichtenverarbeitung zur Laufzeit Unterstützt XML Nachrichtentransformation über XSLT Erstellung von Workflows über Pipelines möglich Enthält eingebaute Sicherheitsmechanismen für den Zugriffschutz von Diensten Einfache Einbindung neuer Prozesse in das bestehende System zur Laufzeit möglich Tabelle 6: Vor- und Nachteile Neuron ESB Nachteile Hohe Lizenzkosten (im 5 stelligem Bereich) Single Point of Failure ohne Farm Mode Realisierung von Workflows ist sehr komplex Load Balancing auf Dienstebene nicht skalierbar Das Gesamtfazit, dass sich somit schliessen lässt, lautet, dass der Einsatz von NServiceBus in einer KMU Umgebung durchaus seine Berechtigung hat, jedoch eignet es sich nicht für die Service Integrationsaufgaben von Grossunternehmen. Umgekehrt ist von einem Einsatz von Neuron ESB bei Kleinund Mittelunternehmen einerseits wegen den hohen Lizenzkosten und andererseits wegen der benötigten Infrastruktur abzuraten. Student: Marko Marković Seite 76 von 95

77 6 Verzeichnis 6.1 Abbildungsverzeichnis Abbildung 1: Komponenten des Enterprise Service Bus SOA Patterns Abbildung 2: Einsatz einer Message Queue Abbildung 3: Service Broker Abbildung 4: Data Model Transformation Abbildung 5: Data Format Transformation Abbildung 6: Protocol Briding Abbildung 7: Regelbasiertes Routing Abbildung 8: Intermediate Routing Abbildung 9: Reliable Messaging Abbildung 10: Pizzabestellservice mit WS-Policy Abbildung 11: Richtlinienhierarchie Abbildung 12: Durchsetzung der Unternehmensrichtlinien mit Hilfe von WS-Policies Abbildung 13: SOA Plattform Abbildung 14: Event-Driven Massaging Abbildung 16: Gebotsseite für die Entwicklung von neuen Funktionen für ESB.NET (Quelle: 21 Abbildung 15: ESB.NET Logo Abbildung 17: Service Catalog in ESB.NET Abbildung 18: Eine der vielen Fehlermeldungen in ESB.NET Abbildung 19: NServiceBus Logo Abbildung 20: Store & Forward Abbildung 21: Request / Response Abbildung 22: Publish / Subscribe Abbildung 23: Busaufbau bei NServiceBus (Quelle: 25 Abbildung 24: NServiceBus Interface Beschreibung Abbildung 25: Einfacher Aufbau einer Client-Server-Kommunikation in NServiceBus Abbildung 26: Load Balancing in NServiceBus Abbildung 27: Von NServiceBus implementierte ESB Funktionskomponenten Abbildung 29: Simple Service Bus Endpoint Managment & Monitoring System (Quelle: 33 Abbildung 28: Simple Service Bus Logo Abbildung 30: Beispiel eines Dienst Monitoring in Simple Service Bus Abbildung 31: Neuron ESB Logo Abbildung 32: ESB Diagramm im Neuron ESB Explorer Abbildung 33: Erzeugung eines Key zur verschlüsselten Kommunikation in Neuron ESB Abbildung 34: Zuweisung eines Key zur Verschlüsselten Datenkommunikation innerhalb eines Topics Abbildung 35: Pipeline Konzept in Neuron ESB Abbildung 36: Neuron ESB Explorer (Quelle: 40 Student: Marko Marković Seite 77 von 95

78 Abbildung 37: Beispiel einer Federated ESB Infrastruktur Abbildung 38: Bildung von Zonen in Neuron ESB Abbildung 39: Farm Mode in Neuron ESB Abbildung 40: Echtzeitauswertung der Nachrichtenverarbeitung in Neuron ESB Abbildung 41: Von Neuron ESB implementierte ESB Funktionskomponenten Abbildung 42: Szenario 1 - Aufbau Abbildung 43: Szenario 1 - Aufbau der Packages in NServiceBus Abbildung 44: NServiceBus Klassenstruktur in Szenario Abbildung 45: Neuron ESB Klassendiagram zu Szenario 1 - Variante Abbildung 46: ESB Diagramm im Neuron ESB Explorer zum Szenario 1 - Variante Abbildung 47: Neuron ESB Klassendiagram zu Szenario 1 - Variante Abbildung 48: Konvertierungsbeispiel zu einer XML Rabattsystemnachricht Abbildung 49: Erstellung einer Pipeline zur XSL Transformation einer XML Nachricht Abbildung 50: Zuweisung einer Pipeline einem Subscriber Abbildung 51: ESB Diagram im Neuron ESB Explorer zum Szenario 1 - Variante Abbildung 52: Szenario 2 - Aufbau Abbildung 53: Szenario 2 - Aufbau der Packages in NServiceBus Abbildung 54: ESB Diagramm im Neuron ESB Explorer zum Szenario 2 - Variante Abbildung 55: Szenario 3 - Aufbau Abbildung 56: Versionierung in NServiceBus über Vererbung Abbildung 57: Neuron ESB Klassendiagram zu Szenario 3 - Variante Abbildung 58: Szenario 4 - Aufbau Abbildung 59: Szenario 5 - Aufbau Abbildung 60: Szenario 6 - Aufbau Abbildung 61: Messagemodel vom Prinzahlentestdienst in NServiceBus Abbildung 62: Front-End des NServiceBus Webdienstes im Web nach Start Abbildung 63: Import der WSDL Dienstbeschreibung in Eclipse Abbildung 64: Sequenzdiagramm der Nachrichtenverarbeitung zwischen dem Java Client und dem Primzahlentestdienst Abbildung 65: Packageanordnung NServiceBus Szenario 7 Aufruf eines Java Web Dienstes Abbildung 66: Service Endpoint Konfiguration in Neruon ESB Abbildung 67: Szenario 8 - Aufbau Abbildung 68: Fibonacci Load Balancing Ergebnis in NServiceBus Abbildung 69: Redundante Service Endpunkte mit identischer Client Adresse Abbildung 70: Fibonacci Load Balancing Ergebnis in Neuron ESB Tabellenverzeichnis Tabelle 1: Stichwortverzeichnis... 9 Tabelle 2: ESB Funktionskomponenten in NServiceBus Tabelle 3: Pipelinefunktionsübersicht in Neuron ESB Tabelle 4: Beschreibung der Neuron ESB Pipeline Workflow Bausteine Tabelle 5: Vor- und Nachteile NServiceBus Tabelle 6: Vor- und Nachteile Neuron ESB Student: Marko Marković Seite 78 von 95

79 7 Quellen [1] Marko Marković, "ESB & Process Engine in JBoss," Informatik, Distributed Secure Software Systems, Horw, [2] Erl, Little, Rischbeck, and Simon. SOA Patterns - A Community Site for SOA Design Patterns. [Online]. [3] Udi Dahan. (2007, Dezember) No more workflow for nservicebus please welcome the Saga. [Online]. [4] Neuron ESB. Neuron ESB Service Bus. [Online]. [5] IBM. WebSphere MQ. [Online]. [6] Keystroke IT Australia. Keystroke IT Australia. [Online]. [7] Jesus Rodriguez and Don Demsak. (2009, Dezember) The Architecture Journal. [Online]. [8] BizAgi. (2010, März) BizAgi. [Online]. [9] Udi Dahan. (2010, Februar) nservicebus. [Online]. [10] Mohammad Ahmed Meligy. (2008, April) GuruStop.NET. [Online]. [11] Thomas Erl, SOA Design Patterns, Inc Pearson Education, Ed. Boston, USA: PRENTICE HALL, Student: Marko Marković Seite 79 von 95

80 8 Anhang I 8.1 Einfache Nachrichtenübermittlung in NServiceBus Projekteinrichtung im Visual Studio In diesem Abschnitt soll eine einfache Nachrichtenübertragung mittels NServiceBus implementiert werden. Es wird das bereits im Abschnitt NServiceBus Implementation von Seite 25 vorgestellte Nachrichtenmodell implementiert. Für die Implementation wird im Microsoft Visual Studio eine neue Solution InfoAnfrage mit drei neuen Projekten erstellt, welche nach dem jeweiligen Packages benannt werden. Alle drei Packages müssen die mit NServiceBus mit installierten Bibliotheken log4net, NServiceBus, NService- Bus.Core sowie NServiceBus.Host, welche sich im Installationsverzeichnis von NServiceBus befinden, referenzieren. Zudem müssen die Packages Client sowie Server auf das Projekt InfoMessages referenzieren, welches die Nachrichtenbasis bildet. Aus der nachfolgenden Abbildung können die vereinzelten Projektstrukturen inkl. Referenz betrachtet werden, wie es im Visual Studio aussehen müsste. Das Projekt Client wird als ConsoleApplication im Visual Studio markiert. Die anderen Projekte InfoMessages und Server werden als Klassenbibliotheken gekennzeichnet. Nun können die Klassen nacheinander implementiert werden Package: InfoMessages Da dieses Projekt lediglich die zu verwendenden Nachrichtenklassen enthält, bleibt dessen Grösse Student: Marko Marković Seite 80 von 95

81 überschaubar. Es wird lediglich die InfoAnfrage Klasse implementiert. using System; using NServiceBus; namespace InfoMessages { public class InfoAnfrage : IMessage { public Guid AnfrageId { get; set; public string Mitteilung { get; set; Damit die Klasse als Nachrichtenklasse vom NServiceBus Framework erkannt wird, implementiert sie das IMessage Interface Package: Server Beim Serverprojekt müssen neben den Klassenimplementationen auch Konfigurationseinstellungen vorgenommen werden. Diese werden in der App.config Datei des Projektes vorgenommen. Deren Inhalt sieht beim Server wie folgt aus: <?xml version="1.0"?> <configuration> <configsections> <section name="msmqtransportconfig" type="nservicebus.config.msmqtransportconfig, NServiceBus.Core" /> <section name="unicastbusconfig" type="nservicebus.config.unicastbusconfig, NServiceBus.Core" /> </configsections> <MsmqTransportConfig InputQueue="MyServerInputQueue" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5" /> </configuration> Es werden zwei Transportkonfigurationen eingerichtet. Die eine betrifft die MSMQ und die andere den UnicastBus, welcher die Busimplementation in diesem Beispiel darstellt. Die wichtigste Einstellung wird im XML Element MsmqTransportConfig gesetzt. Das Attribut InputQueue definiert den eindeutigen Namen der MSMQ Input Queue. Anhand dieses Namens wird der Server in der NServiceBus Umgebung identifiziert. Das Attribut ErrorQueue gibt an, in welche System-Queue Fehlernachrichten weitergeleitet werden sollen. Die Standardqueue lautet error und sollte in der Regel nicht geändert werden. NumberOfWorkerThreads gibt an, wie viele Worker-Threads beim Betrieb des Servers laufen sollen. Je mehr Threads aktiv sind, umso mehr Nachrichten können parallel bearbeitet werden. Mit MaxRetries kann eingestellt werden, wie oft ein Client eine Anfrage, welche beim Verarbeiten eine Exception auslöst, vom Server bearbeitet wird, bis dieser alle weiteren Anfragen direkt in die ErrorQueue weiterleitet. Student: Marko Marković Seite 81 von 95

82 Der Server ist somit konfiguriert. Über die Klasse EndpointConfig kann der Server nun als Server- Endpunkt deklariert werden: using NServiceBus; namespace Server { class EndpointConfig : IConfigureThisEndpoint, AsA_Server { Nun fehlt nur noch die Nachrichtenverarbeitung. Diese ist in der Klasse RequestDataMessageHandler enthalten: using System; using NServiceBus; using InfoMessages; namespace Server { class RequestDataMessageHandler : IHandleMessages<InfoAnfrage> { public void Handle(InfoAnfrage neueanfrage) { Console.ForegroundColor = ConsoleColor.Yellow; Console.WriteLine("Neue Anfrage eingetroffen: {0 (ID: {1)", neueanfrage.mitteilung, neueanfrage.anfrageid); Console.ForegroundColor = ConsoleColor.Gray; Package: Client Nun da der Server fertig ist, kann der Client erstellt werden. Auch beim Client wird eine Kommunikationskonfiguration benötigt. Diese fällt diesem etwas kürzer aus und wird wiederum in der App.config Datei des Projektes eingerichtet: <?xml version="1.0" encoding="utf-8"?> <configuration> <configsections> <section name="unicastbusconfig" type="nservicebus.config.unicastbusconfig, NServiceBus.Core" /> </configsections> <UnicastBusConfig> <MessageEndpointMappings> <add Messages="InfoMessages" Endpoint="MyServerInputQueue" /> </MessageEndpointMappings> </UnicastBusConfig> </configuration> Auf der Clientseite wird die anzusprechende Server Input Queue MyServerInputQueue sowie das verwende Nachrichtenpackage InfoMessages angegeben. Auch hier wird über Klasse EndpointConfig die Natur des Endpunktes festgelegt. In diesem Fall handelt es sich um einen Client. Aus diesem Student: Marko Marković Seite 82 von 95

83 Grund wird das Interface AsA_Client implementiert. using NServiceBus; namespace Client { class EndpointConfig : IConfigureThisEndpoint, AsA_Client { Weitere Konfigurationen werden nicht mehr benötigt. Die Clientlogik kann nun in der Klasse RequestSender programmiert werden: using System; using NServiceBus; using InfoMessages; namespace Client { public class RequestSender { static void Main(string[] args) { InfoAnfrage neueanfrage = new InfoAnfrage(); neueanfrage.anfrageid = Guid.NewGuid(); neueanfrage.mitteilung = "Benötige 10 Einheiten vom Typ XY"; sendeanfrage(neueanfrage); private static void sendeanfrage(infoanfrage neueanfrage) { Console.WriteLine("Zum Starten [Enter] drücken"); Console.ReadLine(); IBus meinbus = Configure.With().SpringBuilder().XmlSerializer().MsmqTransport().IsTransactional(true).PurgeOnStartup(false).UnicastBus().ImpersonateSender(false).LoadMessageHandlers().CreateBus().Start(); meinbus.send(neueanfrage); Console.WriteLine("Anfrage abgeschickt"); Der Client ist somit nun ebenfalls einsatzbereit Testdurchführung Nun soll die programmierte Infrastruktur gestartet werden. Hierfür sind noch einige kleinere Einstellungen im Visual Studio erforderlich. Beim Projekt Server muss in den Projekteigenschaften unter Student: Marko Marković Seite 83 von 95

84 Debug die Startaktion angepasst werden. Der Server wird zu Testzwecke mit einem Host Prozess von NServiceBus gestartet. Hierfür wird als externes Startprogramm der sich im Debug Verzeichnis des Projektes befindende NServiceBus.Host.exe Host Prozess angegeben: Als letzter Schritt wird in den Eigenschaften der Solution die Option Single startup project auf Multiple startup projects angepasst. Als Startobjekte werden die Projekte Client und Server gesetzt. Nun können der Client und der Server gestartet werden. Es erscheinen zwei Konsolefenster. Beim einem der beiden Fenster erscheint die Meldung Zum Starten [Enter] drücken. Student: Marko Marković Seite 84 von 95

85 Dies ist das Cleint-Konsolefenster. Sobald das Server-Konsolefenster die Startsequenz beendet hat, kann mit einer beliebigen Taste auf der Clientseite die Anfrage an den Server gesendet werden. Diese zeigt diese tatsächlich in gelber Schrift neben vielen anderen Debug Meldungen an. Die Kommunikation mittels NServiceBus ist somit hergestellt und funktionsfähig. 8.2 Einfache Nachrichtenübermittlung in Neuron ESB Projekteinrichtung im Visual Studio In diesem Abschnitt wird gezeigt, wie einfach eine Nachrichtenübermittlung zwischen zwei Diensten in Neuron ESB realisiert werden kann. Für die Implementation wird wie im vorhergehenden Abschnitt im Microsoft Visual Studio eine neue Solution InfoAnfrage erstellt. Diesmal werden statt drei lediglich zwei neue Konsoleprojekte AnfrageSender und AnfrageEmpfänger erstellt. Beide Projekte referenzieren auf die mit Neuron ESB installierten Bibliotheken Neuron.dll sowie Neuron.ESB.dll. Auch hier finden sich die Programmbibliotheken im Installationsverzeichnis des Produktherstellers. Die nebenstehende Abbildung zeigt die Struktur inkl. Referenzen der verwendeten Visual Studio Projekte. Student: Marko Marković Seite 85 von 95

ESB Produkte in.net. MSE Vertiefungsmodul II. Marko Marković. Student. Jörg Hofstetter. Advisor. André Rogger (HSLU, Wirtschaft) Experte

ESB Produkte in.net. MSE Vertiefungsmodul II. Marko Marković. Student. Jörg Hofstetter. Advisor. André Rogger (HSLU, Wirtschaft) Experte ESB Produkte in.net Student Advisor Experte Marko Marković Jörg Hofstetter André Rogger (HSLU, Wirtschaft) Kompetenzzentrum Distributed Secure Software Systems (D3S) 3 Das Enterprise Service Bus SOA Pattern

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

ObjectBridge Java Edition

ObjectBridge Java Edition ObjectBridge Java Edition Als Bestandteil von SCORE Integration Suite stellt ObjectBridge Java Edition eine Verbindung von einem objektorientierten Java-Client zu einer fast beliebigen Server-Komponente

Mehr

Enterprise Service Bus

Enterprise Service Bus Enterprise Service Bus Christopher Weiß 25.01.2010 Gliederung 1 Motivation und Einordung Integrationsformen 2 Definition und Eigenschaften Definitionen Eigenschaften 3 Aufbau und Konzepte Aufbau Produkte

Mehr

SOA mit.net: Vom Geschäftsprozess zur Lösung

SOA mit.net: Vom Geschäftsprozess zur Lösung SOA mit.net: Vom Geschäftsprozess zur Lösung Manfred Steyer Aktuelles Buch.Net 4.0 Update ISBN 978-3866454439 http://tinyurl.com/net4update 1 Kontakt [www] www.softwarearchitekt.at [mail] Manfred.Steyer@SoftwareArchitekt.at

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr

Tutorial: Eigene Module und Extensions entwickeln. Version: 0.1 Autor: Anja Beuth

Tutorial: Eigene Module und Extensions entwickeln. Version: 0.1 Autor: Anja Beuth Tutorial: Eigene Module und Extensions entwickeln Version: 0.1 Autor: Anja Beuth Inhaltsverzeichnis 1 2 2.1 2.2 2.3 2.4 3 4 4.1 4.2 4.3 5 5.1 6 6.1 6.2 Notwendigkeit prüfen... Ein Projekt in Visual Studio

Mehr

Ein Vergleich zwischen SCA,JBI und WCF. Marcello Volpi

Ein Vergleich zwischen SCA,JBI und WCF. Marcello Volpi Service Component Architecture Ein Vergleich zwischen SCA,JBI und WCF Marcello Volpi Agenda Einführung Service Component Architecture (SCA) Java Business Integration (JBI) Windows Communication Foundation

Mehr

Oracle Advanced Queuing AQ

Oracle Advanced Queuing AQ Oracle Advanced Queuing AQ 13.09.2012 Referenten: Claus Cullmann Andreas Steinel Inhalt Motivation Message Systeme Eigenschaften, Beispiele Oracle AQ Terminologie AQ Beispiel pure SQL Beispiel Java-Anwendung

Mehr

Installation Wawi SQL in Verbindung mit Microsoft SQL Server 2008 Express with Tools

Installation Wawi SQL in Verbindung mit Microsoft SQL Server 2008 Express with Tools Installation Wawi SQL in Verbindung mit Microsoft SQL Im nachfolgenden Dokument werden alle Einzelschritte aufgeführt, die als Voraussetzung für die korrekte Funktionalität der SelectLine Applikation mit

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen.

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. 181 In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. Wir beginnen mit dem Startup-Unternehmen Seals GmbH aus Frankfurt,

Mehr

Error-Hospital für Oracle SOA Suite

Error-Hospital für Oracle SOA Suite Error-Hospital für Oracle SOA Suite Markus Lohn esentri AG Ettlingen Schlüsselworte Fusion Middleware, SOA, SOA Suite Einleitung Die Entwicklung von Services mit der SOA Suite erfolgt überwiegend deklarativ

Mehr

COPPER Best Practices

COPPER Best Practices COPPER Best Practices Version 1.0.1 Wann sollte man überhaupt COPPER verwenden? Allgemein genau dann, wenn man von der COPPER Notation oder den COPPER-Features profitieren kann. Ein wesentliches Feature

Mehr

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2)

Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2) Referat im Rahmen des Proseminars Internettechnologie WS 2007/2008 Thema: Web Services und serviceorientierte Architekturen (SOA) vorgelegt von: Intelligente Web Services sind für das Informationszeitalter,

Mehr

PRODATIS CONSULTING AG. Folie 1

PRODATIS CONSULTING AG. Folie 1 Folie 1 Führend im Gartner Magic Quadranten für verteilte, interagierende SOA Projekte Oracle ist weltweit auf Rang 1 auf dem Markt der Enterprise Service Bus Suiten (ESB) für SOA Software 2010 26,3 %

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Einführung in die Cross-Plattform Entwicklung Web Services mit dem Intel XDK

Einführung in die Cross-Plattform Entwicklung Web Services mit dem Intel XDK Einführung in die Cross-Plattform Entwicklung Web Services mit dem Intel XDK Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel XDK und dem Zugriff auf Web Services vertraut. Der Web Service

Mehr

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Business Process Management und Enterprise Service Bus

Business Process Management und Enterprise Service Bus Business Process Management und Enterprise Service Bus Gegner oder doch eine gute Ergänzung? Author: Date: Markus Demolsky Soreco International 08. November 2010 Vortragender Warum über Integration nachdenken?

Mehr

Oracle Warehouse Builder 3i

Oracle Warehouse Builder 3i Betrifft Autoren Art der Info Oracle Warehouse Builder 3i Dani Schnider (daniel.schnider@trivadis.com) Thomas Kriemler (thomas.kriemler@trivadis.com) Technische Info Quelle Aus dem Trivadis Technologie

Mehr

Seminarvortrag Serviceorientierte Softwarearchitekturen

Seminarvortrag Serviceorientierte Softwarearchitekturen Seminarvortrag Serviceorientierte Softwarearchitekturen vorhandene Altsysteme Gliederung Einführung Grundlegende Modelle Grundlegende Komponenten Architekturen 2 Einführung Altanwendung und Altsysteme?

Mehr

Installation SelectLine SQL in Verbindung mit Microsoft SQL Server 2008 Express with Tools

Installation SelectLine SQL in Verbindung mit Microsoft SQL Server 2008 Express with Tools Im nachfolgenden Dokument werden alle Einzelschritte aufgeführt, die als Voraussetzung für die korrekte Funktionalität der SelectLine Applikation mit dem SQL Server Express with Tools 2008 vorgenommen

Mehr

SAP NetWeaver Gateway. Connectivity@SNAP 2013

SAP NetWeaver Gateway. Connectivity@SNAP 2013 SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Howto. Konfiguration eines Adobe Document Services

Howto. Konfiguration eines Adobe Document Services Howto Konfiguration eines Adobe Document Services (ADS) Inhaltsverzeichnis: 1 SYSTEMUMGEBUNG... 3 2 TECHNISCHE VERBINDUNGEN ZWISCHEN DEN SYSTEMEN... 3 2.1 PDF BASIERENDE FORMULARE IN DER ABAP UMGEBUNG...

Mehr

Die Windows Workflow Foundation in Microsoft.NET 3.0

Die Windows Workflow Foundation in Microsoft.NET 3.0 Die Windows Workflow Foundation in Microsoft.NET 3.0 Klaus Rohe (klrohe@microsoft.com) Developer Platform & Strategy Group Microsoft Deutschland GmbH Agenda Was ist Windows Workflow Foundation? Microsoft

Mehr

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1 Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 31.03.2003 J.M.Joller 1 Inhalt Architekturen Main Stream.NET J2EE und Applikations-Server Sicht der Anbieter Java J2EE J2EE versus.net Web

Mehr

Metadata Service Respository (MDS) - Sehen, lernen, verstehen!

Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Carsten Wiesbaum esentri AG Schlüsselworte Metadata Service Repository, MDS, Oracle Fusion Middleware Einleitung Früher oder später wird jeder

Mehr

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I

Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I Sicherheitsaspekte in Service Orientierten Architekturen Eike Falkenberg Sommersemester 2006 Anwendungen I Agenda SOA? Web Services? Sicherheitsrisiko Web Services Web Services & Sicherheit Sichere SOAs

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Dokumentation zur Anlage eines JDBC Senders

Dokumentation zur Anlage eines JDBC Senders Dokumentation zur Anlage eines JDBC Senders Mithilfe des JDBC Senders ist es möglich auf eine Datenbank zuzugreifen und mit reiner Query Datensätze auszulesen. Diese können anschließend beispielsweise

Mehr

EDI Datenaustausch und Konvertierung Funktionsumfang & Services

EDI Datenaustausch und Konvertierung Funktionsumfang & Services cleardax EDI Datenaustausch und Konvertierung Funktionsumfang & Services Einleitung Hauptfunktionen Datenaustausch (Anbindungsmöglichkeiten) Konvertierung Mappings Zusatzleistungen und Funktionen cleardax

Mehr

Installation Microsoft SQL Server 2008 Express

Installation Microsoft SQL Server 2008 Express Installation Microsoft SQL Server 2008 Express Im nachfolgenden Dokument werden alle Einzelschritte aufgeführt, die als Voraussetzung für die korrekte Funktion der SelectLine Applikation mit dem SQL Server

Mehr

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE PROZESSE INTEGRIEREN leicht gemacht DURCH TransConnect Geschäftsprozesse ableiten mit der Universal Worklist (UWL) Integrationsszenarien effektiver verwalten und transportieren Optimierte Personalverwaltung

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

ESB & Process Engines Die Kombination macht s aus Wie man die verschiedenen Dienste einer Unternehmung in den Griff bekommt und zusammenspielen lässt

ESB & Process Engines Die Kombination macht s aus Wie man die verschiedenen Dienste einer Unternehmung in den Griff bekommt und zusammenspielen lässt ESB & Process Engines Die Kombination macht s aus Wie man die verschiedenen Dienste einer Unternehmung in den Griff bekommt und zusammenspielen lässt von Marko Marković, marko.markovic@stud.hslu.ch, MSE

Mehr

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Betriebswirtschaftliche Anwendungen 2: Serviceorientierte Anwendungsintegration Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Umrechnung von Währungen Steffen Dorn, Sebastian Peilicke,

Mehr

WebSphere_Integration_Developer_D_Jan06 Script

WebSphere_Integration_Developer_D_Jan06 Script WebSphere_Integration_Developer_D_Jan06 Script 1a In dieser Demonstration wird Will Dunlop, ein Integrationsentwickler bei JK Enterprises, IBM oder WID benutzen, um einen neuen service-orientierten Geschäftsprozess

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 08 Einführung Service-Orientierte Architekturen

Enterprise Applikation Integration und Service-orientierte Architekturen. 08 Einführung Service-Orientierte Architekturen Enterprise Applikation Integration und Service-orientierte Architekturen 08 Einführung Service-Orientierte Architekturen Ist SOA immer noch aktuell? Prof. Dr. Holger Wache http://bhc3.files.wordpress.com/2009/07/gartner-emerging-technologies-hype-cycle-2009.png?w=552&h=451

Mehr

Java Forum Stuttgart 2008

Java Forum Stuttgart 2008 Professionelle Open Source SOA in 45 Minuten! Java Forum Stuttgart 2008 Dr. Halil-Cem Gürsoy, CDI AG Der Referent Insgesamt ca. 10 Jahre Beratung, davor Forschung Senior Consultant - JEE Evangelist Hauptsächlich

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen Open Source professionell einsetzen 1 Mein Background Ich bin überzeugt von Open Source. Ich verwende fast nur Open Source privat und beruflich. Ich arbeite seit mehr als 10 Jahren mit Linux und Open Source.

Mehr

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa Dr. Stefan Pietschmann, PF Service-Oriented Enterprise Applications, T-Systems MMS Dresden, 22.10.2013 About US PF42 Service-oriented enterprise

Mehr

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick:

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick: Seite 1 PROTAKT Speziallösung EDI Connect Auf einen Blick: EDI CONNECT für Microsoft Dynamics NAV Elektronischer Datenaustausch ganz effizient und einfach über Ihr Microsoft Dynamics NAV System. Vollständige

Mehr

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Johannes Michler PROMATIS software GmbH Ettlingen Schlüsselworte Geschäftsprozess, Horus, SOA, BPMN, ADF, WebCenter Einleitung Die Umsetzung

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Java Web Services mit Apache Axis2

Java Web Services mit Apache Axis2 Thilo Frotscher, Marc Teufel, Dapeng Wang Java Web Services mit Apache Axis2 ntwickier Vorwort 13 Wer sollte dieses Buch lesen? 14 Aufbau 14 Wichtiger Hinweis zu den Listings 16 Feedback 16 Danksagung

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Benutzerverwaltung mit ASP.NET Membership

Benutzerverwaltung mit ASP.NET Membership Benutzerverwaltung mit ASP.NET Membership Dieser Artikel soll zeigen, wie man ASP.NET Membership einsetzt, um Benutzer einer Web Anwendung zu authentifizieren. Es werden sowohl Grundlagen wie die Einrichtung

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

Universal Mobile Gateway V4

Universal Mobile Gateway V4 PV-Electronic, Lyss Universal Mobile Gateway V4 Autor: P.Groner Inhaltsverzeichnis Allgemeine Informationen... 3 Copyrightvermerk... 3 Support Informationen... 3 Produkte Support... 3 Allgemein... 4 Definition

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Powermanager Server- Client- Installation

Powermanager Server- Client- Installation Client A Server Client B Die Server- Client- Funktion ermöglicht es ein zentrales Powermanager Projekt von verschiedenen Client Rechnern aus zu bedienen. 1.0 Benötigte Voraussetzungen 1.1 Sowohl am Server

Mehr

SMTP-Verfahren POP-Verfahren IMAP-Verfahren

SMTP-Verfahren POP-Verfahren IMAP-Verfahren IT Zertifikat Mailserver 01 Server Mailserver Protokolle Teil des Client-Server-Modells bietet Dienste für lokale Programme/ Computer (Clients) an -> Back-End-Computer Ausbau zu Gruppe von Servern/ Diensten

Mehr

Dreamwap. Systemanalyse

Dreamwap. Systemanalyse Dreamwap Systemanalyse Änderungskontrolle Version Datum Name Bemerkung 0.1 15.7.2000 P. Troxler Initialversion 0.2 16.7.2000 P. Troxler Neue Tabelle: Kap. 2.1. Vgl. Datenbank Tabellen 0.3 18.7.2000 P.

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

License Management 1.0 - SDK

License Management 1.0 - SDK License Management 1.0 - SDK Inhalt Allgemeine Beschreibung... 2 Vorbereitungen... 2 Download aller nötigen Dateien und Dokumentationen... 2 Beantragung eines ValidationKeys... 2 Beantantragung einer Development-Lizenz...

Mehr

PDF FormServer Quickstart

PDF FormServer Quickstart PDF FormServer Quickstart 1. Voraussetzungen Der PDF FormServer benötigt als Basis einen Computer mit den Betriebssystemen Windows 98SE, Windows NT, Windows 2000, Windows XP Pro, Windows 2000 Server oder

Mehr

Enterprise Application Integration Erfahrungen aus der Praxis

Enterprise Application Integration Erfahrungen aus der Praxis Enterprise Application Integration Erfahrungen aus der Praxis Teil 4: EAI und.net, EAI und J2EE Tutorial NODs 2002, Wolfgang Keller and Generali 2001, 2002, all rights reserved 1 Überblick EAI und....net

Mehr

Next generation open source BPM JBoss jbpm 4. Java Forum Stuttgart 02.07.2009 bernd.ruecker@camunda.com

Next generation open source BPM JBoss jbpm 4. Java Forum Stuttgart 02.07.2009 bernd.ruecker@camunda.com Next generation open source BPM JBoss jbpm 4 Java Forum Stuttgart 02.07.2009 bernd.ruecker@camunda.com Bernd Rücker / bernd.ruecker@camunda.com / 2 Guten Morgen Berater, Trainer, Coach Softwareentwickler

Mehr

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Wiederholung: Beginn

Wiederholung: Beginn B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben

Mehr

3 Programmiermodelle für parallele und verteilte Systeme

3 Programmiermodelle für parallele und verteilte Systeme 3 Programmiermodelle für parallele und verteilte Systeme Das vorherrschende Programmiermodell für parallele und verteilte Systeme ist das Client Server Modell. Das Client Server Modell ist unabhängig von

Mehr

ALE-Szenarien der Anlagenbuchhaltung

ALE-Szenarien der Anlagenbuchhaltung ALE-Szenarien der Anlagenbuchhaltung HELP.FIAA Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind,

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

1. Wie können Forms und SOA integriert werden?

1. Wie können Forms und SOA integriert werden? Forms goes SOA Jüssen, Stefan Senior Consultant 03.02.2011 Jede Änderung im Geschäftsprozess muss umgehend in der unterstützenden Software abgebildet werden können. Professionelle Systementwicklung basiert

Mehr

4D v11 SQL Release 6 (11.6) ADDENDUM

4D v11 SQL Release 6 (11.6) ADDENDUM ADDENDUM Willkommen zu Release 6 von 4D v11 SQL. Dieses Dokument beschreibt die neuen Funktionalitäten und Änderungen der Version. Erweiterte Verschlüsselungsmöglichkeiten Release 6 von 4D v11 SQL erweitert

Mehr

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Web-Content-Management-Systeme () dienen dazu, komplexe Websites zu verwalten und den Autoren einzelner Webseiten möglichst

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

ESecuremail Die einfache Email verschlüsselung

ESecuremail Die einfache Email verschlüsselung Wie Sie derzeit den Medien entnehmen können, erfassen und speichern die Geheimdienste aller Länder Emails ab, egal ob Sie verdächtig sind oder nicht. Die Inhalte von EMails werden dabei an Knotenpunkten

Mehr

Leistung schafft Vertrauen

Leistung schafft Vertrauen SOA Hintergrund und Praxis visionäre Praxis oder praxisnahe Vision Toni Gasser Integration Services 27. Oktober 2010 Leistung schafft Vertrauen Private Banking Investment Banking Asset Management Seite

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis

SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis Heutige Vorlesung SOAP und WSDL in der Praxis Aufbau von WSDL-Beschreibungen Protokoll-Bindungen in WSDL Google-WSDL lesen und erweitern können Vor- und Nachteile von WSDL heute Wie wird SOAP/WSDL verwendet?.net,

Mehr

Microsoft ISA Server 2006

Microsoft ISA Server 2006 Microsoft ISA Server 2006 Leitfaden für Installation, Einrichtung und Wartung ISBN 3-446-40963-7 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-40963-7 sowie im Buchhandel

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Service Oriented Architectures ICA Joh. Kepler Universität Linz Überblick Service-Oriented Architectures (SOAs) Verteilt Basierend auf Standards Lose gekoppelt Protokoll-unabhängig

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr