Spludlow Service Configuration File

Contents

Introduction. 1

“Method” Task. 1

“Server” Task. 1

 

Introduction

Every service process (Windows Service) listed in Applications.txt, that is Framework managed (has a port number in the Hosted column), must have a service configuration file with the filename being the “ApplicationId” with a “.txt” extension.

This is a list of all the tasks that a service should be doing. The file format is not a TextTable, this time, but the same tabbing and comment rules apply.

There are 2 types of task; “Method” and “Server”. All entries in this file must start with one of these task types followed by the details of the task, the line format is different for each task type.

“Method” Task

The simplest of the 2 task types. It simply means run the specified method. The method is intended to run indefinably (the method does not return or drop out the bottom).

The line must always start with the word “Method” followed by a Key, used for identification, the ATM and then optional guessed data type parameters. Here’s an example line, that runs the logging queue processor:

#Method             Key        Assembly            Type                                                      Method               Parameters

Method               Log         Spludlow             Spludlow.QueueProcessor          Run                        Log

“Spludlow.QueueProcessor” is a class that contains a “Run” method that takes a single string parameter. This method is used to execute calls on a message queue, the parameter is the message queue name. That’s all it does and it sits pretty running as a “Method” Task.

 If you have more than one parameter, you can keep specifying along the line them tab delimited, the data types will be guessed.

If you have more complicated parameter requirements or need to specify constructor arguments or CallFlags then you are going to need “Partial CallText”, see the CallText section. To use it put an at sign ‘@’ as the parameter, all lines following will be interpreted as partial CallText up to the next empty line.

Here is an example of using a “Method” task to run a Minecraft server:

Method               MineCraft           Spludlow             Spludlow.ProcessExecutor          Run        @

P00         filename             String                    C:\Program Files\Java\jre1.8.0_71\bin\java.exe

P01         arguments          String                    -Xms2G -Xmx2G -jar minecraft_server.jar nogui

P02         directory             String                    C:\MINECRAFT

P03         varibles String[]

P04         outputFilename               String                    C:\MINECRAFT\OUTPUT.txt

P05         restartOnExit     Boolean               True

P06         stopInput            String                    /stop

“Spludlow.ProcessExecutor” is a class with a “Run” method that has more parameters than the previous example. This method is used to permanently run a process, could be any process.

If you are writing a server, or some indefinitely running process, always consider the simpler “Method” task type first, because it’s simpler. If you do need to communicate with some server can you do it through the file system for example?

If the ATM’s class contains a “Stop()” method it will be called for clean shutdowns, then given 10 seconds to finish. If it doesn’t or hasn’t got a “Stop()” method the thread will be aborted.

After adding a new Method task the Windows service should be restarted, you can do it through the Status page of the Intranet.

“Server” Task

This is what you use when a simple method isn’t enough, you want a server that you can interact with, you want a persistent object that holds state and make method calls from clients. This is achieved by the Framework creating standard .net WCF TCP servers (used to be called .net Remoting). You don’t need to mess about with .net XML configuration files on the server and client (I can tell you they are a nightmare), the Framework takes care of it all, just specify the Assembly and Type to your code, make sure you’ve defined an interface in your code and the framework does the rest.

Example of 2 “Server” task lines:

#Server Key                                        Assembly            Type                                                      Port

Server   ParallelResults                 Spludlow             Spludlow.ParallelResults             32101

Server   MyCompLegacyData      MyCompLib       MyCompLib.LegacyData*            32102

Here we have a Framework server “ParallelResults” used for orchestrating parallel calls and a user server “MyCompLegacyData” that could be used to access an obscure data source.

The default “Instance Context Mode” for Server objects is “Single” meaning; one instance of the object is created on the sever, client method calls use this single instance.

If the Type has a star ‘*’ at the end it means the object will be “PerCall” meaning; every client method call will create a new object instance on the server, then discard it.

Try to use “PerCall” if you can, it is considered more scalable, but many problems require a single instance design and that’s that.

Port numbers should count up from the base server port number 32100.

After adding Server Tasks, you must re-send configuration to all relevant hosts, using the Config.aspx Intranet page. The Framework will automatically add the WCF TCP addresses into “Spludlow.config” for the clients to use. Sending configuration will also automatically restart all applications on the host, so everything should be ready to use the new server.

To access the servers from other hosts on the local network you need to copy the WCF TCP addresses from “Spludlow.config” and put them in as user configuration at the network level on the Config.aspx page then send configuration to all hosts on the network.