Hands-On Lab
Service Remoting With Windows Azure Service Bus
Lab version: 2.0.0
Last updated: 12/7/2011
Contents
Overview 3
Exercise 1: Using the Service Bus to Host Services Remotely 5
Task 1 – Running the Service On-Premises 6
Task 2 – Provisioning and Configuring the Service Bus Namespace 10
Task 3 – Configuring Access Control Service for Authentication 14
Task 4 – Configuring the Service to Listen on the Windows Azure Service Bus 29
Task 5 – Configuring the Client Application to Connect to a Service on the Windows Azure Service Bus 35
Verification 38
Exercise 2: Publishing Services Hosted in Windows Azure with the Service Bus 39
Task 1 – Hosting the Service in a Windows Azure Worker Role 40
Task 2 – (Optional) Configuring the CRM Data Service to Listen on the Windows Azure Service Bus 49
Verification 52
Summary 55
Appendix - Using the SBaZTool Command Line Tool 55
Overview
Due to recent bank regulation, the Fictional Bank is ordered to split into two separate banking entities: Fictional Investment and Fictional Retail. The IT department needs to restructure the existing customer relationship management (CRM) such that both banking entities can continue to share customer data even though they are no longer within the same corporate network boundary. The existing CRM Web services in Fictional Bank are largely written using Windows Communication Foundation and hosted on-premises.
Initially, the IT department decides to continue hosting the CRM Web services on-premises, at Fictional Investment. To achieve the goal of providing services to both entities, they choose to expose a subset of the CRM functionality through a second service, which they publish externally using the Windows Azure Service Bus, thus allowing clients at Fictional Retail access to the required functionality. This solution enables them to accomplish their objective with minimal changes to the service and client applications, which are mostly limited to WCF configuration changes.
In a second phase, Fictional Investment outsources its application services hosting. As a result, they relocate the service that they share with Fictional Retail to Windows Azure and host it in a worker role. Despite its new location, and because the Service Bus namespace allows the service to continue to be published at its present location, clients remain unaware of the change.
This hands-on lab walks you through this scenario using a sample application that replicates, albeit in a simplistic manner, the application architecture at Fictional Bank.
Objectives
In this hands-on lab, you will learn how to:
· Provision Windows Azure projects and service namespaces
· Manage Access Control Service issuers and rules to provide service and client authentication
· Host services on-premises and publish then remotely using the Service Bus
· Publish services hosted in Windows Azure using the Service Bus
Prerequisites
The following is required to complete this hands-on Lab:
· IIS 7 (with ASP.NET, WCF HTTP Activation)
· Microsoft .NET Framework 4.0
· Microsoft Visual Studio 2010
· Windows Azure Tools for Visual Studio 1.6
· Windows Azure Libraries for .Net 1.6
You must have Internet access to complete the lab.
Setup
In order to execute the exercises inthis hands-on lab you need to set up your environment.
1. Open a Windows Explorer window and browse to the lab’s Source folder.
2. Double-click the Setup.cmd file in this folder to launch the setup process that will configure your environment and install the Visual Studio code snippets for this lab.
3. If the User Account Control dialog is shown, confirm the action to proceed.
Note: Make sure you have checked all the dependencies for this lab before running the setup.
Using the Code Snippets
Throughout the lab document, you will be instructed to insert code blocks. For your convenience, most of that code is provided as Visual Studio Code Snippets, which you can use from within Visual Studio 2010 to avoid having to add it manually.
If you are not familiar with the Visual Studio Code Snippets, and want to learn how to use them, you can refer to the Setup.docx document in the Assets folder of the training kit, which contains a section describing how to use them.
Exercises
This hands-on lab includes the following exercises:
1. Using the Service Bus to Host Services Remotely
2. Publishing Services Hosted in Windows Azure with the Service Bus
Estimated time to complete this lab: 45 minutes.
Note: When you first start Visual Studio, you must select one of the predefined settings collections. Every predefined collection is designed to match a particular development style and determines window layouts, editor behavior, IntelliSense code snippets, and dialog box options. The procedures in this lab describe the actions necessary to accomplish a given task in Visual Studio when using the General Development Settings collection. If you choose a different settings collection for your development environment, there may be differences in these procedures that you need to take into account.
Exercise 1: Using the Service Bus to Host Services Remotely
In this exercise, you start with a solution that implements the Fictional Bank application architecture. The solution consists of two web services hosted by Fictional Investment. The first service, the CRM Data Service, provides application services for Fictional Investment. A second service, the FI Public Service, makes use of the first and exposes a subset of the CRM functionality to make it available to users in Fictional Retail.
Figure 1
Application architecture with services and clients directly connected
Initially, you run the service to reproduce a scenario where all services are hosted on-premises and communicate directly with their clients using a NetTcpBinding class. Such a scenario is feasible when all services reside within the same network and there are no intervening firewalls or Network Address Translation (NAT) devices along the path.
Nonetheless, Fictional Retail clients are not located within Fictional Investment’s network. In order to make the services externally accessible to Fictional Retail clients, you then update the WCF configuration to expose the FI Public Service over the Service Bus using a NetTcpRelayBinding class and a public endpoint address. This makes the service reachable from anywhere and allows you to fulfill one of the goals in the proposed scenario.
Task 1 – Running the Service On-Premises
In this task, you run the solution and test it locally using a NetTcpBinding to replicate the fully on-premises scenario, with services and clients located within the same network boundary.
1. Open Visual Studio from Start | All Programs | Microsoft Visual Studio 2010.
2. In the File menu, choose Open Project. In the Open Project dialog, browse to \Source\Ex1-ServiceBusRemoting\Begin, select ServiceRemoting.sln in the folder for the language of your preference (Visual C# or Visual Basic) and click Open.
The solution contains the following projects:
Common / A library project, shared by all the projects in the solution, containing the service and data contracts as well as the client proxies for the Web services in the applicationFictionalInvestment.Crm.Data / A console application that hosts the CRM application services for Fictional Bank
FictionalInvestment.PublicServices / A console application that hosts the public service for Fictional Bank
FictionalRetail.Crm.Client / A Windows Forms application that uses the public services provided by the CRM
Figure 2
Solution Explorer showing the CRM application components (C#)
Figure 3
Solution Explorer showing the CRM application components (VB)
3. Configure the solution to launch the client and both the CRM Data Service and the FI Public Service simultaneously. To do this, in Solution Explorer right-click the ServiceRemoting solution and select Set StartUp Projects. In the Solution 'ServiceRemoting' Property Pages dialog, select the option labeled Multiple startup projects, and then set the Action for the Fictional.Investment.Crm.Data, Fictional.Investment.PublicServices, and FictionalRetail.Crm.Client projects to Start. Ensure that the order of the projects is as shown in the figure below. To change the starting order, select a project in the list and click the up or down arrow to move it. Press OK to confirm your changes.
Figure 4
Configuring the start up order of the projects in the solution
4. Press F5 to build the solution and start the services and the client application.
5. Notice that each service displays the URL where it listens and that both services, the CRM Data Service and the FI Public Service, are currently using net.tcp and listening at the loopback address (localhost).
6. Switch to the Fictional Retail CRM Client application. The UI presents a list of customers and their current assignment to one of the two banking entities.
7. Move one or more customers from Fictional Investment to Fictional Retail by selecting the check box next to each customer's name and clicking Move to Fictional Retail Bank. Confirm that the operation succeeds by observing the status messages in the console windows of the CRM Data Service and the FI Public Service.
Figure 5
Testing the on-premises scenario with a NetTcpBinding
Note: The client application invokes the ListCustomers operation of the CRM service to retrieve the list of customers and the MoveCustomersToBankingEntity operation of the service to transfer the customers to another entity.
8. Press ENTER in both console windows to terminate the services and then exit the client application.
Task 2 – Provisioning and Configuring the Service Bus Namespace
In this task, you will create a new Windows Azure Service Bus Namespace.
1. Navigate to the Windows Azure portal. You will be prompted for your Windows Live ID credentials if you are not already signed in.
2. Click Service Bus, Access Control & Caching link in the left pane, and then select the Service Bus item under the Services element.
Figure 6
Configuring Windows Azure Service bus
3. Add a Service Namespace. A service namespace provides an application boundary for each application exposed through the Service Bus and is used to construct Service Bus endpoints for the application. To add a service namespace, click New button on the upper ribbon bar.
Figure 7
Creating a New Namespace
4. Enter a name for your service Namespace, select a Region for your service to run in, choose the Subscription and click the Create Namespace button. Make sure to validate the availability of the name first. Service names must be globally unique as they are hosted in the cloud and accessible by whomever you decide to grant access.
Figure 8
Creating a new Service Namespace
Please be patient while your service is activated. It can take a few minutes while it is provisioned.
Note: You may have to refresh the browser to show the service is active.
5. Once the namespace is active, click its name in the list of available namespaces to display the Service Namespace information page.
Figure 9
Summary page listing available service namespaces
6. In the Properties right pane, locate the Service Bus section and click the Default Key View button.
Figure 10
Namespace properties section
7. Record the value shown for Default Issuer and Default Key, and click OK. You will need these values later on to authenticate using the Access Control.
Figure 11
Service Bus default keys
You have now created a new namespace for this hands-on lab. To sign in at any time, simply navigate to the Windows Azure portal, click Sign In and provide your Live ID credentials.
Task 3 – Configuring Access Control Service for Authentication
The Windows Azure Access Control Service (ACS) service controls Service Bus authentication. You can take advantage of ACS to authenticate a host that listens on the Service Bus as well as clients that use the bus to connect to the service.
An issuer in Access Control Service represents a trusted application. Using ACS, you can create rules to map incoming claims, from trusted identity providers, into claims issued by ACS that an application or service consumes. More specifically, in the case of the Service Bus, these rules map the identity of the issuer into a series of claims that Service Bus uses to determine which actions the issuer is allowed to perform. For example, a Listen claim issued by AC allows an application to expose services on the Service Bus, while a Send claim allows it to send messages.
The Management Portal allows you to administer Access Control Service resourcesI, including its trusted issuers and the transformation rules. Additionally, a command line tool (sbaztool.exe) that you can use for managing Access Control service resources is included as part of the Service Bus samples.
In this task, you will use the Management Portal to create two issuers, one issuer for Fictional Investment and another one for Fictional Retail. Then, you will create rules to map the identity of the Fictional Investment issuer to the Listen and Send claims, allowing it to publish a service and send messages, and a second rule to map the identity of the Fictional Retail issuer to the Send claim, so that it can connect and send messages to services published on the Service Bus.
Note: For an alternative procedure that uses the command line tool to create issuers and Access Control Service rules, see Appendix 1 - Using the Windows Azure Access Control Management Command Line Tool.
1. Navigate to the Windows Azure portal. You will be prompted for your Windows Live ID credentials if you are not already signed in.
2. Click Service Bus, Access Control & Caching link in the left pane, and then select the Service Bus item under the Services element.
Figure 12
Windows Azure ServiceBus namespaces
3. Select your Namespace and click the Access Control Service button in the upper ribbon.