Integration with runtime

[rjflp]

The runtime has a component called "discovery lib" that enables apps to "discover hyperties". It basically should provide these calls (or similar):

• Given profile data (such as email, name, etc) and type of service (e.g. video call) return hyperties or dataobject (two methods)
• Given GUID and type of service (e.g. video call) return hyperties or dataobject (two methods)
• Given user@idp@sp and type of service (e.g. video call) return hyperties or dataobject (two methods)

Currently, we are using the Message Node to communicate with the Domain Registry and the Graph Connector to query the Global Registry (also through the Message Node).

We are missing a way for the runtime to communicate with the Discovery Service. @ingofriese @sdruesedow Can you lets us when the protostub loader is available? In order to integrate all this into the next release, it would be great if you can provide this next week?

[sdruesedow]

As far as I know the way for any component (incl. the runtime) to access the Discovery Service is via its exposed REST API (see here for reference) @ingofriese: please correct me if I'm wrong.

The protostub loader is a proposed alternative way for the discovery service itself to communicate with the Domain Registries via corresponding Message Nodes. Currently the discovery service uses REST to query the domain registries directly (which at the moment doesn't work as it should due to a versioning issue: issue 57 ).

The protostub loader is working in general but not yet integrated with the discovery service. Personally I got severe doubts about that mechanism because it opens the door for any kind of abuse. It would allow ANY (even non-authorized) component to send ANY kind of message to a MN. IMO the security concerns are lower with a direct REST interfacing between discovery and domain registry, even if it means to open an additional port in a firewall. But I'm not an expert on security.

[ingofriese]

Steffen is right an exposed REST API / or a Web interface are currently the only ways to contact the discovery service. Maybe I don't get the poin but every runtime or message node can do an API call.

[sbecot]

I fully agree. This was also discussed here. A REST API guarantees to have a loosely coupled way of querying a component.

[fbeierle]

In order to demonstrate the feasibility of integrating the Discovery Service into the Address Book via the REST API, we implemented it prototypically in the current version (see also here: https://github.com/reTHINK-project/dev-runtime-core/issues/33):

Querying the Discovery Services:

Display of results of an example query:

[rjflp]

The idea of using a protostub like approach was do decouple the runtime from the current implementation of the Discovery Service. We have a fully decentralized architecture, where different service providers colaborate, were calls depend on a single Discovery Service.

I know this should evolve into a distributed system, but development work is about to finish. Also, in my view, the Discovery Service was one of the components where each Service Provider, or third parties, could innovate by creating different services. Even though I don't know how, I expect the Discovery Service to also evolve into several instances in the future. A protostub like approach would make this easier.

Anyway, we had also added a REST client to the Discovery Lib so not to halt development work by other. We were hopping to then evolve into this solution. We are currently factoring into the Discovery Lib code that was spread over several places.

@fbeierle Would you be willing to use the discovery Lib for this?

[ingofriese]

Ok...from your last remark I see two points. The idea was once to have several instances exchanging search queries. this could be a way to distribute the service. Its not yet implemented.

I think we need a preconfigured discovery-URl anyway.

How is the Ip-address of the global registry configured. Is it hard coded?

[sbecot]

protostub like approach was to decouple the runtime from the current implementation

I think this is exactly the opposite. If you insert a part of the code discovery service in the runtime it will be completely coupled. You can say that the prototub itself is downloaded from the service. But this suppose you share a datamodel, so you are coupled. Anyway, besides google there are other search engines in the web, that all can be used by there API in the web browser. And this works without protostub. @ingofriese : I agree that the preconfigured discovery-URI is necessary. That's the same mechanism in the web browser. Maybe this could be a parameter of the runtime. We can imagin a service provider has a prefered engine.

[fbeierle]

How is the Ip-address of the global registry configured. Is it hard coded?

The communication with the Global Registry is handled by the message node. So far, the IP of the Global Registry is hardcoded there: https://github.com/reTHINK-project/dev-msg-node-vertx/blob/develop/node.config.json#L10

[ingofriese]

Ok here we go. The Global Registry Entries are distributed in a DHT. But the management server has also one single address (or 3 like mentioned somewhere) Anyway in this configuration file also the discovery URl can be hardcoded in the same way.

[fbeierle]

@fbeierle Would you be willing to use the discovery Lib for this?

In principle yes, as I see it, it would just be a matter of refactoring.