Berichtgerichte middleware - Message-oriented middleware

Message-oriented middleware ( MOM ) is software- of hardware-infrastructuur die het verzenden en ontvangen van berichten tussen gedistribueerde systemen ondersteunt . MOM maakt het mogelijk applicatiemodules te distribueren over heterogene platforms en vermindert de complexiteit van het ontwikkelen van applicaties die meerdere besturingssystemen en netwerkprotocollen omvatten . De middleware creëert een gedistribueerde communicatielaag die de applicatieontwikkelaar isoleert van de details van de verschillende besturingssystemen en netwerkinterfaces. API's die zich over verschillende platforms en netwerken uitstrekken, worden doorgaans geleverd door MOM.

Met deze middleware-laag kunnen softwarecomponenten (applicaties, Enterprise JavaBeans, servlets en andere componenten) die onafhankelijk zijn ontwikkeld en die op verschillende netwerkplatforms draaien, met elkaar communiceren. Toepassingen die op verschillende netwerkknooppunten worden gedistribueerd, gebruiken de toepassingsinterface om te communiceren. Door een administratieve interface te bieden, kan dit nieuwe, virtuele systeem van onderling verbonden applicaties bovendien betrouwbaar en veilig worden gemaakt.

MOM biedt software-elementen die zich in alle communicerende componenten van een client/server-architectuur bevinden en die doorgaans asynchrone oproepen tussen de client- en servertoepassingen ondersteunen. MOM vermindert de betrokkenheid van applicatieontwikkelaars bij de complexiteit van het master-slave-karakter van het client/server-mechanisme.

Middleware-categorieën

Al deze modellen maken het mogelijk dat een softwarecomponent het gedrag van een andere component via een netwerk beïnvloedt. Ze verschillen doordat op RPC en ORB gebaseerde middleware systemen van nauw gekoppelde componenten creëren, terwijl op MOM gebaseerde systemen een losse koppeling van componenten mogelijk maken. In een op RPC of ORB gebaseerd systeem, wanneer de ene procedure een andere oproept, moet deze wachten tot de aangeroepen procedure terugkeert voordat deze iets anders kan doen. In deze modellen voor synchrone berichtgeving functioneert de middleware gedeeltelijk als een superlinker, die de aangeroepen procedure op een netwerk lokaliseert en netwerkservices gebruikt om functie- of methodeparameters door te geven aan de procedure en vervolgens om resultaten te retourneren.

Voordelen:

Centrale redenen om een op berichten gebaseerde communicatie protocol omvatten het vermogen om opslag (buffer), route of transformatie berichten terwijl ze transporteren van afzenders naar ontvangers.

Een ander voordeel van gemedieerde berichtenuitwisseling tussen clients door een berichtenprovider is dat u de prestaties kunt controleren en afstemmen door een beheerinterface toe te voegen. Clienttoepassingen worden dus effectief verlost van elk probleem, behalve dat van het verzenden, ontvangen en verwerken van berichten. Het is aan de code die het MOM-systeem implementeert en aan de beheerder om problemen zoals interoperabiliteit, betrouwbaarheid, beveiliging, schaalbaarheid en prestaties op te lossen.

asynchroniciteit

Met behulp van een MOM-systeem doet een klant een API-aanroep om een ​​bericht naar een door de provider beheerde bestemming te sturen. De oproep roept providerdiensten op om het bericht te routeren en af ​​te leveren. Nadat het bericht is verzonden, kan de klant doorgaan met ander werk, erop vertrouwend dat de provider het bericht bewaart totdat een ontvangende klant het ophaalt. Het op berichten gebaseerde model, gekoppeld aan de bemiddeling van de provider, maakt het mogelijk om een ​​systeem van losjes gekoppelde componenten te creëren.

MOM omvat een categorie communicatiesoftware tussen applicaties die over het algemeen vertrouwt op asynchrone berichtoverdracht , in tegenstelling tot een architectuur voor verzoek-antwoorden . In asynchrone systemen bieden berichtenwachtrijen tijdelijke opslag wanneer het doelprogramma bezet is of niet is verbonden. Bovendien bieden de meeste asynchrone MOM-systemen permanente opslag om een back-up te maken van de berichtenwachtrij. Dit betekent dat de zender en ontvanger niet tegelijkertijd verbinding met het netwerk hoeven te maken ( asynchrone levering ), en problemen met intermitterende connectiviteit worden opgelost. Het betekent ook dat als de ontvangertoepassing om welke reden dan ook faalt, de afzenders onaangetast kunnen blijven, omdat de berichten die ze verzenden zich eenvoudigweg ophopen in de berichtenwachtrij voor latere verwerking wanneer de ontvanger opnieuw wordt opgestart.

Routering

Veel berichtgeoriënteerde middleware-implementaties zijn afhankelijk van een berichtenwachtrijsysteem . Sommige implementaties maken het mogelijk dat routeringslogica wordt geleverd door de berichtenlaag zelf, terwijl andere afhankelijk zijn van clienttoepassingen om routeringsinformatie te leveren of een combinatie van beide paradigma's mogelijk te maken. Sommige implementaties maken gebruik van broadcast- of multicastdistributieparadigma 's.

transformatie

In een op berichten gebaseerd middlewaresysteem hoeft het op de bestemming ontvangen bericht niet identiek te zijn aan het oorspronkelijk verzonden bericht. Een MOM-systeem met ingebouwde intelligentie kan transformeren berichten en route naar de eisen van de afzender of van de ontvanger aan te passen. In combinatie met de routerings- en broadcast/ multicast- faciliteiten kan één applicatie een bericht in zijn eigen native formaat verzenden en kunnen twee of meer andere applicaties elk een kopie van het bericht in hun eigen native formaat ontvangen. Veel moderne MOM-systemen bieden geavanceerde tools voor berichttransformatie (of mapping) waarmee programmeurs transformatieregels kunnen specificeren die van toepassing zijn op een eenvoudige GUI- drag-and-drop- bewerking.

nadelen

Het voornaamste nadeel van veel message-georiënteerde middleware-systemen is dat ze een extra component in de architectuur nodig hebben , de message transfer agent ( message broker ). Zoals bij elk systeem kan het toevoegen van een ander onderdeel leiden tot verminderde prestaties en betrouwbaarheid, en kan het systeem als geheel ook moeilijker en duurder te onderhouden worden .

Bovendien hebben veel communicatie tussen applicaties een intrinsiek synchroon aspect, waarbij de afzender specifiek wil wachten op een antwoord op een bericht voordat hij verder gaat (zie realtime computing en near-realtime voor extreme gevallen). Omdat op berichten gebaseerde communicatie inherent asynchroon functioneert, past het misschien niet goed in dergelijke situaties. Dat gezegd hebbende, hebben de meeste MOM-systemen de mogelijkheid om een ​​verzoek en een antwoord te groeperen als een enkele pseudo-synchrone transactie.

Bij een synchroon berichtensysteem keert de aanroepende functie pas terug als de aangeroepen functie zijn taak heeft voltooid. In een losjes gekoppeld asynchroon systeem kan de aanroepende client doorgaan met het laden van werk op de ontvanger totdat de middelen die nodig zijn om dit werk af te handelen op zijn en het aangeroepen onderdeel faalt. Natuurlijk kunnen deze omstandigheden worden geminimaliseerd of vermeden door de prestaties te bewaken en de berichtenstroom aan te passen, maar dit is werk dat niet nodig is met een synchroon berichtensysteem. Het belangrijkste is om de voordelen en aansprakelijkheden van elk soort systeem te begrijpen. Elk systeem is geschikt voor verschillende soorten taken. Soms is een combinatie van beide soorten systemen nodig om het gewenste gedrag te verkrijgen.

normen

Historisch gezien was er een gebrek aan normen voor het gebruik van op berichten gerichte middleware, wat problemen heeft veroorzaakt. De meeste grote leveranciers hebben hun eigen implementaties, elk met zijn eigen Application Programming Interface (API) en beheertools.

Een van de al lang bestaande standaarden voor op berichten gerichte middleware is de XATMI-specificatie van de X/Open-groep (Distributed Transaction Processing: The XATMI Specification) die de API standaardiseert voor communicatie tussen processen . Bekende implementaties voor deze API zijn Enduro/X middleware van ATR Baltic en Tuxedo van Oracle .

De geavanceerde Message Queuing Protocol (AMQP) is een goedgekeurde OASIS en ISO-norm dat het protocol en -formaten tussen deelnemende applicatie componenten definieert, zodat implementaties interoperabel zijn. AMQP kan worden gebruikt met flexibele routeringsschema's, inclusief algemene berichtparadigma's zoals point-to-point , fan-out , publish/subscribe en request-response (merk op dat deze opzettelijk zijn weggelaten uit v1.0 van de protocolstandaard zelf, maar vertrouwen op de specifieke implementatie en/of het onderliggende netwerkprotocol voor routering). Het ondersteunt ook transactiebeheer, wachtrijen, distributie, beveiliging, beheer, clustering, federatie en heterogene ondersteuning voor meerdere platforms. Java-applicaties die AMQP gebruiken, zijn meestal geschreven in Java JMS. Andere implementaties bieden API's voor C#, C++, PHP, Python, Ruby en andere talen.

De High-Level Architecture (HLA IEEE 1516) is een IEEE- en SISO- standaard voor simulatie-interoperabiliteit. Het definieert een reeks services, geleverd via een API in C++ of Java. De diensten bieden op publiceren/abonneren gebaseerde informatie-uitwisseling, gebaseerd op een modulair Federation Object Model. Er zijn ook diensten voor gecoördineerde gegevensuitwisseling en tijdvervroeging, gebaseerd op logische simulatietijd, evenals synchronisatiepunten. Aanvullende diensten bieden eigendomsoverdracht, optimalisatie van gegevensdistributie en monitoring en beheer van deelnemende federaties (systemen).

De MQ Telemetry Transport (MQTT) is een ISO-standaard (ISO/IEC PRF 20922) die wordt ondersteund door de OASIS-organisatie. Het biedt een lichtgewicht publiceren/abonneren betrouwbaar berichtentransportprotocol bovenop TCP/IP dat geschikt is voor communicatie in M2M/IoT-contexten waar een kleine codevoetafdruk vereist is en/of netwerkbandbreedte van groot belang is.

De Object Management Group 's Gegevens Distribution Service (DDS) levert bericht georiënteerde publish / subscribe (P / S) middleware standaard die streeft naar schaalbare, real-time, betrouwbare, hoge prestaties en interoperabele uitwisseling van gegevens tussen uitgevers en abonnees mogelijk te maken. De standaard biedt interfaces voor C++, C++11, C, Ada, Java en Ruby.

Het eXtensible Messaging and Presence Protocol ( XMPP ) is een communicatieprotocol voor berichtgeoriënteerde middleware op basis van XML (Extensible Markup Language). Het protocol is ontworpen om uitbreidbaar te zijn en is ook gebruikt voor publicatie-abonneersystemen, signalering voor VoIP, video, bestandsoverdracht, gaming, Internet of Things-toepassingen zoals het smart grid en sociale netwerkdiensten. In tegenstelling tot de meeste instant messaging-protocollen, is XMPP gedefinieerd in een open standaard en gebruikt het een open systeembenadering van ontwikkeling en toepassing, waardoor iedereen een XMPP-service kan implementeren en kan samenwerken met implementaties van andere organisaties. Omdat XMPP een open protocol is, kunnen implementaties worden ontwikkeld met elke softwarelicentie; hoewel veel server-, client- en bibliotheekimplementaties worden gedistribueerd als gratis en open-source software, bestaan ​​er ook tal van freeware en propriëtaire software-implementaties. De Internet Engineering Task Force (IETF) heeft in 2002 een XMPP-werkgroep opgericht om de kernprotocollen te formaliseren als een IETF-technologie voor instant messaging en aanwezigheid. De XMPP-werkgroep produceerde vier specificaties (RFC 3920, RFC 3921, RFC 3922, RFC 3923), die in 2004 werden goedgekeurd als voorgestelde standaarden. In 2011 werden RFC 3920 en RFC 3921 vervangen door respectievelijk RFC 6120 en RFC 6121, met RFC 6122 specificeert het XMPP-adresformaat. Naast deze bij de IETF gestandaardiseerde kernprotocollen, is de XMPP Standards Foundation (voorheen de Jabber Software Foundation) actief in het ontwikkelen van open XMPP-extensies. Op XMPP gebaseerde software wordt volgens de XMPP Standards Foundation op grote schaal op internet ingezet en vormt de basis voor het Unified Capabilities Framework van het Department of Defense (DoD).

De Java EE- programmeeromgeving biedt een standaard API genaamd JMS (Java Message Service), die door de meeste MOM-leveranciers wordt geïmplementeerd en tot doel heeft de specifieke MOM API-implementaties te verbergen; JMS definieert echter niet het formaat van de berichten die worden uitgewisseld, dus JMS-systemen zijn niet interoperabel.

Een soortgelijke inspanning is met het actief evoluerende OpenMAMA- project, dat tot doel heeft een gemeenschappelijke API te bieden, met name aan C-clients. Op dit moment (augustus 2012) is het echter vooral geschikt voor het verspreiden van marktgerichte gegevens (bijvoorbeeld aandelenkoersen) via pub-submiddleware.

Berichtenwachtrij

Zie ook: Berichtenwachtrijservice

Berichtenwachtrijen maken de uitwisseling van informatie tussen gedistribueerde toepassingen mogelijk. Een berichtenwachtrij kan zich in het geheugen of op schijfopslag bevinden. Berichten blijven in de wachtrij staan ​​totdat ze worden verwerkt door een servicegebruiker. Via de berichtenwachtrij kan de applicatie onafhankelijk worden geïmplementeerd - ze hoeven elkaars positie niet te kennen, of doorgaan met het implementeren van procedures om te voorkomen dat ze hoeven te wachten om dit bericht te ontvangen.

Trends

Zie ook

Referenties

Externe links