Skip to content
stuarthalloway edited this page Jan 2, 2013 · 2 revisions

Services represent any resource that a simulation might need to use. Service can include both the system(s) under test, and code used to capture results.

A full service lifecycle includes creation, initialization, accessing the service during a simulation process, and finalizing the service when the process is completing.

Creation

Services are entities in the database, and are related to a sim via the sim/services attribute. Services can be related to a sim, or to a process within a sim. If a service is related to a sim, it will be available to all processes in that sim; otherwise, it will be available only to the specific process it is related to.

Initialization

Service entities implement start-service based on their :service/type tag. This method should do any necessary setup, and return an object that will be made accessible to the sim process.

Access

Service entities must have a :service/key tag, which uniquely names the service within a simulation process. The object returned by start-service is stored under this key in the *services* map.

Finalization

At the end of a process's simulation run, the finalize-service method is called on all service entities. The *services* map is still in dynamic scope at this time. (Note: When a simulation process uses multiple services, there are no ordering guarantees for calls to start-service or finalize-services.)

Example

The simulation library includes an example service, :service.type/actionLog, that demonstrates how a service can be used to capture results from a sim. The action log works as follows:

  • start-service creates a temporary file, and returns a function that writes data to that file.
  • During a sim, actions can record data about themselves by writing "eventy" transaction data to that temporary file.
  • finalize-service then batches up the data, and transacts it into the sim database for study later.

The hello world example creates an event log, records how long each trade took, and then validates that the trade times meet a nonfunctional performance requirement.