You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the current behavior?
We need systematic way to allow DESDEO to be connected to simulators that can, e.g., generate solutions to multiobjective optimization problems. This way, we can implement support for simulator-based problems. Describe the solution you'd like
This solution should be simple enough to be implemented on both sides. We cannot expect DESDEO to be able to connect universally to any software, remotely or locally. Instead, we need to require the server-side to implement a simple interface to their simulator to be able to connect to DESDEO. Then, DESDEO can expect this kind of interface to be available, which allows DESDEO to communicate with it.
What is the motivation/use case for changing the behavior?
We currently have no way to support simulator-based problems, unless we first run the simulator, generate data, and then model a multiobjective optimization problem offline, based on the data.
Describe alternatives you've considered
Because we want for users to be able to supply a simulator even though a graphical user interface in the future, it should be enough to supply an (web) url to a simulator's API. For these, we need the simulator-side to implement a simple web-based API. We could have such an url for each objective function separately, if the values come from different simulators, or just one for all the objective functions.
There exist software that support remote procedure calls in Python. These vary in their features, and come with built-in security considerations as well. Some of these are:
gRPC: gRPC generates server and client (python) files based on .proto service definitions. An example of such a file can be found here. There is also a quick start guide for Python here. gRPC is not purely Python based.
pyro: pyro is a Python-based solution for remote objects. This allows Python objects to remotely communicate with each other. Pyro offers a quick intro and example here.
ZeroMQ: ZeroMQ seems to be a popular option as well, an it offers a Python implementation. A brief example of it is available here.
FastAPI: since we are already using FastAPI, we could also require users to implement a simple fast API server that provides an interface to their simulator. By careful documentation, and offering a cookie-cutter template, we can clearly indicate what HTTP endpoint we might require from the API implemented by the client. Because, apart from gRPC, the two other options seems to be just specialized web APIs. I am probably mistaken, but correct me if I am wrong.
There are probably many more similar solutions, so if I missed any, feel free to add. I do not have much experience in this, so any input from a more experienced individual, is welcome.
Additional context
I believe whatever option we chooses, documenting the steps necessary to be taken by users for connecting their simulator(s) to DESDEO, will be crucial. Therefore, when choosing an option, we should keep in mind the ease of its implementation for both us, and especially users.
The text was updated successfully, but these errors were encountered:
What is the current behavior?
We need systematic way to allow DESDEO to be connected to simulators that can, e.g., generate solutions to multiobjective optimization problems. This way, we can implement support for simulator-based problems.
Describe the solution you'd like
This solution should be simple enough to be implemented on both sides. We cannot expect DESDEO to be able to connect universally to any software, remotely or locally. Instead, we need to require the server-side to implement a simple interface to their simulator to be able to connect to DESDEO. Then, DESDEO can expect this kind of interface to be available, which allows DESDEO to communicate with it.
What is the motivation/use case for changing the behavior?
We currently have no way to support simulator-based problems, unless we first run the simulator, generate data, and then model a multiobjective optimization problem offline, based on the data.
Describe alternatives you've considered
Because we want for users to be able to supply a simulator even though a graphical user interface in the future, it should be enough to supply an (web) url to a simulator's API. For these, we need the simulator-side to implement a simple web-based API. We could have such an url for each objective function separately, if the values come from different simulators, or just one for all the objective functions.
There exist software that support remote procedure calls in Python. These vary in their features, and come with built-in security considerations as well. Some of these are:
gRPC: gRPC generates server and client (python) files based on
.proto
service definitions. An example of such a file can be found here. There is also a quick start guide for Python here. gRPC is not purely Python based.pyro: pyro is a Python-based solution for remote objects. This allows Python objects to remotely communicate with each other. Pyro offers a quick intro and example here.
ZeroMQ: ZeroMQ seems to be a popular option as well, an it offers a Python implementation. A brief example of it is available here.
FastAPI: since we are already using FastAPI, we could also require users to implement a simple fast API server that provides an interface to their simulator. By careful documentation, and offering a cookie-cutter template, we can clearly indicate what HTTP endpoint we might require from the API implemented by the client. Because, apart from gRPC, the two other options seems to be just specialized web APIs. I am probably mistaken, but correct me if I am wrong.
There are probably many more similar solutions, so if I missed any, feel free to add. I do not have much experience in this, so any input from a more experienced individual, is welcome.
Additional context
I believe whatever option we chooses, documenting the steps necessary to be taken by users for connecting their simulator(s) to DESDEO, will be crucial. Therefore, when choosing an option, we should keep in mind the ease of its implementation for both us, and especially users.
The text was updated successfully, but these errors were encountered: