A service started by an instance of the registry will have an ID assigned to it. Child services will be organized into groups, with an ID assigned to each group by the registry. A group can, in turn, have sub-groups, so the definition of a group is recursive, and groups are organized into n-ary trees. The ID assigned to a service or group will be a string constructed with a URI-like strategy, starting with the instance ID of the registry, followed by a separator (a colon or two?) and then the ID for the entity. Group IDs will be divided into segments by periods, with each segment indicating a level in a hierarchy of groups. The left-most segment of a group ID would be the 'root' group, then, and the right-most segment would be the ID of an individual group. The registry instance ID could be optional, allowing for short ID values, as opposed to fully-qualified ones. The ID for services could include the ID for its owning group, although I'm not sure how useful that would be. So, for example, a group ID would be something like

some.registry.host:1.2.3 (1.2.3 for the short form)

and a service ID would be

some.registry.host:1 (1 for the short form) (or maybe some.registry.host:1.2.3:1)

Service groups are created with a call to createServiceGroup(), and they never expire. Service groups can have descriptive labels attached to them, which are appended to log output associated with that particular group. A service group can be removed from a registry with a call to removeServiceGroup(), which releases the data structures associated with the group and stops any running services owned by the group. The registry implementation will eventually need to maintain a database of active groups and services on file, to protect against crashes. A client will be able to ask the registry to stop either a single running service, a group of running services, or all running services. The registry will only attempt to stop services that it started, so calling a stop method on a service that the registry only connects to will have no effect. A client will also be able to get information regarding a particular running service, a list of running services for a particular group, or the set of all running services organized by group. The new code for the interface would be as follows:

module CipresIDL_api1
{
   /*
      ...
   */


   struct Service
   {
      string serviceID;
      string groupID;
      string registryInstanceID;
      string ior;
      RegistryEntryInfo entry;
   };

   typedef sequence<Service> ServiceSeq;

   struct ServiceGroup;

   typedef sequence<ServiceGroup> ServiceGroupSeq;

   struct ServiceGroup
   {
      string groupID;
      string registryInstanceID;
      ServiceSeq services;
      ServiceGroupSeq subgroups;
   };

   interface Registry 
   {
      /*
         ...
      */


      Object getObject(in RegistryEntryInfo entry, in string groupID) raises(ApplicationException, NoRegistryMatchException, BadArgException);

      string createServiceGroup(in string label);

      void removeServiceGroup(in string groupID) raises(BadArgException);

      Service listService(in string serviceID) raises(BadArgException);

      ServiceGroup listServiceGroup(in string groupID) raises(BadArgException);

      ServiceGroupSeq listAllServices();

      void stopService(in string serviceID) raises(BadArgException);

      void stopServiceGroup(in string groupID) raises(BadArgException);

      void stopAllServices();
   };

};

-- PaulHoover - 10 May 2007