Sonic ESB

01 Jun 2009 by Keith Elder

Sonic

Sonic ESB

Sonic ESB was our Enterprise messaging system until replaced by Universal Messaging in 2015. Sonic integrated with AMP and LOLA. It was the only way for us to reliably get data in and out of those systems at the time. It was selected as our messaging system because Sonic was purchased by Progress, the makers of OpenEdge and the 4GL language that AMP/LOLA are powered by.

Selection Process

As part of the selection process we explored other options at the time including Microsoft BizTalk. Because BizTalk didn't integrate with OpenEdge software the selection process was easy.

Standardizing Messaging

Dot Net applications needed to communicate with Sonic. They had to reliably connect to Sonic, listen for messages, and process them.

I started working to integrate Sonic support into Rock.Framework with a new namespace called Rock.Framework.Messaging. Sonic was written in Java but they did provide .NET APIs.

The APIs developed for Rock.Framework.Messaging were used through all .NET applications to send and receive messages throughout the Enterprise. This work paved the way for QTweets to exist and to be leveraged, of which I was also involved with early on.

Today, this portion of the API has been removed but still viewed in archive as we no longer leverage Sonic. However, the design implemented in those early days of Rock Framework is still followed today for RockLib (our open source framework) and has been extended to support multiple messaging products including SQS and Universal Messaging.

API Examples

using (var producer = MessagingScenarioFactory.CreateQueueProducer("QueueName"))
{
    var message = "Some Message to Queue";
    
    await producer.SendAsync(message);
}

using (var producer = MessagingScenarioFactory.CreateQueueProducer("QueueName"))
{
    var message = "Some Message to Queue;
    var senderMessage = new StringSenderMessage(message);
    senderMessage.Headers.Add("Format", "Json");
    senderMessage.Headers.Add("ModelType", SomeType.GetType().FullName);

    await producer.SendAsync(senderMessage);    
}

In both examples above the code is creating and then destroying the ISender. The process of creating the ISender can be expensive, if you are going to be sending a high volume of messages it may make the most sense to create a singleton instance for the given queue (ISender) to allow it to be used multiple times.

private IReceiver _amazonOrderReceiver;

public void Listen()
{
    // This creates the IReceiver
    // When creating your Queue Consumer make sure you provide the name of the queue to listen to.  This needs to match your name from your app.config/web.config file
    _amazonOrderReceiver = MessagingScenarioFactory.CreateQueueConsumer("QUEUE_NAME");

    // Setup the Message Received callback (see below)
    _amazonOrderReceiver.MessageReceived += OnMessageReceived;

    // Start the listener
    _amazonOrderReceiver.Start();
}