Kø-øvelse
Her er en lille, aktuel og konkret øvelse fra min hverdag. Forestil dig at du skal lave en arkitektur for anskaffelse og integration af en fem-seks forskellige produktionssystemer over de næste par år. Hvert system skal løbende rapportere transaktions-data til ét fælles datavarehus. Disse transaktions-data skal leveres på under et sekund og med leverance-garanti, helst i en garanteret rækkefølge. Både datavarehus og hvert produktionssystem skal kunne have service-vinduer eller mindre udfald uden at skulle ind i en større catch-up eller udrednings-proces af den grund. Utilgængelighed af datavarehuset må ikke bremse det enkelte produktionssystem lige som manglende data fra produktionssystemet må bremse datavarehuset. Produktionssystemerne og datavarehuset skal med andre ord være afkoblede.
Asynkron kommunikation er svaret på kravet om afkobling, men det er ikke helt nok. Filflytning af forskellig art som fx FTP er svær at gøre hurtigt nok og mit gæt er, at der skal kodes og testes en del for at sikre robusthed i løsningen når begge parter kan risikere at være utilgængelige på forskellige tidspunkter. Når vi smider garanti for leverance med i kurven af krav, er en kø-mekanisme med persistens oplagt som løsning.
Men hvilket kø-produkt skal anvendes til formålet?
Her har du brug for følgende ekstra information: Formålet er at gøre arkitekturen parat til at servicere de forretningsmæssigt bedste produktionssystemer på markedet inden for hver deres område. Du har derfor ikke løst din opgave hvis du kræver, at systemerne bygger på fx. Java da du ad den vej risikerer at diskvalificerer de i øvrigt bedste løsninger derude. Da hvert system vedligeholdes af leverandørerne og bliver hostet forskellige steder ude i byen har du i øvrigt heller ikke specielle interesser i at stille krav til teknologien bag produktionssystemerne. Forudsat at prisen ikke bliver mange hundredetusinder, vil det bedste snarere end det billigste integrationsprodukt være at foretrække.
Mit eget bud er IBM Websphere MQ – det er i hvert fald et ret solidt produkt som er tilgængeligt på flere platforme. Hvilke andre produkter derude kan løfte opgaven?
Om Peter NørregaardPeter Nørregaard er principal consultant hos PA Consulting Group. Peter blogger om koblingen mellem strategi, forretnings- og it-arkitektur og om hvordan it påvirker samfundet
Follow @peternorregaardKommentarer (22)
Netscaler VPX - hvis du ikke skal have SSL offloading. En virtuel appliance fra citrix. Bliver brugt af alle større sites.
Den kan alt det du ønsker, men koster også penge.
Byg din applikation gennem noget HTTP baseret, så er det ret lige til.
-
0 -
0
Ville nok være mit første bud: http://www.rabbitmq.com/ – det er open source og der er et veritabelt hav af implementationer til forskellige platforme og programmeringssprog.
-
0
-
0
Der findes flere open source MQ projekter, som er enterprise grade, og som ikke koster en formue, og en gigantisk IBM server, for at komme i gang.
RabbitMQ er en af dem.
Øvrige jeg kan huske:
ActiveMQ
HornetQ
Fuse Message Broker (ActiveMQ baseret afair)
-
0
-
0
Tak for input - hvilke erfaringer har I selv fra et enterprise-miljø med RabbitMQ, Netscaler eller fx HornetQ?
-
0
-
0
Jeg er blevet stærkt betaget af ZeroMQ (http://www.zeromq.org/), der udmærker sig ved at være brokerless. Desværre har jeg ikke rigtigt har noget projekt her på de sidste der var oplagt til kø-brug, så jeg venter stadig på at få praktiske erfaringer med det...
Systemet er efter sigende udviklet til finanskvarteret i London....
-
0
-
0
Endnu en AMQP-implementation er Red Hat's MRG, hvortil man må forvente at kunne få 24/7 support. Nej, jeg har ikke erfaringer.
-
0
-
0
RabbitMQ fungerer fint og vi anvender det som grundlag for et 23x6 handelssystem der håndterer værdier til 500 mia DKK. Fra et administrator perspektiv har RabbitMQ det problem at produktet udvikler sig meget hurtigt og hver måned bringer en ny version. Det er ikke alle versioner som er lige stabile så vi skal bruge en del tid på at teste og lave life-cycle management. Tilgengæld elsker udviklerne RabbitMQ :-)
Jeg har også tilbragt et par år med IBM MQ og her er situationen modsat.
Produktet udvikler sig langsomt, er meget stabilt men både udviklerne og administratorne hader det hvis ikke de har en baggrund i mainframeverdenen.
Til et nyt projekt uden bindinger til allerede anskaffet infrastructur vil jeg aldrig anbefale IBM MQ
-
0
-
0
Jeg har skimmet ZeroMQ og det lader til at være relativt low-level og min bekymring er, at der skal en del til at få en fiks og færdig service med de krævede kvaliteter ud af det. Er du enig i det, Svenne?
Praktiske erfaringer, høj modning og ikke mindst stærk support 24/7 er et krav til kø-teknologi, der er brug for her.
-
0
-
0
Det lyder godt og prisen er ikke afskrækkende selvom løbende afregning jo løber op ved intensiv brug 24/7 over 3-5 år. Jeg har dog tre reservationer med Amazon SQS:
1) Et ekstra hosting-led i kæden: Aftalemæssigt skal det være klokkeklart hvem, der har ansvaret for at beskeder når frem til kø-modtageren i tide og der skal være et incitament for at holde service-niveauet oppe, gerne med bod. Med en 3.part i ligningen bliver det sværere at placere ansvaret præcist.
2) Service-level. Amazon giver ingen garantier på service-levels, herunder svartider, tilgængelighed eller afhjælpning. En god tommelfinger-regel er i øvrigt, at der skal være et ligeværdigt forhold mellem leverandør og kunde - her er Amazon alt for stor og alt for uforpligtet. Et nedbrud på fx et døgn på en infrastruktur-komponent er uacceptabel og indkøberen af løsningen betaler gerne en præmie for en garanti for service-level, men det tilbyder Amazon ikke.
3) Polling! Datavarehuset skal polle efter nye beskeder, da det ikke bliver notificeret automatisk. Så kunne vi næsten lige så godt bruge webservices direkte mod produktionssystemerne. En overførselstid på under ét sekund bliver svært når man skal polle en 3.parts service.
Amazon SQS er god når man i forvejen er på EC2, men som ren back-end til back-end integration mellem systemer som ikke bor i EC2 synes jeg der er nogle issues.
-
0
-
0
@Claus, stabilitet er naturligvis vigtig - specielt hvis to (eller flere) aftaleparter skal opdatere versioner samtidigt før at de kan tale sammen. Men det kan man vel organisere sig ud af ved at køre på en ældre, men stabil release (det er jo ikke rocket-science, vi er ude efter, men driftsikker performance)
Er din implementering af RabbitMQ en intern kø-infrastruktur eller går den også på tværs af systemer/hosting-miljøer/parter (og dermed også kontrakter...)?
-
0
-
0
Jeg har selv introduceret redis[1] for at løse en ligende opgave.
Egentligt en udspringer af NoSQL bevægelsen. Bemærk dog at redis garantere kun konsistens hvis den kun bliver afsluttet gracefull (Hvilket i mine øjne gælder for alle database produkter) - man her har man valgt det som en del af arkitekturen, performance at sat højt.
Redis giver også en del andre features for distribueret set af data osv. For mig blev det en kærligheds historie.
DISCLAIMER: Har ikke selv set efter kommercielt support.
[1] http://redis.io/
-
0
-
0
Som jeg skrev, så har jeg ikke haft noget rigtigt projekt hvor en god kø skal bruges siden jeg opdagede zmq - så jeg har kun et par håndfulde timers "leg" med det som praktisk erfaring... Jeg vil dog sige, at det imponerer mig nok til at det indgår i overvejelserne til mere end et fremtidigt projekt, der pt. er i støbeskeerne.
Jeg vil give dig ret i, at det er relativt low-level.
Hvis du kigger på deres site, er der et punkt, der hedder paid support (en af dem er firmaet bag zmq- som er bosat i Belgien hvis jeg husker rigtigt). Prøv evt. at kontakte dem (eller se nogle af de mange videoer).
Det er min opfattelse at zmq bliver brugt i særdeles mission-critical løsninger (dog uden at jeg har direkte kendskab).
-
0
-
0
Men er det en arkitekturopgave som handler om integration, eller en kø-implementeringsopgave.
-
0
-
0
En præsentation der måske kan hjælpe:
http://www.slideshare.net/carrja99/high-powered-messaging-with
-
0
-
0
@Nikolaj, det er en integrationsopgave, ikke nødvendigvis en kø-opgave. Kombinationen af krav synes jeg peger på et kø-pattern, men andre bud er velkommen. Er i gang med at se på dit slide-link :-)
-
0
-
0
Yes FUSE MB er bare ActiveMQ med support og hurtig løsning/release af bugs - derefter gives ændringerne tilbage til OpenSource AMQ. Har selv erfaring med det. Det virker og har nogle ok fede features - bl.a. fuldt integreret med Camel til routing etc.
-
0
-
0
nServicebus er gået fra opensource til købe produkt, men er rigtigt stærkt til MSMQ. De kigger også på at understøtte andre kø'er som MQ.
Men det er produkt der er værd at kigge på for at lave afkoblet system. Det er dog blevet meget stort produkt og efterhånden også dyrt i forhold til det var opensource.
nServicebus giver muligheden for at bruge MSMQ til afkoble din arkitektur til et distribueret system og er efter min mening meget stærkt i .net verden
-
0
-
0
Floss Weekly havde et afsnit om ZeroMQ - det gav et fint indblik i hvor de var som projekt og typen af problemer der er løst med ZeroMQ
http://twit.tv/show/floss-weekly/195
Der er intet visuelt vigtigt i afsnittet så lyd-versionen fungerer helt fint.
-
0
-
0
Tak for tips, senest til Jon, Mads og Per. Jeg har tidligere efterlyst stærk support 24/7 som et krav, gerne med udførende/udkørende konsulenter.
Har nogen af jer kendskab til et kø-produkt som har sådan en support (ud over IBM Websphere MQ)?
-
0
-
0
Oracle MessageQ ?
Oracle plejer at have god support... hvis man betaler for det.
-
0
-
0
RabbitMQ her også commercial services via springsource
http://www.rabbitmq.com/services.html
http://www.springsource.com/rabbit-technologies-acquisition-faq
http://www.springsource.com/services
-
0
-
0
Tilføj kommentar
