Darned if this post hasn’t been rough to write. I don’t know if its my continued lack of caffeine (quit it about 10 days ago now), or the constant interruptions. At least the interruptions have been meaningful. But after 2 days of off and on again effort, this post is finally done.
As some of you reading this may already been aware, I’ve spent much of my spare time the last several weeks diving into Microsoft’s .NET Services. I’m finally ready to start sharing what I’ve learned in what I hope is a much more easily digestible format. Nothing against all the official documents and videos that are out there. They’re all excellent information. The problem is that there’s simply too much of it. 🙂
Overview of .NET Services
Lets start with this diagram from Microsoft
As you can see, Microsoft’s Azure Services is comprised of various components. I’ve already covered Windows Azure, the Platform as a Service (PaaS) component in other posts. However, a key point in Microsoft’s cloud messages is the notion of Software + Services or S+S. If Windows Azure or any of the products listed across the top are the software, then the blocks in the middle represent the services. I’ve spent the last 2 weeks doing my best to get my head wrapped around .NET Services. The work will continue for many weeks to come (I don’t have the luxury of being able to devote myself to it full time), but I’m looking forward to uncovering even more of this great component of Microsoft’s Azure Services.
.NET Services currently consists of three different features:
Service Bus – We’ve all heard of the notion of an Enterprise Service Bus (ESB). Well this is an Internet Service Bus. It provides a way to enable communication between processes even with firewalls, NAT, etc… protecting our intranet resources from the perils of the cloud.
.NET Access Control Service – Of course what good would being able to access things across the bus be if there wasn’t a way to help secure them. This service can handle authentication and then provide back the user’s claims.
.NET Workflow Service – Workflows are great. But for the cloud we need to ensure that they are scalable and we’d also like to be able to integrate them easily with our Service Bus.
The Service Bus – in 60 seconds or less (ok, 90. I read slow).
The purpose of the Service Bus is to give developers a way to easily overcome the challenges of working across internet security barriers such as firewalls and NAT. Thus allowing them to quickly implement secure messaging between processes regardless of where those processes reside (on-premise or in the cloud). This is the feature I’ve spent the bulk of my time looking into so far. And there’s a ton here. Course is doesn’t help that I really hadn’t done anything with WCF prior to learning about the Service Bus.
Because its a service bus, it has a service registry to support discovery and can handle access control and routing. However, the service bus is not just a single thing. Its actually comprised on a three distinct pieces. There’s the relay, used to move messages between running processes. Next, there’s routers, used strangely enough to route messages. And lastly (and most recently added), there are queues which provide an asynchronous, persistent method of delivery messages between processes (similar but more robust then the queues in Azure Storage).
Of course, none of these operate on their own. Behind the scenes, the Service Bus works with the Access Control Service and SQL Data Services. The ACS handles authentication and publication of the claims, while SDS provides persistence.
All access to endpoints exposed via the bus, regardless of their type (relay, router, or queue) must be secured. The Service Bus already recognizes the Access Control Service as a trusted authority for claims based authentication. In turn, the ACS trusts Windows Live ID. Future releases are supposed to support AD Federation Services (Codename: Geneva) and private Active Directories. It also has its own built-in identify provider that does simple userid/password authentication. This built-in provider is supposed to go away eventually. However, I can easily see if being persisted into commercial release and beyond. I also suspect we’ll see support for non-Microsoft solutions like Tivoli in future releases/update.
The ACS uses claims based authorization. You present some credentials, they are authenticated, and then a list of claims is digitally signed and returned to the caller. These claims are then used by such items as the Service Bus to determine what a user can access.
The ACS is a big topic that I’m not prepared to get into just yet. However, I will say that you can interact with the ACS via WCF, REST, or HTTP. There’s also supposed to be an ATOM interface, but no details on it have been published as yet. I’ll get into this area in more depth in future posts, once I’ve figured it out a bit more. 🙂
Workflow for the Cloud
And the final component is the ability to create your own .NET Workflow and deploy it into the cloud. The advantage here is that these workflows, already in the cloud can then be used to help coordinate the interaction of services wherever they might live. The other advantage is that because they reside within Microsoft Azure, they have the scalability needed for a robust cloud implementation. If they’re not needed, they aren’t consuming resources. If 100 instances are needed, they are spun up to meet demand.
As solutions demand more and more services, not all directly under your control, coordinating them will be increasing important. The .NET Workflow service will help meet that need. It will leverage its cousins, the ACS and Service Bus to assist with those duties.
I haven’t really dug into this item at all yet. But I’m keenly interested in it. So you’ll be seeing more of it in the hopefully not too distance future.
Update: Workflow will be going offline in July 2009 as the team prepares for their next milestone (after .NET 4.0 ships). For details, go to http://blogs.msdn.com/netservicesannounce/archive/2009/06/12/upcoming-important-changes-to-net-workflow-service.aspx
*ding* Your brain is full
I wish I could share with you exactly how much my brain starts swimming when I begin to ponder what could be accomplished with these services. If Windows Azure allows you to put applications into the cloud, these services are the glue that can help bind applications into cohesive business solutions. I’m really looking forward learning more about the various services via some hands-on practice and exploration. And you can be certain I’ll be sharing this with you ever step along the way.
BTW, it took this blog over 4 months to go from start to 500 pages viewed. In just over a month this has doubled to over 1000. Thanks to everyone that’s been visiting and sharing this blog. A special thanks to Roger Jennings of Oakleaf Systems. I continue to be impressed by Roger’s work and I’m flattered that he finds my posts valuable enough to continue to link to. He’s directly responsible for much of the traffic I see and I can’t express how much I appreciate his support.
As always, if there’s something specific you’d like to hear more on, just let me know.