Implementing a callback in XML-RPC or SOAP?

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.

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.

This means that essentially I am left with periodic updates, which is somewhat wasteful in terms of resources. Thanks for the answer – Tsahi Levent-Levi Aug 21 '09 at 4:10.

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.

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

I have just completed writing a middleware solution that allows client to register callbacks and data providers can either notify us of an update or we can poll the provider and only notify the client when needed rather than the client having to poll. If this is something you would be interested in working with us on I would be happy to talk to you. You can email me at: rogsmith at gmail dot com.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.