Handling a Response
for binding in bindings:
service = self.serviceEndPoint(binding) if service:
service.reset()
Handling a Response
When you send a service request, you do not get an immediate response back. That is, the call is asyn- chronous. If you want to be able to capture any response generated from a request, you need to capture the conversation id associated with the request and then register a callback to handle the response. The conversation id is the value returned when you make the call against the service endpoint object. Hav- ing obtained the conversation id you must then register a callback to handle the response using the member function "processResponse()". If you also want to be notified that the request has failed, you will also need to set up a separate callback using the "processFailure()" member function.
class Client(netsvc.Service): def __init__(self,name):
netsvc.Service.__init__(self,"","") service = self.serviceEndPoint("SMS") if service:
id = service.uptime() self.processReponse(self.uptimeResponse,id) self.processFailure(self.uptimeFailure,id)
def uptimeResponse(self,result): print result
def uptimeFailure(self): print "failure"
The callbacks which you put in place to handle the result and/or failure will be automatically deregis- tered when a response is received. This will be the case whether the response is valid or was a failure indication. Prior to having received a response, if you decide you are no longer interested in the re- sponse, you can call the member function "ignoreResponse()" supplying the conversation id. If you are submitting multiple requests in one go, you must call the "processResponse()" and/or "processFailure()" member functions for a conversation id before you send any subsequent re- quest.
Note that prior to the release of OSE 7.0pl5, instead of using the "processResponse()" and
"processFailure()" member functions, one would use the "monitorResponse()" method. This method in effect combined the operation of both of the new methods albeit it with subtle differ- ences as far as the arguments the callback would be passed and the functionality it implemented. Using the new methods it is possible to register separate callbacks for handling of the result versus a failure. It is even possible to only register interest in one or the other of the result or a failure notification. The "monitorResponse()" member function should as a result now be viewed as deprecated and should not be used.
59
