• Microservices can be considered ‘fine-grained SOA’ – a small self-contained service that does not depend on other microservices.
• These services are mostly composed and orchestrated together to form more complex application services.
• Typically small feature-focused teams will create these microservices.
• Each team is free to use any technology/stack that makes them productive. Each microservice can use different versions of frameworks/platforms.
• DevOps mentality means each team is also responsible for deploying the microservice into production and monitoring and managing it.
• Have a self-service capability that allows teams to ‘spin-up’ a service to test/develop ideas. (this is where the private Paas/cloud helps).
• Organization structure should be built around this idea of microservices – it should not be some huge team but a number of small independent teams.
• Once a service is out there, it never goes away. You can put new versions side-by-side and redirect calls to the new version, but the old version remains around. If there is an issue with the new version, traffic is routed back to the old version (automatically or manually).
• Microservices are cornerstone of the system so they should be very, very, very well tested. Try to break it before publishing it to production.
• All deployment, management is done through script … no manual process.
• De-normalize all data so that it can be sharded as much as possible.
• Preferably these services should be stateless but this can be tricky. Azure Service Fabric allows you to build statefull microservices with no downside.
• Every service should have a client access library – do not require apps to call your service via REST endpoint as different interpretations of the methods etc. may cause confusion.
• Because microservices get called so often, consider using a binary format like Google Protocol Buffer, instead of JSON. This will reduce network congestion and improve performance.
• Tooling is the secret sauce that makes microservices viable in the enterprise. There are some open source tools but you will have to build many of your own because:
  • Microservices are complex to build and compose.
  • Avoid duplicate code everywhere.
  • Versioning is not easy.
  • Same with routing.
  • Common interface naming requires some sort of repository.
  • Monitoring and logging should be inherent (not a separate microservice).
• A good PaaS system makes some of these issues go away and adds autoscaling, service discovery, versioning, rollback, fault tolerance etc.

This behavior is by design as the WSDL is considered a 'static' thing and must always be the same for a service, so there is no retry logic built into WCF to call it more than once in the event of an error.

This is the one point I wanted to get across in the post - as far as possible, avoid doing anything fancy in the GetGeneratedMetadata method and ensure it is always able to return a WSDL, possible read from a local file.

The original instructions are here, but the steps below are organized better and fill some gaps. Except for the .NET 4.5.2, PowerShell 4.0 and VC++ redistributable, you don't need admin access for DNX itself as it deploys to your user folder.

Upgrade to .NET 4.5.2 (or higher) if you don't have it - Note needs about 3GB on C drive so you may have to make room first. This is a pre-requisite for PowerShell.
Reboot!

Upgrade PowerShell to latest version (4.0) if you don't have it already
 https://www.microsoft.com/en-us/download/details.aspx?id=40855&WT.mc_id=rss_alldownloads_all
(Select x64 version)
Reboot!

Install the Visual C++ 2013 redistributable package from here (in case you don't have it already). Install both the x86 and x64 packages. This is pre-requisite for Kestrel (the development web server).

Run PowerShell

Check powershell version:
 $PSVersionTable.PSVersion (should be 4.0)

Exit PowerShell

Issue the following command:

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "&{$Branch='dev';iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}"

This will install DNVM (.NET Version Manager) to your user folder.

Close command prompt window.

Open new Command Prompt

dnvm

You should see help information for the DNVM command

If you use a Proxy Server within your environment (at work for example), pay attention to the next 2 lines, otherwise skip over it.
 setx http_proxy https://proxy.server.com:1234

Close prompt and open a new one - check that http_proxy environment variable has been set correctly.

dnvm install latest -Unstable -Persistent (this will pull the latest runtime bits and install to your user folder) 

dnvm list (this will show you all the installed runtimes and a * will be next to the current default)

Close prompt and open a new one

Type the following command:

dnx

You should see help information for DNX

Occasionally you can run the following command to get the latest DNX and DNVM bits:

dnvm upgrade

dnvm update-self

Finally we need to tell the package management system to get packages from the DEV package server.

Update c:\users\<user>\AppData\Roaming\Nuget\NuGet.config (this determines which source DNU RESTORE will use) with these contents. You can merge the existing contents.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/api/v2/" />
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
  <disabledPackageSources />
  <activePackageSource>
    <add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/api/v2/" />
  </activePackageSource>
</configuration>

Another option is use this DNU command instead of 'dnu restore':

 dnu restore -s https://www.myget.org/F/aspnetvnext

Note DNU is the .NET Utility which includes functionality to restore packages, build packages, compile code etc.

To test the installation:

Create a folder c:\temp\ConsoleApp
In this folder, create a file Program.cs with these contents:

using System;
public class Program
{
    public static void Main()
    {
        Console.WriteLine("Hello World");
    }
}

Also create a file project.json with these contents:

{
    "dependencies": {

    },
    "commands": {
        "ConsoleApp": "ConsoleApp"
    },
    "frameworks": {
        "dnx451": { },
        "dnxcore50": {
            "dependencies": {
                "System.Console": "4.0.0-beta-*"
            }
        }
    }
}

Now using a Command Prompt, go to the folder containing the files and execute the following command:

dnu restore (this will pull all the required packages into your user folder)
dnx ConsoleApp

It should print Hello World!

You can also try the simple CookieSample web app from here.

Note for web apps you have to use the following command to run the development web server (kestrel):

dnx kestrel (assuming you are currently in the folder containing the project.json file)

Optional Step

If you would like to have a convenient way of editing your source files without installing Visual Studio, then check out OmniSharp. It is a free plug-in to some popular source editors that supports ASP.NET 5 development. The Atom editor works pretty well on Windows, is lightweight and deploys to the user folder (no admin permissions required). Also install the OmniSharp plugs for Atom. 

After you install Atom, close the editor and open a new command prompt and type this command if you use a Proxy Server in your environment: 

apm config set https-proxy https://proxy.server.com:1234

Then issue these commands to install the Atom plug-ins:

apm install autocomplete-plus
apm install linter
apm install omnisharp-atom

Then run Atom and follow the instructions here to use the intellisense etc.

If you access an Intranet site (Intranet Zone) then your BHO has a medium level trust but if you access an Internet site (Internet Zone) then it has a Low level of trust. If your BHO is writing to say some log file, then it is very possible that the File.Open() call will fail due to these restrictions. If you find IE is misbehaving (kept crashing in my case) whenever you access an Internet website, then read on. (Note I discovered this issue on a Windows 8.1 + IE 11 Surface Pro 3, but have not tried it on an older OS).

As it turns out, besides the usual NTFS permissions, all files and folders also have an 'integrity' level, which is 'Medium' by default. You can use the handy icacls command to find information about your integrity level:

icacls "c:\\Log"

You can look for the presence of this in the displayed output:

 Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

The default is Medium if the above is not displayed.

So what do you do if you need write access in the Internet Zone (low trust)? Issue the icacls command as follows:

icacls "c:\Log" /T /setintegritylevel (OI)(CI)L​

This will allow BHOs in the Internet Zone to Write to the c:\Log folder. The Zone restrictions are meant to prevent malicious code from unauthorized access to your files and folders so be carefull with this command and only give access to a specific folder.

When you create a WebAPI service, you must configure it in code by adding to the generated Register method. There does not seem to be a way to establish a policy-based configuration for ALL WebAPI services on the box. After coming up empty on Bing (and Google!) I decided to read up on Katana and found a hook at the OWIN host level which can be used to inject configuration onto these WebAPI apps.

First, write a simple class as follows and make it strongly-typed by signing it and then GAC it (you will need to pull in OWIN and WebAPI libs via NuGet).  

namespace WebApi

{

    publicclassWebApiConfiguration

    {

        publicvoid Configuration(IAppBuilder app)

        {

            var config = GlobalConfiguration.Configuration;

            ConfigureAuth(app);

            ConfigureExtensions(config);

        }

        publicstaticvoid ConfigureExtensions(HttpConfiguration config)

        {

            config.Filters.Add(newMyAuthFilter());

            config.MessageHandlers.Add(newMyDelegatingHandler());

            config.Filters.Add(newMyExceptionFilterAttribute());

            config.Filters.Add(newMyActionFilterAttribute());

            config.Formatters.Add(newMyMediaTypeFormatter());

        }

        publicvoid ConfigureAuth(IAppBuilder app)

        {

            app.UseCookieAuthentication(newCookieAuthenticationOptions());

            app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);

        }

    }

… other classes left out for brevity.

The main method is Configuration which gets called by the OWIN host – but only if it finds a particular setting in the appSettings configuration. What was surprising (to me) is that you can have a ‘global’ set of appSettings in the global web.config file. Just add the following to the web.config file located in c:\windows\microsoft.net\framework\v4.0.30319\config:

  <appSettings>

                <add key="owin:appStartup" value="WebApiConfiguration, WebApiExtension, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fc3a6ca1f8e86de8" />

    </appSettings>

Now any WebAPI app on that box will automatically pull in your custom extensions so you can have your own hooks into these apps. From an enterprise perspective, you can plugin your own tracing, exception handling, Action filters, authentication etc. And the app developer needs not do anything special so there is nothing new to learn. It was pointed out to me that this will setting will override the Startup class in the app. In our case this is a good thing as we want to enforce certain behaviors on the app.

BTW I used Web API 2.2 for this POC.

var proxy = new tempuri.org.IService();
proxy.GetDataREST(id, successRESTService, errorRESTService, null);             

The problem with this proxy is that it has a dependency on the ASP.NET ScriptManager server controls so you generally have to include it within an ASPX page. However in the day of HTML+JS apps you can use this with a plain HTML file if you know which JS library to include from the ASP.NET CDN:

<script src="https://ajax.aspnetcdn.com/ajax/4.0/1/MicrosoftAjax.js"></script>

This will include the compressed and obfuscated ASP.NET JS library that has the helper functions required to use the generated service proxy. Now recently I’ve gotten to love Angular.JS and I thought of using that framework to write a tiny HTML app that calls a WCF REST service using the generated proxy. Off course it generally works fine with one big problem. The callbacks used by the ASP.NET AJAX libraries (successRESTService and errorRESTService in the example above) don’t seem to work the same way as the Promises used by Angular.JS. As a result, although the callback is invoked correctly, none of the bindings are updated during the callback. So the view elements do not show the data returned form the web service. However, I was able to force the view to update by calling $scope.$digest(); at the end of the callback method. So the completed app looks like so:

<!doctype html>
<html ng-app>
<head>
    <title>Call REST service via Angular</title>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.7/angular.min.js"></script>
    <script src="https://ajax.aspnetcdn.com/ajax/4.0/1/MicrosoftAjax.js"></script>
    <script src="https://localhost/RESTJSONCompare/Service.svc/js"></script>
    <script type="text/javascript">
        var ServiceController = function ($scope, $http) {
            var id = 123;
            $scope.getPerson = function () {
                var proxy = new tempuri.org.IService();
                proxy.GetDataREST(id, successRESTService, errorRESTService, null);               
                $scope.ErrorMessage = "";
            }
            var successRESTService = function (data) {
                $scope.PersonID = data.ID;
                $scope.PersonName = data.Name;
                $scope.PersonAddress = data.Address;
                $scope.$digest();
            }
            var errorRESTService = function (data) {
                $scope.ErrorMessage = "HTTP error code : " + data;
                $scope.$digest();
            }
        };
    </script>
</head>
<body>
    <div ng-controller="ServiceController">
        <input type="button" ng-click="getPerson();" value="Call REST Service">
        <hr />
        <ul>
            <li>
                ID: {{PersonID}}
            </li>
            <li>
                Name: {{PersonName}}
            </li>
            <li>
                Address: {{PersonAddress}}
            </li>
        </ul>
        <label>{{ErrorMessage}}</label>
    </div>
</body>
</html>

This gives you the best of both worlds, the power of Angular.JS data binding and the simplicity of the ASP.NET AJAX proxies + WCF REST services.

By popular demand, I have also uploaded the WCF service to this post.

RESTJSONCompare.zip

One approach to get around the Sandboxing is to use the oldest form of IPC – the file system. However this still needs a common file/folder that all apps can access. By default, apps have their own private isolated storage that is not accessible by other apps. But you can give the apps the capability to access the user’s Documents folder for specific file types. So I went down the road of using a shared folder with a bunch of files as a means of communications and was surprised how well it worked. Off course you can’t expect the file system notification to handle very rapid changes, but for many scenarios, this scale works (think FileSystemWatcher).

I’ve wrapped all the functionality into an easy-to-use WinMD module (that is accessible from both WinJS and C# apps). Here are some of the highlights of the library:

Overview

The general idea is fairly simple, implement a Publish/Subscribe mechanism by using shared files. WinRT has a mechanism to detect changes to a folder so we leverage that facility to detect the changes and call a delegate within the registered application. As a convention, I used a folder named Topics and in that folder are various files with the .topic extension. This allows various types of publish/subscribe events to be fired and applications need only listen to the one they are interested in.

First here is the snippet to write the application provided payload to the file. The application calls the NotifyApps method to Publish something new:

public async void NotifyApps(string Payload)
{
     StorageFolder folder = KnownFolders.DocumentsLibrary;
     folder = await folder.CreateFolderAsync(TopicsFolder, CreationCollisionOption.OpenIfExists);
     StorageFile f = await folder.CreateFileAsync(SharedFile, 

        CreationCollisionOption.OpenIfExists);
     await Windows.Storage.FileIO.WriteTextAsync(f, Payload);
}

Now there is no FileSystemWatcher in WinRT but we do have a mechanism to monitor a folder for changes. So we can leverage that to achieve our goal as follows. Note we take a delegate from the application and save it for later. And we set the StorageFileQueryResult to call our delegate when any changes are detected via the ContentsChanged event. Applications using the library call Subscribe if they wish to receive notifications for a particular topic:

public async void Subscribe(NotificationReceived NotificationCallback)
{
    callback = NotificationCallback;
    folder = KnownFolders.DocumentsLibrary;
    folder = await folder.CreateFolderAsync(TopicsFolder, 

       CreationCollisionOption.OpenIfExists);
    QueryOptions qo = new QueryOptions();
    qo.FileTypeFilter.Add(SharedFileExtension);
    query = folder.CreateFileQueryWithOptions(qo);
    query.ContentsChanged += query_ContentsChanged;
    await query.GetFilesAsync();
}

And in the ContentsChanged event we simply read the file and call the application registered delegate. Note we also check if the Payload has changed since the last event.

f = await folder.GetFileAsync(SharedFile);

IInputStream stream = await f.OpenReadAsync();
using (DataReader reader = new DataReader(stream))
{
    var read = await reader.LoadAsync(MAX_PAYLOAD_LENGTH);
    string CurrentPayload = reader.ReadString(read);
    if (CurrentPayload != LastPayload)
    {
        callback(CurrentPayload);
        LastPayload = CurrentPayload;
    }
}

Sample App code to publish information:

StartupTech.WindowsStore.Library.ApplicationNotification notify = 

new StartupTech.WindowsStore.Library.ApplicationNotification("AccountNumber");
notify.NotifyApps(StatusTextBox.Text);

Sample App code to consume notifications

StartupTech.WindowsStore.Library.ApplicationNotification notify = new 

StartupTech.WindowsStore.Library.ApplicationNotification("AccountNumber");
notify.Subscribe(ReceivedNotification);

void ReceivedNotification(string Payload)
{
     SetStatus("Payload received : " + Payload);
}
The complete project for the AppNotification library can be found here.

Just a reminder to add the Documents folder capability to your Windows Store application and configure it for the .topic file extension. That is the only file extension you can access from your app.

If you need Windows Apps to communicate across machines you can look at SignalR instead. See my post on this scenario.

Note that these samples were tested with Visual Studio 2012 + Update 1.

From the SignalR site, here are the NuGet packages you need to pull into your self-hosted server app:

Install-Package Microsoft.Owin.Hosting –pre

Install-Package Microsoft.Owin.Host.HttpListener –pre

Install-Package Microsoft.AspNet.SignalR.Owin

And the server code is here:

using System;
using Microsoft.AspNet.SignalR;
using Microsoft.Owin.Hosting;
using Owin;
using Microsoft.AspNet.SignalR.Hubs;

namespace SignalRNotifier
{
    class Program
    {
        static void Main(string[] args)
        {
            string url = "https://localhost:8080";

            using (WebApplication.Start<Startup>(url))
            {
                Console.WriteLine("Server running on {0}", url);

                string c = Console.ReadLine();
                while (!string.IsNullOrEmpty(c))
                {
                    if (c == "S") // Send a message to all clients.
                    {
                        GlobalHost.ConnectionManager.GetHubContext<MyHub>().Clients.All.addMessage("Hello World");
                    }
                    c = Console.ReadLine();
                }
            }
        }
    }

    class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            var config = new HubConfiguration { EnableCrossDomain = true };
            app.MapHubs(config);
        }
    }

    [HubName("TestHub")]
    public class MyHub : Hub
    {
    }
}

For the client app, simply get the client package as follows:

Install-Package Microsoft.AspNet.SignalR.Client 

and the client code is extremely simply too:

using Microsoft.AspNet.SignalR.Client.Hubs;
using System;

namespace SRClient
{
    class Program
    {
        static void Main(string[] args)
        {
            var hub = new HubConnection("https://localhost:8080");
            IHubProxy h = hub.CreateHubProxy("TestHub");
            
            hub.Start().ContinueWith(task => 
            {
                if (task.IsFaulted)
                    Console.WriteLine("Failed: {0}", task.Exception.GetBaseException());
                else
                {
                    Console.WriteLine("Connected with id {0}", hub.ConnectionId);
                    h.On("addMessage",  data => Console.WriteLine("Got the event from the server! [" + data + "]"));   
                }
            });
            Console.ReadLine();
        }
    }
}

You can start multiple clients in different command windows and see all of them get updated near instantaneously.

SignalR is great library for many purposes. Get to know it!

The support for .NET seems pretty deep, my code referenced some pretty advanced assemblies and it all worked perfectly. I've only tried console apps and they pretty much cover all aspects of the framework from Xml, Networking, web services etc. WinForms and WebForms support is supposed to be very good too although I haven't tried them yet. If you have a Mac or Linux box, then please check out Mono. 

Most WCF developers will use MEX at some point in their projects. It is a convenient way to expose and consume metadata about your WCF service. Normally you can use the built-in MetadataExchangeClient class which was made specifically for consuming a MEX endpoint.

WCF provides you standard bindings for using MEX across the usual set of protocols, HTTP, HTTPS, TCP and named pipes. Here is an example of using the WSHttpBinding:

WSHttpBinding mex = (WSHttpBinding)MetadataExchangeBindings.CreateMexHttpBinding(); MetadataExchangeClient mec = new MetadataExchangeClient(mex);

In most enterprises you often use custom bindings, so you can replace the binding above with your custom binding – as long as you are using the same custom binding with the service. However, where I hit a road block was in using custom client behaviors with MetadataExchangeClient. There does not seem to be any obvious way to attach behaviors to the outgoing MEX requests. After doing some experimentation, I realized that the MetadataExchangeClient class is extensible and the way to do this is to write a simple class that inherits from it and then override a couple of methods as follows:

public class MyMexClient : MetadataExchangeClient

{

   Binding MexBinding = null;

   bool RequiresClientCertificate = false;

   public MyMexClient(Binding b): base(b)

   {

       MexBinding = b;

   }

   public MyMexClient(Binding b)

       : base(b)

   {

       MexBinding = b;

   }

   protected override ChannelFactory<IMetadataExchange> GetChannelFactory(EndpointAddress metadataAddress, string dialect, string identifier)

   {

       ChannelFactory<IMetadataExchange> MexFactory = new ChannelFactory<IMetadataExchange>();

       MexFactory.Endpoint.Binding = MexBinding;

       MexFactory.Endpoint.Address = metadataAddress;

       // Add your client behavior here ...

       MexFactory.Endpoint.Behaviors.Add(SomeBehavior);

       return MexFactory;

   }

}

Now you simply use MyMexClient wherever you would normally use MetadataExchangeClient.