Re: [Minutes] Auto WG 2020-09-29 on WAMP

> Thanks for your time, definitely want to explore this further with

great, was interesting and fun!

btw, I had a deeper look at VSS and https://github.com/GENIVI/vss-tools 
in particular

I think I could come up with a "vspec2wamp.py" in a PR to have something 
concrete. a proposal to discuss (or throw away in the end). but I like 
working code;)

this is how I would approach ^: the script would

1. just read the VSS definition from the spec files,

2. internally fill in data structures that hold wamp api flatbuffers 
definitions roughly along

https://github.com/crossbario/xbr-app/tree/master/schema
https://github.com/google/flatbuffers/blob/master/reflection/reflection.fbs

3. output everything again in

- flatbuffers source format (.fbs) files,
- one binary flatbuffers file using flatbuffers reflection schema, or
- as sphinx rst sources for api docs

now, I would guess this is ~500 lines and 1 day work, but surely that 
would only make sense if you guys would welcome such a proposal and code 
based approach.

speaking of working code. actually, I would go even further. above fbs 
files generated should then be used to generate code bindings for actual 
wamp components. say in python to just take one nice language;)

maybe a day more work .. because once we had the whole bunch of VSS APIs 
in flatbuffers reflection schema, we can easily walk over that and dump 
out code for some language ..

but as said: I'd rather spare my time if there isn't _some_ 
interest/support for that anyways;)

> group during our 12-15 October meetings I mentioned earlier and perhaps

ok, I'll join in (once definite date is known)

> just one on one so I can learn more and maybe narrow focus.
> Authentication and access control for instance is something recently
> hammered out with Ulf and Isaac putting in considerable work.

sure, fwiw, just super quickly: Crossbar.io works at 3 levels in WAMP:

1) wamp client authentication

authenticating the connecting client results in a WAMP session (realm, 
authrole, authid, sessionid)

there are multiple authentication methods, and this is pluggable

2) wamp session authorization

(realm, authrole) then determines permissions on the URI namespace of 
the realm

a permission can match exact or by prefix, and toggles permission to 
perform WAMP actions (call/register/publish/subscribe)

authorization rules can be static, or dynamic (computed at run-time by a 
user provided wamp component)

3) app payload end-to-end encryption

that is, per-action application payload end-to-end encryption using data 
encryption keys

this completely decouples wamp routing realms / namespaces from the 
application data plane, including trust domains (eg you can secure your 
app data even against crossbar admins or network root)

the resulting operational and trust decoupling also comes in handy when 
different large entities want to integrate systems or data in a flexible way

the management of keys: in xbr, data encryption keys are traded in data 
markets. in other scenarios, keys might be managed differently

> 
> 
> I corrected WebSocket to be consistent, fixed company name and sorry
> about that.
> 
> Inlined many of those links in the minutes but some topics you just
> sent were not covered or I didn't capture enough in minutes on eg
> microservices to place those so trimming this mail and including these
> useful resources in sending minutes to the group.
> 
> When we met last Friday and on call yesterday we got into push vs pull
> and how dealer addresses that. Some see Gen2 as being used to pull data
> off the vehicle and others including myself thinking it should be
> pushed. I see Gen2 being used for in-vehicle applications and Gen2 can
> also run in the cloud for accessing already off-boarded data from the
> vehicle. The push v pull thing gives me pause for its usefulness in
> vehicle to cloud. In-vehicle applications performing data sampling to
> offboard could benefit if the Gen2 service could serialize and
> compress, especially if the format allows for inspection and further
> trimming of extraneous data. This would be prepacking and enable local
> storage/caching and off-boarding in batches based on connectivity.
> There is clear interest in WAMP for cloud<->vehicle RPC. I am wondering
> if WAMP could be a broker to Gen2 residing in the vehicle. Another

yes, absolutely.

you could have a so-called "edge node" inside every car which locally 
routes WAMP between in-car microservices, as well as into and from the cloud

the edge node connects to the cloud, a fully meshed cluster of cloud 
nodes. this is using a special link (not a normal wamp session), a 
so-called "router-to-router" link, which is able to forward and route 
WAMP messages between nodes.

the routers form transparent routing realms. that is, any microservices 
connected to any of the nodes (edge, cloud, wherever) can talk to any 
other on the same wamp realm (well, if authorized). without noticing 
where the other end actually resides. transparent.

fwiw, Crossbar.io implements router-to-router links (beta):

https://github.com/crossbario/crossbar/blob/master/crossbar/worker/rlink.py

> thought on how this can be architected in addition to your mapping
> analysis. We may need a virtual whiteboard for the different
> possibilities.

yeah, that would be great! also, it just wasn't enough time to really 
discuss many things ..

/Tobias

Received on Wednesday, 30 September 2020 22:20:42 UTC