Dieses Gipfeltreffen deckt die neuesten handels - und technologischen Herausforderungen, die die Buy-Side in einer sich ständig verändernden Finanz - und Regulierungslandschaft betreffen, sowie innovative Strategien zur Optimierung der Handelsabwicklung, Risikomanagement und Steigerung der operativen Effizienz bei gleichzeitiger Minimierung der Kosten. WatersTechnology und Sell-Side Technology freuen sich, den 7. jährlichen North American Trading Architecture Summit zu präsentieren. Zusammenführung von Technologen, Architekten, Softwareentwicklern und Rechenzentrumsleitern aus der Finanzwelt, um die neuesten Fragen der Handelstechnologie zu diskutieren. Datum: 05 Apr 2017 New York Marriott Marquis, New York Tokio Finanzinformationstechnologie Gipfel Gewässer TechnologieInteresting Anwendungen selten leben in Isolation. Ob Ihre Vertriebsanwendung sich mit Ihrer Inventaranwendung verbinden muss, Ihre Beschaffungsanwendung muss eine Verbindung zu einem Auktionsstandort herstellen oder Ihre PDAs müssen mit dem Unternehmenskalender-Server synchronisieren, es scheint, dass jede Anwendung durch Integration mit anderen Anwendungen besser gestaltet werden kann. Alle Integrationslösungen müssen mit einigen grundlegenden Herausforderungen umgehen: Netzwerke sind unzuverlässig. Integrationslösungen müssen Daten von einem Computer zu einem anderen über Netzwerke transportieren. Im Vergleich zu einem Prozess, der auf einem einzelnen Computer läuft, muss das verteilte Computing bereit sein, mit einem viel größeren Satz möglicher Probleme umzugehen. Oftmals werden zwei zu integrierende Systeme durch Kontinente getrennt, und Daten zwischen ihnen müssen über Telefonleitungen, LAN-Segmente, Router, Switches, öffentliche Netze und Satellitenverbindungen reisen. Jeder dieser Schritte kann zu Verzögerungen oder Unterbrechungen führen. Netzwerke sind langsam. Das Senden von Daten über ein Netzwerk ist mehrere Größenordnungen langsamer als ein lokaler Methodenaufruf. Das Entwerfen einer breit verteilten Lösung die gleiche Weise, die Sie einer einzelnen Anwendung nähern würden, könnte verheerende Leistungsimplikationen haben. Alle zwei Anwendungen sind unterschiedlich. Integrationslösungen müssen Informationen zwischen Systemen übertragen, die unterschiedliche Programmiersprachen, Betriebssystemplattformen und Datenformate verwenden. Eine Integrationslösung muss in der Lage sein, mit all diesen verschiedenen Technologien zu kommunizieren. Veränderung ist unvermeidlich. Anwendungen ändern sich mit der Zeit. Eine Integrationslösung muss mit Änderungen in den Anwendungen, die sie verbindet, Schritt halten. Integrationslösungen können leicht in einem Lawineneffekt von Änderungen erwischt werden, wenn sich ein System ändert, alle anderen Systeme können betroffen sein. Eine Integrationslösung muss die Abhängigkeiten von einem System zum anderen durch eine lockere Kopplung zwischen Anwendungen minimieren. Im Laufe der Zeit haben Entwickler diese Herausforderungen mit vier Hauptansätzen überwunden: File Transfer Eine Anwendung schreibt eine Datei, die eine andere später liest. Die Anwendungen müssen sich auf den Dateinamen und Speicherort, das Format der Datei, das Timing, wenn es geschrieben und gelesen werden, und wer wird die Datei löschen zu vereinbaren. Gemeinsam genutzte Datenbank Mehrere Anwendungen verfügen über das gleiche Datenbankschema, das sich in einer einzigen physischen Datenbank befindet. Da es keine doppelte Datenspeicherung gibt, müssen keine Daten von einer Anwendung in die andere übertragen werden. Remoteprozeduraufruf Eine Anwendung stellt einige ihrer Funktionalitäten zur Verfügung, sodass sie remote von anderen Anwendungen als Remoteprozedur abgerufen werden kann. Die Kommunikation erfolgt in Echtzeit und synchron. Messaging Eine Anwendung veröffentlicht eine Nachricht an einen gemeinsamen Nachrichtenkanal. Andere Anwendungen können die Nachricht aus dem Kanal zu einem späteren Zeitpunkt lesen. Die Applikationen müssen sich auf einen Kanal sowie das Format der Nachricht einigen. Die Kommunikation ist asynchron. Während alle vier Ansätze im Wesentlichen das gleiche Problem lösen, hat jeder Stil seine eigenen Vor-und Nachteile. In der Tat können Anwendungen integrieren mit mehreren Stilen, so dass jeder Punkt der Integration nutzt den Stil, der am besten passt. Was ist Messaging Dieses Buch behandelt die Verwendung von Messaging zur Integration von Anwendungen. Ein einfacher Weg, um zu verstehen, was Messaging ist, um die Telefonanlage zu betrachten. Ein Telefonat ist eine synchrone Kommunikationsform. Ich kann nur mit der anderen Partei kommunizieren, wenn die andere Partei zum Zeitpunkt des Anrufs verfügbar ist. Voice-Mail auf der anderen Seite, ermöglicht asynchrone Kommunikation. Bei Voicemail, wenn der Empfänger nicht antwortet, kann der Anrufer ihm eine Nachricht hinterlassen, sobald der Empfänger (an seiner Bequemlichkeit) kann die Nachrichten in der Warteschlange in seiner Mailbox zu hören. Voice Mail ermöglicht es dem Anrufer, eine Nachricht zu hinterlassen, damit der Empfänger es später hören kann, was viel einfacher ist als der Versuch, den Anrufer und den Empfänger gleichzeitig am Telefon zu bekommen. Voice Mail bündelt (mindestens einen Teil) eines Anrufs in eine Nachricht und wart es für späteren Verbrauch Dies ist im Wesentlichen, wie Messaging funktioniert. Messaging ist eine Technologie, die eine schnelle, asynchrone Programm-zu-Programm-Kommunikation mit zuverlässiger Lieferung ermöglicht. Die Programme kommunizieren durch Senden von Datenpaketen mit der Bezeichnung Nachricht s zueinander. Kanal s, auch als Warteschlangen bekannt, sind logische Pfade, die die Programme verbinden und Nachrichten übermitteln. Ein Kanal verhält sich wie eine Auflistung oder ein Array von Nachrichten, aber einer, der magisch auf mehreren Computern gemeinsam genutzt wird und gleichzeitig von mehreren Anwendungen verwendet werden kann. Ein Sender oder Produzent ist ein Programm, das eine Nachricht sendet, indem er die Nachricht an einen Kanal schreibt. Ein Empfänger oder Verbraucher ist ein Programm, das eine Nachricht empfängt, indem es von einem Kanal gelesen (und gelöscht) wird. Die Nachricht selbst ist einfach irgendeine Art von Datenstrukturen wie eine Zeichenfolge, ein Bytearray, ein Datensatz oder ein Objekt. Sie kann einfach als Daten interpretiert werden, wie die Beschreibung eines Befehls, der auf dem Empfänger aufgerufen werden soll, oder als Beschreibung eines Ereignisses, das im Sender aufgetreten ist. Eine Nachricht enthält eigentlich zwei Teile, einen Header und einen Körper. Der Header enthält Meta-Informationen über die Nachricht, die ihn gesendet hat, wo er hingeht, usw. Diese Informationen werden vom Messaging-System verwendet und sind meist (aber nicht immer) von den Anwendungen unter Verwendung der Nachrichten ignoriert. Der Körper enthält die übermittelten Daten und wird vom Messaging-System ignoriert. Im Gespräch, wenn ein Anwendungsentwickler, der Messaging verwendet, spricht über eine Nachricht, hes in der Regel bezieht sich auf die Daten im Körper der Nachricht. Asynchrone Messaging-Architekturen sind leistungsstark, aber erfordern uns, unseren Entwicklungsansatz neu zu überdenken. Im Vergleich zu den anderen drei Integrationsansätzen waren relativ wenige Entwickler mit Messaging - und Nachrichtensystemen konfrontiert. Daher sind Anwendungsentwickler im Allgemeinen nicht so vertraut mit den Idiomen und Besonderheiten dieser Kommunikationsplattform. Was ist ein Messaging-System Messaging-Funktionen werden in der Regel durch ein separates Software-System namens Messaging-System oder Message-orientierte Middleware (MOM) zur Verfügung gestellt. Ein Messaging-System verwaltet Messaging die Art und Weise ein Datenbanksystem verwaltet Daten Persistenz. So wie ein Administrator die Datenbank mit dem Schema für Anwendungsdaten füllen muss, muss ein Administrator das Messaging-System mit den Kanälen konfigurieren, die die Kommunikationswege zwischen den Anwendungen definieren. Das Messaging-System koordiniert und verwaltet das Senden und Empfangen von Nachrichten. Der primäre Zweck einer Datenbank ist es, sicherzustellen, dass jeder Datensatz sicher beibehalten wird, und ebenso die Hauptaufgabe eines Nachrichtensystems ist es, Nachrichten von dem Absender-Computer zu dem Empfänger-Computer in einer zuverlässigen Weise zu verschieben. Der Grund, weshalb ein Messaging-System benötigt wird, um Nachrichten von einem Computer zu einem anderen zu verschieben, ist, dass Computer und Netzwerke, die sie verbinden, inhärent unzuverlässig sind. Nur weil eine Anwendung bereit ist, eine Kommunikation zu senden, bedeutet das nicht, dass die andere Anwendung bereit ist, sie zu empfangen. Selbst wenn beide Anwendungen bereit sind, funktioniert das Netzwerk möglicherweise nicht oder kann die Daten nicht ordnungsgemäß übertragen. Ein Messaging-System überwindet diese Einschränkungen, indem es wiederholt versucht, die Nachricht zu übertragen, bis es erfolgreich ist. Unter idealen Umständen wird die Nachricht beim ersten Versuch erfolgreich übertragen, aber die Umstände sind oft nicht ideal. Im Wesentlichen wird eine Nachricht in fünf Schritten übertragen: Erstellen Der Absender erstellt die Nachricht und füllt sie mit Daten. Senden Der Absender fügt die Nachricht zu einem Kanal hinzu. Deliver Das Messaging-System verschiebt die Nachricht vom Absendercomputer zum Empfängercomputer und stellt sie dem Empfänger zur Verfügung. Empfangen Der Empfänger liest die Nachricht aus dem Kanal. Prozess Der Empfänger extrahiert die Daten aus der Nachricht. Dieses Diagramm veranschaulicht diese fünf Übertragungsschritte, die jeder Computer ausführt und welche Schritte das Messaging-System ausführen: Nachrichtenübertragung Schritt für Schritt Dieses Diagramm veranschaulicht auch zwei wichtige Messaging-Konzepte: Senden und vergessen In Schritt 2 sendet die sendende Anwendung die Nachricht Auf den Nachrichtenkanal. Sobald das Senden abgeschlossen ist, kann der Absender zu anderen Arbeiten weiterleiten, während das Nachrichtenübermittlungssystem die Nachricht im Hintergrund überträgt. Der Absender kann sicher sein, dass der Empfänger schließlich die Nachricht erhält und nicht warten muss, bis das passiert. Speichern und Weiterleiten In Schritt 2 speichert das Nachrichtenübermittlungssystem, wenn die sendende Anwendung die Nachricht an den Nachrichtenkanal sendet, die Nachricht auf dem Absender-Computer, entweder im Speicher oder auf der Festplatte. In Schritt 3 liefert das Nachrichtenübermittlungssystem die Nachricht, indem es es von dem Absender-Computer an den Empfänger-Computer weiterleitet und dann die Nachricht erneut auf dem Empfangsrechner speichert. Dieser Vorgang zum Speichern und Weiterleiten kann viele Male wiederholt werden, da die Nachricht von einem Computer zu einem anderen verschoben wird, bis er den Empfängercomputer erreicht. Die Schritte zum Erstellen, Senden, Empfangen und Verarbeiten können wie unnötiger Overhead erscheinen. Warum nicht einfach die Daten an den Empfänger liefern Durch das Umhüllen der Daten als Nachricht und das Speichern in dem Nachrichtensystem delegieren die Anwendungen dem Messaging-System die Verantwortung für die Bereitstellung der Daten. Da die Daten als atomare Nachricht gewickelt werden, kann die Zustellung wiederholt werden, bis sie erfolgreich ist, und dem Empfänger kann sichergestellt werden, dass er genau eine Kopie der Daten zuverlässig empfängt. Warum Messaging verwenden Nun, da wir wissen, was Messaging ist, sollten wir fragen: Warum Messaging verwenden Wie bei jeder anspruchsvollen Lösung gibt es keine einfache Antwort. Die schnelle Antwort ist, dass Messaging ist unmittelbarer als File Transfer. Besser gekapselt als Shared Database. Und zuverlässiger als Remote Procedure Invocation. Allerdings ist das nur der Anfang der Vorteile, die mit Messaging gewonnen werden können. Spezielle Vorteile von Messaging sind: Remote Communication. Mit Messaging können einzelne Anwendungen kommunizieren und Daten übertragen. Zwei Objekte, die sich im selben Prozess befinden, können einfach die gleichen Daten im Speicher gemeinsam nutzen. Das Senden von Daten an einen anderen Computer ist viel komplizierter und erfordert, dass Daten von einem Computer zu einem anderen kopiert werden. Dies bedeutet, dass Objekte serialisierbar sein müssen, d. h. sie können in einen einfachen Byte-Strom umgewandelt werden, der über das Netzwerk gesendet werden kann. Wenn keine Fernkommunikation erforderlich ist, ist keine Nachrichtenübermittlung erforderlich. Eine einfachere Lösung wie z. B. gleichzeitige Kollektionen oder gemeinsam genutzter Speicher ist ausreichend. PlattformLanguage Integration. Bei der Verbindung mehrerer Rechnersysteme über eine Fernkommunikation verwenden diese Systeme wahrscheinlich unterschiedliche Sprachen, Technologien und Plattformen, vielleicht weil sie im Laufe der Zeit von unabhängigen Teams entwickelt wurden. Die Integration derartiger divergierender Anwendungen kann eine entmilitarisierte Zone der Middleware erfordern, um zwischen den Anwendungen zu verhandeln, wobei häufig die kleinsten gemeinsamen Nenner verwendet werden, wie flache Datendateien mit obskuren Formaten. Unter diesen Umständen kann ein Messaging-System ein universeller Übersetzer zwischen den Anwendungen, die mit jeder Sprache und Plattform auf seine eigenen Begriffe arbeitet, dennoch ermöglicht es ihnen, alle durch ein gemeinsames Messaging-Paradigma zu kommunizieren. Diese universelle Konnektivität ist das Herzstück des Message-Bus-Musters. Asynchrone Kommunikation. Messaging ermöglicht einen Sende - und Forte-Ansatz für die Kommunikation. Der Absender muss nicht darauf warten, dass der Empfänger die Nachricht empfängt und verarbeitet, die er nicht einmal warten muss, bis das Nachrichtenübermittlungssystem die Nachricht liefert. Der Absender muss nur warten, bis die Nachricht gesendet wird, z. B. Damit die Nachricht erfolgreich in dem Kanal durch das Nachrichtensystem gespeichert werden kann. Sobald die Nachricht gespeichert ist, ist der Absender dann frei, andere Arbeiten durchzuführen, während die Nachricht im Hintergrund übertragen wird. Der Empfänger möchte möglicherweise eine Bestätigung oder ein Ergebnis zurück an den Absender senden, was eine weitere Nachricht erfordert, deren Lieferung durch einen Rückrufmechanismus auf dem Absender erkannt werden muss. Variable Zeitmessung. Bei synchroner Kommunikation muss der Anrufer warten, bis der Empfänger die Verarbeitung des Anrufs beendet hat, bevor der Anrufer das Ergebnis empfangen und fortfahren kann. Auf diese Weise kann der Anrufer nur Anrufe tätigen, so schnell der Empfänger sie ausführen kann. Andererseits ermöglicht die asynchrone Kommunikation dem Absender, Batch-Anfragen an den Empfänger in seinem eigenen Tempo abzufragen und für den Empfänger, um die Anfragen in seinem eigenen unterschiedlichen Tempo zu verbrauchen. Dies ermöglicht es, dass beide Anwendungen mit maximalem Durchsatz laufen und nicht aufeinander warten (zumindest bis der Empfänger keine Nachrichten mehr verarbeiten kann). Drosselung. Ein Problem bei Remoteprozeduraufrufen ist, dass zu viele von ihnen auf einem einzigen Empfänger zur gleichen Zeit den Empfänger überladen können. Dies kann zu Leistungsabfall und sogar zum Absturz des Empfängers führen. Die asynchrone Kommunikation ermöglicht es dem Empfänger, die Rate zu steuern, mit der er Anfragen verbraucht, so daß er nicht durch zu viele gleichzeitige Anforderungen überladen wird. Die durch diese Drosselung verursachte Beeinträchtigung der Anrufer wird minimiert, da die Kommunikation asynchron ist, so dass die Anrufer nicht blockiert werden und auf den Empfänger warten. Zuverlässige Kommunikation. Messaging bietet zuverlässige Lieferung, die ein Remoteprozeduraufruf (RPC) nicht möglich ist. Der Grund, warum Messaging zuverlässiger ist als RPC, ist, dass Messaging einen Store - und Forward-Ansatz zum Übertragen von Nachrichten verwendet. Die Daten werden als Nachrichten verpackt, die atomare, unabhängige Einheiten sind. Wenn der Absender eine Nachricht sendet, speichert das Nachrichtensystem die Nachricht. Sie liefert dann die Nachricht, indem sie sie an den Empfängercomputer weiterleitet, wo sie wieder gespeichert wird. Das Speichern der Nachricht auf dem Absender-Computer und dem Empfänger-Computer wird als zuverlässig angenommen. (Um es noch zuverlässiger zu machen, können die Nachrichten auf dem Datenträger gespeichert werden, anstatt des Speichers siehe Guaranteed Delivery.) Was unzuverlässig ist, ist die Weiterleitung (Verschieben) der Nachricht vom Absender-Computer zum Empfänger-Computer, da der Empfänger oder das Netzwerk nicht Ordnungsgemäß ausgeführt werden. Das Messaging-System überwindet dies, indem es die Nachricht erneut sendet, bis es erfolgreich ist. Diese automatische Wiederholung ermöglicht es dem Messaging-System, Probleme mit dem Netzwerk zu überwinden, so dass der Sender und der Empfänger sich nicht um diese Details kümmern müssen. Getrennter Betrieb. Einige Anwendungen sind speziell dafür konzipiert, dass sie nicht mit dem Netzwerk verbunden sind, sondern mit den Servern synchronisiert werden, wenn eine Netzwerkverbindung verfügbar ist. Solche Anwendungen werden auf Plattformen wie Laptop-Computern, PDAs und Automobil-Dashboards eingesetzt. Messaging ist ideal für die Aktivierung dieser Anwendungen synchronisiert werden, um synchronisiert werden können in der Warteschlange, wie es erstellt wird, warten, bis die Anwendung wieder mit dem Netzwerk verbunden. Vermittlung. Das Messaging-System fungiert als Mediatoras im Mediator-Muster GoF zwischen allen Programmen, die Nachrichten senden und empfangen können. Eine Anwendung kann sie als ein Verzeichnis für andere Anwendungen oder Dienste verwenden, die zur Integration verfügbar sind. Wenn eine Anwendung von den anderen getrennt wird, muss sie nur mit dem Messaging-System und nicht mit allen anderen Messaging-Anwendungen verbunden werden. Das Messaging-System kann verwendet werden, um eine hohe Anzahl von verteilten Verbindungen zu einer gemeinsam genutzten Ressource, wie beispielsweise einer Datenbank, bereitzustellen. Das Messaging-System kann redundante Ressourcen zur Verfügung stellen, um Hochverfügbarkeit bereitzustellen, die Last zu belasten, um ausgefallene Netzwerkverbindungen umzuleiten und Leistung und Servicequalität zu optimieren. Thread-Verwaltung. Asynchrone Kommunikation bedeutet, dass eine Anwendung nicht blockieren muss, während sie darauf wartet, dass eine andere Anwendung eine Aufgabe ausführt, es sei denn, sie will. Anstatt zu blockieren, um auf eine Antwort zu warten, kann der Anrufer einen Rückruf verwenden, der den Anrufer alarmiert, wenn die Antwort ankommt. (Siehe Muster Request-Reply.) Eine große Anzahl blockierter Threads oder Threads, die für eine lange Zeit blockiert sind, können problematisch sein. Zu viele blockierte Threads können die Anwendung mit zu wenigen verfügbaren Threads verlassen, um echte Arbeit durchzuführen. Wenn eine Anwendung mit einer dynamischen Anzahl von blockierten Threads abstürzt, wird die Wiederherstellung dieser Threads schwierig, wenn die Anwendung neu startet und ihren früheren Zustand wiederherstellt. Bei Callbacks sind die einzigen Threads, die blockieren, eine kleine, bekannte Anzahl von Hörern, die auf Antworten warten. Dies lässt die meisten Threads für andere Arbeiten zur Verfügung und definiert eine bekannte Anzahl von Listener-Threads, die nach einem Absturz leicht wiederhergestellt werden können. So gibt es eine Reihe von verschiedenen Gründen eine Anwendung oder Unternehmen können von Messaging profitieren. Einige davon sind technische Details, auf die sich Anwendungsentwickler am ehesten beziehen, während andere strategische Entscheidungen sind, die am besten mit Unternehmensarchitekten klingen. Welcher dieser Gründe am wichtigsten ist, hängt von den aktuellen Anforderungen Ihrer Anwendungen ab. Theyre alle guten Gründe, Messaging zu verwenden, also nutzen Sie aus, welche Gründe die meisten Nutzen für Sie zur Verfügung stellen. Herausforderungen der asynchronen Messaging Asynchrone Messaging ist nicht das Allheilmittel der Integration. Es löst viele der Herausforderungen der Integration von disparate Systeme auf elegante Weise, aber es stellt auch neue Herausforderungen. Einige dieser Herausforderungen sind dem asynchronen Modell innewohnend, während andere Herausforderungen mit der spezifischen Implementierung eines Messaging-Systems variieren. Komplexes Programmiermodell. Das asynchrone Messaging erfordert, dass Entwickler mit einem ereignisgesteuerten Programmiermodell arbeiten. Die Anwendungslogik kann nicht mehr in einer einzigen Methode codiert werden, die andere Methoden aufruft, sondern die Logik wird nun in eine Anzahl von Ereignishandlern aufgeteilt, die auf eingehende Nachrichten antworten. Ein solches System ist komplexer und schwieriger zu entwickeln und zu debuggen. Beispielsweise kann das Äquivalent eines einfachen Methodenaufrufs eine Anforderungsnachricht und einen Anforderungskanal, eine Antwortnachricht und einen Antwortkanal, eine Korrelationskennung und eine ungültige Nachrichtenwarteschlange (wie in der Anforderungsantwort beschrieben) erfordern. Sequenzprobleme. Nachrichtenkanäle garantieren eine Zustellung der Nachricht, aber sie garantieren nicht, wann die Nachricht geliefert wird. Dies kann dazu führen, dass Nachrichten, die in der Reihenfolge gesendet werden, um aus der Sequenz zu erhalten. In Situationen, in denen Nachrichten von einander abhängen, ist besondere Vorsicht geboten, um die Nachrichtensequenz wiederherzustellen. Synchrone Szenarien. Nicht alle Anwendungen können im Sende - und Forget-Modus betrieben werden. Wenn ein Benutzer nach Flugtickets sucht, wird er oder sie will den Ticketpreis sofort sehen, nicht nach einigen unbestimmten Zeit. Daher müssen viele Messaging-Systeme die Lücke zwischen synchronen und asynchronen Lösungen überbrücken. (Siehe Request-Reply-Muster.) Leistung. Messaging-Systeme fügen der Kommunikation etwas Overhead hinzu. Es nimmt Anstrengung, Daten in eine Mitteilung zu machen und sie zu senden, und eine Mitteilung zu empfangen und sie zu verarbeiten. Wenn Sie einen riesigen Teil der Daten transportieren müssen, können Sie es in eine gazillion kleine Stücke nicht eine intelligente Idee. Wenn beispielsweise eine Integrationslösung Informationen zwischen zwei vorhandenen Systemen synchronisieren muss, besteht der erste Schritt in der Regel darin, alle relevanten Informationen von einem System zum anderen zu replizieren. Für einen solchen Massendatenreplikationsschritt sind ETL-Tools (Extrahieren, Transformieren und Laden) viel effizienter als Messaging. Messaging eignet sich am besten, um die Systeme nach der ersten Datenreplikation synchron zu halten. Begrenzte Plattformunterstützung. Viele proprietäre Messaging-Systeme sind nicht auf allen Plattformen verfügbar. Oft ist es einfacher, FTP eine Datei auf eine andere Plattform als den Zugriff über ein Messaging-System. Lieferantensperre. Viele Messaging-System-Implementierungen beruhen auf proprietären Protokollen. Selbst gängige Messaging-Spezifikationen wie JMS steuern nicht die physikalische Implementierung der Lösung. Dies führt dazu, dass sich unterschiedliche Messaging-Systeme meist nicht miteinander verbinden. Dies kann Sie mit einer ganz neuen Integration Herausforderung: Integration von mehreren Integrationslösungen (Siehe die Messaging-Brücke Muster.) So asynchrone Messaging nicht alle Probleme lösen, und kann sogar einige neue. Behalten Sie diese Konsequenzen bei der Entscheidung, welche Probleme mit Messaging zu lösen. Thinking Asynchronous Messaging ist eine asynchrone Technologie, die es ermöglicht, dass die Zustellung wiederholt wird, bis sie erfolgreich ist. Im Gegensatz dazu verwenden die meisten Anwendungen synchrone Funktionsaufrufe zum Beispiel: eine Prozedur, die eine Unterprozedur aufruft, eine Methode, die eine andere Methode aufruft, oder eine Prozedur, die durch einen Remoteprozeduraufruf (RPC) (wie beispielsweise CORBA und DCOM) einen anderen aufruft. Synchrone Aufrufe bedeuten, dass der aufrufende Prozess angehalten wird, während der Unterprozess eine Funktion ausführt. Sogar in einem RPC-Szenario, bei dem die aufgerufene Subprozedur in einem anderen Prozess ausgeführt wird, blockiert der Aufrufer, bis die Unterprozedur die Steuerung (und die Ergebnisse) an den Aufrufer zurückgibt. Bei der Verwendung von asynchronem Messaging verwendet der Anrufer einen Sende - und Forte-Ansatz, der es weiterhin ausführen lässt, nachdem er die Nachricht gesendet hat. Daher läuft die Aufrufprozedur weiter, während die Unterprozedur aufgerufen wird. Synchrone und asynchrone Call-Semantik Die asynchrone Kommunikation hat eine Reihe von Implikationen. Erstens haben wir nicht mehr einen einzigen Thread der Ausführung. Mehrere Threads ermöglichen das gleichzeitige Ausführen von Subprozeduren, was die Performance erheblich verbessern kann und dazu beiträgt, dass einige Unterprozesse Fortschritte machen, während andere Subprozesse auf externe Ergebnisse warten können. Gleichzeitige Threads können aber auch das Debugging erheblich erschweren. Zweitens, Ergebnisse (falls vorhanden) kommen über einen Rückruf an. Dies ermöglicht es dem Anrufer, andere Aufgaben auszuführen und benachrichtigt zu werden, wenn das Ergebnis verfügbar ist, was die Leistung verbessern kann. Allerdings muss der Anrufer in der Lage sein, das Ergebnis selbst dann zu verarbeiten, wenn es sich inmitten anderer Aufgaben befindet, und es muss in der Lage sein, das Ergebnis zu verwenden, um sich an den Kontext zu erinnern, in dem der Anruf gemacht wurde. Drittens können asynchrone Subprozesse in beliebiger Reihenfolge ausgeführt werden. Dies wiederum ermöglicht eine Sub-Prozedur, um Fortschritte zu machen, auch wenn eine andere nicht. Aber es bedeutet auch, dass die Teilprozesse unabhängig voneinander in beliebiger Reihenfolge laufen können, und der Aufrufer muss feststellen können, welches Ergebnis aus welchem Teilprozess stammt und die Ergebnisse zusammen kombiniert. So hat die asynchrone Kommunikation mehrere Vorteile, erfordert jedoch ein Überdenken, wie ein Verfahren seine Unterprozeduren verwendet. Verteilte Anwendungen vs. Integration In diesem Buch geht es um Enterprise Integration, um unabhängige Anwendungen zu integrieren, damit sie zusammenarbeiten können. Eine Enterprise-Anwendung enthält häufig eine n-tier-Architektur (eine komplexere Version einer Client-Server-Architektur), die es ermöglicht, auf mehrere Computer verteilt zu werden. Obwohl dies zu Prozessen auf verschiedenen Maschinen führt, die miteinander kommunizieren, ist dies die Anwendungsverteilung, nicht die Anwendungsintegration. Warum ist eine n-Tier-Architektur als Anwendungsverteilung und nicht als Anwendungsintegration betrachtet? Zuerst werden die kommunizierenden Teile eng miteinander gekoppelt, da sie direkt von einander abhängig sind, so dass eine Stufe nicht ohne die anderen funktionieren kann. Zweitens neigt die Kommunikation zwischen den Ebenen dazu, synchron zu sein. Drittens neigt eine Anwendung (n-tier oder atomar) dazu, menschliche Benutzer zu haben, die nur eine schnelle Systemantwort akzeptieren werden. Im Gegensatz dazu sind integrierte Anwendungen unabhängige Anwendungen, die jeweils von selbst ausgeführt werden können, aber koordiniert miteinander lose gekoppelt sind. Dies ermöglicht es jeder Anwendung, sich auf einen umfassenden Satz von Funktionalität zu konzentrieren und dennoch an andere Anwendungen für verwandte Funktionalität zu delegieren. Integrierte Anwendungen, die asynchron kommunizieren, müssen nicht auf eine Antwort warten, die ohne eine Antwort fortfahren oder andere Aufgaben gleichzeitig ausführen können, bis die Antwort verfügbar ist. Integrierte Anwendungen neigen dazu, eine breite Zeiteinschränkung zu haben, so dass sie an anderen Aufgaben arbeiten können, bis ein Ergebnis verfügbar wird, und sind daher geduldiger als die meisten menschlichen Benutzer, die in Echtzeit auf ein Ergebnis warten. Kommerzielle Messaging-Systeme Die offensichtlichen Vorteile der Integration von Systemen, die eine asynchrone Messaging-Lösung nutzen, eröffnen einen bedeutenden Markt für Softwarehersteller, die Messaging-Middleware und zugehörige Tools erstellen. Wir können grob Gruppe der Messaging-Anbieter Produkte in die folgenden vier Kategorien: Betriebssysteme. Messaging ist zu einem derartigen gemeinsamen Bedarf geworden, dass Anbieter begonnen haben, die notwendige Software-Infrastruktur in das Betriebssystem oder die Datenbank-Plattform zu integrieren. Zum Beispiel enthalten die Microsoft Windows 2000 und Windows XP-Betriebssysteme die Microsoft Message Queuing (MSMQ) - Service-Software. Dieser Dienst ist über eine Reihe von APIs, einschließlich COM-Komponenten und dem System. Messaging-Namespace, Teil der Microsoft. NET-Plattform, verfügbar. Ebenso bietet Oracle Oracle AQ als Teil seiner Datenbank-Plattform. Anwendungsserver. Sun Microsystems integrierte zunächst den Java Messaging Service (JMS) in die Version 1.2 der J2EE-Spezifikation. Seitdem bieten praktisch alle J2EE-Anwendungsserver (wie IBM WebSphere, BEA WebLogic, etc.) eine Implementierung für diese Spezifikation. Außerdem liefert Sun eine JMS-Referenzimplementierung mit dem J2EE JDK. EAI Suites Gästebewertungen. Produkte von diesen Anbietern bieten proprietäre aber funktionelle Richsuite, die Messaging, Business Process Automation, Workflow, Portale und andere Funktionen umfassen. Key-Player auf diesem Markt sind IBM WebSphere MQ, Microsoft BizTalk, TIBCO, WebMethods, SeeBeyond, Vitria, CrossWorlds und andere. Viele dieser Produkte umfassen JMS als eine der vielen Client-APIs, die sie unterstützen, während andere Anbieter wie SonicSoftware und Fioranofocus in erster Linie auf die Implementierung von JMS-konformen Messaging-Infrastrukturen. Web-Service-Toolkits. Web-Services haben ein großes Interesse an der Enterprise Integration Communities gewonnen. Normungsgremien und Konsortien arbeiten aktiv an der Standardisierung einer zuverlässigen Nachrichtenübermittlung über Webdienste (d. h. WS-Reliability, WS-ReliableMessaging und ebMS). Eine wachsende Zahl von Anbietern bietet Tools, die Routing, Transformation und Verwaltung von Web Services-basierten Lösungen implementieren. Die Muster in diesem Buch sind herstellerunabhängig und gelten für die meisten Messaging-Lösungen. Leider neigt jeder Anbieter dazu, seine eigene Terminologie zu definieren, wenn er Messaging-Lösungen beschreibt. In diesem Buch haben wir uns bemüht, Musternamen zu wählen, die technologie - und produktneutral sind, aber beschreibend und einfach zu handhaben sind. Viele Messaging-Anbieter haben einige dieser Buchmuster als Merkmale ihrer Produkte integriert, was die Anwendung der Muster vereinfacht und die Lösungsentwicklung beschleunigt. Leser, die mit einer bestimmten Anbieter-Terminologie vertraut sind, werden wahrscheinlich viele der Konzepte in diesem Buch erkennen. Damit diese Leser die Pattern-Sprache der herstellerspezifischen Terminologie zuordnen, werden in den folgenden Tabellen die häufigsten Pattern-Namen zu den entsprechenden Produkt-Feature-Namen in einigen der am häufigsten verwendeten Messaging-Produkte abgebildet. Enterprise Integration Patterns Java Message Service (JMS) Musterform Dieses Buch ist als eine Reihe von Mustern in einer Mustersprache organisiert. Bücher wie Design Patterns. Musterorientierte Softwarearchitektur. Kern-J2EE-Muster. Und Patterns der Enterprise-Anwendungsarchitektur haben das Konzept der Verwendung von Mustern zur Dokumentation von Computerprogrammierungstechniken populär gemacht. Christopher Alexander pionierte das Konzept von Mustern und Mustersprachen in seinen Büchern A Pattern Language und A Timeless Way of Building. Jedes Muster stellt eine Entscheidung dar, die der Leser treffen muss und die Überlegungen, die in diese Entscheidung fallen. Eine Mustersprache ist ein Netz verwandter Muster, wobei jedes Muster zu anderen führt und den Leser durch den Entscheidungsprozess leitet. Dieser Ansatz ist eine leistungsfähige Methode, um Fachwissen zu dokumentieren, damit es von Nicht-Experten gut verstanden und angewandt werden kann. Eine Mustersprache lehrt den Leser, wie man eine grenzenlose Vielfalt von Problemen innerhalb eines beschränkten Problemraums lösen kann. Weil das Gesamtproblem, das gelöst wird, jedes Mal unterschiedlich ist, ist der Weg durch die Muster und wie sie angewendet werden, auch einzigartig. Auf diese Weise wurde dieses Buch für alle, die Messaging-Tools für jede Anwendung geschrieben, aber kann speziell für Sie und die spezifische Anwendung von Messaging angewendet werden, die Sie konfrontiert sind geschrieben. Nur mit dem Muster Form nicht garantieren, dass ein Buch enthält eine Fülle von Wissen. Es ist nicht nur genug, um einfach sagen, wenn Sie dieses Problem, wenden Sie diese Lösung. Für einen Leser, wirklich aus einem Muster zu lernen, muss es dokumentieren, warum das Problem schwer zu lösen ist, betrachten mögliche Lösungen, die in der Tat nicht gut funktionieren, und erklären, warum die angebotene Lösung ist die beste Verfügung. Ebenso müssen die Muster miteinander verbunden werden, um den Leser von einem Problem zum nächsten zu gehen. Auf diese Weise kann die Musterform verwendet werden, um den Leser nicht nur zu vermitteln, welche Lösungen anzuwenden sind, sondern wie man Probleme lösen kann, die der Autor nicht voraussagen konnte. Das sind Ziele, die wir in diesem Buch anstreben. Muster sollten präskriptiv sein, was bedeutet, dass sie Ihnen sagen sollten, was zu tun ist. Sie beschreiben nicht gerade ein Problem, und sie beschreiben nicht gerade, wie man es löst, sie erklären dir, was zu tun ist, um es zu lösen. Jedes Muster stellt eine Entscheidung dar, die der Leser machen muss: Sollte ich Messaging verwenden, würde mir hier eine Antwortnachricht helfen Der Punkt der Muster und die Mustersprache ist, dem Leser zu helfen, Entscheidungen zu treffen, die zu einer guten Lösung für sein spezifisches Problem führen, auch wenn Die Autoren haben nicht, dass spezifische Problem im Auge, und auch wenn der Leser nicht das Wissen und die Erfahrung, um diese Lösung auf eigene Faust zu entwickeln. Es gibt keine universelle Musterform verschiedene Bücher verwenden verschiedene Strukturen. Wir verwendeten einen Stil, der ziemlich nah an der alexandrinischen Form liegt, die zuerst für die Computerprogrammierung in Smalltalk Best Practice Patterns von Kent Beck populär wurde. Wir mögen die alexandrinische Form, weil sie zu Mustern führt, die prosaischer sind. Infolgedessen vermeidet das Format, obwohl jedes Muster einer identischen, wohldefinierten Struktur folgt, Überschriften für jeden einzelnen Unterabschnitt, die den Ablauf der Diskussion stören. Um die Navigierbarkeit zu verbessern, verwendet das Format Stilelemente wie Binden, Einkerben und Bilder, um dem Leser dabei zu helfen, wichtige Abschnitte auch auf einen Blick zu identifizieren. Diese Mustersprache verwendet die folgende Musterstruktur: Name Dies ist ein Bezeichner für das Muster, das angibt, was das Muster tut. Wir wählten Namen, die leicht in einem Satz verwendet werden können, der die Anwendung des Musters beschreibt, so dass es leicht ist, das Musterkonzept in einer Konversation zwischen Designern zu verweisen. Symbol Viele Muster sind zusätzlich zu dem Namen des Musters mit einem Symbol verknüpft. Weil viele Architekten dazu verwendet werden, visuell mit Hilfe von Diagrammen zu kommunizieren, wollten wir zusätzlich zur verbalen Sprache eine visuelle Sprache liefern. Diese visuelle Sprache unterstreicht die Komponierbarkeit der Muster, da mehrere Muster-Icons kombiniert werden können, um die Lösung eines größeren, komplexeren Musters zu beschreiben. Context This explains what you might be working on that would make you likely to run into the problem that this pattern solves. The context sets the stage for the problem and often refers to other patterns you may have already applied. Problem This explains the difficulty you are facing, expressed as a question youre asking yourself, which this pattern solves. You should be able to read the problem statement and quickly determine if this pattern is relevant to your work. Weve formatted the problem to be one sentence, bold and indented. Forces The forces explore the constraints that make the problem difficult to solve. If it were easy, you wouldnt need a pattern. They often consider alternative solutions that seem promising but dont pan out, which helps show the value of the real solution. Solution This is a template that explains what you should do to solve the problem. It is not specific to your particular circumstances, but describes what to do in the variety of circumstances represented by the problem. If you understand a patterns problem and solution, you understand the pattern and dont necessarily need to read the other sections. Weve formatted the solution to be one sentence, bold and indented. Sketch One of the most appealing properties of the Alexandrian form is that each pattern contains a sketch that illustrates the solution. In many cases, just by looking at the pattern name and the sketch you can understand the essence of the pattern. We tried to maintain this style by inserting a solution picture, or sketch, after the solution statement of each pattern. Results This part expands upon the solution to explain the details of how to apply the solution and how it resolves the forces. It also addresses new challenges that may arise as a result of applying this pattern. Next This section lists other patterns to be considered after applying the current one. Patterns dont live in isolation the application of one pattern usually leads you to new problems that are solved by other patterns. This is what makes the collection a pattern language and not just a pattern catalog. Sidebars These sections discuss more detailed technical issues or variations of the pattern. We set these sections visually apart from the remainder of the text so you can easily skip them if they are not be relevant to your particular application of the pattern. Examples A pattern usually includes one or more examples of the pattern being applied or having been applied. An example may be as simple as naming a known use or as detailed as a large segment of sample code. Given the large number of available messaging technologies, we do not expect readers to be familiar with each technology used to implement an example. Therefore, we designed the patterns so that you can safely skip the example without loosing any critical content of the pattern. The beauty in describing solutions as patterns is that it not only teaches the reader how to solve the specific problems discussed, but also how to create designs that solve problems the authors were not even aware of. As a result, these patterns for messaging describe not only messaging systems that exist today, but may also apply to new ones created well after this book is published. Diagram Notation Integration solutions consist of many different piecesapplications, databases, endpoints, channels, messages, routers, etc. If we want to describe an integration solution, we need to define a notation that accommodates all these different components. To our knowledge, there is no widely used, comprehensive notation that is geared towards the description of all aspects of an integration solution. The Unified Modeling Language (UML) does a fine job of describing object-oriented systems with class and interaction diagrams, but it does not contain semantics to describe messaging solutions. The UML Profile for EAI UMLEAI enriches the semantics of collaboration diagrams to describe message flows between components. This notation is very useful as a precise visual description of a system that can serve as the basis for code generation as part of a model-driven architecture (MDA). We decided not to adopt this notation for two reasons. First, the UML Profile does not capture all the patterns described in our pattern language. Second, we were not looking to create a precise visual specification, but images that have a certain sketch quality to them. We wanted pictures that are able to convey the essence of a pattern to the reader at a quick glancevery much like Alexanders sketch . Thats why we decided to create our own notation. Luckily, unlike the more formal notation, ours does not require you to read a large manual. A simple picture should suffice: Visual Notation for Messaging Solutions This simple picture shows a message being sent to a component over a channel. We use the word component very loosely hereit can indicate an application that is being integrated, an intermediary that transforms or routes the message between applications, or a specific part of an application. Sometimes, we also depict a channel as a three-dimensional pipe if we want to highlight the channel itself. Often times we are more interested in the components and draw the channels as simple lines with arrow heads. The two notations are equivalent. We depict the message as a small tree with a round root and nested, square elements. The tree elements can be shaded or colored to highlight their usage in a particular pattern. Many messaging systems allow messages to contain tree-like data structures, for example XML documents. Also, depicting messages in this way allows us to provide a quick visual description of transformation patternsit will be easy to show a pattern that adds, re-arranges or removes fields from the message. When we describe application designsfor example, messaging endpoints or examples written in C or Javawe do use standard UML class and sequence diagrams to depict the class hierarchy and the interaction between objects. The UML notation is widely accepted as the standard way of describing these types of solutions (if you need a refresher on UML, have a look at UML ). Examples and Interludes We have tried to underline the broad applicability of the patterns by including implementation examples using a variety of integration technologies. The potential downside of this approach is that you may not be familiar with each technology that is being used in an example. Thats why we made sure that reading the examples is strictly optional all relevant points are discussed in the pattern description. Therefore, you can safely skip the examples without risk of losing out on important detail. Also, where possible, we provided more than one implementation example using different technologies. When presenting example code we focused on readability over runnability. A code segment can help remove any potential ambiguity left by the solution description and many application developers and architects prefer looking at 30 lines of code as opposed to reading many paragraphs of text. To support this intent we often only show the most relevant methods or classes of a potentially larger solution. We also omitted most forms of error checking to highlight the core function implemented by the code. Most code snippets do not contain in-line comments as the code is explained in the paragraphs before and after the code segment. Providing a meaningful example for a single integration pattern is challenging. Enterprise integration solutions typically consist of a number of heterogeneous components, spread across multiple systems. Likewise, most integration patterns do not operate in isolation but rely on other patterns to form a meaningful solution. To highlight the collaboration between multiple patterns we included more comprehensive examples as interludes at the end of the major sections of the book. These solutions illustrate many of the trade-offs involved in designing a more comprehensive messaging solution. All code samples should be treated as illustrative tools only and not as a starting point for development of an integration solution. For example, almost all examples lack any form of error checking or concern for robustness, security, or scalability. We tried as much as possible to base the examples on software platforms that are available free of charge or as a trial version. In some cases, we used commercial platforms (such as TIBCO ActiveEnterprise or Microsoft BizTalk) to illustrate the difference between developing a solution from scratch and using a commercial tool. We presented those example in such a way that they are educational even if you do not have access to the required run-time platform. For many examples, we use relatively bare-bones messaging frameworks such as JMS or MSMQ. This allows us to be more explicit in the example and focus on the problem at hand instead of distracting from it with all the features a more complex middleware toolset may provide. The Java examples in this book are based on the JMS 1.1 specification, which is part of the J2EE 1.4 specification. By the time this book is published, most messaging and application server vendors will support JMS 1.1. You can download Suns reference implementation of the JMS specification from Suns Web site: java. sunj2ee . The Microsoft. NET examples are based on Version 1.1 of the. NET Framework and are written in C. You can download the. NET Framework SDK from Microsofts Web site: msdn. microsoftnet . Organization of this Book The pattern language in this book, as with any pattern language, is a web of patterns referring to each other. At the same time, some patterns are more fundamental than others, forming a hierarchy of big-concept patterns that lead to finer-detailed patterns. The big-concept patterns form the load-baring members of the pattern language. They are the main ones, what we term root patterns . that provide the foundation of the language and support the other patterns. This book groups patterns into chapters by level-of-abstraction and by topic area. The following diagram shows the root patterns and their relationship to the chapters of the book. Relationship of Root Patterns and Chapters The most fundamental pattern is Messaging thats what this whole book is about. It leads to the six root patternswhich are in the Messaging Systems chapternamely Message Channel . Message . Pipes and Filters . Message Router . Message Translator . and Message Endpoint . In turn, each of these root patterns leads to its own chapter in the book (except Pipes and Filters . which is not specific to messaging but is the basis of the routing and transformation patterns). The pattern language is divided into eight chapters, which follow the hierarchy described above: Chapter 1: Integration Styles This chapter reviews the different approaches available for integrating applications, including Messaging . Chapter 2: Messaging Systems This chapter reviews the six root messaging patterns, giving an overview of the entire pattern language. Chapter 3: Messaging Channels Applications communicate via channels. Channels define the logical pathways a message can follow. This chapter shows how to determine what channels your applications need. Chapter 4: Message Construction Once you have message channels, you need messages to send on them. This chapter explains the different ways messages can be used and how to take advantage of their special properties. Chapter 5: Message Routing As a messaging topography becomes more complex, senders know less and less about who should receive their messages. Rather, they send the messages to intermediate applications that send them to others until the messages finally find their way to their final destination. This chapter teaches you the responsibilities of these routing applications. Chapter 6: Message Transformation Independently developed applications often dont agree on messages formats, on the form and meaning of supposedly unique identifiers, and even the character encoding to be used. Therefore, intermediate components are needed to convert messages from the form one application produced to that which other applications will consume. This chapter shows how to design these transformer applications. Chapter 7: Messaging Endpoints Many applications were not designed to participate in a messaging solution. As a result, they must be explicitly connected to the messaging system. This section describes a messaging layer in the applications that is responsible for sending and receiving the messages, making your application an endpoint for messages. Chapter 8: System Management Once we have a messaging system in place to integrate our applications, how do we make sure that its running correctly and doing what we want This chapter explores how to test and monitor a running messaging system. These eight chapters go together to teach you what you need to know about connecting applications using messaging. Getting Started With any book that has a lot to teach, its hard to know where to start, both for the authors and the readers. Reading all of the pages straight through assures covering the entire subject area, but isnt the quickest way to get to the issues that are of the most help. Starting with a pattern in the middle of the language can be like starting to watch a movie thats half over you see whats happening but dont understand what it means. Luckily, the pattern language is formed around root patterns (as described earlier). These root patterns collectively provide an overview of the pattern language, and individually provide starting points for delving deep into the details of messaging. To get an overall survey of the language without reviewing all of the patterns, start with reviewing the root patterns. To jump into the middle of the language, jump in at a root pattern, a place where the language has finished discussing one major topic and is now starting another. Chapter 1: Integration Styles provides an overview of the four main application integration techniques and settles on Messaging as being the best overall for many integration opportunities. Read this chapter if you are unfamiliar with issues involved in application integration and the pros and cons of the various approaches that are available. If you just want to know whats so great about messaging, go straight to that pattern. If youre already convinced that messaging is the way to go and want to get started with how to use messaging, you can skip the first chapter completely. Chapter 2: Messaging Systems contains all of this pattern languages root patterns (except Messaging . which is in the first chapter). For an overview of the pattern language, read (or at least skim) all of the patterns in this chapter. To dive deep on a particular topic, read its root pattern, then go to the patterns mentioned in its next section at the end of the pattern those next patterns will all be in a chapter named after the root pattern. The root patterns in this language are: Messaging This is the 1 root pattern for the entire book: What is messaging, what problem does it solve, and how does it solve it Message Channel What is the structure in a messaging system that conveys messages from the sender to the receiver How do you know which ones your applications need Message How does information get communicated from a sender to a receiver Pipes and Filters How can intermediate steps be performed after a message is sent but before it is received Message Router If the sender does not know ultimately where the message should go, how can the messaging system get it there Message Translator If the sender and receiver do not agree on the message format, how can they communicate Message Endpoint How do the applications that send and receive messages connect to the messaging system After the first two chapters, different types of messaging developers may be most interested in different chapters, based on the specifics of how each group uses messaging to perform integration: System Administrators may be most interested in Chapter 3: Messaging Channels . the guidelines for what channels to create, and Chapter 8: System Management . guidance on how to maintain a running messaging system. Application Developers should look at Chapter 7: Messaging Endpoints to learn how integrate an application with a messaging system, and Chapter 4: Message Construction to learn what messages to send when. System Integrators will gain the most from Chapter 5: Message Routing how to direct messages to the proper receiversand Chapter 6: Message Transformation how to convert messages from the senders format to the receivers. Keep in mind that when reading a pattern, if youre in a hurry, start by just reading the problem and solution (the two sentences in bold). This will give you enough information to determine if the pattern is of interest to you right now, and if you already know the pattern. If you do not know the pattern and it sounds interesting, go ahead and read the other parts. Also remember that this is a pattern language, so the patterns are not necessarily meant to be read in the order theyre presented in the book. The books order teaches you about messaging by considering all of the relevant topics in turn and discussing related issues together. To use the patterns to solve a particular problem, start with an appropriate root pattern. Its context explains what patterns need to be applied before this one, even if theyre not the ones immediately preceding this one in the book. Likewise, the next section (the last paragraph of the pattern) describes what patterns to consider applying after this one, even if theyre not the ones immediately following this one in the book. Use the web of interconnected patterns, not the linear list of book pages, to guide you through the material. Supporting Web Site Please look for companion information to this book plus related information on enterprise integration at our Web site: enterpriseintegrationpatterns. You can also e-mail your comments, suggestions and feedback to us at authorsenterpriseintegrationpatterns. You should now have a good understanding of the following concepts which are fundamental to the material in this book: What messaging is What a messaging system is Why to use messaging How asynchronous programming is different How application integration is different from application distribution What types of commercial products contain messaging systems You should also have a feel for how this book is going to teach you how to use messaging: The role patterns have in structuring the material The meaning of the custom notation used in the diagrams The purpose and scope of the examples The organization of the material How to get started learning the material Now that you understand the basic concepts and how the material will be presented, you are now ready to start learning how to integrate applications using messaging. Want to keep up-to-date Follow My Blog . Want to read more in depth Check out My Articles . Want to see me live See where I am speaking next . Find the full description of this pattern in: Enterprise Integration Patterns Gregor Hohpe and Bobby Woolf ISBN 0321200683 650 pages Addison-Wesley From Enterprise Integration to Enterprise Transformation: My new book describes how architects can play a critical role in IT transformation by applying their technical, communication, and organizational skills with 37 episodes from large-scale enterprise IT. Parts of this page are made available under the Creative Commons Attribution license. You can reuse the pattern icon, the pattern name, the problem and solution statements (in bold), and the sketch under this license. Other portions of the text, such as text chapters or the full pattern text, are protected by copyright.
No comments:
Post a Comment