Service Bootstrap Design
------------------------

   The Service Bootstrap for the control system serves to insure that
   there is mechanism for connecting to Services, whether in the
   parent controller process or on a remote host.  

   The primary requirements for the Service Bootstrap are:

      1) A means for a Service_Manager to know the list of hosts at
         which to look for remote Services. 

      2) Client RPS2 invocations need to have access to remote
         Service_Factorys.  

      3) The Service_Manager needs to be able to determine if a particular
         remote host is available for providing a particular Service.

      4) Service_Factorys need to be creatable with marker names
         registered in the implementation repository for access by remote
         RPS2 processes. 

      5) Service_Factorys need to be creatable without marker names for
         access by parent controller process. 


   The design for the Service Bootstrap consists of a set of solutions
   for the requirements.


      Solution for Requirement 1:
         Add a preference called remote_hosts to all Tools that is a list of
         host names.  There will be a special hostname "localHost" for
         running the Tool in the parent controller process.  There will be a
         default list that is something like:   

		localHost
		rps21.stsci.edu
		rps22.stsci.edu
		rps23.stsci.edu

         When a Tool runs, it will pass the list of host names to the
         Service_Manager.


      Solution for Requirement 2:
         Create a main program which serves out Service_Factorys.  This main
         program will be registered in the OrbixWeb implementation
         repository (ie, the OrbixWeb daemon) on each host which provides
         remote services for RPS2.  The main server program will be
         registered with server name "RPS2_REMOTE_SERVER".  The associated
         Service_Factory will be registered with marker name
         "SERVICE_FACTORY".   RPS2 can then access a registered
         Service_Factory on a remote machine given by remote_host using the
         OrbixWeb bind function:  
   
   	    Factory remote_service_factory =
   	       FactoryHelper.bind
   	          ("SERVICE_FACTORY:RPS2_REMOTE_SERVER", remote_host);


      Solution for Requirement 3:
         The Service_Manager first attempts to request the Service from the
         Service_Factory at the remote host.  If the Service_Manager cannot
         connect with the remote Service_Factory, then the Service is assumed
         to not be available from the remote host.
   
         If the Service_Factory is available, then the Service_Factory will
         attempt to locate the particular Service.  The Service may either
         be a JAVA implemented object directly accessible from the
         Service_Factory's process, a JAVA wrapped image, or a CORBA
         accessible image.  In the case of JAVA wrapped images or CORBA 
         accessible images, the Service_Factory checks to see if the image 
         is accessible.  If not, then the Service_Factory throws an
         exception.  Otherwise, the Service is created and its object
         reference is returned to the Service_Manager. 


      Solution for Requirement 4:
         Service_Factory has a constructor that takes a marker name string
         as an argument.  The constructor passes this string to the super
         class to register the Service_Factory in the implementation
         repository.  Upon invocation, the Service Server registered in the
         remote host implementation repository will create a Service_Factory
         with marker name "SERVICE_FACTORY".

      Solution for Requirement 5:
         Service_Factory has a constructor with no arguments that creates
         the Sevice_Factory without registering it in the implementation 
         repository.