Service Agents
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.
Service Naming
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
class AlarmMonitor(netsvc.Service):
def
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.
38
