I am developing an application on Titanium Alloy that has connectivity to database located at windows azure. I want to know:
Let me start by saying I'm not familiar with Titanium Alloy, but I see that it is a mobile development framework. I'll answer this as I would for any mobile solution that would want to hit the Storage services.
One - You can get at the data in Azure storage without a web service serving as a proxy; however, this has some drawbacks to it which I'll touch on below. You can certainly hit the REST API direct for anything you need from anything that can speak HTTPS and interpret the results.
Two - The issue with going direct to the REST API for Table Storage, Queues and private BLOB containers is that the caller has to have credentials to get at the data. Storage accounts have only one type of credential, and that is the account key and account name. There isn't currently fine grained control over different services or aspects of the services, so this means that anyone with these credentials can do anything they want to your data in that account short of deleting the account (though they can certainly delete the data within the account, or even replace your data with their entire ripped Movie collection). So, if you include your credentials in your mobile client code they are exposed and that's definitely not recommended.
An option to this is to use Shared Access Signatures (SAS). An SAS offers generates a URL that is signed with the credentials and can be valid for a certain period of time. The issue here is that you would need something to generate the SAS urls for the clients, which means you'll have a web service somewhere. However, you could reduce the amount of times the web service is hit because the SAS would generate and be used for some period of time before you would need to hit the service again to get another one.
I'll caution this approach with the idea that the URL generated by for a SAS is just a URL. Anyone with this URL has the ability to do whatever rights were assigned to the SAS when it was created. Granted, if you are making these calls HTTPS (and you should be) then the signature portion is encrypted; however, be aware that man in the middle attacks could actually still occur. To deal with this people often really scope the SAS expiration time to seconds or minutes, but then at that point, depending on your load, you may be just as well to route everything through your web service anyway and be that much more comfortable that authentication is occurring. For example, if you have very little load or time between queries is longer than you want the SAS to remain valid this may not be a good fit. I've seen this "valet key" pattern used to great success so don't take my caution as a sign it's a bad idea, you just need to be aware of what it means to use them.
Three - If you can offload some of the processing to other servers then that's great. Security wise you are going to be more secure to go through your web service which is handling authentication (either directly or through identity providers). You'll control all access to your system that way. Performance wise, if you are then turning around and calling off to the Table Storage you'll see a hit because there are multiple hops in place. This can be mitigated some with caching at your service level (which is a completely different topic).
One option you may want to look at is using Azure Mobile Services. This provides a back end for you. By default it uses SQL Database, but with the new Custom API feature you can go off and do whatever you need to from the node script, including hitting the table storage APIs (see this post by Chris Risner for examples). This approach would remove your need for a web service that you run since the Mobile Services would serve that role, but you'll want to be aware of the pricing model and do some comparisons based on your own scenario.
