# Modules: Adding functionality to Joseki

The functionality provided by a Joseki server takes the form of different modules which are dynamically loaded when the server starts. This includes all query language processors, other operations and the data-specific "fetch" handlers.

## Module

A module is simply a loadable unit. It must implement the following interface and must have a constructor with no arguments.

    public interface Loadable
    {
        public String getInterfaceURI() ;
        public void init(Resource binding,
                         Resource implementation,
                         AttachedModel aModel) ;
    }

It provides the URI of the functionality and this is checked against the configuration details.

Whenever a module is loaded and instantiated, the `init` method is called. The `init` method is given the resources from the configuration file that caused it to be loaded because these can have additional, module instance specific parameters. init is called once per instantiation of a module, just after the object is created.

## Example Declaration

Consider the following example for the query processor for the GET operation. The first form is taken from the Joseki standard definitions file (a collection of common modules) that can be referenced from the configuration file.

    <http://server/testdata>
        . . .
        joseki:hasQueryOperation joseki:BindingGET ;
        . . .

    joseki:BindingGET
        a   joseki:QueryLanguageBinding ;
        joseki:queryOperationName  "GET" ;
        module:interface           joseki:QueryOperationGET ;
        module:implementation      joseki:ImplQueryOperationGET .

    joseki:ImplQueryOperationGET
        a   joseki:QueryOperation ;
        module:className
            "org.joseki.server.processors.QueryProcessorGET" .

The second form below is an equivalent way of defining the module, but puts everything inline in the configuration file:

    <http://server/testdata>
      . . .
      joseki:hasQueryOperation
        [ a   joseki:QueryLanguageBinding ;
          joseki:queryOperationName  "GET" ;
          module:interface           joseki:QueryOperationGET ;
          module:implementation
            [ a   joseki:QueryOperation ;
              module:className
                 "org.joseki.server.processors.QueryProcessorGET" ;
            ]
        ] ;
      . . .

The property `joseki:hasQueryOperation` indicates the module; it is a subPropertyOf `module:module`.

The module description is in two parts: the binding being made, which is the instance of the module, and the implementation to be used, specifying the Java class name. There is a binding-specific parameter, `joseki:queryOperationName "GET"`, which provides additional information.

## See Also

Data sources are not restricted to just files and Jena database backed models. Adapters can be written that execute an operation against any data source with the requirement that the results are in RDF. These adapters are loaded through the module mechanism.

The fetch mechanism uses modules to provide the server-side functionality that defines data objects.