Bidirectional communication between ArrowheadCore Services and Consumers without a REST service on the consumer.

[punyal]

Maybe I'm wrong and some of these assumptions are already fixed on the latest version. But as I see it, the current solution requires the consumers to run a REST service to get all the AH features from the AH Core Services. This fact creates some issues:

• Consumers must have the capability to run a REST server
• Consumers must open a port to expose that service
  • Consumers behind firewalls (hardware or software) must be modified
  • Consumers in subnetworks require some kind of tunneling

If a consumer can not run a REST interface the only solution is the use of pulling mechanisms, with the consequent drawbacks.

The proposal that I would like to make is the use of bidirectional communications, for example:

• REST with keep-alive
• Websockets
• CoAP with Observe
• MQTT with subscriptions So with this, the System Registry can keep a connection to the consumer after it is registered with a real-time bidirectional connection.

Benefits:

• No services are exposed
• No ports are opened on any Firewall
• No issues between subnets
• No issues between inter-clouds
• It will improve the QoS

Is there any interest in this?

[emanuelpalm]

@punyal There sure is interest in this. There SHOULD be no requirement on a consumer running any REST-services, even though the Event Handler currently require it for event distribution. I hope this will be fixed for Arrowhead version 5.0, but I do not know for sure. @tsvetlin?

I know that @jenseliasson have had quite some success in using WebSockets for some of his Arrowhead implementations, for example. There should also be plenty of interest in using MQTT, AMQP and other message busses or publish/subscribe protocols. I personally believe that JSON-RPC 2.0 (which is JSON messages sent over TCP or WebSockets) should be the gold standard for reference implementations instead of REST, as it is far less complicated.

[punyal]

The biggest challenge to deal with that is how to solve the Security and Access Control. Maybe, if there is interest, we should start discussing possible solutions.

[emanuelpalm]

As long as the communication link uses TLS or DTLS, there shouldn't be any problems with security. The access control question requires us to decide what makes up a service when e.g. WebSockets or MQTT is being used. Access control is on a per-service basis, as it currently stands.

[punyal]

There are problems even with (D)TLS, an example can be MQTT where we need a broker, so there will not be direct communication with the AH Core. In that case, we must "trust" the broker from AH. Regarding AC, a control per-service is not enough. More fined grain mechanisms are demanded. We can discuss this at the next meeting if you want.

[emanuelpalm]

I would assume the MQTT broker would need to have an Arrowhead-compliant certificate. An Arrowhead cloud is not just a networking or communication concept, it is the idea of a physical premise within which Arrowhead systems communicate with each other and other systems. If you use an MQTT broker in your local cloud, you would have to trust that just as the rest of your equipment. Excuse me if I say things you already know. Indeed there could be some details having to be worked out regarding pub/sub architectures and security. I don't see anything that would be difficult to solve, however. Please tell me if I'm wrong.

Access Control is the one that is a bit tougher to solve, just as you hinted at. Per-service is hardly a size that fits all, so to speak. There have been quite some work at LTU at replacing the current AC model with one using NGAC (Next Generation Access Control), which would move the granularity to specific requests matching specific "filters" (I can't recall the actual name, but that is how I conceptualize them functionally). I'm unsure how close those efforts are at resulting in something concrete for Arrowhead.

You should bring this up in the next meeting. I would love to see this issue getting more attention.

[emanuelpalm]

@punyal How do you want to proceed with this issue? Would you like to propose starting a roadmap subgroup? If nothing else, I will certainly work for that Arrowhead moves in the direction I believe you are wishing for. Perhaps that is enough?

[jerkerdelsing]

@jenseliasson @punyal Any updates to this?

[jenseliasson]

WebSockets have been added to the core software base and is already used by th DataManager. The next step would be to add WS to the appropriate services in the service registry, orchestrator and authorization.

The same can be achieved by MQTT with some application level subscription support.

Do you want me to have a look at it?

[jerkerdelsing]

Could be a very important feature. Especially in comparison with our competitors. Core requirements for v5.0.0. We keep it as an separate issue.