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 Service-Oriented Script Basics to learn the basics of the Exertion-Oriented Language (EOL).
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
- for the implementation of the service type
- for a service UI delivered by the provider to requestors
- for the service requestor
Finally create the package for JUnit tests of your provider in th directory src/test/java
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 contextual service type of the provider, Java interface Adder in
Use this guidelines to Design a Contextual Service Type for your provider.
Implement the interface Adder, Java class AdderImpl in
Develop JUnit test cases for local and remote SML service requests for your provider in
Selected and tested JUnit service requests in SML in the form of netlets install in
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
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:
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:
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
To halt SOS started up with the task bootSorcerRio call
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:
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:
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
See also Project Automation.
If you have not built the SORCER project distribution yet, that’s the first step to do
Use the provided build.gradle template in the examples/service project. The template creates all needed artifacts to run your service provider, requestor, and service UI attached to the provider. All created artifacts allows you run JUnit test cases as well.
First build the project (in src/main/java) with not tests building and running
gradle build -x test
Install all your jars built to Maven Local Repository (.m2)
If SOS is not available in the network you can boot own collection of SOS services
or if you want to use services provisioned on demand
Start your service provider
Compile your test cases in src/test/java
Run your test cases
Run and test your requestor with Java exertions and netlets
At the level of the SORCER project (root project) start the service browser for testing your service UI
To halt SOS started up with the task bootSorcer call
or if you started up with the task bootSorcerRio call
Logging and Test Results
A Java logging properties files sorcer.logging.groovy (Logback) and sorcer.logging (JDK logging) are in
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
Test results created by the gradle test task are in
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