Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Document patterns for services that depend on other services #453

Open
mdickinson opened this issue Oct 21, 2021 · 0 comments
Open

Document patterns for services that depend on other services #453

mdickinson opened this issue Oct 21, 2021 · 0 comments
Labels
component: documentation Issues related to documentation.

Comments

@mdickinson
Copy link
Member

The Envisage service docs are explicit that:

To get the job done, services obviously need to interact, and so Envisage provides a way for them to find each other. This is where the service registry comes in.

This turns up in real projects: for example, a service that provides remote compute facilities might depend on a database service (to store inputs and outputs for the compute jobs).

However, we're missing documentation on good patterns for this; it would be good to fix that.

A pattern that doesn't work well is to instantiate the dependent services at ServiceOffer creation time - that can lead to issues with ordering of plugin startups. A better pattern is to instantiate the dependent services when the ServiceOffer object's factory is called (which should happen after all the service offers have been contributed to the service registry). That typically means passing the service registry object as a parameter to that factory. (Or the application, but the service factory will be easier to test if it doesn't require a fully-baked application object.)

@mdickinson mdickinson added the component: documentation Issues related to documentation. label Oct 21, 2021
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
component: documentation Issues related to documentation.
Projects
None yet
Development

No branches or pull requests

1 participant