SQL Server Service Broker provides native support for messaging and queuing in the SQL Server Database Engine.
In a post on Hacker News, a user named rusanu states:
Having spent 7 years of my life working with Pat Helland in implementing Exactly Once In Order messaging with SQL Server Service Broker I can assure you that practical EOIO messaging is possible, exists, and works as advertised. Delivering data EOIO is not rocket science, TCP has been doing it for decades. Extending the TCP paradigms (basically retries and acks) to messaging is not hard if you buy into transacted persisted storage (= a database) for keeping undelivered messages (transmission queue) and storing received messages before application consumption (destination queue). Just ack after you commit locally.
The article SQL Server Service Broker demystified states:
There is one temporary queue on every SQL Server instance, called the transmission_queue. When a message is sent over a network, Service Broker puts the message in this queue, on the initiator server. Then, the Service Broker sends the message over the network and marks it as waiting for acknowledgement in the transmission_queue. When the message is received in the target queue, Service Broker sends an acknowledgement back to the initiator. When this acknowledgement is received, the message is deleted from the transmission_queue.
Although this approach isn't as bad as using persistent message brokers, it is still unnecessarily complex and inefficient. Implementing a persistent version of TCP (e.g. with persistent transmission queues) isn't necessary.