As part of the December 2011 Labs of Service Bus we are adding a brand-new set of EAI (Enterprise Application Integration) capabilities which includes bridges (commonly referred to as pipelines), transforms, and hybrid connectivity. We will go through the full set of capabilities over a series of blog posts but let us start by discussing EAI bridges and the basic concepts behind it. This post will explain the need for bridges and show how to configure & deploy a simple XML bridge and send messages through it.

The term ‘bridge’ immediately reminds us of something which connects two end points. In the context of information systems here we are talking about a bridge connecting two or more disparate systems. Let us understand this better with a sample scenario. Consider a scenario within an organization wherein the employee management system and the HR system interacts with the payroll system whenever a new employee is inducted or the details for an employee changes such as the bank account. The employee mgmt and the HR system can be disparate systems such as in SQL, Oracle, SAP or so on.

These systems will interact with the payroll system (by exchanging messages) in formats they understand. The payroll system being a separate unit can be implemented using a third infrastructure. These systems need to be connected in a way that they can continue to use their respective message formats but still be able to communicate with each other. Whenever the payroll system receives a message from the other two systems, it would perform a common set of operations. These set of operations can be consolidated to into a common unit called a bridge.

Why Bridge?

Protocol Bridging

Consider a scenario wherein application 1 wishes to talk to application 2. However application 1 sends messages only using REST/POX protocol though application 2 can receive messages over SOAP protocol only. To make this happen one of the applications needs to be modified to talk in a format which the other application understands which is costly exercise and in most cases an unacceptable solution. This scenario can be solved easily by using a bridge as a mediator. The bridge will accept messages over REST/POX but will send them out over SOAP. A bridge helps in appropriately connecting two applications which are over different protocols. 

Structural Normalization or Data Contract Transformation

In the below diagram, application on the left is sending messages in a particular structure. The receiving application requires the same data in another structure. A structural transformation needs to occur between the two so that they can communicate with each other. A bridge can help in achieving this structural normalization/transformation.

This situation can be further expanded into a scenario where multiple disparate applications are sending messages to a particular application. The receiving application/process can prepend a bridge to it which normalizes all incoming messages into a common format which it understands and do the vice-versa for the response message. This process is commonly is referred to as canonicalization.

Message / Contract Validation

Consider a simple situation wherein a process/application wishes to allow only messages that conform to one or more formats to come in and reject all else. To achieve this, one may need to write complex and costly validation logic. Using an EAI bridge, this can be achieved with some very basic configuration steps. The bridge can validate all incoming messages against one or more schemas. Only if the message conforms to one of the provided schemas, the message is sent to the application. Otherwise it is rejected and an appropriate response is sent to the message sending application/client.

Content based routing

Many a time we see that an application needs to route messages to another application based on the message metadata/context. For example, in a loan processing scenario if amount > $10,000, send the message to application1, otherwise send it to application2. This content-based-routing can be done using a bridge. A bridge helps in achieving this by using simple routing rules on the outgoing message metadata. The message can be sent to any end point/application, be it on the cloud or on-premise.

Though we talked about each of the above capabilities individually they rarely occur in isolation. One can combine one or more of the above and solve them using one or more EAI bridges. Bridges can also be chained or used in parallel as per the requirement and/or to achieve modularity and easy maintainability.

Configuration, Deployment, and Code

Signing up for a Service Bus account and subscription

Before you can begin working with the EAI bridges, you’ll first need to sign-up for a Service Bus account within the Service Bus portal. You will be required to sign-in with a Windows Live ID (WLID), which will be associated with your Service Bus account. Once you’ve done that, you can create a new Service Bus Subscription. In the future, whenever you login with your WLID, you will have access to all of the Service Bus Subscriptions associated with your account.

Creating a namespace

Once you have a Subscription in place, you can create a new service namespace. You’ll need to provide a new and unique service namespace across all Service Bus accounts. Each service namespace acts as a container for a set of Service Bus entities. The screenshot below illustrates what the interface looks like when creating the “Harish-Blog” service namespace.

Further details regarding account setup and namespace creation can be found in the User Guide accompanying the Dec CTP release here.

Configuring and deploying a bridge

One can configure a bridge using a simple UI designer surface we have provided as part of Microsoft Visual Studio. To enable this experience download the SDK from here. After installing the SDK go to Visual Studio and create a new EAI project which you can find under Visual C# -> ServiceBus. After this follow the steps mentioned here (for XML One-Way Bridge) or here (for XML Request-Reply Bridge) to configure and deploy a bridge. 

The below snapshot shows a one way bridge (bridge1) connected to a Service Bus queue (Queue1), a Service Bus relay (OneWayRelay1) and a one way service hosted in Cloud (OneWayExternalService1). A message coming to a bridge will be processed and routed to one of these 3 end points.

The below snapshot shows the various stages involved in a request-response bridge and forms the surface from where the bridge can be configured:

Sending messages to a bridge

After configuring and deploying a bridge it is now time to send messages to it. You can send messages to a bridge using a simple web client or a WCF client. Also it can be sent over REST/POX or SOAP. As part of the samples download we have provided sample clients which you can use to send messages. Download the samples from here to use these message sending clients.

Wrapping up and request for feedback

Hopefully this post has shown you how to get started with EAI bridges capability being introduced in the new Dec CTP of Service Bus. We’ve only really seen the tip of the iceberg here. We’ll go in to more depths and capabilities in future posts.

Finally, remember one of the main goals of our CTP release is to get feedback on the service and its capabilities. We’re interested to hear what you think of these integration features. We are particularly keen to get your opinion on the configuration and deployment experience for a bridge, and the various other features we have so far exposed as part of it.

For other suggestions, critique, praise, or questions, please let us know at our Labs forum. Your feedback will help us improve the service for you and other users like you.