REST

Common Service Bus Queue Operations with the REST API

Rick G. Garibay — Thu, 19 Jan 2012 16:23:08 GMT

Azure Service Bus Brokered Messaging provides durable pull-based pub-sub, complimenting it’s older sibling Relay Messaging which uses a push messaging model. While both enable hybrid composition across traditional business, trust and network boundaries, they provide unique capabilities in and of themselves.

As with Relay Messaging, Brokered Messaging provides first class support for WCF with the NetMessagingBinding, but expands the developer surface to general .NET and cross-platform/mobility scenarios by offering the .NET Client and REST API respectively.

Of the 3 APIs, the .NET Client API is the most robust and seems to be the most documented.

The simplicity of the WCF programming model (the illusion that messages are being pushed to your endpoint) is balanced with some restrictions that naturally fall out of the scope of one-way messaging including queue/topic/subscription/rule creation and support for peek lock.

In this regard, while not as robust as the .NET Client API, the REST API offers a more comprehensive feature set and when working on solutions that must be interoperable across client platforms or due to other restrictions, the REST API is a great choice.

Microsoft has documented the REST API in the Service Bus REST API Reference, but there are not a ton of imperative examples out there that show WebClient or HttpWebRequest, so the purpose of this post is to share some nitty gritty examples of how to get some of the most common operations done in C#.

Please note that my goal is not to be elegant or use the tersest or most fluid syntax possible in this samples, but rather to get some quick and dirty examples out there, well, quickly.

As such, the unit tests should be self explanatory, but if you have any questions, please don’t hesitate to ask.

Feedback, comments related to the API or WebClient techniques welcome

   1:  using System;

   2:  using System.Text;

   3:  using System.Collections.Generic;

   4:  using System.Linq;

   5:  using Microsoft.VisualStudio.TestTools.UnitTesting;

   6:  using System.Collections.Specialized;

   7:  using System.Net;

   8:  using System.Runtime.Serialization.Json;

   9:  using System.Runtime.Serialization;

  10:  using System.IO;

11:

  12:  namespace RESTAPITests

  13:  {

  14:      [TestClass]

  15:      public class RESTAPITests

  16:      {

17:

  18:          static string serviceNamespace = "[NAMESPACE]";

  19:          static string issuerName = "owner";

  20:          static string issuerSecret = "[KEY]";

  21:          const string sbHostName = "servicebus.windows.net";

  22:          const string acsHostName = "accesscontrol.windows.net";

  23:          static string relativeAddress = "[Queue]";

  24:          static string baseAddress;

25:

26:

  27:          [TestMethod]

  28:          public void SendMessageShouldSucceedWithoutError()

  29:          {

  30:              string body = "foo";

31:

  32:              var token = GetToken(issuerName, issuerSecret);

33:

  34:              baseAddress = GetBaseAddress();

  35:              string fullAddress = baseAddress + relativeAddress + "/messages";

36:

  37:              WebClient webClient = new WebClient();

  38:              webClient.Headers[HttpRequestHeader.Authorization] = token;

  39:              webClient.UploadData(fullAddress, "POST", Encoding.UTF8.GetBytes(body));

40:

  41:          }

42:

  43:          [TestMethod]

  44:          public void PeekLockMessageShouldReturnLockId()

  45:          {

  46:              var token = GetToken(issuerName, issuerSecret);

47:

  48:              baseAddress = GetBaseAddress();

49:

  50:              // Read and lock the message. Unless released, the lock will expire within the configured lock duration (on the queue)

  51:              string fullAddress = baseAddress + relativeAddress + "/messages/head";

52:

  53:              WebClient webClient = new WebClient();

  54:              webClient.Headers[HttpRequestHeader.Authorization] = token;

  55:              webClient.UploadData(fullAddress, "POST", new byte[0]{});

56:

  57:              var props = webClient.ResponseHeaders["BrokerProperties"];

58:

  59:              // Deserialize the JSON header to a simple class

  60:              DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(BrokerProperty));

  61:              using (MemoryStream stream = new MemoryStream(Encoding.Unicode.GetBytes(props)))

  62:              {

  63:                  var result = (BrokerProperty)serializer.ReadObject(stream);

64:

  65:                  Assert.IsNotNull(result.LockToken);

  66:              }

67:

  68:          }

69:

  70:          [TestMethod]

  71:          public void PeekLockMessageAndAbandonShouldSucceed()

  72:          {

  73:              var token = GetToken(issuerName, issuerSecret);

74:

  75:              baseAddress = GetBaseAddress();

76:

  77:              // Read and lock the message. Unless released, the lock will expire within the configured lock duration (on the queue)

  78:              string fullAddress = baseAddress + relativeAddress + "/messages/head";

79:

  80:              WebClient webClient = new WebClient();

  81:              webClient.Headers[HttpRequestHeader.Authorization] = token;

  82:              webClient.UploadData(fullAddress, "POST", new byte[0] { });

83:

  84:              var props = webClient.ResponseHeaders["BrokerProperties"];

85:

  86:              // Deserialize the JSON header to a simple class

  87:              DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(BrokerProperty));

88:

  89:              using (MemoryStream stream = new MemoryStream(Encoding.Unicode.GetBytes(props)))

  90:              {

  91:                  var result = (BrokerProperty)serializer.ReadObject(stream);

92:

  93:                  // Bail on the message, release the lock so it is available for another consumer

  94:                  fullAddress = baseAddress + relativeAddress + String.Format("/messages/{0}/{1}", result.MessageId, result.LockToken);

  95:              }

96:

  97:              webClient = new WebClient();

  98:              webClient.Headers[HttpRequestHeader.Authorization] = token;

  99:              webClient.UploadData(fullAddress, "PUT", new byte[0] { });

 100:

 101:          }

 102:

 103:          [TestMethod]

 104:          public void PeekLockMessageAndCompleteShouldSucceed()

 105:          {

 106:              var token = GetToken(issuerName, issuerSecret);

 107:

 108:              baseAddress = GetBaseAddress();

 109:

 110:              // Peek lock the message

 111:              string fullAddress = baseAddress + relativeAddress + "/messages/head";

 112:

 113:              WebClient webClient = new WebClient();

 114:              webClient.Headers[HttpRequestHeader.Authorization] = token;

 115:              webClient.UploadData(fullAddress, "POST", new byte[0] { });

 116:

 117:              var props = webClient.ResponseHeaders["BrokerProperties"];

 118:

 119:              DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(BrokerProperty));

 120:

 121:              using (MemoryStream stream = new MemoryStream(Encoding.Unicode.GetBytes(props)))

 122:              {

 123:                  var result = (BrokerProperty)serializer.ReadObject(stream);

 124:

 125:                  // Complete the read operation, releasing the lock and deleting the message from the queue

 126:                  fullAddress = baseAddress + relativeAddress + String.Format("/messages/{0}/{1}", result.MessageId, result.LockToken);

 127:              }

 128:              webClient = new WebClient();

 129:              webClient.Headers[HttpRequestHeader.Authorization] = token;

 130:              webClient.UploadData(fullAddress, "DELETE", new byte[0] { });

 131:          }

 132:

 133:          [TestMethod]

 134:          public void DecodeJsonToTypeShouldAllowEasyExtractionOfProps()

 135:          {

 136:

137: string payload = @"{""DeliveryCount"":3,""LockToken"":""4a1d4c96-9837-42a9-ad91-3ecf704eec40"",""LockedUntilUtc"":""Thu, 19 Jan 2012 01:22:44 GMT"",

""MessageId"":""4a4fa2c7d87a40a7b799625b9de69e42"",""SequenceNumber"":2,""TimeToLive"":922337203685}";

 138:

 139:              DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(BrokerProperty));

 140:

 141:              using (MemoryStream stream = new MemoryStream(Encoding.Unicode.GetBytes(payload)))

 142:              {

 143:                  var result = (BrokerProperty)serializer.ReadObject(stream);

 144:

 145:                  Assert.IsNotNull(result.MessageId);

 146:              }

 147:

 148:          }

 149:

 150:          [DataContract]

 151:          public class BrokerProperty

 152:          {

 153:              [DataMember]

 154:              public string DeliveryCount { get; set; }

 155:              [DataMember]

 156:              public string LockToken { get; set; }

 157:              [DataMember]

 158:              public string LockedUntilUtc { get; set; }

 159:              [DataMember]

 160:              public string MessageId { get; set; }

 161:              [DataMember]

 162:              public string SequenceNumber { get; set; }

 163:              [DataMember]

 164:              public string TimeToLive { get; set; }

 165:          }

 166:

 167:

 168:          // Helper

 169:          private static string GetBaseAddress()

 170:          {

 171:              return baseAddress = "https://" + serviceNamespace + "." + sbHostName + "/";

 172:          }

 173:

 174:          // Helper, warmly borrowed from Service Bus Management Sample :-)

 175:          private static string GetToken(string issuerName, string issuerSecret)

 176:          {

 177:              var acsEndpoint = "https://" + serviceNamespace + "-sb." + acsHostName + "/WRAPv0.9/";

 178:

 179:              // Note that the realm used when requesting a token uses the HTTP scheme, even though

 180:              // calls to the service are always issued over HTTPS

 181:              var realm = "http://" + serviceNamespace + "." + sbHostName + "/";

 182:

 183:              NameValueCollection values = new NameValueCollection();

 184:              values.Add("wrap_name", issuerName);

 185:              values.Add("wrap_password", issuerSecret);

 186:              values.Add("wrap_scope", realm);

 187:

 188:              WebClient webClient = new WebClient();

 189:              byte[] response = webClient.UploadValues(acsEndpoint, values);

 190:

 191:              string responseString = Encoding.UTF8.GetString(response);

 192:

 193:              var responseProperties = responseString.Split('&');

 194:              var tokenProperty = responseProperties[0].Split('=');

 195:              var token = Uri.UnescapeDataString(tokenProperty[1]);

 196:

 197:              return "WRAP access_token=\"" + token + "\"";

 198:          }

 199:

 200:      }

 201:

 202:  }

Azure Service Bus Connect EAI and EDI “Integration Services” CTP

Rick G. Garibay — Fri, 16 Dec 2011 18:46:51 GMT

I am thrilled to share in the announcement that the first public CTP of Azure Service Bus Integration Services is now LIVE at http://portal.appfabriclabs.com.

The focus of this release is to enable you to build hybrid composite solutions that span on-premise investments such as Microsoft SQL Server, Oracle Database, SAP, Siebel eBusiness Applications, Oracle E-Business Suite, allowing you to compose these mission critical systems with applications, assets and workloads that you have deployed to Windows Azure, enabling first-class hybrid integration across traditional network and trust boundaries.

In a web to web world, many of the frictions addressed in these capabilities still exist, albeit to a smaller degree. The reality is that as the web and cloud computing continue to gain momentum, investments on-premise are, and will continue to be critical to realizing the full spectrum of benefits that cloud computing provides both in the short and long term.

So, what’s in this CTP?

Azure Service Bus Connect provides a new server explorer experience for LOB integration exposing a management head that can be accessed on-prem via Server Explorer or PowerShell to create, update, delete or retrieve information from LOB targets. This provides a robust extension of the Azure Service Bus relay endpoint concept, which acts a LOB conduit (LobTarget, LobRelay) for bridging these assets by extending the WCF LOB Adapters that ship with BizTalk Server 2010. The beauty of this approach is that you can leverage the LOB Adapters using BizTalk as a host, or, for a lighter weight way approach, use IIS/Windows Server AppFabric to compose business operations on-premise and beyond.

In addition, support for messaging between trading partners across traditional trust boundaries in business-to-business (B2B) scenarios using is EDI is also provided in this preview, including AS2 protocol support with X12 chaining for send and receive pipelines, FTP as transport for X12, agreement templates, partners view with profiles per partner, resources view, and an intuitive, metro style EDI Portal.

Just as with on-premise integration, friction always exists when integrating different assets which may exist on different platforms, implement different standards and at a minimum have different representations of common entities that are part of your composite solution’s domain. What is needed is a mediation broker that can be leveraged at internet-scale, and apply message and protocol transformations across disparate parties and this is exactly what the Transforms capability provides. Taking an approach that will be immediately familiar to the BizTalk developer, a familiar mapper-like experience is provided within Visual Studio for interactively mapping message elements and applying additional processing logic via operations (functoids).

In addition, XML Bridges which include the XML One-Way Bridge and XML Request-Reply Bridge are an extension to the Azure Service Bus which supports critical patterns such as protocol bridging, routing actions, external data lookup for message enrichment and support for both WS-I and REST endpoints and any combination thereof.

As shown below in the MSDN documentation, “bridges are composed of stages and activities where each stage is a message processing unit in itself. Each stage of a bridge is atomic, which means either a message completes a stage or not. A stage can be turned on or off, indicating whether to process a message or simply let it pass through”.

Taking a familiar VETR approach to validate, extract, transform and route messages from one party to another, along with the ability to enrich messages by composing other endpoint in-flight (supported protocols include HTTP, WS-HTTP and Basic HTTP, HTTP Relay Endpoint, Service Bus Queues/Topics and any other XML bridge) the Bridge is a very important capability and brings very robust capabilities for extending Azure Service Bus as a key messaging broker across integration disciplines.

In reality, these patterns have no more to do with EAI than with traditional, contemporary service composition and become necessary once you move from a point-to-point approach and need to elegantly manage integration and composition across assets. As such, this capability acts as a bridge to Azure Service Bus that is very powerful in and of itself, even in non-EAI/EDI scenarios where endpoints can be virtualized increasing decoupling between parties (clients/services). In addition, this capability further enriches what is possible when using the BrokeredMessage property construct as a potential poor-man’s routing mechanism.

In closing, the need to address the impedance mismatch that exists between disparate applications that must communicate with each other is a friction that will continue to exist for many years to come, and while traditionally, many of these problems have been solved by expensive, big iron middleware servers, this is changing.

As with most technologies, often new possibilities are unlocked that are residual side-effects of something bigger, and this is certainly the case with how both innovative and strategic Azure Service Bus is to Microsoft’s PaaS strategy. Azure Service Bus continues to serve as a great example of a welcomed shift to a lightweight capability-based, platform-oriented approach to solving tough distributed messaging/integration problems while honoring the existing investments that organizations have made and benefiting from a common platform approach which is extremely unique in the market. And while this shift will take some time, in the long-run enterprises of all shapes and sizes only stand to benefit.

To get started, download the SDK & samples from http://go.microsoft.com/fwlink/?LinkID=184288 and the tutorial & documentation from http://go.microsoft.com/fwlink/?LinkID=235197 and watch this and the Windows Azure blog for more details coming soon.

Happy Messaging!

Getting the Most out of WCF 4.0 REST Today

Rick G. Garibay — Fri, 21 Oct 2011 06:09:10 GMT

WCF has supported HTTP and RESTful approaches to service design for some time now, and while there are some exciting new enhancements being worked on as part of the WCF Web API project, there is some pretty rich functionality in WCF 4.0 that is definitely worth taking advantage of if you need to build HTTP/REST services today, especially when hosting in Windows Server AppFabric.

There a number of differences to consider when working with REST services that require some special attention as compared to traditional SOAP services, and those differences are definitely noticeable when working with WCF. In this post, I’d like to highlight some of the most common capabilities that REST developers ask for and how to accomplish them in general and when hosting in IIS or Windows Server AppFabric. The WCF Web API improves upon some of the techniques I cover here and introduces new ones which I’ll be discussing in future posts.

The first thing you want to do when working with WCF REST is pick a project template. While WCF 4 supports REST out-of-the-box (including a number of improvements over previous versions and the alignment of out-of-band features first seen in the WCF Starter Kit), the default WCF templates are really designed for SOAP-based services and thus are rather lacking for supporting REST an an intuitive, F5 manner (again, this will get better).

Microsoft provides the WCF REST Service Application template via the Visual Studio 2010 Extension Manager. In addition to some useful scaffolding for providing an F5 experience, some fundamental code and configuration is provided as part of the template which is necessary for working with a host such as IIS or Windows Server AppFabric. Ron Jacobs also has a great template specifically designed for Server AppFabric that extends the functionality in this template to support end to end monitoring and provides a web-based test harness among other things. I definitely recommend that you check it out as well.

To keep things focused on the basic aspects of WCF REST 4.0, I’ve taken the WCF REST Service Application template with very minor modifications and created a simple read-only GET service to illustrate some of the most common things you’re likely to hit when starting out with REST in WCF 4.

Out of the box, the WCF REST Service Application template provides some basic scaffolding including a functional read-only (GET) REST service. While “SampleItem” is certainly not the most interesting domain, I am going to leave the sample unaltered for simplicity sake as we are going to focus more on the hosting aspects of WCF REST than the design and the code.

Once you create a project with the WCF REST Service Application template, there are 4 files that are created in the project:

The Service1.cs file includes the definition and implementation of the service.
The SampleItem.cs file includes the Data Contract that models a resource.
The Global.asax file defines some key events that we’ll hook into to enable dynamic routing.
The Web.config file includes some key configuration for enabling dynamic routing and supporting extension-less (svc-less) URIs among other things.

The first thing you’ll probably notice in the template is that its missing an .svc file. Most REST developers would rather work with clean URIs as opposed to having a file extension get in the way. Fortunately, with a little bit of help from ASP.NET, we can leverage some pretty sophisticated routing capabilities that not only allow us to eliminate the need for the .svc extension, but in addition enable us to factor our URIs across a number of services and have some pretty fine grained control over URI routes using a templated approach.

If you hit F5 at this point, the service will run in Cassini, generating a rather glum response (note that you may not see XML immediately depending on the browser you are using; a brute force approach is to view source or, in the case of IE9, which I am using here, leverage the browser targeting capabilities provided by the F12 developer tools):

If you take a look inside the Global.asax.cs files, you’ll see what makes this magic happen:

  1: RouteTable.Routes.Add(new ServiceRoute("Service1", new WebServiceHostFactory(), typeof(Service1)));
  2:

As shown above, the template automatically added an entry to the System.Web.Routing.RouteTable. The Add method takes a ServiceRoute instance for which we provide 3 parameters:

The first parameter is known as a route prefix and signals the root path that will be mapped to a given WCF service type. In this case, the URI segment of “Service1” will route to the Service1 class as specified in the third parameter.
The second parameter is also interesting. Unlike traditional SOAP services that use a ServiceHost, the WebServiceHostFactory was designed to deal with HTTP-based services exclusively.

This default code can immediately be improved upon in my opinion by replacing the route prefix with a simple empty string. This will invoke the GetCollection method in the service implementation which provides a nice, intuitive user experience when interacting with the service without knowing much about it.

Taking a look at the service class and the GetCollection method, you will see some familiar attributes, along with the AspNetCompatabilityRequirements attribute which, among other things enables support for routing:

  1:     [ServiceContract]
  2:     [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
  3:     [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
  4:     public class Service1
  5:     {
  6:         [WebGet(UriTemplate = "")]
  7:         public List<SampleItem> GetCollection()
  8:         {
  9:             // TODO: Replace the current implementation to return a collection of SampleItem instances
 10:             return new List<SampleItem>() { new SampleItem() { Id = 1, StringValue = "Hello" } };
 11:         }
 12:     }

All of this also requires that ASP.NET compatibility is enabled declaratively in the Web.config by setting the aspNetCompatibilityEnabled attribute to true in the serviceHostingEnvironment element:

  1:  <system.serviceModel>
  2:     <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
  3:     <standardEndpoints>
  4:       <webHttpEndpoint>
  5:            <standardEndpoint name="" helpEnabled="true" automaticFormatSelectionEnabled="true"/>
  6:       </webHttpEndpoint>
  7:     </standardEndpoints>
  8:   </system.serviceModel>

You will also notice that the web.config is absent of the boilerplate service and endpoint configuration including the address, binding and contract attributes. WCF 4 introduces the concept of default endpoints to simplify the approach for hosting services in WCF 4, which in effect automates the creation of common endpoint configurations for getting your WCF services up and running quickly and easily. Standard Endpoints build on this simplicity by providing common configurations packaged into an element and exercising convention over configuration. By using the WebHttpEndpoint standard endpoint, you are provided some common configuration knobs such as supporting multiple encoding types and help documentation that is automatically generated provided you enable the helpEnabled attribute in line 5 above:

While all of this works just fine in Cassini, it won’t work in IIS/Windows Server AppFabric as without the additional configuration I am going to cover next because it (rightfully) assumes that you are asking to browse the contents of the root directory which is fortunately forbidden unless you explicitly allow it:

Note that had I left the route prefix with the default “Service1”, a 404 would instead be thrown because without the correct modules, IIS has no way of routing this to the class by the same name.

The remedy to these problems is provided by setting the runAllManagedModulesForAllRequests attribute in the modules element to true, which ensures that any requests that come into the request pipeline that are not mapped to an extension are passed on to the modules in the pipeline for processing. Specifically, the route that was added to the Application_Start method implementation in the Global class will be used to resolve to the Service1 class by the UrlRoutingModule managed module which is registered using the configuration below and enables this routing for services that do not use the .svc extension and are hosted in IIS/Windows Server AppFabric:

  1:  <system.webServer>
  2:     <modules runAllManagedModulesForAllRequests="true">
  3:       <add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  4:     </modules>
  5:   </system.webServer>

It is possible, depending on your IIS configuration that the UrlRoutingModule has already been registered, in which case line 3 above is superfluous. If you comment it out and re-deploy, things will continue to work as expected unless you either remove it declaratively in the web.config or explicitly remove it from the Modules manager.

With this configuration in place, the service will result in the request being correctly routed and the response presented in the browser:

If you’re like me, you likely find the XML, or at least the root node abhorrent. We can improve upon this significantly by creating a second class to represent the SampleItem that inherits from the original List<SampleItem> found in the template and decorate it with a CollectionDataContract attribute.

  1:     [CollectionDataContract(Name = "SampleItems",Namespace = "")]
  2:     public class SampleItems : List<SampleItem>
  3:     {
  4: 
  5:     }

Further, if we override the Namespace by setting the Namespace parameter of the attribute and setting it to an empty string, we get a much nice, cleaner result:

Note: I have to credit this technique to Jon Flanders, who’s excellent book “Restful .NET” is where I first learned this technique a couple of years ago.

Some developers and administrators may be concerned about the potential performance implications that enabling the runAllManagedModulesForAllRequests attribute introduces for static requests such as HTML pages, image files, etc. since each of these requests must run through all of the configured modules unnecessarily. Fortunately, Microsoft introduced an alternative to this approach in a QFE Hotfix which enables dynamic routing without impacting static requests. You can download and install the Hotfix from here: http://support.microsoft.com/kb/980368. After installing the hotfix, three new handlers with a name prefix of ExtnesionlessUrlHandler are installed in IIS which correspond to 32, 64 bit and integrated modes and applied to all applications. With these handlers installed, you can remove or disable the runAllManagedModulesForAllRequests attribute and all routing will continue to function as expected provided the handlers remain registered as shown below.

As I was walking through the standard endpoint configuration, you may have noticed an attribute on the standard endpoint element called automaticFormattingEnabled. When set to true, this allows you to manipulate whether the service should return XML or JSON. According to MSDN, the determination is based on the following in order:

The media types in the request message’s Accept header.
The content-type of the request message.
The default format setting in the operation.
The default format setting in the WebHttpBehavior.

Using Fiddler, I’ve set the Accept header to application/json which has the result of returning JSON without me having to do anything to the service itself:

Of course, you can have the service return plain text or a stream, but to do so today, you need to implement a custom mechanism for passing the format you need such as a querystring and then writing some code to read it and return the appropriate expected format.

Finally, one of the biggest benefits of designing REST services, or services that leverage the HTTP protocol exclusively, is that you get all of the features inherent to the HTTP protocol including support for caching requests, or GET requests. By adding an attribute called AspNetCacheProfile to the GetCollection method and mapping the profile name in the web.config, I can leverage the caching capabilities in ASP.NET to cache GET requests:

  1: [WebGet(UriTemplate = "")]
  2: [AspNetCacheProfile("MyCacheProfile")]
  3: public SingleTracks GetCollection()
  4: {
  5:     return GetSingleTracks();
  6: }

As I hope I’ve shown, there is pretty strong support for REST in WCF 4, both in the box and as provided by the WCF REST specific templates which allows you to easily host your WCF REST services on any host, including Windows Server AppFabric which allows you to take advantage of all of the great management and monitoring capabilities it provides. New features in the WCF Web API will make it even easier to host HTTP/REST services with WCF, so watch this space for some upcoming posts and be sure to keep up with the latest developments on the WCF Community Site at http://wcf.codeplex.com/.

Azure AppFabric Service Bus Brokered Messaging GA & Rude CTP Diffs

Rick G. Garibay — Wed, 14 Sep 2011 16:46:52 GMT

Today at the Build conference in Anaheim California, Satya Nadella, President Server and Tools business announced general availability of the production release of AppFabric Queues and Topics, otherwise known as Brokered Messaging.

Brokered Messaging introduces durable queue capabilities and rich, durable pub-sub with topics and subscriptions that compliment the existing Relayed Messaging capabilities.

I covered Brokered Messaging following the May CTP release of Queues and followed up shortly with an overview and exploration of Topics (please see some other great resources at the end of this post).

Since then, there was a June CTP release which included the new AppFabric Application and no visible changes to Brokered Messaging, however since its release, the AppFabric Messaging team has been hard at work refining the API and behaviors based on feedback from Advisors, MVPs and the community at large.

Since I’ve already covered Queues and Topics in the aforementioned posts, I’ll dive right in to some terse examples which demonstrate the API changes. Though not an exhaustive review of all of the changes, I’ve covered the types that your most likely to come across and will cover Queues, Topics and Subscriptions extensively in my upcoming article in CODE Magazine which will also include more in-depth walk-throughs of the .NET Client API, REST API and WCF scenarios.

Those of you who have worked with the CTPs will find some subtle and not so subtle changes, but all in all I think all of the refinements are for the best and I think you’ll appreciate them as I have. For those new to Azure AppFabric Service Bus Brokered Messaging, you’ll benefit most from reading my first two posts based on the May CTP (or any of the resources at the end of this post) to get an idea of the why behind queues and topics and then come back here to explore the what and how.

A Quick Note on Versioning

In the CTPs that preceded the release of the new Azure AppFabric Service Bus features, a temporary assembly called “Microsoft.ServiceBus.Messaging.dll” was added to serve a container for new features and deltas that were introduced during the development cycle. The final release includes a single assembly called “Microsoft.ServiceBus.dll” which contains all of the existing relay capabilities that you’re already familiar with as well as the addition of support for queues and topics. If you are upgrading from the CTPs, you’ll want to get ahold of the new Microsoft.ServiceBus.dll version 1.5 which includes everything plus the new queue and topic features.

The new 1.5 version of the Microsoft.ServiceBus.dll assembly targets the .NET 4.0 framework. Customers using .NET 3.5 can continue using the existing Microsoft.ServiceBus.dll assembly (version 1.0.1123.2) for leveraging the relay capabilities, but must upgrade to .NET 4.0 to take advantage of the latest features presented here.

.NET Client API

Queues

May/June CTP	General Availability	Comments
ServiceBusNamespaceClientSettings	NamespaceManagerSettings	New class for encapsulating endpoint and security settings.
N/A	TokenProvider	New class for acquiring a WRAP token from ACS.
ServiceBusNamespaceClient	NamespaceManager	Root management object for creating Queues, Topics, Subscriptions.
Queue	QueueDescription	In May/June CTP, Topic / Queue / Subscription were management objects. All create/delete operations were moved to NamespaceManager and the state operations are now on TopicDescription/QueueDescription etc.
MessagingFactorySettings	MessagingFactorySettings	New class for encapsulating security settings.
MessagingFactory	MessagingFactory
BrokeredMessage	BrokeredMessage	No longer a factory. Simply instantiate a BrokeredMessage.
MessageSender	MessageSender	Optional, for use when you want to abstract away queue or topic.
MessageReceiver	MessageReceiver	Optional, for use when you want to abstract away queue or topic.

Below is a representative sample for creating, configuring, sending and receiving a message on a queue:

Administrative Operations

  1: 
  2:             // Configure and create NamespaceManager for performing administrative operations
  3:             NamespaceManagerSettings settings = new NamespaceManagerSettings();
  4:             TokenProvider tokenProvider = settings.TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(issuer,key);
  5:             
  6:             NamespaceManager manager = new NamespaceManager(ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespace, string.Empty), settings);
  7: 
  8:             // Check for existence of queues on the fabric
  9:             var qs = manager.GetQueues();
 10: 
 11:             var result = from q in qs
 12:                          where q.Path.Equals(queueName, StringComparison.OrdinalIgnoreCase)
 13:                          select q;
 14: 
 15:             if (result.Count() == 0)
 16:             {
 17:                 Console.WriteLine("Queue does not exist");
 18: 
 19:                 // Create Queue
 20:                 Console.WriteLine("Creating Queue...");
 21: 
 22:                 manager.CreateQueue(new QueueDescription(queueName) { LockDuration = TimeSpan.FromSeconds(5.0d) });
 23:                 
 24:             }

Runtime Operations

  1:             // Create and Configure Messaging Factory to provision QueueClient
  2:             MessagingFactorySettings messagingFactorySettings = new MessagingFactorySettings();
  3:             messagingFactorySettings.TokenProvider = settings.TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(issuer, key);
  4:             MessagingFactory messagingFactory = MessagingFactory.Create(ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespace, string.Empty), messagingFactorySettings);
  5:             
  6:             QueueClient queueClient = messagingFactory.CreateQueueClient(queueName, ReceiveMode.PeekLock);
  7: 
  8:             Order order = new Order();
  9:             order.OrderId = 42;
 10:             order.Products.Add("Kinect", 70.50M);
 11:             order.Products.Add("XBOX 360", 199.99M);
 12:             order.Total = order.Products["Kinect"] + order.Products["XBOX 360"];
 13: 
 14:             // Create a Brokered Message from the Order object
 15:             BrokeredMessage msg = new BrokeredMessage(order);
 16: 
 17:             /***********************
 18:             *** Send Operations  ***
 19:             ************************/
 20: 
 21:             queueClient.Send(msg);
 22: 
 23:             /**************************
 24:              *** Receive Operations ***
 25:             ***************************/
 26:             
 27:             BrokeredMessage recdMsg;
 28:             Order recdOrder;
 29: 
 30:             // Receive and lock message
 31:             recdMsg = queueClient.Receive();
 32: 
 33:             if(recdMsg != null)
 34:             {
 35:                 // Convert from BrokeredMessage to native Order
 36:                 recdOrder = recdMsg.GetBody<Order>();
 37: 
 38:                 Console.ForegroundColor = ConsoleColor.Green;
 39:                 Console.WriteLine("Received Order {0} \n\t with Message Id {1} \n\t and Lock Token:{2} \n\t from {3} \n\t with total of ${4}", recdOrder.OrderId, recdMsg.MessageId, recdMsg.LockToken, "Receiver 1", recdOrder.Total);
 40:                 recdMsg.Complete();
 41:             }
 42:             queueClient.Close();

Note that MessageSender and MessageReceiver are now optional. Here’s an example that shows PeekLocking a message, simulating an exception and trying again:

  1: 
  2:             // Alternate receive approach using agnostic MessageReceiver
  3:             MessageReceiver receiver = messagingFactory.CreateMessageReceiver(queueName);            // Recieve, complete, and delete message from the fabric
  4: 
  5:             try
  6:             {
  7:                 // Receive and lock message
  8:                 recdMsg = receiver.Receive();
  9: 
 10:                 // Convert from BrokeredMessage to native Order
 11:                 recdOrder = recdMsg.GetBody<Order>();
 12: 
 13:                 // Complete read, release and delete message from the fabric
 14:                 receiver.Complete(recdMsg.LockToken);
 15: 
 16:                 Console.ForegroundColor = ConsoleColor.Green;
 17:                 Console.WriteLine("Received Order {0} \n\t with Message Id {1} \n\t and Lock Token:{2} \n\t from {3} \n\t with total of ${4} \n\t at {5}", recdOrder.OrderId, recdMsg.MessageId, recdMsg.LockToken, "Receiver 2", recdOrder.Total, DateTime.Now.Hour + ":" + DateTime.Now.Minute + ":" + DateTime.Now.Second);
 18:             }
 19:             catch
 20:             {
 21:                 // Should processing fail, release the lock from the fabric and make message available for later processing.
 22:                 if (recdMsg != null)
 23:                 {
 24:                     receiver.Abandon(recdMsg.LockToken);
 25:                     
 26:                     Console.ForegroundColor = ConsoleColor.Red;
 27:                     Console.WriteLine("Message could not be processed.");
 28: 
 29:                 }
 30:             }
 31:             finally
 32:             {
 33:                 receiver.Close();
 34:             }

As shown below, this sample results in order 42 being received by the QueueClient:

Topics

May/June CTP	General Availability	Comments
Topic	TopicDescription	In May/June CTP, Topic / Queue / Subscription were management objects. All create/delete operations were moved to NamespaceManager and the state operations are now on TopicDescription/QueueDescription etc.
TopicClient	TopicClient	As noted in the Queues section, you can use TopicClient or MessageSender in the event you want to abstract details of using Topics.
SubscriptionClient	SubscriptionClient	As noted in the Queues section, you can use SubscriptionClient or MessageReceiver in the event you want to abstract details of using a Topic/Subscription.
Subscription	SubscriptionDescription	Changes to constructors and use of properties (see code samples below), but intent is the same.
RuleDescription	RuleDescription	Changes to constructors and use of properties (see code samples below), but intent is the same.
FilterExpression	Filter	Base for Filter types such as SqlFilter
SqlFilterExpression	SqlFilter
FilterAction	RuleAction

Below is a representative sample for creating, configuring, sending and receiving a message on a topic:

Administrative Operations

  1:             // Configure and create NamespaceManager for performing administrative operations
  2:             NamespaceManagerSettings settings = new NamespaceManagerSettings();
  3:             settings.TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(issuer, key);
  4:             NamespaceManager manager = new NamespaceManager(ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespace, string.Empty), settings);
  5: 
  6:             // Check for existence of topics on the fabric
  7:             var topics = manager.GetTopics();
  8: 
  9:             var result = from t in topics
 10:                          where t.Path.Equals(topicName, StringComparison.OrdinalIgnoreCase)
 11:                          select t;
 12: 
 13:             if (result.Count() == 0)
 14:             {
 15:                 Console.WriteLine("Topic does not exist");
 16: 
 17:                 // Create Queue
 18:                 Console.WriteLine("Creating Topic...");
 19: 
 20:                 TopicDescription topic = manager.CreateTopic(topicName);
 21:             }
 22: 
 23:             // Create Subscriptions for InventoryServiceSubscription and CreditServiceSubscription and associate to OrdersTopic:
 24:             SubscriptionDescription inventoryServiceSubscription = new SubscriptionDescription(topicName, "InventoryServiceSubscription");
 25:             SubscriptionDescription creditServiceSubscription = new SubscriptionDescription(topicName, "CreditServiceSubscription");
 26: 
 27: 
 28:             // Set up Filters for NorthAmericaFulfillmentServiceSubscription
 29:             RuleDescription northAmericafulfillmentRuleDescription = new RuleDescription();
 30:             northAmericafulfillmentRuleDescription.Filter = new SqlFilter("CountryOfOrigin = 'USA' OR CountryOfOrigin ='Canada' OR CountryOfOrgin ='Mexico'");
 31:             northAmericafulfillmentRuleDescription.Action = new SqlRuleAction("set FulfillmentRegion='North America'");
 32: 
 33: 
 34:             // Create Subscriptions
 35:             SubscriptionDescription northAmericaFulfillmentServiceSubscription = new SubscriptionDescription(topicName, "NorthAmericaFulfillmentServiceSubscription");
 36: 
 37:             // Delete existing subscriptions
 38:             try { manager.DeleteSubscription(topicName, inventoryServiceSubscription.Name); } catch { };
 39:             try { manager.DeleteSubscription(topicName, creditServiceSubscription.Name); } catch { };
 40:             try { manager.DeleteSubscription(topicName, northAmericaFulfillmentServiceSubscription.Name); } catch { };
 41: 
 42:             
 43:             // Add Subscriptions and Rules to Topic
 44:             manager.CreateSubscription(inventoryServiceSubscription);
 45:             manager.CreateSubscription(creditServiceSubscription);
 46:             manager.CreateSubscription(northAmericaFulfillmentServiceSubscription, northAmericafulfillmentRuleDescription);
 47:

Runtime Operations

  1:             // Create and Configure Messaging Factory to provision TopicClient
  2:             MessagingFactorySettings runtimeSettings = new MessagingFactorySettings();
  3:             runtimeSettings.TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(issuer, key);
  4:             MessagingFactory messagingFactory = MessagingFactory.Create(ServiceBusEnvironment.CreateServiceUri("sb",serviceNamespace,String.Empty),runtimeSettings);
  5:             
  6:             // Create Topic Client for sending messages to the Topic:
  7:             TopicClient client = messagingFactory.CreateTopicClient(topicName);
  8:          
  9:             /***********************
 10:              *** Send Operations ***
 11:              ***********************/
 12: 
 13:             // Prepare BrokeredMessage and corresponding properties
 14:             Order order = new Order();
 15:             order.OrderId = 42;
 16:             order.Products.Add("Kinect", 70.50M);
 17:             order.Products.Add("XBOX 360", 199.99M);
 18:             order.Total = order.Products["Kinect"] + order.Products["XBOX 360"];
 19: 
 20:             // Set the body to the Order data contract
 21:             BrokeredMessage msg = new BrokeredMessage(order);
 22:             
 23:             // Set properties for use in RuleDescription
 24:             msg.Properties.Add("CountryOfOrigin", "USA");
 25:             msg.Properties.Add("FulfillmentRegion", "");
 26:             
 27:             // Send the message to the OrdersTopic
 28:             client.Send(msg);
 29:             client.Close();
 30:             
 31:            /**************************
 32:              *** Receive Operations ***
 33:            ****************************/
 34:         
 35:             BrokeredMessage recdMsg;
 36:             Order recdOrder;
 37: 
 38:             // Inventory Service Subscriber
 39:             SubscriptionClient inventoryServiceSubscriber = messagingFactory.CreateSubscriptionClient(topicName, "InventoryServiceSubscription",ReceiveMode.PeekLock);
 40:             
 41:             // Read the message from the OrdersTopic
 42:             while ((recdMsg = inventoryServiceSubscriber.Receive(TimeSpan.FromSeconds(5))) != null)
 43:             {   
 44:                 // Convert from BrokeredMessage to native Order
 45:                 recdOrder = recdMsg.GetBody<Order>();
 46: 
 47:                 // Complete read, release and delete message from the fabric
 48:                 inventoryServiceSubscriber.Complete(recdMsg.LockToken);
 49: 
 50:                 Console.ForegroundColor = ConsoleColor.Green;
 51:                 Console.WriteLine("Received Order {0} \n\t on {1} \n\t with Message Id {2} \n\t and Lock Token {3}.", recdOrder.OrderId, "Inventory Service Subscriber", recdMsg.MessageId, recdMsg.LockToken);
 52:             }
 53:             inventoryServiceSubscriber.Close();
 54: 
 55:             // Credit Service Subscriber
 56:             SubscriptionClient creditServiceSubscriber = messagingFactory.CreateSubscriptionClient(topicName, "CreditServiceSubscription");
 57: 
 58:             // Read the message from the OrdersTopic
 59:             recdMsg = creditServiceSubscriber.Receive();
 60: 
 61:             // Convert from BrokeredMessage to native Order
 62:             recdOrder = recdMsg.GetBody<Order>();
 63: 
 64:             // Complete read, release and delete message from the fabric
 65:             creditServiceSubscriber.Complete(recdMsg.LockToken);
 66: 
 67:             Console.ForegroundColor = ConsoleColor.Green;
 68:             Console.WriteLine("Received Order {0} \n\t on {1} \n\t with Message Id {2} \n\t and Lock Token {3}.", recdOrder.OrderId, "Credit Service Subscriber", recdMsg.MessageId, recdMsg.LockToken);
 69: 
 70:             creditServiceSubscriber.Close();
 71: 
 72:             // Fulfillment Service Subscriber for the North America Fulfillment Service Subscription
 73:             SubscriptionClient northAmericaFulfillmentServiceSubscriber = messagingFactory.CreateSubscriptionClient(topicName, "northAmericaFulfillmentServiceSubscription");
 74:             
 75:             // Read the message from the OrdersTopic for the North America Fulfillment Service Subscription
 76:             recdMsg = northAmericaFulfillmentServiceSubscriber.Receive(TimeSpan.FromSeconds(5));
 77: 
 78:             
 79:            if(recdMsg != null)
 80:             {
 81:                 // Convert from BrokeredMessage to native Order
 82:                 recdOrder = recdMsg.GetBody<Order>();
 83: 
 84:                 // Complete read, release and delete message from the fabric
 85:                 northAmericaFulfillmentServiceSubscriber.Complete(recdMsg.LockToken);
 86: 
 87:                 Console.ForegroundColor = ConsoleColor.Green;
 88:                 Console.WriteLine("Received Order {0} \n\t on {1} \n\t with Message Id {2} \n\t and Lock Token {3}.", recdOrder.OrderId, "North America Fulfillment Service Subscriber", recdMsg.MessageId, recdMsg.LockToken);
 89:             }
 90:             else
 91:             {
 92:                 Console.ForegroundColor = ConsoleColor.Yellow;
 93:                 Console.WriteLine("No messages for North America found.");
 94:             }
 95:             
 96:             northAmericaFulfillmentServiceSubscriber.Close();

When running this sample, you’ll see that I have received Order 42 on my Inventory, Credit and North America Fulfillment Service subscriptions:

WCF

One of the great things about the WCF programming model is that it abstracts much of the underlying communication details and as such, other than dropping in a new assembly and and refactoring the binding and configuration, it is not greatly affected by the API changes from the May/June CTP to GA.

As I mentioned, one thing that has changed is that the ServiceBusMessagingBinding has been renamed to NetMessagingBinding. I’ll be covering and end to end example of using the NetMessagingBinding in my upcoming article in CODE Magazine.

REST API

The REST API is key to delivering these new capabilities across a variety of client platforms and remains largely unchanged, however one key change is how message properties are handled. Instead of individual headers for each, there is now one header with all the properties JSON encoded. Please refer to the updated REST API Reference doc for details. I’ll also be covering and end-to-end example of using the REST API to write an read to/from a queue in my upcoming article in CODE Magazine.

More Coming Soon

As I mentioned, in my upcoming article in CODE Magazine, I’ll cover the Why, What, and How behind Azure AppFabric Service Bus Brokered Messaging including end to end walkthroughs with the .NET Client API, REST API and WCF Binding. The November/December issue should be on newsstands (including Barnes and Noble) or your mailbox towards the end of October. You can also find the article online at http://code-magazine.com

Resources

You can learn more about this exciting release as well as download the GA SDK version 1.5 by visiting the following resources:

Azure AppFabric SDK 1.5:http://www.microsoft.com/download/en/details.aspx?id=27421
Clemens Vasters on the May CTP: http://vasters.com/clemensv/2011/05/16/Introducing+The+Windows+Azure+AppFabric+Service+Bus+May+2011+CTP.aspx
Great video by Clemens Vasters on Brokered Messaging: http://vasters.com/clemensv/2011/06/11/Understanding+Windows+Azure+AppFabric+Queues+And+Topics.aspx
David Ingham on Queues: http://blogs.msdn.com//b/appfabric/archive/2011/05/17/an-introduction-to-service-bus-queues.aspx
David Ingham on Topics: http://blogs.msdn.com//b/appfabric/archive/2011/05/25/an-introduction-to-service-bus-topics.aspx
My Introduction to Queues: http://rickgaribay.net/archive/2011/05/17/appfabric-service-bus-v2-ctp.aspx
My Introduction to Topics:http://rickgaribay.net/archive/2011/05/31/exploring-appfabric-service-bus-v2-may-ctp-topics.aspx

A Middle-Tier Guy’s Take on HTML 5

Rick G. Garibay — Mon, 22 Aug 2011 22:50:58 GMT

(My) Early Beginnings

I started my career in software development as a very junior web developer in 1999. I taught myself HTML, VBScript and JavaScript. The browser wars between Microsoft and Netscape were raging. I still remember how exciting my first Classic ASP page was. The fact that I was able to connect to an Access or SQL Server 7 database with just a few lines of code inside my markup was incredible at the time. I consumed new recipes from “4 Guys from Rolla” with relish and kept Scott Mitchell’s titles like “Teach Yourself Classic ASP 3.0 in 21 Days” on my desk at all times (it’s still on my bookshelf which itself has become a sort of Smithsonian for software development over the last decade). Even more exciting was that fact that it seemed like the beginning of a new era in which I could relegate JavaScript as a necessary evil for handling tricks like focus and validation on the UI.

At the time, I was doing some really fun and interesting work as a young Padawan for the credit card division inside the #1 Visa issuer in the country (we didn’t have a fancy name for it other than “reports” back then but we were doing very early work on what would become “BI”). By rendering data-driven operational reports dynamically on the browser, we had revolutionized how metrics like Occupancy, Average Handle Time, and Multiple-Call-Rate were disseminated within the bank ushering in a new era of productivity, transparency and accountability for everyone from agent to VP. Through this experience, we built a center of excellence which served as a benchmark for other call centers to follow (in fact, we had the likes of Amex come in and review how we did it). Sure, we had displaced an army of Excel Macro and Access developers, but such was the price of progress. As this little rogue IT shop basking in our success, I remember a number of “true programmer” personas in the “Real IT” group that tended to undermine what was happening. These were programmers who came from C++ or Java (and whose managers felt threatened by what we were able to do with such few resources) and mostly thumbed their nose at things like lack of strong typing, OO, etc. They looked at JavaScript as just a tool for dirty hippie web masters (remember that term) and VBScript as as something OK for administrators to use to walk AD hives, but being inferior for lacking OO and being handicapped by things like variants. Despite our incredibly visible success (at the CEO level and above) by applying these scripting technologies, I was hungry to see the forest for the trees and experimented a bit with COM and COM+, learning how to encapsulate business logic in components and delighting in being able to wire up my COM libraries with Classic ASP even though with the exception of my manager and mentor at the time, no one else even had the tools to debug my components.

The Server Era

Then, this thing called Windows DNA came along which promised to marry Windows, ActiveX and Internet into one big cluster… well you know. Fortunately, it’s fate was short-lived, but I remember attending a couple MSDN events where it seemed like concurrency and single threaded apartments would become mainstream topics on the web. Maybe us script kiddies would earn some respect after all? Then, just like that, this new, new thing called .NET happened. All of a sudden, just like that, I had a ton to learn. All my Classic ASP and JavaScript skills were superseded by Web Forms. I still remember stepping through every line of code in the I Buy Spy reference app and being completely blow away. ASP.NET offered something that was OO, strongly typed, and would even render JavaScript for you. Cumbersome JavaScript validation was replaced by server-side templates and controls. Form fields magically remembered their values across post backs. And, as I learned, WebForms offered a better separation of concerns with a nice, clean code-behind model that I would later leverage to introduce patterns like MVP, MVC Page Controller and Front Controller. I built a nice CMS portal for a multi-national bank (which according to Forbes Magazine is the largest public trading company in the world today) with these new skills and I hear it is still running today. Life was good. This was the age of the web server, and the only major argument within the Microsoft web community at that time was “C# or VB.NET”?

At this point in my career, I’d grown a bit bored with web development. I felt like I’d accomplished everything I wanted to with ASP.NET, and the roles I found myself in started dealing with problems at a more holistic, program level which would involve a handful of web apps and coordination between them and new and existing enterprise resources. I discovered Web Services, and the problems I was now trying to solve led to the gradual gravitation to enterprise architecture and middleware and before I knew it, I was hooked. Admittedly, it was a great time to make the shift. SOA was king. COM+ had grown up with support for Enterprise Services in .NET and in parallel, this amazing new messaging framework codenamed “Indigo” was in development that would provide a black belt for hungry ninjas like me who wanted to take over the world with SOA. When it came to Indigo, there were two types of members in the community: Those on this inside, and the rest of the world. I was very much part of the rest of the world, but I consumed every bit of content I could get my hands on from folks like Don Box, Juval Lowy, Wenlong Dong, Michele Bustamante and Dr. Nick.

Around the same time, a major re-engineering of a product called BizTalk Server was nearing release which took full advantage of the .NET Framework. My employer then, a mid-sized auto retail and finance company was one of the first BizTalk Server 2004 customers in Phoenix. For a fledging enterprise integration architect, this was an awesome opportunity. I learned a ton from my friend Todd Sussman, Brian Loesgen and Adam Smith, the latter of the two I wouldn’t meet in person for a few years, but I had read “BizTalk Server 2004 Unleashed” and “The Blogger’s Guide to BizTalk” from cover to cover more than once. Even better was that I was leading the development of our first SOA and 802.11 enterprise mobility project. We had decided to build the mobile apps- which were a superset of a desktop control center- with ASP.NET. Users would hit the same URL whether they were on the desktop or in the field with their device, and the right screen would render. All of our business logic was wrapped in an ASMX façade which then communicated with our BizTalk orchestrations. With my first real enterprise program under my belt, and WCF nearing GA, I decided that this was what I wanted to do when I grew up, or at least for the next 5 years.

Along with WCF, WPF was nearing release. WPF offered a completely different paradigm on which to build traditional Windows apps. Support for rich media like video and sound, flat controls, new gradients all with an incredibly “webby” DHTML-looking design aesthetic. At the time, I remember introspecting that if presentation technologies like this were successful at winning over users, then one day, users won’t care if they are using a browser or an OS to interact with software. What I didn’t realize was to what extent everyone’s cheese was about to be moved. Here we had two tremendously powerful additions to the .NET Framework, poised to revolutionize how we write software from a presentation and back-end perspective, and yet, something subtle was happening that was bigger than Microsoft, bigger than the marvel that is .NET.

The Web Reborn

Content building SOA solutions in the walled gardens of my employers and clients, almost overnight, I remember when web developers started insisting on me starting to expose JSON endpoints on my services. Apparently, while I was in messaging la la land, users had grown tired of refreshing their browsers and posting back to the server every time they submitted a form. Turns out, I too was one of them! Users were demanding not just a dynamic web experience, but one that was interactive, and felt more like a rich client (a great example at this time was Outlook Web Access). But if you wanted a rich experience, isn’t that why you stuck to the desktop and used WPF? Following the promulgation of XML as the second coming, wasn’t JSON nothing more than an esoteric relic of JavaScript? AJAX had arrived. What followed was a complete disruption of the seeming balance between intended purpose that would shift the pendulum once again to the web.

This was about the same time that Microsoft had shared its vision for Software + Services, first unveiled at Mix 07. On the outside, the Mix conference was all about the web, but the reality was that this was also part of a pretty massive campaign to court and win over designers from Adobe/Macromedia to a new technology: WPF/Everywhere, aka Silverlight. While many had been signaling WPF as the return of the smart client, users were accepting an alternate, even degraded user experience in exchange for interop. Silverlight offered a superset of WPF capabilities, delivering a somewhat equally productive design time and development experience as .NET and thus began penetrating Apple and Linux via the ubiquity of the browser. This was the first time I saw Microsoft really understanding that it wasn’t only about .NET and Windows anymore. This was evidenced by prominent PMs on stage demonstrating Silverlight apps on Macs, and running Linux distros on VMs to show that you could write the app once, and run it (almost) everywhere. A number of incredible apps were released on Silverlight including examples like Netflix and Hard Rock Café Memorabilia which were each both a sign of the times and a hint at what was to come.

To be sure, this had indeed become a software + services world, and for a while Silverlight looked promising despite the tremendous market footprint that Flash had and continues to have. I remember writing about how remarkable Silverlight was and what a game changer it could be. But then, an interesting thing happened. JavaScript and REST started appearing more and more in web apps, particularly in the consumer space. At first, despite the popularity of Fielding’s paper, REST seemed like a fringe thing, and in many ways a step backward. Here we had a tremendously powerful consortium of standards built around SOAP representing the intersection of the very few things big players like Microsoft, IBM, Sun and Oracle agreed on. What’s more, it seemed that Microsoft had timed this SOAP bubble (no pun intended) perfectly, with its shiny, new, equally efficacious messaging stack called WCF which was, and still today remains unrivaled by other platform vendors. In addition to HTTP, WCF brought TCP, MSMQ and IPC to the enterprise, offering (proprietary) binary encoding and MTOM for optimizing message exchanges. The programming model had (and continues to have) a learning curve over ASMX, but once you got over the hump, you were on a high summit and could see the world for miles around from this new vantage point. So, why in the world would anyone want to go back to using HTTP POST and POX? How could it be that the world was settling for REST and JavaScript?

Simple. The world (and the internet) was changing. A gradual, yet viral shift was taking place fueled by the success of Ruby on Rails and PHP which built the foundation for what is today known as Web 2.0. All of a sudden, anyone with a laptop and an internet connection could download a few packages and get an app up and running in no time. The barrier to entry was financially negligible and because these languages fully embraced HTTP, a tremendous community was born that was as smart as they were entrepreneurial. Interop and reuse were mere side-effects that led to tremendous adoption by everyone with a browser. Fully embracing JavaScript with their productivity boosting libraries that took the sting out of writing JavaScript, similar approaches to packaging robust functionality into libraries such as JQuery followed. In addition, while at first, Ruby on Rails embraced SOAP, it was later replaced with REST. Ask your mother or grandmother what Twitter or Groupon is and you’ll have the answer as to why REST and JavaScript have persevered.

In response to all of this, WCF added support for JSON first, followed by REST, and by the release of .NET 4, both were in the box. In addition, WCF RIA Services was introduced, adding an easy button for integrating with Silverlight clients with the stack, and WCF Data Services provided a REST-friendly approach to managing CRUD operations using ATOM as the message contract. The success of the ASP.NET MVC framework, which has all but subsumed its older, less cool ASP.NET Web Forms sibling, is further evidence of the developer and user community embracing the browser as a conduit for interoperability on the client.

The Mobility Wars

Even amidst the mobile revolution, which has been largely built on the ubiquity of broadband connections and increasingly capable handheld devices, proprietary platforms have emerged which in many ways are more restrictive, and costly than any other platform. Want to build apps for iOs? Learn Objective C. Android? Got Java? Windows Phone? .NET. Even though they all sit on similar devices and depend on the same infrastructure for messaging (the internet), apps are hardly interoperable with one another. I am sure you know at least two people that carry multiple headsets with them for this very reason, and tablets, sure to be the next wave of mobile innovation suffer from the same dilemma (if you ask me why HP abandoned WebOS, I think it has more to do with the writing on the wall regarding HTML5 than anything else, but more on that shortly). At first, this dilemma seems somewhat benign, perhaps only affecting developers. The truth is it affects everyone. Talk to any iOS developer (that’s not a complete Apple zealot) and they’ll tell you that Objective C isn’t the most productive language to write apps with. Aside from Java not being too sexy these days, I don’t hear many Android (or WP7) users raving about the selection of apps in Android Market. Same goes for WP7 and Windows Marketplace- I remember how long I had to wait to get Angry Birds on my Windows Phone 7! But the most salient example I can think of is the fact that after a decade of browser wars, tremendous innovation on the client and the server, I still can’t play Flash videos on my iPad or WP7. My iPad refuses to run Silverlight apps, even though its browser on the desktop is fully capable of doing so. This is a situation that is just plain broken, and it isn’t just me that feels this way…

The World Wants Native Interoperability on the Client, and Today, the Answer is HTML 5.

Like it or not, HTTP has become the ubiquitous interface for both the client and its conduit to the backend. This incredibly simple protocol has had more influence on software over the last decade than any other technology, completely reshaping the strategies of the biggest players. I don’t have to tell you that without HTTP, you don’t have cloud computing. For example, who would have thought that Amazon, after pioneering e-commerce would get into the PaaS business by being the first to truly innovate in commercial cloud computing at scale? Who would think that Microsoft would completely reinvent itself on Windows Azure and invest as deeply in REST as it has, not only with standards and technologies like OData and WCF Data Services, but also in exposing their incredibly rich and powerful Azure APIs as REST heads? Again, the answer is simple. HTTP has become the lingua franca of the interconnected world and the disruption started with the first packet in the early 60s.

Just as SOAP was developed to aid in interop between vendor platforms, banks and partners, REST has increased the native interoperability of applications on the web. Hold your rotten tomatoes, but I am afraid that so too is the fate of iOS, Android, WP7, WPF, ASP.NET and Silverlight. Are they going away tomorrow, next year or 5 years from now? Nope. SOAP still has a very important place in back-end systems and I don’t mean just for legacy applications. When you you want to work with contracts and interfaces (very important when designing critical message exchanges for business processes), need support for heavy lifting such as distributed transactions, reliable messaging, multiple transports and the like, SOAP is your tool. Case in point as I mentioned briefly above is Windows Azure. While the investment in REST has been significant, these REST endpoints are merely designed for optimizing interop allowing any client or platform to take advantage of the services offered by Microsoft’s cloud. Want to start or stop a compute instance? Need to write a file to blob storage, retrieve an entity from table storage or publish a message for hundreds of subscribers to consume over the AppFabric Service Bus? There’s a REST API for that. While adoption is key to the success of any product or platform, the API, and thus REST is not the end itself but merely a means to the end, and as such is only the tip of the iceberg. Below the water’s surface, there is, and will continue to be a ton of SOAP and .NET.

The same is happening on the client with HTML5. While Silverlight and ASP.NET MVC were a step in the right direction and aren’t going to just vanish tomorrow, HTML5 offers true interop at the native (browser) level, and since native interop is what the world wants, it will win, at least for now. I say at least for now because as tempting as it is to chock this up to just another trend, unlike the crusty programmer personas I mentioned when I started this stream of consciousness that has become a rather long post (thanks for staying with me this far, btw), I’ve been doing this long enough to have seen software reinvent itself a few times now. I’ve learned that rather than cry over spilled milk, it is important to embrace change and this means you have to expect and be prepared for anything. HTML 5 could fail, and companies that have already invested significantly in ASP.NET, Silverlight, Flash and one (or several) mobile platforms aren’t going to just jump in right away, but they are going to watch very, very carefully. If I am building a web app or a rich client app today from scratch though, I’m going to think very, very hard before I decide to do so in anything but HTML 5.

Who Moved my Cheese?

Who would have thought that Microsoft, with an incredibly lucrative productivity, OS, server and tools business would bet the farm on Windows Azure? As innovative as I think Microsoft’s (PaaS) cloud story is, in many ways, it is the software giant’s response to its cheese being moved by the web. And make no mistake, it is a massive bet. Initial buzz around Windows 8 has so far been met with both positive and quite negative feedback after the revelation that Windows 8 will make HTML 5 a first class citizen on the desktop and the tablet. Viewed simplistically, the seams between client and server/backend are exposed with Windows 8 and Microsoft Azure respectively. At first, this seems quite alarming (Joel Spolsky saw this coming over 8 years ago), but if you think about it, it makes perfect sense. If the client is moving to the browser, the value proposition of a beefy desktop or a rack of servers in an opaque data center is diminished significantly. However, all that data, records, images, videos, files still have to be stored and served up some where, and that somewhere needs to be natively interoperable with the the client at the iceberg and get the heavy lifting done below the water’s surface. The need for middleware- integration between the client, that somewhere and its data, applications and systems has never been greater.

Even though I’ve joked to friends that stayed on the front end that I didn’t miss anything by skipping WPF and Silverlight because we’re back to where I first began with HTML and JavaScript, the reality is that the last decade has been incredibly important in reinforcing that innovation is bigger than any platform vendor or standards body because unlike them, it is you and me that determine the fate of technology, and for that we should all be proud.

So, What Now?

I provide no value without designing distributed solutions that can be consumed by the client applications and automate the business processes they serve. So just as before, its time to buckle down once again and learn the client technologies that one of my primary customers- the UI developer- will soon be using. First in line is Mango. Next is HTML 5. And who knows, after specializing in integration for the last 5 years, I just might start generalizing a bit and get back into web development again.

See you at the other end of the wire.