Service solution alternative

I would like to present alternative, or maybe more complementary design
ideas of a service oriented framework to the very respectable proposal
coming from Magnus F, together with Gunnar.
It was touched upon at the RPC meeting today, and there decided I should
present it at the W3C meeting tomorrow, so below you find it.
My current view is that it may be more oriented towards the vehicle to
cloud communication, while Magnus design may be more oriented towards
in-vehicle use. Therefore they could be complementary, and maybe after
being to some level aligned be two alternatives to choose between.
If there would be any interest in my ideas, there are of course a lot of
details and improvements yet to work out.
Let us see what the WG view on it is tomorrow.

BR
Ulf

A new "VSS tree" is defined, having the root node name "VehicleService",
and a new node type is introduced, "service", which may have child nodes of
the type "sensor", or be a leaf node.
The tree must only consist of the node types "branch", "service", and
"sensor".
Its structure does not have any dependency to the VSS signal tree. An
example follows below.

VehicleService.Access.Door.Lock
VehicleService.Access.Door.Unlock
VehicleService.Access.Window.Close
VehicleService.Access.Window.Open
VehicleService.Access.Trunk.Unlock
VehicleService.Access.Trunk.Lock
VehicleService.Climate.Seat.SetTemperature
VehicleService.Climate.Seat.SetFanSpeed
VehicleService.Climate.Cabin.SetHeater
VehicleService.Climate.Cabin.SetHeater.TimeSet


The VISS protocols for signals are reused to a large extent, as described
in the following.

If the service request is issued over HTTP then the immediate response is
only for the receipt of the request by the server, if the client wants to
follow up the execution of the request, then that must be done by follow-up
read status requests of the service, see below.

If the service request is issued over Websocket (or MQTT) then a service
parameter "reporting" can be set to specify how the execution is reported
back to the client as notifications with the service status, see  below.
The integer "reporting" value is for positive values expressing in 10th of
a second the period between notifications. If it is set to zero,
notification is only issued when done (or failure), if it is set to minus
one (-1) notification is only done if service fails. If "reporting" is not
included, then it is set to zero by default.

Example YAML node definition:

- Lock:
  type: service
  arguments:
    - position:
      datatype:string
      description: The position of the door, e. g. "Row1.Left". May contain
wildcards.
  description: Lock one or more doors.

Websocket payload example:
{"action":"set", "service":"VehicleService.Access.Door.Lock",
"arguments":{"position":"Row1.Left", "reporting":"20"}, "requestId":"234"}

Set vs Get?
- The action "set", or method POST over HTTP, is used to initiate a service
request.

- The action "get", or method GET over HTTP, is used to inquire about the
current status of a service request.
The status response content depends on whether the service node has any
children or not.
If no children, then the response is one value, the service completion in
percent.
If it has children, then the response also contains their current values.
An example is the service "SetHeater" above, which has a child "TimeSet"
which contains the set starting time for the heater, if set.

A service that is not in processing of a request MUST respond with 100
percent completion, or error if not operable.

The action "get", or method GET over HTTP, together with the query for
static-metadata, leads to a "service discovery" response, containing the
tree metadata for the addressed nodes.

Requirements on the vehicle deployed service implementation:
- It shall at all times have immediately accessible status data in the form
of a current completion percentage, and a status code (Ready/Temporarily
off-line/Out-of-order)<- Could be coded into the percentage value, using
100 for Ready, and negative values for the two latter?
- If the service has children containing further status data, then these
shall be timely updated.
- If it does not have an associated "stop service" it must regularly during
service execution check if a service cancel request is received.
- The status data shall have an associated timestamp for when it was last
changed.

Service execution:
The service is carried out by the execution of the named method, with the
provided parameter values. The server shall at startup be provisioned with
function pointers to the methods/services it supports. These function
pointers are stored in the tree, associated to the metadata name
"service-handle".

Issues:
- Shall a client be possible to cancel an ongoing service execution? => It
must then have acquired authority to do so through possession of a valid
token.
- If cancel is supported, how is such a request expressed? => action
"delete", or HTTP method DELETE with path to service? Or set/POST with
path+query?
- Shall services that has no defined end be supported? => E. g.
StartWindshieldWiper? That it has no defined end point shall be found in
the service description metadata.
- If so, how is a never ending service updating the percentage status? =>
Percentage is set to 0, and stay that until service is cancelled, or
stopped via a "stop-the service" service, where it returns to 100.
- If cancel is the only way to stop a never ending service, which require a
token, should start of it also require this token? => Not sure.
- How is state of a never ending service checked? => Via the percentage of
its "start service", which is kept zero when it is executing. Its "stop
service" is only less than 100 during its execution of stopping the
service. The service might also have extra status data defined via child
nodes.

A single server implementation that processes both signal based and server
based requests should be straight forward.
In the existing VISSv2 server implementation project it would be a matter
of the server handling two trees, and having two "southbound" managers
registering for signals and services respectively.

-- 
Ulf Bjorkengren
*Geotab*
Senior Connectivity Strategist | Ph. D.
Mobile +45 53562142
Visit www.geotab.com