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.)
The Envisage service docs are explicit that:
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
ServiceOffercreation time - that can lead to issues with ordering of plugin startups. A better pattern is to instantiate the dependent services when theServiceOfferobject'sfactoryis 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.)