Trentino - User Manual

info –qb will retrieve a list of all contribution available in the runtime

Trentino> info –qb
[contribution]: some.contrib.uri
[contribution]: other/uri

info –s –qb additionally shows the contribution states

Trentino> info –s –qb
[contribution]: some.contrib.uri (Running)
[contribution]: other/uri (Running)

It’s also possible to pass a contribution base uri to the info command in order to retrieve information about a specific contribution. Since it’s currently not possible to retrieve other information than the contribution’s state info –qb some.contrib.uri is the same as –qb -s some.contrib.uri

 Trentino> info -qb some.contrib.uri
[contribution]: some.contrib.uri (Running)
 

info –qc will retrieve a list of all the domain-level components (i.e. components not contained in a composite used as implementation). Components are referenced by their structural URI.

Trentino> info –qc
[component]: BuilderComponent
[component]: LoggerComponent
[component]: GUIComponent

info –qc some.contrib.uri will retrieve a list of all the components contained in the contribution with the given base URI.

Trentino> info -qc some.contrib.uri
[component]: BuilderComponent/BuilderImplComponent
[component]: BuilderComponent/LinkerComponent
[component]: BuilderComponent/CompilerComponent
[component]: LoggerComponent/SmartLoggerComponent/SmartLogger
[component]: LoggerComponent/LoggerImpl
[component]: LoggerComponent/SmartLoggerComponent
[component]: BuilderComponent
[component]: LoggerComponent
[component]: GUIComponent

Notice the structural URI style: LoggerComponent/SmartLoggerComponent/SmartLogger for example means that SmartLogger is contained in a composite used as SmartLoggerComponent’s implementation while SmartLoggerComponent itself is contained in a composite used as LoggerComponent’s implementation. The -s option can be specified also for components to retrieve their states: info –s –qc some.contrib.uri

In order to retrieve information about a specific component, the component’s URI must be passed to the info command. The simplest case is as follows: info GUIComponent will do nothing except for showing the passed component URI as output. This can be used to check for the existence of a component:

Trentino> info GUIComponent
[component]: GUIComponent
Trentino> info nonExistent
ERROR - Component with URI 'nonExistent' not found
Trentino>

info –s GUIComponent will additionaly show the component’s state

Trentino> info -s GUIComponent
[component]: GUIComponent (Resolved)

The –q option can also be used with any combination of the s, r and qqualifiers. For example –qs, -qr, -qp, -qrs, -qrsp etc. Where s retrieves information about services, r about references and p about properties.

Trentino> info -qsr LoggerComponent/LoggerImpl
[component]: LoggerComponent/LoggerImpl
    [references]:
        FileLogger
        ConsoleLogger
    [services]:
        Log

Additionally using the the –s options will retrieve also the state of the component as well as the states and wiring information of the services and references.

Trentino> info -s -qrs BuilderComponent/CompilerComponent
[component]: BuilderComponent/CompilerComponent (Resolved)
    [references]:
        Log (Resolved) -> LoggerComponent#service(Log) LoggerComponent#service(Log)
    [services]:
        ExecuteCompiler (Available)

The output tells us that CompilerComponent’s reference with the name “Log” is wired twice to the “Log” service implemented by the LoggerComponent. Furthermore CompilerComponent offers an “ExecuteCompiler” service that is in Available state.

Trentino> info -qp Person1
[component]: Person1
    [properties]:
        Name ( 'John Doe' )
        Age ( '23' )
        FavouriteNumbers ( '3' '9' '23' )

The p qualifier shows all the available properties and their values.

In order to retrieve information about a specific service or reference, its structural URIs must be passed as argument. Example:

Trentino> info -s LoggerComponent/LoggerImpl#reference(FileLogger)
[references]:
    FileLogger (Resolved) -> LoggerComponent/SmartLoggerComponent#service(FileLogger)
Trentino> info  -s BuilderComponent/LinkerComponent#service(ExecuteLinker)
[services]:
    ExecuteLinker (Available)

In order to retrieve information about a specific property, its structural URIs must be passed as argument. Example:

Trentino> info Person1#property(Name)
[properties]:
    Name ( 'John Doe' )

Trengen validates the contribution against Service Component Architecture v1.1 (SCAAM v1.1) and SCA client and implementation Model for C++ Specification V1.1.

USAGE 1:
trengen -cont <contribution_directory> -outdir <output_directory*> -lib <libname*>
        -libdirs <directory*> -includedirs <directory*> -d* -rtdir <runtime_directory*>
        -install_dir <contribution_installation_directory*> -v*

OPTIONS:
-cont <contribution_directory>|<zip_file_of_contribution_directory_tree>: specifies
        the root directory of SCA contribution, can be a zip file or a path.
-outdir <output_directory*>: If provided it specifies the output directory for the
        Trengen generated code. Default is <input_directory>Gen.
-lib <libname*>: Library names (not path) of the service/component implementations.
        Names are separated by ';' or ':'. Default is the contribution name.
-libdirs <directory*>: path separator separated list of directories, where libraries
        containing the service/component implementations are located. Default is <root>
        and <root>/lib.
-includedirs <directory*>: path separator separated list of directories, service and
        component header files are located. Default are <root>, <root>/services and
        <root>/include.
-d*: Optional. If provided, Trengen runs in debug mode. Default is -r.
-v*: Optional. If provided, Trengen shows info logs.
-rtdir <runtime_directory*>: specify the location of the Trentino Runtime. Optional
        since Trengen tries to resolve the runtime from itself.
-install_dir <contribution_installation_directory*>: Optional. Trengen generates a
        Cmake file for the generated code. It requires the location where binaries
        will be installed as result of a Cmake install. Default value is the 'META-INF'
        of the <contribution_directory>.

USAGE 2:
trengen -gencppitf <path to properties file>.properties> -inc <header file name*> -outdir <path to output dir
*>

OPTIONS:
-gencppitf <path to properties file>.tidl.properties: The tidl configuration file containing
        the information about the interface to be generated.The tidl file is a java resource
        file.It should contain an entry indicating the location of the interface to be used.
        If the path is a directory, then all *.tidl.properties files in the given directory will be processed

-inc    <header file name*> name of an optional header file to be included in the generated C++ header file.
-outdir <path to output dir*>: The path to the output directory this parameter is
        optional. The default value is the current directory.


I:\Trentino\trentino\DEV\cpp_build>


		Trengen outputs the generated code along with a cmake file under the [ContributionName]Gen folder at the same level with the contribution folder. The user should compile the generated code according to the provided CMake. As the result of the compilation of generated code the “sca-contribution.dll”, “sca-contribution.lib”, “sca-contribution.conf “ files are placed under the META-INF folder of the contribution. (For detailed sequence please see section :Compiling and Installing A Sample Contribution)


 

The validation includes a syntax and a semantic validation.

The Syntax validation validates the contribution and its artifacts (componentType files, composites, contribution documents, ...) against specified xsd schemas provided by the SCA specification.

To get the list of all syntax constraints that are validated by Trengen, please see Appendix A.

Semantic validation takes place after and if syntax validation was successful. It includes validation of the relationship between artifacts, the consistency of the whole contribution as defined by the SCA Specification

SCA binding for Trentino is done via TCP/IP. Following snippet shows the SCA binding element pseudo-schema.

<binding.sca uri="xs:anyURI"? name="xs:NCName"? requires="list of xs:QName"? policySets="list of xs:QName"?>
 <wireFormat/>?
 <operationSelector/>?
 <requires/>*
 <policySetAttachment/>*
</binding.sca>


 

The following SCDL is an example for the usage of binding.sca in Trentino.

<?xml version="1.0" encoding="utf-8"?>
<composite name="BasicCalculatorRemoteClientComposite" xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" targetNamespace="BasicCalculatorNamespace">
  <component name="BasicCalculatorRemoteClientImpl">
    <implementation.cpp
        class="Trentino::Example::BasicCalculatorRemoteClient::BasicCalculatorRemoteClientImpl"
		header="TrentinoExampleBasicCalculatorRemoteClientBasicCalculatorImpl.h"
        scope="composite" eagerInit="true"
		library="BasicCalculatorRemoteClient" >
		 <function name="onInit" init="true" />
		</implementation.cpp>
     <reference name="BasicCalculatorRef" >
	 	<binding.sca uri="tcp://localhost:5342/BasicCalculatorImpl/BasicCalculator"/>
    </reference>
  </component>
</composite>


 

Each binding.sca (in Trentino) must have a "uri" attribute. The convention for the attribute is represented below:

tcp://localhost:5342/BasicCalculatorImpl/BasicCalculator


 

"Uri" attribute of binding.sca must begin with "tcp://" which is followed by a valid host and a valid port. Host and port checks are done by Trengen. End-user is informed when there are some errors during validation before deployment.

In the next 10 minutes, we want to create a Hello World remote application and deploy it on two Trentino runtimes. The first runtime is a server and the second a client. On the Server, a contribution implementing the Helloworld Service is deployed. On the client, the contribution is having a reference using the service provided by server. The overall deployment diagram of our system is described in the following picture.

Assembly diagram of Helloworld remote

5.1.2.1. Create the Helloworld server application

Binding.sca is the default binding for all remotable services. If there are not any bindings specified for a remotable service, we can say that it uses binding.sca. If there are not any binding.sca specified, which port will be used by Trentino runtime? The Trentino runtime hosting the server application has a Binding.conf file. The contents of the Binding.conf is below:

binding.sca.port=5342
binding.sca.dll=TrentinoBindingSCA
binding.sca.thread.number=1
binding.sca.client.timeout=1500 #in miliseconds

The port in the Binding.conf is used if there are not any bindings in the remotable service. It is the port number that ZMQServer listens for a request and opens it for sending the response. End-user may edit the values of the parameters in the Binding configuration file.

5.1.2.1.1. Download all necessary files and setup development environment

Download and install the Trentino runtime as described in the Trentino Getting Started guide. It includes all the necessary binaries for developing a remote application. Now create a folder called HelloWorldRemote_Source. At the end of this section, we will end up with the following file structure:

Server folder structure

Since the application developed in this tutorial is platform independent, we will use Cmake as cross platform build tool. And therefore we need to define a CMakeList.txt file describing our project. Create a file named CMakeList.txt and paste the following code into that file:

cmake_minimum_required(VERSION 2.6)
project(HelloWorldRemote)

set(PNAME HelloWorldRemote)
##############################################################################
# 									MACROS									 #
##############################################################################

#----------------------------------
# MY_LINK_THIRD_PARTY_LIBRARIES 
#----------------------------------
#The libs to be linked to are expected to be passed as additional arguments after 'target'.
#This arguments have to be uncomplete variable names representing the libs
#The macro will append '_DEBUG' respectively '_RELEASE' to the passed arguments
#in order to produce real variable names that are expected to contain the real lib names.
#EXAMPLE: 
#The call MY_LINK_THIRD_PARTY_LIBRARIES(main Boost_FILESYSTEM_LIBRARY) expects the variables
#'Boost_FILESYSTEM_LIBRARY_DEBUG' (if build type is debug) respectively 
#'Boost_FILESYSTEM_LIBRARY_RELEASE' (if build type is release) to be defined
#----------------------------
macro(MY_CREATE_VALIDATE_GENERATE_INSTALL_TARGET installDir)
if (WIN32)
	set(GEN_INSTALL_COMMAND msbuild INSTALL.vcxproj)
else()
	set(GEN_INSTALL_COMMAND make install)
endif()
add_custom_target([Trengen_Validate_Generate_Install] 
COMMAND Trengen	-cont ${installDir}
#create a build folder for the generated code
COMMAND ${CMAKE_COMMAND} -E make_directory ${installDir}Gen_Build
#build the project using cmake
COMMAND ${CMAKE_COMMAND} -E chdir ${installDir}Gen_Build cmake ../${installDir}Gen
#now install the application: on windows, call msbuild on linux call make
COMMAND ${CMAKE_COMMAND} -E chdir ${installDir}Gen_Build ${GEN_INSTALL_COMMAND}
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/../
VERBATIM
)	
endmacro(MY_CREATE_VALIDATE_GENERATE_INSTALL_TARGET)



set (TRENTINO_RUNTIME_DIR $ENV{TRENTINO_HOME})
set (DEFAULT_INSTALL_PATH ${CMAKE_CURRENT_SOURCE_DIR}/../)

if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
   set (CMAKE_INSTALL_PREFIX ${DEFAULT_INSTALL_PATH} CACHE STRING "Install path" FORCE)
endif()

##############################################################################
# 								COMPILER OPTIONS  							 #
##############################################################################
if(MSVC)
	add_definitions(-DUNICODE -D_UNICODE)
	add_definitions(/W4)
else()
	add_definitions(-Wall -pedantic)
endif()

##############################################################################
# 							   OUTPUT CONFIGURATION						     #
##############################################################################
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/build/${CMAKE_SYSTEM_PROCESSOR}${CMAKE_SYSTEM_NAME})
set(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/build/${CMAKE_SYSTEM_PROCESSOR}${CMAKE_SYSTEM_NAME})



set(SCAAPI_INCLUDE_DIRS ${TRENTINO_RUNTIME_DIR}/include)
set(BOOST_INCLUDE_DIRS ${TRENTINO_RUNTIME_DIR}/include)
#source and header files
FILE (GLOB ${PNAME}_HEADER_FILES *.h *.inl
	  services/*.h services/*.inl)

FILE (GLOB ${PNAME}_SCA_FILES *.xml  *.componentType META-INF/*.xml META-INF/*.composite)
FILE (GLOB ${PNAME}_BINDING_SCA_FILES *.tidl.properties *.java)

FILE (GLOB ${PNAME}_SCA_COMPONENT_TYPES *.componentType )
FILE (GLOB ${PNAME}_SOURCE_FILES *.cpp services/*.cpp)
SET(${PNAME}_SCA_FILES ${${PNAME}_SCA_FILES} ${${PNAME}_SCA_COMPONENT_TYPES})
FILE(GLOB ${PNAME}_EXPORTED_HEADERS *.h *.inl)  
#libs
set( ${PNAME}_THIRD_PARTY_LIBS 
     )
	 
set( ${PNAME}_CUSTOM_LIBS 
     )
	 
set( ${PNAME}_SOURCE_FILES ${${PNAME}_SOURCE_FILES}
						  ${${PNAME}_HEADER_FILES} ${${PNAME}_SCA_FILES})

if (WIN32)
	add_definitions(-DHELLOWORLDREMOTE_EXPORTS)
endif()

if(MSVC_IDE)
	source_group("SCA Files" FILES ${${PNAME}_SCA_FILES})
endif()

include_directories(${SCAAPI_INCLUDE_DIRS} ${BOOST_INCLUDE_DIRS})

add_library(${PNAME} SHARED ${${PNAME}_SOURCE_FILES})
set(${PNAME}_INSTALL_DIR ${PNAME})
set_target_properties(${PNAME} PROPERTIES OUTPUT_NAME ${PNAME})
install(TARGETS ${PNAME} RUNTIME DESTINATION ${${PNAME}_INSTALL_DIR}
                         LIBRARY DESTINATION ${${PNAME}_INSTALL_DIR}
						 ARCHIVE DESTINATION ${${PNAME}_INSTALL_DIR})
install(DIRECTORY META-INF DESTINATION ${${PNAME}_INSTALL_DIR})
install(FILES ${${PNAME}_EXPORTED_HEADERS} ${${PNAME}_BINDING_SCA_FILES} ${${PNAME}_SCA_COMPONENT_TYPES} DESTINATION ${${PNAME}_INSTALL_DIR})



##############################################################################
#                           CUSTOM TARGET FOR VALIDATING AND GENERATING CODE BY TRENGEN#
##############################################################################
MY_CREATE_VALIDATE_GENERATE_INSTALL_TARGET(${${PNAME}_INSTALL_DIR} )

5.1.2.1.2. Define the HelloWorld remote interface

A remote application using the SCA Binding should be defined using an interface description language. Trentino default binding defines its own IDL called TIDL (Trentino IDL) that is derived from the CORBA IDL specification. More details about TIDL can found in the next chapter. A TIDL interface is defined in one or more .java classes. TIDL uses part of the java syntax to describe the interfaces. The use of the java syntax makes it easy to extend and parse the interface. It also makes it possible to write TIDL files using existing java editors. Create a file named HelloWord.java in HelloWorldRemote_Source. The file should have the following content:

package Trentino.Example.HelloWorldRemote;

//We should ALWAYS Import org.trentino.tidl.* in a TIDL file
import org.trentino.tidl.*;

/**
* HelloWord Service, receive hello world messages 
* and send wellcome to the client.
**/
public interface HelloWorld extends TInterface{

/**
* The server receive an Hello message and send a 
* wellcome message back to the client who sent 
* the message
* @param name: the name of the client who sent the message
* @return TString a welcome message
**/
TString hello(TString name);
}

Then create a configuration file that describes declare the interface. The configuration file is the entry point for code generators like Trengen, that would like to create C++ artifacts based on a given service definition. The configuration file name should be exactly the qualified name of the HelloWorld interface, without dot. A TIDL configuration file end with tidl.properties. In our case it is: TrentinoExampleHelloWorldRemoteHelloWorld.tidl.properties. It only contains the following line of code:

interface=./HelloWorld.java

5.1.2.1.3. Generate the C++ interface

Note

Important: Trengen relies on JDK and not only the JRE (Java Runtime Environment). Make sure that a JDK 1.6.X has been installed.

From the TIDL definition of Helloword, we then generate the corresponding C++ interface. This is done using Trengen. (See Chapter 4 to learn more about Trengen tool). In the command line type:

Trengen -gencppitf Path/to/HelloWorldRemote_Source

The generated artifact is a header file containing the generated interface definition.

5.1.2.1.4. Implement the HelloWordRemote interface.

Create a class named HelloWordImpl in a header file named TrentinoExampleHelloWorldRemoteHelloWordImpl.h and copy the following implementation into it.

#ifndef TrentinoExampleHelloWorldRemoteHelloWorldImplH
#define TrentinoExampleHelloWorldRemoteHelloWorldImplH
#ifdef WIN32
   #ifdef HELLOWORLDREMOTE_EXPORTS
      #define HELLOWORLDREMOTE_IMPORT_EXPORT __declspec(dllexport)
   #else
      #define HELLOWORLDREMOTE_IMPORT_EXPORT __declspec(dllimport)
   #endif //HELLOWORLDREMOTE_EXPORTS
   #else
      #define HELLOWORLDREMOTE_IMPORT_EXPORT
#endif //WIN32
//baseclass
#include "TrentinoExampleHelloWorldRemoteHelloWorld.h"


namespace Trentino{
namespace Example{
namespace HelloWorldRemote{

//forward declaration


 //**************************************************************************************
 //                                         HelloWorld
 //**************************************************************************************
 //! \brief implementation of helloword service
 //**************************************************************************************
class HELLOWORLDREMOTE_IMPORT_EXPORT HelloWorldImpl : public HelloWorld{
  //construction
public:
 HelloWorldImpl();
 virtual ~HelloWorldImpl();
  //services
public:
	virtual std::string hello (const std::string& name);
  
}; //class HelloWorld
} //namespace Trentino
} //namespace Example
} //namespace HelloWorldRemote

#endif //TrentinoExampleHelloWorldRemoteHelloWorldImplH

Create the corresponding C++ class TrentinoExampleHelloWorldRemoteHelloWordImpl.cpp and copy the following code into it.

#include "TrentinoExampleHelloWorldRemoteHelloWorldImpl.h"


using namespace Trentino::Example::HelloWorldRemote;

//class HelloWorldImpl

HelloWorldImpl::HelloWorldImpl()
{
}
HelloWorldImpl::~HelloWorldImpl()
{
}

std::string HelloWorldImpl::hello (const std::string& name)
{
  std::string result("Hello ");
  result+=name;
  return name;
}

5.1.2.1.5. Describe your HellowordRemote SCA contribution

Now our service is implemented (a C++ implementation is available), we need to create SCA component composite and contribution in other to describe our application and make it deployable into a Trentino runtime.

5.1.2.1.5.1. HelloWorld remote component

We start by defining our SCA component type which represents the configurable aspects of our implementation. A component type is described in a *.componentType xml document, that must be located in the same folder with the component implementation (the location of the component header file), in our case the component type name is TrentinoExampleHelloWorldRemoteHelloWordImpl.componentType. It has the following content:

<?xml version="1.0" encoding="utf-8"?>
<componentType xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912">
      <service name="HelloWorld" >
      <interface.cpp remotable="true" class="Trentino::Example::HelloWorldRemote::HelloWorld" header="TrentinoExampleHelloWorldRemoteHelloWorld.h"/>
    </service>
</componentType> 

Our component type defines the Helloword Service and C++ interface. The interface is defined to be remotable ("remotable" is Trentino's contribution to SCA. It is defined by Trentino). Since no binding is specified for the service, our default sca binding is assumed to be the one used for remote communication.

5.1.2.1.5.2. HelloWorld remote composite

Now we can create a composite that has one instance of our previously defined component type For that purpose Trentino requires composites to be located in a folder named META-INF. In our source folder, create META-INF folder and create an xml file named: HelloWorldRemote.composite (composite files always end with .composite), and paste following content into it:

<?xml version="1.0" encoding="utf-8"?>
<composite name="HelloWorldRemoteComposite" xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" targetNamespace="HelloWorldRemoteNamespace">

  <component name="TrentinoExampleHelloWorldRemoteHelloWorldImpl">

    <implementation.cpp
        class="Trentino::Example::HelloWorldRemote::HelloWorldImpl"
		header="TrentinoExampleHelloWorldRemoteHelloWorldImpl.h"
        scope="composite"
		library="HelloWorldRemote" 
		eagerInit="true"/>
		<service name="HelloWorld" >
      <interface.cpp remotable="true" class="Trentino::Example::HelloWorldRemote::HelloWorld" header="TrentinoExampleHelloWorldRemoteHelloWorld.h"/>
    </service>
  </component>
</composite>

Our composite has a component that is an instance of TrentinoExampleHelloWorldRemoteHelloWorldImpl.componentType. The component is configured with our implementation. The location of the library containing the implementation is also defined.

5.1.2.1.5.3. HelloWorld contribution

The last step in your application description is to create a contribution that is an xml document that describes all the artifacts (the so-called deployable elements) to be deployed into and managed together by the runtime. For our simple case, the only available deployable element is the previously created composite and its dependencies (all componentTypes and compiled libraries). The name of the contribution file should be sca-contribution.xml and it should be created in our META-INF folder. Paste the following code into it:

<?xml version="1.0" encoding="utf-8"?>
<contribution xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" xmlns:sample="HelloWorldRemoteNamespace">
<deployable composite="sample:HelloWorldRemoteComposite"/>
</contribution>

5.1.2.1.6. Compile the server application

We would like to do all these steps without an IDE but rather with a console.

• If you are using windows, then please open your visual studio console.

• Create a folder named HelloWorldRemote_Build next to HelloWorldRemote_Source

• Change to the created directory : cd HelloWorldRemote_Build

• Call Cmake: cmake ../ HelloWorldRemote_Source

• Now your visual studio solution has been created (On linux your make files)

• On windows call ‘msbuild INSTALL.vcxproj’ on linux just ‘make install’

• This will create a folder named HelloWorldRemote next to HelloWorldRemote_Source. The HelloWorldRemote folder contains your compiled and ready for validation contribution

5.1.2.1.7. Code validation and generation

Before been deployed into the runtime, a prepared contribution as we did in the last steps will go through a complex validation and code generation process. The validation process make sure that only a consistent and specification conform contribution can be deployed into the runtime. To validate and generate code, type for windows:

msbuild [Trengen_Validate_Generate_Install].vcxproj

For linux, type:

make [Trengen_Validate_Generate_Install]

This last step update your contribution by creating a new library called sca-contribution (.dll or .so). The created library is located in the META-INF folder of your contribution. To further understand what is done during the last step, you can take a look on the custom target [Trengen_Validate_Generate_Install] defined in our cmake file

#include <iostream>
#include "TrentinoExampleHelloWorldRemoteHelloWorldClientImpl.h"


using namespace Trentino::Example::HelloWorldRemote;

//class HelloWorldClientImpl

HelloWorldClientImpl::HelloWorldClientImpl()
{
}
HelloWorldClientImpl::~HelloWorldClientImpl()
{
}

void HelloWorldClientImpl::setHelloWorld(HelloWorld* helloWorld){
mHelloWorld = helloWorld;
callHello();
}

//This method is called by the Runtime as soon as this component is initialized
void HelloWorldClientImpl::callHello ()
{

  try
  {
      std::string name("Trentino");
      std::string response = mHelloWorld->hello(name);
      std::cout << "Remote HelloWorld Service called. Response is:" << response << std::endl;
  }
  catch (std::exception& e)
  {
  	 std::cout << "Exception during call of hello world:" << e.what() << std::endl;
    return;
  }

}

Remote HelloWorld Service called. Response is: Hello Trentino

For the server side, the files generated by Trengen can be seen in the following figure:

server-side generated files

For the client side, the files generated by Trengen can be seen in the following figure:

client-side generated files

The following diagram represents the sequence of binding in Trentino. It covers the "boot", "install server" and "install client" commands.

Sequence diagram for binding SCA

After "boot" command, BootsTrapper is called. It creates instances of Binding Manager, Contribution Loader, ComponentCPPImpl Manager, ComponentProperty Manager and Invocation Layer.

After "install _name_of_the_server_contribution_" command, onDeploy() function of BindingManager is called. This is the start of Binding in Trentino.

After "install _name_of_the_client_contribution_" command, onInit() or getInstance() function of ComponentCPPImplManager is called (This is decided by the configuration in SCDL).

After a request is received in server side, handle() function of BindingSCADataHandler by ZMQServer.

Inter-process communication (IPC) is a set of methods for the exchange of data among multiple threads in one or more processes. IPC methods are divided into methods for

RPC is not in the scope of this binding type. Because other binding types (binding SCA, bacnet binding etc…) are kinds of RPC. Message queues and shared memory are our focus for IPC binding in Trentino.

Each thread has its own private memory which is not accessible to other threads. Each thread may want to access a shared memory for fast communication.

There can be more than one Trentino runtime running on the same computer. The reason why the end-user has 2 or more Trentinos running in the same computer is that customer may want to isolate services from each other.

Complex types are defined by creating a class that extends "TStruct" or that extends another complex type. A complex type defines all the fields it contains. The fields MUST be TIDL simples types or TIDL complex types. Inheritance is supported for complex types. A complex type can reference a object from the same type.

	 class Person extends TStruct{
		Address addres;
		TString name;
		TString surname;
		Person mother;
     }

TIDL support exception specification. An exception is a TIDL complex type with the particularity that it extends "TException" instead of "TStruct"

	class ValidationException extends TException{
     TString details;
    }
	 

A TIDL interface MUST allways import org.trentino.tidl.*; This import statement will import all the basic TIDL types and annotations in the TDIL description file.

Interfaces methods are normal java methods. All the types used by a TIDL methods as arguments or return types MUST be TIDL types. Normal java types like "String", "int" are not used and will cause the compilation and code generation to fails. Exceptions can be specified on methods. In that case, exception MUST be a TIDL exception.

Methods arguments can be annotated to describe their behaviour.

void multiply(ComplexNumber a, ComplexNumber b,@Out ComplexNumber c);

This is the corresponding C++ code generated for the BasicCalculator interface specified in the last section

// Generated by Trentino TDIL CPP interface generator. do not modify

#ifndef TrentinoExampleBasicCalculatorRemoteBasicCalculatorH
#define TrentinoExampleBasicCalculatorRemoteBasicCalculatorH

#include "BasicCalculatorGlobal.h"
#ifndef NULL
#define NULL 0
#endif


#include <boost/cstdint.hpp>
#include <string>

typedef  boost::int32_t  tint32_t;
typedef  boost::uint32_t  tuint32_t;
typedef  boost::int64_t  tint64_t;
typedef  boost::uint64_t  tuint64_t;

namespace Trentino{
namespace Example{
namespace BasicCalculatorRemote{

//forward declaration
class ComplexNumber;
class Phone;
class Address;
class Person;
class TupleComplexNumber;
class ValidationException;


//**************************************************************************************
//                                         ComplexNumber
//**************************************************************************************
//! \brief 
//**************************************************************************************
class TRENTINO_EXAMPLE_BASICCALCULATORREMOTE_IMPORT_EXPORT ComplexNumber{
private:
	tint32_t a_;
	tint32_t b_;

public:
// constructor and destructor---------------------------------------
	ComplexNumber();
	virtual ~ComplexNumber();
// default instance
   static const ComplexNumber& default_instance();
// accessors -------------------------------------------------------
	void set_a(tint32_t value);
	tint32_t a() const; 
	void set_b(tint32_t value);
	tint32_t b() const; 
 
 //default instance data
 private:
   static ComplexNumber* default_instance_;
}; //class ComplexNumber

//**************************************************************************************
//                                         Phone
//**************************************************************************************
//! \brief 
//**************************************************************************************
class TRENTINO_EXAMPLE_BASICCALCULATORREMOTE_IMPORT_EXPORT Phone{
private:
	std::string* home_;
	std::string* mobile_;

public:
// constructor and destructor---------------------------------------
	Phone();
	virtual ~Phone();
// default instance
   static const Phone& default_instance();
// accessors -------------------------------------------------------
 	const std::string& home() const;
 	void set_home(const std::string& value);
	void set_home(const char* value);
	void set_home(const char* value, size_t size);
 	const std::string& mobile() const;
 	void set_mobile(const std::string& value);
	void set_mobile(const char* value);
	void set_mobile(const char* value, size_t size);
 
 //default instance data
 private:
   static Phone* default_instance_;
}; //class Phone

//**************************************************************************************
//                                         Address
//**************************************************************************************
//! \brief 
//**************************************************************************************
class TRENTINO_EXAMPLE_BASICCALCULATORREMOTE_IMPORT_EXPORT Address{
private:
	std::string* street_;
	Phone* phone_;

public:
// constructor and destructor---------------------------------------
	Address();
	virtual ~Address();
// default instance
   static const Address& default_instance();
// accessors -------------------------------------------------------
 	const std::string& street() const;
 	void set_street(const std::string& value);
	void set_street(const char* value);
	void set_street(const char* value, size_t size);
	Phone* mutable_phone();
	Phone& phone() const;
	bool has_phone() const;
 
 //default instance data
 private:
   static Address* default_instance_;
}; //class Address

//**************************************************************************************
//                                         Person
//**************************************************************************************
//! \brief 
//**************************************************************************************
class TRENTINO_EXAMPLE_BASICCALCULATORREMOTE_IMPORT_EXPORT Person{
private:
	Address* addres_;
	std::string* name_;
	std::string* surname_;
	Person* mother_;

public:
// constructor and destructor---------------------------------------
	Person();
	virtual ~Person();
// default instance
   static const Person& default_instance();
// accessors -------------------------------------------------------
	Address* mutable_addres();
	Address& addres() const;
	bool has_addres() const;
 	const std::string& name() const;
 	void set_name(const std::string& value);
	void set_name(const char* value);
	void set_name(const char* value, size_t size);
 	const std::string& surname() const;
 	void set_surname(const std::string& value);
	void set_surname(const char* value);
	void set_surname(const char* value, size_t size);
	Person* mutable_mother();
	Person& mother() const;
	bool has_mother() const;
 
 //default instance data
 private:
   static Person* default_instance_;
}; //class Person

//**************************************************************************************
//                                         TupleComplexNumber
//**************************************************************************************
//! \brief 
//**************************************************************************************
class TRENTINO_EXAMPLE_BASICCALCULATORREMOTE_IMPORT_EXPORT TupleComplexNumber{
private:
	ComplexNumber* a_;
	ComplexNumber* b_;

public:
// constructor and destructor---------------------------------------
	TupleComplexNumber();
	virtual ~TupleComplexNumber();
// default instance
   static const TupleComplexNumber& default_instance();
// accessors -------------------------------------------------------
	ComplexNumber* mutable_a();
	ComplexNumber& a() const;
	bool has_a() const;
	ComplexNumber* mutable_b();
	ComplexNumber& b() const;
	bool has_b() const;
 
 //default instance data
 private:
   static TupleComplexNumber* default_instance_;
}; //class TupleComplexNumber

//**************************************************************************************
//                                         ValidationException
//**************************************************************************************
//! \brief 
//**************************************************************************************
class TRENTINO_EXAMPLE_BASICCALCULATORREMOTE_IMPORT_EXPORT ValidationException{
private:
	std::string* details_;

public:
// constructor and destructor---------------------------------------
	ValidationException();
	virtual ~ValidationException();
// default instance
   static const ValidationException& default_instance();
// accessors -------------------------------------------------------
 	const std::string& details() const;
 	void set_details(const std::string& value);
	void set_details(const char* value);
	void set_details(const char* value, size_t size);
 
 //default instance data
 private:
   static ValidationException* default_instance_;
}; //class ValidationException

//**************************************************************************************
//                                         BasicCalculator
//**************************************************************************************
//! \brief 
//**************************************************************************************
class BasicCalculator{
  //services
public:
	virtual ComplexNumber add (const ComplexNumber& a,const ComplexNumber& b) =0;
	virtual tint32_t addSimple (const tint32_t a,const tint32_t b) =0;
	virtual ComplexNumber divide (const ComplexNumber& a,const ComplexNumber& b) =0;
	virtual void multiply (const ComplexNumber& a,const ComplexNumber& b, ComplexNumber& c) =0;
	virtual ComplexNumber divide2 (const TupleComplexNumber& tuple) =0;
	virtual tuint32_t calculateAge (const Person& person) throw (ValidationException)=0;
  
}; //class BasicCalculator
} //namespace Trentino
} //namespace Example
} //namespace BasicCalculatorRemote

#endif //TrentinoExampleBasicCalculatorRemoteBasicCalculatorH

Default values for structures can be defined in a TIDL using the @Default annotation.

public interface ICommandService extends TInterface{

    TBool isRunning();
	StorageRackData getStateData();
	
   void setCommand(Command command);
   void setCommandWithIdentifier(TString identifier, Command command);
   
   class StorageRackCommand extends TStruct {
        TFloat activePower;
        TFloat reactivePower;  
   }
   
   class Data extends TStruct{
   
        @Default(bv=true)
		TBool isValid;
		
		@Default(sv="Default")
		TString Name;
		   
		@Default(nv=-1)
		TFloat StateOfCharge;
		
		@Default(nv=-1)
		TFloat MaxChargingPower;
   }
}

The @Default annotation has tree attributes.

Service discovery is enabled or partially configured in the Runtime.conf file. Trentino uses OpenSLP for service discovery please also refer at the OpenSLP configuration mentioned under the respective section below. The user can enable or disable service discovery for a Trentino runtime. In the Trentino configuration file Runtime.conf, the following options should be available.

In case of a discovery failure, the service state should be NOT_AVAILABLE. The runtime MUST be configured to try discovery a number of time if discovery fails. The time interval and the number of retries are configurable in Runtime.conf.

Trentino uses OpenSLP for service discovery.
http://www.openslp.org/

Service Location Protocol (SLP) is an Internet Engineering Task Force (IETF) standards track protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks.

The OpenSLP project is an effort to develop an open-source implementation of the IETF Service Location Protocol suitable for commercial and non-commercial application.

Errors that are detected at network by OpenSLP are logged or notified with error codes of OpenSLP. For the meanings of error codes please see Appendix-B.