Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
What’s New in 2012 R2: Enabling Modern Apps with the Windows Azure Pack
Published Sep 07 2018 10:22 PM 504 Views
Iron Contributor
First published on CloudBlogs on Aug, 21 2013


Part 8 of a 9-part series .

Don’t let the title fool you – this post is critically important for Developers and IT pros.

The reason I call out this warning up front is that often, when I’m speaking at conferences around the world, as soon as I start to discuss the developer perspective and developer tools, many IT Pros in the room starts playing Angry Birds while they wait for the developer section to be over.

Why is it so important for IT Pros to understand how modern applications are built? The answer is simple: IT Pros are the ones who build and operate the infrastructure that hosts these applications, and, the more you know about how these applications are built, the better you will understand their platform requirements.

That’s the tactical reason. There is also a strategic reason.

If your organization is not already in the process of defining it’s cloud strategy – it soon will be. You need to be a contributor and leader in these conversations. By mastering today’s topics, you can become a part of the conversation and define the long-term solution , rather than someone who is simply reacting to decisions they were not a part of making.

The future of the IT Pro role will require you to know how applications are built for the cloud, as well as the cloud infrastructures where these apps operate, is something every IT Pro needs in order to be a voice in the meetings that will define an organization’s cloud strategy. IT pros are also going to need to know how their team fits in this cloud-centric model, as well as how to proactively drive these discussions.

These R2 posts will get you what you need, and this “Enable Modern Business Apps” pillar will be particularly helpful.

Throughout the posts in this series we have spoken about the importance of consistency across private, hosted and public clouds, and we’ve examined how Microsoft is unique in its vision and execution of delivering consistent clouds. The Windows Azure Pack is a wonderful example of Microsoft innovating in the public cloud and then bringing the benefits of that innovation to your datacenter .

The Windows Azure Pack is – literally speaking – a set of capabilities that we have battle-hardened and proven in our public cloud. These capabilities are now made available for you to enhance your cloud and ensure that “consistency across clouds” that we believe is so important.

A major benefit of the Windows Azure Pack is the ability to build an application once and then deploy and operate it in any Microsoft Cloud – private, hosted or public.

This kind of flexibility means that you can build an application, initially deploy it in your private cloud, and then, if you want to move that app to a Service Provider or Azure in the future, you can do it without having to modify the application. Making tasks like this simple is a major part of our promise around cloud consistency, and it is something only Microsoft (not VMware, not AWS) can deliver.

This ability to migrate an app between these environments means that your apps and your data are never locked in to a single cloud . This allows you to easily adjust as your organization’s needs, regulatory requirements, or any operational conditions change.

A big part of this consistency and connection is the Windows Azure Service Bus which will be a major focus of today’s post.

The Windows Azure Service Bus has been a big part of Windows Azure since 2010. I don’t want to overstate this, but Service Bus has been battle-hardened in Azure for more than 3 years, and now we are delivering it to you to run in your datacenters. To give you a quick idea of how critical Service Bus is for Microsoft, consider this: Service Bus is used in all the billing for Windows Azure , and it is responsible for gathering and posting all the scoring and achievement data to the Halo 4 leaderboards (now that is really, really important – just ask my sons!). It goes without saying that the people in charge of Azure billing and the hardcore gamers are not going to tolerate any latency or downtime getting to their data.

With today’s topic, take the time to really appreciate the app development and app platform functionality in this R2 wave. I think you’ll be really excited about how you can plug into this process and lead your organization.

This post, written by Bradley Bartz (Principal Program Manager from Windows Azure) and Ziv Rafalovich (Senior Program Manager in Windows Azure), will get deep into these new features and the amazing scenarios that the Windows Azure Pack and Windows Azure Service Bus enable. As always in this 2012 R2 series , check out the “ Next Steps ” at the bottom of this for links to additional information about the topics covered in this post.

* * *

When building modern applications, developers want a way to connect multiple tiers of their application as well as a way to consume services offered by third party vendors. Different tiers within modern applications may have different hosting methods, e.g. front-tier components are often written as web applications, while back-end services may be hosted in a virtual machine.

The Windows Server 2012 R2 platform offers multiple hosting alternatives, but there is still a need to enable connectivity between an application’s components and services. One of the common approaches is to exchange messaging using a broker.

Two years ago, we have introduced the Windows Azure Service Bus which provides messaging capabilities in the public cloud. Since its launch we’ve seen multiple scenarios where messaging has been a valuable in addition to the basic back-end/front-end pattern. We’ve seen messaging used to connect clients and devices to a cloud service, as well as scenarios where messaging was used for integration.

Just a year ago we released Service Bus for Windows Server v1.0, which enables a developer to build, test, and run loosely-coupled, message-driven applications in self-managed environments as well as on developer computers.

Now, with the release of Windows Server 2012 R2 (just one year after we released Service Bus 1.0 for Windows Server and introduced the runtime capabilities of brokered messaging on-premises!), we are proud to release the second version of our broker called Service Bus 1.1 for Windows Server .

In this release we have invested in an integrated experience as a part of the Windows Azure Pack , with the goal of bringing a self-service tenant experience that is consistent with the one that currently exists in Windows Azure.

We’ve listened closely to our customers and focused on improving the following 3 core scenarios with the Service Bus 1.1 for Windows Server and the Windows Azure Pack:

  1. Application Messaging Patterns with Service Bus
    With Service Bus we support basic as well as advanced messaging patterns for use in modern applications. With this release we’ve also added new messaging capabilities, additional protocols, and simplified APIs to enable developers to write better applications faster.
  2. Manage Messaging entities across clouds
    Whether you’re developing for the public cloud, private cloud, or a hosted cloud (with your service provider), developers will be able to write applications once and then use it anywhere within these clouds – without needing to recompile. This can be done by simply changing an entry in the configuration file.
  3. Offering Alternatives with Service Bus
    Whether you are an Independent Software Vendor developing software and services for others, an enterprise which deploys home-grown applications, or a developer looking for an easy to deploy messaging component, you can use Service Bus in your topology. With this release we’ve improved the hosting capabilities for enterprises and service providers enabling new hosting topologies.

Scenario 1: Application Messaging Patterns with Service Bus.

To enable a wide variety of messaging scenarios, Service Bus provides message queues and “Publish/Subscribe” topics.

A queue is a message store in which messages are ordered by send date. One or multiple senders can send messages into a queue, and one or multiple receivers can read and remove messages from the queue. Once a receiver has received a message, that message cannot be received by another receiver.

Typically, queues are used for:

  • Load leveling: Receiver can process messages at its own pace.
  • Temporal decoupling: Sender is not blocked if receiver is offline.
  • Load balancing: Multiple receivers compete for messages; auto load balancing.

A topic can have multiple subscriptions and each subscription behaves like a queue. One or multiple senders can send messages into a topic. From there, each message is copied into each of the subscriptions. If receivers receive from different subscriptions, they each get a copy of the message. The user can define filters which determine which message is copied into which subscription.

Typically, topics are used for

  • Message distribution: Deliver the same message to more than one receiver.
  • Message filtering: Subscribers can filter messages according to business logic.
  • Message partitioning: Using filters, receiver get mutually exclusive slices of the message stream.

Messaging with Service Bus: Building Loosely Coupled Application

In a tightly coupled system, if any one of the components fails, the whole system fails and creates bad user experiences. Communication between components is usually based on synchronous or asynchronous calls to perform a task.

For example, consider a retailer application performing calls from a store front-end (web application) to back-end services like shipping and tracking. See Figure 1 below.


Figure 1: Tightly coupled application.

The front-end and back-end applications can be loosely coupled by introducing a message queue. The store front-end sends shipping requests to the queue, and, once a request is queued, the store front-end sends an acknowledgement to the user that confirms the order. The shipping service fetches orders from the queue at its own pace. If a spike of orders arrives and the shipping service falls behind, or if the shipping service is temporarily unavailable, the store frontend is still able to process new orders. At the same time the shipping service can still process orders already in the queue in case the store frontend application is down.

Scaling a loosely coupled application (see Figure 2 and 3 below) is simple. The application may consist of multiple instances of the store frontend or the shipping service. The queue enables multiple senders and receivers to send messages into (or receive messages from) the queue. At the same time the queue guarantees that each message will be processed only once. Monitoring the queue length enables you to determine whether you need to scale your application.


Figure 2: Loosely coupled application.


Figure 3: Scaling a loosely coupled application.

Messaging with Service Bus: Publish-Subscribe Patterns

In some systems the same order must be processed by multiple, independent services. Besides shipping, we may need each order to be processed by a CRM system. Some of the orders are to be processed by the fraud detection system as well. By replacing the queue with a topic and multiple subscriptions our shipping service will continue to receive a copy of each order while the CRM and fraud detection systems receive additional copies of these orders. Since the fraud detection system wants to inspect only a subset of the orders, a filter is defined on the fraud detection’s subscription (see Figure 4 below). The filtering can be done on any property of the order, such as the purchase price.


Figure 4: Publish-subscribe.

Messaging with Service Bus: Cross-Platform Interoperability

Because applications can interface with Service Bus in different ways, it supports three communication protocols:

  • Service Bus Messaging Protocol (SBMP)
    This is a proprietary SOAP-based protocol on TCP that is feature-rich and efficient. The Service Bus Messaging API, which is exposed by the Azure .NET SDK , allows a client application to communicate with Service Bus via SBMP. The Azure .NET SDK also exposes a WCF NetMessagingBinding .
  • Advanced Message Queuing Protocol (AMQP)
    This is an open protocol specified by an international standardization body. Service Bus implements AMQP 1.0, which is the current version of the standard. Similar to SBMP, the Azure .NET SDK allows an application to communicate with Service Bus via AMQP. In addition to the Azure .NET SDK, other third-party client implementations are available for various languages, such as Apache Proton-C, Apache Qpid, or Java/JMS AMQP 1.0 (see Figure 5 below). All AMPQ 1.0 clients can communicate with any messaging server or service that implements AMPQ 1.0. More information on Service Bus and AMQP is available here .
  • HTTP/HTTPS
    This allows a language-agnostic way to access Service Bus. HTTP is available for .NET, Visual Basic, Python, PHP, Java, Node.js, and other languages. All basic Service Bus functionality is available via HTTP/HTTPS. Some of the advanced features, such as sessions, are available only via SBMP or AMQP.


Figure 5: Languages and protocols supported by Service Bus.

Traditionally, message-oriented middleware products have used proprietary protocols for communication between client applications and brokers. This means that once you’ve selected a particular vendor’s messaging broker, you must use that vendor’s libraries to connect your client applications to that broker. This results in a "lock-in" to that vendor since porting an application to a different product requires re-coding all the connected applications.

Furthermore, connecting messaging brokers from different vendors is tricky and typically requires application-level bridging to move messages from one system to another, and to translate between their proprietary message formats.

AMQP 1.0 is an efficient, reliable, wire-level messaging protocol that can be used to build robust, cross-platform, messaging applications. The protocol has a simple goal: Define the mechanics of the secure, reliable, and efficient transfer of messages between two parties.

With the release of Service Bus 1.1, we are happy to announce that AMQP 1.0 support is now available in Service Bus .

Adding the support for AMQP 1.0 messaging protocol enables our customers to experience messaging in new ways. One of the key new scenarios enabled in this release is exchanging messages between applications written in multiple platforms running on multiple Operating Systems.

Figure 6 (see below) demonstrates the rich connectivity patterns that are now enabled by Service Bus.


Figure 6: Connectivity scenario involving various programming languages.


Scenario 2: Manage Messaging Entities Across Clouds

Innovation at the infrastructure layer has made it possible for organizations to start acting like cloud vendors by offering subscription-based IT resources to their business groups. In addition, service providers can now offer more advanced cloud services like Platform-as-a-Service (PaaS) and even Software-as-a-service (SaaS).

In this new world of connected services and mobile workforces, deciding on your cloud strategy can impact the entire organization – not just your IT spending structure.

With Service Bus 1.1 for Windows server and the Windows Azure Pack, we adopted a key principle when it comes to someone’s cloud strategy: consistency in the Service Bus tenant experience across multiple clouds.Consistency in the Service Bus tenant experience across multiple clouds.

In other words, the scenarios revolving Brokered Messaging (like loosely coupling with queues and publish-subscribe with topics) are consistent (but not necessarily identical) across the multiple cloud offerings.

Consistency across clouds takes shapes in various aspects of using Service Bus:

  1. Same Client SDK being used in Windows Azure as well as on-premises.
    Keep in mind that due to the differences in the release cadence, there will be points in time where the latest SDK for Windows Azure is newer than the one supported in a private cloud. Regardless, there will always be a version of the SDK which is supported by both.
  2. Same authorization model for clients based on shared secrets.
    While there are additional authentication mechanisms supported in the public cloud (such as ACS) as well as on-premises (Windows Integrated Security), using shared access secrets is consistent between the offerings.
  3. Switch to the Service Bus of choice with a change of configuration.
    The SDK supports using a connection string in order to connect to Service Bus. This connection string could be read from configuration or fed to the application in runtime.
  4. Self-service tenant portal consistent to the Windows Azure portal.
    A web-based management portal to create your subscription, service bus namespace and entities (queues and topics).
  5. Support for the Windows Azure PowerShell Cmdlets with hosted Service Bus.

Next, we will explain how the Service Bus self-service tenant experience follows the one available in Windows Azure – as well as the consistent experience for the developers’ using Service Bus with their application.

The Tenant Experience


Figure 7: Tenant experience.

Subscriptions, Plans and Service Bus Namespaces

When creating a subscription in the Windows Azure Pack and selecting a plan to use, the tenant portal reflects the services available with this subscription. In the case where the plan chosen had a Service Bus cloud enabled with it (see Figure 8 below), the tenant sees Service Bus available in the portal and can then create a Service Bus namespace. Windows Azure Pack subscriptions and plans where already discussed in one of the earlier posts in this series.


Figure 8: Creating a Service Bus namespace.

Create Service Bus Entities – Queues and Topics

In order to create messaging entities such as queues and topics, Service Bus requires you to create a namespace first. A service namespace is used for addressing, isolation, and management the underlying messaging entities. All Service Bus messaging entities are created within the scope of a service namespace.

Creating a queue with the self-service portal is easy and straightforward. With the ‘quick create’ function you simply specify the name of the queue as well as the name of the namespace (see Figure 9 below). This quick create experience will create a new namespace in case one is not already selected.


Figure 9: Creating Service Bus queues and topics.

Set Permissions at the Level of a Queue

Service Bus 1.1 for Windows Server supports configuring authentication using the following:

  • Windows Integrated Security to authenticate users based on their domain credentials.
  • Shared Access Secrets to authenticate users based on a shared secret.

Service bus support authorization rules at two levels:

  1. Namespace level authorization is applicable to all entities (queues and topics) defined in the scope of this namespace.
  2. Entity level authorization is scoped to a single entity. Use entity level authorization in integration scenarios where an application needs access to a subset of the entities in the namespace.

Each authorization rule includes one (or more) permissions , including: Manage, Send, and Listen (see Figure 10 below).


Figure 10: Defining authorization rules for the entities of a namespace.

Basic Queue Monitoring

When creating a messaging entity, applications may send and receive messages. The self-service tenant portal exposes basic monitoring attributes for each entity such as length and last accessed time, which indicate when a message was sent or received (see Figure 11 below).

For more advanced queries you can use the Service Bus API to issue queries like: “Get me all queues which have more than 10 messages.”


Figure 11: Monitoring queues or topics.

The Developer Experience

Consistency within public and private clouds begins by using the same client SDK when developing applications with Service Bus. In fact, you don’t need to change your application or rebuild it if you wish to switch between environments. In other words, by changing a single entry in a configuration file, you select which broker to use: Private, hosted, or public cloud.

In addition, Service Bus 1.1 for Windows Server supports a local deployment for development purposes only where you install Service Bus locally on a client Operating System using an Express Database.

A Complete End-to-End experience sample can be found here .

Connecting to Service Bus

As mentioned above, a single configuration entry specifies which broker to use. We call it the Service Bus connection string . When creating a new project in Visual Studio and adding a reference to the Service Bus SDK via the NuGet Package Manager , a new entry is added to your configuration files (app.config or web.config) with an empty connection string.

When deploying the application, you will replace the connection string with the one pointing to your Service Bus cloud, namespace, as well as security settings.

<appSettings>

<!-- Service Bus specific app settings for messaging connections -->

<add key="Microsoft.ServiceBus.ConnectionString" value="Endpoint=sb://[your namespace].servicebus.windows.net;SharedSecretIssuer=owner;SharedSecretValue=[your secret]" />

</appSettings>

Sending Messages

While Service Bus offers many advanced messaging features, the simplest scenario is sending and receiving messages.

Sending a message requires the application to connect to Service Bus by using the connection string as well as providing an entity (queue or topic) to send the message to. The following example uses the connection string provided in the configuration file to connect to a topic whose name is specified in a local variable.

// creates a topic client with a provided topic name.

TopicClient topicClient = TopicClient.Create(ServiceBusTopicName);

// creates a simple brokered message and send it over.

topicClient.Send(new BrokeredMessage("Hello World"));

Note that the topic needs to be created prior to using it. This

Receiving Messages

When sending a message to a queue or topic it remains there waiting to be consumed (received). With Service Bus 1.1 for Windows Server and the Windows Azure Pack, we have simplified the way an application receives messages, and we have introduced an event-driven programing model. In this model, you specify what is expected to be done with messages and the SDK takes care of the rest.

The following code snippet shows the simplest way to consume messages from a Service Bus subscription.

SubscriptionClient subsClient = SubscriptionClient.Create(ServiceBusTopicName, subsName);

subsClient.OnMessage((receivedMessage) =>

{

Console.WriteLine(string.Format("Processing recived Message: Id = {0}, Body = {1}",

receivedMessage.MessageId, receivedMessage.GetBody<string>()));

});

Note that this not a complete sample. For example, it lacks exception handling as well as performance optimization. Still, it demonstrates just how simple it is to consume messages from Service Bus.

Scenario 3: Hosting Alternatives with Service Bus

With the release of Windows Server 2012 R2 and the Windows Azure Pack, we’ve identified several key deployment scenarios where Service Bus was used:

  1. Locally Hosted & Managed
    This scenario is found within enterprises where a local IT team manages multiple deployments and each is dedicated for a different application or business unit. This scenario is the first time an administrator experience is separated from the tenant’s.
  2. Shared across multiple applications
    This is a common scenario with larger organizations where multiple applications are using the same Service Bus instance. In this scenario applications may, or may not, exchange messages between themselves. This topology calls for scaling the Service Bus deployment as well as introducing multiple tenants to Service Bus management.
  3. Hosted & Dedicated in a Public Cloud
    In this scenario, hosters who provide IT services are looking for ways to offer PaaS services including messages. As a part of the Windows Azure Pack, Service Bus supports managing multiple deployments from a single portal, separation of a service provider from a tenant portal experience, as well as plans and subscriptions to create isolation between tenants.

In addition, customers are also looking for a ‘self-hosted’ broker in the following cases:

  1. Developers Environment
    Service Bus is hosted on a developer’s machine (potentially virtual) to enable applications development in a local environment. The challenge in such a topology is to enable a lightweight deployment which includes the runtime components only.
  2. Embedded with the application
    In this scenario Software Vendors deploy their solution (including Service Bus) on dedicated servers. In addition to a lightweight deployment of runtime messages only, this topology requires a way to automate Service Bus deployment and management with scripts and APIs.

In addition to the topologies mentioned above, Service Bus is fully supported by the Windows Azure Infrastructure-as-a-Service (IaaS) including support for SQL Azure .

Next, we will explain how the Service Bus architecture fits into the Windows Azure Pack overall architecture while still enabling a lightweight deployment of the messaging runtime components. We will also describe how the Service Provider experience supports hosted scenarios (either shared or dedicated).

Service Bus Architecture


Figure 12: Service Bus architecture.

Some key requirements of the Service Bus architecture include:

  • Service Bus requires a 2008 R2 SP1 or higher 64-bit Microsoft Operating System.
  • Additional platform components are Microsoft .NET Framework 4.0 PU3 and Windows PowerShell 3.0.
  • Being a durable messages store, Service Bus requires SQL Server 2008 R2 SP2 or higher.
  • Service Bus setup installs the following local services: Windows Fabric, Service Bus Gateway, Message Broker, and the Service Bus Management APIs (resource provider).
  • External management components such as the Windows Azure Pack are potentially installed separately on a different server.

The Service Provider Experience

With Service Bus 1.1 for Windows Server and the Windows Azure Pack, we introduced the service provider experience.

In previous releases, we supported an administrator with a set of PowerShell CmdLets for configuration and a Management Pack for monitoring. As we began to plan for R2, customer feedback was clear: They wanted a self-service experience for their tenants and they needed a way to manage multiple deployments with different scale and SLA – and they wanted this all under the same portal.

With these needs in mind, we have aligned the service provider experience of Service Bus with the rest of the services enabled in the Windows Azure Pack by providing the following capabilities:

  • Automated deployment of a new Service Bus cloud while selecting resource pools to use for compute, as well as databases providing different level of SLAs.
  • The ability to glimpse Service Bus health, scale, and usage in the service provider’s portal.
  • Support for offers and tenant subscriptions by adding Service Bus resources to the Windows Azure Pack plan.

The Service Provider experience, which has already been discussed here , consists of the following three steps (see Figure 13 below):

  1. Deploy the Windows Azure Pack and enable the administrator’s portal as well as tenant’s portal.
  2. Service Bus cloud setup (either automated or manual) and the creation of a trust relationship between Service Bus cloud and the portal.
  3. Author a plan and add Service Bus resources (which cloud to use).


Figure 13: Service provider experience.

Connect to an Existing Service Bus Cloud

As noted above, you may be automating the deployment of a Service Bus with the Windows Azure Pack automation capabilities. However, in case you are manually installing Service Bus, or even upgrading from an older version, you need to connect your Service Bus deployment with the Service Provider’s portal.

From the portal’s main screen, just click ‘ New’ followed by ‘ Service Bus Cloud ’ to select a Service Bus cloud to connect (see Figure 14 below).

Figure 14: Connecting to an existing Service Bus cloud.

Like all the Windows Azure Pack services, Service Bus exposes two sets of REST APIs to be used by the Windows Azure Pack portals. These APIs are authenticated with two sets of credentials which you need to provide when connecting to a Service Bus cloud.

Basic Health Monitoring of a Service Bus Cloud

When connecting a Service Bus cloud to the Service Provider portal (see Figure 15 below), an administrator can list all the clouds, see basic health data from each node, and monitor the messaging databases for health and space (see Figure 16 below).


Figure 15: Connecting to a Service Bus cloud.


Figure 16: Monitoring Service Bus messaging databases.

Monitor Service Bus Health with System Center Operations Manager

Like many other cloud services, health monitoring of Service Bus is available with System Center Operations Manager (see Figure 17 below). The Service Bus Management Pack monitors the cloud’s health including status/underlying databases, hosts, and services.

Based on a rich set of monitoring rules and built-in alerts, with System Center Operations Manager an administrator is able to detect service related issues and their root cause.


Figure 17: Monitoring Service Bus in System Center.

Next Steps

Version history
Last update:
‎Sep 07 2018 10:22 PM
Updated by: