Skip to content

SO Apps 1, WcfNQueueSMEx – WCF NetMessagingBinding In-Azure and On-Prem

May 12, 2015

WcfNQueueSMEx is the starter app for my SO Apps series, which is sketched in “Introducing the ‘SO Apps’ Series of Blog Articles and Code Examples“.

WcfNQueueSMEx is a base upon which to build future examples. This small SO App fragment is a simple code skeleton whose function is to service data feeds  – Ingest data into a system received via a queue from one or more data sources. It also demonstrates the use of a productivity enhancing library: IDesign’s ServiceModelEx for WCF, developed by Juval Lowy.

The goals of this article are:

  • Provide you with an on-ramp to building WCF services using Service Bus Queues via the NetMessagingBinding.
  • Demonstrate how a WCF service can be hosted as follows, with zero code changes to the WCF service code:
    • In the cloud on Azure in a WorkerRole.
    • In a Windows Service/Console App on-prem.
    • In Microsoft’s new Service Fabric technology (or so it appears at the time of writing this).
  • Demonstrate useful productivity boosters – Technologies and techniques that can reduce the amount of plumbing code you need to write, allowing a dev team to focus more on directly creating business logic (and hence value) instead of the working with the plumbing code connecting chunks of business logic in a code base.

WcfNQueueSMex uses a single Azure Service Bus queue to transmit data from one or more data sources to a WCF data feed service (data ingestion in IoT parlance) that services the queue via the NetMessagingBinding. The WCF data feed service is hosted in either a console app (simulating an on-prem service), or in an Azure WorkerRole in an Azure Cloud Service. The NetMessagingBinding and ServiceModelEx are used to reduce the amount of plumbing code needed to be written when servicing the Service Bus queue, increasing programmer productivity. A working code example is provided to give you running software you can experiment with.

Here is a tour of the projects in the solution:

  • DataSourceSimulatorClient – A console app that enqueues messages to the Service Bus ingestionqueue with the DataFeedsClient proxy. The proxy uses the ServiceModelEx QueuedServiceBusClient and the NetMessagingBinding. Think of the DataSourceSimulatorClient as simulating an IoT device, or a process in a data center or in the cloud, that needs to periodically send chunks of data to a central processing service. There may be multiple instances of the DataSourceSimulatorClient running simultaneously, and they all place their data on the same ingestionqueue.
  • DataFeedsManager – Hosted as described below, this is a WCF service listening to the ingestionqueue via the NetMessagingBinding, dequeueing messages from the queue. The DataFeedsManager acts in the role of only dealing with the data feed in various ways, including persisting the data.  In subsequent versions processing the data will be added in a different manager (also a WCF service) to have a good separation of concerns between feeds and data processing, as recommended by the Single Responsibility Principle and the general approach that microservices use. The DataFeedsManager receives a queued item and in this version does nothing! In real life, the business logic in this manager will involve saving data to storage, perhaps doing some on-the-fly prep for subsequent analysis. It could also involve placing a message on a different queue to send it to another service for specialized processing. The example code for the DataFeedsManager now contains no such business logic or persistence code. Save that for a subsequent iteration. Now it is just a skeleton, displaying the contents of the message to a Console if available and also via Trace statements for running in Azure. The defaults used in this WCF service are InstanceContextMode.PerSession and SessionMode.Allowed.  It’s called a “manager” rather than a “service” due to this example using the IDesign Method (TM) for the design.  To learn more about this proven effective approach to designing Service Oriented Apps, please click the link.
  • DataFeedsServiceHost – A console app that hosts the DataFeedsManager WCF service, simulating an on-prem Windows Service or IIS hosting. It uses the ServiceModelEx QueuedServiceBusHost.
  • DataFeedsCloudWorker – Hosts the DataFeedsManager WCF service in an Azure Worker role in the cloud or in the Visual Studio Azure Emulator.
  • DataFeedsCloudSvc – The Azure publishing package containing the DataFeedsCloudWorker.
  • Shared – Contains items that are shared between the Client and Service, like the DataContracts and Service Contracts, plus other things as well.
  • MiscHelpers – Contains various helper classes.
  • ServiceModelEx – System.ServiceModel is the Microsoft assembly for WCF. ServiceModelEx is the IDesign library of extensions to WCF, plus productivity boosters. ServiceModelEx components are used to host the WCF service, and also used to resolve complex DataContract definitions between the client and server, without having to resort to the cumbersome KnownType attribute that tightly couples code and can be an irritating source of maintenance problems.
  • App.config Files – Both the DataFeedsCloudWorker and DataFeedsServiceHost instantiate and open the ServiceModelEx QueuedServiceBusHost, which uses information in their app.config files to connect to the Service Bus ingestionqueue via the NetMessagingBinding. In a similar way the DataSourceSimulatorClient uses the ServiceModelEx QueuedServiceBusClient (via the DataFeedsClient proxy) which depends upon an app.config file’s settings for the NetMessagingBinding. A production app would likely use code for these purposes, although app.configs work well during early development to enable fast progress.

To run the code, first install it on your system and follow the Setup Instructions that come with the code. Then run the DataSourceSimulatorClient to enqueue a few messages. Follow that by running the DataFeedsServiceHost to dequeue them. Then take it from there, also running the DataFeedsCloudSvc with the debugger/Azure Emulator, and finally deploying it to Azure. The Setup Instructions indicate how to run the above.

When inspecting the code, notice the following areas that deal with increasing productivity:

  • No changes to the WCF service code are required in order to host it in either of the 2 above hosts. The WCF DataFeedsManager encapsulates the business logic separately from hosting code. This separation of concerns minimizes the amount of things to be changed when re-hosting. The rise of hybrid apps and cloud computing has increased the need to have flexible hosting. Hosting has become a common area of volatility needing to be well encapsulated to prevent code changes from rippling through the code base, again and again.
  •  The NetMessagingBinding takes care of most of the details of dealing with the ingestionqueue. This means you do not have to write plumbing code to enqueue, dequeue, and convert a BrokeredMessage item of the queue to and from the types used in the app (the TestMessage and SbMessage types in this case). Plumbing code creates no direct business value. It is there purely to connect chunks of business logic together. All of the plumbing work required is done behind the scenes by WCF, the binding, plus the GenericResolver as follows.
  • The work of resolving types between WCF services and clients by manually applying the KnownType attribute correctly (and chasing bugs when doing it incorrectly) is avoidable by using ServiceModelEx’s GenericResolver. This is one good reason to choose WCF over using the native Service Bus queues directly. Save time, get done sooner.

For a complete description of the GenericResolver see “Known Types and the Generic Resolver” by Juval Lowy in MSDN Magazine. In order to host a WCF service in Azure or in IIS, and use the GenericResolver, you need to prefix the name of each assembly containing types that need resolution with “App_Code.”.  More specifically, you need this prefix when the hosting process has any of the following names “w3wp”, “WevDev.WebServer40”, or “WaWorkerHost”. In this article’s code example such prefixing has been done to the Shared assembly by naming it App_Code.Shared in the properties page of the Shared project. This makes the GenericResolver work when running in an Azure WorkerRole (in the WaWorkerHost process).

Also note that I have applied the GenericResolverBehavior attribute to the DataFeedsManager WCF service since it depends upon complex types. This insures the GenericResolver will be installed regardless of the service host used, although the example code uses ServiceModelEx’s QueuedServiceBusHost and QueuedServiceBusClient which install the GenericResolver by default. Please see the ServiceModelEx source code and above article for more information on this.

In the case that you have a Data Source client that cannot or does not use a WCF proxy to enqueue items, it is still possible to have a WCF Service use the NetMessaging binding to service an ingestionqueue containing BrokeredMessages. This scenario fits cases where clients must use the Service Bus REST API, or when clients are written in other than .NET languages. Please see the blog “Receiving messages using NetMessagingBinding with custom formats” by Abhishek Lal for how to do this.

To see how the WCF OperationContext can be used with Service Bus queues to gain access to the BrokeredMessage properties, plus more minute details, please see the code example and write up by Paolo Salvatori, “How to use WCF to send/receive messages to/from Service Bus for Windows Server”.

There you have it, an on-ramp to using WCF with Service Bus queues on-prem and in Azure. I hope you find WcfNQueueSMEx as useful a learning tool as I did in developing it.

Thanks to Robert Broomandan for aiding me in getting started on this path.

George Stevens
Creative Commons License

dotnetsilverlightprism blog by George Stevens is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Based on a work at dotnetsilverlightprism.wordpress.com.

Advertisements
Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: