services - Datomic/simulant GitHub Wiki
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.
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.
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.
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.
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
.)
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.