A message broker in an enterprise is basically a message-oriented middleware, which is used for sending messages between two or more clients. In a simple mechanism, it's basically an implementation support for the producer and consumer pattern. In general, they provide one-to-one communication (point-to-point/queues) and one-to-many communication (publish-subscribe/topics) as well.

Message broker promotes loose coupling, and enables asynchronous communication within distributed applications.

Some implementations use TCP as the underlying data transfer protocol, while others also give provisions for UDP, Multicasts, and hybrids. Data types for payload that are commonly available include string, binary, XML, and JSON along with the options to enable compression.

There are some brokerless messaging approaches, but those are not found commonly in SOA platforms.

Some of the message brokers in the market include IBM's WebSphere MQ, Microsoft's MSMQ, Oracle's Service Bus, and TIBCO's EMS besides many others. As an example, let's look at some of the highs and lows of MSMQ. Note that these points are just for demonstration, and in no way give an exhaustive product evaluation.

The highs for MSMQ are as follows:

• Built-in Microsoft Windows (infrastructure)
• No need to pay extra if you have a Windows server license (cost)
• Active Directory Integration (security)
• Libraries already present with .NET Framework (not with .NET Core as of now)
• Transaction support (integrity)

The lows for MSMQ are as follows:

• Not so popular in bigger enterprises (popularity here might be related to reliability, and the number of use cases supported)
• Limitations on the size of message and queue (limitations for big-sized message flow)
• Not a cross-platform product
• A newer product, Azure Service Bus, is now a better alternative