After starving for a good definition for SMF I concluded that it can be better understood as a special framework to provide service availability support, optimization and orchestration for a set of related daemons and (sh) scripts collectively abstracted as a service. It is important to grasp this concept of service as not necessarily being a synonym to a single daemon.
NOTE
In relation to a service initialization it's also important to keep in mind that in most cases (contract or transient service models), a script or daemon should not spawn or fork and then exit from their initial process. Instead, they should wait until start-up completion and, only then, return.For developers and administrators SMF exposes a local multi-layered (more on this on later SMF administration series of posts) repository of services' metadata and an interface (CLI) for both the repository's and service's administration.
By now, it should be clear that SMF service development is nothing more than integrating a certain set of related daemons and scripts into the SMF framework, which shouldn't be difficult provided that one has all the necessary information and the big-picture of how to properly carry out the task. This is precisely what I intend to demonstrate in a following SMF development series of posts:
