When working with Silverlight, we often end up communicating with some form of services. They might be SOAP-based WCF services, which Silverlight handles fine, but lately REST-like services have become a lot more popular, and Silverlight doesn’t always handle them as nicely… They often rely on headers and HTTP verbs other than GET and POST, which Silverlight doesn’t handle very well by default.
In my world, I am currently spending a lot of time working with a Silverlight client that is used in a situation where we use federated security. This requires the client to carry around a token that tells the service who he/she is, and what claims are being made.
In this case, we are using the thinktecture IdentityServer, which after a bit of configuration works very well. It makes it very easy to integrate with using Silverlight, which is nice. All you need to do is do is to make an HTTP GET call to the identity server, passing along the credentials in the form of a basic authentication header. The identity server in turn replies with a token that identifies the client (at least if the credentials are valid). The client can then POST that token to the the service (relying party) who will then use that token to authenticate the client. And after that, everyone is happy, and the service can trust the client being who he/she says he/she is…
There are many ways to expose functionality and data from a server to a client. And there is probably almost as many going the other way… In Microsoft scenarios, using WCF is the obvious choice for most of us, and when people talk WCF, they generally talk SOAP based webservices.
SOAP can however be a less than ideal choice in a some cases. It is way more complicated than some of the other options, and on top of that it has a tendency to bloat the messages being sent, which can be an issue when working with mobile clients for example.
I am now about a week and a half into my latest Azure project, which so far has been a lot of fun and educational. But the funky thing is that I am still excited about working with the Service Bus, even though we are a week and a half into the project. I guess there is still another half week before my normal 2 week attentions span is up, but still!
So what is so cool about the bus, well, my last 2 posts covered some of it, but it is just so many cool possibilities that open up with it.
This post has very little to do with what I am currently working on, and to be honest, the sample is contrived and stupid, but it shows how we can use REST based services with the bus.