IBM MQ - IBM MQ

IBM MQ er en familie af meddelelsesorienterede middleware- produkter, som IBM lancerede i december 1993. Det blev oprindeligt kaldt MQSeries og blev omdøbt til WebSphere MQ i 2002 for at slutte sig til pakken med WebSphere- produkter. I april 2014 blev det omdøbt til IBM MQ . De produkter, der er inkluderet i MQ -familien, er IBM MQ, IBM MQ Advanced, IBM MQ Appliance, IBM MQ for z/OS og IBM MQ på IBM Cloud. IBM MQ har også containeriserede implementeringsmuligheder.

MQ tillader uafhængige og potentielt ikke-samtidige applikationer på et distribueret system at kommunikere sikkert med hinanden ved hjælp af meddelelser. MQ er tilgængelig på et stort antal platforme (både IBM og ikke-IBM), herunder z/OS ( mainframe ), IBM i , Transaction Processing Facility , UNIX ( AIX , HP-UX , Solaris ), HP NonStop , OpenVMS , Linux og Microsoft Windows .

MQ -komponenter

Kernekomponenterne i MQ er:

• Besked : Beskeder er samlinger af binære data eller tegn (f.eks. ASCII eller EBCDIC ), der har en vis betydning for et deltagende program. Som i andre kommunikationsprotokoller føjes lagrings-, routings- og leveringsinformation til meddelelsen før transmission og fjernes fra meddelelsen før levering til den modtagende applikation.
• Kø : Beskedskøer er objekter, der gemmer meddelelser i et program.
• Køhåndtering : en systemtjeneste, der giver en logisk beholder til meddelelseskøen. Den er ansvarlig for at overføre data til andre køledere via beskedkanaler. Selvom det ikke er strengt påkrævet for meddelelsesorienteret middleware, er det en IBM MQ-forudsætning. Køledere håndterer lagring, timingproblemer, triggering og alle andre funktioner, der ikke er direkte relateret til den faktiske flytning af data.

Programmer integreret med IBM MQ bruger en konsekvent applikationsprogramgrænseflade (API) på tværs af alle platforme.

Beskedtyper

MQ understøtter point-to-point og Publish-Subscribe- beskeder.

API'er

API'er, der understøttes direkte af IBM, omfatter:

• IBM Message Queue Interface (MQI) til C , COBOL , PL/I , Java , Rexx , RPG og C ++
• Java Message Service (JMS)
• XMS til C/C ++ og .NET
• .NET
• Overførsel af repræsentationsstat
• SÆBE

Yderligere API'er (ikke officielt understøttet) er også tilgængelige via tredjeparter, herunder:

• Perl -interface (udviklet og bidraget af Hildo Biersma), tilgængelig fra CPAN .
• Python (programmeringssprog) interface PyMQI (oprindeligt udviklet af Les Smithson), tilgængelig fra PyPI
• Windows PowerShell

Funktioner

Engangslevering : MQ bruger kun én gang levering. Denne servicekvalitet forhindrer typisk tab af beskeder eller dobbeltarbejde.

Asynkron besked : MQ giver applikationsdesignere en mekanisme til at opnå ikke-tidsafhængig arkitektur. Beskeder kan sendes fra et program til et andet, uanset om applikationerne kører på samme tid. Hvis en meddelelsesmodtager -applikation ikke kører, når en afsender sender den en besked, vil køhåndteringen holde meddelelsen, indtil modtageren beder om den. Bestilling af alle meddelelser bevares, som standard er dette i FIFO -modtagelsesrækkefølge ved den lokale kø inden for meddelelsens prioritet.

Datatransformation : f.eks. Big Endian til Little Endian eller EBCDIC til ASCII . Dette opnås ved brug af meddelelsesdataudgange . Exits er kompilerede applikationer, der kører på køhåndteringsværten, og udføres af IBM MQ -softwaren på det tidspunkt, hvor datatransformation er nødvendig.

Beskeddrevet arkitekturramme : IBM MQ tillader modtagelse af meddelelser for at "udløse" andre applikationer til at køre.

Omfang af API'er : Det implementerer Java Message Service (JMS) standard API, og har også sit eget proprietære API, kendt som Message Queuing Interface (MQI), der gik forud for JMS flere år i eksistens. Fra version 8.0.0.4 understøtter MQ også MQ Light API.

Klynger : Flere MQ -implementeringer deler behandlingen af ​​meddelelser, hvilket giver belastningsbalancering.

Meddelelse

Køledere kommunikerer med omverdenen enten gennem:

• Bindinger : en direkte softwareforbindelse. Generelt hurtigere, men begrænset til programmer, der kører på den samme fysiske vært som køadministratoren.
• Et netværk eller en "klient" -forbindelse : applikationer, der bruger en klientforbindelse, kan oprette forbindelse til en køstyring på enhver anden vært i netværket. Køens manager er fysisk irrelevant, så længe den er tilgængelig via netværket.

Kommunikation mellem køledere

Dette afhænger af en kanal . Hver køstyrer bruger en eller flere kanaler til at sende og modtage data til andre køledere. En kanal er envejs; en anden kanal er påkrævet for at returnere data. I et TCP/IP -baseret netværk sender eller modtager en kanal data på en bestemt port.

Kanaltyper:

• Sendekanal : har en defineret destination og er forbundet med en bestemt transmissionskø (den mekanisme, hvormed meddelelser står i kø, og venter på transmission på kanalen).
• Modtagende kanal : modtager data fra enhver anden kømanager med en afsenderkanal med samme navn.

Når en modtagende kanal modtager en besked, undersøges det for at se, hvilken kømanager og kø den er bestemt til. I tilfælde af kommunikationsfejl kan MQ automatisk genetablere en forbindelse, når problemet er løst.

Den lytteren er programmets netværksinterface til køen manager. Lytteren registrerer forbindelser fra indgående kanaler og administrerer forbindelsen mellem afsenderkanalerne og de modtagende kanaler. I et TCP/IP -netværk vil lytteren "lytte" efter forbindelser på en bestemt port.

Overførsel af data til en kø i en anden køstyrer

Køtyper:

• Lokal kø : repræsenterer det sted, hvor data er gemt og afventer behandling.
• Fjernkø : repræsenterer en kø i en anden køstyrer. De definerer destinationskøen, som er et element i routingsmekanismen for meddelelser.
• Klyngekø : repræsenterer en kø, som kan nås via en hvilken som helst køhåndtering i dens klynge.

En besked placeres i en fjernkø. Meddelelserne går til en midlertidig lagertransmissionskø, der er knyttet til en kanal. Når en meddelelse placeres i en fjernkø, sendes meddelelsen på tværs af fjernkanalen. Hvis transmissionen lykkedes, fjernes meddelelsen fra transmissionskøen. Ved modtagelse af en meddelelse undersøger den modtagende kø -manager meddelelsen for at afgøre, om meddelelsen er til sig selv, eller om den skal gå til en anden kø -manager. Hvis den modtagende køstyring kontrolleres den nødvendige kø, og hvis den findes, placeres meddelelsen på denne kø. Hvis ikke, placeres meddelelsen i den døde bogstavkø . MQ har funktioner til at styre effektiv transmission af data på tværs af forskellige kommunikationsmedier. For eksempel kan meddelelser batches sammen, indtil en kø når en bestemt dybde.

Bestilling

Selvom køen er FIFO, bestilles den baseret på kvitteringen i den lokale kø, ikke på afsendelse af beskeden fra afsenderen. Beskeder kan prioriteres, og som standard prioriteres køen i rækkefølge efter ankomst. Køer vil kun være i rækkefølge af tilføjelse, hvis meddelelsen tilføjes lokalt. Meddelelsesgruppering kan bruges til at sikre, at et sæt meddelelser er i en bestemt rækkefølge, bortset fra det, hvis sekvensen er kritisk, er det applikationens ansvar at placere sekvensdata i meddelelsen eller implementere en håndtryksmekanisme via en returkø. I virkeligheden vil bestillingen blive opretholdt i enkle konfigurationer.

Loggen

Det andet element i en køstyring er loggen . Når en meddelelse placeres i en kø, eller der foretages en konfigurationsændring, logges dataene også. I tilfælde af en fejl bruges loggen til at genskabe beskadigede objekter og genskabe meddelelser. Kun vedvarende meddelelser genskabes, når der opstår en fejl-"ikke-vedvarende" meddelelser går tabt. Ikke-vedvarende meddelelser kan sendes over en kanal, der er indstillet til en hurtig tilstand, hvor levering ikke er sikret i tilfælde af en kanalfejl.

MQ understøtter både cirkulær og lineær logning.

Henter beskeder fra køer

Information kan hentes fra køer enten ved at afstemme køen for at søge efter tilgængelige data med passende intervaller, eller alternativt kan MQ udløse en hændelse, så en klientapplikation kan reagere på levering af en besked.

Tilgængelighed

IBM MQ tilbyder en række forskellige løsninger for at imødekomme tilgængelighed:

Replikeret Data Queue Manager (RDQM / 'Easy HA'- MQ Advanced kun distribueret): Synkron replikation mellem tre servere, der alle deler en flydende IP-adresse.

Købehandlingsklynger: Grupper af to eller flere køadministratorer på en eller flere computere er defineret til en klynge, der giver automatisk sammenkobling, og gør det muligt at dele køer mellem dem for belastningsbalancering og redundans.

Kø-delingsgrupper (kun z/OS): I et delt kø-miljø kan et program oprette forbindelse til en hvilken som helst af køens ledere i kødelingsgruppen. Fordi alle køledere i kødelingsgruppen kan få adgang til det samme sæt delte køer, afhænger applikationen ikke af tilgængeligheden af ​​en bestemt køadministrator. Dette giver større tilgængelighed, hvis en køstyrer stopper, fordi alle de andre køledere i kødelingsgruppen kan fortsætte behandlingen af ​​køen.

Multi-Instance Queue Managers (tilgængelig fra v7.0.1): Forekomster af den samme kømanager er konfigureret på to eller flere computere, hvor deres køer og metadata findes på delt lager. Ved at starte flere instanser bliver den ene instans den aktive forekomst, og de andre instanser bliver standbys. Hvis den aktive forekomst mislykkes, overtager en standby -forekomst, der kører på en anden computer, automatisk.

Historie

Udgivelsesdatoer for version

Versionsafslutning på supportdatoer

Følgende tabel gælder for MQ -software. MQ Appliance har forskellige livscyklusdatoer for både firmware og hardware end dem i tabellen.

Arkitektonisk baggrund i baggrunden

Med fremkomsten af ​​computere så IBM en mulighed for at anvende ny teknologi til behovet for beskedskift.

I begyndelsen af ​​1960'erne markedsførte IBM IBM 7740 Communication Control System og IBM 7750 Programmed Transmission Control, som var programmerbare meddelelsesskiftesystemer.

IBM System/360 blev annonceret i april 1964, og med det fulgte kommunikationsadgangsmetoder såsom BTAM og QTAM (Basic and Queued Telecommunications Access Methods). I 1971 tilbød TCAM, Telecommunications Access Method , sine brugere en mere avanceret form for beskedskift eller beskedrouting. TCAM blev bredt accepteret, især i finans- og mæglerindustrien. Det understøttede asynkrone beskeder, som med den senere MQ. TCAM 3.0 tilføjet i genanvendelige diskmeddelelseskøer til gendannelse kort tid efter, som med MQ. Et PL/I-program på højt niveau kan bruges til at få adgang til TRANSIENT datasæt (dynamiske meddelelseskøer). Læsning af en besked fra et forbigående datasæt resulterede i, at meddelelsen blev fjernet fra køen, som med en ikke-gennemse LÆS med MQ.

I slutningen af ​​1970'erne opstod transaktionsstyringssystemer, der hver forsøgte at opnå en ledende position i branchen. Inden for IBM blev CICS og IMS valgt som strategiske produkter for at imødekomme behovet for transaktionsstyring. Inden for både CICS og IMS havde hver sin version af meddelelseskift, IMS var et front-end-system i kø og CICS havde sin Transient Data-facilitet som det mulige grundlag for beskedskift.

CICS etablerede sig som et populært transaktionsstyringssystem i perioden 1968-1971. De brugere, der havde vedtaget TCAM for sine beskedhåndteringsmuligheder, ønskede nu en kombineret brug af TCAM med CICS. I december 1971 annoncerede IBM CICS-understøttelse af TCAM som en del af CICS/OS-Standard-produktet, der skulle leveres i december 1972. For interesserede kunder gjorde dette dem i stand til at bruge TCAM til sine meddelelseshåndteringsstyrker og også have TCAM-tilsluttede terminaler eller computere grænseflade med CICS online applikationer.

I januar 1973 blev TCAM fortsat understøttet af CICS/OS-Standard Version 2.3. Imidlertid blev TCAM-support udeladt fra den første udgivelse af CICS/VS, annonceret i februar 1973 og leveret i juni 1974. Det er overflødigt at sige, at mange CICS-TCAM-kunder ikke var tilfredse med den produktretning.

Med stort pres fra CICS-TCAM-kunder blev CICS-understøttelsen fra TCAM genindsat i CICS/VS 1.1-produktet fra september 1974. Ud over den tidligere DCB-support, med denne genindførelse af TCAM-support, begyndte CICS at understøtte TCAM-adgang via VTAM, også kendt som ACB -understøttelse. CICS TCAM ACB -support blev afbrudt fra CICS/ESA Version 3 -produktet i 1990.

I 1992 annoncerede IBM et nyt produkt kaldet MQSeries. Dette mærkenavn blev senere omdøbt til WebSphere MQ (undertiden forkortet til WMQ) i 2002 for at understøtte WebSphere -familienavnet og produktet. I 2014 blev det omdøbt til IBM MQ. MQ skulle være forlængelsen af ​​TCAM-funktionalitet fra IBM-only-systemer til alle andre platforme. MQ har en arkitektur, der gør det muligt for heterogene systemer at kommunikere med hinanden (f.eks. IBM, HP, Sun, Tandem osv.). MQ kan bruges sammen med CICS-systemer til at sende og modtage data til/fra ethvert andet MQ-berettiget system. MQ kan bruges til at starte arbejde i et CICS-system, eller en CICS-transaktion kan starte arbejde i et andet CICS- eller ikke-CICS-system.

IBM MQ understøtter nu 80 forskellige miljøer og er blevet det førende budskabssikrede leveringsomskiftnings-/routingsprodukt i branchen.

MQ og webtjenester

IBM MQ kan bruges som et fundament til at skabe serviceorienterede arkitekturer . Der findes flere yderligere produktmuligheder for at hjælpe med at konvertere ældre programmer til fungerende webtjenester ved hjælp af MQ. Større, heterogene virksomheder fremstår ofte som en sammenslutning af noget autonome domæner baseret på forretningsområder, funktionelle eller forvaltningsområder. I sådanne miljøer kan nogle tjenester deles eller genbruges kun inden for et enkelt domæne, mens andre kan deles eller genbruges i hele virksomheden. IBM MQ tilvejebringer de midler, der kan bruges til kommunikation mellem forretningsområder eller på anden måde adskilte forretningsområder.

Et relateret produkt i IBM MQ-produktfamilien, kaldet IBM Integration Bus (tidligere WebSphere Message Broker) , muliggør et mangfoldigt og robust sæt udvidelser til købaserede arkitekturer. Ved hjælp af IBM Integration Bus kan brugerne implementere en WebServices-frontend, komplet med WSDL-filsupport , der kan interagere med enhver købaseret applikation.

Se også

• Avanceret meddelelseskøprotokol
• IBM WebSphere Message Broker
• Java Message Service
• Beskedskø
• Besked i kø som en tjeneste
• MQTT

Referencer

eksterne links

Lyt til denne artikel ( 22 minutter )

Denne lydfil blev oprettet ud fra en revision af denne artikel dateret 29. oktober 2011 og afspejler ikke efterfølgende ændringer. ( 2011-10-29 )

( Lydhjælp  · Flere talte artikler )

• IBM MQ -produktside