Develop a system adapter

This article is a tutorial to write a system adapter for an existing system that should be benchmarked inside the Hobbit platform. It is recommended to read the overview article before reading this tutorial. Additionally, the general hints on components should be read. If the system adapter will be developed in Java, there is a more detailed tutorial how this development can be supported by using the HOBBIT core library.

Benchmarked system API

The API the system (or system adapter) has to offer to interact with the Hobbit platform is defined as follows.

• It has to use the hobbit session id and RabbitMQ host name that are available as environment variables.
• It has to be connected to the command queue
• After the system is started, it has to initialize itself. At the end of the initialization, the system has to send the Commands.SYSTEM_READY_SIGNAL id (=0x01) on the command queue.
• It has to listen to the command queue and should react on the Commands.TASK_GENERATION_FINISHED id (=0x0F).
• It has to implement the API of the benchmark with which it should be benchmarked. Note that this API can vary and should be described in more detail by the benchmark. Typically, the API looks as follows.
  • The system might connect to the hobbit.datagen-system.<sessionId> queue to receive data.
  • The system has to connect to the hobbit.taskgen-system.<sessionId> queue to receive tasks.
  • The system has to connect to the hobbit.system-evalstore.<sessionId> queue to send its result to the evaluation storage.
  • All three queues follow the work queue pattern and have to be setup with
    • their queue name (<sessionId> has to be replaced with the current session id),
    • durable = false
    • exclusive = false
    • autoDelete = true
    • and no additional arguments

The typical messages of the different queues are described in the following.

The data queue

The structure of messages in the data queue is solely defined by the benchmark.

The task queue

Every task has a unique id that is used to map the task to the response that the system created. That means that a message in the task queue always should contain an id that has to be sent to the result queue together with the result.

start byte	length	meaning
0	4	task id length as 32 bit integer (t)
4	s	task id
s + 4	4	data length as 32 bit integer (d)
s + 8	d	data

The task id is a UTF-8 encoded String. However, it does not have to be encoded and can be user as byte array for the message that has to be sent to the result queue. The data is a byte array and its content/meaning is solely defined by the benchmark.

The result queue

The result of a task has to be sent to the result queue together with its task id.

start byte	length	meaning
0	4	task id length as 32 bit integer (t)
4	s	task id
s + 4	4	data length as 32 bit integer (d)
s + 8	d	data

The data is a byte array containing the result as it is defined by the benchmark.