Search results matching tag 'windows azure'

Behind Service Bus Connection String

ddobric — Tue, 21 May 2013 06:14:00 GMT

When working with Service Bus, it is very useful to make a usage of Service Bus Connection String to create SB-entities.
For example, following line of code can be used to create the QueueClient instance which can be used to send and receive messages:

var client = QueueClient.CreateFromConnectionString(connStr, “queuname”);

Connection string looks usually like:

"Endpoint=sb://yournamespacename.servicebus.windows.net/;SharedSecretIssuer=bla;SharedSecretValue=**obfuscated..=";

Connection String is very useful, because many information like service bus namespace and all credentials are contained inside of that staring. This enables creation of for example QueueClient in a single line of code.
In general Connection String is consisted of a moniker (sb://..) which includes protocol and URI with namespace. This defines the Endpoints and/or StsEndpoints.
Additionally it contains a number of so called connection properties which describe credentials.

Following picture illustrates the code which extracts all these artifacts inside of Service Bus library.

What is new in Service Bus 2.0?

ddobric — Wed, 01 May 2013 09:30:03 GMT

This post should give you a quick overview of new features of Service Bus. Note that I didn’t describe the MessageBrowse Feature, because it is already well described by other SB team colleagues.

MessagePump

When receiving messages from queue, you have been responsible to implement some kind of listener which will receive messages and dispatch them to some message processor.
With Service Bus 2.0 you can give this responsibility away. SB v2 provides an event driven message receiver based on message pump implementation.
Following code snippet shows how easy you can receive messages now.

   client.OnMessage((msg) =>
            {
                Console.WriteLine("ThreadId: {0}, Message: {1}",

                Thread.CurrentThread.ManagedThreadId, msg.GetBody<string>());

                if (cnt == 10) // because we expect 10 messages.
                    return;
            },
                new OnMessageOptions()
                {
                    AutoComplete = true,
                    MaxConcurrentCalls = 5
                }
               );

OnMessageOptions can be used to specified the number of concurrently processing messages. If you want to process one by one message ( one thread only) specify value one here.
Independent on his value messages are always processed on another thread.

Last but not least in OnMessageOptions you set AutoComplete, if you want that message is completed after successful execution of callback.

Suspend and Resume Queue

The queues and topics can be now suspended and resumed. This can be achieved by manipulating the status of the queue:

// Summary:
    //     Enumerates the possible values for the status of a messaging entity.
    [DataContract(Name = "EntityStatus", Namespace = "http://schemas.microsoft.com/netservices/2010/10/servicebus/connect")]
    public enum EntityStatus
    {
        // Summary:
        //     The status of the messaging entity is active.
        [EnumMember]
        Active = 0,
        //
        // Summary:
        //     The status of the messaging entity is disabled.
        [EnumMember]
        Disabled = 1,
        //
        // Summary:
        //     Resuming the previous status of the messaging entity.
        [EnumMember]
        Restoring = 2,
        //
        // Summary:
        //     The sending status of the messaging entity is disabled.
        [EnumMember]
        SendDisabled = 3,
        //
        // Summary:
        //     The receiving status of the messaging entity is disabled.
        [EnumMember]
        ReceiveDisabled = 4,
    }

Following sample illustrates how this work:

        /// <summary>
        /// Suspend and Resume sample.
        /// </summary>
        private static void suspendResumeSamnple()
        {
            string qName = "hello/msgpump";

            var qDesc = prepareQueue(qName);

            var client = QueueClient.CreateFromConnectionString(m_ConnStr,
            qName, ReceiveMode.PeekLock);

            Console.WriteLine("Sending messages...");

            for (int i = 0; i < 10; i++)
            {
                client.Send(new BrokeredMessage("i = " + i.ToString() + ", payload = "
                + new Random().Next().ToString()));
            }

            int cnt = 10;

            client.OnMessage((msg) =>
            {
                Console.WriteLine("ThreadId: {0}, Message: {1}",
                Thread.CurrentThread.ManagedThreadId, msg.GetBody<string>());

                Thread.Sleep(1000);

                if (cnt == 10)
                    return;
            },
             new OnMessageOptions()
             {
                 AutoComplete = true
             }
            );

            // Wait to receive few messages.
            Thread.Sleep(2000);

            NamespaceManager namespaceManager =
            NamespaceManager.CreateFromConnectionString(m_ConnStr);

          // Suspend Queue
           qDesc.Status = EntityStatus.ReceiveDisabled;
            namespaceManager.UpdateQueue(qDesc);
            Console.WriteLine("Receive disabled!");

            Thread.Sleep(25000);

          // Resume Queue
            qDesc.Status = EntityStatus.Active;
            namespaceManager.UpdateQueue(qDesc);

            Console.WriteLine("Receive enabled...");

            Console.ReadLine();
        }

And finally, the picture below shows that receiving of messages is stopped for a while. Note that message pump might already has received a message in the moment of
disabling of receive operation. See blue underlined message. To resume the receiving (or any other suspended) operation just set the queue state to active again.

AutoDelete Queue on Idle

This features enables removal of queues which are not used for a while.
Following sample illustrate this. After sleep time (higher than specified delete on idle time) you can check if the queue exists.
If all works fine the queue will not exist. Note that specified time is not very exact. Do not expect that this time is exact like Swiss Watch.
The queue will not be deleted one second after specified time. I tried with idle of 5min and sleep of 6 and queue has not been deleted.

   private static void autodeletOnIdle()
        {
            var qDesc = prepareQueue("hello/autodelete");

            qDesc.AutoDeleteOnIdle = TimeSpan.FromMinutes(5);


            NamespaceManager namespaceManager = NamespaceManager.CreateFromConnectionString(m_ConnStr);

namespaceManager.UpdateQueue(qDesc);

Thread.Sleep(6 * 60000);

            if (namespaceManager.QueueExists("hello/autodelete"))
            {
                Console.WriteLine("Queue has been deleted");
            }
            else
            {
                Console.WriteLine("Queue has NOT been deleted!");
            }

            Console.ReadLine();
        }

The value supplied for TimeSpan of AutoDelete must be between 00:05:00 and 10675199.02:48:05.4775807.
All previously created queue (before version of SB 2.0) have the same default value like newly queues created queues. This value is the maximum allowed value 10675199.02:48:05.4775807, which is

more details about this in Haishi’s post.

Authorization Rules

One of really interesting improvements in V2 is support for ShareAccessSignature. The problem we usually have a related to sharing of keys and maintaining service identities in Access Control Service.
This is a task which I and most of you out there do not like. Now you can set permission on the queue/topic directly. The authorization is defined as list of rules and one rule would look like:

authorizationRule = ( KeyName, KeyValue, [AccessRule1, .., AccessRuleN]);

Programmatically authorization rule can be created as follows:

new SharedAccessAuthorizationRule("demouser1_can_Send", key1, new AccessRights[] { AccessRights.Send }));

The first argument is simply the name of the rule. For example: Rule1, ReadRule or transferAccountQueue.

The key must be 44 bytes long. I guess this is 256 bits base64 encoded. Otherwise you will get following error:

The remote server returned an error: (400) Bad Request. A SharedAccessAuthorizationRule only supports keys of size 44 bytes..

Anyhow, the be sure you can use a helper method to create the key:

string key1 = SharedAccessAuthorizationRule.GenerateRandomKey();

Then you have to append the list of rights:

// Summary:
    //     Specifies the possible access rights for a user.
    [DataContract(Name = "AccessRights", Namespace = "http://schemas.microsoft.com/netservices/2010/10/servicebus/connect")]
    public enum AccessRights
    {
        // Summary:
        //     The access right is Manage.
        [EnumMember]
        Manage = 0,
        //
        // Summary:
        //     The access right is Send.
        [EnumMember]
        Send = 1,
        //
        // Summary:
        //     The access right is Listen.
        [EnumMember]
        Listen = 2,
    }

After you setup permissions, participants can do following to access the entity:

var factory1 = MessagingFactory.Create(new Uri("sb://xyyyyy.servicebus.windows.net"),
TokenProvider.CreateSharedAccessSignatureTokenProvider("your rule key name", yourkey));

var clientDemoUser1 = factory1.CreateQueueClient(qName, ReceiveMode.PeekLock);

As long the keyName and key match all will work fine. Note that in this sample we didn’t use any credential from Access Control Service.

Following full sample illustrates how to deal with Shared Access Signatures.

private static void authorizationRulesSample()
        {
            NamespaceManager namespaceManager = NamespaceManager.CreateFromConnectionString(m_ConnStr);

            string qName = "hello/rule1q";

            string key1 = SharedAccessAuthorizationRule.GenerateRandomKey();
            string key2 = SharedAccessAuthorizationRule.GenerateRandomKey();

            if (namespaceManager.QueueExists(qName))
                namespaceManager.DeleteQueue(qName);

            QueueDescription qDesc1 = new QueueDescription(qName);

            qDesc1.Authorization.Add(new SharedAccessAuthorizationRule("demouser1_can_Send", key1, new AccessRights[] { AccessRights.Send }));

            qDesc1.Authorization.Add(new SharedAccessAuthorizationRule("demouser2_can_Listen", key2, new AccessRights[] { AccessRights.Listen }));

            //qDesc1.Authorization.Add(new SharedAccessAuthorizationRule("how_to_set_admin_perm", key3, new AccessRights[] { AccessRights.Manage, AccessRights.Listen, AccessRights.Send }));

            namespaceManager.CreateQueue(qDesc1);

            var factory1 = MessagingFactory.Create(new Uri("sb://frankfurt.servicebus.windows.net"), TokenProvider.CreateSharedAccessSignatureTokenProvider("demouser1_can_Send", key1));
            var factory2 = MessagingFactory.Create(new Uri("sb://frankfurt.servicebus.windows.net"), TokenProvider.CreateSharedAccessSignatureTokenProvider("demouser2_can_Listen", key2));

            var clientDemoUser1 = factory1.CreateQueueClient(qName, ReceiveMode.PeekLock);
            var clientDemoUser2 = factory2.CreateQueueClient(qName, ReceiveMode.PeekLock);

            clientDemoUser1.Send(new BrokeredMessage("abc"));

            try
            {
                // This one has not a right to send to queue.
                clientDemoUser2.Send(new BrokeredMessage("abc"));
           }
            catch (UnauthorizedAccessException)
            {

            }

            try
            {
                // This one has not a right to Listen on queue.
                var msg = clientDemoUser1.Receive();
            }
            catch (UnauthorizedAccessException)
            {

            }

            // This one can listen.
            var msg2 = clientDemoUser2.Receive();

            Console.ReadLine();
        }

More about this topic: http://haishibai.blogspot.de/2013/01/new-features-in-service-bus-preview_29.html

Task Based Api

Most of ServiceBus methods provides now async/await support. More about this feature:
http://blogs.msdn.com/b/windowsazure/archive/2013/04/11/task-based-apis-for-service-bus.aspx

(image copied from msdn – see URL above)

Video about SB v2 features:
http://channel9.msdn.com/Blogs/Subscribe/Whats-new-in-the-Service-Bus-NET-SDK-20

Sample for this solution:
http://code.msdn.microsoft.com/ServiceBus-V2-Features-6b29f2ca

Power of Windows Azure PaaS: State Share and Persistence in the cloud

ddobric — Mon, 22 Apr 2013 13:00:00 GMT

If you are experienced enterprise developer who targets the Microsoft platform, you have probably at least once in your have a requirement to share some state across different instance of an application.
But, if you are hobby developer or any other professional developer, who possible do not focus distributed systems, you will might find the term “State” in context of persistence a pure theory thing.
So who ever you are, let’s start with a simple theory thing.
Imaging you have in theory a trivial application (today I call such applications simply “apps”). Assume this is an app running on smart phone or any other mobile device. This app has a variable ‘A’ and value assigned to this variable ‘1’. This value is not the default value. It is rather the value which user has assigned at some point of time.

Now, imagine the application crashes and you start it again. The value of variable A is obviously lost. If you want to keep this value somewhere, so it can be loaded even if application crashes. We call that usually persistence. Depending on application and your skill, there are several ways to persists the value of an variable. For example you can use any kind of local cache, like a file system.

But what if your application has to survive the hardware damage? Or what if your application is consisted multiple clients which have to share the same value? In this case you will have to use some kind of database.
As long you are in control of your infrastructure (means application is deployed in your enterprise) you can use some database to persist the value. The good example of this is Workflow Foundation. Long running processes require by default the state persistence.
Unfortunately we have more often scenarios where applications are distributed across the web. In such cases the only sharing artifact between such applications is the cloud. Following picture shows how two apps (or applications) share their state through the cloud.

This is a nice theoretical case which is practically a horror to implement. I strongly believe that today we are implicitly preparing for dominance of devices in the web. In this hypothetical scenario both devices (see picture above) should act as services to be able to share their state. If you are distributed application or integration developer you know that connectivity us such scenarios is a big, big issue. Or simply, it is the fact, devices in the web have a private IP address and because of that they are not reachable by anybody. So if the microscope on the left cannot reach the smart-phone on the right, the state from left to right cannot be propagated and vice versa.

If this to theoretical to you, imagine just a service which is running distributed across cloud. This might be WCF service, Windows Service (running in SCM) or even Web Api based service. Whatever technology you peek, it does not matter. The only important thing is that you want run multiple instances of the service, but on two machines which are not in the same environment (if they are in the same environment even better). So that means, independent on a case, devices or services or both, we have the same requirement:

1. Sharing of the state between applications distributed in the web
2. Persisting of the state without database.

You believe or not, this problem can be solved by using Windows Azure Service Bus, which in this case plays a role of cloud artifact. To illustrate how this can work, take a look on following example.
This is a console application in C#. The state which should be shared and persisted across many applications is stared in variable State.

class Program{

public static WebState<string> State { get; set; }

static void Main(string[] args)
{

State = new WebState<string>(ConfigurationManager.AppSettings["SbConnStr"], "BusinessDomain", ConfigurationManager.AppSettings["Node"]);

           State.StateChanged += State_StateChanged;

            Console.WriteLine("I'm node with name: " + ConfigurationManager.AppSettings["Node"]);

Console.WriteLine("Running with state: {0}", State.Value);

           while (true)
            {
                State.Value = Console.ReadLine();
            }
        }

        static void State_StateChanged(object sender, WebStateEventArg<string> e)
        {
            Console.WriteLine("State changed by {0} at value: {1}", e.InstanceName, e.NewValue);
        }

}

As you see this variable is of type WebState, which is implemented by me. When you start this application, enter some text on the console. The text will be immediately persisted in the cloud after following line of code is executed:

State.Value = …

Now stop the application gracefully and start it again. You will notice that application write out the value which was as last one persisted. In fact event with one participant in the system you have achieved the persistence.
The magic behind this is implemented on top of Windows Azure Service Bus queues. Each time the value is changed, the WebState implementation receives the existing message from the queue and put back the new message in the queue which basically holds the serialized value of variable State, and so on. Because access to the queue is session based, Service Bus guaranties that no any other applications which shares this value, will access the queue in the same time. I don’t want to call this distributed transaction, but it behaves in persistence this scenario like it would be one. In fact the WebState class uses the Queue as a unit of storage. By reading and immediate writing back of the new value, it is guarantied that the queue holds one and only one message all the time.
Following picture illustrate this. Each time the value i changed the old value is stored in the queue as a message. The old value is received from queue and the new message with new value is sent to the queue. At the end the old one is completed, because PeekAndLock receive is used.When the new instance of the State is created (for example when application is started) the same cycle with receive/send is done. This is how multiple applications obtain there actual state.

Additionally the implementation of the WebState takes a care about state sharing. For this purpose there is a topic used to share state changes. All participants in this distributed system have to create a subscription on that topic.
In this case (see picture below) the new value is published as a message to the topic. After that all subscribers can receive the message with the new value. The publishing process additionally updates the new value in the persistence queue from previous example.

Because topic-subscriptions are used, the application which was not running for a while, will automatically receive all state changes which have happened in the mean time.

This examples shows how complex patterns can be implemented by using connectivity service in Windows Azure. I know that majority of people out there still think a..bout cloud as an old thing. There is also a group of people who thinks that cloud is unsafe think to keep the data. If you are one them them please rethink your thinking. The scenario and solution shown above is a new way of thinking and using cloud services. And the nice think here is that practically no real data is stored in the cloud.
As you see, the cloud is more than solely putting of some application online. :)

The code for this will be published soon.

Welcome to WinDays 2013

ddobric — Sun, 21 Apr 2013 14:06:16 GMT

I'm very happy that 01. Mai is on the front. This is my favorite Barbie Queue day.
But till than one more public conference only. WinDays is probably after Tech Ed the biggest developer conference in Europe.

Traditionally I will give few talks there. As always I will talk about things which publicly never been covered from perspective I usually do.
I’m ready for new year of more or less new fiscal strategies. This time my focus will be story about Devices and Service in context of cloud.
A good short introduction in upcoming content will be presented in my keynote.
Of course as MVP and VTSP I will focus Windows Azure Cloud and my personal expertise area around Distributed Systems, heavy architectures, Service Bus, Workflow Manager etc.

Here is short summary:

Devices and Service Intro

22.04.: Keynote
To be covered very common and useful scenarios for devices in the cloud. What can you do with Service Bus and why is Service Bus one of core PaaS components of Windows Azure.

How to build Services for Devices
24.04: Distributed Applications for Windows, Cloud & SharePoint (400)
srijeda15:05 - 15:50Coral 5

Runtime for Devices

24.04: Runtime 8 Fight-Club
srijeda18:20 - 19:05Coral 5

How to add the user to Windows Azure Sql Server?

ddobric — Tue, 16 Apr 2013 19:09:00 GMT

When working with SQL Server in Windows Azure you can create very quickly the database. But if you have a big distributed team usually you will not want to give everybody the access to DB.
Unfortunately right now, there is no way to manage users in Management Portal or event to do that within SQL Management studio. At least not by using common UI. This post describes stepp by step how to create the user
by using T-SQL within SQL Management Studio.

Start SQM Management studio and connect with the admin user, which you will usually use in SQL Management Portal.
Once you are connected to your Windows Azure Database, select the master database, right mouse click and select new query.

This will open the new query wit connection to master database. Note that you have to open the SQL editor with master database!
Then type following in the query in the editor:

CREATE LOGIN yourusername WITH password=’YourPwd123‘;

This will create the new LOGIN in the master database.

Now execute following statement in the same editor:

CREATE USER yourusername FROM LOGIN yourusername ;
This statement will create the user from specified login in the master database.

After that we need the to select wanted database (as in previous step, but this time you will not select master database) and open the query window.
In that window enter same script as in previous step:

CREATE USER yourusername FROM LOGIN yourusername ;

This statement will create the user from specified login in your database.

At the end we need to append some roles to the user. They can be enlisted as follows:

For example if you want to add it in the role of owners do following:

EXEC sp_addrolemember 'db_owner', yourusername ;

Now you can use use DB in the cloud. I know that last few steps are not very common task of every developer. I have tried to keep them simple. T-SQL can look much worse, believe me.
An alternative to these steps was to setup completely new infrastructure which will publicly provide secure access to database. My steps have taken about 20 mins to provision and migrate one DB in the cloud.
To do all that On-Prem will take much, much more time.

Integration Styles – University of Applied Sciences Frankfurt am Main

ddobric — Sat, 13 Apr 2013 08:14:33 GMT

Announcing Agenda for April 15. 2013. The focus of the session will be “Introduction in Integration Styles”.

Distributed Systems and Service Patterns Session – University of Applied Sciences Frankfurt am Main

ddobric — Sat, 13 Apr 2013 08:13:22 GMT

Here is the recap of the session Distributed Systems and Service Patterns.

Agenda for MSNetwork Web vNext Session

ddobric — Sun, 31 Mar 2013 12:49:16 GMT

Here is the preliminary agenda for MSNetwork upcoming session next week.

There are few important things which will unfortunately not be covered in this session.
But if you really want to dive deeper behind Steaming and Push technologies, I would recommend you to read this post.

ExpressionTranslator Error when publishing Workflows

ddobric — Tue, 26 Mar 2013 21:43:00 GMT

When working with Workflows, which running in Workflow Manager (SP devs call it usually SharePoint Workflow) on-premises or in Office 365 you might get following error:

Expression: DateTime.Now.ToString()

"Property access conversion to an activity is not supported for property 'CurrentDomain' defined on type 'System.AppDomain'."

This error occurs during Translation of the workflow. The translation is a step in process of publishing of the Workflow in Workflow Manager. it basically translates all expressions in Workflow Activities in a form
required by XAML, before the workflow is published (installed) to the host.

Following picture shows an expression which will cause described error:

The picture left below shows XAML expression which is translated in a bit different expression (picture right below). Note that DateTime.Now.ToString() is in this case not evaluated. It is a pure string like “BLA, BLA”.

   <Assign sap2010:WorkflowViewState.IdRef="Assign_1">
      <Assign.To>
        <OutArgument x:TypeArguments="x:String">
          <mca:CSharpReference
            x:TypeArguments="x:String">result</mca:CSharpReference>
        </OutArgument>
      </Assign.To>

      <Assign.Value>
        <InArgument
         x:TypeArguments="x:String">DateTime.Now.ToString()
        </InArgument>

</Assign.Value>

</Assign>

Right now, it is not possible to access properties within Expressions. To make this working you will unfortunately have to define the type to access properties. For example, if you want to access MyCustomTye.MyProp you will have to create the activity like GetMyCustomPropActivity and define InArgument<MyCustomTye> and OutArgument<yourproptrustedtype>. The later one will hold the value of MyProp.
This activity have to extend trusted surface (se URL below) even if the type is common .NET type like DateTime.

How to create custom activities:

http://developers.de/blogs/damir_dobric/archive/2012/09/16/workflow-trusted-surface.aspx

http://msdn.microsoft.com/en-us/library/windowsazure/jj193517(v=azure.10).aspx

Why SignalR does not use WebSockets Part II?

ddobric — Tue, 19 Mar 2013 07:21:00 GMT

If you notice that signalR does not use websockets you might first take a look on this post. But if this does not help there is also seething you have to be aware of. That means depending on how you have created the solution it might happen that websockets will be be used as a default transport.

If you create your solution like this the websockets will be downgraded (not used):

1. Create new project like MVC4, empty web or any other.

2. Add Nuget Reference to SignalR

3. Change the project to 4.5 (within project properties)

4. Set httpRuntime to 4.5

Now create solution like describe below: