Overview

At deployment time, a component instance can be marked in the CDB as the default component for it's IDL type. This is particularly useful for clients of components that know ahead of time there will only be a single instance of a component they utilize throughout ALMA software (e.g., the Scheduling subsystem's Master Scheduler component is a perfect example). In short, the main benefit of using Default components is the client developer need not know the name of the singleton component he or she may be working with. Additionally, the component developer need not be aware of the fact they are developing a Default component (i.e., there is nothing special they must do).

As an example, we'll take a look at the identifier archive component in the standard CDB ($ACSDATA/config/defaultCDB/CDB/MACI/Components/Components.xml):

<_ Name="IDENTIFIER_ARCHIVE"
     Code="alma.archive.helpers.IdentifierHelper"
     Type="IDL:alma/xmlstore/Identifier:1.0"
     Container="frodoContainer"
     Default="true"/>

As you can see, IDENTIFIER_ARCHIVE becomes the default component of type "IDL:alma/xmlstore/Identifier:1.0" by changing the Default attribute from "false" to "true".

In the running system, a client can obtain this instance of the identifier archive without having to know the instance name IDENTIFIER_ARCHIVE. It only has to provide the Type attribute (IDL:alma/xmlstore/Identifier:1.0) that is independent of any particular deployment configuration.

If the client is a Java component, it would use the method public org.omg.CORBA.Object getDefaultComponent(String componentIDLType) from the ContainerServices interface. For a C++ component, !!!TODO!!!