Summarizing the experience of the successful co-organization of the DEBS Grand Challenge 2017 on the HOBBIT platform, we made one step towards a more lightweight and productive design-development of HOBBIT-related software components. We are happy to announce a standalone software library called the HOBBIT Java SDK.

The proposed SDK is targeted to make the design and development of HOBBIT-compatible components easier and to execute them locally without having a running HOBBIT-platform instance.

The SDK helps platform users with the following tasks:

  • Design systems for benchmarking and debug them within a particular benchmark
  • Design a benchmark and debug the interactions between its components
  • Upload results (docker images of your components) to the online platform

Technically the SDK is focused on the orchestration of docker images/containers for all the required components. Basic implementations of hobbit-related components (described here) are also included into SDK to demonstrate how the local debugging process may be organized. As a result users may execute and debug their systems/benchmarks either “as is” (and hit the breakpoints in the code) or being packed into docker containers (the same manner as components will be operated by the online platform). The SDK provides users with internal log messages from the containers, which make the debugging process more effective and less time-consuming.

Use cases

The proposed SDK covers the requirements of  the following groups of users of the HOBBIT platform:

  • System developers. Being a system developer (e.g. participant of a challenge) you need to be sure, that your system is compatible with the particular benchmark and produces proper results, which will be evaluated. To make such check possible you should obtain a particular benchmark at least as docker image (or a set of images – one for each component). Having container images or source codes of benchmark components (described here) you submit them and your system into the components executor (offered by SDK’s) to run/debug them together locally. The final result you have to provide to the online platform is a docker image of your system (see submission details). The image can be created either manually (described here) or by creating a dockerizer using the primitives provided by the SDK. Submitting  the components’ dockerizers  into the SDK’s executor you are able to test how your system behaves together with the benchmark (both being packed into docker containers). All the related actions (image building, creation/start/stop/getting logs from containers) are performed by the SDK automatically. The only thing you should make sure is that the image is build from the latest version of your artifacts or you may use cached containers to avoid image building/container creation on every run. Finally you have to push you working and tested images of your system to the online platform as it described in the procedure.
  • Benchmark developers. Being a benchmark developer (e.g. challenge organizer) you need to be sure that all components of your benchmark (including a mock-up of a benchmarked system) interact properly. Your pipeline is the same as for the system developer, but differs with the number of components. Submitting your components into SKD’s components executor you are able to debug the whole chain of interactions between them. Having programmatic dockerizers (based on SDK’s primitives) you are able to automatically build docker images and run containers for each of your components in one click. Finally you have to  push your images to the remote repository of the platform as it described in the procedure.

Find source codes, details and requirements of the procedure please at the SDK’ github. Feel free to ask your questions and share experiences under the issues tab.

Spread the word. Share this post!

Leave A Reply

Your email address will not be published. Required fields are marked *