Introducing Queues and Topics in Azure Service Bus

In 2007, Microsoft unveiled a new vision called “Software + Services” that would fundamentally change the way that both Microsoft and their customers build software and have a gradual, yet marked ripple effect throughout the software giant’s entire strategy.

What inspired this shift in strategy at Microsoft is the same impetus for organizations of all shapes and sizes striving to take advantage of the tremendous opportunities for interconnectivity offered by the web and the economies of scale rendered by platforms that embrace interoperability.

Software + Services: A Vision

Microsoft’s shift in strategy was the maturation of an early vision initially embryonically outlined in a landmark 2005 memo by then Chief Architect Ray Ozzie entitled, “The Internet Services Disruption,” in which he addressed his executive peers and direct reports writing (see sidebar, “The Internet Services Disruption”):

“Computing and communications technologies have dramatically and progressively improved to enable the viability of a services-based model. The ubiquity of broadband and wireless networking has changed the nature of how people interact, and they’re increasingly drawn toward the simplicity of services and service-enabled software that ‘just works.’ Businesses are increasingly considering what services-based economics of scale might do to help them reduce infrastructure costs or deploy solutions as-needed and on subscription basis.“

This early memo manifested itself into the “Software + Services” vision first delivered nearly two years later at MIX 07 (see sidebar “Software + Services”):

“It’s our aspiration to create tools and platforms that will make your lives as developers easier, more productive, and profitable, in developing a software plus services solution. So you’ll have to be the judge as to whether we’ve succeeded in these aspirations.”

Ozzie went on to say:

“This software plus service pattern is very powerful, and it’s great for the user. It gives the user tremendous flexibility. We see this pattern in many of our own apps in-house, and I expect that we’ll see it in many of yours. It brings together the best of the Web, the best of the desktop, and the best of the device always using the service as a hub.”

Since 2005, investments in this vision have included presentation technologies for building rich, interconnected applications on the desktop like WPF, as well as Silverlight and ASP.NET MVC for building rich, perennially connected applications on the browser. In addition, advancements in distributed messaging and middleware capabilities with the introduction of WCF and continued investment in BizTalk Server, while rebuilding Microsoft’s framework for building long-running, composite solutions (WF), have made connecting and composing heterogeneous applications and systems more tenable than ever before.

Still, up until recently, while significant, these evolutions of the platform have fallen short of truly delivering on the Software + Services promise.

Indeed, for nearly a decade, organizations of all shapes and sizes have been applying service-oriented architecture (SOA) with varying degrees of sophistication (and success). Even where SOA has been successful, practitioners have traditionally been handicapped by the friction resulting from the non-interchangeable roles of client and service. For example, once a client learns the URI of a service endpoint, it consumes the service by making a request for which it either expects a response or no response at all (in the case of a one-way or datagram exchange). In order for the URI to be addressable and consumable by the client, the service must reside on the same network, or be routed to a different network via a traditional router or the Internet.

We’ve been using this model for exposing, composing and consuming services across network boundaries for almost two decades. The client can live anywhere and on any platform provided it can call a service over port such and such, but it is nearly impossible for a client living in a different network to call a service without some hosting or heavy infrastructure work that enables the endpoint to be exposed and consumed across a heterogonous network. These limitations have hampered the true realization of Software + Services by unnecessarily elevating the service to an entity that can only live within the walled garden of the enterprise or stood up by some expensive infrastructure. Azure Service Bus levels the playing field making Software + Services a reality.

The Lazarus Effect

Despite losing some of its luster due in part to the inherent complexity of middleware coupled with the insatiable need for our industry to oversaturate the market with hype and false promises, the need for SOA in composing solutions across the boundaries of the traditional enterprise has never been greater. Chris Howard of Gartner Research agrees. In his report, “The Lazarus Effect: SOA Returns” (see sidebar by the same name), Howard writes:

“To achieve the goals of a hybrid data center with processes spanning the internal/external boundary, service orientation is a prerequisite. This doesn’t mean that sophisticated services and mature SOA must already exist before an enterprise can venture into the cloud, but rather that architecture strategies that involve cloud computing must have a service orientation foundation.”

Fittingly, Azure Service Bus has much to do with enabling a new generation of hybrid computing, which in my view represents the realization of Software + Services and SOA to their full potential.

Azure Service Bus Relay Messaging

Microsoft is a platform company at its core. One of the things that make Windows Azure so compelling is that it is built on a single unified platform: Windows and .NET.

In December 2009, Microsoft released a new Internet-scale Service Bus that finally made Software + Services truly tenable. By applying similar techniques that have allowed chat software to traverse traditional boundaries inherent to modern networks (software firewalls, hardware firewalls, routing challenges due to the lack of public IP addresses and proliferation of NAT) and leverage the largest, most sophisticated and resilient network ever built (the Internet), Service Bus democratized the ability to stand up a service from anywhere in the world, ushering in a new era of truly hybrid computing.

In a nutshell, Service Bus provides a highly robust messaging fabric hosted by Windows Azure that serves as a relay between two (or more) endpoints. A client and service (or services) establish an outbound, bi-directional socket connection over either TCP or HTTP on the relay and thus, messages from the client tunnel their way through the relay to the service. In this way, both the client and service are really peers on the same messaging fabric. The service receives messages from the relay on behalf of the client and as such, the roles can easily be reversed. This pattern unlocks the power of Software + Services, which enables true hybrid enterprise composition allowing clients to communicate with services and vice-a-versa beyond the enterprise and literally from anywhere in the world, provided an Internet connection exists.

This significant unlocking technology aside, what makes Azure Service Bus so practical is that the relay capabilities are modeled on WCF. To on-ramp Service Bus, the WCF developer need only choose the binding corresponding to the channel shape and protocols of interest. Support for REST and SOAP over HTTP as well as SOAP over TCP are provided by the relay bindings:

• BasicHttpRelayBinding: Complements BasicHttpBinding for WS-I Basic Profile Request-Response MEP over HTTP/S
• WebHttpRelayBinding: Complements WebHttpBinding for REST Request-Response MEP over HTTP/S
• WS2007HttpRelayBinding: Complements WsHttpBinding for WS-* Request-Response MEP over HTTP/S
• NetTcpRelayBinding: Complements NetTcpBinding for Request-Response MEP over TCP
• NetOneWayRelayBinding: Smart, optimized Datagram messaging over bi-directional TCP
• NetEventRelayBinding: Smart, optimized Multicast messaging over bi-directional TCP

Note: This article is not an introduction to Service Bus or Relay Messaging as it is already a well-established product that includes key capabilities for exposing services beyond traditional trust boundaries. However, if Service Bus is new to you, I recommend reading, “A Developer’s Guide to the Azure Service Bus” (see the sidebar) as I’ll be making some assumptions about your knowledge as I talk about the exciting new Brokered Messaging capabilities in Service Bus.

By: Rick Garibay

With over 13 years’ experience delivering solutions on the Microsoft platform across industry sectors such as finance, transportation, hospitality and gaming, Rick is a developer, architect, speaker and author on distributed technologies and is the General Manager of the Connected Systems Development Practice at Neudesic.

Rick specializes in distributed technologies such as Microsoft .NET, Windows Communication Foundation, Workflow Foundation, and Windows Azure to deliver business value and drive revenue while reducing operational costs.

Rick serves as a member of the Microsoft Application Platform Partner Advisory Council and is an advisor to Microsoft in a number of capacities including long-time membership on the Business Platform and Azure Technology Advisors group. As a five-time Microsoft Connected Systems MVP, Rick is an active speaker, writer and passionate community advocate in the national .NET community. Rick is the Co-Founder of the Phoenix Connected Systems User Group, celebrating four years in operation.

Recent presentations include talks at the Microsoft SOA and Business Process Conference in Redmond, WA, Microsoft TechEd, DevConnections, .NET Rocks, Desert Code Camp, and numerous Microsoft events throughout North America. Rick is a frequent contributor to industry publications such as CODE Magazine, and is the co-author of Windows Server AppFabric Cookbook by Packt Press.

When not immersed in the work he loves, Rick enjoys mountain biking and spending time with his wife, Christie and two children, Sarah and Ricky.