Arquitetura do sistema de negociação de obrigações

Arquitetura do sistema de negociação de obrigações
(Por Jonathan Simon)
É fácil se distanciar de uma grande coleção de padrões ou de uma linguagem de padrões. Padrões são a abstração de uma ideia de forma reutilizável. Muitas vezes, a natureza muito genérica dos padrões que os tornam tão úteis também os torna difíceis de entender. Às vezes, a melhor coisa para ajudar a entender os padrões é um exemplo do mundo real. Não é um cenário planejado do que poderia acontecer; mas o que realmente acontece e o que vai acontecer.
Este capítulo aplica padrões para resolver problemas usando um processo de descoberta. O sistema que discutiremos é um sistema de negociação de títulos com o qual trabalhei durante dois anos desde o projeto inicial até a produção. Vamos explorar cenários e problemas que foram encontrados e como resolvê-los com padrões. Isso envolve o processo de decisão de escolher um padrão, bem como combinar e ajustar padrões para atender às necessidades do sistema. E tudo isso é feito levando-se em consideração as forças encontradas em sistemas reais, incluindo requisitos de negócios, decisões de clientes, requisitos técnicos e de arquitetura, bem como integração de sistemas legados. A intenção desta abordagem é fornecer uma compreensão mais clara dos próprios padrões através da aplicação prática.
Construindo um sistema.
Um grande banco de investimento de Wall Street se propõe a construir um sistema de precificação de títulos em um esforço para simplificar o fluxo de trabalho de sua mesa de negociação de títulos. Atualmente, os corretores de títulos precisam enviar preços para um grande número de títulos para vários locais de negociação diferentes, cada um com sua própria interface de usuário. O objetivo do sistema é minimizar as minúcias de precificação de todos os seus títulos combinados com funcionalidades analíticas avançadas específicas do mercado de títulos em uma única interface de usuário encapsulada. Isso significa integração e comunicação com vários componentes em vários protocolos de comunicação. O fluxo de alto nível do sistema se parece com isso:
Fluxo de Alto Nível.
Primeiro, os dados de mercado entram no sistema. Os dados do mercado são dados sobre o preço e outras propriedades do título, representando o que as pessoas estão dispostas a comprar e vender o título no mercado livre. Os dados de mercado são enviados imediatamente ao mecanismo de análise que altera os dados. Analytics refere-se a funções matemáticas para aplicações financeiras que alteram os preços e outros atributos dos títulos. Estas são funções genéricas que usam variáveis ​​de entrada para adequar os resultados da função a um vínculo específico. O aplicativo cliente que será executado em cada desktop do comerciante configurará o mecanismo de análise por comerciante, controlando os detalhes da análise para cada título que o negociador estiver precificando. Uma vez que as análises são aplicadas aos dados de mercado, os dados modificados são enviados para vários locais de negociação onde os comerciantes de outras empresas podem comprar ou vender os títulos.
Arquitetura com padrões.
Com essa visão geral do fluxo de trabalho do sistema, podemos abordar alguns dos problemas de arquitetura que encontramos durante o processo de design. Vamos dar uma olhada no que sabemos até agora. Os traders precisam de um aplicativo muito responsivo nas estações de trabalho Windows NT e Solaris. Portanto, decidimos implementar o aplicativo cliente como um cliente thick Java devido à sua independência de plataforma e sua capacidade de responder rapidamente aos dados de entrada e de mercado do usuário. No lado do servidor, estamos herdando componentes C ++ legados que nosso sistema irá utilizar. Os componentes de dados de mercado se comunicam com a infra-estrutura de mensagens TIBCO Information Bus (TIB).
Estamos herdando os seguintes componentes:
Servidor de Feed de Preços de Dados de Mercado: Publica dados de mercado de entrada para o TIB. Mecanismo de análise: executa análises em dados de mercado de entrada e transmite os dados de mercado modificados para o TIB. Servidor de Contribuição: Executa toda a comunicação com os locais de negociação. As plataformas de negociação são componentes de terceiros não controlados pelo banco.
Subsistema de Dados de Mercado Legado.
Subsistema de Contribuição Legado.
Precisamos decidir como os subsistemas separados (cliente thick de Java, dados de mercado e contribuição) vão se comunicar. Poderíamos ter o cliente thick se comunicando diretamente com os servidores legados, mas isso exigiria muita lógica de negócios no cliente. Em vez disso, construiremos um par de gateways Java para nos comunicarmos com os servidores legados: o gateway de preços para dados de mercado, um gateway de contribuição para o envio de preços a locais de negociação. Isso alcançará um bom encapsulamento da lógica de negócios relacionada a essas áreas. Os componentes atuais no sistema são mostrados abaixo. As conexões marcadas como. • indicam que ainda não temos certeza de como alguns dos componentes se comunicarão.
O sistema e seus componentes.
A primeira questão de comunicação é como integrar o cliente thick Java e os dois componentes do servidor Java para trocar dados. Vejamos os quatro estilos de integração sugeridos neste livro: Transferência de Arquivos, Banco de Dados Compartilhado, Invocação de Procedimento Remoto e Mensagens. Podemos descartar o Banco de Dados Compartilhado imediatamente porque desejamos criar uma camada de abstração entre o cliente e o banco de dados e não queremos ter o código de acesso ao banco de dados no cliente. A transferência de arquivos também pode ser descartada, uma vez que a latência mínima é necessária para garantir que os preços atuais sejam enviados para os locais de negociação. Isso nos deixa com uma escolha entre Invocação de Procedimento Remoto ou Mensagens.
A plataforma Java fornece suporte integrado para Invocação de Procedimento Remoto e Mensagens. A integração no estilo RPC pode ser obtida usando o Remote Method Invocation (RMI), o CORBA ou o Enterprise Java Beans (EJB). O Java Messaging Service (JMS) é a API comum para integração no estilo de mensagens. Portanto, ambos os estilos de integração são fáceis de implementar em Java.
Então, qual funcionará melhor para este projeto, Invocação de Procedimento Remoto ou Mensagens? Há apenas uma instância do Gateway de Precificação e uma instância do Contribution Gateway no sistema, mas geralmente muitos Clientes Claros conectam-se simultaneamente a esses serviços (um para cada comerciante de títulos que está conectado em um determinado momento). Além disso, o banco gostaria que este fosse um sistema genérico de preços que pode ser utilizado em outras aplicações. Portanto, além de um número desconhecido de Think Clients, pode haver um número desconhecido de outros aplicativos usando os dados de preços que saem dos Gateways.
Um Thick Client (ou outro aplicativo que usa os dados de precificação) pode facilmente usar o RPC para fazer chamadas para os Gateways para obter dados de preços e chamar o processamento. No entanto, os dados de preços serão constantemente publicados, e determinados clientes estão interessados ​​apenas em determinados dados, portanto, pode ser difícil obter os dados relevantes para os clientes apropriados em tempo hábil. Os clientes podem pesquisar os Gateways, mas isso criará muita sobrecarga. Seria melhor que os Gateways disponibilizassem os dados aos clientes assim que estivessem disponíveis. Isso, no entanto, exigirá que cada Gateway monitore quais clientes estão ativos no momento e quais desejam dados específicos; então, quando um novo pedaço de dados se torna disponível (o que acontecerá várias vezes por segundo), o Gateway terá que fazer um RPC para cada cliente interessado para passar os dados para o cliente. Idealmente, todos os clientes devem ser notificados simultaneamente, portanto, cada RPC precisa ser feito em seu próprio encadeamento simultâneo. Isso pode funcionar, mas está ficando muito complicado muito rápido.
Mensagens simplifica muito este problema. Com o Messaging, podemos definir canais separados para os diferentes tipos de dados de preços. Em seguida, quando um Gateway receber um novo dado, ele adicionará uma mensagem contendo esses dados ao Publish-Subscribe Channel desse tipo de dados. Enquanto isso, todos os clientes interessados ​​em um determinado tipo de dados ouvirão o canal desse tipo. Desta forma, os Gateways podem enviar facilmente novos dados para quem estiver interessado, sem precisar saber quantos aplicativos de ouvinte existem ou quais são.
Os clientes ainda precisam ser capazes de invocar comportamentos nos Gateways também. Como há sempre apenas dois Gateways e o cliente provavelmente pode bloquear enquanto o método é chamado de forma síncrona, essas chamadas de cliente para gateway podem ser facilmente implementadas usando o RPC. No entanto, como já estamos usando o sistema de mensagens para comunicação entre o gateway e o cliente, as mensagens provavelmente são uma maneira igualmente boa de implementar a comunicação do cliente para o gateway.
Portanto, toda a comunicação entre os Gateways e os clientes será realizada por meio de mensagens. Como todos os componentes são escritos em Java, o JMS apresenta uma opção fácil para o sistema de mensagens. Isso está efetivamente criando um Message Bus ou uma arquitetura que possibilitará a integração de futuros sistemas com o sistema atual, com pouca ou nenhuma alteração na infra-estrutura do sistema de mensagens. Dessa forma, a funcionalidade de negócios do aplicativo pode ser facilmente usada por outro aplicativo desenvolvido pelo banco.
Componentes Java Comunicando com o JMS.
O JMS é simplesmente uma especificação e precisamos decidir sobre um sistema de mensagens compatível com o JMS. Decidimos usar o IBM MQSeries JMS porque o banco é uma "loja IBM", usando servidores de aplicativos WebSphere e muitos outros produtos IBM. Como resultado, usaremos o MQSeries, pois já temos uma infraestrutura de suporte e uma licença de site do produto.
A próxima pergunta é como conectar o sistema de mensagens do MQSeries ao servidor C ++ Contribution autônomo e aos servidores Market Data e Analytics Engine baseados no TIBCO. Precisamos de uma maneira de os consumidores do MQSeries terem acesso às mensagens do TIB. Mas como? Talvez pudéssemos usar o padrão Message Translator para traduzir mensagens TIB em mensagens do MQSeries. Embora o cliente C ++ para o MQSeries funcione como um Message Translator, usá-lo sacrificaria a independência do servidor JMS. E embora a TIBCO tenha uma API Java, o arquiteto e gerente do cliente a rejeitaram. Como resultado, a abordagem do Message Translator deve ser abandonada.
A ponte do servidor TIB para o servidor MQSeries requer comunicação entre C ++ e Java. Poderíamos usar o CORBA, mas e as mensagens? Uma análise mais detalhada do padrão Message Translator mostra que ele está relacionado ao Channel Adapter no uso de protocolos de comunicação. O coração de um adaptador de canal é conectar sistemas sem mensagem a sistemas de mensagens. Um par de adaptadores de canal que conecta dois sistemas de mensagens é uma ponte de mensagens.
O objetivo de uma ponte de mensagens é transferir mensagens de um sistema de mensagens para outro. É exatamente isso que estamos fazendo com a complexidade adicional da comunicação intra-linguagem de Java para C ++. Podemos implementar o Messaging Bridge entre linguagens usando uma combinação de Channel Adapters e CORBA. Vamos construir dois servidores leves de adaptador de canal, um em C ++ gerenciando a comunicação com o TIB e um em Java gerenciando a comunicação com o JMS. Esses dois Adaptadores de Canal, que são os próprios Endpoint da Mensagem, se comunicarão entre si via CORBA. Como nossa escolha para o MQSeries, usaremos CORBA em vez de JNI, já que é um padrão da empresa. A ponte de mensagens implementa a tradução de mensagens efetivamente simulada entre sistemas de mensagens aparentemente incompatíveis e diferentes idiomas.
Tradutor de mensagens usando adaptadores de canal.
O diagrama a seguir mostra o design atual do sistema, incluindo os Gateways e outros componentes. Este é um bom exemplo de aplicação de padrões. Combinamos dois Channel Adapters com um protocolo sem mensagem para implementar o padrão Message Translator, usando efetivamente um padrão para implementar outro padrão. Além disso, alteramos o contexto do adaptador de canal s para vincular dois sistemas de mensagens a um protocolo de conversão de texto cruzado sem mensagem, em vez de conectar um sistema de mensagens a um sistema sem sistema de mensagens.
O sistema atual com os adaptadores de canal.
Estruturando Canais.
Uma chave para trabalhar com padrões não é apenas saber quando usar o padrão, mas também como usá-lo de maneira mais eficiente. Cada implementação de padrão deve levar em conta detalhes específicos da plataforma de tecnologia, bem como outros critérios de design. Esta seção aplica o mesmo processo de descoberta para encontrar o uso mais eficiente do Publish-Subscribe Channel no contexto do servidor de dados de mercado que se comunica com o mecanismo de análise.
Os dados de mercado em tempo real originam-se do feed de dados de mercado, um servidor C ++ que transmite dados de mercado no TIB. O feed de dados de mercado usa um canal de publicação separado para cada vínculo para o qual está publicando os preços. Isso pode parecer um pouco extremo, já que cada novo vínculo precisa de seu próprio novo canal. Mas isso não é tão grave, já que você não precisa criar canais no TIBCO. Em vez disso, os canais são referenciados por um conjunto hierárquico de nomes de tópicos chamados assuntos. O servidor TIBCO então filtra um único fluxo de mensagens por assunto, enviando cada assunto único para um único canal virtual. O resultado é um canal de mensagens muito leve.
Poderíamos criar um sistema que publicasse em alguns canais e os assinantes pudessem ouvir apenas os preços em que estivessem interessados. Isso exigiria que os assinantes usassem um Filtro de Mensagens ou Consumidor Seletivo para filtrar todo o fluxo de dados por preços de títulos interessantes, decidindo se cada mensagem deve ser processado conforme é recebido. Dado que os dados de mercado são publicados em canais dedicados a títulos, os assinantes podem se registrar para atualizações de uma série de títulos. Isso permite que os assinantes "filtrem" seletivamente assinando canais e recebendo apenas atualizações de interesse, em vez de decidir depois que a mensagem é recebida. É importante observar que o uso de vários canais para evitar a filtragem é um uso não padronizado de canais de mensagens. No contexto da tecnologia TIBCO, no entanto, estamos realmente decidindo se implementamos ou possuímos filtros ou utilizamos a filtragem de canais incorporada ao TIBCO - em vez de usar tantos canais.
O próximo componente que precisamos projetar é o mecanismo de análise, outro servidor C ++ / TIB que modificará os dados de mercado e o retransmitirá para o TIB. Embora esteja fora do escopo do nosso desenvolvimento Java / JMS, estamos trabalhando em conjunto com a equipe do C ++ para projetá-lo, já que somos o principal 'cliente' do mecanismo de análise. O problema em questão é encontrar a estrutura de canal que retransmite de maneira mais eficiente os dados de mercado recém-modificados.
Como já temos um Canal de Mensagem dedicado por vínculo herdado do feed de preço de dados de mercado, seria lógico modificar os dados de mercado e retransmitir os dados de mercado modificados no Canal de Mensagem dedicado de vínculo. Mas isso não funcionará, já que as análises que modificam os preços dos títulos são específicas do trader. Se retransmitirmos os dados modificados no Canal de Mensagens, destruiremos a integridade dos dados, substituindo dados genéricos de mercado por dados específicos do trader. Por outro lado, poderíamos ter um tipo de mensagem diferente para dados de mercado específicos do comerciante que publicamos no mesmo canal, permitindo que os assinantes decidam qual mensagem eles estão interessados ​​em evitar a destruição da integridade dos dados. Mas os clientes terão que implementar seus próprios filtros para separar as mensagens de outros comerciantes. Além disso, haverá um aumento substancial nas mensagens recebidas pelos assinantes, sobrecarregando-as desnecessariamente.
Existem duas opções:
Um canal por comerciante: Cada comerciante tem um canal designado para os dados de mercado modificados. Dessa forma, os dados originais do mercado permanecem intactos e cada aplicativo negociador pode ouvir o Canal de Mensagem de seus operadores específicos para as atualizações de preço modificadas. Um Canal por negociante por Obrigação: Crie um Canal de Mensagem por comerciante por título apenas para os dados de mercado modificados desse título. Por exemplo, os dados de mercado para o título ABC seriam publicados no canal "Bond ABC", enquanto os dados de mercado modificados para o comerciante A seriam publicados no Canal de Mensagens "Trader A, Bond ABC", dados de mercado modificados para o trader B no "Trader B , Bond ABC ", e assim por diante.
Um canal por trader.
Um canal por vínculo por trader.
Existem vantagens e desvantagens para cada abordagem. A abordagem por ligação, por exemplo, usa muito mais o Message Channel. Na pior das hipóteses, o número de canais de mensagens será o número total de títulos multiplicado pelo número de operadores. Podemos colocar limites superiores no número de canais que serão criados, uma vez que sabemos que existem apenas cerca de 20 traders e eles nunca têm preço superior a algumas centenas de títulos. Isso coloca o limite superior abaixo do intervalo de 10.000, o que não é tão estranho comparado aos quase 100.000 Message Channel que o feed de preço de dados de mercado está usando. Além disso, como estamos usando o TIB e o Message Channel são muito baratos, o número de Message Channel s não é um problema grave. Por outro lado, o grande número de canais de mensagens pode ser um problema do ponto de vista gerencial. Toda vez que um título é adicionado, um canal para cada negociador deve ser mantido. Isso pode ser grave em um sistema muito dinâmico. Nosso sistema, no entanto, é essencialmente estático. Também possui uma infraestrutura para gerenciar automaticamente os Message Channel. Isso combinado com a arquitetura herdada de um componente legado usando uma abordagem semelhante minimiza a desvantagem. Isso não quer dizer que devemos fazer um número desnecessariamente excessivo de MessageScan. Em vez disso, podemos implementar uma abordagem arquitetônica que usa um grande número de canais de mensagens quando há um motivo.
E há uma razão neste caso que se resume à localização da lógica. Se implementarmos a abordagem por negociador, o mecanismo do Google Analytics precisa de lógica para agrupar os canais de entrada e saída. Isso ocorre porque os canais de entrada do Mecanismo do Google Analytics são por vínculo e os canais de mensagens de saída seriam por comerciante, exigindo que o Mecanismo do Google Analytics direcione todas as entradas analíticas de múltiplos títulos para um determinado negociante para um Canal de mensagens de saída específico do negociante. Isso transforma efetivamente o mecanismo de análise em um roteador baseado em conteúdo para implementar a lógica de roteamento personalizada para nosso aplicativo.
Seguindo a estrutura do Message Bus, o Mecanismo do Analytics é um servidor genérico que pode ser usado por vários outros sistemas no. Portanto, não queremos obscurecer a funcionalidade específica do sistema. Por outro lado, a abordagem per-bond funciona desde que a ideia de um negociante que possui a saída analítica dos preços dos títulos é uma prática aceita pela empresa. A abordagem por ligação mantém intacta a separação do canal de mensagens do feed de dados de mercado, enquanto adiciona vários outros canais de mensagens. Antes de chegarmos ao cliente, queremos que um roteador baseado em conteúdo combine esses vários canais em um número gerenciável de canais. Não queremos que o aplicativo cliente em execução na área de trabalho do trader esteja ouvindo milhares ou dezenas de milhares de canais de mensagens. Agora a questão é onde colocar o roteador baseado em conteúdo. Poderíamos simplesmente ter o adaptador de canal C ++ / TIB encaminhando todas as mensagens para o gateway de preços em um único canal de mensagem. Isso é ruim por dois motivos; estaríamos dividindo a lógica de negócios entre C ++ e Java, e perderíamos o benefício dos Message Channel s separados no lado do TIB, o que nos permitiria evitar a filtragem mais tarde no fluxo de dados. Analisando nossos componentes Java, podemos colocá-lo no gateway de preços ou criar um componente intermediário entre o gateway de preços e o cliente.
Em teoria, se persistíssemos na separação baseada em títulos do Message Channel até o cliente, o Gateway de preços retransmitia informações de preço com a mesma estrutura de canal que o Gateway de preços e o Mecanismo do Google Analytics. Isso significa uma duplicação de todos os canais TIB dedicados à ligação no JMS. Mesmo se criarmos um componente intermediário entre o gateway de preços e o cliente, o gateway de preços ainda terá que duplicar todos os canais no JMS. Por outro lado, implementar a lógica diretamente no gateway de preços nos permite evitar a duplicação do grande número de canais no JMS - o que nos permite criar um número muito menor de canais na ordem de um por trader. O Gateway de Preços registra-se através do Adaptador de Canal C ++ / TIB como um consumidor para cada ligação de cada operador no sistema. Em seguida, o gateway de preços encaminhará cada cliente específico apenas as mensagens relacionadas a esse comerciante em particular. Dessa forma, usamos apenas um pequeno número de Message Channel no final do JMS, enquanto maximizamos o benefício da separação no final do TIB.
O Fluxo de Dados de Mercado completo para o cliente.
A discussão do layout do Message Channel é um bom exemplo de como a integração de padrões é importante. O objetivo aqui era descobrir como usar efetivamente os canais de mensagens. Dizer que você usa um padrão não é suficiente. Você precisa descobrir como melhor implementá-lo e incorporar em seu sistema para resolver os problemas em questão. Além disso, este exemplo mostra as forças de negócios em ação. Se pudéssemos implementar a lógica de negócios em qualquer um dos nossos componentes, poderíamos ter seguido a abordagem por negociador e implementado uma abordagem geral mais simples com muitos menos canais.
Selecionando um canal de mensagens?
Agora que conhecemos a mecânica da comunicação entre os componentes Java / JMS e os componentes C ++ / TIBCO, e vimos alguma estruturação do Canal de Mensagens, precisamos decidir qual tipo de Canal de Mensagens JMS os componentes Java devem usar para se comunicar. Antes de podermos escolher entre os diferentes canais de mensagem disponíveis no JMS, vejamos o fluxo de mensagens de alto nível do sistema. Temos dois gateways (Preços e Contribuição) comunicando-se com o cliente. Os dados de mercado são enviados para o cliente a partir do Gateway de preços, que os envia para o Contribution Gateway. O aplicativo cliente envia uma mensagem para o gateway de preços para alterar as análises aplicadas a cada vínculo. O Contribution Gateway também envia mensagens para o aplicativo Cliente, transmitindo o status das atualizações de preços para os diferentes locais de negociação.
O fluxo de mensagens do sistema.
A especificação JMS descreve dois tipos de Canal de Mensagem, Canal Ponto-a-Ponto (Fila JMS) e Canal de Publicação-Assinatura (Tópico JMS). Lembre-se de que o caso de usar publicação-assinatura é permitir que todos os consumidores interessados ​​recebam uma mensagem, enquanto o caso de usar ponto-a-ponto é garantir que apenas um consumidor qualificado receba uma mensagem em particular.
Muitos sistemas simplesmente transmitiam mensagens para todos os aplicativos clientes, deixando que cada aplicativo cliente individual decidisse por si mesmo se processaria ou não uma determinada mensagem. Isso não funcionará para nosso aplicativo, pois há um grande número de mensagens de dados de mercado sendo enviadas para cada aplicativo cliente. Se transmitirmos atualizações de dados de mercado para um trader desinteressado, estaremos desnecessariamente desperdiçando ciclos de processadores de clientes decidindo se processamos ou não uma atualização de dados de mercado.
Inicialmente, os canais ponto a ponto soam como uma boa escolha, já que os clientes estão enviando mensagens para servidores únicos e vice-versa. Mas era um requisito de negócios que os operadores pudessem estar logados em várias máquinas ao mesmo tempo. Se tivermos um trader logado em duas estações de trabalho simultaneamente e uma atualização de preço ponto-a-ponto for enviada, somente um dos dois aplicativos cliente receberá a mensagem. Isso ocorre porque apenas um consumidor em um canal ponto a ponto pode receber uma mensagem específica. Observe que apenas o primeiro de cada grupo de aplicativos clientes de um comerciante recebe a mensagem.
Mensagens ponto-a-ponto para atualizações de preços.
Podemos resolver isso usando o padrão Recipient List, que publica mensagens para uma lista de destinatários pretendidos, garantindo que apenas os clientes na lista de destinatários recebam mensagens. Usando esse padrão, o sistema poderia criar listas de destinatários com todas as instâncias do aplicativo cliente relacionadas a cada comerciante. Enviar uma mensagem relacionada a um determinado operador, por sua vez, enviaria a mensagem para cada aplicativo na lista de destinatários. Isso garante que todas as instâncias do aplicativo cliente relacionadas a um determinado operador recebam a mensagem. A desvantagem dessa abordagem é que ela requer um pouco de lógica de implementação para gerenciar os destinatários e despachar mensagens.
Lista de Destinatários para Atualizações de Preços.
Mesmo que o ponto-a-ponto possa funcionar, vamos ver se existe uma maneira melhor. Usando Publish-Subscribe Channel s, o sistema pode transmitir mensagens em canais específicos do comerciante, em vez de canais específicos de aplicativos do cliente. Desta forma, todas as aplicações do cliente processando mensagens para um único operador receberiam e processariam a mensagem.
Publicação-Assinatura de Mensagens para Atualizações de Preços.
A desvantagem de usar Publish-Subscribe Channel s é que o processamento exclusivo de mensagens não é garantido com os componentes do servidor. Seria possível que várias instâncias de um componente de servidor fossem instanciadas e cada instância processasse a mesma mensagem, possivelmente enviando preços inválidos.
Recordando o fluxo de mensagens do sistema, apenas uma única direção de comunicação é satisfatória com cada Canal de Mensagem. A comunicação servidor-cliente com publicação-assinatura é satisfatória, enquanto a comunicação cliente-servidor não é e a comunicação cliente-servidor com ponto-a-ponto é satisfatória, enquanto o servidor-cliente não é satisfatório. Como não há necessidade de usar o mesmo Message Channel em ambas as direções, podemos usar cada Message Channel apenas em uma direção. A comunicação de cliente para servidor será implementada com ponto a ponto, enquanto a comunicação servidor a cliente será implementada com publicação-assinatura. Usando essa combinação de Message Channel, o sistema se beneficia da comunicação direta com os componentes do servidor usando o sistema de mensagens ponto-a-ponto e a natureza multicast da publicação-assinatura sem nenhum dos inconvenientes.
Fluxo de mensagens com tipos de canais.
Solução de problemas com padrões.
Padrões são ferramentas e coleções de padrões são caixas de ferramentas. Eles ajudam a resolver problemas. Alguns pensam que os padrões são úteis apenas durante o design. Seguindo a analogia da caixa de ferramentas, isso é como dizer que as ferramentas são úteis apenas quando você constrói uma casa, não quando você a conserta. O fato é que os padrões são uma ferramenta útil em todo o projeto, quando bem aplicados. Nas seções a seguir, usaremos o mesmo processo de exploração de padrão que utilizamos na seção anterior para resolver problemas em nosso sistema atual.
Atualizações de dados de mercado piscando.
Os traders querem que as células da mesa pisquem quando novos dados de mercado são recebidos por um título, indicando claramente mudanças. O cliente Java recebe mensagens com novos dados que acionam uma atualização do cache de dados do cliente e, eventualmente, piscam na tabela. O problema é que as atualizações vêm com bastante frequência. A pilha de threads da GUI está ficando sobrecarregada e, eventualmente, congelando o cliente, já que ele não pode responder à interação do usuário. Vamos supor que o flash é otimizado e se concentrar no fluxo de dados das mensagens através do processo de atualização. Um exame dos dados de desempenho mostra que o aplicativo cliente está recebendo várias atualizações por segundo; algumas atualizações ocorreram com menos de um milissegundo de intervalo. Dois padrões que parecem ajudar a desacelerar o fluxo de mensagens são Agregador e Filtro de Mensagens.
Um primeiro pensamento é implementar um Filtro de Mensagens para controlar a velocidade do fluxo de mensagens, lançando as atualizações recebidas por um curto período de tempo após a mensagem de referência. Por exemplo, vamos dizer que vamos ignorar mensagens dentro de 5 milissegundos um do outro. O Filtro de Mensagens pode armazenar em cache a hora da última mensagem aceitável e rejeitar qualquer coisa recebida nos próximos 5 milissegundos. Embora outras aplicações possam não ser capazes de resistir à perda de dados de tal forma, isso é perfeitamente aceitável em nosso sistema devido à frequência de atualizações de preços.
Filtro de mensagens baseado em tempo.
O problema com essa abordagem é que nem todos os campos de dados são atualizados ao mesmo tempo. Cada título possui aproximadamente 50 campos de dados exibidos ao usuário, incluindo o preço. Percebemos que nem todo campo é atualizado em todas as mensagens. Se o sistema ignorar mensagens consecutivas, pode muito bem estar jogando dados importantes.
O outro padrão de interesse é o Agregador. O Agregador é usado para gerenciar a reconciliação de várias mensagens relacionadas em uma única mensagem, reduzindo potencialmente o fluxo de mensagens. O Agregador pode manter uma cópia dos dados de ligação da primeira mensagem agregada e, em seguida, atualizar apenas as mensagens sucessivas de campos novos ou alterados. Eventualmente, os dados de ligação agregados serão passados ​​em uma mensagem para o cliente. Por enquanto, vamos supor que o Agregador enviará uma mensagem a cada 5 milissegundos, como o Filtro de Mensagens. Mais tarde, vamos explorar outra alternativa.
Agregador com atualizações sucessivas parciais.
O Agregador, como qualquer outro padrão, não é uma bala de prata; tem suas vantagens e desvantagens que precisam ser exploradas. Um potencial menos é que a implementação de um Agregador reduziria o tráfego de mensagens em grande quantidade em nosso caso apenas se muitas mensagens estivessem chegando em um tempo relativamente curto em relação ao mesmo vínculo. Por outro lado, não conseguiríamos nada se o cliente Java receber apenas atualizações para um campo em todos os títulos de traders. Por exemplo, se recebermos 1000 mensagens em um período de tempo especificado com 4 títulos de interesse, reduziríamos o fluxo de mensagens de 1.000 para 4 mensagens durante esse período. Alternativamente, se recebermos 1000 mensagens no mesmo período com 750 títulos de interesse, teremos reduzido o fluxo de mensagens de 1.000 para 750 mensagens; relativamente pouco ganho para a quantidade de esforço. Uma análise rápida das atualizações de mensagens prova que o cliente Java recebe muitas mensagens atualizando campos do mesmo vínculo e, portanto, mensagens relacionadas. Então, Agregador é na verdade uma boa decisão.
O que resta é determinar como o Agregador saberá quando enviar uma mensagem que está agregando. O padrão descreve alguns algoritmos para o Agregador saber quando enviar a mensagem. Estes incluem algoritmos para fazer com que o agregador envie seu conteúdo após um determinado período de tempo, após todos os campos obrigatórios em um conjunto de dados terem sido concluídos, e outros. O problema com todas essas abordagens é que o agregador está controlando o fluxo de mensagens, não o cliente. E o cliente é o maior gargalo nesse caso, não o fluxo de mensagens.
Isso ocorre porque o Agregador está supondo que os consumidores de suas mensagens eliminadas (o aplicativo cliente, nesse caso) são consumidores orientados a eventos ou consumidores que dependem de eventos de uma fonte externa. Precisamos transformar o cliente em um Consumidor de pesquisa ou em um consumidor que verifica continuamente as mensagens, para que o aplicativo cliente possa controlar o fluxo de mensagens. Podemos fazer isso criando um thread em segundo plano que percorre continuamente o conjunto de ligações e atualizações e exibe todas as alterações que ocorreram desde a última iteração. Dessa forma, o cliente controla quando as mensagens são recebidas e, como resultado, garante que elas nunca ficarão sobrecarregadas com mensagens durante os períodos de alta atualização. We can easily implement this by sending a Command Message to the Aggregator initiating an update. 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 couldn’t 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 don’t 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.
Gregor Hohpe and Bobby Woolf.
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.

Sistemas de Negociação: Projetando Seu Sistema - Parte 1.
A seção anterior deste tutorial analisou os elementos que compõem um sistema de negociação e discutiu as vantagens e desvantagens de usar um sistema desse tipo em um ambiente de negociação ao vivo. Nesta seção, construímos esse conhecimento examinando quais mercados são especialmente adequados para o sistema de negociação. Vamos, então, dar uma olhada mais profunda nos diferentes gêneros de sistemas de negociação.
O mercado acionário é provavelmente o mercado mais comum para o comércio, especialmente entre os novatos. Nessa arena, grandes jogadores como Warren Buffett e Merrill Lynch dominam, e as estratégias tradicionais de investimento em valor e crescimento são, de longe, as mais comuns. No entanto, muitas instituições investiram significativamente na concepção, desenvolvimento e implementação de sistemas de negociação. Investidores individuais estão aderindo a essa tendência, embora lentamente.
A grande quantidade de ações disponíveis permite que os investidores testem sistemas em muitos tipos diferentes de ações - tudo, desde ações de balcão extremamente voláteis (OTC) a blue chips não voláteis.
A eficácia dos sistemas de negociação pode ser limitada pela baixa liquidez de algumas ações, especialmente as questões de balcão e folha-de-rosa.
As comissões podem consumir lucros gerados por negócios bem-sucedidos e podem aumentar as perdas. OTC e ações de folha-de-rosa freqüentemente incorrem em comissões adicionais.
Os principais sistemas de negociação utilizados são aqueles que buscam valor - ou seja, sistemas que usam parâmetros diferentes para determinar se um título está subvalorizado em comparação com seu desempenho passado, seus pares ou o mercado em geral.
O mercado de câmbio, ou forex, é o maior e mais líquido mercado do mundo. Os governos, bancos e outras grandes instituições do mundo negociam trilhões de dólares no mercado forex todos os dias. A maioria dos traders institucionais no forex depende de sistemas de negociação. O mesmo vale para os indivíduos no forex, mas alguns negócios são baseados em relatórios econômicos ou pagamentos de juros.
A liquidez neste mercado - devido ao enorme volume - torna os sistemas de negociação mais precisos e eficazes.
Não há comissões neste mercado, apenas se espalha. Portanto, é muito mais fácil fazer muitas transações sem aumentar os custos.
Em comparação com a quantidade de ações ou mercadorias disponíveis, o número de moedas a negociar é limitado. Mas por causa da disponibilidade de "pares de moedas exóticas" - isto é, moedas de países menores - o intervalo em termos de volatilidade não é necessariamente limitado.
Os principais sistemas de negociação utilizados no forex são aqueles que seguem as tendências (um ditado popular no mercado é "a tendência é seu amigo"), ou sistemas que compram ou vendem em breakouts. Isso ocorre porque os indicadores econômicos geralmente causam grandes movimentos de preços de uma só vez.
Os mercados de ações, forex e commodities oferecem negociação de futuros. Este é um veículo popular para o sistema de negociação por causa da maior quantidade de alavancagem disponível e da maior liquidez e volatilidade. No entanto, esses fatores podem cortar os dois lados: eles podem amplificar seus ganhos ou amplificar suas perdas. Por esta razão, o uso de futuros é geralmente reservado para os operadores avançados de sistemas individuais e institucionais. Isso ocorre porque os sistemas de negociação capazes de capitalizar no mercado futuro exigem uma customização muito maior, usam indicadores mais avançados e demoram muito mais para serem desenvolvidos.
Cabe ao investidor individual decidir qual mercado é mais adequado ao sistema de negociação - cada um tem suas próprias vantagens e desvantagens. A maioria das pessoas está mais familiarizada com os mercados de ações e essa familiaridade facilita o desenvolvimento de um sistema de negociação. No entanto, o forex é comumente pensado para ser a plataforma superior para executar sistemas de negociação - especialmente entre os comerciantes mais experientes. Além disso, se um comerciante decidir capitalizar o aumento da alavancagem e volatilidade, a alternativa de futuros estará sempre aberta. Em última análise, a escolha está nas mãos do desenvolvedor do sistema.
O método mais comum de negociação do sistema é o sistema de acompanhamento de tendências. Em sua forma mais fundamental, esse sistema simplesmente espera por um movimento significativo de preços, depois compra ou vende nessa direção. Este tipo de sistema espera que esses movimentos de preços mantenham a tendência.
Média móvel de sistemas.
Frequentemente usado em análise técnica, uma média móvel é um indicador que simplesmente mostra o preço médio de um estoque durante um período de tempo. A essência das tendências é derivada dessa medida. A maneira mais comum de determinar a entrada e a saída é um cruzamento. A lógica por trás disso é simples: uma nova tendência é estabelecida quando o preço cai acima ou abaixo de sua média histórica de preço (tendência). Aqui está um gráfico que representa tanto o preço (linha azul) quanto o MA de 20 dias (linha vermelha) da IBM:
O conceito fundamental por trás desse tipo de sistema é semelhante ao de um sistema de média móvel. A ideia é que, quando uma nova alta ou baixa é estabelecida, é mais provável que o movimento do preço continue na direção da fuga. Um indicador que pode ser usado na determinação de fugas é um simples Bollinger Band & reg; sobreposição. Bollinger Bands & reg; mostra médias de preços altos e baixos, e breakouts ocorrem quando o preço atinge as margens das bandas. Aqui está um gráfico que traça o preço (linha azul) e Bollinger Bands & reg; (linhas cinza) da Microsoft:
Desvantagens dos sistemas de acompanhamento de tendências:
Tomada de Decisão Empírica - Ao determinar as tendências, há sempre um elemento empírico a considerar: a duração da tendência histórica. Por exemplo, a média móvel poderia ser nos últimos 20 dias ou nos últimos cinco anos, portanto, o desenvolvedor deve determinar qual é a melhor para o sistema. Outros fatores a serem determinados são os altos e baixos médios em sistemas de fuga.
Natureza atrasada - As médias móveis e os sistemas de fuga estarão sempre atrasados. Em outras palavras, eles nunca podem atingir a parte superior ou inferior de uma tendência. Isso inevitavelmente resulta em uma perda de lucros potenciais, que às vezes podem ser significativos.
Wipsaw Effect - Entre as forças do mercado que são prejudiciais ao sucesso dos sistemas de acompanhamento de tendências, este é um dos mais comuns. O efeito whipsaw ocorre quando a média móvel gera um sinal falso - ou seja, quando a média cai apenas no intervalo, então, de repente, inverte a direção. Isso pode levar a perdas massivas, a menos que técnicas eficazes de interrupção de perdas e gerenciamento de risco sejam empregadas.
Mercados Sideways - Sistemas de acompanhamento de tendências são, por natureza, capazes de ganhar dinheiro apenas em mercados que realmente fazem tendência. No entanto, os mercados também se movem para os lados, permanecendo dentro de um determinado intervalo por um longo período de tempo.
Pode ocorrer extrema volatilidade - Ocasionalmente, os sistemas de acompanhamento de tendências podem experimentar extrema volatilidade, mas o profissional deve manter seu sistema. A incapacidade de fazer isso resultará em falha garantida.
Basicamente, o objetivo do sistema de tendência de contração é comprar na baixa mais baixa e vender na máxima alta. A principal diferença entre este e o sistema de acompanhamento de tendência é que o sistema de tendência contrária não é autocorretivo. Em outras palavras, não há tempo definido para sair de posições, e isso resulta em um potencial de queda ilimitado.
Tipos de sistemas de tendência contrária.
Muitos tipos diferentes de sistemas são considerados sistemas de contra-tendência. A ideia aqui é comprar quando o momentum em uma direção começa a desaparecer. Isso é mais frequentemente calculado usando osciladores. Por exemplo, um sinal pode ser gerado quando os stochastics ou outros indicadores de força relativa caem abaixo de certos pontos. Existem outros tipos de sistemas de negociação de tendência de contração, mas todos eles compartilham o mesmo objetivo fundamental - comprar baixo e vender alto.
Tomada de Decisão Ética - Por exemplo, um dos fatores que o desenvolvedor do sistema deve decidir são os pontos nos quais os indicadores de força relativa desaparecem.
Volatilidade Extrema Pode Ocorrer - Esses sistemas também podem experimentar alguma volatilidade extrema, e a incapacidade de manter o sistema apesar dessa volatilidade resultará em falha garantida.
Downside Ilimitado - Como mencionado anteriormente, existe um potencial de downside ilimitado porque o sistema não é autocorretor (não há tempo definido para sair de posições).
Os principais mercados para os quais os sistemas de negociação são adequados são os mercados de ações, forex e futuros. Cada um desses mercados tem suas vantagens e desvantagens. Os dois principais gêneros de sistemas de negociação são os sistemas de acompanhamento de tendência e de contra-tendência. Apesar de suas diferenças, os dois tipos de sistemas, em seus estágios de desenvolvimento, exigem uma tomada de decisão empírica por parte do desenvolvedor. Além disso, esses sistemas estão sujeitos a extrema volatilidade e isso pode exigir alguma resistência - é essencial que o operador do sistema mantenha seu sistema durante esses períodos. Na próxima parte, daremos uma olhada mais de perto em como projetar um sistema de negociação e discutir alguns dos softwares que os operadores de sistema usam para facilitar suas vidas.

Sistemas de negociação de títulos.
Como os sistemas de negociação de títulos funcionam.
The Service Platform.
E-trading depends on data being shared between services. A service platform that facilitates easy data sharing and service management is essential to building a successful bond trading system. This article describes the core fundamental requirements of the service platform and why they are so important.
Service Access Protocol.
A service supports a particular business process, it provides access to data and functions that are specific to the business process. Typically the data produced by a service needs to be accessed by multiple clients on remote machines. The clients can be applications or other services. A service should not make a distinction between the type of client accessing it; all access is treated in the same way. The way in which a service makes data available and the format of the data is called the service access protocol . All services should use the same access protocol so that a client can connect to any service using the same protocol. A common service access protocol is the backbone of the service platform concept. When all services support the same access protocol, they share a common design and form the foundation of a service platform.
The diagram below helps to illustrate the components of the service access protocol.
Data Access Patterns.
A service provides access to data using one of three patterns:
For each of these, data is published in the form of messages. A message is generally published when an update occurs to a data entity. All three of these patterns can be considered real-time data access patterns. Real-time in this context means the data response is provided as fast as possible with no introduced delays. The service access protocol needs to support these access patterns.
Blind-publish.
This describes the pattern where a service unilaterally publishes data for any client to receive, regardless of whether there is any client that is actually interested in the data. Blind-publishing can be very inefficient, particularly for highly volatile data, as network bandwidth is taken up publishing messages with potentially no clients using the data. Data published using this pattern is always a complete image for each and every update. Multiple clients can receive the same message. Heartbeats (signals published by a service to indicate they are on-line) are one example of the blind-publish data access pattern.
Subscribe-publish.
This pattern requires a service to publish data for a specific entity only when one or more clients subscribe for the entity. This requires that the data has some form of unique identification for each entity. A service will need to track what clients have subscribed for what data entities. A heart-beating mechanism is also required for services to monitor clients. A service stops publishing data for an entity when there are no more clients subscribed for the data entity. This can happen if a client suddenly stops or sends a request to unsubscribe from the data entity. The heart-beating mechanism is used by the service to detect when a client stops unexpectedly. When a client subscribes for data in this way it should, generally, be able to expect an initial version of the data entity that the service has. This initial version might be the current state of the data or a ‘blank’ state which can indicate that the data is not available in the service.
If the service supports publishing deltas, then an image-on-subscribe capability also is needed. The term ‘delta’ describes only publishing changes in the data, not the complete image. This can provide substantial network bandwidth savings as, in general, not all attributes of an entity change all the time. The image-on-subscribe concept refers to the client receiving the initial image of the data entity as its first update and then after this only receiving the deltas. The deltas can be applied on top of the initial image to resolve the current state of the data entity. All messages published for a data entity will need a sequence number. This allows the client to detect any out-of-order messages and is also critical to being able to apply deltas on top of the received image. The image itself must have a sequence that can be identified within a stream of delta messages for the entity. The same delta message can be received by multiple clients.
The subscribe-publish pattern is essential when a service can have a potentially large data universe and expects that at any point in time only a portion of the universe will be subscribed for by clients. This makes the network utilisation more efficient and allows the service to conserve its resources.
Request-response.
A request-response pattern provides the capability for a client to be able to receive a response to a request sent to the service. In general, the service response is only directed at the requesting client; other clients do not see the response message. This access pattern is typically used for clients to invoke functions on services. The request message identifies the function to invoke along with any arguments for the function. The response from the service will contain the result from invoking the function. However, this access pattern can also be used to request images or receive on-shot data upon request by the client.
This pattern requires some form of timeout logic in the client. When a client sends a request it generally starts a countdown for a response. If the response does not arrive within the countdown the client determines that the request has failed. This is a basic way to handle the request timings. An improvement is for the service to send back a signal when it receives the message, another signal when it starts to process the message and then finally send the response. If the client has a separate countdown for each of these phases in the request-response then more fine-grain control is achievable and timeout situations can be tuned out. As an example, if a service takes 0.2 seconds to process a message but, due to the number of requests, each request takes 0.9 seconds before it starts to be processed, then a client with a simple 1 second timeout would fail each request (each request would appear to take 1.1 seconds). However, if the client observed a 1 second start timeout and a 0.5 second processing timeout then the requests would succeed.
Data Format.
The service access protocol also defines what the data looks like, its format. This is very important so that the data is universally understandable by all connecting clients. Translating between data formats is costly, in terms of development and maintenance timescales and runtime processing resources. Therefore a critical aspect for all services is to have a common data format.
Data format defines the rules for how the data is structured and the type of the data values. The structure defines how to understand what the data is representing. If the structure is understood, then the data values can be interpreted in the correct context, e. g. the value 123.45 can be correctly interpreted as the bid price, say, rather than the ask price, because the structure is understood. Generally, data structures fall into one of these categories:
dictionary – this is the key-value structure where every data value is identified with a unique key. This type of structure is very fast for reading and writing sparse data. Sending data changes (deltas) is most efficient when the structure is dictionary-based. hierarchy – data is expressed in a hierarchical manner, e. g. XML. It is generally quite verbose. Data structures that are hierachy-based tend to be more complex to process then dictionary-based ones and are not as fast as a dictionary-based equivalent.
There is a hybrid category where a dictionary-based structure uses hierarchy within the keys to achieve a middle-ground solution. As an example, keys can be “.” separated to provide for an address space like, “foo. bar.1”, “foo. bar.2”, say.
Regardless of the data structure, there has to be a defined range of types that the data values can express. The types allow the data to be interpreted in its correct form, e. g. a string or a number or a binary stream. The basic data types that need to be supported are:
text floating-point numbers integer numbers binary stream images (blobs)
Supporting these 4 data types allows for any real-world data value to be correctly represented.
Service Platform Features.
The data access protocol for a service is supported by some form of messaging technology. However, messaging technology only solves the “plumbing” problem of how to get data from one endpoint to another. The service infrastructure for bond trading requires more than just messaging technology for a common service access protocol, it also needs the capability for:
discovery and monitoring of services – allows functionality to be controlled depending on availability of business services discovery of data available from services – allows functionality to react when specific data is ready discovery of when clients subscribe for data – allows resources to be activated only when there is a need to support a client subscription (e. g. starting data feeds only when a client starts a subscription for the feed) inspection of service state – allows support teams to be able to know when a service is in trouble and take action to fix it viewing of data in a service – allows support teams to be able to diagnose data problems by viewing the data at source permissioning of data – supports data security/fee requirements by preventing unauthorised clients from receiving data controlling data publishing rates (throttling) – protects the environment from high publish rates that can overload clients and hardware resources remote control of services – provides the capability to change service status and settings without needing to disrupt the service high-availability for services – replaces a service that stops unexpectedly with a backup service.
All these capabilities should be provided by a common framework that all services are built upon. This common framework is the service platform . By designing a framework that has these features and supports services and clients that use the same messaging technology, a truly robust and extensible technology solution platform is provided for bond trading.
Why use a service platform?
It is possible to have all the capabilities listed above by not using a service platform, however the features tend to be retro-fitted onto existing designs, sometimes only being applied to certain services, othertimes different technologies are used for the same feature in different services. Eventually the service landscape becomes a heterogeneous mix-n-match of different designs and technologies that ultimately may provide the core features of a service platform but at the expense of unified architecture and increase maintenance costs. Using a service platform to build a bond trading system provides reduced development and maintenance costs and timescales; development can focus on the business logic of the services/clients rather than the infrastructure concerns.
The diagram below helps to illustrate how using a service platform architecture simplifies the access to services. With a service platform, clients only need a single interface to access all services, whereas a non service platform design requires the client to use a different interface depending on the service being accessed. A separate interface per service introduces complexity because, generally, the interfaces use different technologies which increases the resources required for development and maintenance.
A service platform also benefits the user-interface design of a bond trading system. The user-interface (UI) is usually a grouping of various visual displays and controls across different services. If all the services share the same messaging technology and data structure then the UI components become standard across all services. Specialised versions can be created that exist purely for business reasons rather than technical and ultimately all components share a common interface pattern to the business services.
Ao fechar & # 8230;
This article has introduced the concept of the service platform and highlighted its architectural importance. Building a service platform is not a trivial undertaking. There are only a few commercially available options and even fewer open-source ones. The ClearConnect platform is an open-source example that provides all the capabilities described in this article. This platform will be used as a reference platform for building examples of the services in later articles.

Bond trading system architecture

negociação eletrônica de renda fixa -
soluções para negócios.
Sistema de negociação de buy-side vencedor do ano no FOW International Awards de 2017.
AxeTrader traz seus locais de negociação de renda fixa e fontes de liquidez juntos em um único aplicativo de negociação - para maior eficiência e melhor execução.
O AxeTrader é o primeiro e mais avançado sistema de gerenciamento de execução de renda fixa projetado para o propósito.
Mais de 90% dos nossos clientes referem a AxeTrading.
para novos clientes.
Dentro de 1 mês de ir ao vivo com AxeTrader,
uma corretora baseada em Londres viu os negócios aumentarem.
de uma média de 30 a mais de 150 por dia.
Um comerciante líder regional de renda fixa.
melhorou a capacidade de negociação e economizou milhares de dólares por ano.
escolhendo AxeTrader como sua solução de mercado.
Sistema de gerenciamento de pedidos & amp; integração de múltiplas plataformas de negociação, fluxo de trabalho de negociação e melhores ferramentas de execução, relatórios, automação pós-negociação.
Balcões de execução e negociação de agência:
Roteiro de ordens de clientes e fluxo de trabalho de execução;
integração com o Bloomberg TSOX & lt; Go & gt;
Folhas de preços poderosas, configuráveis ​​pelo usuário,
cotação automática, reserva de comércio de voz,
processamento direto.
A AxeTrading® é especializada no fornecimento de soluções tecnológicas eficazes para os desafios enfrentados pelos investidores e comerciantes de renda fixa nos mercados atuais.
Nossas pessoas experientes e nossas soluções exclusivas permitem que os clientes da AxeTrading implementem suas estratégias de negociação eletrônica de renda fixa com sucesso e orçamento. Eles permitem que nossos clientes atendam aos desafios impostos pela liquidez fragmentada, regulamentação (incluindo MiFID2, EMIR, Dodd-Frank e Basileia III) e pela demanda por maior eficiência.
'Axe': O interesse de uma pessoa ou comerciante em comprar ou vender uma garantia de renda fixa.
Um comerciante pode ter interesse específico em um determinado título de renda fixa com base em suas posições de negociação.
Pode-se dizer que essa pessoa é 'Axed' nessa segurança.
As soluções inovadoras e exclusivas da AxeTrading permitem que tanto negociantes de renda fixa do lado da compra quanto do lado da venda aproveitem o comércio eletrônico de renda fixa; eles agilizam o fluxo de trabalho, reduzem o risco operacional e facilitam a conformidade regulatória.
Nossas soluções permitem a geração de relatórios e ajudam nossos clientes a extrair insights de negócios valiosos de suas atividades de negociação. O pessoal da AxeTrading tem décadas de experiência na indústria de TI financeira. O atendimento ao cliente de qualidade também é parte integrante de nossa oferta.
Referências podem ser obtidas de nossos clientes existentes, se necessário.
razões pelas quais AxeTrading.
vai te dar a vantagem.
A AxeTrading fornece agregação de múltiplas plataformas de renda fixa, incluindo OTC, Exchanges, SEF.
O AxeTrader suporta a melhor execução e conformidade com o MiFID2. Compare os preços de várias fontes e rastreie automaticamente o mercado durante a vida útil do pedido.
A AxeTrading fornece soluções de negociação eletrônica de renda fixa que atendem às necessidades de ambos.
compra e venda.
Temos décadas de experiência em negociação eletrônica de renda fixa;
somos capazes de aconselhar e ajudar nossos clientes.
A AxeTrading constrói parcerias tecnológicas com nossos clientes. Trabalhamos com eles para implementar sistemas de e-trading de renda fixa eficazes & amp; estratégias.
Poderosas planilhas de preços configuráveis ​​pelo usuário, incluindo cálculos personalizados, preços condicionais, alertas definidos pelo usuário / condições off-line, & amp; características de segurança.
AxeTrading integra-se com sistemas internos e externos para captura de comércio automatizado & amp; relatórios (straight-through-processing ou 'STP')
Serviço especializado & amp; suporte estão incluídos no AxeTrader.
Fácil de usar, eficiente e flexível;
O AxeTrader é baseado nas mais recentes tecnologias Java e implementado em sua organização.
Implementação direta de um disco ou download; assistência incluída.
Requisito mínimo de hardware.
O AxeTrader é um sistema abrangente com um tamanho compacto.
Inclui serviço e suporte.
A AxeTrading faz parcerias com nossos clientes para fornecer soluções eficazes,
no tempo e no orçamento.
Sistema flexível e fácil de usar; auto-configurável - economiza custos.
Escalável de 2 comerciantes.
para a empresa global.
Recursos de segurança integrados em todo o AxeTrader.
Mecanismo de precificação poderoso e flexível - os traders podem configurar e gerenciar a si mesmos.
As soluções da AxeTrading se integram com sistemas de gerenciamento de pedidos e back office, bem como múltiplas plataformas de negociação de renda fixa e fontes de preços.
Nossas soluções unem seus fluxos de trabalho de renda fixa e liquidez em um único aplicativo de desktop para uma negociação mais eficiente e melhor execução.
A integração pós-negociação com locais de relatórios regulatórios, incluindo o TRACE / FINRA, custodiantes e agências de compensação, agiliza ainda mais a negociação.
tipos de conectividade fornecidos pela AxeTrader.
para negociação eficiente de renda fixa.
Integração do Bloomberg VCON;
Confirmação de comércio de voz via web;
Confirmação comercial FIX;
Bloomberg FIT, TSOX;
MarketAxess (incl. Negociação Aberta);
Integração com as principais trocas (FIX)
Integração e Integração Múltipla do SEF.
Integração com o Sistema de Gerenciamento de Pedidos da sua empresa (FIX):
Fluxo de trabalho solicitado ou não solicitado.
Integrar quaisquer dados (quando permitido);
A AxeTrading possui Parcerias de Dados com fornecedores de dados de renda fixa líderes para garantir a rápida & amp; integração fácil.
Integração com middle & amp; sistemas de back office, incluindo Bloomberg TOMS, MUREX, Kondor +;
Integração pós-negociação com custodiantes, despachantes, relatórios normativos incluindo TRACE / FINRA.
Nossos clientes são traders de renda fixa, incluindo as empresas sell-side e buy-side, que buscam formas novas ou mais eficientes de negociar ou distribuir sua liquidez de renda fixa.
através de redes de comércio eletrônico de renda fixa.
Nossa tecnologia ajuda nossos clientes a se adaptarem efetivamente ao impacto crescente das regulamentações nos mercados de renda fixa, incluindo MiFID, Basel III, Dodd-Frank e outros.
O QUE ELES DIZEM SOBRE NÓS
Martin Richardson - Mercado de Capitais de Dívida no Rand Merchant Bank.
& quot; Depois de avaliar várias alternativas, selecionamos a AxeTrader porque elas forneceram uma solução personalizada para nós, portanto, não pagamos por nenhuma funcionalidade supérflua. O resultado final é que AxeTrader nos forneceu um ótimo produto que é extremamente rentável e perfeito para as nossas necessidades individuais & quot;
Richard Boast, chefe da Sterling Credit Trading na Cannaccord Genuity.
"Para cumprir nossa exigência de negociar títulos eletronicamente via Bloomberg, analisamos as opções disponíveis para nós e favorecemos a AxeTrading e sua solução AxeTrader. Isso forneceu uma maneira eficiente de negociar e também aumentou a visibilidade da Cannaccord Genuity com clientes no mercado. Aguardo com expectativa uma parceria longa e saudável com a AxeTrading no futuro. & Quot;
Dinos co-fundou a AxeTrading em 2009 e tem mais de 25 anos de experiência em corretagem de renda fixa, vendas e comércio eletrônico.
Sua experiência anterior inclui, entre outros, um papel sênior em vendas eletrônicas de crédito no Citigroup e uma renda fixa.
função de especialista em vendas de negociantes de negociação eletrônica na Bloomberg; ambas as posições mantidas em Londres por 5 e 7 anos, respectivamente.
Tendo adquirido mais de 16 anos de experiência em operações de renda fixa / recompra e corretagem eletrônica, o profundo conhecimento técnico e de negócios da Dinos neste setor lhe rendeu uma sólida reputação entre seus pares, colegas e clientes.
Co-fundador da AxeTrading, Ralf tem mais de 15 anos de experiência em negociação eletrônica de renda fixa e é responsável pelo desenvolvimento de tecnologia e software na AxeTrading.
Graduado em Engenharia de Computação, sua experiência passada.
inclui o projeto e a implementação de sistemas de precificação e negociação de renda fixa sob medida para o JP Morgan e outros principais distribuidores de renda fixa.
Ralf é um desenvolvedor de negócios estratégicos com familiaridade de mercados de negociação em diferentes países. Antes de co-fundar a AxeTrading, ele contribuiu para o start-up e desenvolvimento de várias outras empresas de tecnologia de negociação de renda fixa bem-sucedidas, cada uma das quais continua sendo bem-sucedida nos negócios de hoje.
Mark é responsável pelo desenvolvimento de negócios da AxeTrading desde que ingressou na equipe em 2011.
Ele tem mais de 17 anos de experiência na Bloomberg, incluindo cargos seniores em negociação eletrônica de renda fixa.
Mark ganhou experiência especializada em.
venda e implementação de sistemas de leilão de títulos, plataformas de negociação e sistemas de negociação de renda fixa de mercado primário e secundário em mercados desenvolvidos e emergentes.
Ele trabalhou com tesouros nacionais, emissores e com o setor de compra e venda implementando transações eletrônicas de renda fixa em muitos países ao redor do mundo. Mark traz experiência adicional de negociação eletrônica de renda fixa em profundidade para a equipe AxeTrading.
Engenheiro de software senior.
Hannes faz parte da equipe AxeTrading desde 2010 e é engenheiro de software sênior. Com um mestrado em Ciência da Computação e mais de 10 anos de experiência em sistemas de negociação eletrônica de renda fixa, ele lidera o desenvolvimento de software.
e equipe de testes da AxeTrading.
Com uma sólida compreensão de negócios e tecnologia, sua experiência inclui design de produtos para negociação eletrônica de títulos, FX e Derivativos, bem como avaliação e implementação de sistemas de dados de mercado.
O conjunto de habilidades de Hannes permite que a AxeTrading responda com rapidez e precisão aos requisitos de nossos clientes.
A AxeTrading Limited está baseada em Londres e registrada na Inglaterra e no País de Gales.
Sede: Craven House, 16 Northumberland Avenue - Londres, WC2N 5AP (UK) | Número de registo da empresa: 06721631.
© Copyright AxeTrading® 2016. AxeTrading é uma marca registrada. Todos os direitos reservados.

Sistemas de Negociação: O que é um sistema de negociação?
Um sistema de negociação é simplesmente um grupo de regras específicas, ou parâmetros, que determinam pontos de entrada e saída para um determinado patrimônio. Esses pontos, conhecidos como sinais, são frequentemente marcados em um gráfico em tempo real e solicitam a execução imediata de uma negociação.
Médias móveis (MA) Osciladores estocásticos Força relativa Bollinger Bands & reg; Muitas vezes, duas ou mais dessas formas de indicadores serão combinadas na criação de uma regra. Por exemplo, o sistema crossover MA usa dois parâmetros de média móvel, a longo prazo e a curto prazo, para criar uma regra: "compre quando o curto prazo ultrapassar o longo prazo e venda quando o oposto for verdadeiro". Em outros casos, uma regra usa apenas um indicador. Por exemplo, um sistema pode ter uma regra que proíbe qualquer compra, a menos que a força relativa esteja acima de um determinado nível. Mas é uma combinação de todos esses tipos de regras que fazem um sistema comercial.
Como o sucesso do sistema geral depende de quão bem as regras funcionam, os comerciantes do sistema gastam otimizar o tempo para gerenciar o risco, aumentar o valor obtido por comércio e alcançar estabilidade a longo prazo. Isso é feito modificando diferentes parâmetros dentro de cada regra. Por exemplo, para otimizar o sistema crossover de MA, um trader faria um teste para ver quais médias móveis (10 dias, 30 dias, etc.) funcionam melhor e, em seguida, implementá-las. Mas a otimização pode melhorar os resultados apenas por uma pequena margem - é a combinação de parâmetros utilizados que, em última instância, determinarão o sucesso de um sistema.
É preciso toda emoção de negociação - Emoção é frequentemente citada como uma das maiores falhas dos investidores individuais. Os investidores que são incapazes de lidar com perdas adivinham suas decisões e acabam perdendo dinheiro. Seguindo estritamente um sistema pré-desenvolvido, os operadores do sistema podem renunciar à necessidade de tomar quaisquer decisões; uma vez que o sistema é desenvolvido e estabelecido, a negociação não é empírica porque é automatizada. Ao reduzir as ineficiências humanas, os comerciantes do sistema podem aumentar os lucros.
Os sistemas de negociação são complexos - essa é a maior desvantagem deles. Nos estágios de desenvolvimento, os sistemas de negociação exigem uma sólida compreensão da análise técnica, da capacidade de tomar decisões empíricas e de um conhecimento profundo de como os parâmetros funcionam. Mas mesmo se você não estiver desenvolvendo seu próprio sistema de negociação, é importante estar familiarizado com os parâmetros que compõem o que você está usando. Adquirir todas essas habilidades pode ser um desafio.

Bond trading system architecture

Many patterns in this chapter present ways to route messages to the proper destination without the originating application being aware of the ultimate destination of the message. Most of the patterns focused on specific types of routing logic. However, in aggregate, these patterns solve a bigger problem.
How can you decouple the destination of a message from the sender and maintain central control over the flow of messages?
Use a central Message Broker that can receive messages from multiple destinations, determine the correct destination and route the message to the correct channel. Implement the internals of the Message Broker using the design patterns presented in this chapter.
Using a central Message Broker is sometimes referred to as hub-and-spoke architectural style, which appears to be a descriptive name when looking at the diagram above.
Gregor Hohpe and Bobby Woolf.
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.