Services

Apart from applications, SiteFusion can also run services. These are a different kind of process that operate in the background and can offer "services" (hence the name) to applications. Services can be added to the Service List in SiteFusion Admin:

As shown, services can run as two kinds of processes:

One Continuous Process: This process will be always-on and functions like a daemon. Multiple applications can connect to it.

Multiple On-demand Processes: This kind of service process will be started as soon as an application requests it. If multiple applications request this service, every application gets its own service process.

Where an application is started through a .startup.php.inc file, a service is started through a .service.php.inc file. A service, like an application, is part of an application group (or 'owner', the directory that the service resides in). When referring to a service, the name of the application group and the name of the service file without .service.php.inc are used. Let's start with a very basic service class. We'll assume the following code is placed in 'myservice.service.php.inc' in the 'testapp' application group:

As you can see, there's no authorizeLogin() function since services can only be addressed by application processes, which take care of external logins. Then, instead of a getApplication() function, there's a getService() function that does the same thing. It returns the name of the service class, and receives the arguments set for the service (if any).

The service class itself has an init() function, like an application. However since there's no window, there's no window initialized event, and thus the init function of the service receives the arguments as its only parameter.

The Service class shares a set of functions with the Application class, that allow it to set timeouts and intervals, and to send and receive global events. In the example above, an interval is set to execute the function sendText() every ten seconds. This function then sends a global event named 'myEvent', carrying the text in the array. This global event can be received by applications or other services in the same application group, or by any process that joins a shared Event Group.

A service can also offer an interface to applications, that can be used to call methods inside the service and get data returned. This functionality can be used to dispatch and queue certain tasks centrally, to keep operations going after the application is closed, or to multithread your application. Lets extend the previous Service class:

As you can see, a call handler for the function 'myFunction' is set and will be handled by the method 'onMyFunction'. Now lets look at it from the application side. You can use the Application::getService() method to connect to a service.

<?php

// We assume here that you are inside the Application class,// $this in this context refers to that class

// Have the service calculate the sum of 3 and 5 for us$sum = $service->myFunction( 3, 5 );

// Now $sum contains the string// "You gave 3 and 5, which adds up to 8"

This is of course a very simple example, but it demonstrates the power and ease of services. Anything can be passed to a service call and returned from it, even complex object structures. You could write an entire daemon inside a service, and have applications connect to it and exchange data with it using shared classes and objects. Even exceptions thrown in the call handler of the service get transferred to the application and can be caught there.