Component Base Class Rationale Components share common startup and shutdown patterns Consistency across components is difficult to maintain, especially when changes to location, replication, etc. occur Benefits Encapsulates most of the Ice related “boilerplate code” for Icebox services Concrete instance of proper startup and shutdown protocol Provides some default implementation, lowering the bar for component developers getting started The need for a component base class became increasingly clear as more components were developed. With overall infrastructure-like features like replication, configuration and discovery being added and refined by different developers, the inconsistencies became unmanageable. It was decided to create a base class that would formalize and set in "code" the start-up and shutdown protocols as well as provide support for the implementation of derived classes that provide the component specific specializations. Maintaining the existing components was more efficient and creating new components that behaved as good Asterisk SCF "citizens" was much easier.

Component Base Class -Anatomy (1/3) Method groups system component initialization initialization service registration replication support shutdown and cleanup After looking at why it exists, let's look at what and where it is. You will notice that the Component class itself is derived from IceBox::Service. Asterisk SCF components are implemented as IceBox services and need to implement certain methods so that IceBox can load, start and stop them properly. The first group of functions: suspended, etc. are there to allow servants implementing the AsteriskSCF "Component" interface defined in Slice to control the IceBox service as well. This interface is accessible remotely through Ice and allows the component to be shutdown or "paused" remotely. The second set of methods are there to support implementations of the Asterisk SCF Replica interface which basically allows a component to be made active or put into standby mode remotely.

Component Base Class – Anatomy (2/3) Vertical interface methods: i.e. interface for derived classes Default implementations Abstract (pure virtual) methods Most of the rest of the methods are in the "protected" section of the class declaration as they are meant to be used only by derived classes. The methods include "notification" type calls that are called when key stages of initialization or shutdown. For example, onPreInitialize() is where you might initialize third party libraries, etc. Methods like createBackplaneServices() and createPrimaryServices() are key and must have implementations. In the case of backplane services, the minimal set of backplane services are the component and replica objects, so the Component class provides a default implementation. In the case of "primary" services, these are the fundamental services implemented and "advertised" by a particular component instance. It is not possible to provide a default implementation for this method because the objects that need to be created are not known to the Component base class and will change for each component. Amongst the methods not shown here are the important counterparts to initialization, that is the methods that are called when shutting down the components. This is very handy! As they take care of the clean up for you.

Component Base Class – Anatomy (3/3) Helpers for managing registrations with the service locator registering and unregistering support for retry reduces startup order issues void managePrimaryService( const AsteriskSCF::Discovery::LocatorRegistrationWrapperPtr& service); void manageBackplaneService( AsteriskSCF::Discovery::LocatorRegistrationWrapperPtr wrapServiceForRegistration(const Ice::ObjectPrx& proxy, const std::string& category) const; Finally, here are some examples of some helper methods for registering your services with the service locator and managing the registration, including unregistering the services on shutdown. The first two basically register an instance of a registration wrapper object with one of two collections of wrapper objects. The last method is a little special. It is one of two – the other one having a few extra parameters – that "wrap" a proxy with some simple registration information in an object that attempts to contact the service locator and register the proxy so it might be found by others. The cool thing is, if it cannot contact the service locator it takes care of retrying it for you. It will keep retrying until you shut down the component. Why is this important? Well, Asterisk SCF is made up of a collection of multiple components, of which the service locator is one. One problem in this type of system is component dependency, particularly on startup. If your component needs another component that is unavailable at startup, you have a few choices, go away, hold things up indefinitely until you can get at that component or continue with initialization, retrying in the background. The first choice is not great because a deployer may pull their hair out trying to figure out why a component is not coming up and waste time checking and re-checking configuration, blaming it on bugs, etc. when all it was that component XYZ was not started yet. The second choice is actually preferred under some conditions, if a component absolutely cannot do anything until it makes that one (or two or three, well you get the idea) important call during startup, then holding up until it can make that call is not always a terrible choice. The third choice is most appropriate when you really should make some calls, but your component could conceivably perform some useful work without it. In Asterisk SCF, the third choice is really very similar to the second one because even if the service comes all the way up, the only way not registering with the location (for example) will not affect the overall system function is if none of the other services it is going to call on will need to access it and will do so by finding it through the service locator. needs rewording.. maybe a diagram would be good... something with a sad face !