Day 3 keynotes were about Microsoft research, presented by Rick Rashid. Rick’s presentation was probably the most impressing presentation in PDC – even I did not know how large the Microsoft research team is (850 researchers – larger than most universities), and the breath of projects they are involved in – from software proofing, to weather control, health research (yes!) and surface programming. However to me as a father (and as a former LOGO instructor) the most impressing project presented is Boku – a programming environment for children. If you have children (and / or you are still, like me, a little bit of a child yourself) go see it.
After Boku, returning to the technical stuff was a bit hard…
I went to see Clemens Vasters‘ presentation on .NET services. Clemens showed how you can connect two applications through the cloud – even if they run on public Internet connections, corporate environments, NATS etc. To enable that, Microsoft is delivering a whole bunch of new bindings for WCF – the "relay" bindings – each corresponding to an existing "normal" binding (for example, BasicHttpRelayBinding corresponds to BasicHttpBinding. There is no MsmqRelayBinding yet – it may be a good exercise to develop one… According to Clemens, one of the reasons that Microsoft did not come up with such binding is the difficulty of keeping end-to-end transactional messages protocol through the cloud. However, I think it is a good idea anyway to avoid transactional messages.
Later in the day, I went to see Sriram Krishnan’s talk on best practices of programming on the Cloud. Sriram is an excellent presenter and I highly recommend that you go see his talk (should be available online on the PDC site in a few days) – especially if you are distributed applications architects – not only those developing for the cloud. Sriram preaches for stateless, loosely coupled and simple solutions (did I tell you I hate transactions?). He strengthened my conclusion that cloud programming to the enterprise programmers is what VB.NET is to VB6 programmers – it looks the same, but it is actually quite different – and it will take time to adjust and think "the cloud way". You can see more in his site.
I learned a little more today about Azure queues. The interface to these queues is HTTP REST interface (which implies that duplications are part of life and there are no real transactions – but you know that already). Here are the APIs:
Queues:
- Create –
PUT http://myaccount.queue.core.windows.net/myqueue
DELETE http://myaccount.queue.core.windows.net/myqueue
GET/HEAD http://127.0.0.1:10001/myaccount/myqueue?comp=metadata
Similar to get properties in MSMQ, except it also returns the message count (do I hear you clap?) and the other properties are free form name / value pairs.
- Set metadata
PUT http://127.0.0.1:10001/myaccount/myqueue?comp=metadata
You can't set the number of messages... just the rest of the name/value pairs.
Messages:
- Put message:
POST http://127.0.0.1:10001/myaccount/myqueue/messages
The actual message is in the request's body.
GET http://127.0.0.1:10001/myaccount/myqueue/messages
In the URI, you can also ask for the number of messages you want, and also specify a timeout. If you do not delete the message within the timeout, it will be returned to the queue.
- Peek Messages:
GET http://myaccount.queue.core.windows.net/myqueue/messages?peekonly=true
Same as GET, but the message remains visible in the queue (you knew that already, didn’t you?)
- Delete Message:
DELETE http://127.0.0.1:10001/myaccount/myqueue/messages/messageid?popreceipt=string-value
"lightweight commit" You have to call that after GET – otherwise the message will be put back in the queue
- Clear messages:
DELETE http://myaccount.queue.core.windows.net/myqueue/messages
Deletes all the messages in the queue (purge).
The Azure samples (provided with the SDK) wrap the REST methods with a .NET class, RestQueue, which itself is wrapped with a class called… Ahm… MessageQueue! Isn’t that fun? You already know that when programming with System.Messaging on a widows form you have to explicitly put the namespace for Message, now you also have MessageQueue in a different namespace. Should be fun.
That’s all folks… four queue methods, five message methods. Is that all we need? I guess that in most cases, the answer is surprisingly YES. I would love to hear your views.