As a client, I think you can hack your way to a workable solution for some of these things, but as a component OACS/AOLserver would be part of the Jabber server, or maybe would use the Jabber server as it's dog for all the routing stuff. As a component, the Jabber server would see the OACS as: a user database, a content library, an email conduit, a blog, only depending on the programming done in OACS/AOLserver. The truth is the Jabber community is very good with the plumbing, and IM, but not too tuned in to the http type applications most of us are used to: bigger, fatter and not necessarily human attended. The one painful application I saw, which introduced me to Jabber in August, I think it was a survey bot, could probably be done with simple survey with a little hacking. The example I saw was never finished, so difficult to use is the perl library for anything beyond chat.
One thing to note also, is my module gives a great example of using one client connection that de-multiplexes into OACS with the dqd threadpool module so that database activity doesn't slow things down. So you end up with one thread in, many execution threads, and one thread back out. Another interesting feature I discovered is the ability to inject (like internal redirect) packets into the stream, to skip from one 'url' to another. I also experimented using the thread tag as a url. All of this would have been painful, I believe, except for the fact of AOLserver/Tcl. Anyway, having two OACS/AOLserver setups would allow using some kind of specialized namespaces to transfer data. One thing to note is that jabber packet size maxes out at at most 500k, but again a namespace might be developed to allow message disassembly/reassembly.