Sistema de negociação de obrigações

Bond Trading Systems.
Como os sistemas de negociação de títulos funcionam.
E-Trading Primer.
E-trading é essencialmente uma coleção de sistemas de tecnologia que compartilham informações sobre a negociação de títulos. Precisamos entender essas informações para poder projetar os sistemas de tecnologia para apoiá-la.
A informação pode ser dividida em 7 domínios funcionais. Cada domínio se concentra em um tipo específico de função e informação relevante para o e-trading. A informação em todos os domínios é necessária para o e-trading. O diagrama abaixo mostra os 7 domínios da informação de e-trading.
Esta separação lógica da informação também define fronteiras de responsabilidade funcional para a tecnologia da informação e fornece um guia sobre como uma organização pode alinhar o gerenciamento da tecnologia da informação; normalmente as equipes são formadas para suportar cada domínio (às vezes vários domínios).
Os dados e funções de um domínio são fornecidos por um ou mais sistemas que existem no domínio. Os próprios sistemas são geralmente uma composição de um ou mais serviços. Assim, no nível mais baixo, o e-trading é uma grande coleção de serviços que podem ser agrupados como sistemas cada um alinhados a um dos domínios funcionais. O diagrama abaixo ajuda a representar esta afirmação.
Por simplicidade, suponha que cada domínio tenha apenas um sistema e que cada sistema seja composto por alguns serviços. Na prática no entanto, pode haver vários sistemas em um domínio, por exemplo, o domínio de preços pode ter um sistema de preços diferente para títulos do governo e títulos corporativos. Embora todos os revendedores tenham projetos de sistemas diferentes, os 7 domínios existirão em cada ambiente de revendedor.
Os Domínios Funcionais.
Os domínios funcionais separam as informações de comércio eletrônico em grupos lógicos. Isso significa que cada domínio possui um conjunto de dados de informação distinto. Os conjuntos de dados podem ser generalizados conforme descrito na tabela abaixo. Pode ser útil consultar a terminologia para definições de quaisquer termos usados ​​nesta tabela e mais adiante neste artigo.
Isto resume essencialmente todos os tipos de dados que existem no e-trading. Diferentes sistemas de revendedores podem ter refinamentos variáveis ​​para os tipos de dados dentro de cada domínio, mas, fundamentalmente, os dados que fluem entre seus sistemas podem ser categorizados em um desses tipos de dados de domínio.
Relações de dados entre domínios.
Os sistemas dentro de cada domínio funcional precisam de dados dos outros domínios para funcionar corretamente. O diagrama abaixo mostra as relações de dados lógicas entre os domínios. Esta é uma visão simplificada, mas, em geral, os fluxos aqui mostrados são universais para todos os sistemas de comércio eletrônico.
Dados de referência e dados de mercado são fundamentais para todos os domínios. Os dados de referência fornecem os dados analíticos para o preço de uma ligação, traduzindo entre sistemas de identificação de títulos e dados de informações de contraparte para reserva. Os dados de mercado fornecem preços externos que são usados ​​como mecanismo de comparação e controle para os principais preços, orçamentos e pedidos.
Os sistemas de preços precisam dos dados de referência de uma obrigação para calcular os dados do preço do vínculo principal. Cálculos de preços mais sofisticados podem levar os dados do mercado como entradas adicionais ao calcular os preços dos títulos do núcleo.
Os sistemas de cotação tomam os principais preços dos títulos e os utilizam como base para o cálculo de cotações para ECNs. As cotações são geralmente calculadas aplicando os spreads de oferta-percurso específicos da ECN aos preços dos títulos principais (ampliação dos preços) e a configuração de uma quantidade para a qual a citação é boa. Os dados de posição do domínio de reserva são usados ​​para avaliar a posição atual mantida na ligação e alterar as quantidades da citação. A posição também pode ser usada para marcar o lado apropriado como axado. Os dados do mercado (os melhores preços do mercado) são usados ​​citando sistemas para fornecer limites para os preços de cotação da ECN ou até mesmo substituir os preços de cotação ECN do revendedor (por exemplo, usar o melhor preço do mercado como o próprio preço da cotação).
Os sistemas de negociação D2C lidam com o fluxo de trabalho de negociação eletrônico entre os clientes e o revendedor. Quando um cliente inicia uma negociação, o revendedor precisa fornecer um preço para a quantidade do vínculo que o cliente propõe negociar. A cotação de títulos atual na ECN da negociação veio geralmente é o ponto de partida para o preço. Outros fatores são então considerados que irão alterar o preço; a qualidade do cliente, a quantidade que o cliente solicita, os melhores preços do mercado atual e a posição atual que o revendedor detém na obrigação são geralmente combinadas em alguma função para alterar o preço da cotação do cédula do sistema de cotação e enviá-lo para o cliente.
Os sistemas de negociação D2D são usados ​​para gerenciar cotações e pedidos em D2D ECNs. Em geral, esses sistemas usam algoritmos que constantemente sintonizam os preços e as quantidades comparando as cotações do sistema de cotação e os preços dos dados do mercado. As informações de posição dos sistemas de domínio de reserva são usadas para controlar quantidades de citações e pedidos. Os sistemas de negociação D2D são os sistemas de negociação de alta freqüência que executam algo-trading. Eles precisam ser altamente eficientes e operar com as latências mais baixas possíveis para garantir que os preços das ordens sejam mantidos atualizados com as mudanças nas condições do mercado.
Os Serviços nos Domínios.
No início do artigo, um domínio foi descrito como tendo um ou mais sistemas e cada sistema possui um ou mais serviços. São os serviços responsáveis ​​pela produção de dados para um domínio. Em geral, existe um serviço para cada tipo de dados, estes são os serviços empresariais. O diagrama abaixo ilustra os principais serviços empresariais que devem existir em cada domínio para produzir os dados que foram definidos nas seções anteriores. Este diagrama expande o diagrama anterior, de modo que também inclui as relações de dados entre os domínios. Isso não abrange os serviços de infra-estrutura (por exemplo, bancos de dados, serviços de conexão ECN, serviços de mensagens e outros), apenas serviços relacionados a negócios.
Dependendo do design dos sistemas do concessionário, todos os serviços em um domínio podem ser de propriedade de um sistema ou sistemas separados. No entanto, o que é constante é que as funções para cada serviço mostrado aqui serão preenchidas por algum sistema no domínio. A função de cada serviço é descrita na tabela abaixo.
Ambientes.
Tendo aprendido sobre todos os serviços que precisam existir, podemos agora passar a discutir o conceito de ambientes de comércio eletrônico. Um ambiente de comércio eletrônico é uma coleção de serviços. A implantação de duplicatas dos mesmos serviços cria um segundo ambiente de comércio eletrônico. A maioria das instituições de negociação de títulos tem múltiplos ambientes em paralelo para diferentes usos. A tabela abaixo descreve os ambientes comuns que são implantados.
O conjunto de ambientes não está limitado a estes, por exemplo, algumas organizações terão vários ambientes de teste. Ter diferentes ambientes é essencial para a execução bem sucedida do e-trading de títulos. Sem isso, o ambiente de comércio eletrônico de títulos de produção estancaria devido à falta de mudança ou será extremamente instável à medida que a nova funcionalidade é testada e # 8216; em vez de nas condições controladas de um ambiente de desenvolvimento e teste.
Ambiente cruzado.
O cross-over de meio ambiente é um conceito que descreve quando os sistemas de um ambiente estão conectados aos de um outro. Normalmente, isso ocorre quando alguns serviços não existem no ambiente e para compensar isso, os serviços de outros ambientes são usados. Um exemplo clássico é o comércio da ECN; Os ECNs, em geral, não possuem ambientes de desenvolvimento, apenas ambientes de teste e produção, de modo que o ambiente de desenvolvimento de um revendedor geralmente se transpõe para o ambiente de teste ECN. O diagrama abaixo ilustra o cruzamento ambiental.
Para a resiliência, geralmente há cross-over entre os ambientes de produção ao vivo e de backup do revendedor e ECN. No entanto, apenas um ambiente está ativo em qualquer ponto no tempo em qualquer um dos sites.
Um ambiente é implantado em uma localização geográfica. Um revendedor que negocia globalmente geralmente requer um ambiente de produção localizado em várias regiões geográficas. Para cada região que existe um ambiente de produção, há também um requisito para ambientes de backup, teste e desenvolvimento. Portanto, se um revendedor tiver 3 regiões comerciais globais, o revendedor tem um total de 3 x 4 = 12 implantações dos serviços de comércio eletrônico. Portanto, o número de implantações necessárias é uma função dos ambientes necessários e dos locais de negociação. Gerenciando vários ambientes em vários locais pode tornar-se muito intensivo em tempo e complicado. Se a tecnologia de implantação não é fácil de trabalhar, então o conceito simples de adicionar um novo serviço a um ambiente pode se tornar um processo tedioso, pois é necessário ser adicionado em todos os ambientes em todos os locais.
Ao encerrar & # 8230;
Este artigo introduziu conceitos que são universais para todos os ambientes de comércio eletrônico. Entender isso é fundamental para qualquer profissional de tecnologia da informação ou analista de negócios que trabalha no e-trading. Esta informação faz parte da base que é necessária para começar a investigar os serviços e infra-estrutura em maior profundidade nos próximos artigos.

Bond Trading Systems.
Como os sistemas de negociação de títulos funcionam.
Bond Trading Business Primer.
O comércio de títulos usando sistemas eletrônicos é chamado de comércio eletrônico. Isso requer uma quantidade considerável de infra-estrutura de tecnologia da informação. Antes de explorar a tecnologia da informação, precisamos entender os fundamentos do negócio de negociação de títulos. Este artigo descreve os processos de negociação de títulos. Este é um tópico muito amplo e profundo; Neste artigo, vamos apenas escorrer a superfície e ganhar apenas entendimento suficiente para prosseguir com a exploração da tecnologia da informação nos próximos artigos.
O negócio de títulos.
O negócio de títulos tem muitas atividades, para simplificar, elas podem ser agrupadas em um dos quatro grupos de operações principais. Todas essas operações são suportadas por tecnologia da informação e cada grupo é focado em um aspecto específico da negociação de títulos.
Básico básico do ciclo de vida.
Um vínculo é um meio para uma organização legal levantar capital através da emissão de dívida. As organizações legais são governos, corporações, organizações supra-nacionais e outros. A dívida é comprada por investidores que se tornaram detentores de títulos. Os detentores de títulos recebem pagamentos de juros do emissor de obrigações em períodos definidos por um cronograma. O vínculo tem um prazo definido (o prazo de vencimento) e no final do prazo, o valor original de cada ação é devolvido ao detentor do vínculo. O valor original também é chamado de valor nominal.
O diagrama abaixo ajuda a ilustrar isso.
Os pagamentos de juros feitos em uma obrigação são chamados de pagamento de cupom. Este termo é histórico para quando um certificado de títulos realmente tinha cupons de arranque que deveriam ser apresentados ao emissor de obrigações para receber o pagamento de juros.
Padrão.
Existe o risco de o emissor de obrigações não poder pagar alguns ou todos os pagamentos de juros ou o valor nominal no vencimento para os compradores de títulos. Isso é chamado de risco de crédito. Se o emissor de obrigações não cumprir o cronograma de obrigações, o emitente de obrigações não cumprirá a obrigação.
Se o emissor de obrigações for inadimplente e estiver em garantia (ou seja, declarado falido), os detentores de obrigações podem receber uma porcentagem do valor nominal se a obrigação for classificada como dívida sénior. Se é uma dívida subordinada, então qualquer pagamento só acontece depois que a dívida sénior foi liquidada.
Mercado Primário.
As obrigações são emitidas no mercado primário; É aqui que o emissor de obrigações recebe o capital dos compradores de títulos em troca da propriedade de títulos. O comprador de uma obrigação pode manter a caução até o vencimento e receber o valor nominal no vencimento mais os pagamentos de juros durante a vida útil.
Mercado secundário.
Um detentor de títulos pode optar por mudar o vínculo e para outro investimento financeiro. Isso é facilmente feito através da negociação do vínculo no mercado secundário. Os mercados secundários são onde os títulos são comprados e vendidos como commodities.
Em geral, o termo "negociação de títulos" refere-se à negociação no mercado secundário. O diagrama abaixo resume a negociação de títulos durante as fases do mercado e a vida útil de uma obrigação.
O Mercado de Obrigações Secundárias.
Um mercado tem clientes e comerciantes, os clientes vão ao mercado para obter bens por dinheiro, enquanto os comerciantes vão ao mercado para vender bens com fins lucrativos. A este respeito, o mercado secundário não é diferente. Os bancos de investimento são os comerciantes e as empresas de investimento que gerenciam pensões ou fundos de gestão de riqueza são os clientes. Esta é uma generalização dos participantes do mercado, mas é bom para o que precisamos para prosseguir. Nos mercados secundários, os termos sell-side, market-maker, comerciante ou revendedor identificam comerciantes. Os clientes são identificados pelos termos buy-side, market-taker, cliente ou cliente. Nestes artigos, usaremos os termos revendedor / comerciante e cliente.
Os preços são expressos como uma porcentagem do par. Par é outro termo para o valor nominal. Portanto, um preço de 100,00 é de 100,00% do valor nominal da obrigação. O diagrama abaixo mostra situações de exemplo para clientes comprando e vendendo com revendedores. O revendedor define os preços que os clientes podem negociar. Em geral, o revendedor vai comprar baixo e vender alto. Nos exemplos, o revendedor está disposto a comprar em 99,5 e vender em 100,5. Isso significa essencialmente que, se o valor nominal da bonificação for de US $ 100, o revendedor está disposto a comprar em US $ 99,50 e vender em US $ 100,50. O preço que um negociante compra é o preço da oferta e o preço que o revendedor vende é o preço do pedido. O preço do pedido também é conhecido como o preço da oferta.
A diferença entre o preço da oferta e da oferta é denominada spread bid-ask (também spread de ofertas). Os spreads mais amplos são melhores para os revendedores, os spreads mais restritos são melhores para o cliente, mas o preço da oferta é sempre menor que o preço do pedido. Os negociantes sempre querem spreads mais amplos, enquanto os clientes sempre desejarão spreads mais restritos.
Geralmente, os negociantes não estão interessados ​​em manter títulos até o vencimento, eles estão interessados ​​em fazer lucros com a compra baixa e alta. Os clientes, em contraste, estão interessados ​​em manter uma obrigação no vencimento ou, pelo menos, com o objetivo de receber os pagamentos de juros de uma obrigação e, normalmente, reinvesti-los.
Avaliando um vínculo no mercado secundário.
O valor de um título valioso pode ser calculado como seu valor nominal mais o restante dos pagamentos do cupom, descontados contra o prazo de vencimento do vínculo. Isso também é chamado de rendimento até a maturidade e representa o rendimento que você obteria se você segurar o vínculo até amadurecer.
No entanto, o rendimento até o vencimento não leva em consideração o risco de crédito do emissor de obrigações (ou seja, a probabilidade de incumprimento). Também não tem fator no risco devido a mudanças na taxa de juros; geralmente à medida que as taxas de juros aumentam, os preços dos títulos caem e vice-versa. Em suma, o rendimento até o vencimento não é geralmente utilizado para calcular os preços no mercado secundário.
Na prática, há uma variedade de técnicas usadas para preços de títulos no mercado secundário. Nós não estaremos discutindo essas técnicas, pois não são apropriadas neste nível de introdução. No entanto, existe um conceito fundamental que é comum a todas as técnicas de precificação; preço de um vínculo de outro. O diagrama abaixo ajuda a ilustrar isso. Isso mostra um exemplo típico em que os preços das obrigações corporativas são impulsionados por mudanças em um vínculo de referência. Geralmente, o vínculo de referência é um vínculo governamental.
Normalmente, o preço das obrigações corporativas tem um spread fixo do benchmark. À medida que o preço de referência muda, também o preço da obrigação corporativa. Técnicas de preços mais avançadas podem usar preços misturados ou rendimentos de benchmarks múltiplos para chegar ao preço da obrigação. Por enquanto, é suficiente que tenhamos uma apreciação de que os preços dos títulos podem impulsionar os preços dos outros títulos. Este é um conceito importante no preço das obrigações para negociação. Relações de preços como esta são a base para a maioria dos sistemas de preços de títulos.
Liquidez do mercado secundário.
Os governos emitem obrigações para financiar a dívida pública. Para garantir que o valor das obrigações detém e que a dívida não é vista como lixo, os governos colocam obrigações de que os revendedores mantenham os preços dos títulos liquidos no mercado secundário, continuamente citando preços de 2 vias. Um preço de 2 vias é outro termo para preços de compra e venda. Isso coloca uma grande responsabilidade e possível risco financeiro para os revendedores para garantir que seus preços de títulos públicos sejam precisos para o mercado. Esses preços tornam-se muito sensíveis às mudanças nas taxas de juros e vice-versa. Essas obrigações asseguram que os preços dos títulos do governo sejam sempre líquidos, o que mantém a negociação de títulos secundários viável e estável. O benefício para os revendedores que assumem essas obrigações é que eles podem participar nos leilões do mercado primário da dívida pública. Participar desses leilões tem benefícios financeiros e de reputação para os concessionários.
Importância dos preços líquidos dos títulos do governo.
Em geral, os títulos são classificados como dívida pública ou corporativa. As obrigações governamentais são emitidas pelos governos e têm um menor risco de inadimplência porque, em geral, os governos não falam. Devido ao menor risco, eles também têm um menor pagamento de cupom. Isso segue o conceito de menor risco, menor recompensa.
Os títulos corporativos, ao contrário, têm maior risco de inadimplência. Como tal, seus cupons são maiores do que um vínculo governamental equivalente. O preço dos títulos corporativos geralmente é feito por preços sobre títulos do governo. Uma única dívida pública pode estar dirigindo preços de títulos corporativos múltiplos. À medida que os preços dos títulos públicos variam, há um efeito em cascata no preço das obrigações corporativas. Ao avaliar os títulos das empresas em relação aos preços líquidos do governo, os próprios títulos corporativos têm uma liquidez inerente.
A liquidez dos preços da dívida pública também é um fator importante para o crescimento econômico. A liquidez é um sinal de confiança no governo e sua estabilidade financeira.
Produção de lucros no mercado secundário.
Embora um revendedor possa lucrar com a compra baixa e alta, isso geralmente não está disponível para o cliente, pois os preços de compra e venda são definidos pelos revendedores. Algumas instituições comerciais tentam arbitrar os preços dos revendedores, mas isso geralmente é muito difícil e requer um investimento intensivo em tecnologia da informação com retorno de investimento um pouco quantificável.
Estilos de negociação de títulos.
Existem dois estilos de negociação no mercado secundário. Um revendedor que negocia com um cliente é chamado de negociante para cliente (D2C) ou comercial de empresa a cliente (B2C). Esta forma de negociação geralmente surge na negociação de títulos a preços que são adaptados pelo revendedor para o cliente e ambos os lados concordam com o preço antes da negociação ser acordada.
Um revendedor também pode negociar diretamente com outros revendedores. Isso é referido como negociação de revendedor / revendedor (D2D), business-to-business (B2B) ou inter-dealer-broker (BID). Esta forma de negociação é de alta velocidade e implacável sem interação humana para concordar com os preços do comércio. Os preços citados por um revendedor podem ser negociados instantaneamente (ou agredidos) por qualquer outro revendedor. Por esta razão, a citação D2D deve ser mantida em progresso com os concorrentes; preços baixos podem significar que um negociante irá negociar fora do mercado e fazer uma perda.
Normalmente, os mercados eletrônicos são divididos em categorias D2D ou D2C. Um revendedor exige diferentes modelos de sistemas para lidar com os dois paradigmas comerciais; O comércio D2C é mais sobre saber o cliente para fornecer preços precisos para o cliente. O comércio D2D é sobre a potência de cavalo crua do sistema de comércio do revendedor.
Para referência, as obrigações de cotação do governo estão apenas em mercados D2D.
A negociação eletrônica de títulos permite que clientes e revendedores troquem. No entanto, os dois lados precisam ser reunidos. É aí que as pessoas de vendas entram; eles fazem o trabalho de conseguir que o cliente negocie com o revendedor. Mesmo que tanto do fluxo de trabalho comercial seja realizado eletronicamente, ainda existem certos elementos que dependem de dinâmicas humanas simples. Obtendo clientes na & # 8220; shop & # 8221; é um desses.
As pessoas de vendas recebem comissão por comércio para os clientes que representam que executam negócios com o revendedor.
Mercados eletrônicos.
A negociação de títulos eletrônicos é hospedada por provedores de mercado eletrônicos, denominados Electronic Communication Networks (ECNs). Estes também são denominados trocas. Existem ECNs que se especializam em negócios D2D ou D2C. Concessionários e clientes se conectam diretamente às ECNs e executam atividades de negociação via ECN. Os negociantes normalmente se conectam a uma ECN através de uma API. A API permite ao revendedor receber dados de mercado disponíveis no ECN, enviar pedidos (mercados D2D) ou responder às negociações dos clientes (mercados D2C). Os clientes normalmente usarão uma aplicação de software fornecida pela ECN para ver os preços atuais no ECN e iniciar as negociações. Em geral, as ECNs tomam uma pequena comissão por troca executada. Um revendedor geralmente se conecta a múltiplas ECNs para ter a maior presença comercial eletrônica possível. Este é o senso comum, pois os locais mais acessados ​​por um revendedor aumentam as chances de negociação.
Estas são algumas das ECNs que existem hoje. Não é abrangente.
Assentamento.
ECNs são onde os negócios são acordados, mas a entrega real de dinheiro para títulos ou liquidação acontece em câmaras de compensação. A liquidação ocorre nos intervalos de tempo padrão após a execução do comércio. O intervalo de tempo é uma convenção para a ligação, e. Os títulos do governo do euro se estabelecem numa base T + 2 (ou seja, 2 dias após a concordância do comércio). Alguns títulos se contentam com o dinheiro, o que significa que eles negociam e se estabelecem no mesmo dia (T + 0).
As casas de compensação assumem o risco de contraparte de um comércio. Essencialmente, cada conterparty no comércio (o comprador e o vendedor) se instala com a câmara de compensação e não diretamente entre si. Caso nenhum dos lados não pague ou entregue, a câmara de compensação garante que o outro lado do comércio recebe o que é devido. Isso protege cada contraparte do padrão durante a liquidação comercial. A câmara de compensação se protege ao exigir pagamentos colaterais de cada contraparte para que haja alguma cobertura de quaisquer dívidas que possam surgir.
Ao encerrar & # 8230;
Neste artigo, os processos e conceitos fundamentais utilizados no negócio de negociação de títulos foram descritos. Com essa compreensão básica, a tecnologia da informação pode ser explorada e terá sentido o que o processo comercial que cada parte da tecnologia e-trading suporta.

Sistema de negociação de obrigações
(Por Jonathan Simon)
É fácil distanciar-se de uma grande coleção de padrões ou de uma linguagem padrão. Os padrões são a abstração de uma idéia em uma forma reutilizável. Muitas vezes, a natureza muito genérica dos padrões que os torna 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 artificial do que poderia acontecer; mas o que realmente acontece e o que 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. Exploraremos 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 como combinar e ajustar padrões para atender às necessidades do sistema. E tudo isso é feito levando em consideração as forças encontradas em sistemas reais, incluindo requisitos de negócios, decisões de clientes, requisitos arquitetônicos e técnicos, bem como integração de sistemas legados. A intenção desta abordagem é proporcionar 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 pretende construir um sistema de preços de títulos em um esforço para agilizar o fluxo de trabalho de sua mesa de negociação de títulos. Atualmente, os comerciantes de títulos têm que 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 avaliar 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 parece ser o seguinte:
Fluxo de alto nível.
Primeiro, os dados do mercado entram no sistema. Os dados de mercado são dados relativos ao preço e outras propriedades do vínculo que representam o que as pessoas estão dispostas a comprar e vender o vínculo no mercado livre. Os dados do mercado são imediatamente enviados para o mecanismo de análise que altera os dados. A análise 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 adaptar os resultados da função a uma ligação particular. O aplicativo cliente que será executado em cada área de trabalho do comerciante configurará o mecanismo de análise por base de comerciante, controlando as especificidades da análise para cada vínculo, o comerciante está classificando os preços. Uma vez que a análise é aplicada aos dados do mercado, os dados modificados são enviados para vários locais de negociação em que os comerciantes de outras empresas podem comprar ou vender os títulos.
Arquitetura com padrões.
Com esta visão geral do fluxo de trabalho do sistema, podemos abordar alguns dos problemas arquitetônicos que encontramos durante o processo de design. Vamos dar uma olhada no que sabemos até agora. Os comerciantes precisam de uma aplicação muito receptiva nas estações de trabalho Windows NT e Solaris. Portanto, decidimos implementar o aplicativo cliente como um cliente de Java grosso devido à independência de sua plataforma e sua capacidade de responder rapidamente aos dados de entrada e ao mercado do usuário. Do lado do servidor, estamos herdando componentes C ++ legados que o nosso sistema utilizará. Os componentes de dados do mercado se comunicam com a infra-estrutura de mensagens TIBCO Information Bus (TIB).
Estamos herdando os seguintes componentes:
Market Data Price Feed Server: publica dados de mercado recebidos para o TIB. Mecanismo de análise: executa análises de dados de mercado recebidos 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. Os locais de negociação são componentes de terceiros não controlados pelo banco.
Subsistema de dados do mercado legado.
Subsistema de contribuição legado.
Precisamos decidir como os subsistemas separados (Java thick client, data de mercado e contribuição) se comunicarão. Poderíamos que o cliente grosso se comunicasse 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 se comunicar com os servidores herdados - O Gateway de preços para dados de mercado, um Contribution Gateway para enviar preços para os locais de negociação. Isso alcançará um bom encapsulamento da lógica de negócios relacionada a essas áreas. Os componentes atuais do 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 Java thick client e os dois componentes do servidor Java para trocar dados. Olhe nos quatro estilos de integração sugeridos neste livro: Transferência de arquivos, banco de dados compartilhado, Invocação de procedimento remoto e mensagens. Nós podemos descartar o banco de dados compartilhado imediatamente porque queríamos criar uma camada de abstração entre o cliente eo banco de dados e não queremos ter o código de acesso ao banco de dados no cliente. A transferência de arquivos pode ser descartada de forma similar, uma vez que é necessária uma latência mínima para garantir que os preços atuais sejam enviados para os locais de negociação. Isso nos deixa uma escolha entre Invocação de Procedimento Remoto ou Mensagens.
A plataforma Java fornece suporte incorporado para Invocação de Procedimentos Remotos e Mensagens. A integração com o estilo RPC pode ser alcançada usando o Remote Method Invocation (RMI), CORBA ou Enterprise Java Beans (EJB). O Java Messaging Service (JMS) é a API comum para integração com o estilo de mensagens. Portanto, ambos os estilos de integração são fáceis de implementar em Java.
Então, o que funcionará melhor para este projeto, Invocação de Procedimento Remoto ou Mensagens? Há apenas uma instância do Pricing Gateway e uma instância do Contribution Gateway no sistema, mas geralmente muitos Clientes Grossos se conectam simultaneamente a esses serviços (um para cada comerciante de títulos que esteja logado em um horário específico). Além disso, o banco gostaria que este fosse um sistema genérico de preços que possa ser utilizado em outras aplicações. Portanto, além de um número desconhecido de Think Clients, pode haver um número desconhecido de outras aplicações usando os dados de preços que saem dos Gateways.
Um Thick Client (ou outro aplicativo usando os dados de preços) pode bastante facilmente usar o RPC para fazer chamadas nos Gateways para obter dados de preços e invocar o processamento. No entanto, os dados de preços serão constantemente publicados, e certos clientes só estão interessados ​​em determinados dados, de modo que obter dados relevantes aos clientes adequados em tempo hábil pode ser difícil. Os clientes poderiam pesquisar os Gateways, mas isso criará muitas despesas gerais. Seria melhor para os Gateways disponibilizar os dados aos clientes assim que estejam disponíveis. Isso, no entanto, exigirá que cada Gateway fique atento a quais clientes estão atualmente ativos e que querem quais dados específicos; então, quando um novo pedaço de dados ficar disponível (o que acontecerá várias vezes por segundo), o Gateway terá que fazer um RPC para cada cliente interessado para transmitir os dados ao cliente. Idealmente, todos os clientes devem ser notificados simultaneamente, então cada RPC precisa ser feito em seu próprio segmento simultâneo. Isso pode funcionar, mas está ficando muito complicado muito rápido.
O Messaging simplifica muito esse problema. Com o Messaging, podemos definir canais separados para os diferentes tipos de dados de preços. Então, quando um Gateway obtém uma nova peça de dados, ele adicionará uma mensagem contendo esses dados ao Canal de Publicação-Inscrição para esse tipo de dados. Enquanto isso, todos os clientes interessados ​​em um determinado tipo de dados escutarão no canal para esse tipo. Desta forma, os Gateways podem facilmente enviar novos dados para quem está interessado, sem precisar saber quantos aplicativos de ouvintes existem ou o que são.
Os clientes ainda precisam ser capazes de invocar comportamentos nos Gateways também. Uma vez que existem apenas dois Gateways, e o cliente provavelmente pode bloquear enquanto o método é invocado de forma síncrona, essas invocações de cliente para Gateway podem ser facilmente implementadas usando o RPC. No entanto, uma vez que já estamos usando mensagens para a comunicação do Gateway para o cliente, as mensagens provavelmente são uma maneira tão boa de implementar a comunicação do cliente para o gateway também.
Portanto, toda comunicação entre os Gateways e os clientes será realizada através de mensagens. Como todos os componentes estão escritos em Java, o JMS apresenta uma escolha fácil para o sistema de mensagens. Isso efetivamente está criando um barramento de mensagens ou uma arquitetura que tornará possível que sistemas futuros se integrem com o sistema atual com poucas ou nenhuma alteração na infra-estrutura de mensagens. This way, the business functionality of the application can be easily used by other application the bank develops.
Java Components Communicating with JMS.
JMS is simply a specification and we need to decide on a JMS-compliant messaging system. We decided to use IBM MQSeries JMS because the bank is an “IBM shop, ” using WebSphere application servers and many other IBM products. As a result, we will use MQSeries since we already have a support infrastructure in place and a site license of the product.
The next question is how to connect the MQSeries messaging system with the standalone C++ Contribution server and the TIBCO based Market Data and Analytics Engine servers. We need a way for the MQSeries consumers to have access to the TIB messages. But how? Perhaps we could use the Message Translator pattern to translate TIB messages into MQSeries messages. Although the C++ client for MQSeries serves as a Message Translator , using it would sacrifice JMS server independence. And although TIBCO does have a Java API, the customer architect and manager have rejected it. As a result, the Message Translator approach has to be abandoned.
The bridge from the TIB server to the MQSeries server requires communication between C++ and Java. We could use CORBA, but then what about the messaging? A closer look at the Message Translator pattern shows it is related to the Channel Adapter in its use of communication protocols. The heart of a Channel Adapter is to connect non-messaging systems to messaging systems. A pair of channel adapters that connects two messaging systems is a Messaging Bridge .
The purpose of a Messaging Bridge is to transfer messages from one messaging system to another. This is exactly what we are doing with the added complexity of the intra-language Java to C++ communication. We can implement the cross language Messaging Bridge using a combination of Channel Adapter s and CORBA. We will build two lightweight Channel Adapter servers, one in C++ managing communication with the TIB, and one in Java managing communication with JMS. These two Channel Adapter , which are Message Endpoint s themselves, will communicate with each other via CORBA. Like our choice for MQSeries, we will use CORBA rather than JNI since it is a company standard. The messaging bridge implements the effectively simulated message translation between seemingly incompatible messaging systems and different languages.
Message Translator using Channel Adapters.
The next diagram shows the current system design including the Gateways and other components. This is a good example of pattern application. We combined two Channel Adapter s with a non-messaging protocol to implement the Message Translator pattern, effectively using one pattern to implement another pattern. Additionally, we changed the Channel Adapter s' context to link two messaging systems with a non-messaging cross language translation protocol rather than connecting a messaging system to a non-messaging system.
The current system with the Channel Adapters.
Structuring Channels.
A key to working with patterns is not only knowing when to use which pattern, but also how to most effectively use it. Each pattern implementation has to take into account specifics of the technology platform as well as other design criteria. This section applies the same discovery process to find the most efficient use of the Publish-Subscribe Channel in the context of the market data server communicating with the analytics engine.
Real time market data originates with market data feed, a C++ server that broadcasts market data on the TIB. The market data feed uses a separate Publish-Subscribe Channel for each bond it is publishing prices for. This may seem a little extreme since each new bond needs its own new channel. But this is not so severe since you do not actually need to create channels in TIBCO. Rather, channels are referenced by a hierarchical set of topic names called subjects. The TIBCO server then filters a single message flow by subject, sending each unique subject to a single virtual channel. The result of which is a very lightweight message channel.
We could create a system that publishes on a few channels and subscribers could listen only for prices they are interested in. This would require subscribers to use a Message Filter or Selective Consumer to filter the entire data flow for interesting bond prices, deciding whether each message should be processed as it is received. Given that the market data is published on bond-dedicated channels, subscribers can register for updates on a series of bonds. This effectively allows subscribers to "filter" by selectively subscribing to channels and only receiving updates of interest rather than deciding after the message is received. It is important to note that using multiple channels to avoid filtering is a nonstandard use of messaging channels. In context of the TIBCO technology however, we are really deciding whether to implement or own filters or utilize the channel filtering built into TIBCO -- rather than whether to use so many channels.
The next component we need to design is the analytics engine, another C++/TIB server that will modify the market data and rebroadcast it to the TIB. Although it is out of the scope of our Java/JMS development, we are working closely with the C++ team to design it since we are the analytics engine's primary 'customer'. The problem at hand is to find the channel structure that most efficiently rebroadcast the newly modified market data.
Since we already have one dedicated Message Channel per bond inherited from the market data price feed, it would be logical to modify the market data and rebroadcast the modified market data on the bond dedicated Message Channel . But this will not work since the analytics modifying the bonds prices are trader specific. If we rebroadcast the modified data on the bond Message Channel , we will destroy the data integrity by replacing generic market data with trader specific data. On the other hand, we could have a different message type for trader specific market data that we publish on the same channel allowing subscribers to decide which message they are interested in to avoid destroying the data integrity. But then clients will have to implement their own filters to separate out messages for other traders. Additionally, there will a substantial increase in messages received by subscribers, placing an unnecessary burden on them.
There are two options:
One Channel per Trader: Each trader has a designated channel for the modified market data. This way, the original market data remains intact and each trader application can listen to its specific traders Message Channel for the modified price updates. One Channel per trader per Bond: Create one Message Channel per-trader per-bond solely for the modified market data of that bond. For example, the market data for bond ABC would be published on channel "Bond ABC" while the modified market data for trader A would be published on Message Channel "Trader A, Bond ABC", modified market data for trader B on "Trader B, Bond ABC," and so on.
One channel per trader.
One channel per bond per trader.
There are advantages and disadvantages to each approach. The per-bond approach, for example, uses a lot more Message Channel . In the worst-case scenario, the number of Message Channel will be the number of bonds total multiplied by the number of traders. We can put upper bounds on the number of channels that will be created since we know that there are only around 20 traders and they never price more than a couple hundred bonds. This puts the upper limit below the 10,000 range, which is not so outlandish compared to the nearly 100,000 Message Channel the market data price feed is using. Also, since we are using the TIB and Message Channel are quite inexpensive, the number of Message Channel s is not a severe issue. On the other hand, the sheer number of Message Channel s could be a problem from a management perspective. Every time a bond is added a channel for each trader must be maintained. This could be severe in a very dynamic system. Our system, however, is essentially static. It also has an infrastructure for automatically managing Message Channel s. This combined with the inherited architecture of a legacy component using a similar approach minimizes the downside. This is not to say we should make an unnecessarily excessive number of Message Channel s. Rather, we can implement an architectural approach that uses a large number of Message Channel s when there is a reason.
And there is a reason in this case that comes down to the location of logic. If we implement the per trader approach, the Analytics Engine needs logic to group input and output channels. This is because the input channels from the Analytics Engine are per bond and the output Message Channel s would be per trader, requiring the Analytics Engine to route all analytics input from multiple bonds for a particular trader to a trader specific output Message Channel . This effectively turns the analytics engine into a Content-Based Router to implement custom routing logic for our application.
Following the Message Bus structure, the Analytics Engine is a generic server that could be used by several other systems in the. So we don’t want to cloud it with system specific functionality. On the other hand, the per-bond approach works since the idea of a trader owning the analytics output of bond prices is a company accepted practice. The per-bond approach keeps the Message Channel separation of the market data feed intact, while adding several more Message Channel s. Before we reach the client, we want a Content-Based Router to combine these several channels into a manageable number of channels. We don’t want the client application running on the trader’s desktop to be listening to thousands or tens of thousands of Message Channel s. Now the question becomes where to put the Content-Based Router . We could simply have the C++/TIB Channel Adapter forward all of the messages to the Pricing Gateway on a single Message Channel . This is bad for two reasons; we would be splitting up the business logic between C++ and Java, and we would lose the benefit of the separate Message Channel s on the TIB side allowing us to avoid filtering later in the data flow. Looking at our Java components, we could either place it in the Pricing Gateway or create an intermediary component between the Pricing Gateway and the client.
In theory, if we persisted the bond-based separation of Message Channel s all the way to the client, the Pricing Gateway would rebroadcast pricing information with the same channel structure as the Pricing Gateway and Analytics Engine. This means a duplication of all of the bond dedicated TIB channels in JMS. Even if we create an intermediary component between the Pricing Gateway and the client, the Pricing Gateway will still have to duplicate all of the channels in JMS. On the other hand, implementing logic directly in the Pricing Gateway allows us to avoid duplicating the large number of channels in JMS—allowing us to create a much smaller number of channels in the order of one per trader. The Pricing Gateway registers itself through the C++/TIB Channel Adapter as a consumer for each bond of every trader in the system. Then the Pricing Gateway will forward each specific client only the messages related to that particular trader. This way, we only use a small number of Message Channel s on the JMS end, while maximizing the benefit of the separation on the TIB end.
The complete Market Data Flow to the client.
The Message Channel layout discussion is a good example of how integrating patterns is important. The goal here was to figure out how to effectively use the Message Channel s. Saying you use a pattern isn’t enough. You need to figure out how to best implement it and incorporate into your system to solve the problems at hand. Additionally, this example shows business forces in action. If we could implement business logic in any of our components, we could have gone with the per trader approach and implemented an overall more simple approach with many less channels.
Selecting a Message Channel?
Now that we know the mechanics of the communication between the Java/JMS components and the C++/ TIBCO components, and we have seen some Message Channel structuring, we need to decide which type of JMS Message Channel s the Java components should use to communicate. Before we can choose between the different Message Channels available in JMS, let’s look at the high level message flow of the system. We have two gateways (Pricing and Contribution) communicating with the client. Market data flows to the client from the Pricing Gateway which sends it out to the Contribution Gateway. The client application sends message to the Pricing Gateway to alter the analytics being applied to each bond. The Contribution Gateway also sends messages to the Client application relaying the status of the price updates to the different trading venues.
The system message flow.
The JMS specification describes two Message Channel types, Point-to-Point Channel (JMS Queue ) and Publish-Subscribe Channel (JMS Topic ). Recall that the case for using publish-subscribe is to enable all interested consumers to receive a message while the case for using point-to-point is to ensure that only one eligible consumer receives a particular message.
Many systems would simply broadcast messages to all client applications, leaving each individual client application to decide for itself whether or not to process a particular message. This will not work for our application since there are a large number of market data messages being sent to each client application. If we broadcast market data updates to uninterested trader, we will be unnecessarily wasting client processor cycles deciding whether or not to process a market data update.
Point-to-Point Channel s initially sound like a good choice since the clients are sending messages to unique servers and visa versa. But it was a business requirement that traders may be logged in to multiple machines at the same time. If we have a trader logged in at two workstations simultaneously and a point-to-point price update is sent, only one of the two client applications will get the message. This is because only one consumer on a Point-to-Point Channel can receive a particular message. Notice that only the first of each group of a trader's client applications receives the message.
Point-to-Point Messaging for Price Updates.
We could solve this using the Recipient List pattern, which publishes messages to a list of intended recipients, guaranteeing that only clients in the recipient list will receive messages. Using this pattern, the system could create recipient lists with all client application instances related to each trader. Sending a message related to a particular trader would in turn send the message to each application in the recipient list. This guarantees all client application instances related to a particular trader would receive the message. The downside of this approach is that it requires quite a bit of implementation logic to manage the recipients and dispatch messages.
Recipient List for Price Updates.
Even though point-to-point could be made to work, let’s see if there is a better way. Using Publish-Subscribe Channel s, the system could broadcast messages on trader specific channels rather than client application specific channels. This way, all client applications processing messages for a single trader would receive and process the message.
Publish-Subscribe Messaging for Price Updates.
The downside of using Publish-Subscribe Channel s is that unique message processing is not guaranteed with the server components. It would be possible for multiple instances of a server component to be instantiated and each instance process the same message, possibly sending out invalid prices.
Recalling the system message flow, only a single communication direction is satisfactory with each Message Channel . Server-to-client communication with publish-subscribe is satisfactory while client-to-server communication is not and client-server communication with point-to-point is satisfactory while server-client is not. Since there is no need to use the same Message Channel in both directions, we can use each Message Channel only one direction. Client-to-server communication will be implemented with point-to-point while server-to-client communication will be implemented with publish-subscribe. Using this combination of Message Channel s, the system benefits from direct communication with the server components using point-to-point messaging and the multicast nature of publish-subscribe without either of the drawbacks.
Message flow with Channel Types.
Problem Solving With Patterns.
Patterns are tools and collections of patterns are toolboxes. They help solve problems. Some think that patterns are only useful during design. Following the toolbox analogy, this is like saying that tools are only useful when you build a house, not when you fix it. The fact is that patterns are a useful tool throughout a project when applied well. In the following sections we will use the same pattern exploration process we used in the previous section to solve problems in our now working system.
Flashing Market Data Updates.
Traders want table cells to flash when new market data is received for a bond, clearly indicating changes. The Java client receives messages with new data which triggers a client data cache update and eventually flashing in the table. The problem is that updates come quite frequently. The GUI thread stack is becoming overloaded and eventually freezing the client since it can’t respond to user interaction. We will assume that the flashing is optimized and concentrate on the data flow of messages through the updating process. An examination of performance data shows the client application is receiving several updates a second; some updates occurred less than a millisecond apart. Two patterns that seem like they could help slow down the message flow are Aggregator and Message Filter.
A first thought is to implement a Message Filter to control the speed of the message flow by throwing out updates received a small amount of time after the reference message. As an example, lets say that we are going to ignore messages within 5 milliseconds of each other. The Message Filter could cache the time of the last acceptable message and throw out anything received within the next 5 milliseconds. While other applications may not be able to withstand data loss to such an extent, this is perfectly acceptable in our system due to the frequency of price updates.
Time based Message Filter.
The problem with this approach is that not all data fields are updated at the same time. Each bond has approximately 50 data fields displayed to the user including price. We realize that not every field is updated in every message. If the system ignores consecutive messages, it may very well be throwing out important data.
The other pattern of interest is the Aggregator . The Aggregator is used to manage the reconciliation of multiple, related messages into a single message, potentially reducing the message flow. The Aggregator could keep a copy of the bond data from the first aggregated message, then update only new or changed fields successive messages. Eventually the aggregated bond data will be passed in a message to the client. For now, lets assume that the Aggregator will send a message every 5 milliseconds like the Message Filter . Later, we'll explore another alternative.
Aggregator with partial successive updates.
The Aggregator , like any other pattern, is not a silver bullet; it has its pluses and minuses that need to be explored. One potential minus is that implementing an Aggregator would reduce the message traffic by a great amount in our case only if many messages are coming in within a relatively short time regarding the same bond. On the other hand, we would accomplish nothing if the Java client only receives updates for one field across all of the traders bonds. For example, if we receive 1000 messages in a specified timeframe with 4 bonds of interest, we would reduce the message flow from 1000 to 4 messages over that timeframe. Alternatively, if we receive 1000 messages in the same timeframe with 750 bonds of interest, we will have reduced the message flow from 1000 to 750 messages; relatively little gain for the amount of effort. A quick analysis of the message updates proves that the Java client receives many messages updating fields of the same bond, and therefore related messages. So, Aggregator is in fact a good decision.
What's left is to determine how the Aggregator will know when to send a message it has been aggregating. The pattern describes a few algorithms for the Aggregator to know when to send the message. These include algorithms to cause the aggregator to send out its contents after a certain amount of time has elapsed, after all required fields in a data set have been completed, and others. The problem with all of these approaches is that the aggregator is controlling the message flow, not the client. And the client is the major bottleneck in this case, not the message flow.
This is because the Aggregator is assuming the consumers of its purged messages (the client application in this case) are Event-Driven Consumer s, or consumers that rely on events from an external source. We need to turn the client into a Polling Consumer , or a consumer that continuously checks for messages, so the client application can control the message flow. We can do this by creating a background thread that continuously cycles through the set of bonds and updates and flashes any changes that have occurred since the last iteration. This way, the client controls when messages are received and as a result, guarantees that it will never become overloaded with messages during high update periods. 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.

Bond trading system

O Futuro da Taxa de Juros se Contrairá!
está disponível para compra com o.
JB BONDBUSTER TRADING SYSTEM.
É uma coisa para nós falar sobre o que é esperado, mas é muito mais importante estar preparado com bastante antecedência. Mas como podemos nos preparar? As opiniões são baratas. Dependendo de quem você fala ou de quem você ouve, estamos prestes a mergulhar na depressão profunda, uma ligeira recessão, um período de inflação, um período de hiperinflação, estagnação ou condições econômicas até agora desconhecidas.
Em 10 dias, vou divulgar o que acredito ser o MEU MELHOR SISTEMA DE NEGOCIAÇÃO para futuros de taxa de juros. Alguns detalhes do sistema são explicados abaixo.
Negociações de curto prazo em 30 anos Tbond, 10 anos,
Futuros TNote de 5 anos e 2 anos.
Meu novo sistema de negociação JB Bond Buster é executado sob o software Genesis Gold ou Platinum. Todos os dias após o fechamento do mercado, ele gera sinais de curto prazo, alta probabilidade, 100% objetivos e baseados em regras em todo o amplo espectro de futuros de taxas de juros. Isso é extremamente importante devido às anomalias nos rendimentos (a curva de rendimento) que criará oportunidades e relações sem precedentes entre os vários instrumentos. É concebível que meu JB Bond Buster seja um longo veículo de taxa de juros enquanto seja curto outro, aproveitando assim os giros na curva de rendimentos.
Meu novo sistema de negociação incorpora alguns dos padrões de preços e horários mais confiáveis, consistentes e precisos que eu já descobri! O processo de desenvolvimento que usei na construção do meu novo sistema foi cuidadoso, não excessivamente otimizado, e contém mais de três anos de dados de amostra para validar sua precisão. Em suma, eu estou muito satisfeito e entusiasmado com o novo sistema e seu potencial de lucro. Eu acredito que o JB Bond Buster pode mantê-lo no lado direito do mercado ao longo da inevitável volatilidade que nos espera apenas no final da estrada.
Quantidade estritamente limitada de sistemas disponíveis.
Só disponibilizo uma quantidade muito limitada do meu novo sistema, a fim de evitar a diluição da performance. Ofereço o sistema aos meus clientes com base no primeiro a chegar, primeiro a ser servido. Como cliente, você também é elegível para o preço de desconto. E eu mantive o preço baixo e elegível para o preço do cartão 2fer (economize 50%).
O que o sistema JB BondBuster inclui.
Cesta e sistema de estratégia JB Bond Buster para o software Genesis Platinum e Gold Manual de vídeo Instruções completas de instalação Atualizações do sistema se e quando emitidas Suporte técnico fornecido por mim pessoalmente Divulgação completa das regras comerciais O JB Bond Buster Webinar de 60 minutos 100% negociações objetivas e sinais Sinais para T-bonds de 30 anos, notas T de 10 anos, notas T de cinco anos e notas T de dois anos Divulgação completa de regras e procedimentos Paradas iniciais e paradas de trânsito Todas as negociações são rastreadas do início ao fim.
Você não usa o Genesis? Receba todos os dias os sinais.
Alguns de vocês não usam o software de negociação Genesis, mas você quer trocar meu novo sistema.
Mostrado abaixo, com as comissões deduzidas, são as histórias de desempenho de cada futuro de taxa de juros. Embora possamos garantir o futuro, acredito que os conceitos e padrões que usei para desenvolver o JB Bond Buster continuarão a funcionar bem, permitindo-nos tirar proveito da volatilidade voltada em nossos mercados. Idealmente, seria melhor tomar todos os sinais nos quatro mercados para replicar um histórico. Observe que esse registro NÃO mostra estratégia de maximização de lucros. O comprimento médio do comércio é de 7 dias. В.
Nota: O BondBuster Trading System está disponível para compra com o.
O melhor do comércio para você,
Escolha o link apropriado abaixo.
ou ligue para o escritório: Ph 831-430-0600, 800-678-5253.