Service Life Cycle

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
MaVo's picture

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?

kwatters's picture

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.

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:






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

  • create
  • start
  • ready
  • shutdown

We might want pre/post hooks on each of those events... we might also want to introduce an error event of some sort.