Mihgt be worth your while to plug in some numbers and see where things are likely to break. Not too many variables in play. So let's go with the weather example, and assume a single client makes 50 requests and it takes 12s for the weather service to respond to each request. Let's also assume for now that the weather service is capable of responding to any volume of requests it receives simultaneously, just that it always takes 12s for each.
Scenario 1. Your original situation where the requests are synchronous. So 50 requests will take 600s or 10 minutes to complete. Practically zero performance impact on the client as it isn't doing anything most of the time. Same for XData. Just an unhappy user waiting for 10 minutes.
Scenario 2. Requests are asynchronous. So the client makes 50 calls to XData, which then makes 50 calls to the weather service and responds with each after 12s. Bit of a performance hit on the client as the requests are queued up, and then nohting while waiting for them to be completed. XData has to handle 50 incoming connections with 50 threads, and then 50 outbound connections. It is likely that this will work very well, as no limits are being tripped and the total time will be slightly more than 12s but probably well under 20s. In my adventures, round trip response times to XData involving a database query are typically less than 200ms, so not really a problem at all.
Scenario 3. Requests are asynchronous and batched together. So the client makes one call to XData. And XData makes 50 calls to the weather service. Might be marginally longer to respond due to the overhead of parsing the list of cities requested and combining the results in the response, but likely in the same ballpark as Scenario 2. But 1/50th of the overhead in terms of threads, CPU, TCP connections, memory, etc.
So then the question is about what is going to break if one of the key variables changes?
Say you have 1,000 users?
In Scenario 1, nothing really changes other than having 1,000 unhappy users instead of 1 unhapy user. I'm thinking XData can plow through 1,000 connections at a time without falling over unexpectedly. It might slow down a bit depending on its resources, but a modern server with a reasonable amount of RAM is probably going to be just fine here.
In Scenario 2, I think things are more problematic. 1,000 users each making 50 connections means more like 50,000 connections. That's probably going to be an unpleasant experience no matter how well equipped XData is and wil likely require multiple servers and a load balancing scheme. Always doable but suddenly much more difficult.
In Scenario 3, it's back to just 1,000 incoming XData requests, so likely not going to be a big problem. A bit more of a hit than Scenario 1, but manageable.
Say you have only 100 users but each makes 500 requests instead of 50?
In Scenario 1, well, hard to imagine a situation where a user would wait more than an hour and a half for data to update. Unlikely to be feasible.
In scenario 2, we're back to 50,000 connections again and bad news all around.
In scenario 3, we're only having to deal with 100 inbound connections to XData, so all should be ok.
Another consideration is where the bottleneck might be in terms of the network. If you've got high-powered desktop clients on the same LAN as the XData server, then not really a concern. Same if your clients are all happy broadband users in the same country as your XData server. But say you've got users in a foreign land using mobile devices on wireless networks?
Scenario 1 is probably fine, so long as the data coming back is relatively small. If it is returning satellite images in the weather data instead of just daily highs/lows, then this might not work so well.
Scenario 2 is not going to work so well as that may be making demands beyond the capabilities of their network connection, and likely many connections would be dropped.
Scenario 3 is probably just fine as well, with the same caveat about the data being small.
Lots to think about, maybe a little bit of measurement, but I think there are quite a few options available to you depending on your specific situation. Would be interested to know what you end up with at the end of the day, and maybe some numbers to show how you got there?