I searched on the web how to access in an efficient manner to a central database at a remote location and I met suggestions to use web services instead direct access (i.e. JDBC etc ) to a database.I wonder the reason of that and any other suggestions.


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.

  • 1
    "both in terms of the required CPU power and the bandwidth used during the processing" was the keypoint I was looking for.Thanks – yesildal Oct 18 '12 at 20:36
  • 4
    Also, if your app directly communicates with the database, you are just a reverse-compiler away from someone dropping every table in your database. With a web-app, you can use much more fine-grained control and stop things like that – Earlz Oct 18 '12 at 20:49
  • 1
    @Earlz: not that I'd ever willingly do it for a webapp, but most database servers do have rather solid and fine grained permissions. No excuse for a web user with drop table permissions. – Wyatt Barnett Oct 18 '12 at 21:49
  • 1
    @WyattBarnett ok... without stored procedures and the like, how would you allow a user to update their user-profile? read/write permission to the USERS table... What'd stop them from delete or editing rows that aren't theirs.. or even reading rows that aren't theirs. I'm pretty sure no database server has this kind of fine-grain without using stored procedures or some such – Earlz Oct 19 '12 at 13:37
  • @Earlz -- not any that I am aware of, but that is besides the point -- why are you going to talk directly to your database and deliberately ignore database features to make that sane? And would you do something profile-centric and update heavy this way? – Wyatt Barnett Oct 19 '12 at 17:55

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.
  • 1
    Another advantage is it allows you to add a cache, either client-side or server-side (or both, for different purposes). – TMN Oct 18 '12 at 20:20
  • @TMN - Good point! – System Down Oct 18 '12 at 20:23
  • Ok but these facts are valid for any kind of web applications too,aren't they?Does Inserting a layer (web services) increase a response time for a mobile app which is expected to response quickly ? – yesildal Oct 18 '12 at 20:28
  • 1
    @yesildal - Yes they are still valid. In fact, they are valid for all types of application. However, in web apps you don't have to stick to using web services and can simply just isolate these functions into their own assembly (for instance). The reason for using web services for remote apps (such as phone apps) is that the DB server isn't in close proximity. – System Down Oct 18 '12 at 20:31
  • @yesildal - re performance: not really, if you have 1 user then yes, there will be an extra delay in returning the result, but if you have a million users things are different, and splitting the code up into 2 servers can make the overall performance faster. – gbjbaanb Oct 18 '12 at 20:45

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.