Web servers and web hosting for mobile client/server application

I would like to build a mobile application with the following requirements:

• The mobile client applications should request and recieve data from a database on a server.
• In the future I will probably want to build a web application for the same database.
• For communication between the clients and the server I would like to use Google Protocol Buffers.

So I have the following questions:

1. How does one set up a server to take request and respond with anything other than html. I think that using RPC sounds nice, but开发者_StackOverflow社区 I have no clue how to set it up on a server.
2. I need to find a good web hosting service which will allow me to set up a database and a server that can serve both Google Protocol Buffers and regular web pages with data.
3. Before I get to making the web app, is there any more lightweight solution that might be better just for communicating with the clients (maybe even a home made tiny server), and how hard would it be to do it with a full scale web server from the start?

Please point me in the right direction so I know what to read up on. I'm not necessarily looking for specific names of web hosting services but rather an idea what kind of services are available that might meet my needs. I've worked a little bit with django, Spring and Java EE so if there's any solution involving those that would be great, however I'm not afraid of learning something new.

Thanks in advance

Simon

1. if you still mean http, that is pretty trivial - you simply set an appropriate content-type, and write your data to the response stream. The exact how depends on your web framework and tools, but this is no different to (say) serving generated images on the fly. HTTP requests function fine for messaging scenarios - as simple as making an http request (typically POST) with a protobuf (etc) body, and processing the response in the same way.

2. can't comment

3. a web app can be lightweight; certainly more-so than having to configure a non-http service/daemon. The "lightweight" option would be raw sockets, but that is harder to deploy, and you'll have to be more picky choosing a host. Unless you absolutely need this level of terseness (i.e. dropping the http headers and writing your own transport to get close to the wire), just stick with http - it'll be a lot easier to get going and maintain

For info, I have a blog post on doing this with ASP.NET MVC; this isn't intended to mean "do this" (heck, use whatever tools help you) - simply, it is meant to show the kind of thing necessary.