What is one correct architecture when using a DB with multiple clients?

Question

We have a legacy system with data stored in a SQL database. Several clients connects to this database using a web service. The web service expose a lot of "commands" to query the database and to "do" operations.

So far, so good.

However, new operations need to be added and the web service cannot be extended. We can add a new service that would implement the operations from the old one (somewhat easy) and add our own operations.

At the same time we want to enhance the performance of the web service by having multiple requests bundled as one request (the responses would come out as a bundle too).

One desirable outcome would be to isolate the application from the web service using programming interfaces and a somewhat generic messaging (or whatever) mechanism.

We are contemplating several ways to effectively support multiple clients: enterprise service bus, a request/response service layer, ORM with client/server architecture...

Has anyone been confronted to such issues and what did you end up with?