April 2009

Volume 24 Number 03

Cloud Computing - Building Distributed Applications With .NET Services

By Aaron Skonnard | April 2009

This article is based on a prerelease version of .NET Services. All information is subject to change.

Contents

.NET Services
What's in .NET Services?
Creating a .NET Services Solution
Installing the .NET Services SDK
The .NET Access Control Service
Configuring a Service
The .NET Service Bus
Communicating Through the .NET Service Bus
The .NET Workflow Service
Building a Cloud Workflow

At the 2008 Professional Developers Conference(PDC) in Los Angeles, Microsoft announced an ambitious new cloud computing strategy that will unfold over the next few years. The Microsoft cloud platform—officially known as the Azure Services Platform—makes it easy for .NET developers to move their applications (or portions thereof) to the cloud using the same tools and APIs they're already familiar with.

Azure lays the foundation of the Microsoft cloud platform. Think of Azure as a Windows-based cloud operating system. It provides a highly-scalable execution environment for running .NET applications and storing data in Microsoft data centers throughout the world. Building applications on Azure can shield you from many of the costly and troublesome infrastructure aspects of your app, allowing you to focus instead on development and your business.

Microsoft provides several service offerings built on the Azure foundation, including .NET Services, SQL Services, Live Services, SharePoint Services, and more. Combining these service offerings with the Azure foundation forms the complete Azure Services Platform (see Figure 1). Each of these service offerings includes multiple individual services that you can choose to call upon in your applications. Microsoft is actively building on the Azure Services Platform in various consumer-facing applications such as Windows Live, Microsoft Office Live, Microsoft Exchange Online, Microsoft SharePoint Online, as well as others. You have the opportunity to do the same, taking advantage of whatever Azure services provide value to you.

Figure 1 The Azure Services Platform

Throughout the rest of this article,I am going to dive into the .NET Services offering within the Azure Services Platform, based on the November/December 2008 CTP release. As you can see from Figure 1, this is only one small piece of the broader cloud platform strategy but it's one of particular interest to .NET developers moving towards the cloud.

.NET Services

If you consider yourself a Microsoft connected systems developer using technologies like Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), and BizTalk Server, you'll want to pay particular attention to .NET Services. This is where most of the technologies you care about will appear within the Azure Services Platform. (It's interesting to note that the original name for the incubation project was "BizTalk Services." The official name—.NET Services—was announced at the PDC along with Azure.)

If you like to think of Azure as "Windows in the cloud," you can think of .NET Services as "the Microsoft .NET Framework in the cloud." Today, .NET developers rely heavily on the .NET Framework for building applications targeting the Windows platform. The .NET Framework provides common building blocks required by many applications, making it easier to get them up and running quickly. .NET Services plays a similar role the Azure Services Platform by providing some common building blocks that make it easier to write cloud-based applications.

Despite the similarities, there's also a striking difference between the .NET Framework and .NET Services. While the .NET Framework provides building blocks in the form of .NET assemblies, .NET Services provides building blocks in the form of hosted services running within Microsoft data centers. When using .NET Services, there's a clear boundary between your on-premise logic and the .NET Services running in the cloud. It's your job to compose these services into your business solutions. Microsoft will host, manage, and maintain the hosted services that your applications depend on.

You program against .NET Services by integrating with the individual services it provides. Although it's called ".NET" Services, you don't actually have to use .NET to accomplish this; you can integrate with .NET Services through the standard SOAP and REST interfaces it exposes. Microsoft provides a .NET Services SDK that optimizes the .NET developer experience, and there are even Java and Ruby SDKs available from the community.

What's in .NET Services?

If you consider what it would take to move your application to a cloud platform, there are a few common requirements you'll most likely run into. First, you'll need a way to describe and package your business processes, or workflows, so they can be executed and managed in the cloud. Second, you'll need a way to communicate between your cloud-based workflows and your on-premise applications, traversing any firewalls or network address translation (NAT) devices that might be in the way. And third, you'll need a way to secure communication and control access to your various cloud-based resources.

Most cloud applications need to deal with at least one of these requirements. If you had to build this type of infrastructure yourself, it would drastically change the overall value proposition. These are precisely the areas that .NET Services focuses on in the November/December 2008 CTP version.

Specifically, .NET Services fulfills these cloud infrastructure needs through three individual building block services: the .NET Workflow Service, the .NET Service Bus, and the .NET Access Control Service (see Figure 2for details).

The .NET Service Bus relies on the .NET Access Control Service to control access to the relay service by both senders and listeners. This means all senders and listeners must first obtain a token from the .NET Access Control Service before they can use the .NET Service Bus. The .NET Workflow Service integrates with the .NET Service Bus to make it possible to transmit messages through the relay service, enabling a variety of interesting communication scenarios within your cloud-based workflows. Together these services provide a compelling development fabric for building applications in the cloud.

Creating a .NET Services Solution

Before you can get started with .NET Services, you'll need to visit the Azure Services Platform portaland create a solution. This article is based on the November/December 2008 CTP release, for which you'll need an invitation token before you can create a .NET Services solution. You can obtain an invitation token by following the "Try it now" links on the Azure Services Platform portal.Azure and .NET Services require different invitation tokens, so make sure you request a .NET Services token, too. Once approved, you'll receive your .NET Services invitation token via e-mail.

Once you've received an invitation code, you can browse to the .NET Services area within the portal and create a new solution. You'll have to enter a valid invitation code and specify a solution name, then it will provision a new .NET Services solution and provide you with a solution password. (The solution name serves as the username for authentication purposes.)

During the provisioning process, you'll be required to sign in using a Windows Live ID (WLID) so the new solution can be associated with your account. Multiple solutions can be associated with a single WLID, but each solution requires a unique invitation code today. Whenever you login into the portal with your WLID, you'll see all of your solutions listed under "My Solutions" on the right side of the page. When you select a specific solution, it will take you to a page for managing different aspects of .NET Services within that specific solution (see Figure 3).

Figure 3 Managing a Solution

A solution is basically a top-level container for managing your various .NET Services assets. For example, it's a container for your .NET Service Bus endpoints, your .NET Workflow Service types and instances, and your .NET Access Control Service identities and claims transformation rules.

Installing the .NET Services SDK

You'll also need to download and install the .NET Services SDK, which you can also obtain from the Azure Services Platform portal. When you install the SDK, it will add several .NET assemblies to your machine and some Visual Studio add-ins that make it easier to integrate with .NET Services programmatically.

You'll find the new assemblies in the installation directory, which is located by default in \Program Files\Microsoft .NET Services SDK. The key assemblies include Microsoft.ServiceBus.dll, Microsoft.Workflow.Activities.dll, and Microsoft.AccessControl.Management.dll. The installation directory also contains samples illustrating how to use each service and the key features provided by each service. Be sure to check out the various samples as you begin your journey.

If you start Visual Studio, you'll also notice a new project template called CloudSequentialWorkflow (under the CloudWorkflow project type). Use this project template to create WF workflows that you want to host in the .NET Workflow Service. The SDK also installs a Visual Studio add-in that makes it easy to deploy your workflows to the .NET Workflow Service.

It's interesting to note that the implementation of .NET Services actually derives fromWCF and WF in the .NET Framework 3.5. The .NET Services SDK is able to build on that synergy to make the consumer developer experience as straightforward as possible for those already familiar with the WCF and WF programming models. If you're in that camp, the mechanics of programming .NET Services will feel very natural to you. In the end, it's mostly a matter of learning some new WCF bindings (for the .NET Service Bus), configuring those bindings, and understanding some new activities (for the .NET Workflow Service).

In the remaining sections, I'll take a quick look at each service and walk through an example of using each one. By the end, you should feel comfortable with how to get started on your own.

The .NET Access Control Service

Let's start by looking at the .NET Access Control Service. For the past several years, Microsoft has been moving towards a claims-based identity model that allows you to factor authentication and authorization decisions out of your applications and into an external service that can be centrally maintained by security experts. Under this model, the security experts control the process of authenticating users and issuing claims about the users. Your applications can simply trust the claims presented by the service and make decisions based on those claims (avoiding authentication).

When using a claims-based identity model, the user presents his identity to your application as a set of claims. Claims are simply assertions about the user—they can be anything like a name, an e-mail address, or a feedback rating. The claims are supplied by an identity provider that knows how to authenticate the user and his attributes (perhaps from an enterprise directory). The client application works transparently with the issuing authority to obtain these claims and present them to the application.

The Microsoft .NET Access Control Service is a centralized cloud-based service that makes this model easy to realize within the Azure Services Platform. Today, the .NET Access Control Service can act as an identity provider (by authenticating users via the solution credentials assigned during the provisioning process), but that's not really what it's meant to do. It was designed to primarily rely on existing identity providers such as WLID and the"Geneva" Server security token service or any identity provider that supports the standard federation protocols. This makes single sign-on a natural outcome.

The primary responsibility of the .NET Access Control Services is to provide a set of claims that are useful to your application. This typically means translating the input claims (that come from an identity provider such as WLID or the "Geneva" Server) into a set of output claims that have meaning to your application. You can think of it as a configurable claims transformation engine in the cloud.

Configuring a Service

You configure the .NET Access Control Service through the administration portal provided within a particular solution (see Figure 4). This is where you configure the rules that determine how it will issue claims for the users it knows about or as a result of transforming claims from other providers.

Figure 4 The .NET Access Control Service Administration Portal

Instead of configuring a sample service of my own, I'm going to show you how the .NET Access Control Service is configured for the .NET Service Bus. If you click on the Advanced button within the administration portal, you'll see a drop-down of solution names that represent the owners of the various scopes. A scope is a collection of claim transformation rules. When I select the Service Bus solution for my account, it shows a scope of

https://servicebus.windows.net/services/pluralsight/

When using the .NET Service Bus, you'll configure endpoints that use this Service Bus scope as the base URI (yours will be customized to your account, of course). Every solution comes preconfigured with a set of access control rules for both the .NET Service Bus and the .NET Workflow Service.

If you click on Manage, you can inspect the list of rules configured for a particular scope (see Figure 5). In this particular example, there are two rules that look for an incoming Username claim containing a value of pluralsight. One produces an output claim of Send and the other produces an output claim of Listen. The .NET Service Bus was developed to look for these claims to control access to its endpoint namespace. Any user that presents a Send claim will be allowed to send messages to the scope URI, and any user that presents a Listen claim will be allowed to create a listen on the scope URI. If I were to delete the rule that generates the Send token, my pluralsight account would no longer be able to send messages through the .NET Service Bus within this scope—it would only be able to listen.

Figure 5 Confi guring Rules for a Scope

It's easy to add similar support to your own services. You simply define new scope URIs within the administration portal, then define the necessary rules to produce the claims expected by your service.Within your service logic, you'll need to write code to inspect the incoming claims and to make authorization decisions based on what claims are present and what they contain. Both WCF and the new "Geneva" Framework make this possible through their claims-based programming models. For a complete example, see the .NET Access Control Service Getting Started sample in the SDK.

The .NET Service Bus

The primary focus of the .NET Service Bus is to provide bidirectional connectivity at Internet scope, which can be challenging due to ever-so-common firewalls and NAT devices that restrict inbound traffic in most environments. The .NET Service Bus accomplishes this by providing a centralized relay service in the cloud that provides the necessary network traversal logic (see Figure 6).

Figure 6 .NET Service Bus Relay

The relay makes it possible for a sender to communicate with a receiver through a rendezvous address. The receiver connects to the relay through an outbound port and creates a bidirectional socket for communication specifying the rendezvous address it wants to listen on. The sender can then transmit messages to the relay specifying the same rendezvous address as the receiver. When the relay receives a message, it relays the message to the corresponding listener (or listeners, in the case of multicast) that share the same rendezvous address. The relay transmits messages to the receiver through the bidirectional socket already in place, which means no inbound ports are required by the receiver. This explains why the mechanism works through firewalls and NAT devices (like a typical chat application).

The .NET Service Bus supports a variety of messaging styles including one-way, request-response, and even publish-subscribe. It supports both HTTP and TCP for communications, depending on whether you care about interoperability or performance. The relay even provides a mode for negotiating a direct TCP connection between two peer nodes based on a port prediction algorithm. Bypassing the relay allows for higher throughput when transmitting large messages. Overall, the .NET Service Bus provides a great deal of flexibility in adapting to a variety of today's most common communication scenarios.

It's important to understand how to structure the URIs for your .NET Service Bus endpoints. When you expose a TCP-based endpoint, you'll need to structure your addresses as follows:

sb://servicebus.windows.net/services/{solution}/{name}/{name}/...

When you expose an HTTP based address, simply replace the sb protocol scheme with http. Notice that you specify your solution name as part of the address in order to distinguish your endpoints from those used by other solutions throughout the .NET Service Bus. This is the same address that was used as the scope URI within the .NET Access Control Service configuration. After the solution name, you have complete control to specify whatever URI name hierarchy you'd like to use for your endpoints.

Senders and receivers will need to present the Send or Listen claim to the .NET Service Bus (acquired from the .NET Access Control Service) in order to send or listen on a particular address. Since the .NET Service Bus has a trust relationship with the .NET Access Control Service, it's able to read the security tokens that it issues and process those claims. Without those claims, you can't use the relay (unless a particular endpoint has been configured to allow for anonymous send, which is possible).

The easiest way to integrate with the .NET Service Bus relay is through the new WCF relay bindings that ship with the SDK. There is an equivalent relay binding for most of the built-in WCF HTTP/TCP bindings (see Figure 7). There are also a few new ones that don't have a clear counterpart, like NetOneWayRelayBinding (for aggressive one-way traversals) and NetEventRelayBinding (for one-way multicast scenarios, typically used for publish/subscribe). When you use the relay bindings instead of the standard bindings, the underlying WCF channel components take care of communicating with the .NET Access Control Service and the relay behind the scenes, and your code might not even need to change.

The .NET Service Bus also provides a service registry in the form of an Atom feed. This feed is available at the base address of the solution through standard HTTP GET requests. The feed will automatically contain information on all of the active listener endpoints within a particular solution.

Communicating Through the .NET Service Bus

Now let's walk through a complete example of communicating through the .NET Service Bus using a publish/subscribe model. First, assume I have the following service contract:

[ServiceContract(Namespace = "")] public interface ITweetNotifier { [OperationContract(IsOneWay = true, Action = "urn:DisplayTweet")] void DisplayTweet(string status); }

And assume I have an application hosting the service (called TweetNotifierApp) that simply prints the incoming status text to the console window—there's nothing special about it.

I can configure the host application to listen through the .NET Service Bus by defining an endpoint using one of the relay bindings. Since I want to implement publish/subscribe (with potentially multiple listeners), I'll want to use the NetEventRelayBinding as illustrated in Figure 8.

Figure 8 NetEventRelayBinding

<configuration> <system.serviceModel> <behaviors> <endpointBehaviors> <behavior name="Default"> <transportClientEndpointBehavior credentialType="UserNamePassword"> <clientCredentials> <userNamePassword userName="pluralsight" password="{password}"/> </clientCredentials> </transportClientEndpointBehavior> </behavior> </endpointBehaviors> </behaviors> <services> <service name="TweetServiceLibrary.TweetService"> <endpoint address="sb://servicebus.windows.net/services/pluralsight/tweet" behaviorConfiguration="Default" binding="netEventRelayBinding" bindingConfiguration="" contract="TweetServiceLibrary.ITweetNotifier" /> </service> </services> </system.serviceModel> </configuration>

Notice I'm also using a special behavior that tells WCF what credentials to send to the .NET Access Control Service to authenticate and acquire the necessary .NET Service Bus claims. You'll want to replace the username and password with your own credentials if you attempt to run this example.

When I run the host application, the WCF hosting infrastructure automatically authenticates with the .NET Access Control Service, acquires claims, and then opens an outbound port to the .NET Service Bus and registers a listener on the specified address. At that point, the locally hosted service will be ready to receive messages relayed through the .NET Service Bus on the specified address. I can also browse to the base address of the solution at this point to access the service registry feed and any active listener endpoints will appear in the feed.

Now I can write a client application to send messages through the .NET Service Bus on the same rendezvous address. Here's what my client program looks like:

static void Main(string[] args) { ChannelFactory<ITweetNotifier> cf = new ChannelFactory<ITweetNotifier>("tweetService"); ITweetNotifier tweetNotifier = cf.CreateChannel(); Console.WriteLine("Enter a status update: "); string status = Console.ReadLine(); while (!status.Equals("")) { tweetNotifier.DisplayTweet(status); status = Console.ReadLine(); } }

The client configuration file will need to look just like the host configuration file. Only the endpoint definition will need to appear within the <client> section. Other than that, it should look about the same, including the <transportClientEndpointBehavior> configured on the client endpoint.

With this in place, I can run multiple instances of the host application followed by a single instance of the client application, and I see all of the messages relayed in a multicast fashion (see Figure 9). The relaying will work even if the host application is behind a firewall or NAT device.

Figure 9 Running the .NET Service Bus Demo

This is just one example of many possible communication scenarios supported by the .NET Service Bus. For more examples, check out the various .NET Service Bus samples provided in the .NET Services SDK.

The .NET Workflow Service

As you move towards cloud computing, workflow provides a simplified approach for coordinating complex service interactions in the composite cloud solutions you build.

The .NET Workflow Service provides a scalable hosting environment for running and managing WF workflows in the cloud. Because the hosting environment is built on Window Azure, it's capable of scaling on demand, and because the WF runtime is being used, workflow instances are not pinned to any particular server—they are free to move from one server to another (within Azure) for each episode of execution. The .NET Workflow Service relies on a WF persistence service that leverages Microsoft SQL Services to save the state of running workflows and to ensure recovery capabilities.

You build workflows for the cloud using Visual Studio and the same workflow designer that you've always used. You ultimately create XAML workflows and rules files. These XML files are then deployed to the .NET Workflow Service where they can be used to create workflow instances.

The .NET Services SDK includes a project template for creating a SequentialCloudWorkflow that is a specialized version of the standard SequentialWorkflow template. When defining workflows to be run in the cloud, there are also restrictions on what activities you can use in the workflow. You may use only a subset of the activities in the WF base activity library as well as a suite of new custom cloud activities provided as part of the .NET Services SDK (see Figure 10). These cloud activities make it possible to send, receive, and process messages, but that's about it today. More activities will be added in future versions to enhance the capabilities of your cloud-based workflows.

Like the other services, the .NET Workflow Service comes with an administration portal for managing workflow types and instances. The .NET Services SDK also comes with a client management API that allows you to programmatically accomplish the same thing.

Figure 11 Complete Workflow Design

Building a Cloud Workflow

To see how the .NET Workflow Service operates, let's build a workflow that consumes the public Twitter feed and sends the latest entry to any subscribed TweetNotifierApp instances through the .NET Service Bus.

The first thing I need to do is create a new CloudSequentialWorkflow project in Visual Studio 2008. I'll call it MonitorTwitterFeed. At this point, you should see the traditional WF designer. If you expand the activity toolbox, you'll see the restricted set of activities that you're allowed to use.

I'll need to use a While activity to continually poll the public Twitter feed every 60 seconds. So first I drag the While activity onto the workflow design surface, and then specify that the condition with be a Declarative Rule Condition. For the purposes of this example, I make the condition always return "true." Next, I drag a Sequence activity into the While activity to define the sequence of steps that I want to repeat.

Now, I want to delay for 60 seconds, so I drag a CloudDelay activity into the sequence and specify 00:01:00 for the Timeout value. Then I need to retrieve the public Twitter feed using an HTTP GET request, so I place a CloudHttpSend activity right below the CloudDelay activity and configure it appropriately (setting the Method to GET and the URL to https://twitter.com/statuses/public\_timeline.xml).

Next,I need to read the latest status entry from the top of the feed, which is made possible through the CloudXPathRead activity. After placing this in the sequence, I bind the InXml property to the Response property of the previous activity. I also set InXPathExpression to /statuses/status/text to specify the XPath expression.

Next,I need to build an appropriate XML message to send to the TweetNotifierApp through the .NET Service Bus. I can accomplish this through the CloudXPathUpdate activity. The target service is expecting a message that looks like this:

<DisplayTweet><text> status goes here </text></DisplayTweet>

So after placing the CloudXPathUpdate activity into the sequence, I need to enter the XML into the InXml property and "/DisplayTweet/text" for InXPathExpression. I also need to bind InNewValue to the OutReadValue property on the previous activity. This essentially tells the activity how to construct a new XML document by inserting an input value (the latest status) into the XML template.

Finally, I need to instruct the workflow to send the message through the .NET Service Bus. This is where the CloudServiceBusSend activity comes in. After placing it at the end of the sequence, I set the Action to urn:DisplayTweet, the ConnectionMode to Multicast, and the address to sb://servicebus.windows.net/services/pluralsight/tweet. I bind the Body property to the OutXml property on the previous activity. With that in place, the workflow is complete. See Figure 11for a complete visual of the resulting workflow design.

Now, to deploy and test the workflow, I simply right-click on the workflow design surface and select Deploy Workflow. I enter your solution credentials and press Deploy & Run. The add-in will upload your XAML definition to the .NET Workflow Service and start an instance of it. It's also possible to upload the XAML definition manually through a form on the management portal.

After you've deployed the workflow, you can browse to the administration portal and see the workflow type and the running instance. If you have any instances of the TweetNotifierApp running, you'll see Twitter messages appear every 60 seconds.

Aaron Skonnard is a cofounder of Pluralsight, a training provider offering both instructor-led and on-demand Microsoft developer courses. These days Aaron spends most of his time recording Pluralsight On-Demand! courses focused on Cloud Computing, Azure, WCF, and REST. Aaron has spent years writing, speaking, and teaching professional developers around the world. You can reach him at pluralsight.com/.