Design Mønstre Trading System

Jeg er i ferd med å designe en handelsapplikasjon som vil bruke en Markets API til å legge ordre på markedet. Dette er ikke en komplisert søknad om høy ytelsesalgoritmisk handel av typen som finnes i investeringsbanker. Dette er bare et lite personlig søknad som vil handle kanskje to eller tre ganger om dagen, avhengig av markedstilstendighetene. Søknaden vil bestå av følgende modulpakker: Strategier - De faktiske handelsalgoritmer Analytics - Klassene for å analysere levende priser på markedet for å produsere buysell signaler Tjenester - Klassene som brukes for å opprettholde en forbindelse til markedet, hente markedsinformasjon og plassere buysell bestillinger. Så langt, alt som kreves for søknaden, synes å være tilgjengelig på internett: Apache CXF for å generere Java-klassene som brukes for å få tilgang til markedets webtjenester. Apache Maths for å utføre prisanalysen Wikipedia for de ulike designmønstrene, dvs. Factory, SubjectObserver, State, etc. Hvor jeg virkelig sitter fast er imidlertid med algoritmer. Ive bestemte seg for å bruke statsmønsteret til å partisjonere, inn i logiske grupperinger, de ulike logikkstykkene som skal utføres når visse markedsforhold er oppfylt. Problemet er at jeg begynner å se at det er veldig sannsynlig at hver statsklasse vil inneholde en eksplosjon av om andre erklæringer: Jeg kan ikke hjelpe, men føler at jeg mangler noe her, og at det må eksistere noe rammeverk eller designmønster jeg vet ikke om hvilken gjør det mulig for utvikleren å inkapslere alle inngangene og utgangene fra en gitt forretningskontekst til et begrenset antall forretningsprosjekter, hvor utdataene for virksomhetsregimer kan bygges. Dvs. Snarere enn å måtte hardkodes algoritmene Jeg håper at det skal være mulig å gjøre søknaden til en reglerprosessor av noe slag. Dessverre vet jeg ikke hvor jeg skal begynne på dette. Jeg håper jeg har forklart dilemaet mitt klart nok, hvis du vil at jeg skal klargjøre noe, vennligst gi meg beskjed. Takk spurte 8. oktober 09 kl. 22: 48Messaging Patterns 187 Integrering Mønstre i praksis 187 Case Study: Bond Trading System (Av Jonathan Simon) Det er lett å avstå fra en stor samling av mønstre eller et mønster språk. Mønstre er abstraksjonen av en ide i en gjenbrukbar form. Ofte gjør den svært generiske naturen til mønstre som gjør dem så nyttige, også vanskelige å forstå. Noen ganger er det beste å forstå forståelsesmønstre en ekte verdenseksempel. Ikke et opptatt scenario av hva som kan skje, men hva som faktisk skjer og hva som vil skje. Dette kapitlet gjelder mønstre for å løse problemer ved hjelp av en oppdagingsprosess. Systemet vi skal diskutere er et obligasjonshandelssystem som jeg jobbet med i to år fra innledende design gjennom produksjon. Vi vil utforske scenarier og problemer som ble oppstått og hvordan de skal løses med mønstre. Dette innebærer beslutningsprosessen for å velge et mønster, samt hvordan man kan kombinere og justere mønstre som passer til behovene til systemet. Og dette er alt gjort med tanke på de kreftene som oppstår i virkelige systemer, inkludert forretningsbehov, klientbeslutninger, arkitektoniske og tekniske krav, samt eldre systemintegrasjon. Hensikten med denne tilnærmingen er å gi en klarere forståelse av mønstrene selv gjennom praktisk anvendelse. Å bygge et system En stor Wall Street investeringsbank utarbeider å bygge et obligasjonsprissystem i et forsøk på å strømlinjeforme arbeidsflyten i deres obligasjonshandelskort. For tiden må obligasjonshandlere sende priser for et stort antall obligasjoner til flere forskjellige handelssteder, hver med sitt eget brukergrensesnitt. Målet for systemet er å minimere minutiae av prissetting av alle sine obligasjoner kombinert med avansert analytisk funksjonalitet spesifikk for obligasjonsmarkedet i et enkelt innkapslet brukergrensesnitt. Dette betyr integrasjon og kommunikasjon med flere komponenter over ulike kommunikasjonsprotokoller. Systemet på høy nivå ser slik ut: Først kommer markedsdata inn i systemet. Markedsdata er data angående pris og andre egenskaper av obligasjonen som representerer hva folk er villige til å kjøpe og selge obligasjonen til på det frie markedet. Markedsdataene sendes umiddelbart til analysemotoren som endrer dataene. Analytics refererer til matematiske funksjoner for finansielle applikasjoner som endrer prisene og andre attributter av obligasjoner. Dette er generiske funksjoner som bruker inputvariabler til å skreddersy resultatene av funksjonen til en bestemt binding. Klientprogrammet som kjører på hver handelsdrivende skrivebord, konfigurerer analysemotoren på en bransjebasert basis, og kontrollerer spesifikkene for analysene for hvert bånd som foretaket prissetter. Når analysene er brukt på markedsdataene, sendes de modifiserte dataene ut til ulike handelssteder hvor handelsmenn fra andre firmaer kan kjøpe eller selge obligasjonene. Arkitektur med mønstre Med denne oversikten over systemets arbeidsflyt, kan vi nærme noen av de arkitektoniske problemene vi møter under designprosessen. La oss ta en titt på det vi kjenner til i dag. Traders trenger en svært responsiv applikasjon på både Windows NT og Solaris-arbeidsstasjoner. Derfor bestemte vi oss for å implementere klientprogrammet som en Java tykk klient på grunn av plattform uavhengighet og evne til å reagere raskt på brukerinngang og markedsdata. På server siden arver vi arv C-komponenter som systemet vårt skal bruke. Markeddatakomponentene kommuniserer med TIBCO Informasjonsbuss (TIB) meldingsinfrastruktur. Vi arver følgende komponenter: Market Data Price Feed Server. Publiserer innkommende markedsdata til TIB. Analytics Engine. Utfører analyser på innkommende markedsdata og sender de modifiserte markedsdataene til TIB. Bidragsserver. Utfører all kommunikasjon med handelssteder. Handelsstedene er tredjepartskomponenter som ikke kontrolleres av banken. Underliggende system for delsystemer for eldre markedsdata Vi må bestemme hvordan de separate delsystemene (Java tykk klient, markedsdata og bidrag) skal kommunisere. Vi kunne ha den tykke klienten kommunisere direkte med de eldre serverne, men det ville kreve for mye forretningslogikk på klienten. I stedet vel bygge et par Java-gateways for å kommunisere med de eldre serverne. Prissettingsgatewayen for markedsdata, en bidragsportway for å sende priser til handelssteder. Dette vil oppnå god innkapsling av forretningslogikken knyttet til disse områdene. De nåværende komponentene i systemet er vist nedenfor. Tilkoblingene merket som. indikere at vi fortsatt er usikre på hvordan noen av komponentene vil kommunisere. Systemet og dets komponenter Det første kommunikasjonsspørsmålet er hvordan du integrerer Java-tykk klient og de to Java-serverkomponentene for å utveksle data. La oss se på de fire integrasjonsstilene som foreslås i denne boken: File Transfer. Delt database. Remote Procedure Invocation. og Meldinger. Vi kan utelukke delt database umiddelbart fordi vi ønsket å opprette et lag av abstraksjon mellom klienten og databasen og ikke vil ha database tilgangskode i klienten. Filoverføring kan på samme måte utelukkes siden minimal ventetid er nødvendig for å sikre at nåværende priser sendes ut til handelsstedene. Dette gir oss et valg mellom Remote Procedure Invocation eller Messaging. Java-plattformen gir innebygd støtte for både Remote Procedure Invocation og Meldinger. Integrering av RPC-stil kan oppnås ved hjelp av Remote Method Invocation (RMI), CORBA eller Enterprise Java Beans (EJB). Java Messaging Service (JMS) er den felles API for meldingsstil-integrasjon. Så begge integreringsstilene er enkle å implementere i Java. Så som vil fungere bedre for dette prosjektet, Remote Procedure Invocation eller Meldinger. Det er bare én forekomst av Pricing Gateway og en forekomst av Contribution Gateway i systemet, men vanligvis kobler mange Tyske klienter samtidig til disse tjenestene (en for hver obligasjonshandler som skjer for å være logget inn på en bestemt tid). Videre ønsker banken at dette skal være et generisk prissystem som kan benyttes i andre applikasjoner. Foruten et ukjent antall Think Clients, kan det være et ukjent antall andre programmer som bruker prisdataene som kommer ut av Gateways. En tykk klient (eller et annet program som bruker prisdataene) kan ganske enkelt bruke RPC til å ringe til Gateways for å få prisdata og påkalle behandling. Imidlertid vil prisdata publiseres kontinuerlig, og enkelte kunder er bare interessert i visse data, slik at det kan være vanskelig å få relevante data til de riktige kundene på en riktig måte. Klienten kunne kollidere Gateways, men det vil skape mye overhead. Det ville være bedre for Gateways å gjøre dataene tilgjengelige for kundene så snart det er tilgjengelig. Dette vil imidlertid kreve at hver Gateway skal holde rede på hvilke klienter som for øyeblikket er aktive, og som vil ha hvilke spesifikke data da, når et nytt stykke data blir tilgjengelig (som vil skje mange ganger i sekundet), må Gateway gjøre en RPC til hver interessert klient for å sende dataene til klienten. Ideelt sett bør alle kunder bli varslet samtidig, så hver RPC må gjøres i sin egen samtidige tråd. Dette kan fungere, men blir veldig komplisert veldig raskt. Meldinger forenkler dette problemet sterkt. Med Meldinger. Vi kan definere separate kanaler for ulike typer prisdata. Da, når en Gateway får et nytt stykke data, vil det legge til en melding som inneholder dataene til Publiser-Abonner-kanalen for den datatypen. I mellomtiden vil alle klienter som er interessert i en bestemt type data, høre på kanalen for den typen. På denne måten kan Gateways enkelt sende ut nye data til hvem som er interessert, uten å måtte vite hvor mange lytteapplikasjoner det er eller hva de er. Klientene må fortsatt kunne påberope seg også i Gateways. Siden det kun er to Gateways, og klienten kan sannsynligvis blokkere mens metoden påberopes synkront, kan disse klient-til-gateway-invokasjonene ganske enkelt implementeres ved hjelp av RPC. Men siden vi allerede bruker meldinger for Gateway-to-client-kommunikasjon, er meldinger sannsynligvis like god en måte å implementere klient-til-Gateway-kommunikasjon også. Derfor vil all kommunikasjon mellom Gateways og klientene oppnås gjennom meldinger. Fordi alle komponentene er skrevet i Java, presenterer JMS et enkelt valg for meldingssystemet. Dette skaper effektivt en Meldingsbuss eller en arkitektur som gjør det mulig for fremtidige systemer å integrere med dagens system med liten eller ingen endringer i meldingsinfrastrukturen. På denne måten kan virksomhetsfunksjonaliteten til applikasjonen enkelt brukes av et annet program som banken utvikler. Java-komponenter Kommunisere med JMS JMS er bare en spesifikasjon, og vi må bestemme et JMS-kompatibelt meldingssystem. Vi bestemte oss for å bruke IBM MQSeries JMS fordi banken er en IBM-butikk, ved hjelp av WebSphere applikasjonsservere og mange andre IBM-produkter. Som et resultat vil vi bruke MQSeries siden vi allerede har en støtteinfrastruktur på plass og et nettstedslisens for produktet. Det neste spørsmålet er hvordan du kobler MQSeries messaging system med den frittstående C-bidragsserveren og TIBCO-baserte Market Data og Analytics Engine-servere. Vi trenger en måte for MQSeries-forbrukerne å få tilgang til TIB-meldingene. Men hvordan kan vi kanskje bruke Message Translator-mønsteret til å oversette TIB-meldinger til MQSeries-meldinger. Selv om C-klienten for MQSeries fungerer som en Meldingsoversetter. bruk av det ville ofre JMS server uavhengighet. Og selv om TIBCO har en Java API, har kunden arkitekt og leder avvist det. Som et resultat, må Message Translator-tilnærmingen bli forlatt. Broen fra TIB-serveren til MQSeries-serveren krever kommunikasjon mellom C og Java. Vi kunne bruke CORBA, men hva med meldingene. En nærmere titt på Message Translator-mønsteret viser at den er relatert til Kanaladapteren ved bruk av kommunikasjonsprotokoller. Hjertet på en kanaladapter er å koble ikke-meldingssystemer til meldingssystemer. Et par kanaladaptere som kobler til to meldingssystemer, er en Messaging Bridge. Formålet med en Meldingsbro er å overføre meldinger fra ett meldingssystem til et annet. Dette er akkurat det vi gjør med den ekstra kompleksiteten til den språket Java til C-kommunikasjon. Vi kan implementere krysspråket Messaging Bridge ved hjelp av en kombinasjon av Channel Adapter s og CORBA. Vi skal bygge to lettvektkanaladapter-servere, en i C-kommunikasjon med TIB, og en i Java-kommunikasjon med JMS. Disse to kanaladapteren. som er Message Endpoint s selv, vil kommunisere med hverandre via CORBA. Som vårt valg for MQSeries, vil vi bruke CORBA i stedet for JNI siden det er en bedriftsstandard. Messagingbroen implementerer den effektivt simulerte meldingsoversettelsen mellom tilsynelatende inkompatible meldingssystemer og forskjellige språk. Meldingsoversetter ved hjelp av kanaladaptere Det neste diagrammet viser dagens systemdesign, inkludert Gateways og andre komponenter. Dette er et godt eksempel på mønsterapplikasjon. Vi kombinerte to kanaladapter s med en ikke-meldingsprotokoll for å implementere Message Translator-mønsteret, effektivt ved å bruke ett mønster for å implementere et annet mønster. I tillegg endret vi kanaladapterens kontekst for å koble to meldingssystemer med en ikke-meldingsoverskrivende oversettelsesprotokoll i stedet for å koble et meldingssystem til et ikke-meldingssystem. Det nåværende systemet med kanaladaptere Strukturering av kanaler En nøkkel til å jobbe med mønstre, er ikke bare å vite når du skal bruke hvilket mønster, men også hvordan du bruker det mest effektivt. Hvert mønsterimplementasjon må ta hensyn til spesifikasjoner av teknologiplattformen, samt andre designkriterier. Denne delen gjelder samme oppdagingsprosess for å finne den mest effektive bruken av Publiser-Abonner-kanalen i sammenheng med markedsdata-serveren som kommuniserer med analysemotoren. Real-time markedsdata stammer fra markedsdata, en C-server som sender markedsdata på TIB. Markedsdatainngangen bruker en separat Publiser-Abonner-kanal for hver obligasjon den publiserer priser for. Dette kan virke litt ekstremt siden hvert nytt bånd trenger sin egen nye kanal. Men dette er ikke så alvorlig siden du ikke trenger å skape kanaler i TIBCO. Snarere er kanaler referert av et hierarkisk sett med emne navn kalt fag. TIBCO-serveren filtrerer deretter en enkelt meldingstrøm etter emne, og sender hvert unikt emne til en enkelt virtuell kanal. Resultatet av dette er en veldig lett meldingskanal. Vi kan lage et system som publiserer på noen få kanaler, og abonnenter kan bare lytte til priser de er interessert i. Dette ville kreve at abonnenter bruker et meldingsfilter eller selektiv forbruker for å filtrere hele datafloden for interessante obligasjonspriser, og avgjøre om hver melding bør behandles som den er mottatt. Gitt at markedsdataene er publisert på obligasjonsbaserte kanaler, kan abonnenter registrere seg for oppdateringer på en serie obligasjoner. Dette gjør det mulig for abonnenter å filtrere ved å selektivt abonnere på kanaler og bare motta oppdateringer av interesse i stedet for å bestemme etter at meldingen er mottatt. Det er viktig å merke seg at bruk av flere kanaler for å unngå filtrering er en uavhengig bruk av meldingskanaler. I sammenheng med TIBCO-teknologien bestemmer vi imidlertid om å implementere eller eie filtre eller utnytte kanalfiltreringen som er innebygd i TIBCO - i stedet for å bruke så mange kanaler. Den neste komponenten vi må designe, er analysemotoren, en annen CTIB-server som vil modifisere markedsdataene og rebroadcast den til TIB. Selv om det er utenfor rammen av vår JavaJMS-utvikling, jobber vi nært med C-teamet for å designe det siden vi er analytikkmotorerens primære kunde. Problemet ved hånden er å finne kanalstrukturen som mest effektivt rebroadcast de nylig modifiserte markedsdataene. Siden vi allerede har en dedikert Meldingskanal per obligasjon arvet fra markedsdataprismaten, ville det være logisk å endre markedsdataene og rebroadcast de modifiserte markedsdataene på obligasjonsdisponerte Message Channel. Men dette vil ikke fungere siden analysen endrer obligasjonsprisene, er næringsdrivende spesifikke. Hvis vi rebroadcast de endrede dataene på obligasjonsmeldingskanalen. Vi vil ødelegge dataintegriteten ved å erstatte generiske markedsdata med leverandørens spesifikke data. På den annen side kan vi ha en annen meldingstype for handelsmannsspesifikke markedsdata som vi publiserer på samme kanal, slik at abonnenter kan bestemme hvilken melding de er interessert i for å unngå å ødelegge dataintegriteten. Men da må kundene implementere sine egne filtre for å skille ut meldinger til andre forhandlere. I tillegg vil det bli en betydelig økning i meldinger mottatt av abonnenter, og legger en unødvendig byrde på dem. Det er to alternativer: En kanal per handler: Hver handelsmann har en bestemt kanal for de modifiserte markedsdataene. På denne måten forblir de opprinnelige markedsdataene intakte, og hver handelsvirksomhet kan lytte til sin spesifikke forhandler Message Channel for de modifiserte prisoppdateringene. Én kanal per handler per obligasjon: Opprett en meldingskanal per-trader per-obligasjon utelukkende for de modifiserte markedsdataene for det obligasjonen. Markedsdataene for obligasjon ABC vil for eksempel bli publisert på kanalen Bond ABC, mens de modifiserte markedsdataene for Trader A vil bli publisert på Message Channel Trader A, Bond ABC, modifiserte markedsdata for Trader B på Trader B, Bond ABC, og så videre. En kanal per handler En kanal per obligasjon per handler Det er fordeler og ulemper for hver tilnærming. Per-bond-tilnærmingen bruker for eksempel mye mer Message Channel. I verste fall vil antall Message Channel være antall obligasjoner totalt multiplisert med antall forhandlere. Vi kan sette øvre grenser på antall kanaler som skal opprettes siden vi vet at det bare er rundt 20 handelsmenn, og de pris aldri mer enn et par hundre obligasjoner. Dette setter den øvre grensen under 10.000-serien, noe som ikke er så uhyggelig i forhold til nesten 100.000 Message Channel som markedsdataprismaten bruker. Dessuten, siden vi bruker TIB og Message Channel, er det ganske rimelig, er antall Message Channel s ikke et alvorlig problem. På den annen side kan det rene antallet Message Channel s være et problem fra et ledelsesperspektiv. Hver gang en obligasjon legges til, må en kanal for hver forhandler opprettholdes. Dette kan være alvorlig i et veldig dynamisk system. Vårt system er imidlertid i hovedsak statisk. Den har også en infrastruktur for automatisk styring av meldingskanal s. Dette kombinert med den arvede arkitekturen til en arvskomponent ved hjelp av en lignende tilnærming, minimerer ulemper. Dette er ikke å si at vi burde gjøre et unødvendigt stort antall Message Channel s. Snarere kan vi implementere en arkitektonisk tilnærming som bruker et stort antall Message Channel s når det er grunn. Og det er en grunn i dette tilfellet som kommer ned til plasseringen av logikken. Hvis vi implementerer den næringsdrivende tilnærmingen, trenger Analytics Engine logikk for å gruppere inn - og utgangskanaler. Dette skyldes at inngangskanaler fra Analytics-motoren er per obligasjon, og utgående meldingskanal s vil være per handler, og krever at Analytics-motoren skal rute all analyseinngang fra flere obligasjoner til en bestemt handelsmann til en forhandler-spesifikk utgående meldingskanal. Dette gjør at analysemotoren effektivt blir til en innholdsbasert ruter for å implementere tilpasset rutingslogikk for applikasjonen vår. Etter Message Bus-strukturen er Analytics Engine en generisk server som kan brukes av flere andre systemer i. Så vi vil ikke skyte den med systemspesifikk funksjonalitet. På den annen side virker per-bond-tilnærmingen siden ideen om en næringsdrivende som eier analyseproduksjonen av obligasjonsprisene, er en akseptert praksis. Per-bond-tilnærmingen holder meldingskanalseparasjonen av markedsdatainngangen intakt, mens du legger til flere flere Message Channel s. Før vi når klienten, vil vi ha en innholdsbasert ruter for å kombinere disse flere kanalene til et håndterbart antall kanaler. Vi vil ikke at klientprogrammet kjører på handlerbordet for å høre på tusenvis eller titusenvis av Message Channel s. Nå blir spørsmålet hvor du skal sette innholdsbasert ruteren. Vi kunne ganske enkelt få CTIB-kanaladapteren til å sende alle meldingene til Pricing Gateway på en enkelt meldingskanal. Dette er dårlig av to grunner, vi ville splitte opp forretningslogikken mellom C og Java, og vi ville miste fordelene med den separate Meldingen Channel s på TIB-siden, slik at vi kunne unngå å filtrere senere i datastrømmen. Når vi ser på våre Java-komponenter, kan vi enten plassere den i prisgatewayen eller opprette en mellomkomponent mellom prisgatewayen og klienten. I teorien, hvis vi fortsatte den obligasjonsbaserte separasjonen av Message Channel s hele veien til klienten, ville Pricing Gateway rebroadcast prisinformasjon med samme kanalstruktur som Pricing Gateway og Analytics Engine. Dette betyr en duplisering av alle obligasjons dedikert TIB kanaler i JMS. Selv om vi lager en mellomkomponent mellom prissettingsgatewayen og klienten, vil Pricing Gateway fortsatt måtte duplisere alle kanalene i JMS. På den annen side tillater implementering av logikk direkte i Prissettingsgateway oss å unngå å duplisere det store antallet kanaler i JMS, slik at vi kan lage et mye mindre antall kanaler i rekkefølge av en per handelsmann. Prissettingsgatewayen registrerer seg gjennom CTIB-kanaladapteren som forbruker for hvert obligasjonslån til hver forhandler i systemet. Da vil Pricing Gateway videresende hver enkelt klient bare meldingene som er relatert til den aktuelle forhandleren. På denne måten bruker vi kun et lite antall Message Channel s på JMS-enden, samtidig som vi maksimerer fordelene ved separasjonen på TIB-enden. Den komplette markedsdataflyten til klienten Diskusjonskommunikasjonsdiskusjonen er et godt eksempel på hvordan integrering av mønstre er viktig. Målet her var å finne ut hvordan man effektivt bruker Message Channel s. Å si at du bruker et mønster, er ikke nok. Du må finne ut hvordan du best kan implementere det og innlemme i systemet for å løse problemene ved hånden. I tillegg viser dette eksemplet forretningskrefter i aksjon. Hvis vi kunne implementere forretningslogikk i noen av komponentene våre, kunne vi ha gått med den per handlende tilnærming og implementert en overordnet enklere tilnærming med mange mindre kanaler. Velge en meldingskanal Nå som vi kjenner mekanikkene til kommunikasjonen mellom JavaJMS-komponentene og C TIBCO-komponentene, og vi har sett noen strukturer for Message Channel, må vi bestemme hvilken type JMS Message Channel som Java-komponentene skal bruke til å kommunisere . Før vi kan velge mellom de forskjellige Meldingskanaler som er tilgjengelige i JMS, kan vi se på meldingsflyten på høyt nivå i systemet. Vi har to gateways (Pricing and Contribution) kommuniserer med klienten. Markedsdata flyter til klienten fra Pricing Gateway som sender den ut til Bidrags Gateway. Klientprogrammet sender melding til Pricing Gateway for å endre analysen som blir brukt på hvert obligasjon. Bidragsporten sender også meldinger til klientprogrammet som omdiriger statusen til prisoppdateringene til de forskjellige handelsstedene. Systemmeldingsflyten JMS-spesifikasjonen beskriver to meldingskanaltyper, punkt-til-punkt-kanal (JMS-kø) og publiser-abonner kanal (JMS-emne). Husk at saken for bruk av publiseringsabonnement er å gjøre det mulig for alle interesserte forbrukere å motta en melding, mens saken for bruk av punkt-til-punkt er å sikre at bare en kvalifisert forbruker mottar en bestemt melding. Mange systemer vil ganske enkelt sende meldinger til alle klientprogrammer, slik at hver enkelt klientprogrammer bestemmer seg for å behandle en bestemt melding eller ikke. Dette vil ikke fungere for vår søknad, siden det sendes et stort antall markedsdata meldinger til hvert klientprogram. Hvis vi sender markedsdataoppdateringer til uinteressert næringsdrivende, vil vi unødvendig kaste bort klientprosessor-sykluser ved å avgjøre om en markedsdataoppdatering skal behandles eller ikke. Point-to-Point Channel s høres opprinnelig som et godt valg siden klientene sender meldinger til unike servere og omvendt. Men det var et forretningskrav at forhandlere kan være logget inn på flere maskiner samtidig. Hvis vi har en forhandler logget inn på to arbeidsstasjoner samtidig og en pris-til-punkt-prisoppdatering sendes, vil bare en av de to klientprogrammene få meldingen. Dette skyldes at bare en forbruker på en punkt-til-punkt-kanal kan motta en bestemt melding. Legg merke til at bare den første av hver gruppe av handelshandlerprogrammer mottar meldingen. Punkt-til-punkt-meldinger for prisoppdateringer Vi kan løse dette ved hjelp av mottakerlistemønsteret, som publiserer meldinger til en liste over tilsiktede mottakere, og garanterer at kun klienter i mottakerlisten vil motta meldinger. Ved hjelp av dette mønsteret kan systemet opprette mottakerlister med alle klientapplikasjonsinstanser relatert til hver handelsmann. Sende en melding som er relatert til en bestemt handelsmann, vil i sin tur sende meldingen til hvert program i mottakerlisten. Dette garanterer at alle klientapplikasjonsinstanser knyttet til en bestemt forhandler vil motta meldingen. Ulempen med denne tilnærmingen er at det krever ganske mye implementeringslogikk for å administrere mottakerne og sende meldinger. Mottakerliste for prisoppdateringer Selv om punkt-til-punkt kan gjøres til arbeid, kan vi se om det er en bedre måte. Ved å bruke Publiser-Abonner kanal s, kan systemet kringkaste meldinger på forhandlerspesifikke kanaler i stedet for klientprogrammerte spesifikke kanaler. På denne måten vil alle klientprogrammer som behandler meldinger for en enkelthandler motta og behandle meldingen. Publiser-Abonner Meldinger for prisoppdateringer Ulempen med å bruke Publiser-Abonner Channel s er at unikt meldingsprosessering ikke er garantert med serverkomponentene. Det ville være mulig for flere forekomster av en serverkomponent å bli instantiated, og hver instans behandler samme melding, og muligens sender ut ugyldige priser. Tilbakekalling av systemmeldingsflyten er kun en enkelt kommunikasjonsretning tilfredsstillende med hver meldingskanal. Server-til-klientkommunikasjon med publiseringsabonnement er tilfredsstillende mens klient-til-server-kommunikasjon ikke er, og klient-serverkommunikasjon med punkt-til-punkt er tilfredsstillende mens serverklient ikke er. Siden det ikke er behov for å bruke samme meldingskanal i begge retninger, kan vi bare bruke hver meldingskanal. Klient-til-server-kommunikasjon vil bli implementert med punkt-til-punkt mens kommunikasjon mellom server og klient blir implementert med publiseringsabonnement. Ved hjelp av denne kombinasjonen av Message Channel s, har systemet fordeler fra direkte kommunikasjon med serverkomponentene ved hjelp av punkt-til-punkt-meldinger og multicast-naturen av publiseringsabonnement uten noen av ulempene. Meldingsflyt med kanaltyper Problemløsning med mønstre Mønster er verktøy og samlinger av mønstre er verktøykasser. De hjelper med å løse problemer. Noen tror at mønstre bare er nyttige under design. Etter verktøykasseanalogen er dette som å si at verktøy bare er nyttige når du bygger et hus, ikke når du retter det. Faktum er at mønstre er et nyttig verktøy gjennom et prosjekt når det brukes godt. I de følgende avsnittene vil vi bruke samme mønsterutforskingsprosess vi brukte i forrige avsnitt for å løse problemer i vårt nåværende system. Blinkende markedsdataoppdateringer Traders vil at tabellceller skal blinke når nye markedsdata er mottatt for et obligasjon, tydelig indikasjon på endringer. Java-klienten mottar meldinger med nye data som utløser en klientdatabaseoppdatering og til slutt blinker i tabellen. Problemet er at oppdateringer kommer ganske ofte. GUI-trådstakken blir overbelastet og til slutt fryser klienten, siden den ikke kan svare på brukerinteraksjon. Vi antar at blinkingen er optimalisert og konsentrert om datastrømmen av meldinger gjennom oppdateringsprosessen. En undersøkelse av ytelsesdata viser at klientprogrammet mottar flere oppdateringer hvert sekund. Noen oppdateringer skjedde mindre enn en millisekund fra hverandre. To mønstre som virker som om de kan bidra til å redusere meldingsflyten, er Aggregator og Message Filter. En første tanke er å implementere et meldingsfilter for å kontrollere hastigheten på meldingsflyten ved å kaste ut oppdateringer mottatt en liten stund etter referansemeldingen. Som et eksempel, kan vi si at vi skal ignorere meldinger innen 5 millisekunder av hverandre. Meldingsfilteret kan cache tiden for den siste akseptable meldingen og kaste ut noe mottatt innen de neste 5 millisekunder. Selv om andre programmer kanskje ikke klarer å tåle datatap i en slik grad, er dette helt akseptabelt i vårt system på grunn av hyppigheten av prisoppdateringer. Tidsbasert Meldingsfilter Problemet med denne tilnærmingen er at ikke alle datafeltene blir oppdatert samtidig. Hvert obligasjon har omtrent 50 datafelter som vises til brukeren inkludert pris. Vi innser at ikke alle feltene er oppdatert i hver melding. Hvis systemet ignorerer påfølgende meldinger, kan det godt være å kaste ut viktige data. Det andre mønsteret av interesse er Aggregatoren. Aggregatoren brukes til å håndtere avstemningen av flere relaterte meldinger til en enkelt melding, og potensielt reduserer meldingsflyten. Aggregatoren kunne beholde en kopi av obligasjonsdata fra den første aggregerte meldingen, og oppdater deretter kun nye eller endrede felt påfølgende meldinger. Til slutt vil de aggregerte obligasjonsdataene sendes i en melding til klienten. For nå antar vi at Aggregatoren sender en melding hver 5. millisekunder som Meldingsfiltret. Senere, velg et annet alternativ. Aggregator med delvis suksessive oppdateringer Aggregatoren. som et annet mønster, er ikke en sølvkule, den har sine plusser og minuser som må utforskes. En potensiell minus er at implementering av en Aggregator ville redusere meldingen trafikk med stor grad i vårt tilfelle bare hvis mange meldinger kommer inn innen relativt kort tid om samme obligasjon. På den annen side ville vi ikke oppnå noe hvis Java-klienten bare mottar oppdateringer for ett felt på tvers av alle handelsobligasjoner. 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. Whats 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 couldnt be fixed with a thousand patterns. We later addressed this problem by refactoring the message flow architecture to route messages directly from the Pricing Gateway to the Contribution Gateway. So patterns can help design and maintain a system, but dont necessarily make up for poor upfront design. Throughout this chapter, we have applied patterns to several different aspects of a bond trading system including solving initial upfront design problems and fixing a nearly job threatening production crash with patterns. We also saw these patterns as they already exist in third party product, legacy components, and our JMS and TIBCO messaging systems. Most importantly, these are real problems with the same types of architectural, technical and business problems we experience as we design and maintain our own systems. Hopefully reading about applying patterns to this system helps give you a better understanding of the patterns as well as how to apply them to your own systems. Want to keep up-to-date Follow My Blog . Want to read more in depth Check out My Articles . Want to see me live See where I am speaking next . Find the full description of this pattern in: Enterprise Integration Patterns Gregor Hohpe and Bobby Woolf ISBN 0321200683 650 pages Addison-Wesley From Enterprise Integration to Enterprise Transformation: My new book describes how architects can play a critical role in IT transformation by applying their technical, communication, and organizational skills with 37 episodes from large-scale enterprise IT. Parts of this page are made available under the Creative Commons Attribution license. You can reuse the pattern icon, the pattern name, the problem and solution statements (in bold), and the sketch under this license. Other portions of the text, such as text chapters or the full pattern text, are protected by copyright. Messaging Patterns 187 Integration Patterns in Practice 187 Case Study: Bond Trading SystemTrading Systems: Designing Your System - Part 1 13 The preceding section of this tutorial looked at the elements that make up a trading system and discussed the advantages and disadvantages of using such a system in a live trading environment. I denne delen bygger vi på den kunnskapen ved å undersøke hvilke markeder som er spesielt velegnet til systemhandel. Vi vil da ta en mer grundig titt på de ulike sjangrene av handelssystemer. Handel i ulike markeder Aksjemarkeder Aksjemarkedet er trolig det vanligste markedet for handel, særlig blant nybegynnere. I denne arena dominerer store spillere som Warren Buffett og Merrill Lynch, og tradisjonelle verdier og vekststrategier er langt den vanligste. Likevel har mange institusjoner investert betydelig i design, utvikling og implementering av handelssystemer. Individuelle investorer er med i denne trenden, men sakte. Her er noen viktige faktorer å huske på når du bruker handelssystemer i aksjemarkedene: 13 Den store mengden aksjer som er tilgjengelig, tillater handelsmenn å teste systemer på mange forskjellige typer aksjer - alt fra ekstremt volatile over-the-counter (OTC) aksjer til ikke-flyktige blå sjetonger. Effektiviteten av handelssystemer kan begrenses av den lave likviditeten til enkelte aksjer, spesielt OTC og rosa arkproblemer. Provisjoner kan spise i fortjeneste generert av vellykkede handler, og kan øke tap. OTC og rosa ark aksjer ofte pådrar ytterligere provisjon avgifter. De viktigste handelssystemene som brukes, er de som ser etter verdi - det vil si systemer som bruker forskjellige parametere for å avgjøre om en sikkerhet er undervurdert i forhold til tidligere prestasjoner, sine jevnaldrende eller markedet generelt. Valutamarkeder Valutamarkedet, eller forex. er det største og mest flytende markedet i verden. Verdens regjeringer, banker og andre store institusjoner handler trillioner dollar på valutamarkedet hver dag. De fleste institusjonelle handelsmenn på forexen er avhengige av handelssystemer. Det samme gjelder for enkeltpersoner på forexen, men noen handel basert på økonomiske rapporter eller rentebetalinger. Her er noen viktige faktorer å huske på når du bruker handelssystemer i forexmarkedet: Likviditeten i dette markedet - på grunn av det store volumet - gjør handelssystemene mer nøyaktige og effektive. Det er ingen provisjoner i dette markedet, bare sprer seg. Derfor er det mye lettere å foreta mange transaksjoner uten å øke kostnadene. Sammenlignet med mengden aksjer eller råvarer tilgjengelig, er antall valutaer som skal handles begrenset. Men på grunn av tilgjengeligheten av eksotiske valutapar - det vil si valutaer fra mindre land - er volatilitetsområdet ikke nødvendigvis begrenset. De viktigste handelssystemene som brukes i forex er de som følger trender (et populært ordtak i markedet er trenden er din venn), eller systemer som kjøper eller selger på breakouts. Dette skyldes at økonomiske indikatorer ofte forårsaker store prisbevegelser på en gang. Futures Equity, forex og råvaremarkeder tilbyr alle futures trading. Dette er et populært kjøretøy for systemhandel på grunn av økt utnyttbar utnyttelse og økt likviditet og volatilitet. Disse faktorene kan imidlertid kutte begge veier: de kan enten forstørre gevinstene dine eller forsterke tapene dine. Av denne grunn er bruken av futures vanligvis reservert for avanserte individuelle og institusjonelle systemhandlere. Dette skyldes at handelssystemer som kan kapitalisere på futures markedet krever mye større tilpasning, bruk mer avanserte indikatorer og ta mye lenger tid å utvikle. Så, hva er best Det er opp til den enkelte investor å bestemme hvilket marked som passer best til systemhandel - hver har sine egne fordeler og ulemper. De fleste er mer kjent med aksjemarkedene, og denne kjennskapen gjør det enklere å utvikle et handelssystem. Forex er imidlertid ofte antatt å være den overlegne plattformen for å drive handelssystemer - spesielt blant mer erfarne forhandlere. Videre, hvis en næringsdrivende bestemmer seg for å kapitalisere på økt løftestang og volatilitet, er futuresalternativet alltid åpent. Til slutt ligger valget i hendene til systemutvikleren. Typer av handelssystemer Trend-Følgende systemer Den vanligste metoden for systemhandel er trend-følgesystemet. I sin mest grunnleggende form venter dette systemet bare på en betydelig prisbevegelse, og kjøper eller selger i den retningen. Denne typen system banker på håp om at disse prisbevegelsene vil holde trenden. Flytte gjennomsnittlige systemer Ofte brukt i teknisk analyse. et glidende gjennomsnitt er en indikator som bare viser gjennomsnittsprisen på en aksje over en tidsperiode. Essensen av trender er avledet av denne måling. Den vanligste måten å bestemme inn - og utreise er en crossover. Logikken bak dette er enkel: en ny trend er etablert når prisen faller over eller under dens historiske pris gjennomsnitt (trend). Her er et diagram som tegner både prisen (blå linje) og IBMs 20-dagers røde linje: Breakout Systems Det grunnleggende konseptet bak denne typen system ligner på et glidende gjennomsnittssystem. Tanken er at når en ny høy eller lav er etablert, er prisbevegelsen mest sannsynlig å fortsette i retning av breakout. En indikator som kan brukes til å bestemme breakouts er et enkelt Bollinger Band overlegg. Bollinger Bands viser gjennomsnitt av høye og lave priser, og breakouts oppstår når prisen møter kantene på bandene. Her er et diagram som plots pris (blå linje) og Bollinger Bands (grå linjer) av Microsoft: Ulemper med Trend-Følgende systemer: Empirical Decision-Making Required - Ved bestemmelse av trender er det alltid et empirisk element å vurdere: Varigheten av den historiske trenden. For eksempel kan det bevegelige gjennomsnittet være de siste 20 dagene eller de siste fem årene, så utvikleren må bestemme hvilken som er best for systemet. Andre faktorer som skal bestemmes er de gjennomsnittlige høyder og nedturer i breakout-systemer. Lagging Nature - Flytte gjennomsnitt og breakout systemer vil alltid ligge. Med andre ord, de kan aldri slå den eksakte toppen eller bunnen av en trend. Dette resulterer uunngåelig i en fortabelse av potensiell fortjeneste, noe som noen ganger kan være betydelig. Whipsaw Effect - Blant markedskreftene som er skadelige for suksessen til trend-følgende systemer, er dette en av de vanligste. Whipsaw-effekten oppstår når det bevegelige gjennomsnittet genererer et falsk signal - det vil si når gjennomsnittet faller like i området, så reverserer plutselig retningen. Dette kan føre til store tap, med mindre effektive stopp-tap og risikostyringsteknikker er ansatt. Sideways Markets - Trend-følgende systemer er, av natur, i stand til å tjene penger bare i markeder som faktisk gjør trend. Men markeder flytter også sidelengs. holde seg innenfor et visst område for en lengre periode. Ekstrem volatilitet kan forekomme - Noen ganger kan trend-følgende systemer oppleve ekstrem volatilitet, men handelsmannen må holde seg til sitt system. Manglende evne til å gjøre det vil resultere i sikret fiasko. Countertrend Systems I utgangspunktet er målet med countertrend-systemet å kjøpe på laveste laveste og selge på høyeste høyde. Hovedforskjellen mellom dette og trend-etter-systemet er at motstrømsystemet ikke er selvkorrigerende. Med andre ord er det ikke satt tid for å gå ut av posisjoner, og dette resulterer i et ubegrenset ulemper potensial. Typer Countertrend Systems Mange forskjellige typer systemer betraktes som countertrend-systemer. Ideen her er å kjøpe når momentum i en retning begynner å falme. Dette beregnes oftest ved hjelp av oscillatorer. For eksempel kan et signal genereres når stokastikk eller andre relative styrkeindikatorer faller under bestemte punkter. Det finnes andre typer motstridshandelssystemer, men alle deler samme grunnleggende mål - å kjøpe lavt og selge høyt. Ulemper ved å motvirke følgende systemer: E mpirisk beslutningsprosess påkrevd - For eksempel er en av faktorene som systemutvikleren må bestemme seg for, hvilke punkter som relativstyrkeindikatorene taper. Ekstern volatilitet kan forekomme - Disse systemene kan også oppleve ekstrem volatilitet, og en manglende evne til å holde fast i systemet til tross for denne volatiliteten, vil resultere i sikret feil. Ubegrenset ulemper - Som tidligere nevnt er det ubegrenset ulemper, fordi systemet ikke er selvkorrigerende (det er ingen angitt tid for å gå ut av posisjoner). Konklusjon Hovedmarkedene som handelssystemer egner seg for, er aksje-, valuta - og futuresmarkedet. Hvert av disse markedene har sine fordeler og ulemper. De to viktigste sjangrene av handelssystemer er trend-follow og countertrend-systemene. Til tross for forskjellene deres krever begge typer systemer, i deres utviklingsstadier, empirisk beslutningsprosesser fra utviklerens side. Også disse systemene er utsatt for ekstrem volatilitet, og dette kan kreve noe utholdenhet - det er viktig at systemhandleren holder fast i systemet hans i disse tider. I den følgende avdelingen, ta en nærmere titt på hvordan du designer et handelssystem og diskutere noe av programvaren som systemhandlere bruker for å gjøre livet enklere. Trading Systems: Design ditt system - Del 2