Python Manual Benutzerhandbuch

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)

self.joinGroup("equipment-agents")

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.

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.