database - service - client : different scenarios and vability
- As going through the .NET Service, i was just thinking about different scenarios for utilizing the cloud.
Am listing the scenarios below, can anyone please tell me the viability for each one of them? and pros and cons (and/or difficulties) for each scenario ?
1. Using Azure only for database storage. Service as well as client will be on-premise.
2. Client on cloud and service on-premise.
3. .NET Service bus for hosting service (just like traditional web services) whereas client is on-premise.
4. Whole application is on cloud.
Is it possible for a service hosted in cloud to access on-premise database ?
~MANISH
All Replies
Hello, all those scenarios are valid. The choice usually depends on your existing investiments.
1. If you have already created the client/service applications, and they run well, but the database is the bottle neck of your solution, you can choose this option. You only need SQL Azure. For most solutions, the migration is merely create a new database on SQL Azure, importing the data, and modify the application connection strings.
2. If you have exsting services that runs well, but you want a more scalable server based web application (such as ASP.NET and WCF) as your client, you can choose this option. If your on-premise service already have a static IP address that is visible to internet, and it is not beyond a firewall, your cloud applications can directly invoke the service. Otherwise you will need to expose the on-premise service to the internet using .NET Services. This scenario works best for complex solutions, where some of the work must be done in the cloud, and others must be done on-premise. If you simply need a client application that is not run on-premise, I would suggest you to go with a client web application (such as Silverlight). You can host the Silverlight application in a very basic web server (only required to serve static files), and the actual work is done on the user's client machines.
3. While this is also a valid scenario, this approach is rarely taken. You can host a normal WCF service in Windows Azure in a web role (hosted in IIS), and your on-premise client will be able to work with the service. This will save you a lot of work. If for some reason, you really want to host a WCF service in a worker role, you can use .NET Services to expose it to your on-premise client.
4. Obviously this is a valid scenario. If you don't have any existing on-premise investiments, and you need a scalable solution, this is definitely the best choice.
5. You can work with an on-premise database if it has a static IP address that is visible to the internet, and the firewall allows any traffic. If not, you will need to create a WCF service or an ADO.NET Data Services that is hosted in your on-premise server, and then expose it to the internet using .NET Services.
Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
