Meddelelsesorienteret middleware - Message-oriented middleware

Meddelelsesorienteret middleware ( MOM ) er software eller hardware-infrastruktur, der understøtter afsendelse og modtagelse af beskeder mellem distribuerede systemer . MOM tillader applikationsmoduler at blive distribueret over heterogene platforme og reducerer kompleksiteten af ​​at udvikle applikationer, der spænder over flere operativsystemer og netværksprotokoller . Den middleware skaber et distribueret kommunikation lag, der isolerer applikation udvikler fra detaljerne i de forskellige operativsystemer og netværksgrænseflader. API'er, der strækker sig på tværs af forskellige platforme og netværk, leveres typisk af MOM.

Dette mellemvarelag tillader softwarekomponenter (applikationer, Enterprise JavaBeans, servlets og andre komponenter), der er udviklet uafhængigt, og som kører på forskellige netværksplatforme, at interagere med hinanden. Applikationer distribueret på forskellige netværksnoder bruger applikationsgrænsefladen til at kommunikere. Desuden kan dette nye, virtuelle system af sammenkoblede applikationer gøres pålideligt og sikkert ved at tilvejebringe en administrativ grænseflade.

MOM leverer softwareelementer, der findes i alle kommunikationskomponenter i en klient/serverarkitektur og typisk understøtter asynkrone opkald mellem klienten og serverapplikationer. MOM reducerer involvering af applikationsudviklere med kompleksiteten af ​​master-slave-karakteren af ​​klient/server-mekanismen.

Middleware kategorier

Alle disse modeller gør det muligt for en softwarekomponent at påvirke en anden komponents adfærd over et netværk. De er forskellige ved, at RPC- og ORB-baseret middleware skaber systemer med tæt koblede komponenter, hvorimod MOM-baserede systemer muliggør en løs kobling af komponenter. I et RPC- eller ORB-baseret system, når en procedure kalder en anden, skal den vente på, at den kaldte procedure vender tilbage, før den kan gøre noget andet. I disse synkrone meddelelsesmodeller fungerer middleware delvist som en superlink, lokaliserer den kaldte procedure på et netværk og bruger netværkstjenester til at videregive funktions- eller metodeparametre til proceduren og derefter returnere resultater.

Fordele

Centrale grunde til at bruge en meddelelsesbaseret kommunikation protokol omfatter dens evne til at lagre (buffer), rute eller omdanne meddelelser når den overfører dem fra afsendere til modtagere.

En anden fordel ved meddelelsesudbyderformidlet besked mellem klienter er, at du ved at tilføje en administrativ grænseflade kan overvåge og justere ydelsen. Klientapplikationer lindres således effektivt for ethvert problem, bortset fra at sende, modtage og behandle meddelelser. Det er op til koden, der implementerer MOM -systemet og op til administratoren at løse problemer som interoperabilitet, pålidelighed, sikkerhed, skalerbarhed og ydeevne.

Asynkronitet

Ved hjælp af et MOM -system foretager en klient et API -opkald for at sende en besked til en destination, der administreres af udbyderen. Opkaldet påkalder udbyderens tjenester at rute og levere beskeden. Når den har sendt beskeden, kan klienten fortsætte med at udføre andet arbejde i tillid til, at udbyderen bevarer meddelelsen, indtil en modtagende klient henter den. Den meddelelsesbaserede model, kombineret med udbyderens mægling, gør det muligt at oprette et system med løst koblede komponenter.

MOM omfatter en kategori af inter- ansøgning kommunikation software , der generelt er afhængig af asynkron besked-passerer , i modsætning til en anmodning-respons -arkitektur. I asynkrone systemer giver meddelelseskøer midlertidig lagring, når destinationsprogrammet er optaget eller ikke er forbundet. Derudover giver de fleste asynkrone MOM -systemer vedvarende lagring for at sikkerhedskopiere meddelelseskøen. Det betyder, at afsender og modtager ikke behøver at oprette forbindelse til netværket på samme tid ( asynkron levering ), og problemer med intermitterende forbindelser er løst. Det betyder også, at hvis modtagerprogrammet mislykkes af en eller anden grund, kan afsenderne fortsætte upåvirket, da de beskeder, de sender, simpelthen akkumuleres i meddelelseskøen til senere behandling, når modtageren genstarter.

Routing

Mange meddelelsesorienterede middleware-implementeringer afhænger af et meddelelseskøsystem . Nogle implementeringer gør det muligt at levere routinglogik af selve meddelelseslaget, mens andre er afhængige af klientprogrammer for at levere routingsinformation eller muliggøre en blanding af begge paradigmer. Nogle implementeringer gør brug af broadcast- eller multicast -distributionsparadigmer.

Transformation

I et meddelelsesbaseret middleware-system behøver meddelelsen, der modtages på destinationen, ikke at være identisk med den besked, der oprindeligt blev sendt. Et MOM-system med indbygget intelligens kan omdanne meddelelser og rute til at matche afsenderens eller modtagerens krav. I forbindelse med routing og broadcast/ multicast -faciliteter kan en applikation sende en besked i sit eget native -format, og to eller flere andre applikationer kan hver modtage en kopi af meddelelsen i deres eget native -format. Mange moderne MOM-systemer tilbyder sofistikerede værktøjer til beskedtransformation (eller kortlægning), som giver programmører mulighed for at specificere transformationsregler, der gælder for en simpel GUI- træk-og-slip- operation.

Ulemper

Den primære ulempe ved mange meddelelsesorienterede middleware-systemer er, at de kræver en ekstra komponent i arkitekturen , meddelelsesoverførselsagenten ( meddelelsesmægler ). Som med ethvert system kan tilføjelse af en anden komponent føre til nedsat ydelse og pålidelighed og kan også gøre systemet som helhed vanskeligere og dyrere at vedligeholde .

Derudover har mange interapplikationskommunikationer et iboende synkront aspekt, hvor afsenderen specifikt ønsker at vente på et svar på en meddelelse, før han fortsætter (se real-time computing og nær real-time for ekstreme tilfælde). Fordi meddelelsesbaseret kommunikation i sagens natur fungerer asynkront, passer den muligvis ikke godt i sådanne situationer. Når det er sagt, har de fleste MOM-systemer faciliteter til at gruppere en anmodning og et svar som en enkelt pseudosynkron transaktion.

Med et synkront beskedsystem vender den kaldende funktion ikke tilbage, før den kaldte funktion har afsluttet sin opgave. I et løst koblet asynkront system kan den kaldende klient fortsætte med at indlæse arbejde på modtageren, indtil de nødvendige ressourcer til at håndtere dette arbejde er opbrugt, og den kaldte komponent mislykkes. Selvfølgelig kan disse forhold minimeres eller undgås ved at overvåge ydeevnen og justere meddelelsesflowet, men dette er arbejde, der ikke er nødvendigt med et synkront beskedsystem. Det vigtige er at forstå fordele og forpligtelser ved hver slags systemer. Hvert system er egnet til forskellige slags opgaver. Nogle gange er en kombination af de to slags systemer påkrævet for at opnå den ønskede adfærd.

Standarder

Historisk set manglede der standarder for brugen af ​​meddelelsesorienteret middleware, der har forårsaget problemer. De fleste af de store leverandører har deres egne implementeringer, hver med sit eget programmeringsinterface (API) og styringsværktøjer.

En af de mangeårige standarder for meddelelsesorienteret middleware er X/Open-gruppens XATMI-specifikation (Distributed Transaction Processing: The XATMI Specification), som standardiserer API til interprocesskommunikation . Kendte implementeringer til denne API er ATR Baltic's Enduro/X middleware og Oracle 's Tuxedo .

Den avancerede Message Queuing Protocol (AMQP) er en godkendt OASIS og ISO-standard, der definerer protokollen og formater bruges mellem deltagende programkomponenter, så implementeringer er interoperable. AMQP kan bruges med fleksible routingsordninger, herunder almindelige meddelelsesparadigmer som point-to-point , fan-out , publish/subscribe og request-response (bemærk at disse forsætligt er udeladt fra v1.0 i selve protokollestandarden, men stole på den særlige implementering og/eller underliggende netværksprotokol til routing). Det understøtter også transaktionsstyring, kø, distribution, sikkerhed, ledelse, clustering, føderation og heterogen multi-platform support. Java -applikationer, der bruger AMQP, er typisk skrevet i Java JMS. Andre implementeringer giver API'er til C#, C ++, PHP, Python, Ruby og andre sprog.

Den højtstående Arkitektur (HLA IEEE 1516) er en IEEE og SISO standard for interoperabilitet simulering. Det definerer et sæt tjenester, der leveres via en API i C ++ eller Java. Tjenesterne tilbyder udgivelse/abonnement baseret informationsudveksling baseret på en modulær Federation Object Model. Der er også tjenester til koordineret dataudveksling og tidsforskud baseret på logisk simuleringstid samt synkroniseringspunkter. Yderligere tjenester giver ejerskifte, optimering af datadistribution og overvågning og styring af deltagende føderater (systemer).

Den MQ Telemetri Transport (MQTT) er en ISO-standard (ISO / IEC PRF 20.922) støttet af OASIS organisation. Det giver en let publiceret/abonnér pålidelig meddelelsestransportprotokol oven på TCP/IP, der er velegnet til kommunikation i M2M/IoT -sammenhænge, ​​hvor der kræves et lille kodefodaftryk og/eller netværksbåndbredde.

Den Object Management Group 's data Distribution Service (DDS) giver besked-orienterede Publish / Abonner (P / S) middleware standard, har til formål at gøre det muligt for skalerbar, real-time, pålidelig, højtydende og interoperable dataudveksling mellem udgivere og abonnenter. Standarden giver grænseflader til C ++, C ++ 11, C, Ada, Java og Ruby.

EXtensible Messaging and Presence Protocol ( XMPP ) er en kommunikationsprotokol for meddelelsesorienteret middleware baseret på XML (Extensible Markup Language). Protokollen er designet til at kunne udvides og er også blevet brugt til publicerings-abonnementsystemer, signalering til VoIP, video, filoverførsel, spil, Internet of Things-applikationer såsom smart grid og sociale netværkstjenester. I modsætning til de fleste instant messaging -protokoller er XMPP defineret i en åben standard og anvender en åben systemmetode til udvikling og applikation, hvorved enhver kan implementere en XMPP -service og interoperere med andre organisationers implementeringer. Fordi XMPP er en åben protokol, kan implementeringer udvikles ved hjælp af enhver softwarelicens; Selvom mange server-, klient- og biblioteksimplementeringer distribueres som gratis og open source-software, findes der også adskillige freeware- og proprietære softwareimplementeringer. Internet Engineering Task Force (IETF) dannede en XMPP -arbejdsgruppe i 2002 for at formalisere kerneprotokollerne som en IETF instant messaging og tilstedeværelsesteknologi. XMPP -arbejdsgruppen producerede fire specifikationer (RFC 3920, RFC 3921, RFC 3922, RFC 3923), som blev godkendt som foreslåede standarder i 2004. I 2011 blev RFC 3920 og RFC 3921 afløst af henholdsvis RFC 6120 og RFC 6121 med RFC 6122 angiver XMPP -adresseformatet. Ud over disse kerneprotokoller, der er standardiseret ved IETF, er XMPP Standards Foundation (tidligere Jabber Software Foundation) aktiv i udviklingen af ​​åbne XMPP -udvidelser. XMPP-baseret software distribueres bredt på Internettet ifølge XMPP Standards Foundation og danner grundlaget for Department of Defense (DoD) Unified Capabilities Framework.

Den Java EE programmering miljø giver en standard API kaldet JMS (JMS), som gennemføres af de fleste MOM leverandører og har til formål at skjule de særlige MOM API implementeringer; dog definerer JMS ikke formatet på de meddelelser, der udveksles, så JMS -systemer er ikke interoperable.

En lignende indsats er med det aktivt udviklende OpenMAMA -projekt, der har til formål at levere en fælles API, især til C -klienter. I øjeblikket (august 2012) er det imidlertid primært hensigtsmæssigt at distribuere markedsorienterede data (f.eks. Aktiekurser) over pub-sub middleware.

Besked i kø

Se også: Beskedkø service

Meddelelseskøer tillader udveksling af oplysninger mellem distribuerede applikationer. En meddelelseskø kan ligge i hukommelse eller disklagring. Beskeder forbliver i køen, indtil de behandles af en serviceforbruger. Gennem meddelelseskøen kan applikationen implementeres uafhængigt - de behøver ikke at kende hinandens position eller fortsætte med at implementere procedurer for at fjerne behovet for at vente på at modtage denne besked.

Tendenser

Se også

Referencer

eksterne links