Archive for March, 2013

This is the fourth type of binding after the NetOnewayRelayBinding, WSHttpRelayBinding and NetTcpRelay Binding, one of the binding of the Windows Azure Service bus. I previously introduced the Windows Azure Relay Binding with a small introduction about each binding. In this post you will be able to understand better how the NetEventRelayBinding Namespace work. This binding doesn’t have another equivalent in the .Net framework, it is a derivation of the NetOnewayRelayBinding.

The point of the NetEventRelayBinding is that it allows multiple clients or services to register to the same service bus and when a message is sent, it sends it to all the service subscribers. Like the NetOnewayRelayBinding the NetEventRelayBinding scheme is “sb”.

Its main drawbacks is that you cannot be sure if the message is delivered to all the clients or the service bus subscribers. Currently there are some constraints about the number of the concurrent users or services subscribing to the service, they cannot exceed 20 and the message sent to the listeners also cannot exceed 60 KB.

This is the third type of binding after the WSHttpRelayBinding and NetTcpRelayBinding, one of the binding of the Windows Azure Service bus. I previously introduced the Windows Azure Relay Binding with a small introduction about each binding. In this post you will be able to understand better how the NetOneWayRelayBinding class works. This doesn’t have any equivalent ways of binding in the .Net framework.

Actually the NetOneWayRelayBinding is one of the most complicated bindings, for a simple reason that it is a only an one way communication binding through the Cloud Computing. Like the WSHttpRelayBinding it uses the SOAP 1.2 over the TCP. For its URI Scheme, it is usually the “sb”.

When using this type of binding, an automatically binding is created using the TCP connection or a TCP/SSL connection. This type of binding can be done through the application configuration.

Service Bus WSHttpRelayBinding

Posted: March 18, 2013 in WCF, Windows Azure

This is the fourth type of binding after the NetTcpRelayBinding, one of the binding of the Windows Azure Service bus. I previously introduced the Windows Azure Relay Binding with a small introduction about each binding. In this post you will be able to understand better how the WSHttpRelayBinding Namespace work. The WSHttpRelayBinding is nearly like the WsHttpBinding used in the .Net framework.

For the WsHttpBinding, it was available with the WCF 3.0. It is basically based on the SOAP 1.2 and enables more features like asynchronous messaging, message correlation, and transport-neutral addressing mechanisms which for sure adds some processing overhead, plus the support of both the transport level (SSL) and the message level (WS-Security).

The differences between the WSHttpRelayBinding and the WsHttpBinding is the creation and the control of a desirable creation of an endpoint on Windows Azure where you have the option to make it discoverable too.

For the URI Scheme, it doesn’t work as the NetTCPRelayBinding but you have to make the URI Scheme to “HTTP” or “HTTPS”

Unlike the NetTcpRelayBinding, the WSHttpRelayBinding is an interoperable binding. No matter what type of binding the other clients are using it works with them normally over the HTTP and the HTTPS protocols.

The WS2007HttpRelayBinding is the update of the WSHttpRelayBinding in several fields, like the security and the reliable session which I will certainly cover in a later blog posts.

Service Bus NetTcpRelayBinding

Posted: March 17, 2013 in WCF, Windows Azure

This is one of the first binding of the Windows Azure Service bus. I previously introduced the Windows Azure Relay Binding with a small introduction about each binding. In this post you will be able to understand better how the NetTcpRelayBinding Namespace work. The NetTcpRelayBinding is similar to the NetTcpBinding.

This type of binding the NetTcpRelayBinding supports three types of connection modes, whether hybrid, Relay or Direct. Let’s talk first about the process then we can talk on the differences.

Usually the service registers itself in the service bus, the clients too register themselves in the service bus. Certainly these things are done programmatically. After that the processes differ depending on the connection mode. If the connection mode is a Relay connection then all the next processes go through the service itself, if the connection mode is a direct then a direct connection between the client and the service is established without passing by the service bus. For the Hybrid connection mode, the connection mode starts as relay and then see if the direct connection is feasible to be done or not, if yes then it will change to direct if not then it will remain relay.

Depending on the connection mode, you will then have to decide if the message security is needed or not yet. Which mean if you are using relay connection mode, you won’t need to work on the security message because the connection will always go through the service itself but otherwise when the clients connect automatically or in a hybrid way, you will certainly need to work on the Message security.

The NetTcpRelayBinding is a faster way of communication than the other way of Bindings like the WSHttpRelayBinding.

For more information about securing the Service Bus using the .Net, you will find all the details in the following blog post.

For the clients, services and any other different service bus user using the NetTcpRelayClient, you have to know that the URI scheme must be “sb”. All what is related to the binding, security and endpoints can be found in the application configuration file. It looks like the following:

<endpoint name=”RelayEndpoint”

contract=”Microsoft.ServiceBus.Samples.IMyContract”

binding=”netTcpRelayBinding”

bindingConfiguration=”default”

behaviorConfiguration=”ReplaceWithEndpointBehaviorName”

address=”ReplaceWithEndpointAddress” />

If you are working with the NetTcpRelayBinding, you have to make sure that both the sender and the receiver or all the service clients have the same bindings because other ways they won’t be able to communicate to each other for simple reason that the NetTcpRelayBinding is not interoperable.

In this blog I will focus mainly on the .Net platform, you can find all the related classes for the Service Bus Brokered Messaging in the following namespaces: Microsoft.ServiceBus and Microsoft.ServiceBus.Messaging

As you may know that based on my previous blog post about the Windows Azure Service Bus Brokered Messaging that mainly works using queues or topics and subscriptions. To work with the Service Bus Brokered Messaging you have to be well familiar with the Microsoft.ServiceBus.Messaging namespace because all the related functions is in this namespace, for the Relayed Messaging, most of its classes and functions will be in Microsoft.ServiceBus namespace.

Let me introduce you the main classes that you will certainly have to use during the development:

  • BrokeredMessage:

    it is the unit that communicate the service bus clients together. Like the storage you will have to identify the type of your client whether it was the queue, topic or a subscription client.

  • NamespaceManager:

    The NamespaceManager is what is responsible for runtime of the operations of the service bus messaging entities from inserting, creating, deleting and so on.

  • MessagingFactory

    The lifecycle of the messaging is tracked, monitored and totally handled by the Messaging Factory.

Now let’s start understanding the Brokered Message API using the Queue. You can find a small demo about it in the following link. If you are using the queue here are the main classes related:

  • QueueClient: that’s what represents the object responsible for the communication between the service bus
  • QueueDescription: this is what represents the metadata related

Talking about the next type of Windows Azure Service Bus Brokered Relay, the Topic & Subscription. They will always consume the same classes as the Queue like the BrokeredMessage, the NamespaceManager and the MessagingFactory. Adding to those, the specified clients:

  • TopicClient

    This is the object responsible of sending the data to the service bus client subscriber to the specified topic.

  • TopicDescription

Metadata about the service bus topic.

  • SubscriptionClient

    This is the object responsible of receiving the brokered message from the service bus depending in the subscribed topic.

  • SubscriptionDescription

    Metadata about a specified service bus subscription.

For better understanding all about the Microsoft.ServiceBus .Net class, I would recommend you download the following document. For the Brokered Messaging class, I would recommend you go through the Microsoft.ServiceBus.Messaging document which will certainly help you getting along the development with Service Bus Brokered Message. It contains all the details required about the Windows Azure Service Bus Namespaces with all its classes and its functions too.

For more general information about the Service Bus here is the link of my source.

For more information about Service Bus API using .Net kindly find it on the following link.

For more information about Service Bus API using Node JS kindly find it on the following link.

For more information about Service Bus API using Python Kindly find it on the following link.

For more information about Service Bus API using Java kindly find it on the following link.

After building your first Service Bus Brokered Messaging using the queues, you can now go through this service which will help you with building the first Service Bus application using the Topic & Subscription.

First of all you have to build the namespace on the Windows Azure Portal and link it to the application through the configuration setting like this example.

After that, we can start building an application that simply send and receive the Brokered Message through the Service Bus.

The following function target’s is to send a specified message through the service bus using the Topic and Subscription.

public
string
SendMessageUsingTopicsSubscriptions(string topicname, string message, string uname)

{
var baseaddress = RoleEnvironment.GetConfigurationSettingValue(“namespaceAddress”);

var issuername = RoleEnvironment.GetConfigurationSettingValue(“issuername”);

var issuersecret = RoleEnvironment.GetConfigurationSettingValue(“issuersecret”);

Uri namespaceaddress = ServiceBusEnvironment.CreateServiceUri(“sb”, baseaddress, string.Empty);

NamespaceManager namespacemanager = new NamespaceManager(
namespaceaddress, TokenProvider.CreateSharedSecretTokenProvider(issuername, issuersecret));

MessagingFactory messagingfactory = MessagingFactory.Create(

namespaceaddress, TokenProvider.CreateSharedSecretTokenProvider(issuername, issuersecret));

var topic = namespacemanager.CreateTopic(topicname);

var sub = namespacemanager.CreateSubscription(topic.Path, “typeofmessage”);

try{
messagingfactory.CreateTopicClient(topicname)
.Send(new BrokeredMessage(new MyMessage()

{ mymessage = message, username = uname }));
return “Message sent through the Service Bus Topic”;

}

catch

{ return “Error”; }

}

Here are the main classes that control all the main instructions to the Service Bus.

BrokeredMessage: this is the unit of communication between the service bus clients. The message sent through the Brokered Message are objects or streams.

NamespaceManager: is responsible of the runtime operations no matter was the method used in Service Bus, Queue or Topic and Subscription.

MessagingFactory: is responsible of the messaging entity lifecycle whatever was its type, topic and Subscription or even the queue.

Certainly if you are using the queue in the Service Bus development, you will have to initialize the client for the use of topic and Subscription. You can do so by using the TopicClient and SubscriptionClient.

TopicClient: this is the object that helps sending the brokered message through the Service Bus using the Topic.

SubscriptionClient: This class helps receiving the brokered message from the Service Bus depending on the topic the client is subscribed to.

For the receiving function it will have the same body like the sending function except the last part for the messagingfactory function with a specified interval of time. Like the following example:

SubscriptionClient sc = messagingfactory.CreateSubscriptionClient(topicname, subscriptionname, ReceiveMode.ReceiveAndDelete);

BrokeredMessage bm = sc.Receive(new TimeSpan(0,2,0));

Starting the first application working with the Service Bus Brokered Messaging, after well understanding the Microsoft.ServiceBus.Messaging namespace. Here is a simple function to work with the queues:

First of all you have to build the namespace on the Windows Azure Portal and link it to the application through the configuration setting like this example.

After that, we can start building an application that simply send and receive the Brokered Message through the Service Bus.

This function is simply to send a specified object through the Service Bus.

public WorkingWithQueues(string queuename)

{//initialization for the Service Bus and the configuration settingsvar
baseaddress = RoleEnvironment.GetConfigurationSettingValue(“namespaceAddress”);

var issuername = RoleEnvironment.GetConfigurationSettingValue(“issuername”);

var issuersecret = RoleEnvironment.GetConfigurationSettingValue(“issuersecret”);

//defining the namespace address

Uri namespaceaddress = ServiceBusEnvironment.CreateServiceUri(“sb”, baseaddress, string.Empty);
//creating the namespace manager and the queue

new NamespaceManager(
namespaceaddress,TokenProvider.CreateSharedSecretTokenProvider(issuername,issuersecret)).CreateQueue(queuename);
//initialization the messaging factory

//initialization of the queueclient

//Sending the Brokered Message of the class My Messages

MessagingFactory.Create(
namespaceaddress,TokenProvider.CreateSharedSecretTokenProvider(issuername, issuersecret))
.CreateQueueClient(queuename)

.Send(new
BrokeredMessage(new
MyMessage()));

}

Here are the main classes that control all the main instructions to the Service Bus.

BrokeredMessage: this is the unit of communication between the service bus clients. The message sent through the Brokered Message are objects or streams.

NamespaceManager: is responsible of the runtime operations no matter was the method used in Service Bus, Queue or Topic and Subscription.

MessagingFactory: is responsible of the messaging entity lifecycle whatever was its type, topic and Subscription or even the queue.

Certainly if you are using the queue in the Service Bus development, you will have to initialize the client for the use of queue. The QueueClient: this is the object that enables the sending and receiving the messages through the queue in Service Bus.

The following code is to receive a specified Object through the Service Bus. You will simply change the last line of code of the MessagingFactory to Receive like the following:

//initialization the messaging factory


//initialization of the queueclient

//Receiving the Brokered Message of the class My Messages

var x = MessagingFactory.Create(
namespaceaddress,TokenProvider.CreateSharedSecretTokenProvider(issuername,issuersecret)).CreateQueueClient(queuename).Receive(newTimeSpan(0, 3, 0));