Implementing a callback in XML-RPC or SOAP

Question

I am trying to get an understanding of how I can use SOAP or XML-RPC to create a remote, open API for my product. Problem is, part of my API will require me to be able to get ev

Answer 1

There are two ways to do notifications in an RPC system: the push model, and the pull model. In the pull model, the client will periodically query the server whether any notifications are available. The server needs to store them until the client fetches them (or until they expire). As a variant, the client may have a blocking RPC call that blocks until the next event becomes available, and then returns right away. That works fine with CORBA, but doesn't work so well with SOAP or XML-RPC, since the HTTP implementations are typically not prepared to leave a connection open for hours.

In the push model, the producer will invoke an RPC on the consumer, making the consumer a server. That doesn't work too well with SOAP or XML-RPC, either, since the client is typically not prepared to take the server role, and firewalls may prevent the callback from getting through. So the periodic pull is about the most realistic approach.

P.S. you may have noticed that I didn't follow your terminology: you cannot push events. An event is something that happens. You can only push the notification, which is an information that an event did happen.

Answer 2

Ok, eventually the decision made was to deal with callbacks as APIs that don't return immediately.

Basically, an RPC-XML request will be sent, asking to be notified on a given list of events. Our server would wait until one of the events happen and then report it back as a response or timeout after a set amount of time, notifying that nothing happened. The caller will be able to try and send the request over again to continue waiting.

Answer 3

You can do this with WCF. However, I don't know whether you can do it in an interoperable manner. Look into Duplex Services.