Introduction of signal access- and resource access profile, with common data model (extended VSS).

Please find below our analysis of how the transport models of VISS and VIWI can be unified.

BR
Ulf

Ulf Björkengren Ph. D.
Connectivity Strategist

M +4553562142
ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>

VOLVO CAR CORPORATION
94014 Lund R&D Tech Center
Frederikskaj 10A
Copenhagen, Denmark
volvocars.com


Introduction of signal access- and resource access profile, with common data model (extended VSS).

We have done some work on the http transport issue over the last weeks, which we would like to present here.
Our view was that ideally a client should be able to use either of the two transport protocols websockets (ws) or http, and that on the data level this choice would not be visible (i. e. the data communicated over the transport would be identical).
We then tried to go the same path as for the data model, i. e. to start off with the existing solutions in VISS and VIWI respectively, and then try to find a hybrid solution accommodating both as well as possible.
>From each specification we then got the information shown below, where examples of the ws:send commands for the different VISS requests are shown, and below that a VIWI table showing the different http methods semantic related to the URI levels service/resource/element.
With this information we drew the following conclusions:

1.      When trying to map VISS requests to fields in the VIWI matrix, the areas marked 1 to 3 were identified (our marking).

o   Area 1 maps to the VISS requests get and set.

o   Area 2 maps to the getMetadata request.

o   Area 3 does not have any related requests in VISS.

2.      Subscription operations are only transported over ws.

o   Shall one of existing solutions be selected, or should a new (hybrid) be defined?

3.      Both use JWT tokens for access control. VIWI seems to have a more detailed definition of the JWT content.

o   Should that be selected?

We then started with 1. and tried to see how that could be resolved when trying to meet our ideal view mentioned above.
It immediately becomes obvious that the JSON string payload that is transported in VISS over ws is not suitable for being transported over http, as several of the key:value fields in this payload are explicit parameters in http, the "action" is for example the http method, and the path is the http uri.
So the idea of a transport agnostic payload fails directly.
The methods in VIWI area 3, would have to be defined for the ws transport, adding significantly to the set of request there.
For the 3 matrix elements in the  VIWI area 2, which map to VISS getMetadata, we could not clarify if a complete mapping is possible, or if extensions are needed for one to cover the other.

The sum of the issues mentioned above seems to indicate that a hybrid solution covering the sum of the functionality of the communication over the VISS ws and VIWI http respectively, will yield a quite complex solution.
As we believe complexity is a negative aspect, yielding implementations more bug prone, and harder to get interoperable, we then tried to find if a less complex solution could be found by introducing some restrictions to the ideal view we mentioned before.
The restrictions we then came up with were the following:

-        To only support the VIWI area 3 functionality over http.

o   These operations are not very frequent, so therefore ws support is not so important.

-        To only support the VIWI area 2 functionality over one of ws or http.

o   Which one may depend on which of the two alternatives fully cover the other.
The VIWI area 2, corresponding to VISS get/set was seen as important to support over both ws and http, and hence should not be restricted.
Coming this far in our analysis, another alternative came up in the discussion.
This was to introduce two specification profiles, that could be called the signal access profile, and the resource access profile, which share the common data model (the extended VSS), but which may have deviations on the supported functionality over the transport protocols.
Clients and servers could then be implemented to support one, or the other of these profiles, which should simplify the implementation. The signal access profile should be a subset of the resource access profile.
Functionality for the profiles may be supported over the two transport alternatives as shown in the table below.

Functionality

Resource access

Signal access

Add/delete

http

N/A

Subscription

ws

ws

Get/set

http+ws

http+ws

Metadata

ws

ws

Token

http+ws

http+ws


The main difference between the profiles would be that the signal access profile will not support adding/deleting nodes in the tree. The query functionality may also be somewhat reduced for this profile.
In summary there are three alternatives here:

1.      Support all functionality on both ws and http (except for subscription which only will be on ws)

2.      Support all functionality, but with restrictions on transport alternatives - some only on ws and some only on http (and some on both).

3.      Introduce specification profiles to enable implementations of a subset of all functionality.
Our current view is that we would like to recommend alternative three.

BR
Joakim, Peter, Magnus, Ulf



*******  Excerpts from VISS and VIWI respectively. ***************



VISS WebSocket example messages:



vehicle.send('{"action": "get", "path": "x.y.z", "requestId": "100"}');



vehicle.send('{"action": "set", "path": "x.y.z", "value": "abc", "requestId": "105"}');



vehicle.send('{ "action": "authorize", "tokens": { "authorization": "<user_token_value>" }, "requestId": "115" }');



vehicle.send('{"action": "getMetadata", "path": "x.y.z", "requestId": "120"}');



vehicle.send('{"action": "subscribe", "path": "x.y.z",  "requestId": "110"}');



vehicle.send('{"action": "unsubscribe", "path": "x.y.z", "requestId": "110"}');



vehicle.send('{"action": "unsubscribeAll", "requestId": "110"}');





[cid:image003.jpg@01D43B92.6234D2C0]