Python Manual Benutzerhandbuch

The major classes in the OSE C++ class library involved in providing this functionality are the

OTC_SVBroker

,

OTC_SVRegistry

and

OTC_EVAgent

classes along with various event classes.

In a distributed application the

OTC_Exchange

class comes into play along with the various classes

used to implement the interprocess communications mechanism.

When using the C++ class library, implementation of a service agent entails the use of a number of
different classes together. In the Python interface this has all been brought together in the

Service

class. If you wish to create your own instance of a service agent, you need only derive a class from the

Service

class and then instantiate it.

The most important aspect of creating a service agent is the need to assign it a name. This name is what
is used by other services to access your particular instance of a service agent. Having selected a name,
it should be supplied to the

Service

base class at the point of initialisation. If you wished to call your

service "

alarm-monitor

", the constructor of your class might look as follows.

class AlarmMonitor(netsvc.Service):

def __init__(self,name="alarm-monitor"):

netsvc.Service.__init__(self,name)

In general there is no restriction on what you can put in a service name. It is suggested though that you
avoid any form of whitespace or non printable characters so as to make debugging easier.

In assigning a name to a service agent, there is nothing to stop you from having more than one service
with the same name. Often the ability to have more than one service with the same name is useful, but
in other situations it may be regarded as an error. As a policy on how to handle more than one service
with the same name will be dependent on the actual application, implementation of any scheme to deal
with it is left up to the user.

If you want to query what the service name is for an instance of a service agent, it can be queried using
the "

serviceName()

" member function. If you need to know the unique identity of a service agent,

it can be queried using the "

agentIdentity()

" member function. Even when two services share

the same name, they will still have distinct agent identities. These as well as other details relating to a
service agent can also be obtained from the object returned by the "

serviceBinding()

" member

function.

Note that the

Service

class ultimately derives from the

Agent

class and as such all features of the

event system are also accessible from a service agent. The

Service

class also builds on the same

model used by the

Agent

class with respect to destruction of an object instance and the cleaning up

of circular references. As such the

Service

class contains a derived implementation of the "

de-

stroyReferences()

" member function found in the

Agent

class. Any derived service agent

should use this function in the same way as defined for the

Agent

class.