views:

895

answers:

4

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 events pushed from my server to the client - I will need to be able to "send a callback" and not only "call a function" as part of my API. Is there a good way to do that in SOAP or XML-RPC?

+1  A: 

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.

Martin v. Löwis
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
A: 

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

John Saunders
+1  A: 

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.

Tsahi Levent-Levi
A: 

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

Roger