Difference between message bus and message broker

what's the difference between a message bus[1] and a message broker[2]

• Both is middleware for applications
• Both can be used to decouple various systems
• Both can have a canonical data model
• Both route messages and could offer other features such as data transform

As i see, the only relevent difference is the picture used to represent each of one..

If there's some difference between then, please tell-me what.
If they are the same, plese tell-me why two concepts to refer the same functionality.

Thanks.

[1] http://www.eaipatterns.com/MessageBus.html
[2] http://www.eaipatterns.com/MessageBroker.html

The message bus implies a common protocol spoken and understood by all participants. There is little to no logic in the bus. Usually the message is forwarded to all connected systems.

The hub-and-spoke architecture (or "message broker") has a central piece of software which understands the messages sent to it, can translate them, and forward them to the systems which need the information.

First recognize that these are made-up terms adopted from existing metaphors, like most domain-specific terms are. Nobody has the authority to define them, rather we are just making this stuff up as we (the industry) goes along.

The broker metaphor works nicely with a hub-and-spoke layout. The bus metaphor works better in a direct addressing situation. What is stopping your client from sending a message to one of a number of brokers sitting on the bus, hub-spoke or otherwise? The definitions of the metaphors starts to get a bit silly.

Figure out what you want to do and choose a product that does it best -- hint: it's probably going to provide features of both so-called bus or broker technologies.

Nice explanation on mulesoft on the differences between Message Broker and Enterprise Service Bus -

https://www.mulesoft.com/resources/esb/enterprise-application-integration-eai-and-esb

Quote from the article: " Enterprise Bus: ...While it (i.e Message Broker) is still used a central routing component to pass messages from system to system, the bus architecture sought to lessen the burden of functionality placed on a single component by distributing some of the integration tasks to other parts of the network.

These components could then be grouped in various configurations via configuration files to handle any integration scenario in the most efficient way possible, and could be hosted anywhere within the infrastructure, or duplicated for scalability across large geographic regions."

According to Udi Dahan’s lessons (the guy that invented NServiceBus): “.. the bus architectural style [is] orthogonal to the broker architectural style. Brokers tend to be more aligned with [technical] system boundaries [one system is an iOS mobile app built by one team, another system is the Java backend built by another team, ..]. Services and the bus architectural style are orthogonal/crosscutting to many of how the systems are build”. (Nowadays, you often build a particular service by one team following DDD. A service provides business capabilities of a particular bounded context, e.g., a payment services that could be used by the iOS app or the backend).

https://learn.particular.net/courses/take/DDDEU-explorers-offer/lessons/9737385-services-modelling-workflows-boundaries-and-business-capabilities