IBM MQ

IBM MQ är en familj av meddelandeorienterade mellanprogramprodukter som IBM lanserade i december 1993. Den hette ursprungligen MQSeries och döptes om till WebSphere MQ 2002 för att ansluta sig till sviten av WebSphere -produkter. I april 2014 döptes det om till IBM MQ . Produkterna som ingår i MQ-familjen är IBM MQ, IBM MQ Advanced, IBM MQ Appliance, IBM MQ för z/OS och IBM MQ på IBM Cloud. IBM MQ har också containeriserade distributionsalternativ.

MQ tillåter oberoende och potentiellt icke samtidiga applikationer på ett distribuerat system att säkert kommunicera med varandra med hjälp av meddelanden. MQ är tillgängligt på ett stort antal plattformar (både IBM och icke-IBM), inklusive z/OS ( stordator ), IBM i , Transaction Processing Facility , UNIX ( AIX , HP-UX , Solaris ), HP NonStop , OpenVMS , Linux och Microsoft Windows .

MQ-komponenter

Kärnkomponenterna i MQ är:

  • Meddelande : Meddelanden är samlingar av binär eller tecken (till exempel ASCII eller EBCDIC ) data som har någon betydelse för ett deltagande program. Liksom i andra kommunikationsprotokoll läggs lagrings-, routing- och leveransinformation till meddelandet före sändning och tas bort från meddelandet före leverans till den mottagande applikationen.
  • Kö : Meddelandeköer är objekt som lagrar meddelanden i en applikation.
  • Queue Manager : en systemtjänst som tillhandahåller en logisk behållare för meddelandekön. Den ansvarar för att överföra data till andra köansvariga via meddelandekanaler. Även om det inte strikt krävs för meddelandeorienterad mellanprogram, är det en IBM MQ-förutsättning. Köhanterare hanterar lagring, tidsproblem, triggning och alla andra funktioner som inte är direkt relaterade till den faktiska rörelsen av data.

Program integrerade med IBM MQ använder ett konsekvent applikationsprogramgränssnitt (API) över alla plattformar.

Meddelandetyper

MQ stöder punkt-till-punkt och Publicera-Prenumerera meddelanden.

API:er

API:er som direkt stöds av IBM inkluderar:

Ytterligare API:er (som inte stöds officiellt) är också tillgängliga via tredje part, inklusive:

Funktioner

Engångsleverans : MQ använder endast en gång och en gång leverans. Denna tjänstekvalitet förhindrar vanligtvis meddelandeförlust eller duplicering.

Asynkron meddelandehantering : MQ förser applikationsdesigners med en mekanism för att uppnå icke-tidsberoende arkitektur. Meddelanden kan skickas från en applikation till en annan, oavsett om applikationerna körs samtidigt. Om ett meddelandemottagarprogram inte körs när en avsändare skickar ett meddelande till den, kommer köhanteraren att hålla meddelandet tills mottagaren ber om det. Beställning av alla meddelanden bevaras, som standard är detta i FIFO- ordning för mottagning i den lokala kön inom prioritet för meddelandet.

Datatransformation : t.ex. Big Endian till Little Endian , eller EBCDIC till ASCII . Detta åstadkommes genom användning av meddelandedatautgångar . Exits är kompilerade applikationer som körs på köhanterarens värd och exekveras av IBM MQ-programvaran vid den tidpunkt då datatransformation behövs.

Meddelandestyrt arkitekturramverk : IBM MQ tillåter mottagning av meddelanden för att "trigga" andra applikationer att köras.

Utbud av API :er: Den implementerar Java Message Service (JMS) standard-API och har också sin egen proprietära API, känd som Message Queuing Interface (MQI), som föregick JMS i flera år. Från och med version 8.0.0.4 stöder MQ även MQ Light API.

Klustring : Flera MQ-implementeringar delar behandlingen av meddelanden, vilket ger lastbalansering.

Kommunikation

Köansvariga kommunicerar med omvärlden antingen genom:

  • Bindningar : en direkt mjukvaruanslutning. Generellt snabbare, men begränsat till program som körs på samma fysiska värd som köhanteraren.
  • En nätverks- eller "klient"-anslutning : applikationer som använder en klientanslutning kan ansluta till en köhanterare på vilken annan värd som helst i nätverket. Den fysiska platsen för köhanteraren är irrelevant, så länge den är tillgänglig över nätverket.

Kommunikation mellan köansvariga

Detta är beroende av en kanal . Varje köhanterare använder en eller flera kanaler för att skicka och ta emot data till andra köhanterare. En kanal är enkelriktad; en andra kanal krävs för att returnera data. I ett TCP/IP-baserat nätverk skickar eller tar en kanal emot data på en specifik port.

Kanaltyper:

  • Sändningskanal : har en definierad destination och är associerad med en specifik överföringskö (mekanismen genom vilken meddelanden köas i väntan på överföring på kanalen).
  • Mottagande kanal : tar emot data från vilken annan köhanterare som helst med en sändande kanal med samma namn.

När en mottagande kanal tar emot ett meddelande undersöks den för att se vilken köhanterare och kö den är avsedd för. I händelse av ett kommunikationsfel kan MQ automatiskt återupprätta en anslutning när problemet är löst.

Lyssnaren är applikationens nätverksgränssnitt till köhanteraren . Lyssnaren upptäcker anslutningar från inkommande kanaler och hanterar anslutningen av de sändande kanalerna till de mottagande kanalerna. I ett TCP/IP-nätverk kommer lyssnaren att "lyssna" efter anslutningar på en specifik port.

Överför data till en kö på en annan köhanterare

Kötyper:

  • Lokal kö : representerar platsen där data lagras i väntan på bearbetning.
  • Fjärrkö : representerar en kö på en annan köhanterare. De definierar destinationskön, som är en del av routingmekanismen för meddelanden.
  • Klusterkö : representerar en kö som kan nås via valfri köhanterare i sitt kluster.

Ett meddelande placeras i en fjärrkö. Meddelanden går till en temporär lagringsöverföringskö associerad med en kanal. När ett meddelande placeras i en fjärrkö, sänds meddelandet över fjärrkanalen. Om överföringen lyckas tas meddelandet bort från överföringskön. Vid mottagande av ett meddelande undersöker den mottagande köhanteraren meddelandet för att fastställa om meddelandet är för sig självt eller om det måste gå till en annan köhanterare. Om den mottagande köhanteraren, kommer den nödvändiga kön att kontrolleras, och om den finns placeras meddelandet på denna kö. Om inte, läggs meddelandet i dödbokstavskön . MQ har funktioner för att hantera effektiv överföring av data över en mängd olika kommunikationsmedier. Till exempel kan meddelanden grupperas ihop tills en kö når ett visst djup.

Beställning

Även om kön är FIFO, beställs den baserat på kvittot i den lokala kön, inte bekräftelsen av meddelandet från avsändaren. Meddelanden kan prioriteras, och som standard prioriteras kön i ankomstordning. Köer kommer endast att vara i sekvens av tillägg om meddelandet läggs till lokalt. Meddelandegruppering kan användas för att säkerställa att en uppsättning meddelanden är i en specifik ordning, förutom att, om sekvensen är kritisk, är det applikationens ansvar att placera sekvensdata i meddelandet eller implementera en handskakningsmekanism via en returkö. I verkligheten kommer beställning att bibehållas i enkla konfigurationer.

Loggen

Det andra elementet i en köhanterare är loggen . När ett meddelande placeras i en kö eller en konfigurationsändring görs, loggas även data. I händelse av ett fel används loggen för att återskapa skadade objekt och återskapa meddelanden. Endast beständiga meddelanden återskapas när ett fel inträffar – "icke-beständiga" meddelanden går förlorade. Icke-beständiga meddelanden kan skickas över en kanal inställd på ett snabbt läge, där leverans inte garanteras i händelse av ett kanalfel.

MQ stöder både cirkulär och linjär loggning.

Hämtar meddelanden från köer

Information kan hämtas från köer antingen genom att polla kön för att kontrollera tillgängliga data med lämpliga intervall, eller alternativt kan MQ utlösa en händelse, vilket gör att en klientapplikation kan svara på leveransen av ett meddelande.

Tillgänglighet

IBM MQ erbjuder en mängd olika lösningar för tillgänglighet:

Replicated Data Queue Manager (RDQM / 'Easy HA'- MQ Advanced på endast distribuerad): Synkron replikering mellan tre servrar som alla delar en flytande IP-adress.

Köhanterarkluster: Grupper med två eller flera köhanterare på en eller flera datorer definieras till ett kluster, vilket ger automatisk sammankoppling och tillåter att köer delas mellan dem för lastbalansering och redundans.

Ködelningsgrupper (endast z/OS): I en delad kömiljö kan en applikation ansluta till vilken som helst av köhanterarna inom ködelningsgruppen. Eftersom alla köhanterare i ködelningsgruppen kan komma åt samma uppsättning delade köer, är applikationen inte beroende av tillgängligheten för en viss köhanterare. Detta ger större tillgänglighet om en köhanterare slutar eftersom alla andra köhanterare i ködelningsgruppen kan fortsätta bearbeta kön.

Multi-Instance Queue Managers (tillgänglig från v7.0.1): Instanser av samma köhanterare konfigureras på två eller flera datorer med deras köer och metadata på delad lagring. Genom att starta flera instanser blir en instans den aktiva instansen och de andra instanserna standby. Om den aktiva instansen misslyckas tar en standby-instans som körs på en annan dator automatiskt över.

Historia

Releasedatum för version

Versionsnamn Utgivningsdatum
IBM MQ 9.3 LTS 23 juni 2022
IBM MQ 9.2 LTS 23 juli 2020
IBM MQ 9.1 LTS 23 juli 2018
IBM MQ på IBM Cloud 13 mars 2018
IBM MQ för HPE Nonstop 8.0 23 juni 2017
IBM MQ 9.0 LTS 2 juni 2016
IBM MQ 8.0 23 maj 2014
WebSphere MQ 7.5 15 juni 2012
WebSphere MQ 7.1 november 2011
WebSphere MQ 7.0 z/OS juni 2008
WebSphere MQ 7.0 (Distribuerad, iSeries) maj 2008
WebSphere MQ 6.0 z/OS juni 2005
WebSphere MQ 6.0 (Distribuerad, iSeries) maj 2005
WebSphere MQ 5.3 z/OS juni 2002
WebSphere MQ 5.3 (Distribuerad, iSeries) Juni, juli, okt, nov 2002
MQSeries 5.2 (Distribuerad) december 2000
MQSeries för OS/390 V5.2 nov 2000
MQSeries för AS/400 V5.1 Juli-aug 2000
MQSeries för OS/390 V2.1 februari 1999
MQSeries 5.1 april (NT), juni 1999
MQSeries för AS/400 V4.2 februari 1998
MQSeries 5.0 oktober 1997
MQSeries för MVS/ESA 1.2 29 augusti 1997
MQSeries för MVS 1.1.4, juni 1996
MQSeries 2.2 (Sun OS/Solaris, DC/OSx) juni, juli 1996
MQSeries 2.0 Windows NT 2Q 1996
MQSeries 2.2 (HP, SCO) 4Q 1995
MQSeries för MVS 1.1.3 maj 1995
MQSeries 2.0 (OS/2, AIX) feb 1995 (början på slutet av ezBridge)
MQM/400 V3 4Q 1994
ezBridge Transact för MQSeries 3.0 juli 1994
MQSeries för MVS 1.1.2 juni 1994
MQM/400 V2.3 feb/april 1994
ezBridge Transact för MQSeries Mars, sept, nov, dec 1993 (olika plattformar)
MQSeries för MVS V1.1.1 31 december 1993

Versionens slutdatum för support

Följande tabell gäller MQ-programvaran. MQ Appliance har andra livscykeldatum för både firmware och hårdvara än de i tabellen.

Versionsnamn Allmän tillgänglighet Slut på marknadsföring Slut på support
IBM MQ 9.3 23 juni 2022 - -
IBM MQ 9.2 23 juli 2020 - -
IBM MQ 9.1 23 juli 2018 15 september 2023 30 september 2023
IBM MQ 9.0 2 juni 2016 17 september 2021 30 september 2021
IBM MQ 8.0 13 juni 2014 17 april 2020 30 april 2020
WebSphere MQ 7.5 6 juli 2012 16 december 2016 30 april 2018
WebSphere MQ 7.1 25 november 2011 12 juli 2016 30 april 2017

Bakgrund arkitektonisk referens

Med tillkomsten av datorer såg IBM en möjlighet att tillämpa ny teknik på behovet av meddelandebyte.

I början av 1960-talet marknadsförde IBM IBM 7740 Communication Control System och IBM 7750 Programmed Transmission Control, som var programmerbara meddelandeväxlingssystem.

IBM System/360 tillkännagavs i april 1964 och med det kom metoder för kommunikationsåtkomst som BTAM och QTAM (Basic and Queued Telecommunications Access Methods). 1971 erbjöd TCAM, Telecommunications Access Method , sina användare en mer avancerad form av meddelandeväxling eller meddelandedirigering. TCAM var allmänt accepterat, särskilt inom finans- och mäklarbranscherna. Den stödde asynkron meddelandehantering, som med den senare MQ. TCAM 3.0 lades till i återanvändbara diskmeddelandeköer för återställning snart därefter, som med MQ. Ett PL/I-program på hög nivå skulle kunna användas för att komma åt TRANSIENT datauppsättningar (dynamiska meddelandeköer). Läsning av ett meddelande från en övergående datauppsättning resulterade i att meddelandet togs bort från kön, som med en READ utan att bläddra med MQ.

I slutet av 1970-talet kom transaktionshanteringssystem till, vart och ett försökte uppnå en ledande position i branschen. Inom IBM valdes CICS och IMS som strategiska produkter för att möta behovet av transaktionshantering. Inom både CICS och IMS hade var och en sin version av meddelandeväxling, IMS är ett front-end kösystem och CICS har sin Transient Data-facilitet som möjlig bas för meddelandeväxling. [ citat behövs ]

CICS etablerade sig som ett populärt transaktionshanteringssystem under tidsramen 1968-1971. De användare som hade anammat TCAM för sina meddelandehanteringsfunktioner ville nu ha en kombinerad användning av TCAM med CICS. I december 1971 tillkännagav IBM CICS-stöd för TCAM som en del av CICS/OS-standardprodukten, som skulle levereras i december 1972. För intresserade kunder gjorde detta det möjligt för dem att använda TCAM för sina meddelandehanteringsstyrkor och även ha TCAM-anslutna terminaler eller datorer gränssnitt med CICS online-applikationer. [ citat behövs ]

I januari 1973 fortsatte TCAM att stödjas av CICS/OS-standardversion 2.3. Emellertid uteslöts TCAM-stöd från den första utgåvan av CICS/VS, som tillkännagavs i februari 1973 och levererades i juni 1974. Det behöver inte sägas att många CICS-TCAM-kunder inte var nöjda med den produktriktningen.

Med stort tryck från CICS-TCAM-kunder återinfördes CICS-stödet för TCAM i CICS/VS 1.1-produkten från och med september 1974. Utöver det tidigare DCB-stödet, med detta återinförande av TCAM-stödet, började CICS stödja TCAM-åtkomst via VTAM, även känd som ACB-stödet. CICS TCAM ACB-stöd avbröts från och med CICS/ESA version 3-produkten 1990.

1992 tillkännagav IBM en ny produkt som heter MQSeries. Detta varumärke döptes senare om till WebSphere MQ (ibland förkortat till WMQ) 2002 för att stödja WebSpheres familjenamn och produkten. 2014 döptes det om till IBM MQ. MQ skulle vara en förlängning av TCAM-funktionalitet från endast IBM-system till alla andra plattformar. MQ har en arkitektur som gör att heterogena system kan kommunicera med varandra (t.ex. IBM, HP, Sun, Tandem, etc.). MQ kan användas med CICS-system för att skicka och ta emot data till/från alla andra MQ-berättigade system. MQ kan användas för att initiera arbete i ett CICS-system eller så kan en CICS-transaktion initiera arbete i ett annat CICS- eller icke-CICS-system.

IBM MQ stöder nu 80 olika miljöer och har blivit den ledande produkten för budskapssäkrad leveransväxling/routing i branschen.

MQ och webbtjänster

IBM MQ kan användas som en grund för att skapa tjänsteorienterade arkitekturer . Flera ytterligare produktalternativ finns för att hjälpa till att konvertera äldre program till fungerande webbtjänster genom att använda MQ. Större, heterogena företag framstår ofta som en federation av något autonoma domäner baserade på branscher, funktionella eller styrningsområden. I sådana miljöer kan vissa tjänster delas eller återanvändas endast inom en enda domän, medan andra kan delas eller återanvändas inom hela företaget. IBM MQ tillhandahåller det sätt på vilket kommunikation existerar mellan affärsområden eller på annat sätt separata affärsdomäner.

En relaterad produkt i IBM MQ-produktfamiljen, kallad IBM App Connect Enterprise (tidigare IBM Integration Bus / WebSphere Message Broker) möjliggör en mångsidig och robust uppsättning tillägg till köbaserade arkitekturer. Med hjälp av IBM Integration Bus kan användare implementera ett WebServices-gränssnitt, komplett med WSDL- filstöd som kan interagera med alla köbaserade applikationer.

Se även

externa länkar

Lyssna på den här artikeln ( 22 minuter )
Spoken Wikipedia icon
Den här ljudfilen skapades från en revidering av denna artikel daterad 29 oktober 2011 ( 2011-10-29 ) och återspeglar inte efterföljande redigeringar.
( Ljudhjälp · Fler talade artiklar )
Hämtad från " https://en.wikipedia.org/w/index.php?title=IBM_MQ&oldid=1120010140 "