Application Server Update

October 1, 2014

Progress continues. It’s pretty solid.

The key features that I have been driving for are working:

  • It is hub centric, but the nodes work if the hub is unreachable, and the hub works if the nodes are unreachable. It all recovers. The bus is resilient.
  • Easy Install – you can install an app server on any machine from the website, if you have the proper credentials
  • Multiple Install – you can install the app server multiple times on a single machine. This is good if a single machine is serving multiple roles.
  • Automatic Update – each time the app server starts, it downloads the latest DLLs and other files as necessary. Is should also update without waiting for a restart (as devdash did), but I didn’t get to that yet
  • Dependent Features – If your feature is associated to another feature, it will start the other feature first. You cannot shutdown the parent feature until all child features have been shutdown. (IE: If your feature hosts a scheduled job, it will start the Local Scheduler feature)

There are features built in for the application server itself, such as the Application Host Feature, which hosts all of the applications. There’s another one to manage the bus.

Aside from that, I’ve introduced two features for application use. Currently they are both minimal, but functional.

  • Local Scheduler – if you need something to execute every x minutes, put an attribute on the method that you want to execute. You can change the interval at runtime by issuing a ScheduleChange command.
  • Web Api Host – Associate your API controllers to a feature by putting an attribute on the feature. The Web Api Host Feature will start the OWIN self host. The neat thing about this is that, left to it’s own devices, the OWIN host makes every controller available. In this case, if a controller is associated to a feature that isn’t started, then the controller should not be reachable. The feature keeps track of which controllers are reachable, and which are not. It will return a 404 if you request a completely valid controller whose feature is not started.

    A controller can be associated to multiple features, and as long as one of those features is started, the controller will be reachable.

I have purchased a confluence site for documentation purposes, and I’m slowly filling it in as I do new stuff, but it’s really light at this point. I’ll publish the URL once there’s more substance there.

Scheduled Task

 

namespace SomeGuySoftware.DemoApp
{     using System;     using System.Threading.Tasks;     using SomeGuySoftware.ApplicationServer.Contracts;     public class AnotherPeskyFeature : ApplicationFeature     {         protected override Task OnStart()         {             return Task.FromResult<object>(null);         }         protected override Task OnStop()         {             return Task.FromResult<object>(null);         }         [Schedule("Whatever", "00:00:10")]         public void RunPeriodically()         {             Console.WriteLine(DateTime.Now + ": timer fired");         }     }
}

API Controller

namespace SomeGuySoftware.DemoApp
{     using System.Threading.Tasks;     using SomeGuySoftware.ApplicationServer;     using SomeGuySoftware.ApplicationServer.Contracts;     using SomeGuySoftware.ApplicationServer.Contracts.Events;     [WebApiHost(typeof(YabbaDabbaDooController))]     public class DemoFeature1 : ApplicationFeature     {         public ScopedEventContextBase EventContext { get; set; }         protected override Task OnStart()         {                 return Task.FromResult<object>(null);             }         }         protected override Task OnStop()         {             return Task.FromResult<object>(null);         }     }
}