Online Trading System Architektur

Messaging Patterns 187 Integrationsmuster in der Praxis 187 Fallstudie: Bond Trading System (von Jonathan Simon) Es ist leicht, sich von einer großen Sammlung von Mustern oder einer Mustersprache zu distanzieren. Muster sind die Abstraktion einer Idee in einer wiederverwendbaren Form. Oft macht die sehr generische Natur der Muster, die sie so nützlich macht auch sie schwer zu begreifen. Manchmal ist die beste Sache, um zu verstehen, Muster ist eine reale Welt Beispiel. Nicht ein erfundenes Szenario, was passieren könnte, sondern was tatsächlich passiert und was passieren wird. Dieses Kapitel verwendet Muster, um Probleme mit einem Ermittlungsprozess zu lösen. Das System, das wir diskutieren, ist ein Anleihehandelssystem, mit dem ich zwei Jahre lang von der ersten Planung bis zur Fertigung gearbeitet habe. Wir untersuchen Szenarien und Probleme, die angetroffen wurden und wie man sie mit Mustern lösen kann. Dies beinhaltet den Entscheidungsprozess der Auswahl eines Musters sowie die Kombination und Anpassung von Mustern an die Bedürfnisse des Systems. Und das alles unter Berücksichtigung der Kräfte, die in realen Systemen einschließlich Geschäftsanforderungen, Kundenentscheidungen, architektonische und technische Anforderungen, sowie Legacy-System-Integration. Die Absicht dieses Ansatzes besteht darin, ein klareres Verständnis der Muster selbst durch praktische Anwendung zu schaffen. Aufbau eines Systems Eine große Investmentbank der Wall Street setzt sich für die Schaffung eines Anleihenpreissystems ein, um den Workflow ihrer Anleihenhandelsplattform zu rationalisieren. Derzeit müssen die Anleihenhändler die Preise für eine große Anzahl von Anleihen an mehrere verschiedene Handelsplätze senden, jeweils mit einer eigenen Benutzeroberfläche. Das Ziel des Systems ist die Minimierung der Minutien der Preisbildung aller ihrer Anleihen kombiniert mit fortschrittlichen analytischen Funktionalität spezifisch für den Anleihemarkt in einer einzigen gekapselte Benutzeroberfläche. Das bedeutet Integration und Kommunikation mit mehreren Komponenten über verschiedene Kommunikationsprotokolle. Der High Level Flow des Systems sieht so aus: Zuerst kommen Marktdaten ins System. Marktdaten sind Daten über den Preis und andere Eigenschaften der Anleihe, die repräsentieren, was die Leute bereit sind, die Anleihe für den freien Markt zu kaufen und zu verkaufen. Die Marktdaten werden sofort an die Analytik-Engine gesendet, die die Daten verändert. Analytics bezieht sich auf mathematische Funktionen für Finanzanwendungen, die die Preise und andere Attribute von Anleihen verändern. Dies sind generische Funktionen, die Eingangsvariablen verwenden, um die Ergebnisse der Funktion an eine bestimmte Bindung anzupassen. Die Client-Anwendung, die auf jedem Trader-Desktop ausgeführt wird, konfiguriert die Analytics-Engine auf einer pro Trader-Basis und steuert die Besonderheiten der Analytics für jede Bindung, die der Trader kalkuliert. Sobald die Analytik auf die Marktdaten angewendet wird, werden die geänderten Daten an verschiedene Handelsplätze verschickt, in denen Händler von anderen Firmen die Anleihen kaufen oder verkaufen können. Architektur mit Patterns Mit diesem Überblick über den Workflow des Systems können wir auf einige der architektonischen Probleme eingehen, denen wir während des Designprozesses begegnen. Werfen wir einen Blick auf was wir bis jetzt wissen. Händler benötigen eine sehr ansprechende Anwendung auf Windows NT - und Solaris-Workstations. Daher haben wir uns entschlossen, die Client-Anwendung als Java-Dick-Client zu implementieren, weil es unabhängig von seiner Plattform ist und schnell auf User-Input - und Marktdaten reagieren kann. Auf der Serverseite sind wir erben Legacy-C-Komponenten, die unser System nutzen wird. Die Marktdatenkomponenten kommunizieren mit der TIB-Messaging-Infrastruktur. Wir erben die folgenden Komponenten: Market Data Price Feed Server. Publiziert eingehende Marktdaten an die TIB. Analytics Engine. Führt Analysen zu eingehenden Marktdaten durch und überträgt die geänderten Marktdaten an die TIB. Beitragsserver. Führt alle Kommunikation mit Handelsplätzen durch. Die Handelsplätze sind Drittkomponenten, die nicht von der Bank kontrolliert werden. Legacy Market Data Subsystem Legacy Contribution Subsystem Wir müssen entscheiden, wie die einzelnen Subsysteme (Java dicken Client, Marktdaten und Beitrag) zu kommunizieren. Wir könnten den dicken Client direkt mit den Legacy-Servern kommunizieren, aber das würde zu viel Business-Logik auf dem Client erfordern. Stattdessen bauen Sie gut ein Paar Java-Gateways, um mit den Legacy-Servern zu kommunizieren. Das Pricing Gateway für Marktdaten ist ein Contribution Gateway zum Senden von Preisen an Handelsplätze. Dies wird eine gute Kapselung der Geschäftslogik in Bezug auf diese Bereiche zu erreichen. Die aktuellen Komponenten im System sind unten dargestellt. Die Verbindungen, die als gekennzeichnet sind. Zeigen, dass wir noch nicht sicher sind, wie einige der Komponenten kommunizieren werden. Das System und seine Komponenten Die erste Frage der Kommunikation ist, wie der Java-Dick-Client und die beiden Java-Server-Komponenten zu integrieren, um Daten auszutauschen. Lets Blick auf die vier Integrationsarten, die in diesem Buch vorgeschlagen werden: File Transfer. Gemeinsame Datenbank. Remoteprozeduraufruf. Und Messaging. Wir können Shared Database sofort ausschließen, weil wir eine Schicht der Abstraktion zwischen dem Client und der Datenbank erstellen möchten und keinen Datenbankzugriffscode im Client haben möchten. File Transfer kann ähnlich ausgeschlossen werden, da minimale Latenzzeiten erforderlich sind, um sicherzustellen, dass aktuelle Preise an die Handelsplätze verschickt werden. So haben Sie die Wahl zwischen Remote Procedure Invocation oder Messaging. Die Java-Plattform bietet integrierte Unterstützung für Remote Procedure Invocation und Messaging. RPC-Stil Integration kann mit Remote Method Invocation (RMI), CORBA oder Enterprise Java Beans (EJB) erreicht werden. Der Java Messaging Service (JMS) ist die gemeinsame API für die Integration von Messaging-Stilen. So sind beide Integrationsstile in Java einfach zu implementieren. Also, die besser für dieses Projekt arbeiten, Remote Procedure Invocation oder Messaging. Es gibt nur eine Instanz des Pricing Gateways und eine Instanz des Contribution Gateways im System, aber meistens verbinden sich viele Thick Clients mit diesen Diensten (eine für jeden Bondhändler, der zu einer bestimmten Zeit angemeldet ist). Des Weiteren wäre die Bank ein generisches Preissystem, das in anderen Anwendungen genutzt werden kann. Neben einer unbekannten Anzahl von Think-Clients kann es eine unbekannte Anzahl anderer Anwendungen geben, die die aus den Gateways kommenden Preisdaten verwenden. Ein Thick-Client (oder eine andere Anwendung, die die Kalkulationsdaten verwendet) kann RPC ziemlich einfach verwenden, um Anrufe an die Gateways zu tätigen, um Preisdaten zu erhalten und die Verarbeitung aufzurufen. Allerdings werden die Preisdaten ständig veröffentlicht, und bestimmte Kunden sind nur an bestimmten Daten interessiert, so dass die relevanten Daten an die richtigen Kunden in einer fristgerechten Weise könnte schwierig sein. Die Clients könnten die Gateways abfragen, aber das wird eine Menge Overhead verursachen. Es wäre besser für die Gateways, die Daten den Kunden zur Verfügung zu stellen, sobald sie verfügbar sind. Dies erfordert jedoch jedes Gateway, um zu verfolgen, welche Clients momentan aktiv sind, und welche bestimmte Daten dann wünschen, wenn ein neues Datenelement verfügbar wird (was mehrmals pro Sekunde passieren wird), muss das Gateway machen Ein RPC an jeden interessierten Client, um die Daten an den Client zu übergeben. Idealerweise sollten alle Clients gleichzeitig benachrichtigt werden, so dass jeder RPC in einem eigenen gleichzeitigen Thread erstellt werden muss. Dies kann funktionieren, wird aber sehr schnell sehr kompliziert. Messaging vereinfacht dieses Problem erheblich. Mit Messaging. Können wir für die verschiedenen Arten von Preisdaten separate Kanäle definieren. Wenn dann ein Gateway ein neues Datenpaket erhält, fügt es eine Nachricht hinzu, die diese Daten dem Publish-Subscribe-Kanal für diesen Datentyp enthält. Unterdessen hören alle Klienten, die an einer bestimmten Art von Daten interessiert sind, auf dem Kanal für diesen Typ. Auf diese Weise können die Gateways problemlos neue Daten an jeden senden, der interessiert ist, ohne zu wissen, wie viele Höreranwendungen es gibt oder was sie sind. Die Clients müssen weiterhin in der Lage sein, Verhalten in den Gateways aufzurufen. Da es immer nur zwei Gateways gibt und der Client wahrscheinlich blockieren kann, während die Methode synchron aufgerufen wird, können diese Client-to-Gateway-Aufrufe ziemlich einfach mit RPC implementiert werden. Da wir jedoch bereits Messaging für die Gateway-to-Client-Kommunikation verwenden, sind Nachrichten wahrscheinlich genauso gut für die Implementierung von Client-zu-Gateway-Kommunikation. Daher wird die gesamte Kommunikation zwischen den Gateways und den Clients durch Messaging erreicht. Da alle Komponenten in Java geschrieben sind, bietet JMS eine einfache Auswahl für das Messaging-System. Dies schafft effektiv einen Message Bus oder eine Architektur, die es möglich macht, dass zukünftige Systeme mit dem aktuellen System mit wenig oder keiner Änderung an der Messaging-Infrastruktur integriert werden können. Auf diese Weise kann die Geschäftsfunktionalität der Anwendung leicht von anderen Anwendungen genutzt werden, die die Bank entwickelt. Java-Komponenten Die Kommunikation mit JMS JMS ist einfach eine Spezifikation und wir müssen uns für ein JMS-konformes Messaging-System entscheiden. Wir beschlossen, IBM MQSeries JMS zu verwenden, da die Bank ein IBM-Shop mit WebSphere-Anwendungsservern und vielen anderen IBM Produkten ist. Daher verwenden wir MQSeries, da wir bereits über eine Support-Infrastruktur verfügen und eine Site-Lizenz des Produkts besitzen. Die nächste Frage ist, wie das MQSeries-Messaging-System mit dem eigenständigen C-Contribution-Server und den TIBCO-basierten Market Data - und Analytics Engine-Servern verbunden wird. Wir brauchen eine Möglichkeit für die MQSeries-Konsumenten, Zugriff auf die TIB-Nachrichten zu haben. Aber wie könnten wir das Message Translator-Muster verwenden, um TIB-Nachrichten in MQSeries-Nachrichten zu übersetzen. Obwohl der C-Client für MQSeries als Message Translator dient. Mit es würde JMS Server Unabhängigkeit zu opfern. Und obwohl TIBCO eine Java API hat, haben der Kunde Architekt und Manager sie abgelehnt. Als Ergebnis muss der Message Translator Ansatz aufgegeben werden. Die Brücke vom TIB-Server zum MQSeries-Server benötigt die Kommunikation zwischen C und Java. Wir könnten CORBA verwenden, aber dann was über das Messaging Ein genauerer Blick auf das Message Translator-Muster zeigt, dass es mit dem Channel-Adapter in seiner Verwendung von Kommunikationsprotokollen verwandt ist. Das Herzstück eines Channel-Adapters besteht darin, Nicht-Messaging-Systeme mit Messaging-Systemen zu verbinden. Ein Paar von Kanaladaptern, die zwei Messaging-Systeme verbindet, ist eine Messaging Bridge. Der Zweck einer Messaging Bridge besteht darin, Nachrichten von einem Messagingsystem zu einem anderen zu übertragen. Genau das machen wir mit der zusätzlichen Komplexität der intra-sprachigen Java-to-C-Kommunikation. Wir können die Cross Language Messaging Bridge mit einer Kombination aus Channel Adapter und CORBA implementieren. Wir werden zwei leichte Channel-Adapter-Server aufbauen, einen in C, der die Kommunikation mit dem TIB verwaltet, und einen in Java, der die Kommunikation mit JMS verwaltet. Diese beiden Kanaladapter. Die Message Endpoint selbst sind, kommunizieren miteinander über CORBA. Wie unsere Wahl für MQSeries, verwenden wir CORBA anstatt JNI, da es ein Unternehmensstandard ist. Die Messaging-Bridge implementiert die effektiv simulierte Nachrichtenübersetzung zwischen scheinbar inkompatiblen Messaging-Systemen und verschiedenen Sprachen. Message Translator using Channel Adapters Das nächste Diagramm zeigt das aktuelle Systemdesign einschließlich der Gateways und anderer Komponenten. Dies ist ein gutes Beispiel für eine Musteranwendung. Wir kombinierten zwei Kanaladapter mit einem Nicht-Messaging-Protokoll, um das Message Translator-Muster zu implementieren, wobei effektiv ein Muster verwendet wurde, um ein anderes Muster zu implementieren. Darüber hinaus haben wir den Channel-Adapter-Kontext geändert, um zwei Messaging-Systeme mit einem Nicht-Messaging-Cross-Language-Übersetzungsprotokoll zu verknüpfen, anstatt ein Messaging-System mit einem Nicht-Messaging-System zu verbinden. Das aktuelle System mit den Kanaladaptern Strukturierung von Kanälen Ein Schlüssel zur Arbeit mit Mustern ist nicht nur zu wissen, wann, welches Muster zu verwenden, sondern auch, wie man am effektivsten verwenden. Bei jeder Musterimplementierung sind sowohl die Besonderheiten der Technologieplattform als auch andere Gestaltungskriterien zu berücksichtigen. Dieser Abschnitt wendet denselben Ermittlungsprozess an, um die effizienteste Verwendung des Publish-Subscribe-Kanals im Kontext des Marktdatenservers, der mit der Analytik-Engine kommuniziert, zu finden. Echtzeit-Marktdaten stammen aus dem Marktdaten-Feed, einem C-Server, der Marktdaten auf der TIB überträgt. Der Marktdaten-Feed verwendet für jede Anleihe, für die er die Preise veröffentlicht, einen eigenen Publish-Subscribe-Kanal. Dies mag ein wenig extremer erscheinen, da jede neue Bindung einen eigenen neuen Kanal braucht. Aber das ist nicht so schwer, da man eigentlich keine Kanäle in TIBCO erstellen muss. Vielmehr werden Kanäle durch einen hierarchischen Satz von Themennamen, die als Subjekte bezeichnet werden, referenziert. Der TIBCO-Server filtert dann einen einzelnen Nachrichtenfluss durch das Subjekt und sendet jedes einzelne Objekt einem einzigen virtuellen Kanal zu. Das Ergebnis ist ein sehr leichter Nachrichtenkanal. Wir könnten ein System erstellen, das auf wenigen Kanälen veröffentlicht wird, und Abonnenten können nur auf Preise zugreifen, für die sie interessiert sind. Dies würde es erforderlich machen, dass Abonnenten einen Message Filter oder Selective Consumer verwenden, um den gesamten Datenfluss auf interessante Anleihenpreise zu filtern Sollte so verarbeitet werden, wie sie eingegangen ist. Da die Marktdaten auf Bond-dedizierten Kanälen veröffentlicht werden, können sich Abonnenten für Updates auf einer Reihe von Anleihen anmelden. Dies ermöglicht es effektiv den Teilnehmern zu filtern, indem sie selektiv Kanäle abonniert und nur Aktualisierungen von Interesse empfängt, anstatt zu entscheiden, nachdem die Nachricht empfangen wurde. Es ist wichtig zu beachten, dass die Verwendung mehrerer Kanäle, um eine Filterung zu vermeiden, eine nicht standardmäßige Verwendung von Messaging-Kanälen ist. Im Kontext der TIBCO-Technologie entscheiden wir aber, ob wir Filter oder die in TIBCO eingebaute Kanalfilterung implementieren oder eigene Filter einsetzen müssen - und nicht, ob wir so viele Kanäle verwenden. Die nächste Komponente, die wir entwerfen müssen, ist die Analytik-Engine, ein weiterer CTIB-Server, der die Marktdaten modifiziert und an die TIB weitergibt. Obwohl es nicht im Rahmen unserer JavaJMS-Entwicklung liegt, arbeiten wir eng mit dem C-Team zusammen, um es zu entwerfen, da wir die Analytik-Motoren als primärer Kunde sind. Das Problem besteht darin, die Kanalstruktur zu finden, die die neu modifizierten Marktdaten am effizientesten wiedergibt. Da wir bereits einen dedizierten Message Channel pro Bindung aus dem Marktdaten-Preis-Feed geerbt haben, wäre es logisch, die Marktdaten zu modifizieren und die geänderten Marktdaten auf dem dedizierten Message Channel zu übertragen. Aber dies wird nicht funktionieren, da die Analytik Modifikation der Anleihen Preise sind Händler-spezifisch. Wenn wir die geänderten Daten auf dem Bond Message Channel erneut senden. Werden wir die Datenintegrität zerstören, indem wir generische Marktdaten durch handelspezifische Daten ersetzen. Auf der anderen Seite könnten wir einen anderen Nachrichtentyp für traderspezifische Marktdaten haben, die wir auf demselben Kanal veröffentlichen, sodass die Teilnehmer entscheiden können, an welche Nachricht sie interessiert sind, um die Datenintegrität nicht zu zerstören. Aber dann müssen Kunden ihre eigenen Filter implementieren, um Nachrichten für andere Händler zu trennen. Zusätzlich wird es eine erhebliche Zunahme der von den Teilnehmern empfangenen Nachrichten geben, was eine unnötige Belastung für sie bedeutet. Es gibt zwei Möglichkeiten: Ein Kanal pro Trader: Jeder Trader hat einen bestimmten Kanal für die geänderten Marktdaten. Auf diese Weise bleiben die ursprünglichen Marktdaten intakt und jede Traderanwendung kann auf ihre spezifischen Händler Nachrichtenkanal für die geänderten Preisaktualisierungen zu hören. Ein Channel pro Trader pro Bond: Erstellen Sie einen Message Channel pro Trader pro Bindung ausschließlich für die geänderten Marktdaten dieser Bonds. Zum Beispiel würden die Marktdaten für Anleihen ABC auf Channel Bond ABC veröffentlicht, während die geänderten Marktdaten für Trader A auf Message Channel Trader A, Bond ABC, geänderte Marktdaten für Trader B auf Trader B, Bond ABC und veröffentlicht werden würden bald. Ein Kanal pro Trader Ein Kanal pro Bond pro Trader Es gibt Vor-und Nachteile für jeden Ansatz. Der Pro-Bond-Ansatz verwendet beispielsweise viel mehr Nachrichtenkanal. Im schlimmsten Fall ist die Anzahl der Meldungskanäle die Anzahl der Anleihen insgesamt multipliziert mit der Anzahl der Händler. Wir können obere Schranken setzen auf die Anzahl der Kanäle, die erstellt werden, da wir wissen, dass es nur etwa 20 Händler und sie nie mehr als ein paar hundert Bonds. Damit liegt die obere Grenze unter dem 10.000er Bereich, der nicht so aussergewöhnlich ist, verglichen mit dem fast 100.000 Nachrichtenkanal, den der Marktdatenpreis-Feed verwendet. Auch, da wir die TIB und Message Channel sind ziemlich billig, die Anzahl der Message Channel s ist nicht ein schweres Problem. Andererseits könnte die schiere Anzahl von Nachrichtenkanälen ein Problem aus einer Managementperspektive sein. Jedes Mal, wenn eine Anleihe hinzugefügt wird, muss ein Kanal für jeden Trader gepflegt werden. Dies könnte in einem sehr dynamischen System schwerwiegend sein. Unser System ist jedoch im wesentlichen statisch. Es verfügt außerdem über eine Infrastruktur zur automatischen Verwaltung des Nachrichtenkanals. Dies kombiniert mit der ererbten Architektur einer Legacykomponente unter Verwendung eines ähnlichen Ansatzes minimiert den Nachteil. Dies ist nicht zu sagen, wir sollten eine unnötig übermäßige Anzahl von Message Channel s. Vielmehr können wir einen architektonischen Ansatz implementieren, der eine große Anzahl von Nachrichtenkanälen verwendet, wenn es einen Grund gibt. Und es gibt einen Grund, in diesem Fall kommt auf die Lage der Logik. Wenn wir den pro-Trader-Ansatz implementieren, benötigt die Analytics-Engine eine Logik, um Eingangs - und Ausgangskanäle zu gruppieren. Dies liegt daran, dass die Eingangskanäle der Analytics Engine pro Bond und der Output Message Channel s pro Trader sind und die Analytics Engine alle Analytics-Inputs von mehreren Bonds für einen bestimmten Trader an einen traderspezifischen Output Message Channel leiten muss. Dadurch wird die Analytik-Engine effektiv zu einem Content-Based Router, der eine benutzerdefinierte Routing-Logik für unsere Anwendung implementiert. Im Anschluss an die Message Bus Struktur ist die Analytics Engine ein generischer Server, der von mehreren anderen Systemen in der. Also wollen wir es nicht mit System-spezifische Funktionalität zu bewölken. Auf der anderen Seite, die Per-Bond-Ansatz funktioniert, da die Idee eines Händlers, die die Analytik Ausgabe der Anleihen Preise ist ein Unternehmen akzeptiert Praxis. Der Per-Bond-Ansatz hält die Nachrichtenkanal-Trennung des Marktdaten-Feeds intakt, während der Hinzufügen mehrerer Nachrichten-Kanal s. Bevor wir den Client erreichen, wollen wir einen Content-basierten Router, um diese verschiedenen Kanäle zu einer überschaubaren Anzahl von Kanälen zu kombinieren. Wir möchten nicht, dass die Clientanwendung auf dem Trader-Desktop auf Tausende oder Zehntausende von Nachrichtenkanälen zu hören ist. Nun wird die Frage, wo die Content-Based Router setzen. Wir könnten einfach haben, dass der CTIB-Kanaladapter alle Nachrichten an das Pricing Gateway auf einem einzelnen Message Channel weiterleitet. Dies ist aus zwei Gründen schlecht, weil wir die Geschäftslogik zwischen C und Java aufteilen würden, und wir würden den Vorteil des separaten Nachrichtenkanals auf der TIB-Seite verlieren, was es uns ermöglicht, eine Filterung später im Datenfluss zu vermeiden. Wenn wir unsere Java-Komponenten betrachten, können wir sie entweder im Pricing Gateway platzieren oder eine Zwischenkomponente zwischen dem Pricing Gateway und dem Client erstellen. In der Theorie, wenn wir die Bond-basierte Trennung von Message Channel s bis hin zum Client bestanden, würde das Pricing Gateway Pricing-Informationen mit derselben Kanalstruktur wie das Pricing Gateway und die Analytics Engine erneut senden. Dies bedeutet eine Duplizierung aller Bond-TIB-Kanäle in JMS. Selbst wenn wir eine Zwischenkomponente zwischen dem Pricing Gateway und dem Client erstellen, muss das Pricing Gateway immer noch alle Kanäle in JMS duplizieren. Auf der anderen Seite erlaubt die Implementierung der Logik direkt im Pricing Gateway die Vermeidung von Duplizierung der großen Anzahl von Kanälen in JMS, was uns ermöglicht, eine viel kleinere Anzahl von Kanälen in der Grßenordnung von einem pro Trader zu schaffen. Das Pricing Gateway registriert sich durch den CTIB Channel Adapter als Verbraucher für jede Bindung jedes Traders im System. Dann wird das Pricing Gateway jedem bestimmten Client nur die Nachrichten zu diesem bestimmten Händler weiterleiten. Auf diese Weise verwenden wir nur eine kleine Anzahl von Nachrichtenkanälen am JMS-Ende, während wir den Nutzen der Trennung am TIB-Ende maximieren. Der komplette Market Data Flow zum Client Die Message Channel Layout Diskussion ist ein gutes Beispiel dafür, wie die Integration von Patterns wichtig ist. Das Ziel hier war, herauszufinden, wie man effektiv den Nachrichten-Kanal s verwenden. Sagen Sie verwenden ein Muster ist nicht genug. Sie müssen herausfinden, wie man am besten implementieren und integrieren in Ihr System, um die Probleme zu lösen. Darüber hinaus zeigt dieses Beispiel Geschäftskräfte in Aktion. Wenn wir Geschäftslogik in irgendwelchen unserer Bestandteile umsetzen konnten, konnten wir mit dem pro Händleransatz gegangen und ein allgemeineres einfacherer Ansatz mit vielen weniger Kanälen implementiert haben. Auswählen eines Nachrichtenkanals Nachdem wir nun die Mechanismen der Kommunikation zwischen den JavaJMS-Komponenten und den C-TIBCO-Komponenten kennen und wir einige Nachrichtenkanalstrukturierungen gesehen haben, müssen wir entscheiden, welchen JMS-Nachrichtenkanal die Java-Komponenten zur Kommunikation verwenden sollen . Bevor wir zwischen den verschiedenen Nachrichtenkanälen auswählen können, die in JMS verfügbar sind, können wir uns den hohen Nachrichtenfluss des Systems ansehen. Wir haben zwei Gateways (Pricing and Contribution), die mit dem Kunden kommunizieren. Marktdaten fließen zum Client vom Pricing Gateway, der es an das Contribution Gateway sendet. Die Clientanwendung sendet eine Nachricht an das Pricing Gateway, um die auf jede Anleihe angewendeten Analysen zu ändern. Das Contribution Gateway sendet auch Nachrichten an die Client-Anwendung, die den Status der Preisaktualisierungen an die verschiedenen Handelsplätze weiterleitet. Der Systemnachrichtenfluss Die JMS-Spezifikation beschreibt zwei Message-Channel-Typen, Point-to-Point-Kanal (JMS Queue) und Publish-Subscribe Channel (JMS-Topic). Erinnern Sie sich, dass der Fall für die Verwendung von publish-subscribe es allen interessierten Konsumenten ermöglicht, eine Nachricht zu erhalten, während der Fall für die Verwendung von Punkt-zu-Punkt ist, um sicherzustellen, dass nur ein berechtigter Verbraucher eine bestimmte Nachricht erhält. Viele Systeme würden einfach Nachrichten an alle Client-Anwendungen senden, sodass jede einzelne Client-Anwendung selbst entscheiden kann, ob eine bestimmte Nachricht verarbeitet werden soll oder nicht. Dies funktioniert nicht für unsere Anwendung, da eine große Anzahl von Marktdaten-Nachrichten an jede Client-Anwendung gesendet werden. Wenn wir Marktdaten-Updates an uninteressierten Trader weitergeben, werden wir unnötigerweise Client-Prozessor-Zyklen verschwenden, die entscheiden, ob eine Marktdaten-Aktualisierung verarbeitet werden soll oder nicht. Punkt-zu-Punkt-Kanäle klingt zunächst wie eine gute Wahl, da die Clients Nachrichten an eindeutige Server senden und umgekehrt. Aber es war eine Geschäftsanforderung, dass Händler zu mehreren Maschinen gleichzeitig angemeldet werden können. Wenn ein Händler an zwei Arbeitsplätzen gleichzeitig angemeldet ist und eine Punkt-zu-Punkt-Preisaktualisierung gesendet wird, wird nur eine der beiden Clientanwendungen die Meldung erhalten. Dies liegt daran, dass nur ein Verbraucher auf einem Point-to-Point-Kanal eine bestimmte Nachricht empfangen kann. Beachten Sie, dass nur die erste von jeder Gruppe von Trader-Client-Anwendungen die Nachricht empfängt. Punkt-zu-Punkt-Messaging für Preisaktualisierungen Wir konnten dies mit dem Empfängerlistenmuster lösen, das Nachrichten zu einer Liste der beabsichtigten Empfänger veröffentlicht, sodass nur Clients in der Empfängerliste Nachrichten empfangen können. Mit diesem Muster kann das System Empfängerlisten mit allen Client-Anwendungsinstanzen erstellen, die mit jedem Trader zusammenhängen. Das Senden einer Nachricht, die sich auf einen bestimmten Händler bezieht, würde wiederum die Nachricht zu jeder Anwendung in der Empfängerliste senden. Dies garantiert, dass alle Client-Anwendungsinstanzen, die sich auf einen bestimmten Händler beziehen, die Nachricht erhalten. Der Nachteil dieses Ansatzes ist, dass es eine gewisse Implementierungslogik erfordert, um die Empfänger und Abfertigungsnachrichten zu verwalten. Empfänger-Liste für Preis-Updates Obwohl Punkt-zu-Punkt zur Arbeit gemacht werden könnte, sehen wir, ob es einen besseren Weg gibt. Durch die Verwendung von Publish-Subscribe-Kanälen könnte das System Nachrichten auf handelsüblichen Kanälen und nicht auf Client-spezifische Kanäle übertragen. Auf diese Weise würden alle Client-Anwendungen, die Nachrichten für einen einzelnen Händler verarbeiten, die Nachricht empfangen und verarbeiten. Publish-Subscribe-Messaging für Preisaktualisierungen Der Nachteil der Verwendung von Publish-Subscribe-Channels ist, dass eine eindeutige Nachrichtenverarbeitung nicht mit den Serverkomponenten gewährleistet ist. Es wäre möglich, mehrere Instanzen einer Server-Komponente instanziiert zu werden und jede Instanz verarbeitet dieselbe Nachricht, die möglicherweise ungültige Preise aussendet. Beim Abrufen des Systemnachrichtenflusses ist nur eine einzige Kommunikationsrichtung mit jedem Nachrichtenkanal zufriedenstellend. Server-to-Client-Kommunikation mit publish-subscribe ist zufriedenstellend, während Client-to-Server-Kommunikation nicht und Client-Server-Kommunikation mit Punkt-zu-Punkt zufrieden stellend ist, während Server-Client nicht. Da es nicht notwendig ist, denselben Nachrichtenkanal in beide Richtungen zu verwenden, können wir jeden Nachrichtenkanal nur in einer Richtung verwenden. Die Client-to-Server-Kommunikation wird mit Punkt-zu-Punkt implementiert, während die Server-to-Client-Kommunikation mit publish-subscribe implementiert wird. Mit dieser Kombination von Message Channel s profitiert das System von der direkten Kommunikation mit den Server-Komponenten mittels Point-to-Point Messaging und der Multicast-Art von publish-subscribe ohne einen der Nachteile. Nachrichtenfluss mit Kanaltypen Problemlösungen mit Patterns Patterns sind Werkzeuge und Patternsammlungen sind Toolboxes. Sie helfen, Probleme zu lösen. Einige denken, dass Muster nur während des Entwurfs nützlich sind. Im Anschluss an die Toolbox-Analogie, das ist wie sagen, dass Werkzeuge sind nur sinnvoll, wenn Sie ein Haus zu bauen, nicht, wenn Sie es zu beheben. Die Tatsache ist, dass Muster ein nützliches Werkzeug während eines Projekts sind, wenn es gut angewandt wird. In den folgenden Abschnitten werden wir denselben Mustererforschungsprozess verwenden, wie wir ihn im vorigen Abschnitt verwendet haben, um Probleme in unserem nun arbeitenden System zu lösen. Blinkende Marktdaten-Updates Trader wollen, dass Tabellenzellen blinken, wenn neue Marktdaten für eine Anleihe erhalten werden, was eindeutig die Veränderungen anzeigt. Der Java-Client empfängt Nachrichten mit neuen Daten, die eine Client-Daten-Cache-Aktualisierung auslösen und schließlich in der Tabelle blinken. Das Problem ist, dass Updates ziemlich häufig kommen. Der GUI-Threadstapel wird überladen und erfriert den Client schließlich, da er nicht auf Benutzerinteraktion reagieren kann. Wir gehen davon aus, dass das Blinken optimiert ist und sich auf den Datenfluss von Nachrichten durch den Aktualisierungsprozess konzentriert. Eine Prüfung der Leistungsdaten zeigt, dass die Clientanwendung mehrere Updates eine Sekunde empfängt, einige Updates traten weniger als eine Millisekunde auseinander auf. Zwei Muster, die so aussehen, als könnten sie dazu beitragen, den Nachrichtenfluss zu verlangsamen, sind Aggregator und Nachrichtenfilter. Ein erster Gedanke ist, einen Nachrichtenfilter zu implementieren, um die Geschwindigkeit des Nachrichtenflusses durch das Auswerfen von Aktualisierungen zu steuern, die eine kleine Zeitspanne nach der Referenznachricht empfangen werden. Als Beispiel können wir sagen, dass wir Nachrichten innerhalb von 5 Millisekunden von einander ignorieren werden. Der Nachrichtenfilter kann die Zeit der letzten akzeptablen Nachricht zwischenspeichern und alle empfangenen Nachrichten innerhalb der nächsten 5 Millisekunden auswerfen. Während andere Anwendungen nicht in der Lage, Datenverlust in einem solchen Ausmaß zu widerstehen, ist dies in unserem System durch die Häufigkeit der Preis-Updates völlig akzeptabel. Time Based Message Filter Das Problem bei diesem Ansatz ist, dass nicht alle Datenfelder zur gleichen Zeit aktualisiert werden. Jede Bindung hat ungefähr 50 Datenfelder, die dem Benutzer einschließlich Preis angezeigt werden. Wir wissen, dass nicht jedes Feld in jeder Nachricht aktualisiert wird. Wenn das System aufeinander folgende Nachrichten ignoriert, kann es sehr gut sein, wichtige Daten zu werfen. Das andere Muster von Interesse ist der Aggregator. Der Aggregator wird verwendet, um die Abstimmung mehrerer, verwandter Nachrichten in einer einzigen Nachricht zu verwalten, wodurch der Nachrichtenfluss möglicherweise reduziert wird. Der Aggregator könnte eine Kopie der Bonddaten aus der ersten aggregierten Nachricht behalten und dann nur neue oder geänderte Felder aufeinanderfolgende Nachrichten aktualisieren. Schließlich werden die aggregierten Bonddaten in einer Nachricht an den Client übergeben. Für jetzt gehen wir davon aus, dass der Aggregator eine Nachricht alle 5 Millisekunden wie die Message Filter senden wird. Später, gut erkunden eine andere Alternative. Aggregator mit teilweise aufeinanderfolgenden Updates Der Aggregator. Wie jedes andere Muster, ist nicht eine silberne Kugel es hat seine Pluspunkte und Minus, die erforscht werden müssen. Ein mögliches Minus ist, dass die Implementierung eines Aggregators den Nachrichtenverkehr durch eine große Menge in unserem Fall nur verringern würde, wenn viele Nachrichten innerhalb einer relativ kurzen Zeit in Bezug auf die gleiche Bindung kommen. Auf der anderen Seite würden wir nichts erreichen, wenn der Java-Client nur Updates für ein Feld über alle Trader-Anleihen erhält. Wenn wir zum Beispiel 1000 Nachrichten in einem bestimmten Zeitrahmen mit 4 interessierenden Bonds erhalten, würden wir den Nachrichtenfluss von 1000 auf 4 Nachrichten in diesem Zeitrahmen reduzieren. Alternativ, wenn wir 1000 Nachrichten im gleichen Zeitrahmen mit 750 Bonds von Interesse erhalten, haben wir reduziert den Nachrichtenfluss von 1000 bis 750 Nachrichten relativ wenig Gewinn für den Aufwand. Eine schnelle Analyse der Nachrichtenaktualisierungen beweist, dass der Java-Client viele Nachrichten empfängt, die Felder der gleichen Bindung aktualisieren und damit verbundene Nachrichten. Also, Aggregator ist in der Tat eine gute Entscheidung. Was übrig bleibt, ist zu bestimmen, wie der Aggregator wissen wird, wann eine Nachricht gesendet wird, die er aggregiert hat. Das Muster beschreibt ein paar Algorithmen für die Aggregator zu wissen, wann die Nachricht zu senden. Dazu gehören Algorithmen, die bewirken, dass der Aggregator seinen Inhalt nach Ablauf einer bestimmten Zeitspanne aussendet, nachdem alle erforderlichen Felder in einem Datensatz abgeschlossen sind, und andere. Das Problem mit all diesen Ansätzen ist, dass der Aggregator den Nachrichtenfluss und nicht den Client steuert. Und der Client ist der große Engpass in diesem Fall, nicht der Nachrichtenfluss. Dies liegt daran, dass der Aggregator davon ausgeht, dass die Konsumenten seiner gelöschten Nachrichten (die Clientanwendung in diesem Fall) ereignisgesteuerte Konsumenten oder Verbraucher sind, die auf Ereignisse von einer externen Quelle angewiesen sind. Wir müssen den Kunden in einen Polling Consumer verwandeln. Oder einen Verbraucher, der kontinuierlich nach Nachrichten sucht, so dass die Client-Anwendung den Nachrichtenfluss steuern kann. Wir können dies tun, indem Sie einen Hintergrund-Thread, der kontinuierlich Zyklen durch die Menge von Bindungen und Updates und blinkt alle Änderungen, die seit der letzten Iteration aufgetreten sind. Auf diese Weise kontrolliert der Client, wann Nachrichten empfangen werden, und garantiert dadurch, dass er bei hohen Aktualisierungsperioden niemals mit Meldungen überlastet wird. Wir können dies leicht implementieren, indem wir eine Command Message an den Aggregator senden, die eine Aktualisierung initiiert. The Aggregator will respond with a Document Message containing the set of updated fields that the client will process. The choice of Aggregator over Message Filter is clearly a decision based solely on the business requirements of our system. Each could help us solve our performance problems, but using the Message Filter would solve the problem at cost of the system data integrity. Major Production Crash With the performance of the flashing fixed, we are now in production. One day the entire system goes down. MQSeries crashes, bringing several components down with it. We struggle with the problem for a while and finally trace it back to the MQSeries dead letter queue (an implementation of the Dead Letter Channel ). The queue grows so large that it brings down the entire server. After exploring the messages in the dead letter queue we find they are all expired market data messages. This is caused by slow consumers, or consumers that do not process messages fast enough. While messages are waiting to be processed, they time out (see the Message Expiration pattern) and are sent to the Dead Letter Channel . The excessive number of expired market data messages in the dead letter queue is a clear indication that the message flow is too great messages expire before the target application can consume them. We need to fix the message flow and we turn to patterns for help slowing down the message flow. A reasonable first step is to explore solving this problem with the Aggregator as we recently used this pattern to solve the similar flashing market data control rate problem. The system design relies on the client application to immediately forward market data update messages to the trading venues. This means the system cannot wait to collect messages and aggregate them. So the Aggregator must be abandoned. There are two other patterns that deal with the problem of consuming messages concurrently: Competing Consumers and Message Dispatcher . Starting with Competing Consumers . the benefit of this pattern is the parallel processing of incoming messages. This is accomplished using several consumers on the same channel. Only one consumer processes each incoming message leaving the others to process successive messages. Competing Consumers . however, will not work for us since we are using Publish-Subscribe Channel s in server-to-client communication. Competing Consumers on a Publish-Subscribe Channel channel means that all consumers process the same incoming message. This results in more work without any gain and completely misses the goal of the pattern. This approach also has to be abandoned. On the other hand, the Message Dispatcher describes an approach whereby you add several consumers to a pool. Each consumer can run its own execution thread. One main Message Consumer listens to the Channel and delegates the message on to an unoccupied Message Consumer in the pool and immediately returns to listening on the Message Channel . This achieves the parallel processing benefit of Competing Consumers . but works on Publish-Subscribe Channel s. The Message Dispatcher in context Implementing this in our system is simple. We create a single JMSListener called the Dispatcher, which contains a collection of other JMSListener s called Performers. When the onMessage method of the Dispatcher is called, it in turn picks a Performer out of the collection to actually process the message. The result of which is a Message Listener (the Dispatcher) that always returns immediately. This guarantees a steady flow of message processing regardless of the message flow rate. Additionally, this works equally well on a Publish-Subscribe Channel s as it does on a Point-to-Point Channel s. With this infrastructure, messages can be received by the client application at almost any rate. If the client application is still slow to process the message after receiving them, the client application can deal with the delayed processing and potentially outdated market data rather than the messages expiring in the JMS Message Channel . The crash discussed in this section and the fix using the Message Dispatcher is an excellent example of the limits of applying patterns. We encountered a performance problem based on a design flaw not allowing the client to process messages in parallel. This greatly improved the problem, but did not completely fix it. This is because the real problem was the client becoming a bottleneck. This couldnt be fixed with a thousand patterns. We later addressed this problem by refactoring the message flow architecture to route messages directly from the Pricing Gateway to the Contribution Gateway. So patterns can help design and maintain a system, but dont necessarily make up for poor upfront design. Throughout this chapter, we have applied patterns to several different aspects of a bond trading system including solving initial upfront design problems and fixing a nearly job threatening production crash with patterns. We also saw these patterns as they already exist in third party product, legacy components, and our JMS and TIBCO messaging systems. Most importantly, these are real problems with the same types of architectural, technical and business problems we experience as we design and maintain our own systems. Hopefully reading about applying patterns to this system helps give you a better understanding of the patterns as well as how to apply them to your own systems. 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. Messaging Patterns 187 Integration Patterns in Practice 187 Case Study: Bond Trading SystemTrade Architect Elevate your trading. Experience the view from Trade Architect reg Stay connected to the market with the streamlined Trade Architect platform. Intuitive and easy to use, you can monitor and analyze potential investment opportunities with sophisticated tools, customized charting, live streaming video, and integrated research. Trade Architect now features Trade Finder, a new tool that simplifies the process of making options trades. Get all of this and more all in one place without platform or data fees. Trade Finder Tap into Trading Tools Ask for Help Anytime Trade Finder The Trade Finder tool simplifies the process of making an options trade. Rather than having to do a lot of research and dig through hundreds of different types of trades to make your decision, you enter 4 simple criteria and then with one click, the tool shows you different trades that match your search. View a short demo . Commissions, service fees and exception fees still apply. See our commission and brokerage fees for details Tap into Trading Tools Tap into Trading Tools Get the top-notch tools you need to tackle the market. Find vital stock and option information when and where you need it. Stream news, trade from customizable charts, and take advantage of free in-platform education so you can trade confidently. Commissions, service fees and exception fees still apply. See our commission and brokerage fees for details Ask for Help Anytime All screen shots are for illustrative purposes only, and not a recommendation of any specific security or strategy. Marktvolatilität, Volumen und Systemverfügbarkeit können den Kontozugriff und die Handelsausführung verzögern. Die Wertentwicklung in der Vergangenheit ist keine Garantie für zukünftige Ergebnisse. Access to real-time market data is conditioned on acceptance of exchange agreements. Siehe unsere Provisions - und Maklergebühren für Details. Execution price, speed and liquidity are affected by many factors, including market volatility, size and type of order and available market centers. Die Optionen sind nicht für alle Anleger geeignet, da die besonderen Risiken des Optionshandels den Anlegern potenziell rasche und erhebliche Verluste aussetzen können. Bitte lesen Sie die Merkmale und Risiken der standardisierten Optionen, bevor Sie in Optionen investieren. Optionen Handel Privilegien unterliegen TD Ameritrade Überprüfung und Genehmigung. Not all account owners will qualify. TD Ameritrade was evaluated against 15 others in the 2016 Barronrsquos Online Broker Review, March 19, 2016. The firm was ranked 1st in the categories ldquoBest for Long-Term Investingrdquo, ldquoBest for Usabilityrdquo, ldquoBest for Research Amenitiesrdquo, ldquoBest for Portfolio Analysis amp Reportsrdquo, and ldquoBest for Novices. rdquo TD Ameritrade was also awarded the highest star ratings (4.5) in ldquoBest for Options Tradersrdquo (shared with 2 others) and (4) in ldquoBest for In-Person Servicerdquo (shared with 4 others). Also received 4 stars in ldquoBest for Frequent Tradersrdquo. Star ratings are out of a possible 5. Barronrsquos is a trademark of Dow Jones. L. P. Alle Rechte vorbehalten. Offer valid for one new Individual, Joint or IRA TD Ameritrade account opened by 03312017 and funded within 60 calendar days of account opening with 3,000 or more. To receive 100 bonus, account must be funded with 25,000-99,999. To receive 300 bonus, account must be funded with 100,000-249,999. To receive 600 bonus, account must be funded with 250,000 or more . Offer is not valid on tax-exempt trusts, 401k accounts, Keogh plans, Profit Sharing Plan, or Money Purchase Plan. Offer is not transferable and not valid with internal transfers, TD Ameritrade Institutional accounts, accounts managed by TD Ameritrade Investment Management, LLC, current TD Ameritrade accounts or with other offers. Qualified commission-free Internet equity, ETF or options orders will be limited to a maximum of 500 and must execute within 60 calendar days of account funding. Contract, exercise, and assignment fees still apply . Limit one offer per client. Account value of the qualifying account must remain equal to, or greater than, the value after the net deposit was made (minus any losses due to trading or market volatility or margin debit balances) for 12 months, or TD Ameritrade may charge the account for the cost of the offer at its sole discretion. TD Ameritrade reserves the right to restrict or revoke this offer at any time. Dies ist kein Angebot oder eine Aufforderung in einem Land, in dem wir nicht berechtigt sind, Geschäfte zu tätigen. Please allow 3-5 business days for any cash deposits to post to account. Taxes related to TD Ameritrade offers are your responsibility. Retail values totaling 600 or more during the calendar year will be included in your consolidated Form 1099. Please consult a legal or tax advisor for the most recent changes to the U. S. tax code and for rollover eligibility rules. (Offer Code: 220). The ETRADE Pro trading platform, including Level II quotes and streaming news, is available at no charge to ETRADE Pro Elite active trader customers who execute at least 30 stock or options trades during a calendar quarter. Um weiterhin Zugriff auf diese Plattform zu erhalten, müssen Sie mindestens 30 Aktien - oder Optionsgeschäfte bis zum Ende des folgenden Kalenderquartals ausführen. Customers can also subscribe for 99.95 per month. Active Trader representatives are only available to logged-in ETRADE Pro customers. Fidelityrsquos Active Trader Proreg trading platform is available to households trading 36 times or more in a rolling twelve-month period. Trading 72 times over the same period earns access to static Level II quotes. Trading 120 times over the same period earns streaming news. Active Trader Services, including dedicated trading specialists, are available to households that place 120 or more stock, bond, or options trades over the same period and maintain 25K in assets across eligible Fidelity brokerage accounts. Schwabrsquos StreetSmartreg tools are available to Schwab Trading Services clients. A Schwab brokerage account is required. Schwab behält sich das Recht vor, den Zugang jederzeit zu beschränken oder zu ändern. Access to Nasdaq TotalViewreg quotes is provided for free to non-professional clients who have made 120 or more equity and options trades in the last 12 months, or 30 or more equity and options trades in either the current or previous quarter, or who maintain 1 million or more in household balances at Schwab. Schwab Trading Services clients who do not meet these requirements can subscribe to Nasdaq TotalView quotes for a quarterly fee. Professional clients may be required to meet additional criteria before obtaining a subscription to Nasdaq TotalView quotes. This offer may be subject to additional restrictions or fees, and may be changed at any time. The speed and performance of streaming data may vary depending on your modem speed and ISP connection. Access to electronic services may be limited or unavailable during periods of peak demand, market volatility, systems upgrades or maintenance, or for other reasons. All product names and marks are property of their respective owners. dagger Probability analysis results are theoretical in nature, not guaranteed, and do not reflect any degree of certainty of an event occurring. Research provided by unaffiliated third party sources is deemed reliable by TD Ameritrade. However, TD Ameritrade does not guarantee accuracy and completeness, and makes no warranties with respect to results to be obtained from its use. TD Ameritrade, Inc. Mitglied FINRA SIPC. Dies ist kein Angebot oder eine Aufforderung in einem Land, in dem wir nicht berechtigt sind, Geschäfte zu tätigen. TD Ameritrade ist ein eingetragenes Warenzeichen der TD Ameritrade IP Company, Inc. und der Toronto-Dominion Bank. copy 2017 TD Ameritrade. System architecture for on-line optimization of automated trading strategies Citations Citations 3 References References 20 quotThey built a disk memoization solution to reduce the number of repeated computations, allowing the analysts to build and debug their algorithms more quickly. A new automated trading system architecture was introduced by Freitas 9, who considers dividing the trading problem into several tasks handled by distributed autonomous agents, with minimal central coordination. Their strategy is based on obtaining a consensus trading signal based on other trading signals from multiple strategies. quot Show abstract Hide abstract ABSTRACT: About 80 of the financial market investors fail, the main reason for this being their poor investment decisions. Without advanced financial analysis tools and the knowledge to interpret the analysis, the investors can easily make irrational investment decisions. Moreover, investors are challenged by the dynamism of the market and a relatively large number of indicators that must be computed. In this paper we propose E-Fast, an innovative approach for on-line technical analysis for helping small investors to obtain a greater eciency on the market by increasing their knowledge. The E-Fast technical analysis platform prototype relies on High Performance Computing (HPC), allowing to rapidly develop and extensively validate the most sophisticated finance analysis algorithms. In this work, we aim at demonstrating that the E-Fast implementation. based on the CloudPower HPC infrastructure, is able to provide small investors a realistic, low-cost and secure service that would otherwise be available only to the large financial institutions. We describe the architecture of our system and provide design insights. We present the results obtained with a real service implementation based on the Exponential Moving Average computational method, using CloudPower and Grid5000 for the computationsx27 acceleration. We also elaborate a set of interesting challenges emerging from this work, as next steps towards high performance technical analysis for small investors. Full-text Conference Paper Sep 2015 Concurrency and Computation Practice and Experience Mircea Moca Darie Moldovan Oleg Lodygensky Gilles Fedak quotIn the current section, we present the software architecture model that we have used for implementing the ITA system architecture, which employed a publishsubscribe communication model or pubsub for short. In early versions of our ITA software architecture 17, we directly employed the Carnegie Mellonx27s IPC as a pubsub framework 19. The current version of ITA software architecture now employs the CARMEN Toolkit 18, which is an open-source collection of robot control software based on the IPC communication framework. quot Show abstract Hide abstract ABSTRACT: This work presents the Intelligent Trading Architecture (ITA), which is a new automated trading system architecture that supports multiple strategies for multiple market conditions through hierarchical trading signals generation. The central idea of the proposed system architecture is decomposing the trading problem into a set of tasks that are handled by distributed autonomous agents under a minimal central coordination. With this kind of architecture, we can take advantage of currently available and future high-performance computing systems. These systems, due to the way computer architecture has evolved in the recent past and foreseeable future, are composed of multiple processor cores. We are implementing the ITA software architecture employing the Carnegie Mellon Navigation (CARMEN) robot control software and using a publishsubscribe communication model. Together, CARMEN and this communication model allow the implementation of high-performance, scalable parallel computing systems that leverage the architecture of multi-core systems. For this work, we evaluated the data structures and algorithms employed by the symbol module of the ITA software architecture, which is responsible for maintaining the synchronized local copies of exchanges limit order books (LOB) for the instruments traded by the system. Our LOB implementation strongly outperformed a reference implementation in all evaluated parameters by more than one order of magnitude in some cases, achieving average throughputs of 4 million orderss when creating new orders, 3 million orderss when changing existing orders, and 17 million orderss when querying orders. Copyright Article Sep 2015 Fabio Daros Freitas Christian Daros Freitas Alberto Ferreira De Souza Show abstract Hide abstract ABSTRACT: About 80 of the financial market investors fail, the main reason for this being their poor investment decisions. Without advanced financial analysis tools and the knowledge to interpret the analysis, the investors can easily make irrational investment decisions. Moreover, investors are challenged by the dynamism of the market and a relatively large number of indicators that must be computed. In this paper we propose E-Fast, an innovative approach for on-line technical analysis for helping small investors to obtain a greater efficiency on the market by increasing their knowledge. The E-Fast technical analysis platform prototype relies on High Performance Computing (HPC), allowing to rapidly develop and extensively validate the most sophisticated finance analysis algorithms. In this work, we aim at demonstrating that the E-Fast implementation, based on the CloudPower HPC infrastructure, is able to provide small investors a realistic, low-cost and secure service that would otherwise be available only to the large financial institutions. We describe the architecture of our system and provide design insights. We present the results obtained with a real service implementation based on the Exponential Moving Average computational method, using CloudPower and Grid5000 for the computations acceleration. We also elaborate a set of interesting challenges emerging from this work, as next steps towards high performance technical analysis for small investors. Chapter Jan 2016 Concurrency and Computation Practice and Experience Mircea Moca Darie Moldovan Oleg Lodygensky Gilles Fedak