Controlling availability of services at runtime

Feb 3, 2014 at 3:02 PM

I'm looking to implement your framework in a bespoke internal hardware control server. My project consists of several distinct logical "services", so I will have more than one class inheriting from "JsonRpcService". I'm building on top of your "Getting Started sockets" example.

As far as I can see, services get automagically registered with the framework upon creation. Can this process be controlled at runtime? For example, in some cases, I'd like to temporarily disable one service, but leave others running. Is this possible within the framework?

Feb 3, 2014 at 6:54 PM
Yes, and no.

You can currently add new service methods at runtime.
You can have multiple different Service "instances" based off of a sessionID, and you can create these at runtime, and register different methods with those.

There is currently no method exposed that lets you remove a service method, or destroy a service instance. It would be fairly trivial to add support for that if you need to be able to un-register a service method, or destroy an entire service.

You can create additional service instances by calling:
var additionalService = AustinHarris.JsonRpc.Handler.GetSessionHandler("your instance tracking id here");
// add a new method to that Session
additionalService.Register("MethodName", x => { return something; });
additionalService.MetaData.AddService("MethodName", new Dictionary<string,Type>{ {"parameterName1", typeof(Parameter1) }, {"returns",typeof(returnType) }});
// then call that method by:
additionalService.Handle(JsonRequest, optional Context);
// Or this, which does exactally the same thing.
AustinHarris.JsonRpc.Handler.GetSessionId("your instance tracking Id here").Handle(JsonRequest, optional Context);
Marked as answer by janbreens on 2/4/2014 at 3:39 AM
Feb 4, 2014 at 11:43 AM
Edited Feb 4, 2014 at 11:45 AM
Hey AustinHarris,

Thanks for the quick reply! I'll stay away from explicit method registration; Being able to rely on fully automatic method registration is more important that restricting service access at the moment (not to mention it feels a bit neater as well), thanks for the option!