wat is het verschil tussen een berichtenbus[1] en een berichtenmakelaar[2]
- Beide is middleware voor applicaties
- Beide kunnen worden gebruikt om verschillende systemen te ontkoppelen
- Beide kunnen een canoniek datamodel hebben
- Beide routeberichten en kunnen andere functies bieden, zoals gegevenstransformatie
Zoals ik zie, is het enige relevante verschil de afbeelding die wordt gebruikt om elk van hen weer te geven.
Als er een verschil is tussen dan, vertel me dan wat.
Als ze hetzelfde zijn, vertel me dan waarom twee concepten naar dezelfde functionaliteit verwijzen.
Bedankt.
[1] http://www.eaipatterns.com/MessageBus.html
[2] http://www.eaipatterns.com/MessageBroker.html
Antwoord 1, autoriteit 100%
De berichtenbus impliceert een gemeenschappelijk protocol dat door alle deelnemers wordt gesproken en begrepen. Er zit weinig tot geen logica in de bus. Meestal wordt het bericht doorgestuurd naar alle aangesloten systemen.
De hub-and-spoke-architectuur (of “message broker”) heeft een centraal stuk software dat de berichten begrijpt die ernaar worden verzonden, deze kan vertalen en doorsturen naar de systemen die de informatie nodig hebben.
Antwoord 2, autoriteit 17%
Erken eerst dat dit verzonnen termen zijn die zijn overgenomen van bestaande metaforen, zoals de meeste domeinspecifieke termen. Niemand heeft de autoriteit om ze te definiëren, maar we verzinnen dit soort dingen gewoon terwijl wij (de industrie) meegaan.
De broker-metafoor werkt goed met een hub-and-spoke-lay-out. De busmetafoor werkt beter in een directe adresseringssituatie. Wat houdt uw klant tegen om een bericht te sturen naar een van de vele makelaars die in de bus zitten, hub-spoke of anderszins? De definities van de metaforen beginnen een beetje dwaas te worden.
Bepaal wat u wilt doen en kies een product dat dit het beste doet — hint: het zal waarschijnlijk functies bieden van zowel zogenaamde bus- als brokertechnologieën.
Antwoord 3, autoriteit 6%
Leuke uitleg op mulesoft over de verschillen tussen Message Broker en Enterprise Service Bus –
https://www.mulesoft.com/ resources/esb/enterprise-application-integration-eai-and-esb
Citaat uit het artikel: ” Enterprise Bus: …Hoewel het (dwz Message Broker) nog steeds wordt gebruikt als een centrale routeringscomponent om berichten van systeem naar systeem door te geven, probeerde de busarchitectuur de last van functionaliteit die op een enkele component door een deel van de integratietaken te verdelen over andere delen van het netwerk.
Deze componenten kunnen vervolgens via configuratiebestanden in verschillende configuraties worden gegroepeerd om elk integratiescenario op de meest efficiënte manier af te handelen, en ze kunnen overal binnen de infrastructuur worden gehost, of worden gedupliceerd voor schaalbaarheid over grote geografische regio’s.”
Antwoord 4
Volgens de lessen van Udi Dahan (de man die NServiceBus uitvond): “.. de bouwstijl van de bus [is] orthogonaal aan de bouwstijl van de makelaar. Makelaars zijn meestal meer afgestemd op [technische] systeemgrenzen [het ene systeem is een mobiele iOS-app gebouwd door het ene team, het andere systeem is de Java-backend gebouwd door een ander team, ..]. Diensten en de bouwstijl van de bus zijn orthogonaal/transversaal voor veel van hoe de systemen zijn gebouwd”. (Tegenwoordig bouw je vaak een bepaalde service door één team na DDD. Een service biedt zakelijke mogelijkheden van een bepaalde begrensde context, bijvoorbeeld een betalingsservice die kan worden gebruikt door de iOS-app of de backend).