This is not an architecture problem. It's either a design problem or a management problem.
Why can you not add new operations to the web service? That is one of the principal benefits of having a web service. Adding a new operation is a guaranteed non-breaking change. So either there is some misguided policy explicitly preventing you from doing it (management problem), a technical barrier to doing it (e.g. no privileges to redeploy - different kind of management problem), or you've somehow managed to rev-lock your client applications (serious design problem).
The architecture is fine. There is nothing you need to change in order support this type of extensibility. If you can't make changes to the web service that's there, then wrap it with one that you can change and start using that one from now on.
Multiple requests are, again, a design issue. Specifically, it's a message design issue. You ordinarily do not attempt to architect your entire system so as to literally be sending multiple simultaneous requests. Instead, you design your web services around the "chunky interface" concept, as opposed to the RPC-style "chatty" interface.
Simply put, a chunky interface means that you expose coarse, user-level units of work as operations. Your service contracts should not look like "method calls", they should look like activities. For example, instead of having many different (chatty) operations to change a single customer's phone number, mailing address, e-mail address, etc., you design one (chunky) CustomerUpdateRequest contract that accepts a sequence of customers and performs all of the updates therein.
When you design your messages this way, you should never need to worry about something like bundling multiple requests, because it wouldn't make any logical sense to do so. You're not going to bundle a customer-update request with a shipping request because there is no reason for those requests to ever come in at exactly the same time.
I cannot see any practical purpose in attempting to "isolate the application from the web service" - the web service is your isolation, from library dependencies, platform dependencies, revision dependencies, etc. An orchestration engine or service bus can provide a higher level of abstraction, but that doesn't remove the dependency on contracts, just endpoints. And unless you're prepared to do some serious re-architecting (we are talking about, for example, rewriting every application and service to use pub/sub and other asynchronous messaging patterns), then there's going to be no benefit.
You already have everything you need in place to support multiple clients. What you need is a better deployment process, a clearer upgrade path, and messaging contracts that are more appropriate to an SOA. For scaling, if one web service can't handle the load, then use a load balancer - your web services should be stateless anyway.
If your architecture's become really big - and I mean enormous, to the point where your database and services are hyper-optimized but there are just too many transactions happening per second to keep up - then you might consider implementing Command-Query Separation. But don't start down that path unless you're prepared to see it through to the end, because you won't see most of the benefits until you have completely isolated the queries from the commands.
