Archive for March, 2013

Introducing Service Bus

Posted: March 9, 2013 in Windows Azure

Service Bus is a software model, a middleware, that is mainly used with WCF or SOA to handle and loosens all the coupled messaging between all the applications required. There are 2 types of Service Bus, the one running on Windows Azure and the one that can run on the local servers which we call Enterprise Service Bus.

To clarify more what Service Bus can do, it can work with different applications, reach them and interact with them regardless of the different mechanism they work with.

Here is a video from Channel 9 that clarifies more the concept of EAI and What Service Bus can do.

For the Windows Azure Service Bus, it provides REST, relayed and brokered messaging capabilities for the Messaging, connecting the applications running on premises with the ones running on Windows Azure and finally works also for the mobile devices push notifications.

For more information about the Windows Azure Service Bus Relayed Messaging you can go to the following link and for more information about the Windows Azure Service Bus Brokered Messaging you can find it in the following link.

So why people use the Service Bus?

  • It can be used for delivering messages to multiple connectors or endpoints.
  • Simplify the integration between multiple applications as each one of them is using different connector with different way of integration.
  • Ensure the delivery of the messaging to the applications.

As for the Service Bus, the Windows Azure
middleware solving the EAI (Enterprise application integration), here is the first way to do the messaging using the Relayed Messaging. Let me first explain what does Relayed Messaging means.

Here are the 3 ways of messaging using the Relay messaging:

  • Direct one way messaging
  • Request/response messaging
  • Peer to Peer messaging

For the Binding there are several ways of bindings, certainly that matches all the different ways of Relay Messaging.

  • TCP Relay Binding know as: NetTcpRelayBinding
  • WS Relay Binding know as: WSHttpRelayBinding
  • One Way Relay Binding known as: NetOneWayRelayBinding
  • Event Relay Binding Known as: NetEventRelayBinding

Now starting for the first type of binding the TCP Relay Binding. Actually this type of binding has also three types of binding mode:

  • Relay
  • Direct
  • Hybrid

Each one of them has a specific time to be used in, however there are some people who always go for the easiest one which is the hybrid but I have to clarify all of them. The TCP Relay binding mode “Relay” is used when you are connecting the service and the client through the service itself. First of all the Service has to authenticate itself in the service bus, the clients too has to authenticate itself to the service then it can sends the required message to the service. At the end, the service would be able to send the required message to the client.

The second TCP Relay Binding mode “Direct”, this mode is used for establishing direct connections between the client and the service without having any needs to use the service or passing by it. Like the Relay mode the Service has to authenticate itself, then the client too after that service bus will show them, the client and the service how they can establish connection between them and communicate directly. Working on the Message Security is a must.

The third TCP Relay Binding mode “Hybrid”, from its name you can get that it is a mix from the 2 other modes the Relay and the Direct. Well it is a Yes, like the two other services the authentication for the client and the service has to be done first after that the initialized mode is the relayed. The second step is to check if the direct mode could be achieved successfully, if yes than the switch will be done automatically otherwise the binding will remain the same. Also working on the security is a must.

PS: the TCP Relay Binding is not interoperable, in other words it always assume that the other side is using the same binding so it doesn’t work with other bindings.

Now with the Second type of binding the WSHttpRelayBinding, this one is easier than the NetTcpRelayBinding, it is interoperable, can work with different kind of binding running on the other side over HTTP and HTTPS protocols.

The third type is the NetOneWayRelayBinding, this type of binding doesn’t work like the others, it is a bit different, and although it has some drawbacks like you may face some problems delivering its messages but it is most commonly used when you cannot be sure of the current status of the Service.

The Fourth and last type of binding is the NetEventRelayBinding, this one is commonly used when you are targeting to distribute your message along multiple clients. In case like the above, the service must be connected using the NetEventRelayBinding but the client will have the option to connect using one of the two bindings, the NetEventRelayBinding or the NetOneRelayBinding.

In the following link you can learn step by step how to create Service Bus Relayed Messaging.

For better understanding how Service Bus Relay Messaging works, you can find more about it in this article, one of my resources.

As for the Service Bus, the Windows Azure middleware solving the EAI (Enterprise application integration), here is the second way to do the messaging using Brokered Messaging. Clarifying what Brokered Messaging means.

The Brokered Messaging is a durable, asynchronous messaging that has several ways to achieve this like the “Queues”, the “Topics and Subscriptions”, in a way that the senders and the receivers don’t have to be online when the message is send to receive it.

Starting first with the Queues, this way of communication can be used to make the connection between two points, it is totally like the Point-to-Point messaging. For the queues, it is like any normal queue data structure, or like the Windows Azure Queue storage (all the predefined .net functions) the first message sent is the first is to be received by the receiver (FIFO). This feature also works If you do have several receivers of the message through the Service bus.

Our Next Brokered Messaging way is the Topics and the Subscriptions, for the users, they can subscribe to a specific topic and after that can easily get all the messages sent through the service bus related to the subscribed topic.

Along with the increasing number of the business needs and the new software and applications they get to always meet their customers’ satisfaction and to increase their system’s reliability. An integration between all these applications and software is a must, so they can monitor their systems and the transactions made more easily and efficiently.

The main challenge always reside in how these multiple applications can communicate each other? The answer would be easy, it is SOA (service Oriented Architecture), well it is a yes and no. Yes because all these connections have to go through the SOA but no because SOA is not enough and need few more things to ensure its reliability. The way of the Messaging between the applications which is most probable the point to point integration. This will certainly oblige us to have a deeper look at the way the communication between the apps is done, the middleware. If we are talking about a small IT infrastructure where two or three applications needs to be connected then the point to point messaging would work more than great, but with the increasing number of connectors, you will face certainly a high degree of complexity and would not be able to manage all the connectors effectively.

Well the solution for EAI is quite simple, is building a middleware that manages all the connectors, loosens the coupled connections, which lead me to the Service Bus.

For more information about EAI or Enterprise application integration, you can check the following link on MSDN, it also has several lessons that can help you with it, it is a complete scenario using BizTalk Server.

What is Middleware?

Posted: March 7, 2013 in Windows Azure

If you go to a dictionary to check on the “middleware” you will find this:” Software that manages the connection between a client and a database“. Actually a middleware does more than that, let’s first understand what any operating system must deliver to a developer. Actually they are two main things, the CPU and the Memory. The processor so the developer can execute the instructions for his applications and the memory so the developer can use it to store the required data. For nowadays, the applications require more than that especially for the applications that are designed to serve a special purpose for the enterprises.

The middleware here provides a way of connectivity between the applications like the messaging services. The Messaging service allows programs to share common messages handling code. In other words, the middleware is anything the developer can get to build applications using the networks.

You can find the middleware in your application connecting to the database, the way several applications can communicate with each other even if they are hosted on different hardware resources and on different operating system. You can always find it in the EAI (enterprise application integration) systems