Support Named Services for Communication of Services in the Shared Network

Lets think there are two mesg services called as Service A and Service B that created with their own mesg.yml files.

Service A may want to communicate with Service B over the private shared Docker network. But since there is no an option of setting human readable service names with the yml file or with the service starting api by using a –name flag, it’s required to use this kind of log names like core-f6c5f0abefc66ddb6a80565238fa69e8340582af-service which is hard to use and not static. We need static names otherwise it’s required to update Service B when source code of Service A is changed.

I propose to having the ability of setting static names to services inside yml file or/and with the –name flag on service starting/creation.

We also need to create a special network where all services are connected to each other but not their dependencies. Otherwise we can have conflicts in names because each dependencies has their own static names.

I think this one will be solved by either the service ID system Fixed Service ID/Name & Service Update, Create Feature and the service composition Service composition

I agree with @Anthony that it should be solve by “Fixed service ID” and “service composition”.

Also, Services SHOULD not be able to connect any other services directly. Services should communicate only to the Core.
Currently, services are on the same “mesg-shared” Docker Network but this is not something that should stay. We did it this way only for ease of development. The current design is not sandboxed enough.
We should create one network per service that also include the Core. And also new networks for the service to communicate with each dependencies.

I think we need to prioritize “Fixed service ID” and “service composition”.

from @Nicolas:
Also, Services SHOULD not be able to connect any other services directly. Services should communicate only to the Core.

I’m not sure about this one. There might be some valid reasons why we should not disallow this direct communication between services.

For example, Service A might be a reverse proxy to proxy http endpoints of Service B. In this case it needs to be able access to Service B through http like: http://unique-name-of-service-b. Or it can access to Service B over localhost by opening ports in the mesg.yaml's configuration section first but this will also expose Service B to outside network which may be an unwanted behavior in some cases.

Maybe I was not clear enough:
Direct communication between services should NOT be allowed. But,
Indirect communication between services through Core is fine.

We were brainstorming with Antho about this, and we could just provide the ExecuteTask, ListenEvent, and ListenResult api to the services. This with the alias on service, it will be easy and secure for a service to use another service.

This is still possible inside a single mesg service using the dependencies. All dependencies run in a single network and can access other containers.

If connections between mesg services is possible it means I can create a mesg service that tries to connect bruteforce the connection to all possible services and extract all the events from this service and maybe send it to a private database. Of course users have to verify the source code of the services they install but most of the time they don’t or don’t have the knowledge to do it correctly so we need to reduce this risk and sandbox the different services’s environments.

We can always do that using Service composition where the service will explicitly describe what services it belongs to and will have access only to that service (these services).