GlobalRegistryMessage

[sgoendoer]

Regarding to the message format for the GReg. Where exactly is this to be used?

Yesterday, we had a fruitful discussion with @sdruesedow and @ingofriese and came to the understanding that the Runtime would communicate with the MessageNode using the Global Registry Message formats. For the connection between the MN and the GReg, we use a rather simple REST-style interface described here.

Any thoughts on that?

[pchainho]

Not sure about your question but I understand any entity is able to query the Global Discovery but only the Graph Connector is able to write on it, using these messages.

Then, these message should be translated into your REST API at the MN connector. This is very similar to what is done today with the Domain Registry.

[sbecot]

I think the question of @sgoendoer was about the specs . Indeed they are not describing the message format of the Greg, but the Message Node message format to use the Greg. As long as you use the MN you can use it. Out of the MN, the GReg should be accessed by the its Rest interface. I must admit that I don't understand the rest of the question.

[sgoendoer]

Out of the MN, the GReg should be accessed by the its Rest interface.

My point exactly.

What I meant:

only the Graph Connector is able to write on it, using these messages.

Not only the Graph Connector, but basically every component that is able to send an HTTP request is able to read from or write to the Global Registry (while the latter only makes sense if you are in possession of the signing keys). Whether other components will also access it or not is another question.

As the Global Registry uses a REST-style interface (which is more or less fixed since November 2015), using the exact message format would be a bit problematic.

First off, the REST paradigm would be impaired. Second, the message format specifies a JSON Object (i assume - that doesnt seem to be specified entirely) to be sent with READ requests (i.e. HTTP GET). As GET in HTTP does not allow a body to be transmitted, we would need to either use something completely different than HTTP, encode the MessageRequestJSONObject as a base64 parameter to be send as part of the URI, split the Requesting Object into it's parameters to send them via as parameters in the URI, or deviate from the REST approach big time by just using POST requests.

None of these options looks desirable in my opinion.

My question would hence is the following for the direct communication with the GlobalRegistry:

• Can we stay with the current REST interface the GlobalRegistry provides. It's easy to understand and use. (This only affects the HTTP-based communication between GReg and the service/component accessing it).
• If not, why?
• When have these message formats been discussed? They seem to just have popped up in the specs as of September 2016.
• What does the individual attributes mean and what are they used for? I understand the "body", I have a hunch regarding to "type", "to", and "from" regarding to its use in the Runtime if the message object is handed forward between components, but I dont really get the "id". Are the messages actually all JSON Objects?

[pchainho]

This spec was discussed and agreed with @fbeierle a long time ago:

https://github.com/reTHINK-project/dev-service-framework/blob/master/docs/specs/messages/global-registry-messages.md

[sbecot]

I think you are not talking of the same things. Requests formatted by Paulo are not the interface of the Greg, but of the runtime, and then the runtime translate in Rest interfaces to use the Greg. I think this is the case. So you shouldn't worry, your interface is the good one, and should be also written in the specs. The one Paulo points out shows is an internal interface of the runtime.

So the Global Registry is an independent component. It has been designed with a rest interface, and client of the Greg uses the interface designed for it. If the interface does not fit your client, they should ask for a motivated change request.

The good question would be: why should the Graph connector use the Runtime as a supplementary layer to use the Greg? The complexity/benefit is not so clear. Indeed, one of the requirements is loosely coupled architecture and all is stuck to the runtime.

Can we stay with the current REST interface the GlobalRegistry provides. It's easy to understand and use. (This only affects the HTTP-based communication between GReg and the service/component accessing it).

Yes: the two are complementary, not opposite (the interface described by Paulo is internal and does not affect your component).

What does the individual attributes mean and what are they used for? I understand the "body", I have a hunch regarding to "type", "to", and "from" regarding to its use in the Runtime if the message object is handed forward between components, but I dont really get the "id". Are the messages actually all JSON Objects?

This is internal to the Runtime.

[jmcrom]

As a matter of fact, as we are using a message-based framework (MsgBus + MsgNode) most capabilities are internally invoked thru messages (see here)

[sgoendoer]

Thanks for the clarification. I'll add the GReg REST specs description to the specs repository