Online Trading System Architecture

Étude de cas: système d'échange de titres (par Jonathan Simon) Il est facile de vous distancer d'une vaste collection de modèles ou d'un langage à motifs. Les motifs sont l'abstraction d'une idée sous une forme réutilisable. Souvent, la nature très générique des motifs qui les rend si utiles les rend également difficiles à saisir. Parfois, la meilleure chose pour aider à comprendre les modèles est un exemple du monde réel. Pas un scénario artificiel de ce qui pourrait arriver, mais ce qui se passe réellement et ce qui va arriver. Ce chapitre applique des modèles pour résoudre des problèmes en utilisant un processus de découverte. Le système que nous allons discuter est un système d'échange d'obligations avec lequel j'ai travaillé pendant deux ans, de la conception initiale à la production. Nous allons explorer les scénarios et les problèmes qui ont été rencontrés et comment les résoudre avec des modèles. Cela implique le processus de décision de choisir un modèle, ainsi que la façon de combiner et d'ajuster les modèles pour répondre aux besoins du système. Et tout cela en tenant compte des forces rencontrées dans les systèmes réels, y compris les exigences de l'entreprise, les décisions des clients, les exigences architecturales et techniques, ainsi que l'intégration du système hérité. L'intention de cette approche est de fournir une compréhension plus claire des modèles eux-mêmes par l'application pratique. Construire un système Une grande banque d'investissement de Wall Street se propose de construire un système de tarification des obligations afin de rationaliser le flux de travail de leur guichet de négociation d'obligations. Actuellement, les traders obligataires doivent envoyer des prix pour un grand nombre d'obligations à plusieurs sites de négociation différents, chacun avec sa propre interface utilisateur. Le but du système est de minimiser les minima de tarification de toutes leurs obligations combinées à des fonctionnalités analytiques avancées spécifiques au marché des obligations dans une seule interface utilisateur encapsulée. Cela signifie l'intégration et la communication avec plusieurs composants sur différents protocoles de communication. Le flux de haut niveau du système ressemble à ceci: Premièrement, les données du marché entrent dans le système. Les données de marché sont des données concernant le prix et les autres propriétés de l'obligation représentant ce que les gens sont prêts à acheter et à vendre l'obligation pour sur le marché libre. Les données du marché sont immédiatement envoyées au moteur d'analyse qui modifie les données. Analytique se réfère à des fonctions mathématiques pour les applications financières qui modifient les prix et autres attributs des obligations. Il s'agit de fonctions génériques qui utilisent des variables d'entrée pour adapter les résultats de la fonction à une liaison particulière. L'application cliente qui s'exécutera sur chaque ordinateur de bureau trader configurera le moteur d'analyse sur une base par commerçant, en contrôlant les spécificités de l'analyse pour chaque obligation de l'opérateur est la tarification. Une fois que les données analytiques sont appliquées aux données du marché, les données modifiées sont envoyées à différents lieux de négociation où des commerçants d'autres entreprises peuvent acheter ou vendre des obligations. Architecture avec Patterns Avec cette vue d'ensemble du workflow du système, nous pouvons aborder quelques-uns des problèmes d'architecture que nous rencontrons pendant le processus de conception. Jetons un coup d'oeil à ce que nous savons à ce jour. Les opérateurs ont besoin d'une application très réactive sur les postes de travail Windows NT et Solaris. Par conséquent, nous avons décidé de mettre en œuvre l'application client en tant que client d'épaisseur Java en raison de son indépendance de plate-forme et de sa capacité à répondre rapidement aux données d'entrée et de marché des utilisateurs. Du côté du serveur, nous héritons des composants C hérités que notre système utilisera. Les composants de données de marché communiquent avec l'infrastructure de messagerie TIBCO Information Bus (TIB). Nous héritons des composants suivants: Market Data Feed Feed Server. Publie les données du marché entrant au TIB. Analytics Engine. Effectue des analyses sur les données de marché entrantes et diffuse les données de marché modifiées vers le TIB. Serveur de contribution. Effectue toutes les communications avec les sites de négociation. Les sites de négociation sont des composants tiers non contrôlés par la banque. Sous-système Legacy Market Data Sous-système Legacy Contribution Nous devons décider comment les sous-systèmes distincts (client épais de Java, données de marché et contribution) vont communiquer. Nous pourrions avoir le client épais communiquer directement avec les serveurs hérités, mais cela nécessiterait trop de logique métier sur le client. Au lieu de cela, construisez bien une paire de passerelles Java pour communiquer avec les serveurs héritésLa passerelle de tarification pour les données de marché une passerelle de contribution pour envoyer des prix aux sites de négociation. Cela permettra d'obtenir une bonne encapsulation de la logique métier liée à ces domaines. Les composants actuels du système sont présentés ci-dessous. Les connexions sont marquées comme. Indiquent que nous ne savons toujours pas comment certains des composants communiqueront. Le système et ses composants La première question de communication est d'intégrer le client Java épais et les deux composants du serveur Java afin d'échanger des données. Examinons les quatre styles d'intégration suggérés dans ce livre: Transfert de fichiers. Base de données partagée. Invocation de procédure à distance. Et messagerie. Nous pouvons exclure la base de données partagée immédiatement parce que nous voulions créer une couche d'abstraction entre le client et la base de données et ne veulent pas avoir de code d'accès à la base de données dans le client. Transfert de fichiers peut également être exclue car une latence minimale est nécessaire pour s'assurer que les prix actuels sont envoyés aux lieux de négociation. Cela nous laisse le choix entre l'appel de procédure distante ou la messagerie. La plate-forme Java fournit une prise en charge intégrée pour l'appel de procédure distante et la messagerie. L'intégration de style RPC peut être obtenue à l'aide de Remote Method Invocation (RMI), CORBA ou Enterprise Java Beans (EJB). Java Messaging Service (JMS) est l'API commune pour l'intégration de messagerie. Les deux styles d'intégration sont donc faciles à implémenter en Java. Donc ce qui fonctionnera mieux pour ce projet, Remote Procedure Invocation ou Messaging. Theres une seule instance de la Passerelle de prix et une instance de la passerelle de contribution dans le système, mais habituellement de nombreux clients épais se connectent simultanément à ces services (un pour chaque opérateur d'obligations qui se trouve être connecté à un moment particulier). En outre, la banque aimerait que ce soit un système de prix générique qui peut être utilisé dans d'autres applications. Donc, outre un nombre inconnu de Think Clients, il peut y avoir un nombre inconnu d'autres applications en utilisant les données de tarification qui sortent des passerelles. Un client grossier (ou une autre application utilisant les données de tarification) peut utiliser assez facilement RPC pour effectuer des appels aux passerelles pour obtenir des données de tarification et pour invoquer le traitement. Toutefois, les données sur les prix seront constamment publiées, et certains clients ne s'intéressent qu'à certaines données, ce qui pourrait compliquer l'accès aux données pertinentes aux clients appropriés. Les clients pourraient consulter les passerelles, mais cela va créer beaucoup de frais généraux. Il serait préférable pour les passerelles de mettre les données à la disposition des clients dès qu'il est disponible. Cela nécessitera cependant que chaque passerelle conserve la trace des clients actifs et qui veulent savoir quelles données alors, lorsqu'une nouvelle donnée est disponible (ce qui se produira plusieurs fois par seconde), la passerelle devra Un RPC à chaque client intéressé pour transmettre les données au client. Idéalement, tous les clients doivent être notifiés simultanément, de sorte que chaque RPC doit être faite dans son propre thread simultané. Cela peut fonctionner, mais devient très compliqué très rapidement. La messagerie simplifie grandement ce problème. Avec messagerie. Nous pouvons définir des canaux distincts pour les différents types de données de tarification. Ensuite, lorsqu'une passerelle reçoit une nouvelle donnée, elle ajoute un message contenant ces données au canal Publier-Inscription pour ce type de données. Pendant ce temps, tous les clients intéressés par un certain type de données écouteront sur le canal pour ce type. De cette façon, les passerelles peuvent facilement envoyer de nouvelles données à quiconque est intéressé, sans avoir besoin de savoir combien d'applications d'écoute il ya ou ce qu'ils sont. Les clients doivent encore être en mesure d'invoquer le comportement dans les passerelles ainsi. Puisqu'il y a seulement deux passerelles et que le client peut probablement bloquer pendant que la méthode est appelée de manière synchrone, ces invocations de client à passerelle peuvent assez facilement être implémentées en utilisant RPC. Cependant, étant donné que nous utilisons déjà la messagerie pour la communication passerelle-client, les messages sont probablement aussi bon moyen d'implémenter la communication client-passerelle. Par conséquent, toutes les communications entre les passerelles et les clients seront effectuées par messagerie. Parce que tous les composants sont écrits en Java, JMS présente un choix facile pour le système de messagerie. Cela crée effectivement un Message Bus ou une architecture qui permettra aux futurs systèmes d'intégrer avec le système actuel avec peu ou pas de changements à l'infrastructure de messagerie. De cette façon, la fonctionnalité commerciale de l'application peut être facilement utilisée par d'autres applications développées par la banque. Composants Java Communiquer avec JMS JMS est simplement une spécification et nous devons décider d'un système de messagerie compatible JMS. Nous avons décidé d'utiliser IBM MQSeries JMS parce que la banque est une boutique IBM, utilisant des serveurs d'applications WebSphere et de nombreux autres produits IBM. En conséquence, nous utiliserons MQSeries car nous avons déjà une infrastructure de support en place et une licence de site du produit. La question suivante est de savoir comment connecter le système de messagerie MQSeries au serveur C Contribution autonome et aux serveurs Market Data et Analytics Engine basés sur TIBCO. Nous avons besoin d'un moyen pour les consommateurs MQSeries d'avoir accès aux messages TIB. Mais comment pourrions-nous utiliser le modèle Message Translator pour traduire les messages TIB en messages MQSeries. Bien que le client C pour MQSeries serve de traducteur de messages. L'utilisation de ce serveur sacrifierait l'indépendance du serveur JMS. Et bien que TIBCO ait une API Java, l'architecte client et le gestionnaire l'ont rejetée. Par conséquent, l'approche de Message Translator doit être abandonnée. Le pont entre le serveur TIB et le serveur MQSeries requiert une communication entre C et Java. Nous pourrions utiliser CORBA, mais alors que dire de la messagerie Un examen plus approfondi du modèle Message Translator montre qu'il est lié à l'adaptateur de canal dans son utilisation des protocoles de communication. Le cœur d'un adaptateur de canal est de connecter des systèmes sans messagerie aux systèmes de messagerie. Une paire d'adaptateurs de canal qui connecte deux systèmes de messagerie est un Messaging Bridge. Le but de Messaging Bridge est de transférer des messages d'un système de messagerie à un autre. C'est exactement ce que nous faisons avec la complexité ajoutée de la communication intra-langage Java vers C. Nous pouvons implémenter le Messaging Bridge en utilisant une combinaison de Channel Adapter s et CORBA. Nous allons construire deux serveurs adaptateur de canal léger, l'un en C pour la gestion de la communication avec le TIB et l'autre en Java, qui gère la communication avec JMS. Ces deux adaptateurs de canal. Qui sont Message Endpoint s eux-mêmes, communiquent entre eux via CORBA. Comme notre choix pour MQSeries, nous allons utiliser CORBA plutôt que JNI puisqu'il s'agit d'une norme de l'entreprise. Le pont de messagerie implémente la traduction de messages simulée de manière efficace entre des systèmes de messagerie apparemment incompatibles et des langages différents. Traducteur de messages à l'aide d'adaptateurs de voies Le schéma suivant présente la conception actuelle du système, y compris les passerelles et les autres composants. C'est un bon exemple d'application de modèle. Nous avons combiné deux adaptateurs de canal avec un protocole non messagerie pour implémenter le modèle Message Translator, en utilisant un modèle pour implémenter un autre modèle. En outre, nous avons modifié le contexte de l'adaptateur de canal pour relier deux systèmes de messagerie à un protocole de traduction de langue croisée sans messagerie plutôt que de connecter un système de messagerie à un système sans messagerie. Le système actuel avec les adaptateurs de canal Structurer les canaux Une clé pour travailler avec des modèles n'est pas seulement savoir quand utiliser ce modèle, mais aussi comment l'utiliser plus efficacement. Chaque implémentation de modèle doit tenir compte des spécificités de la plate-forme technologique ainsi que d'autres critères de conception. Cette section applique le même processus de découverte pour trouver l'utilisation la plus efficace du canal Publier-S'abonner dans le contexte du serveur de données du marché communiquant avec le moteur d'analyse. Les données de marché en temps réel proviennent du flux de données du marché, un serveur C qui diffuse des données de marché sur le TIB. Le flux de données de marché utilise un canal de publication-abonnement distinct pour chaque lien pour lequel il publie des prix. Cela peut sembler un peu extrême car chaque nouvelle obligation a besoin de sa propre nouvelle chaîne. Mais ce n'est pas si grave car vous n'avez pas vraiment besoin de créer des canaux dans TIBCO. Les chaînes sont plutôt référencées par un ensemble hiérarchique de noms de sujets appelés sujets. Le serveur TIBCO filtre alors un seul flux de messages par sujet, en envoyant chaque objet unique à un seul canal virtuel. Le résultat est un canal de message très léger. Nous pourrions créer un système qui publie sur quelques canaux et les abonnés pouvaient écouter uniquement pour les prix qu'ils sont intéressés po Cela nécessiterait des abonnés d'utiliser un filtre de message ou consommateur sélectif pour filtrer l'ensemble du flux de données pour les prix des obligations intéressantes, Doit être traitée au fur et à mesure qu'elle est reçue. Étant donné que les données du marché sont publiées sur des chaînes dédiées aux obligations, les abonnés peuvent s'inscrire aux mises à jour d'une série d'obligations. Cela permet effectivement aux abonnés de filtrer en s'abonnant sélectivement aux canaux et de recevoir uniquement des mises à jour d'intérêt plutôt que de décider après la réception du message. Il est important de noter que l'utilisation de plusieurs canaux pour éviter le filtrage est une utilisation non standard des canaux de messagerie. Dans le contexte de la technologie TIBCO cependant, nous décidons vraiment d'implémenter ou de posséder des filtres ou d'utiliser le filtrage de canaux intégré à TIBCO - plutôt que d'utiliser tant de canaux. Le prochain composant que nous devons concevoir est le moteur d'analyse, un autre serveur CTIB qui va modifier les données de marché et de rediffuser à la TIB. Bien qu'il soit hors de la portée de notre développement JavaJMS, nous travaillons en étroite collaboration avec l'équipe C pour le concevoir puisque nous sommes le client principal des moteurs d'analyse. Le problème à venir est de trouver la structure de canal la plus efficace pour retransmettre les données de marché nouvellement modifiées. Puisque nous avons déjà un canal de message dédié par lien hérité de l'alimentation de prix de données de marché, il serait logique de modifier les données de marché et de retransmettre les données de marché modifiées sur le canal de message dédié aux obligations. Mais cela ne fonctionnera pas puisque les analyses modifiant les prix des obligations sont spécifiques au négociant. Si nous retransmettons les données modifiées sur le canal de message de l'obligation. Nous allons détruire l'intégrité des données en remplaçant les données génériques du marché par des données spécifiques aux opérateurs. D'autre part, nous pourrions avoir un type de message différent pour les données de marché spécifiques au trader que nous publions sur le même canal permettant aux abonnés de décider quel message ils sont intéressés à éviter de détruire l'intégrité des données. Mais alors les clients devront mettre en œuvre leurs propres filtres pour séparer les messages pour d'autres commerçants. De plus, les messages reçus par les abonnés augmenteront considérablement, ce qui leur imposera une charge inutile. Il existe deux options: Un canal par commerçant: Chaque opérateur dispose d'un canal désigné pour les données de marché modifiées. De cette façon, les données du marché d'origine reste intacte et chaque application commerçant peut écouter ses commerçants spécifiques Message Channel pour les mises à jour de prix modifiés. Un canal par négociant par obligation: Créer un canal de message par transactionur par obligation uniquement pour les données de marché modifiées de ce lien. Par exemple, les données de marché pour le lien ABC seraient publiées sur le canal Bond ABC alors que les données de marché modifiées pour le négociant A seraient publiées sur le canal de messages Trader A, Bond ABC, les données de marché modifiées pour le trader B sur le Trader B, Bond ABC et bientôt. Un canal par commerçant Un canal par obligation par commerçant Il ya des avantages et des inconvénients à chaque approche. L'approche par lien, par exemple, utilise beaucoup plus le Message Channel. Dans le pire des cas, le nombre de messages sera le nombre d'obligations total multiplié par le nombre de commerçants. Nous pouvons mettre des limites supérieures sur le nombre de canaux qui seront créés, car nous savons qu'il ya seulement environ 20 commerçants et ils ne jamais le prix de plus de quelques centaines d'obligations. Cela place la limite supérieure en dessous de la fourchette de 10 000, ce qui n'est pas si bizarre par rapport à la chaîne de près de 100 000 messages que le flux de données de marché est utilisé. De plus, comme nous utilisons le TIB et le Message Channel sont assez peu coûteux, le nombre de messages n'est pas un problème grave. D'autre part, le simple nombre de canaux de messages pourrait être un problème du point de vue de la gestion. Chaque fois qu'un lien est ajouté un canal pour chaque commerçant doit être maintenu. Cela pourrait être grave dans un système très dynamique. Notre système, cependant, est essentiellement statique. Il dispose également d'une infrastructure pour la gestion automatique des canaux de messages. Ceci combiné à l'architecture héritée d'un composant hérité utilisant une approche similaire minimise l'inconvénient. Cela ne veut pas dire que nous devrions faire un nombre inutilement excessif de canaux de messages. Plutôt, nous pouvons mettre en œuvre une approche architecturale qui utilise un grand nombre de canaux de messages quand il ya une raison. Et il ya une raison dans ce cas qui se résume à l'emplacement de la logique. Si nous mettons en œuvre l'approche par opérateur, le moteur Analytics a besoin d'une logique pour grouper les canaux d'entrée et de sortie. Cela est dû au fait que les canaux d'entrée du moteur d'analyse sont par liaison et que le canal de messages de sortie est par opérateur, ce qui oblige le moteur Google Analytics à acheminer toutes les données analytiques provenant de plusieurs obligations pour un opérateur particulier. Cela transforme effectivement le moteur d'analyse en un routeur basé sur le contenu afin de mettre en œuvre une logique de routage personnalisée pour notre application. Suite à la structure Message Bus, le moteur Analytics est un serveur générique qui pourrait être utilisé par plusieurs autres systèmes dans le. Donc, nous ne voulons pas de cloud avec des fonctionnalités spécifiques du système. D'autre part, l'approche par obligation fonctionne puisque l'idée d'un opérateur possédant la sortie analytique des prix des obligations est une pratique acceptée par l'entreprise. L'approche par liaison maintient la séparation du canal de messages du flux de données du marché intacte, tout en ajoutant plusieurs autres canaux de messages. Avant d'atteindre le client, nous voulons qu'un routeur basé sur le contenu combine ces plusieurs canaux en un nombre gérable de canaux. Nous ne voulons pas que l'application cliente s'exécute sur le bureau des commerçants pour écouter des milliers ou des dizaines de milliers de messages. Maintenant, la question est de savoir où mettre le routeur basé sur le contenu. Nous pourrions simplement avoir l'adaptateur de canal CTIB transmettre tous les messages à la passerelle de prix sur un seul canal de message. C'est mal pour deux raisons que nous allions diviser la logique métier entre C et Java, et nous perdrions l'avantage des canaux de message séparés sur le côté TIB nous permettant d'éviter de filtrer plus tard dans le flux de données. En examinant nos composants Java, nous pourrions le placer dans la passerelle de tarification ou créer un composant intermédiaire entre la passerelle de tarification et le client. En théorie, si nous maintenions la séparation basée sur les obligations de Message Channel s jusqu'au client, la Passerelle de tarification diffuserait des informations sur les prix avec la même structure de canal que la passerelle de tarification et le moteur d'analyse. Cela signifie une duplication de tous les canaux TIB dédiés aux obligations dans JMS. Même si nous créons une composante intermédiaire entre la passerelle de tarification et le client, la passerelle de tarification devra toujours dupliquer tous les canaux dans JMS. D'autre part, la mise en œuvre de la logique directement dans la passerelle de tarification nous permet d'éviter de dupliquer le grand nombre de canaux dans JMS, nous permettant de créer un nombre beaucoup plus petit de canaux de l'ordre d'un par commerçant. La passerelle de tarification s'inscrit par l'intermédiaire de l'adaptateur de canal CTIB en tant que consommateur pour chaque obligation de chaque opérateur dans le système. Ensuite, la Passerelle de tarification transmettra à chaque client spécifique uniquement les messages relatifs à cet opérateur particulier. De cette façon, nous n'utilisons qu'un petit nombre de canaux de messages sur l'extrémité JMS, tout en maximisant l'avantage de la séparation sur la fin TIB. Le flux de données de marché complet pour le client La discussion sur la mise en page des messages est un bon exemple de l'importance de l'intégration de modèles. Le but ici était de comprendre comment utiliser efficacement le canal de messages. Dire que vous utilisez un modèle n'est pas assez. Vous devez trouver la meilleure façon de le mettre en œuvre et d'intégrer dans votre système pour résoudre les problèmes à portée de main. En outre, cet exemple montre les forces d'affaires en action. Si nous pouvions mettre en œuvre la logique métier dans n'importe lequel de nos composants, nous aurions pu utiliser l'approche par opérateur et implémenter une approche globale plus simple avec beaucoup moins de canaux. Sélection d'un canal de messagerie Maintenant que nous connaissons la mécanique de la communication entre les composants JavaJMS et les composants C TIBCO, et nous avons vu une certaine structuration Message Channel, nous devons décider quel type de JMS Message Channel s les composants Java doivent utiliser pour communiquer . Avant de pouvoir choisir entre les différents canaux de messages disponibles dans JMS, nous allons regarder le flux de messages de haut niveau du système. Nous avons deux passerelles (prix et contribution) communiquant avec le client. Les flux de données de marché vers le client à partir de la passerelle de tarification qui envoie à la passerelle de contribution. L'application cliente envoie un message à la passerelle de tarification pour modifier les analyses appliquées à chaque liaison. La Passerelle de contribution envoie également des messages à l'application Client relayant l'état des mises à jour des prix sur les différents sites de négociation. Le flux de messages du système La spécification JMS décrit deux types de canaux de message, le canal point à point (file d'attente JMS) et le canal de publication-souscription (rubrique JMS). Rappelons que le cas de l'utilisation de publish-subscribe est de permettre à tous les consommateurs intéressés de recevoir un message tandis que le cas pour l'utilisation point à point est de s'assurer que seul un consommateur admissible reçoit un message particulier. Beaucoup de systèmes diffuseraient simplement des messages vers toutes les applications clientes, laissant à chaque application client individuelle de décider elle-même s'il fallait ou non traiter un message particulier. Cela ne fonctionnera pas pour notre application car il existe un grand nombre de messages de données de marché envoyés à chaque application cliente. Si nous diffusons des mises à jour de données de marché à un opérateur non désintéressé, nous perdrons inutilement des cycles de processeur client décidant de traiter ou non une mise à jour de données de marché. Point-to-Point Channel s initialement son comme un bon choix puisque les clients envoient des messages à des serveurs uniques et vice versa. Mais il était une exigence commerciale que les commerçants peuvent être connectés à plusieurs machines en même temps. Si un opérateur se connecte simultanément à deux postes de travail et qu'une mise à jour de prix point à point est envoyée, seule une des deux applications clientes obtiendra le message. Cela est dû au fait qu'un seul consommateur sur un canal point à point peut recevoir un message particulier. Notez que seul le premier de chaque groupe d'applications clients d'un commerçant reçoit le message. Messagerie point à point pour les mises à jour des prix Nous pourrions résoudre ce problème en utilisant le modèle Liste des destinataires, qui publie des messages dans une liste de destinataires prévus, garantissant que seuls les clients de la liste des destinataires recevront des messages. En utilisant ce modèle, le système pourrait créer des listes de destinataires avec toutes les instances d'application client liées à chaque opérateur. Envoi d'un message lié à un commerçant particulier, à son tour, envoyer le message à chaque application dans la liste des destinataires. Cela garantit que toutes les instances d'application client liées à un opérateur particulier recevront le message. L'inconvénient de cette approche est qu'il nécessite un peu de logique d'implémentation pour gérer les destinataires et les messages d'expédition. Liste des destinataires pour les mises à jour de prix Même si point-à-point pourrait être fait pour travailler, permet de voir s'il ya une meilleure façon. En utilisant les canaux Publish-Subscribe, le système peut diffuser des messages sur des canaux spécifiques au trader plutôt que sur des canaux spécifiques aux applications clientes. De cette façon, toutes les applications clientes traitant des messages pour un seul opérateur recevraient et traiteraient le message. Publier-souscrire Messagerie pour les mises à jour de prix L'inconvénient de l'utilisation de publier-Subscribe Channel s est que le traitement de message unique n'est pas garanti avec les composants du serveur. Il serait possible que plusieurs instances d'un composant serveur soient instanciées et que chaque instance traite le même message, en envoyant éventuellement des prix incorrects. Rappelant le flux de messages du système, seul un sens de communication unique est satisfaisant avec chaque canal de message. La communication de serveur à client avec publication-souscription est satisfaisante alors que la communication de client à serveur n'est pas et la communication de client-serveur avec point à point est satisfaisante tandis que le client-serveur n'est pas. Comme il n'est pas nécessaire d'utiliser le même canal de messages dans les deux sens, nous ne pouvons utiliser chaque canal de messages que dans une seule direction. La communication entre le client et le serveur sera mise en œuvre de façon ponctuelle, tandis que la communication entre le serveur et le client sera mise en œuvre avec publish-subscribe. Grâce à cette combinaison de canaux de messages, le système bénéficie d'une communication directe avec les composants du serveur à l'aide de la messagerie point à point et de la nature multidiffusion de publication-souscription sans aucun des inconvénients. Flux de messages avec les types de canaux Résolution de problèmes avec les motifs Les modèles sont des outils et des collections de modèles sont des boîtes à outils. Ils aident à résoudre des problèmes. Certains pensent que les modèles ne sont utiles que lors de la conception. Suivant l'analogie de la boîte à outils, c'est comme dire que les outils ne sont utiles que lorsque vous construisez une maison, et non lorsque vous la réparez. Le fait est que les modèles sont un outil utile tout au long d'un projet lorsqu'ils sont bien appliqués. Dans les sections qui suivent, nous utiliserons le même processus d'exploration de modèles que celui utilisé dans la section précédente pour résoudre des problèmes dans notre système actuel. Mises à jour des données de marché clignotantes Les négociants veulent que les cellules de table clignotent lorsque de nouvelles données de marché sont reçues pour un lien, indiquant clairement les changements. Le client Java reçoit des messages avec de nouvelles données qui déclenche une mise à jour du cache de données client et clignote éventuellement dans la table. Le problème est que les mises à jour viennent assez fréquemment. La pile de threads GUI devient surchargée et finalement gel du client, car il ne peut pas répondre à l'interaction de l'utilisateur. Nous supposerons que le clignotement est optimisé et se concentrer sur le flux de données des messages par le biais du processus de mise à jour. Un examen des données de performance montre que l'application cliente reçoit plusieurs mises à jour une seconde, certaines mises à jour se sont produites moins d'une milliseconde. Deux modèles qui semblent pouvoir aider à ralentir le flux de messages sont agrégateur et filtre de messages. Une première réflexion consiste à implémenter un filtre de message pour contrôler la vitesse du flux de messages en jetant des mises à jour reçues une petite quantité de temps après le message de référence. Par exemple, disons que nous allons ignorer les messages dans les 5 millisecondes les uns des autres. Le filtre de messages peut mettre en cache l'heure du dernier message acceptable et jeter tout ce qui a été reçu dans les 5 prochaines millisecondes. Bien que d'autres applications ne puissent pas résister à une perte de données dans une telle mesure, cela est parfaitement acceptable dans notre système en raison de la fréquence des mises à jour des prix. Filtre de messages basé sur le temps Le problème avec cette approche est que tous les champs de données ne sont pas mis à jour en même temps. Chaque obligation comporte environ 50 champs de données affichés à l'utilisateur, y compris le prix. Nous réalisons que tous les champs ne sont pas mis à jour dans chaque message. Si le système ignore les messages consécutifs, il peut très bien être jeter des données importantes. L'autre modèle d'intérêt est l'agrégateur. L'agrégateur est utilisé pour gérer la réconciliation de plusieurs messages connexes en un seul message, ce qui peut réduire le flux de messages. L'agrégateur peut conserver une copie des données de liaison du premier message agrégé, puis mettre à jour uniquement les nouveaux messages ou les champs modifiés par messages successifs. Finalement, les données d'obligations agrégées seront transmises dans un message au client. Pour l'instant, supposons que l'agrégateur enverra un message toutes les 5 millisecondes comme le filtre de message. Plus tard, bien explorer une autre alternative. Agrégateur avec des mises à jour partielles successives L'agrégateur. Comme tout autre modèle, n'est pas une balle d'argent, il a ses avantages et ses inconvénients qui doivent être explorés. Un inconvénient potentiel est que la mise en œuvre d'un agrégateur réduirait le trafic de messages d'une grande quantité dans notre cas seulement si de nombreux messages arrivent dans un délai relativement court concernant le même lien. D'autre part, nous n'accompliraient rien si le client Java ne reçoit que des mises à jour pour un champ à travers tous les obligations des commerçants. Par exemple, si nous recevons 1000 messages dans un intervalle de temps spécifié avec 4 liens d'intérêt, nous réduirions le flux de messages de 1000 à 4 messages au cours de cette période. Alternativement, si nous recevons 1000 messages dans le même intervalle de temps avec 750 obligations d'intérêt, nous aurons réduit le flux de messages de 1000 à 750 messages relativement peu de gain pour la quantité d'effort. Une analyse rapide des mises à jour des messages prouve que le client Java reçoit de nombreux messages mettant à jour des champs du même lien, et donc des messages connexes. Ainsi, Aggregator est en fait une bonne décision. Il reste à déterminer comment l'agrégateur saura quand envoyer un message qu'il a agrégé. Le modèle décrit quelques algorithmes pour que l'Aggregator sache quand envoyer le message. Cela inclut des algorithmes pour amener l'agrégateur à envoyer son contenu après un certain temps écoulé, après que tous les champs requis dans un ensemble de données ont été complétés, et d'autres. Le problème avec toutes ces approches est que l'agrégateur contrôle le flux de messages, pas le client. Et le client est le principal goulet d'étranglement dans ce cas, pas le flux de messages. Cela est dû au fait que l'agrégateur assume que les consommateurs de ses messages purgés (l'application client dans ce cas) sont des consommateurs évités ou des consommateurs qui s'appuient sur des événements provenant d'une source externe. Nous devons transformer le client en un consommateur de vote. Ou un consommateur qui vérifie en permanence les messages, de sorte que l'application cliente peut contrôler le flux de messages. Nous pouvons le faire en créant un thread d'arrière-plan qui parcourt en continu l'ensemble des liens et mises à jour et clignote tous les changements qui se sont produits depuis la dernière itération. De cette façon, le client contrôle les messages reçus et, par conséquent, garantit qu'il ne sera jamais surchargé de messages pendant les périodes de mise à jour élevées. Nous pouvons facilement l'implémenter en envoyant un message de commande à l'agrégateur qui lance une mise à jour. 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 . Les commissions, les frais de service et les frais d'exception s'appliquent toujours. 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. Les commissions, les frais de service et les frais d'exception s'appliquent toujours. 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. La volatilité du marché, le volume et la disponibilité du système peuvent retarder l'accès aux comptes et les exécutions commerciales. Les performances passées ne garantissent pas les résultats futurs. L'accès aux données du marché en temps réel dépend de l'acceptation des accords d'échange. Consultez nos frais de commission et de courtage pour plus de détails. Execution price, speed and liquidity are affected by many factors, including market volatility, size and type of order and available market centers. Les options ne conviennent pas à tous les investisseurs car les risques particuliers inhérents à la négociation d'options peuvent exposer les investisseurs à des pertes potentiellement rapides et substantielles. Veuillez lire les caractéristiques et les risques des options normalisées avant d'investir dans des options. Droits de négociation d'options assujettis à l'examen et à l'approbation de TD Ameritrade. Tous les propriétaires de compte ne seront pas admissibles. 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). Aussi reçu 4 étoiles dans ldquoBest pour Frequent Tradersrdquo. Les notes d'étoiles sont sur un possible 5. Barronrsquos est une marque déposée de Dow Jones. L. P. Tous droits réservés. Offre valide pour un compte individuel, conjoint ou IRA TD Ameritrade ouvert par 03312017 et financé dans les 60 jours civils suivant l'ouverture du compte avec 3 000 ou plus. Pour recevoir 100 bonus, le compte doit être financé avec 25,000-99,999. Pour recevoir 300 bonus, le compte doit être financé avec 100,000-249,999. Pour recevoir 600 bonus, le compte doit être financé avec 250 000 ou plus. L'offre n'est pas valide sur les fiducies exonérées d'impôt, les comptes 401k, les régimes Keogh, le Plan de participation aux bénéfices ou le Plan d'achat d'argent. L'offre n'est pas transférable et n'est pas valable pour les transferts internes, les comptes institutionnels de TD Ameritrade, les comptes gérés par TD Ameritrade Investment Management, LLC, les comptes courants de TD Ameritrade ou d'autres offres. Les actions, les ETF ou les ordres d'options qualifiés, sans commission, seront limités à un maximum de 500 et doivent être exécutés dans les 60 jours civils suivant le financement du compte. Les frais de contrat, d'exercice et de cession s'appliquent toujours. Limite d'une offre par client. La valeur comptable du compte admissible doit demeurer égale ou supérieure à la valeur après le dépôt net (moins les pertes dues à la volatilité du marché ou de la marge ou aux soldes débiteurs de marge) pendant 12 mois, ou TD Ameritrade peut facturer le compte pour Le coût de l'offre à sa seule discrétion. TD Ameritrade se réserve le droit de restreindre ou de révoquer cette offre à tout moment. Il ne s'agit pas d'une offre ou d'une sollicitation dans une juridiction où nous ne sommes pas autorisés à faire des affaires. Veuillez prévoir un délai de 3 à 5 jours ouvrables pour les dépôts en espèces. Les impôts liés aux offres TD Ameritrade sont à votre charge. Les valeurs de détail totalisant 600 ou plus au cours de l'année civile seront incluses dans votre formulaire consolidé 1099. Veuillez consulter un conseiller juridique ou fiscal pour connaître les modifications les plus récentes du code fiscal des États-Unis et des règles d'admissibilité au refinancement. (Code d'offre: 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. To continue receiving access to this platform, you must execute at least 30 stock or options trades by the end of the following calendar quarter. 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 reserves the right to restrict or modify access at any time. 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. Membre de TD Ameritrade, Inc. FINRA SIPC. Il ne s'agit pas d'une offre ou d'une sollicitation dans une juridiction où nous ne sommes pas autorisés à faire des affaires. TD Ameritrade est une marque détenue conjointement par TD Ameritrade IP Company, Inc. et la Banque Toronto-Dominion. 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