A 'client' represents something which submits work to the exchange
An exchange supports both 'client' requests (e.g.
Exposes the course-grained signature of pairing up jobs with worker subscriptions
Represents a match 'handler' which delegates out to other observers
Represents something which can check the current state of the exchange queues.
Represents something which can check the current state of the exchange queues.
This is current kept separate from the Exchange signature so as (1) to require/expose less about a particular exchange itself (2) more practically, expose potentially separate APIs in cases such as e.g. our ui
Contains instructions/information specific to the job scheduling/matching
Represents anything which can be run as a job
Represents anything which can be run as a job
Json is a bit prescriptive, but that's going to cover 95% of the cases. Even if we have binary data, we can base64 encode it as an option.
If we end up doing a lot of data transfer, then we can change the job representation to be an akka Source
represents the job submission. As the job repo is heterogeneous, it could match anything really that's asking for work
The details contain info about the worker subscribing to work, such as it's location (where work should be sent to), and any arbitrary json data it wants to expose (nr of CPUs, runAs user, available memory, OS, a 'topic', etc)
The details contain info about the worker subscribing to work, such as it's location (where work should be sent to), and any arbitrary json data it wants to expose (nr of CPUs, runAs user, available memory, OS, a 'topic', etc)
Once a WorkSubscription is sent
the json matcher used against the 'job' portion of SubmitJob
the json matcher used against the additional 'details' part of SubmitJob
An exchange supports both 'client' requests (e.g. offering and cancelling work to be done) and work subscriptions