Closed pchainho closed 7 years ago
Is this the same as discussed where: https://github.com/reTHINK-project/dev-registry-global/issues/11 ?
yes, but to be supported by the discovery lib.
OK. So it is not related to that issue https://github.com/reTHINK-project/dev-registry-global/issues/11.
It has only to do with integrating, into the runtime discovery lib, the search by GUID. A connector for the global registry already exists in Vertex. So this is a question of interacting with it. Right?
As far as I understand, since Global Registry does not support GUID discovery by IDP Identifiers, we have to use the discovery service
@ingofriese Is there a simply way for the runtime to query the discovery service? Is there a connector for a message node?
@pchainho Should we implement search by GUID using the Global Registry or not?
Yes, I think it is better.
The search by GUID can be implemented with a simple http GET and the global registry is public. I don't see any added value in going through the msg node though a connector. Concerning the discovery service, it's basically the same, and more, implementing a connector is adding comlpexity, and oblige to maintain more code. To finally do an http GET. This way of doing tightly couple the componants. You can of course implement such connectors, but as a application developper I would use directly the APIs.
The runtime is agnostic of protocols or external APIs.
Currently it should only depend on the Catalogue well-known URIs
@rjflp any progress on this?
I am sorry but this is not true. On the contrary the runtime seems to be linked to the apis of the external components through their APIs, meaning that you need to develop and maintain many connectors. The runtime should be as thin as possible. Implementing a new protocol does not mean that you are agnostic, it means that you use a proprietary one.
could you be more clear, perhaps with some examples?
I suspect there is some miss-understanding here
jst a basic fact: most of the web today is not rethink-compliant, not even rethink-aware
to bring them to rethink we have to shows s that the cost of integration is minimal whilst the benefits are huge
Just to be more clear, at the begining I was expecting the message node, and the runtime, to be as thin as possible. This means that the msg bus would route messages dedicated to hyperty signaling, even for catalogue and domain registry if you considere msg node as a gate keeper. I see now in your implementation that all is routed in the msg bus, even support services, which means overhead, complexity in the runtime, and coupling.
@jmcrom I completely agree with you but I think discovery service and global discovery are rethink backend support services
@sbecot the message node is light. Runtime is not so light but that was expected since it is where we have the "business logic" running at the edge. We knew that from the very beginning. Currently we are using the msg node as "gatekeeper" of backend services because that 's the only place where we have a policy engine. Otherwise the runtime could directly interact with these backend services with protostubs. That's also a possibility for the discovery service. It should be straightforward. Another option is to have the discovery service directly connected with the messaging framework as discussed in Lisbon. I think @sdruesedow also has already something implemented for that .
@ingofriese @pchainho
I'm starting looking at this and from the comments above i guess we didn't reach a conclusion related on how to issue queries from the runtime to the discovery service. So, how should the queries be issued? Is there a connector, or the REST endpoints should be used to make HTTP calls, and therefore get the GUID?
Use case: Translate a user url or email to obtain the associated GUID
Current status:
-Waiting for "java loader" being written to complete integration with Discovery Service -Have completed integration with Global Registry. Still testing before release.
Apparently we went the wrong way on this one! We implemented the "client side" on the discovery lib (runtime) that enabled the runtime to communicate with the Global Registry via Message Node. We get the replies back, but have no way to verify the signature.
We should have used the Graph Connector, that already does most of this (if not all). @fbeierle is having a look at how to best integrate the Runtime Discovery Lib with the Graph Connector, already present in the runtime.
The Graph Connector is a runtime core component that already interacts with the Global Registry. Similar to the Domain Registry, a connector in the Message Node (https://github.com/reTHINK-project/dev-msg-node-vertx/tree/master/src/js/connector) handles the call to the Global Registry REST interface. You can find the code for querying the Global Registry here, including the checks of the signature: https://github.com/reTHINK-project/dev-runtime-core/blob/develop-graphConnector/src/graphconnector/GraphConnector.js#L411
As for integration, I think we could: (a) duplicate code and have the Discovery Lib do the same (b) have the Discovery Lib use the Graph Connector to interact with the Global Registry (c) have the Graph Connector use the Discovery Lib to interact with the Global Registry
I think (c) makes the most sense. The Discovery Lib would then bundle all registry interactions. Please note that for the Graph Connector, we also need to send CREATE messages to the Global Registry: https://github.com/reTHINK-project/dev-runtime-core/blob/develop-graphConnector/src/graphconnector/GraphConnector.js#L288
I agree with @fbeierle. Since we have implemented the exactly same query that Graph Connector does to get GUIDs ("READ") from the Global Registry; however, we didn't verify the signatures.
Using (c), it'll only be necessary to add one more query in the discovery lib that sends CREATE messages to Global Registry.
This is ok if the discovery Lib is in the runtime core but I believe this was already done: do you confirm @BernardoMG ?
@fbeierle @pchainho I would say that I prefer option b). The discovery lib would only encapsulate the methods for "discovering" hyperties: Discovery Service, Global Registry and Domain Registry. Eventually, it could also have a method for querying the Graph Connector?
The Graph connector provides more complex functionality (such as creating and inserting GUIDs into the Global Registry) which are not necessary related to searching for other users.
The advantage of keeping the Discovery Lib, would be to encapsulate all the searches:
@BernardoMG Noticed that we currently have a duplication of code to create and send and receive messages to/from the Message Node. We have it at least in the Discovery Lib and in the Graph Connector. Regardless of how we go forward with the integration, it would be wise to refactor the code to use the same methods for contacting the Message Node.
Is there more code in the runtime to contact the Message Node?
What kind of duplication? In general, the exchange of messages between the runtime and back-end services are performed disregardless of the Message Node. For example, the discovery lib just has to use the domain registry address domain://registry.<domain>
to exchange messages with it.
Anyway, I agree there are some components that should be refactored. At this point I'm not going to name them yet ;-)
Currently going with @fbeierle option b) to factor all the Discovery Service, Registry interactions into the Discovery Lib.
For communication with the Global Registry, we use the GraphConnector.
Registry.js is being refactored to use Discovery Lib.
This seams to be the way to "save" the most on code duplication.
Discovery Lib is now integrated in runtime-core (branch discovery-integration
), supporting several discoveries methods.
In total, it supports nine different discovery methods in respect to hyperties and dataObjects.
It used the branches:
dev-runtime-core: discovery-integration
dev-hyperty-toolkit: addressbook-app
dev-registry-domain: develop
dev-msg-node-vertx: develop
dev-service-framework: 74-add-global-discovery-features
dev-runtime-browser: develop-GraphConnector-Test
Discovery methods still exists in the service framework to maintain compatibility with the existing hyperties. But they are now deprecated. A deprecated tag was added to these methods.
I don't find the listener for "
Still working on the exchange of messages between Core Discovery (runtime-core) and Discovery Lib (service-framework).
Messaging between the Core Discovery and Discovery Lib implemented according to this.
You may try it using the following branches:
dev-runtime-core: discovery-integration
dev-hyperty-toolkit: addressbook-app
dev-registry-domain: develop
dev-msg-node-vertx: connector-release-0.8.0
dev-service-framework: 74-add-global-discovery-features
dev-runtime-browser: develop-GraphConnector-Test
After this PR is merged into the develop
branch in runtime-core
, we'll add this implementation to a more recent branch and add unit tests for this component.
@BernardoMG Graph Connector was merged with Runtime Core develop branch
Discovery methods that could receive the email are now updated in order to use the new query per user email supported by the Domain Registry.
Global discovery features are now merged and working for browser and nodejs.
You may try it using the following branches:
dev-runtime-core: develop
dev-hyperty-toolkit: develop
dev-registry-domain: develop
dev-msg-node-vertx: develop
The testbed will be updated in the next days.
We'll update the test of Discovery
in service-framework and add new tests for CoreDiscovery
in runtime-core.
This issue will be closed when the tests are updated.
All tests have been updated. This issue is complete.
Pending on this one.