Adding a web service layer gives you an opportunity to make your client more lightweight, both in terms of the required CPU power and the bandwidth used during the processing. Both factors are extremely important to end-users:

• Using less CPU increases the battery life,
• Using less bandwidth reduces monthly payments for users with metered plans

By introducing a web application layer you move the bulk of the processing from a hand-held mobile low-power, low bandwidth, low-memory client to a plugged-in, high-power high-bandwidth, server that has more memory than it needs – an environment where processing and communications cost a fraction of what they cost on a client.

But wait, there is something in it for you as well: by splitting the system you get more control over your business rules, the structure of your database, and the versions of what’s out there. Once you let a mobile client connect directly to the database, your design is “married” to that database structure: almost any change would break backward compatibility to a client that may be reluctant to upgrade his app.

In contrast, adding a web service in between lets you evolve the interface to mobile clients in more manageable ways: for example, you could keep the old interface in place, add a new one that works “in parallel” with it, and then entirely restructure your database without breaking a single client.

If you follow some pretty basic design principles while designing your web service, you could also get significant benefits by reusing mature server-side infrastructure that has been put in place: for example, you can get cache and proxy services for free.

Finally, this will open the door to other developers exposing your application to platforms that you could not service yourself, ultimately playing to your company’s advantage.

It puts a layer of abstraction between the app and the DB. This gives you a lot of advantages such as:

• Limiting access to the DB to only the parts that the app needs. This both simplifies the app’s code, and keeps your DB secure.
• Asbstracts the inner working of the DB, so if you decided later on to change your schema, queries, or even your whole database the link to your app is not broken as long as you maintain the middle layer correctly.
• It allows you to add functionality outside the scope of a DB. Caching data that is fairly constant for instance. Business rules are another part that should be apart from the DB.

One other reason not to expose the DB directly — transport. Most relational databases, the kinds of things one talks to with JDBC, are not designed for the public internet in general. Wireless internet is a horribly unreliable end of said public internet. Exception handling would be nightmarish and you’d probably end up writing the reverse of the web services layer inside your app to avoid losing transactions.

There are some newer sorts of databases that do speak HTTP and might be suitable for this sort of thing. They also tend to feature ways to put application code of sorts in the database. You might want to look out CouchDb or RavenDb — both are document dbs with map/reduce capabilities that work over json and http, much like many modern web services.