Work in Progress: How to write reusable components that work both locally and on the platform

This page is work in progress. At present, this document should be viewed as ideas and no official code yet exists

A brief introduction to why dependency injection is key!

Consider having created a task generator, that during its task preparation phase requires a SPARQL endpoint. You may be tempted to simply write:

class MyTaskGenerator {
  public void init() {
    createContainer("git.project-hobbit.eu:4567/henning.petzka/facetedgoldvirtuoso/image", envVariables);
  }
  ..
}

If you think: That was too easy - well, here is the next task: Adapt above code so that for testing purposes, you can use an in-memory triple store. If you now think: I can just create a new class, then read on how to do this properly. They magic phrase is dependency injection. The following examples are based on the popular Java Spring framework.

// The spring annotation lets us mark our platform components as components using ... @Component! This is not by chance.
// The annotation just tells dependency injection frameworks that a class is subject to dependency injection
@Component
class MyTaskGenerator {
  @Autowired
  SparqlBasedService sparqlService; 

  public void init() {
  }
  ..
}

You see - now the TaskGenerator only declares that it want's some SparqlBasedService and that's it. All logic in the TaskGenerator built on this service will just run as usual, as long as sparqlService is a valid Java object.

Configuration

But how can we now get a concrete sparqlService object into our TaskGenerator? The answer: Configuration classes. These are simply classes with methods annotated with @Bean. Beans are Java object subject to injection into components.

@Configuration
class MyLocalTestingEnviroment {
    @Bean
    public SparqlBasedSystemService preparationSparqlService() {
        VirtuosoSystemService result = new VirtuosoSystemService(
                Paths.get("/opt/virtuoso/vos/7.2.4.2/bin/virtuoso-t"),
                Paths.get("/opt/virtuoso/vos/7.2.4.2/databases/hobbit_1112_8891/virtuoso.ini"));

        return result;
    }
}

Probably you can already see the pattern, that you can simply create another configuration class for another environment

class HobbitPlatformEnvironment {
    @Bean
    public SparqlBasedService preparationSparqlService() {
        return new SparqlServiceThatGetsStartedViaSendingAMessageOnTheCommandQueueWhichStartsADocker(...);
    }
}