Request-response Service

A request-response Service is a service which handle:

• The sending of a valued request from a subscriber to a the Service provider
• The sending of the associated response from the Service provider to the subscriber which sent the request

A request-response Service:

• Can have ony one providers
• Can have one or several subscribers

Overview

• During configuration, ony one provider can be active, and one or several subscribers can be associated with the Service
• During runtime:
• A subscriber sends a request to the Service
• The provider is notified on the request by this particular subscriber
• The provider invokes the response for this request
• The subscriber which sent the request is notified of the response

Note that is is possible to configure the framework to allow each publish service and request-response service to allow more than one Service provider at the same time. See framework properties.

Request-response specificities

Note that:

• Even if there are several subscribers to the Service, only the subscriber which sent the Service will be notified
• The framework maintains a queue of requests associated with their subscribers, which means that even if several requests are sent at the same time, each request will be handled separately by the provider

Data management

The datas associated with the request are handled as for event Services: the datas sent alongside the request will always have their default value before the invocation of the Service.

Declaring the Service

To declare a request-response Service, you must:

• define the Service name and ID (as for all Services)
• define the datas associated with the request
• define the datas associated with the response

For example:

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

See also services configuration.

Interfacing with the Service

Declaring how the Service is used for a module^[1]

If the module is a provider or a subscriber of the Service

is specified in the module configuration for the Module. The declaration is to be performed under the interfaces element for the module configuration:

• If the module is providing the service (receives the requests and send the response), declare a requestSend element
• If the module is subscribing to the service (send the request and receive the response), declare a requestReceived element

Note that for the module which send the request, there is by default a 200 ms timeOut for receiving the response. You can change the timeOut by setting the timeOut property.

For example:

      <module name="theSender" >
         <interfaces>
            <requestSend service="myRequest"/>
         </interfaces> 
      </module> 
      <module name="theReceiver" >
         <interfaces>
            <requestReceived service="myRequest" timeOut="500ms"/>
         </interfaces> 
      </module>

TimeOut configuration

The timeOut attribute specified how long (in ms) the subscriber must wait before the response is declared as timed out. The default value is 300ms. For example:

       <requestSend service="position" timeOut="500ms" />

A value of "none" for the timeOut attribute specifies that there is no timeOut specified for the request, which means that the response will never *be decklared as time out regardless of the time used by the perovider to return the response.

Getting the processing time for the service

It is possible to get the time used to process a request-response Service by the service provider by using the RequestServiceInstance.getProcessingDuration() or RequestServiceInstance.getProcessingDuration(long) method.

Use cases

The publish Service use case is typically cases where you want to send datas to as many subscribers as necessary. A publish Service can be invoked as often as necessery (even cyclically).

For example, you can define a publish Service to publish an aircraft position (see the example below).

FlightPlan computation example

Consider the computation of a FlightPlan where:

• The subscriber sends a request with the list of Waypoint numbers
• The provider replies with the list of positions for the FlightPlan points

We would have the computeFlightPlan service definition:

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

And the FlightManagementSystem and Display modules definitions:

      <applications>
         <application name="aircraft" id="1">
            <modules>
               <module name="Display" id="1" > 
                  <interfaces>
                     <requestSend service="computeFlightPlan"/>
                  </interfaces>             
               </module>
               <module name="FlightManagementSystem" id="2" >          
                  <interfaces>
                     <requestReceived service="computeFlightPlan"/>
                  </interfaces>            
               </module>                                             
            </modules>
         </application>          
      </applications>

The Display module sends a request for the computeFlightPlan Service, with a list of Waypoints numbers. The FlightManagementSystem modules replies with the associated list of positions for the FlightPlan points. The Display module is notified of the response, allowing it to show the new FlightPlan on the Display.