How to configure multiple NamingServices in a single Domain

Make sure to store the database and the logs in a separate places.

Let's say you start from a domain with only a locator and a node_daemon 
it in. What you effectively need to do is to configure two Naming Service 
instances while avoiding name conflicts between the OS and Orbix resources 
the two NamingServices use. The configuration for the two NamingServices 
would look like this:

     naming
     {
          orb_plugins = ["local_log_stream", "iiop_profile", "giop", "ots", "iiop"];
     event_log:filters = ["IT_NAMING=WARN ERROR FATAL", "IT_MGMT=ERROR FATAL", "IT_PSS_DB=INFO_HIGH WARN ERROR FATAL"];
          plugins:naming:shlib_name = "it_naming_svr";
          plugins:it_naming_store_pss_r:shlib_name = "it_naming_svr_store_pss_r";
          pss_plugins = ["it_naming_store_pss_r"];
          plugins:naming:connect_to = "it_naming_store";
          plugins:pss_db:envs:it_naming_store:create_dirs = "true";
          plugins:pss_db:envs:it_naming_store:init_txn = "true";

          instance1
          {
        plugins:poa:root_name = "instance1";
             plugins:local_log_stream:filename = "/x1/inst/var/sample-domain/logs/naming_instance1.log";
             plugins:pss_db:envs:it_naming_store:db_home = "/x1/inst/var/sample-domain/dbs/naming_instance1";
          };

          instance2
          {
        plugins:poa:root_name = "instance2";
             plugins:local_log_stream:filename = "/x1/inst/var/sample-domain/logs/naming_instance2.log";
             plugins:pss_db:envs:it_naming_store:db_home = "/x1/inst/var/sample-domain/dbs/naming_instance2";
          };
      };

The plugins:poa:root_name variable gives names to otherwise anonymous RootPOAs 
in the NamingServices, to make sure their indirect-persistent POAs do not become replicas 
in the IMR.

Once you have the configuration in place, source the domain environment, prepare 
the two NSes

>/x1/inst/asp/6.3/bin/itnaming -ORBname iona_services.naming.instance1 prepare
NameService = IOR:0100...

>/x1/inst/asp/6.3/bin/itnaming -ORBname iona_services.naming.instance2 prepare
NameService = IOR:0100...

and save the NameService IORs. This also creates the corresponding records in 
the IMR for the processes, ORBs and POAs:

>itadmin process list
iona_services.naming.instance1
iona_services.naming.instance2

>itadmin orbname list
iona_services.naming.instance1
iona_services.naming.instance2

>itadmin poa list
instance1
instance1/IT_NamingContextExt
instance1/IT_ObjectGroup
instance1/IT_ObjectGroupFactory
instance1/IT_NamingServiceAdmin_iona_services.naming.instance1
instance1/IT_MasterNamingContextExt_iona_services.naming.instance1
instance1/IT_Maste.rObjectGroupFactory_iona_services.naming.instance1
instance1/IT_MasterObjectGroup_iona_services.naming.instance1
instance2
instance2/IT_NamingContextExt
instance2/IT_ObjectGroup
instance2/IT_ObjectGroupFactory
instance2/IT_NamingServiceAdmin_iona_services.naming.instance2
instance2/IT_MasterNamingContextExt_iona_services.naming.instance2
instance2/IT_MasterObjectGroupFactory_iona_services.naming.instance2
instance2/IT_MasterObjectGroup_iona_services.naming.instance2

Note the effect of the plugins:poa:root_name settings on the names of 
the POAs. Another aspect of named RootPOAs is that their names end up 
embedded into the NamingService IORs:

>iordump IOR:010... # instance1 NameService initial reference
...
Object key data: ':>.21.sample-domain.location.instance1.IT_NamingContextExt..........'
...

>iordump IOR:010... # instance2 NameService initial reference
...
Object key data: ':>.21.sample-domain.location.instance2.IT_NamingContextExt..........'
...

>

So you'll need to redistribute the IORs to the clients if you change them. 
Also, at this point you can modify the process entries in the IMR for 
on-demand activation if you want.

You might also need to configure distinct NameService initial references, 
if only to be able to reach them with 'itadmin ns'. You would need two config 
scopes 

      naming_instance1
      {
          initial_references:NameService:reference = "IOR:01000000....";
      };

      naming_instance2
      {
          initial_references:NameService:reference = "IOR:0100000028000....";
      };

and the corresponding -ORBname command line arguments for itadmin:

>itadmin -ORBname naming_instance1 ns newnc new_nc_in_instance1
>itadmin -ORBname naming_instance2 ns newnc new_nc_in_instance2
>itadmin -ORBname naming_instance1 ns list

new_nc_in_instance1     Context

>itadmin -ORBname naming_instance2 ns list

new_nc_in_instance2     Context

Note the effect of the plugins:poa:root_name settings on the names of 
the POAs. Another aspect of named RootPOAs is that their names end up 
embedded into the NamingService IORs:

>iordump IOR:010... # instance1 NameService initial reference
...
Object key data: ':>.21.sample-domain.location.instance1.IT_NamingContextExt..........'
...

>iordump IOR:010... # instance2 NameService initial reference
...
Object key data: ':>.21.sample-domain.location.instance2.IT_NamingContextExt..........'
...

>

So you'll need to redistribute the IORs to the clients if you change them. 
Also, at this point you can modify the process entries in the IMR for 
on-demand activation if you want.

You might also need to configure distinct NameService initial references, 
if only to be able to reach them with 'itadmin ns'. You would need two config 
scopes 

      naming_instance1
      {
          initial_references:NameService:reference = "IOR:01000000....";
      };

      naming_instance2
      {
          initial_references:NameService:reference = "IOR:0100000028000....";
      };

and the corresponding -ORBname command line arguments for itadmin:

>itadmin -ORBname naming_instance1 ns newnc new_nc_in_instance1
>itadmin -ORBname naming_instance2 ns newnc new_nc_in_instance2
>itadmin -ORBname naming_instance1 ns list

new_nc_in_instance1     Context

>itadmin -ORBname naming_instance2 ns list

new_nc_in_instance2     Context