Or, when is performing request-response communication over an asynchronous channel a good idea? When is it not?

If system A needs to ask system B a question and get some data as a response it could do so in a variety of ways, some awful, others less so.

• Take a periodic database extract, transform and load
• Query the other system’s database on the fly
• Use RMI / Corba binary interop
• Send a message and wait for a reply
• Get some XML from a URL via HTTP

This list is not exhaustive, but represents a reasonable spread of mechanisms. Lets narrow it down to the two least awful.

First, any integration involving a database is right out. Coupling application databases together is extremely awful. Binary integration is bad for the same reason. These integration mechanisms are fragile and make the job of releasing both applications much harder, as well as making it hard to know if a change has broken the integration.

Moving on to the two remaining choices. Using messaging can work well if the requesting system can tolerate a large variation in latency and/or you need to scale by having multiple processes sending and receiving the messages. It is also very handy if you need to cope with one of the systems failing periodically as the messaging infrastructure can hold onto the messages when the systems are unavailable. The request-response semantics can be achieved by passing a correlation id around to track conversational state. The implementation is more complicated because you don’t really want the requestor sitting blocked waiting for a response that could take an unbounded amount of time to return (eg. if the responder is busy or down).

If the complexity of a message based approach is not justified then a simple web service (that is, XML and HTTP GET requests, no SOAP or other pointless nonsense) can work very well. As an added benefit, if some thought is put into how the URLs are designed it is a relatively simple matter to insert an HTTP proxy cache (such as Squid) into the flow. Sensible use of cache directives in the HTTP headers can allow even moderately fast changing data to be cached effectively without going stale. All without having to complexify the code that returns the XML.