Assignation
Whats is an Assignation
An Assignation is the process of running a Task in Arkitekt, and happens everytime you want to instruct an App to do something with your data. Importantly task assignment in Arkitekt are done not directly but through a "Reservation" which is our way of abstracting the concept of "where" and "how" a task should be run.
Also an Assignation is an ongoing process, and can be cancelled at any time. Cancellation
is again an integral part of the Arkitekt design (and seperates it from a lot other message
broker based systems). This is because we want to be able to cancel tasks at any time, and
interupt critical processes if needed.
Because we establish a streaming network where nodes can produce data over time, Assignations are also a way to establish data streams and will not onyl execute once, but can return continouelsy new data over time. (See below for more on this).
The path of an Assignation
Understanding the concept of Assignation is rather an "implementation detail" of Arkitekt, and we are abstracting it more and more away, so you do not need to crasp it to use Arkitekt. Just think of Assignation as a way to run a Bioimage Task in Arkitekt.
When you create a Task in Akriekt you are essential creating a docket, a list of workitems
that need to be done. Lets say you want to run a task like segmentation on a dataset.
You search the node "Segment Cells", you reserve it and you have decided to not care where it runs, so you instruct Arkiekt to "auto" reserve it, essentially letting Arkitekt decide where to run it. This reservation of the Node is now our entrypoint for all the tasks that we want to run in this configuration.
When you now are ready to run the task, and you enter the data you want to segment, you create an Assignation with the parameters of the task. This Assignation is now a "workorder" that is being sent through a pipeline of tasks.
First Arkitekt acknoledges that you assigned the task (you had the permissions, and your parameters made sense), it entered the "Assigned" state. Now Arikitekt will put it through the rabbitmq based message broker, where it will be routed to the correct node. This is the process of "routing", once the task is routed to a desired implementation, the tasks is now "bound" to this tasks is now "bound" to this implementation, and the implementation is responsible for running the tasks. Binding is an important concept in Arkitekt, as it allows us to keep track where exactly tasks are being executed so that we can always cancel them if needed.
Once the task is running, the implementation will send back results to Arkitekt, which will then be sent back to the user. This is the process of "yielding" results from a task. Once the task is done, Arkiekt will mark the task as "done" and the assignation is completed.
At every step of the way, the assignation can be cancelled, by giving the Assignation ID to Arkitekt, and Arkitekt will then cancel the task, sending the request to cancel to the implementation, and then marking the task as "cancelled".
Cancellation is not as trivial as it sounds, as computers are not always able to stop a process at any time. We have put a lot of care in our SDKs to make sure that cancellation is as smooth as possible, but some tasks might not be able to be cancelled at any time. Please be aware of this when you are running critical tasks.