Service Agents
Service Groups
When a service agent is created, the name of the service is notionally listed in a global group. In respect of this global group, unless you track the coming into existance of every single service agent, there is no way to make conclusions about a subset of services. Even if you do track the creation of every single service agent, the only way you might be able to distinguish a service agent as belonging to some group, is to introduce into the name of the service agent some form of artificial naming hierarchy.
Rather than rely on an artificial means of grouping service agents based on the service agent names, a separate concept of service groups is implemented. To add a service agent to a specific group, the "jo- inGroup()" member function can be called at any point after the Service base class has been in- itialised. That is, adding a service agent to a service group does not specifically have to been done in the constructor but can be done at a later time. To remove a service agent from a service group it has joined, the "leaveGroup()" member function can be called.
class EquipmentAgent(netsvc.Service): def __init__(self,name,audience="*"):
netsvc.Service.__init__(self,name,audience)
As with service names, it is recommended that you avoid using any form of whitespace or unprintable characters in service group names. The empty service group should also not be used to avoid confusion with the global group.
Service Registry
The service registry is where information about available services is recorded. Each process in a dis- tributed applicaton has its own service registry. The service registry in a process will list any services which are local to that process as well as any of which knowledge has been imported into the process from a remote process.
That each process has its own service registry means that the service agent framework can work quite happily within the context of a single process, as well as within the context of a distributed application. That is, when you only have a single process it isn’t necessary for that process to be connected to a central server for the system to work. In this respect, each service registry acts as a peer to other service registries and not in a client/server mode.
A further consequence of this is that even when a process is part of a distributed application and the central message exchange process is terminated, any processes which were connected to it are not forced to restart themselves. In this scenario, any interested parties would be notified of the fact that remote services are no longer accessible and would take any action as appropiate. When the central message process is restarted, processes would automatically reconnect, with interested parties being notified that the remote services are once more accessible.
40
