There are a number of common scenarios where people have taken an interest in the AppFx.ServiceBus framework. These include:

New to Hybrid integration patterns

Some companies are new to the hybrid integration pattern and they may want a low cost quick way to integrate Azure Service Bus queues and topics into their existing applications. Often it would be costly to modify these applications to be able to work directly with the service bus. Using AppFx.ServiceBus as an on-premise host these companies are able to write message handlers to integrate the AppFx.ServiceBus host with their existing on premise applications and expose them to the cloud.

An example of this might be writing a message handler to map and forward a message to an existing web service.

Small organisations who don't have an integration server

Often smaller organisations don't have the resources to purchase and implement one of the common integration server technologies. AppFx.ServiceBus should allow your existing .net developers to be able to leverage this cloud messaging capability into the existing applications at very low cost.

You have an old version of BizTalk

Although we believe BizTalk 2013 will offer one of the best platforms to integrate on-premise applications to the cloud a lot of customers have older versions of BizTalk which do not have the capability to easily integrate with the cloud. Using AppFx.ServiceBus to poll the Azure Service Bus and then forward these messages onto BizTalk is a way these customers can easily extend their existing assets to the cloud while giving them time to upgrade BizTalk later.

Your doing Cloud to Cloud Integration

AppFx.ServiceBus can easily be hosted in a Windows Azure Worker Role to act as a listener for messages from Windows Azure Service Bus. This provides a great hosting capability for cloud to cloud messaging. One example where this kind of pattern may be used would be if you had an application like Dynamics CRM Online. You could have a worker role hosting AppFx.ServiceBus listen to queues or topics for messages and then your message handlers could encapsulate the interaction with the CRM API to get or persist data. This would allow you to implement a "pull" integration model for sending data to SAAS applications.

Im sure as this project evolves we will see many other use cases.

Last edited Feb 24, 2013 at 7:09 AM by michaelstephenson, version 3


No comments yet.