Services configuration

A service XML configuration contains:

• The name and identification of the service these two elements must be unique for all services in the framework^[1]
  The ID is optional
• The datas provided by the service^[2]
  These depend on the service type

Grammar

See the grammar for the services schema.

Types of services

The XML element which declares the service depend on the Service type:

• For a publish Service: a publish element. For example: <publish name="position" id="1" >
• For an event Service: an event element. For example: <event name="directTo" id="1" >.
• For a request-response Service: a requestResponse element. For example: <requestResponse name="computeFlightPlan" id="1" >

Note that it also possible to define a service alias in the Services configuration.

Name and identification

The name and identification of the service must be unique for all services in the framework. For example:

      <publish name="position" id="1" >

See also the identification article for the constraints on naming and identification. Note that the identification can be omitted. For example, the following definition is valid:

      <publish name="position" >

Using namespaces

To avoid names clashes, it is possible to define namespaces for services. To define a namespace, you just have to declare the namespace element as a parent of the services declaration^[3]

Of course, you can define more than one namespace in a services XML file

. For example:

      <services>
        <namespace uri="http://mydomain.com/aircraft" >
          <publish name="position" id="1" >
      ...
          </publish>
          <publish name="speed" >
      ...
           </publish>
        </namespace>
      </services>

Note that services of a specified namespace can access types of the same namespace, or types with no namespace declaration.

Specifying how the service should be invoked

It is possible to set the mode of invocation at the service level by specifying the value of the invocationMode attribute in the service definition:

• By default the framework behavior will be used
• If the attribute has the executorService value, the framework will perform the invocation in a background Thread
• If the property has the blocking value, the framework will perform the invocation in the same Thread as the caller

For example:

      <publish name="position" invocationMode="blocking" >
         <data name="latitude" type="float" />
         <data name="longitude" type="float" />
         <data name="altitude" type="float" />
      </publish>

Specifying how to detect if a data has changed

The dataChangeBehavior attribute allows to specify how to detect that complex datas have changed sqince the last notification.

For example:

      <publish name="attitudes" dataChangeBehavior="unchanged" >
         <data name="position" type="position" />
         <data name="speed" type="speed" />         
      </publish>

There are three possible values for this attribute:

• inherit : the service will inherit the value specified in the framework properties
• changed : the full graph of complex datas will be taken into account to detect if datas have changed after a service invocation
• unchanged : complex datas will generally be considered as changed be taken into account to detect if datas have changed after a service invocation.

Extending a service

It is possible to extend a service definition, by adding new datas to the existing definition of Service. It can be useful if you want to define several Services which small variations on their number of datas.

For example:

      <publish name="2DPosition" >
         <data name="latitude" type="float" />
         <data name="longitude" type="float" />
      </publish>
      <publish name="3DPosition" >
         <extends name="2DPosition" />
         <data name="altitude" type="float" />
      </publish>

Here the definition is equivalent to:

      <publish name="2DPosition" >
         <data name="latitude" type="float" />
         <data name="longitude" type="float" />
      </publish>
      <publish name="3DPosition" >
         <data name="latitude" type="float" />
         <data name="longitude" type="float" />
         <data name="altitude" type="float" />
      </publish>

Abstract services

It is possible to specify that a service is abstract and should not be used in the applications configuration. This can be useful for example if you extend a service and you don't want to use the service upon which you extend.

For example:

      <publish name="2DPosition" isAbstract="true" >
         <data name="latitude" type="float" />
         <data name="longitude" type="float" />
         <data name="altitude" type="float" />
      </publish>
      <publish name="3DPosition" >
         <extends name="2DPosition" />
         <data name="altitude" type="float" />
      </publish>

Datas declaration

The declaration of the datas associated with the service depend on the service type.

Datas for publish and event services

The datas for publish and event services are directly declared under the service itself. For example:

      <publish name="position" >
         <data name="latitude" type="float" />
         <data name="longitude" type="float" />
         <data name="altitude" type="float" />
      </publish>

Datas for request-response services

There are two lists of datas for request-response services:

• The datas associated with the request
• The datas associated with the response

For example:

         <requestResponse name="computeFlightPlan" id="1" >
            <request>
               <data name="waypointList" type="arrayOfInt" />
            </request>
            <response>
               <data name="flightPlan" type="arrayOfPosition" />
            </response>
         </requestResponse>

Anonymous types

Types used in datas can be defined directly under the datas which use them^[4]

These types are defined locally to the data which use them and can not be referred in other datas or types

. See anonymous types for more information.