Cloud as a Story - Vunvulea Radu

A few days ago, client-side encryption for Azure Storage was announced. In this post we will take a look over this feature. First of all, you should know that the encryption/decryption takes place on client side. This means, that the content will be already encryption when it will arrive on Azure. This encryption technique is called Envelop Technique. It is very useful when you want to add another security layer over your data. Out of the box, there are client library for .NET (including Windows Phone). For other languages, like Java is not yet supported, but because the encryption algorithm is a well know one, you may be able to implement it on other platforms also. The encryption algorithm that is used by client library is AES (Advanced Encryption Standard). It is important to know that the encryption keys are generated by the client library. And is NEVER stored in Azure Storage. The encryption key should be stored in a different location. This library is full integration with K...

The new version of Windows Azure Service Bus came with a lot of new feature. One of the new feature that was added in Windows Azure SDK 2.0 is the support of message browsing. What is message browsing? This is a functionality that gives the ability to a client to iterate and access messages from a Service Bus Queue without locking or removing a message from the actual queue. There are pretty interesting thing that we can do using this feature. For example we can peek a message from a specific index in the queue: BrokenMessage message = queueClient.Peek(3); Or we can peek the first message that is available: BrokenMessage message = queueClient.Peek(); Another option is to peek a specific number of message from the queue: IEnumerable<BrokenMessage> messages = queueClient.PeekBatch(20); The PeekBatch support also two parameters, where the first one is used to specify the starting index (similar with Peek(3)): IEnumerable<BrokenMessage> messages = queueClient.PeekBatch...

Pornim de la următorul caz: Avem o aplicatie ce ruleaza 24h pe zi, 7 zile pe saptamana. Aceasta consuma mesaje din mai multe queue. Pentru a putea asculta la queue avem următorul cod: System.Messaging.MessageQueue msmq = new MessageQueue(".\\private$\\exemplu"); msmq .ReceiveCompleted += m_ReceiveCompleted; msmq .BeginReceive(); ... void m_ReceiveCompleted(object sender, ReceiveCompletedEventArgs e) { Console.WriteLine(DateTime.Now.ToString()); MessageQueue msmq = (MessageQueue) sender; msmq.BeginReceive(); } Intr-un anumit moment, dorim sa oprim consumul de mesaje din queue. Pentru acest lucru apelam msmq.Close() Dar avem o surpriza. Mesajele sunt în continuare consuma de către aplicație. Orice am face sau apela acestea sunt în continuare consumate. Pe msdn dacă citim cu atenție pagina care descrie metoda Close() o sa gasim Close does not always free the read and write handles to a queue, because they might be shared. Deși ...