Bond Trading System Arkitektur

Handelssystem Vad är ett handelssystem. Ett handelssystem är helt enkelt en grupp specifika regler eller parametrar som bestämmer inmatnings - och utgångspunkter för en given egenkapacitet. Dessa punkter, så kallade signaler, markeras ofta på ett diagram i realtid och snabb den omedelbara utförandet av en handel. Här är några av de vanligaste tekniska analysverktygen som används för att konstruera parametrarna för handelssystem. Medelvärdena MA. Relativ styrka. Bollinger Bands. Often, två eller flera av dessa indikatorer kommer att kombineras i Skapandet av en regel Till exempel använder MA crossover systemet två glidande medelparametrar på lång sikt och på kort sikt för att skapa en regelköp när kortsiktiga kors över lång sikt och säljer när motsatsen är Sant I andra fall använder en regel endast en indikator Till exempel kan ett system ha en regel som förbjuder köp, såvida inte den relativa styrkan överstiger en viss nivå Men det är en kombination av alla dessa typer av regler som gör ett handelssystem. MSFT Flyttande medelvärdeöverföringssystem med 5 och 20 rörliga medelvärden. Eftersom framgången för det övergripande systemet beror på hur väl reglerna utförs spenderar systemhandlare tidoptimering för att hantera riskerna öka det belopp som uppnåtts per handel och uppnå långsiktig stabilitet Detta görs genom att ändra olika parametrar inom varje regel. För att optimera MA crossover-systemet skulle en näringsidkare testa för att se vilka glidande medelvärden som 10 dagar, 30 dagar osv fungerar bäst och sedan implementera dem. Men optimering kan förbättra resultaten Med endast en liten marginal - det är kombinationen av parametrar som används som i slutändan kommer att bestämma framgången för ett system. Advantager Så, varför kanske du vill anta ett handelssystem. Det tar alla känslor ur handel - Emotion är ofta citerat som en Av de enskilda investerarnas största brister Investerare som inte klarar av förluster andra gissar sina beslut och slutar att förlora pengar Genom att strikt följa ett förutvecklat system kan systemhandlare avstå från behovet Att fatta beslut när systemet är utvecklat och etablerat, handel är inte empirisk eftersom den är automatiserad. Genom att minska mänskliga ineffektiviteter kan systemhandlare öka vinsten. Det kan spara mycket tid. När ett effektivt system har utvecklats och optimerats lite för att ingen ansträngning krävs av näringsidkaren Datorer används ofta för att automatisera inte bara signalgenerationen utan även den faktiska handeln, så att näringsidkaren befrias från att spendera tid på analys och göra affärer. Det är enkelt om du låter andra göra det för Du - Behöver allt arbete för dig Vissa företag säljer handelssystem som de har utvecklat Andra företag kommer att ge dig de signaler som genereras av sina interna handelssystem för en månadsavgift Var försiktig, men - många av dessa företag är bedrägliga Ta en nära Titta på när resultaten de pratar om var tagna. Det är lätt att vinna tidigare. Leta efter företag som erbjuder en rättegång som låter dig testa systemet i realtid. Nackdelar Vi har tittat på de främsta fördelarna med att arbeta med ett handelssystem, men tillvägagångssättet har också dess nackdelar. Tradersystem är komplexa - det här är deras största nackdel. I utvecklingsstadierna kräver handelssystemen en solid förståelse av teknisk analys, förmågan att göra empiriska beslut och en grundlig kunskap om hur parametrar fungerar Men även om du inte utvecklar ditt eget handelssystem är det viktigt att känna till de parametrar som utgör det du använder. Att förvärva alla dessa färdigheter kan vara en utmaning. Du måste kunna göra realistiska antaganden och använda systemet effektivt. Systemhandlare måste göra realistiska antaganden om transaktionskostnader. Dessa kommer att bestå av mer än provisionskostnader. Skillnaden mellan genomförandepriset och påfyllningspriset är en del av transaktionskostnaderna Bear in Det är ofta omöjligt att testa systemen noggrant, vilket medför en viss osäkerhet när systemet lever. Problem som uppstår när Simulerade resultat skiljer sig mycket från det faktiska resultatet kallas slippa Effektivt att hantera slippa kan vara ett viktigt vägspärr för att implementera ett framgångsrikt system. Utveckling kan vara en tidskrävande uppgift - Mycket tid kan gå in i att utveckla ett handelssystem för att få det att springa och fungera på rätt sätt Att avgöra ett systemkoncept och genomföra det i praktiken innebär gott om provning, vilket tar ett tag Historisk backtesting tar några minuter men det är inte tillräckligt med backtestning. System måste också handlas i realtid för att säkerställa tillförlitligheten äntligen kan slippa göra det möjligt för handlare att göra flera ändringar av sina system även efter installationen. De arbetar Det finns ett antal internet-bedrägerier i samband med systemhandel, men det finns också många legitima, framgångsrika system. Kanske är det mest kända exemplet det som utvecklats och implementerats av Richard Dennis och Bill Eckhardt, som är Original Turtle Traders 1983, hade dessa två tvivel om huruvida en bra t Rader är född eller skapad Så tog de några människor utanför gatan och utbildade dem baserat på deras nu kända Turtle Trading System De samlade 13 handlare och slutade göra 80 årligen de närmaste fyra åren Bill Eckhardt sa en gång, vem som helst med genomsnittlig intelligens kan lära sig att handla Detta är inte raketvetenskap Men det är mycket lättare att lära sig vad du ska göra i handel än att göra det Handelssystemen blir alltmer populära bland professionella handlare, fondförvaltare och enskilda investerare - kanske är detta en testamente för hur bra de jobbar. Att ta hand om bedrägerier När man vill köpa ett handelssystem kan det vara svårt att hitta ett pålitligt företag Men de flesta bedrägerier kan ses med sunt förnuft. Till exempel är en garanti på 2500 årligen klart upprörande som den lovar Att med bara 5000 kunde du göra 125 000 på ett år och sedan genom att sammansätta i fem år, 48 828 125 000 Om det var sant, skulle inte skaparen handla sin väg att bli bi Lionaire. Andra erbjudanden är dock svårare att avkoda, men ett vanligt sätt att undvika bedrägerier är att söka efter system som erbjuder en gratis provning. Således kan du testa systemet själv. Blind aldrig lita på att verksamheten skryter om. Det är också en bra idé att kontakta andra som har använt systemet för att se om de kan bekräfta sin tillförlitlighet och lönsamhet. Slutsats Att utveckla ett effektivt handelssystem är inte på något sätt en lätt uppgift. Det kräver en god förståelse av de många tillgängliga parametrarna, förmågan att göra Realistiska antaganden och tid och dedikation att utveckla systemet Men om det utvecklas och distribueras på rätt sätt kan ett handelssystem ge många fördelar. Det kan öka effektiviteten, ledig tid och, viktigast av allt, öka din vinst. Trafiksystem Designa ditt system - Del 1.En föregående del av denna handledning tittade på de element som utgör ett handelssystem och diskuterade fördelarna och nackdelarna med att använda ett sådant system i en live tr Ademmiljö I det här avsnittet bygger vi vidare på den kunskapen genom att undersöka vilka marknader som är särskilt lämpade för systemhandel. Vi tar då en djupare titt på de olika genren av handelssystem. Försäljning i olika marknader. Marknaden är förmodligen den vanligaste marknaden för handel, särskilt bland nybörjare. På den här arenan dominerar stora aktörer som Warren Buffett och Merrill Lynch, och traditionella värde - och tillväxtinvesteringsstrategier är överlägset vanligaste. Dock har många institutioner investerat betydligt i design, utveckling och genomförande av handelssystem Individuella investerare går med i denna trend, men långsamt. Det är några viktiga faktorer att komma ihåg när man använder handelssystem på aktiemarknaderna. Det stora antalet tillgängliga aktier gör det möjligt för handlare att testa system på många olika sätt Typer av aktier - allt från extremt flyktiga OTC-lager till icke-flyktiga blue chips. Effektiviteten hos Handelssystem kan begränsas av vissa aktiers låga likviditet, särskilt OTC och pink sheet-emissioner kan äta i vinster genererade av framgångsrika affärer och kan öka förluster OTC och rosa arkaktier uppstår ofta extra provisionsavgifter. De viktigaste handelssystemen som används är de Som söker värde - det vill säga system som använder olika parametrar för att avgöra huruvida en säkerhet är undervärderad jämfört med tidigare prestanda, dess kamrater eller marknaden i allmänhet. Forex Exchange Markets Valutamarknaden eller forex är den största och mest Världens likvida marknad Världens regeringar, banker och andra stora institutioner handlar biljoner dollar på valutamarknaden varje dag Flertalet institutionella handlare på valutan är beroende av handelssystemen Detsamma gäller för individer i valutan, men vissa handelsbaserade På ekonomiska rapporter eller ränteutbetalningar. Här är några viktiga faktorer att komma ihåg när man använder handelssystem på valutamarknaden. Likviditeten i På grund av den stora volymen gör handelssystemen mer exakta och effektiva. Det finns inga provisioner på den här marknaden. Det sprider sig därför. Därför är det mycket lättare att göra många transaktioner utan att öka kostnadsbesparingarna till antalet aktier eller råvaror som finns tillgängliga, Antalet valutor att handla är begränsat Men på grund av tillgången på exotiska valutapar - det vill säga valutor från mindre länder - är volatilitetsintervallet inte nödvändigtvis begränsat. De viktigaste handelssystemen som används i forex är de som följer trenderna a Populärt säga på marknaden är trenden är din vän eller system som köper eller säljer på breakouts Detta beror på att ekonomiska indikatorer ofta orsakar stora prisrörelser på en gång. Futures Equity, Forex och råvarumarknader erbjuder alla futures trading Detta är en populär Fordon för systemhandel på grund av den ökade mängden hävstång som finns och ökad likviditet och volatilitet. Dessa faktorer kan dock skära båda sätten de ca N antingen förstärka dina vinster eller förstärka dina förluster Av denna anledning är användningen av terminer vanligtvis reserverad för avancerade enskilda och institutionella systemhandlare. Det beror på att handelssystem som kan kapitalisera på terminsmarknaden kräver mycket större anpassning, använder mer avancerade indikatorer och tar Mycket längre att utveckla Så, vilket är bäst Det är upp till den enskilda investeraren att bestämma vilken marknad som bäst passar till systemhandeln - var och en har sina egna fördelar och nackdelar. De flesta människor är mer bekanta med aktiemarknaderna och denna förtrogenhet gör att man utvecklar en Handelssystem lättare Forex anses emellertid vara den överlägsen plattformen för att driva handelssystem - särskilt bland mer erfarna handlare. Om en näringsidkare bestämmer sig för att kapitalisera på ökad hävstångseffekt och volatilitet är terminsalternativet alltid öppet. Slutligen ligger valet i Händerna på systemutvecklaren. Typ av handelssystem. Trend-Följande system Den vanligaste metoden Av systemhandel är trend-efterföljande system I sin mest grundläggande form väntar detta system helt enkelt på en betydande prisrörelse, köper eller säljer i den riktningen. Denna typ av system bankar på hopp om att dessa prisrörelser kommer att behålla trenden. Genomsnittliga system Används oftast i teknisk analys är ett rörligt medelvärde en indikator som helt enkelt visar genomsnittspriset på ett lager över en tidsperiod. Trendens väsentlighet härrör från denna mätning. Den vanligaste sätten att bestämma inmatning och utträde är en crossover. Den logiska bakom detta är enkelt en ny trend upprättas när priset sjunker över eller under dess historiska prisgenomsnittstrenden Här är ett diagram som pryder både prisblå linjen och den 20-dagars MA röda raden av IBM. Breakout Systems Det grundläggande konceptet bakom denna typ av systemet liknar det för ett glidande medelvärde. Tanken är att när en ny hög eller låg är etablerad, är prisrörelsen sannolikt att fortsätta i bromsriktningen Eakout En indikator som kan användas vid bestämning av breakouts är ett enkelt Bollinger Band-överlag Bollinger Bands visar medelvärden av höga och låga priser och breakouts uppstår när priset möter kanterna på banden. Här är ett diagram som prissätter pris blå linje och Bollinger Bands grå Linjer av Microsoft. Nackdelar med Trend-Följande Systems. Empirical Decision-Making Required - Vid bestämning av trender finns det alltid ett empiriskt element för att överväga varaktigheten av den historiska trenden. Till exempel kan det glidande genomsnittet vara de senaste 20 dagarna eller för Under de senaste fem åren måste utvecklaren bestämma vilken som är bäst för systemet. Andra faktorer som ska bestämmas är de genomsnittliga höjderna och nedgångarna i brytningssystemen. Lagring av naturen - Flyttande medelvärden och brytningssystem kommer alltid att vara långa. Med andra ord kan de aldrig träffa exakt toppen eller botten av en trend Detta leder oundvikligen till förverkande av potentiella vinster, vilket ibland kan vara betydande. Växelverkan - Bland marknaden Krafter som skadar framgången för trend-efterföljande system, är detta en av de vanligaste. Whipsaw-effekten uppstår när det rörliga genomsnittsvärdet genererar en falsk signal - det vill säga när medeltalet faller precis i intervallet, så vänder det plötsligt riktning leda till enorma förluster om inte effektiva stoppförluster och riskhanteringstekniker används. Svenskt marknader - Trend-efter-system är av naturen kuna att tjäna pengar endast på marknader som faktiskt tränar. Men marknaderna rör sig också sidledes inom ett visst område Under en längre tidsperiod. Extreme Volatility May Occur - Ibland kan trend-efterföljande system uppleva viss extrem volatilitet, men näringsidkaren måste hålla sig till sitt system. Oförmågan att göra det kommer att resultera i ett försäkrat misslyckande. Countertrend Systems I grund och botten målet med motströmsystemet är att köpa på lägst lågt och sälja högst högt. Huvudskillnaden mellan detta och det efterföljande systemet är att co Untertrend-systemet är inte självkorrigerande Med andra ord är det ingen bestämd tid att avsluta positioner och detta leder till obegränsad nackdel. Typ av motströmsystem Många olika typer av system betraktas som motströmsystem. Tanken här är att köpa när momentum i En riktning börjar blekna Detta beräknas oftast med hjälp av oscillatorer Exempelvis kan en signal genereras när stokastik eller andra relativa styrindikatorer faller under vissa punkter. Det finns andra typer av motsträngshandeln, men alla delar samma grundläggande mål - att Köpa låga och sälja höga. Nackdelar med Countertrend Following Systems. E mpirisk beslutsfattande krävs - Till exempel, en av de faktorer som systemutvecklaren måste bestämma är punkterna där relativa styrindikatorer svävar. Extreme Volatility May Occur - Dessa system kan också uppleva viss extrem volatilitet och en oförmåga att hålla fast vid systemet trots att denna volatilitet kommer att resultera i Försäkrat misslyckande. Otillräcklig nackdel - Som tidigare nämnts finns det obegränsad nackdel, eftersom systemet inte är självkorrigerande. Det finns ingen bestämd tid för att avsluta positioner. Konklusion De viktigaste marknaderna för vilka handelssystem är lämpliga är aktie-, valutamarknaden och terminsmarknaden Var och en av dessa marknader har sina fördelar och nackdelar. De två huvudgenren av handelssystem är trend-följande och motverkningssystemen. Trots skillnaderna kräver båda typerna av system i utvecklingsstadierna empirisk beslutsfattande från utvecklarens sida. , dessa system är föremål för extrem volatilitet och det kan kräva en del uthållighet - det är viktigt att systemhandlaren håller fast vid sitt system under dessa tider. I följande avdelning kommer vi att titta närmare på hur man utformar ett handelssystem och Diskutera en del av programvaran som systemhandlare använder för att göra deras liv enklare. Uppmätta mönster Integrationsmönster i praktiken Fallstudie Bon D Trading System. Av Jonathan Simon. Det är lätt att avstå från en stor samling av mönster eller ett mönsterspråk Mönster är abstraktionen av en idé i en återanvändbar form Ofta gör den mycket generiska karaktären hos mönster som gör dem så användbara gör dem svårt att förstå Ibland är det bästa för att förstå mönster ett verkligt världsexempel. Inte ett konstruerat scenario för vad som kan hända, men vad som faktiskt händer och vad som händer. Detta kapitel gäller mönster för att lösa problem med en upptäcktsprocess. Systemet vi kommer att diskutera är en obligationshandel System som jag arbetade med i två år från inledande design genom produktion Vi kommer att undersöka scenarier och problem som uppstod och hur man löser dem med mönster. Det innebär beslutsprocessen att välja ett mönster, samt hur man kombinerar och anpassar mönster som passar Systemets behov Och det här är allt gjort med hänsyn till krafterna i reala system, inklusive företagskrav, kundbeslut, ar chitekturala och tekniska krav samt äldre systemintegration. Syftet med detta tillvägagångssätt är att ge en tydligare förståelse av mönstren själva genom praktisk tillämpning. Bygga ett system. En stor Wall Street investeringsbank fastställer att bygga ett obligationsprissättningssystem i en Ansträngningar att effektivisera arbetsflödet på deras obligationshandelskort För närvarande måste obligationshandlare skicka priser för ett stort antal obligationer till flera olika handelsplatser, var och en med sitt eget användargränssnitt. Syftet med systemet är att minimera minutiae av prissättning av alla Deras obligationer kombinerat med avancerad analytisk funktionalitet som är specifik för obligationsmarknaden i ett enda inkapslat användargränssnitt. Detta innebär integration och kommunikation med flera komponenter över olika kommunikationsprotokoll. Systemets höga nivå ser ut som detta. Först kommer marknadsdata i systemet Marknaden data är uppgifter om pris och andra egenskaper hos obligationen som representerar vad människor är willin G att köpa och sälja obligationen på den fria marknaden Marknadsdata skickas omedelbart till analysmotorn som ändrar data Analytics avser matematiska funktioner för finansiella applikationer som ändrar priser och andra attribut av obligationer Dessa är generiska funktioner som använder inmatning Variabler för att skräddarsy resultaten av funktionen till ett visst bindning Klientapplikationen som kommer att köras på varje traderbordsskrivare konfigurerar analysmotorn på en näringsidkarbas, kontrollerar analysens specifika för varje obligation som näringsidkaren prissätter. När analyserna är Tillämpas på marknadsdata, skickas de modifierade uppgifterna till olika handelsplatser där handlare från andra företag kan köpa eller sälja obligationerna. Arkitektur med mönster. Med denna översikt över systemets arbetsflöde kan vi närma oss några av de arkitektoniska problemen Vi möter under designprocessen Låt oss ta en titt på vad vi vet hittills Traders behöver ett mycket lyhörd program på både Windows NT en D Solaris-arbetsstationer Därför bestämde vi oss för att implementera klientapplikationen som en Java-tjock klient på grund av dess plattformsoberoende och dess förmåga att snabbt svara på användarinmatning och marknadsdata. På serverns sida förvärvar vi äldre C-komponenter som vårt system kommer att utnyttja Marknadsdatakomponenterna kommunicerar med TIBCO Information Bus TIB Messaging Infrastructure. We ärverger följande komponenter. Marknadsdataprismatningsserver publicerar inkommande marknadsdata till TIB. Analytics Engine Utför analys på inkommande marknadsdata och sänder ändrade marknadsdata till TIB. Contribution Server Utför all kommunikation med handelsplatserna. Handelsplatserna är komponenter från tredje part som inte kontrolleras av banken. Data för subsystem för legitimitetsdata. Subsystem för legitimitetsbidrag. Vi måste bestämma hur separata delsystemen Java tjock klient, marknadsdata och bidrag är Kommunicerar Vi kan få den tjocka klienten att kommunicera direkt med le Gacy-servrar men det skulle kräva för mycket affärslogik på klienten i stället ska vi bygga ett par Java-gateways för att kommunicera med de gamla servrarna Prissättning Gateway för marknadsdata En Bidrags Gateway för att skicka priser till handelsplatser Detta kommer att uppnå en bra inkapsling Av affärslogiken relaterad till dessa områden De nuvarande komponenterna i systemet visas nedan. Anslutningarna markerade som indikerar att vi fortfarande är osäkra på hur några av komponenterna kommer att kommunicera. Systemet och dess komponenter. Den första kommunikationsfrågan är hur man integrerar Java-tjock klient och de två Java-serverkomponenterna för att utbyta data Låt oss titta på de fyra integrationsstilarna som föreslås i denna bok. Filöverföring Delad databas Fjärrprocedur Inbjudningar och meddelanden Vi kan utesluta delad databas omedelbart eftersom vi ville skapa ett lager av abstraktion mellan klienten och databasen och inte vill ha databasåtkomstkod i klienten File Transfe R kan på samma sätt uteslutas eftersom minimal latens krävs för att säkerställa att nuvarande priser skickas ut till handelsplatserna. Detta ger oss möjlighet att välja mellan Remote Procedure Invocation eller Messaging. Java-plattformen erbjuder inbyggt stöd för både Remote Procedure Invocation och Messaging Integration av RPC-stil kan uppnås med hjälp av fjärrmetodinventering RMI, CORBA eller Enterprise Java-bönor EJB Java Messaging-tjänsten JMS är det gemensamma API för meddelandeformatintegration Så båda integrationsstilarna är lätta att implementera i Java. Såsom kommer att fungera bättre För det här projektet, Remote Procedure Invocation eller Messaging There är endast en instans av prissättningsporten och en instans av Contribution Gateway i systemet, men vanligtvis många Thick Clients kopplar samtidigt till dessa tjänster en för varje obligationshandlare som råkar vara inloggad Vid en viss tidpunkt skulle banken vilja att detta är ett generellt prissystem som kan användas i andra applikationer förutom ett okänt antal Think Clients kan det finnas ett okänt antal andra applikationer som använder prisuppgifterna som kommer ut från Gateways. En tjock klient eller annan applikation som använder prissättningsdata kan ganska enkelt använda RPC för att ringa till Gateways för att få prissättning data och åberopa bearbetning Men prissättning data kommer ständigt att publiceras, och vissa kunder är bara intresserade av vissa uppgifter, så att få relevanta uppgifter till rätt kunder i tid kan vara svårt. Kunderna kunde granska Gateways, men det kommer att Skapa mycket överhuvudet Det skulle vara bättre för Gateways att göra data tillgängliga för kunderna så snart den är tillgänglig. Det kommer emellertid att kräva att varje Gateway ska hålla reda på vilka klienter som för närvarande är aktiva och vilka vill ha vilken viss data då, när en ny bit data blir tillgänglig som kommer att hända flera gånger per sekund, måste Gateway göra en RPC till varje intresserad klient för att skicka data till Clie nt Ideellt bör alla klienter meddelas samtidigt, så varje RPC måste göras i sin egen samtidiga tråd. Det kan fungera, men blir väldigt komplicerat mycket snabbt. Med hjälp av meddelanden kan vi definiera separata kanaler för olika typer Av prissättningsdata När en Gateway får en ny datauppsättning kommer den att lägga till ett meddelande som innehåller den dataen till Public-Subscribe-kanalen för den datatypen. Samtidigt lyssnar alla klienter som är intresserade av en viss typ av data på kanalen för den typen På så sätt kan Gateways enkelt skicka ut nya data till den som är intresserad, utan att behöva veta hur många lyssnarapplikationer det finns eller vad de är. Klienterna måste fortfarande kunna påverka beteenden i Gateways Det finns bara två Gateways, och klienten kan förmodligen blockera medan metoden är påkallad synkront. Dessa klient-till-Gateway-inbjudningar kan ganska enkelt implementeras med hjälp av RPC Men eftersom vi använder redan meddelanden för gateway-till-klientkommunikation. Meddelanden är förmodligen lika bra för att implementera klient-till-gateway-kommunikation också. Därför kommer all kommunikation mellan Gateways och klienterna att uppnås genom meddelandet eftersom alla komponenter skrivs i Java, JMS presenterar ett lätt val för som meddelandesystem Det här skapar effektivt en Message Bus eller en arkitektur som gör det möjligt för framtida system att integrera med det nuvarande systemet med få eller inga ändringar i meddelandets infrastruktur. Sättet kan programmets affärsfunktion enkelt användas av en annan applikation som banken utvecklar. Java-komponenter som kommunicerar med JMS. JMS är helt enkelt en specifikation och vi måste bestämma ett JMS-kompatibelt meddelandehanteringssystem. Vi bestämde oss för att använda IBM MQSeries JMS eftersom Banken är en IBM-butik, som använder WebSphere-applikationsservrar och många andra IBM-produkter. Som ett resultat kommer vi att använda MQSeries eftersom vi redan har Ave en stödinfrastruktur på plats och en webbplatslicens för produkten. Nästa fråga är hur man ansluter MQSeries messaging system med fristående C Contribution-servern och TIBCO-baserade marknadsdata och Analytics Engine servrar Vi behöver ett sätt för MQSeries konsumenter att Har tillgång till TIB-meddelanden Men hur kan vi kanske använda Message Translator-mönstret för att översätta TIB-meddelanden till MQSeries-meddelanden Även om C-klienten för MQSeries fungerar som Message Translator använder den att offra JMS-serverens oberoende Och även om TIBCO har ett Java API, kundarkitekten och chefen har avvisat det. Följaktligen måste Message Translator-tillvägagångssättet överges. Broen från TIB-servern till MQSeries-servern kräver kommunikation mellan C och Java. Vi kan använda CORBA, men hur är meddelandet A närmare titta på Message Translator-mönstret visar att den är relaterad till kanaladaptern i dess användning av kommunikationsprotokoll. En hjärtas hjärta Adapter är att ansluta icke-meddelandesystem till meddelandesystem Ett par kanaladaptrar som ansluter två meddelandesystem är en meddelandebro. Syftet med en meddelandebro är att överföra meddelanden från ett meddelandesystem till ett annat Detta är exakt vad vi gör med Den extra komplexiteten hos Java-C-kommunikationen mellan språken Vi kan implementera cross-language Messaging Bridge med hjälp av en kombination av Channel Adapter s och CORBA. Vi kommer att bygga två lättvikta kanaladapterservrar, en i C som hanterar kommunikation med TIB och en i Java hantera kommunikation med JMS Dessa två kanaladapter som är Message Endpoint s själva kommer att kommunicera med varandra via CORBA Liksom vårt val för MQSeries använder vi CORBA snarare än JNI eftersom det är en företagsstandard Meddelandebroen implementerar det effektivt simulerade meddelandet översättning mellan till synes inkompatibla meddelandesystem och olika språk. Message Translator med Channel Adapte r. Nästa diagram visar den aktuella systemdesignen inklusive Gateways och andra komponenter. Detta är ett bra exempel på mönsterapplikation Vi kombinerade två kanaladapter s med ett icke-meddelandeprotokoll för att implementera Message Translator-mönstret, effektivt med ett mönster för att implementera en annan Mönster Dessutom ändrade vi kanaladapterns sammanhang för att länka två meddelandesystem med ett icke-meddelande språköverföringsprotokoll i stället för att ansluta ett meddelandesystem till ett icke-meddelandesystem. Det nuvarande systemet med kanaladaptrarna. Strukturkanaler. En nyckel Att arbeta med mönster är inte bara att veta när man ska använda vilket mönster men också hur man effektivt använder det. Varje mönsterimplementering måste ta hänsyn till specifikationerna för teknologiplattformen liksom andra designkriterier. Det här avsnittet gäller samma funktionsprocess för att hitta Den mest effektiva användningen av Public-Subscribe-kanalen i samband med marknadsdataservern som kommunicerar med t Han analytics engine. Real tid marknadsdata härstammar med marknadsdata feed, en C-server som sänder marknadsdata på TIB Marknadsdata flödet använder en separat Public-Subscribe Channel för varje obligation det publicerar priser för. Det kan tyckas lite extrem eftersom varje nytt band behöver sin egen nya kanal Men det här är inte så allvarligt eftersom du inte behöver skapa kanaler i TIBCO. I stället hänvisas kanaler till en hierarkisk uppsättning ämnesnamn som heter ämnen. TIBCO-servern filtrerar sedan ett enda meddelandeflöde efter ämne , Skickar varje unikt ämne till en enda virtuell kanal. Resultatet är en mycket lätt meddelandekanal. Vi kan skapa ett system som publicerar på några kanaler och abonnenter kan bara lyssna på priser de är intresserade av. Detta skulle kräva att abonnenter använder en Meddelandefilter eller selektiv konsument för att filtrera hela dataflödet för intressanta obligationspriser, bestämma om varje meddelande ska behandlas som det mottas med tanke på att e-marknadsdata publiceras på obligatoriska kanaler. Abonnenter kan registrera sig för uppdateringar på en serie obligationer. Det gör det möjligt för abonnenter att filtrera genom att selektivt prenumerera på kanaler och endast få uppdateringar av intresse snarare än att bestämma efter att meddelandet har tagits emot. Det är viktigt att Notera att användningen av flera kanaler för att undvika filtrering är en icke-standardiserad användning av meddelandekanaler. I samband med TIBCO-tekniken bestämmer vi emellertid verkligen huruvida vi ska implementera eller äga filter eller använda kanalfiltrering som är inbyggd i TIBCO - istället för att använda så många Kanaler. Nästa komponent vi behöver designa är analysmotorn, en annan C TIB-server som kommer att ändra marknadsdata och vidarebefordra den till TIB. Även om den ligger utanför vår Java JMS-utveckling, arbetar vi nära med C Team för att designa det eftersom vi är den primära kunden för analyticsmotor. Problemet är att hitta den kanalstruktur som mest effektivt återuppbyggs T den nyligen modifierade marknadsdata. Since vi redan har en dedikerad Message Channel per bindning ärvt från marknadsdataprismatningen skulle det vara logiskt att modifiera marknadsdata och omfördela den modifierade marknadsdata på den obligatoriska meddelandekanalen, men det här kommer inte att Arbete eftersom analysen som ändrar obligationspriserna är näringsidkare specifika Om vi ​​omfördelade de modifierade uppgifterna på obligationsmeddelandekanalen kommer vi att förstöra dataintegriteten genom att ersätta generisk marknadsdata med specifika uppgifter för näringsidkare. Å andra sidan kan vi ha en annan meddelande typ för Näringsidkare specifika marknadsdata som vi publicerar på samma kanal, så att abonnenterna kan bestämma vilket meddelande de är intresserade av för att undvika att förstöra dataintegriteten. Men då måste klienterna implementera sina egna filter för att skilja ut meddelanden till andra handlare. Dessutom kommer det att bli en väsentlig ökning av meddelanden som mottagits av abonnenter, vilket innebär en onödig börda på dem. Det finns två alternativ. En kanal Per handlare Varje näringsidkare har en utsedd kanal för den modifierade marknadsdataen. På så sätt förblir den ursprungliga marknadsinformationen intakt och varje näringsansökan kan lyssna på sin specifika handelsförmedlare Meddelandekanal för de modifierade prisuppdateringarna. En kanal per näringsidkare per obligation Skapa en meddelandekanal Per-näringsidkare per bindning uteslutande för den modifierade marknadsdata för det obligationen. Exempelvis kommer marknadsdata för obligationen ABC att publiceras på kanalen Bond ABC medan den modifierade marknadsdata för näringsidkare A skulle publiceras på Message Channel Trader A, Bond ABC , Modifierad marknadsinformation för näringsidkare B på Trader B, Bond ABC och så vidare. En kanal per näringsidkare. En kanal per obligation per näringsidkare. Det finns fördelar och nackdelar för varje tillvägagångssätt. Mer Meddelandekanal I värsta fallet kommer antalet meddelandekanaler att vara antalet obligationer totalt multiplicerat med antalet handlare. Vi kan sätta gränser för antalet kanaler som kommer att skapas sedan Vi vet att det bara finns cirka 20 handlare och de prissätter aldrig mer än ett par hundra obligationer. Det sätter den övre gränsen under 10 000-serien, vilket inte är så outlandish jämfört med den nästan 100 000 meddelandekanalen som marknadsdataprismatningen använder också. eftersom vi använder TIB och Message Channel är ganska billiga, är antalet meddelandekanal s inte en allvarlig fråga. Å andra sidan kan det stora antalet Message Channel s vara ett problem ur ett ledningsperspektiv Varje gång ett bindning läggs till en kanal för varje näringsidkare måste bibehållas Detta kan vara svårt i ett mycket dynamiskt system Vårt system är dock väsentligen statiskt. Det har också en infrastruktur för att automatiskt hantera Message Channel s. Detta kombineras med den arvade arkitekturen hos en äldre komponent med en liknande metod Minimerar nackdelen Det här är inte att säga att vi ska göra ett onödigt stort antal meddelandekanaler. Snarare kan vi implementera en arkitektonisk metod som använder en stort antal meddelandekanaler s när det finns en anledning. Och det finns en anledning i det här fallet som kommer ner till logikens läge. Om vi ​​implementerar per näringsidkarbeteende behöver Analytics Engine logik för att gruppera inmatnings - och utmatningskanaler. Detta beror på att Inmatningskanalerna från Analytics-motorn är per bindning och utmatningskommunikationskanalen s skulle vara per näringsidkare och kräver att Analytics-motorn strömmar all analysinsignal från flera obligationer för en viss näringsidkare till en näringsidkars specifika utmatningskommunikationskanal In i en innehållsbaserad router för att implementera anpassad routinglogik för vår application. Following Message Bus-strukturen är Analytics Engine en generisk server som kan användas av flera andra system i det så vi vill inte molna det med systemspecifik funktionalitet Å andra sidan fungerar per-bindningsinriktningen eftersom idén om en näringsidkare som äger analyspappersproduktionen av obligationspriser är ett företags accepterat övning. Per-bond a Pproach håller meddelandekanalseparationen av marknadens dataflöde intakt medan du lägger till flera fler meddelandekanaler s Innan vi når kunden vill vi ha en innehållsbaserad router för att kombinera dessa flera kanaler till ett hanterbart antal kanaler Vi vill inte ha klienten Applikation som körs på näringsidkarens skrivbord för att lyssna på tusentals eller tiotusentals meddelandekanal s Nu blir frågan var man ska sätta innehållsbaserad router Vi kan helt enkelt få C TIB-kanaladapteren att vidarebefordra alla meddelanden till prissättningspanelen På en enda meddelandekanal Det här är dåligt av två anledningar att vi skulle dela upp affärslogiken mellan C och Java och vi skulle förlora fördelen med den separata meddelandekanal s på TIB-sidan, så att vi kan undvika att filtrera senare i dataflödet Om vi ​​tittar på våra Java-komponenter kan vi antingen placera den i prissättningspartén eller skapa en mellanliggande komponent mellan prissättningspartiet och klienten. I teorin om vi fortsatte bindningen Baserad separering av Message Channel s hela vägen till klienten, skulle prissättningsporten återupplösta prisinformation med samma kanalstruktur som Pricing Gateway och Analytics Engine. Detta innebär en duplicering av alla obligatoriska TIB-kanaler i JMS. Även om vi Skapa en mellanliggande komponent mellan prissättningsgatewayen och klienten, måste prissättningsporten fortfarande duplicera alla kanaler i JMS. Å andra sidan tillåter implementering av logik direkt i prissättningsportalen oss att undvika att duplicera det stora antalet kanaler i JMS Tillåter oss att skapa ett mycket mindre antal kanaler i storleksordningen av en per näringsidkare Prissättningsporten registrerar sig via C TIB-kanaladaptern som konsument för varje obligation för varje näringsidkare i systemet. Då kommer prissättningsporten endast att vidarebefordra varje specifik klient Meddelandena relaterade till den specifika näringsidkaren På så sätt använder vi endast ett litet antal meddelandekanal s på JMS-änden, samtidigt som vi maximerar benen efit av separationen på TIB-änden. Den fullständiga marknadsdataflödet till klienten. Diskussionen om meddelandekanalens layout är ett bra exempel på hur integrering av mönster är viktigt. Målet var att se hur man effektivt använder meddelandekanalen s. Använd ett mönster är inte tillräckligt Du måste räkna ut hur du bäst kan genomföra det och införliva i ditt system för att lösa problemen på sidan Dessutom visar detta exempel företagskrafter i handling Om vi ​​kunde genomföra affärslogik i någon av våra komponenter kunde vi 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 av ailable 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 Pri ce 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 ca che 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 milliseco nds 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 mil liseconds 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 t hat 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 continu ously 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 mo re 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 guarantee s 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 refac toring 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. Want to keep up-to-date Follow My Blog. Want to read more in depth Check out My Articles. Want to s ee 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 Integration Patterns in Practice Case Study Bond Trading System.