| Name | Current Action | Description | |
| install | called on Runtime | framework will install if not installed | |
| publishStatus | published from Runtime |
installationStart & installationStop - "general" Status msgs |
|
| getMetaData |
called by Runtime on Service |
getting "meta" information - dependencies, exclusions, peers | |
| create | called on Runtime | construct a new service - do not start inbox or outbox - do not create peers yet | |
| register | published by Runtime | puts service in Runtime's registry | |
| startService | called on Service | starts inbox, outbox - and can call startPeer for all peers | |
| isReady | queried from Service | ||
| isRunning | queried from Service | is true at this point | |
| publishShutdown | published by Runtime | ||
| preShutdown | called on Service | called on each service from Runtime before stopService & releaseService are called | |
| stopService | called on Service | stops the inbox and outbox | |
| releaseService | called on Service | removes the service from the registery | |
| released | published by Runtime | ||
| uninstall | Runtime | doesn't exist yet |
Rough draft of "what exists"
Currently these are method calls, and not "events" ..
register & release are the only official "events" in mrl
myrobotlab
I think we need to
I think we need to differentiate what the framework does vs which method is called on the service/which methods a service should override to do custom things at that stage.
e.g. I want to call a custom cleanup method durning stopService(). Do I now need to take care of my inbox and outbox myself as well?
Lifecycle management
This is really a subset of the methods on services. Lifecycle really is having consistent programatic hooks around when certain framework related things happen to services.
https://docs.oracle.com/cd/E19501-01/819-3659/beamc/index.html
Java defines a specific lifecycle for web servers, and if we consider our services to be very similar in nature.. then the following "official" java lifecycles would be as follows:
INIT_EVENT
STARTUP_EVENT
READY_EVENT
SHUTDOWN_EVENT
TERMINATION_EVENT..
This is just one model ... we might find there are other "events" in a service that we want to hook. Off the top of my head I can think of the following
We might want pre/post hooks on each of those events... we might also want to introduce an error event of some sort.