Create and Build the Service Project

Each service project defines and builds a service provider, service requestor, and its service UI (optional). A recommended template for a service project in the examples/service describes an elementary service project created with InteliJ as described below. It is advised to review the tutorial on Data Contexts, Context Models, Service Routines to learn the basics of the Service Mogramming Language (SML).

Create the Service Project Directory Structure

Create the following directories for Java sources, configuration files, and netlets
```
src/main/java
src/main/netlets
src/main/resources
src/test/java
configs
```
Mark java directories in InteliJ as Resources Root
Create the following packages in src/main/java for the adder service provider
- for a service type implemented by the provider
```
     sorcer.provider.adder
```
- for the implementation of the service type
```
     sorcer.provider.adder.impl
```
- for a service UI delivered by the provider to requestors
```
     sorcer.provider.adder.ui
```
- for the service requestor
```
     sorcer.requestor.adder
```
Finally create the package for JUnit tests of your provider in th directory src/test/java
```
sorcer.provider.adder
```
See the project directory structure with all related files at the end of this page.

Develop Service: Provider, JUnit Test Cases, Requestor, and Service UI

Create build.gradle (use a provided template in the examples/service project). The template creates four artifacts.

a jar file with the classifier prv to run your provider,
a jar file with the classifier req for your requestor,
a jar file with the classifier dl for downloadable code needed by the collaborating services.
a jar file with the classifier ui for downloadable service UI published by the provider.

Declare your new project in the settings.gradle file of the root project by adding the following line: include examples:service

Follow the following steps to develop your service.

Define a service type of the provider, Java interface Adder in
```
sorcer.provider.adder
```
Use this guidelines to Design a Contextual Service Type for your provider.
Implement the interface Adder, Java class AdderImpl in
```
sorcer.provider.adder.impl
```
Develop JUnit test cases for local and remote SML service requests for your provider in
```
src/test/java/sorcer/provider/adder
```
Selected and tested JUnit service requests in SML in the form of netlets install in
```
src/main/netlets
```
Subclass the genericServiceRequestor class, e.g., as AdderRequestor and implement the inherited abstract method that creates exertions and/or reads netlets:
```
ServiceRequestor#getExertion(String... args) : Exertion
```
Develop a service UI (optional) as Java class AdderUI to request services in
```
sorcer.provider.adder.ui
```
Use these guidelines to Setup a Service UI for your provider.

Enable Signature-Based Provisioning (SBP)

You can enable service provisioning by using the deployment operator with signatures that refer to providers to be provisioned. The minimum required when using deploy operator is to provide a provider configuration as follows:

    deploy(configuration("configs/adder-prv.config"))

In that case the provider configuration should include additionally the component sorcer.core.exertion.deployment with entries for signature-based provisioning.

Alternatively you can create an artifact for the configuration file, for example, for the file “configs/adder-prv.config” to be available from the repository as org.sorcer:adder:config:5.0. In that case you can enable signature-based provisioning as follows:

deploy(configuration(“org.sorcer:adder:config:5.0”))

See as an example the netlet examples/service/src/main/netlets/dynamic-adder-netlet.groovy with its provider config file examples/service/src/main/configs/adder-prv.config and its artifact defined in build.gradle of the examples/service project.
Read more on On Demand Service Provisioning.
To enable provisioning with SOS you need to start SORCER with the task
```
gradle bootSorcerRio
```
To halt SOS started up with the task bootSorcerRio call
```
gradle  terminateSorcerRio
```

Develop a Configuration for the Service

Configuration files for both provider and requestor are in example/service/configs. Both the provider and the requestor might have defined domain specific properties in Java properties format, in files: adder-prv.properties and adder-req.properties correspondingly.
The provider properties file is declared in the provider configuration (deployment) file adder-prv.config with the entry:
```
properties="adder-prv.properties";
```
if the file is placed in src/resources/configs directory. This file from here is included into the provider’s artifact so it will be loaded as the resource from the provider’s jar in any place in the network where it gets provisioned.
The requestor properties file is declared as the system property, for example in runReqestor as follows:
```
systemProperty "requestor.properties", "configs/adder-req.properties"
```
These domain specific properties that are loaded by both provider nad requestor at startup are available directly by calling the provider and requestor with operation:
```
getProperty("any.domain.specific.property");
```
Logging properties for both provider and requestor are sorcer-prv.logging and sorcer-req.logging correspondingly, they define the corresponding log files you can find in logs directory of the service project.
There are two provider configuration files. The first one, mentioned above already, adder-prv.config and a startup file StartAdderConfig.groovy. The former configures the provider itself, the latter a service starter that might launch multiple providers per a JVM and needs service descriptors with configuration files for all booted providers. A configuration file adder-prv.config in Jini format can be replaced by the equivalent file AdderPrvConfig.groovy in Groovy format.
Read more on Configuring SORCER Services.

Build and Test the Service Project with Gradle

Logging and Test Results

A Java logging properties files sorcer.logging.groovy (Logback) and sorcer.logging (JDK logging) are in
```
distribution/build/sorcer-version>/configs
```
Take into account that gradle clean removes the build directory of distribution.
SORCER OS logs as specified by sorcer.logging.groovy and sorcer.logging properties are in
```
 distribution/build/sorcer-version>/logs
```
Test results created by the gradle test task are in
```
build/test-results
```
Custom service project logs for a provider and requestor can be optionally managed with local logging configurations in the service project local logs directory

Service Project Directory Structure

The created service project directory structure with related files looks as below (see it in the examples/service project in the SORCER project install directory).

SORCER
|
`-- examples
  `-- service
    ` build.gradle
    `-- configs
      ` adder-prv.config
      ` adder-req.properties
      ` sorcer-prv.logging.groovy
      ` sorcer-req.logging.groovy
      ` StartAdderConfig.groovy
      ` addder-netlet.groovy
    `-- src
      `-- main>
     	`-- java
     	  `-- sorcer
     	    `-- provider
     	      `-- adder
     	        ` Adder.java
     	        `-- impl
     	          ` AdderImpl.java
     	        `-- ui
     	          ` AdderUI.java
     	    `-- requestor
     	      `-- adder
     	        ` AdderRequestor.java
     	`-- netlets
     	`-- resources     	        
      `-- test
     	`-- java
     	  `-- sorcer
     	    `-- provider
     	      `-- adder
     	        ` LocalTasks.java
     	        ` NetTasks.java