Printable View
Hi all,
I need some suggestions on what technologies to use
i will be developing a desktop application in C# with SQL back end. software needs to be accessed from different locations. I know the best answer to this would be a web application, but i don't have the resources for it.
I found some fat client cloud hosting providers, but are really expensive. Has anyone tested running desktop apps with remote databases over TCP/IP ?
any other suggestions
Thanks
Create a web service. The web service then talks to the database as local and the Windows application makes calls to the web service. Even web applications of any significant size often do the very same thing, so the web site actually talks to a web service that talks to the database rather than the web site talking to the database directly.
The first question would be how many users and how would you best consider getting them access to the remote IP address?
Will you have a VPN setup for the users? That is probably the most secure.
That question needs to be answered first before you craft a web service API for consumption by the client.
I think what was proposed in post #1 was to continue to write monolithic desktop applications using some sort of Remote Desktop technology. There just isn't any path available to make such things practical, and this is why you won't find it available cheaply: supply and demand.
Writing a "web application" was rejected for "resource" reasons. We'd have to know what "resources" is standing in for here... but I suspect we're really talking about skills and experience.
"Web" in the generic sense buys you three things:
- HTTP and HTTPS are firewall-friendly, partially by design but mostly by accident. Most ISPs and firewall admins cannot block these and can't even really do much to them at the proxy level without wreaking chaos.
- HTTPS gets you fairly cheap and easy traffic encryption.
- The explosion in use, even though mainly for trivial purposes, means the economics of demand lead to significant competition which has driven down hosting prices. If you are willing to settle for a heavily sandboxed LAMP stack things can't get much cheaper.
As already mentioned above, "web" in the broad sense does not imply the limitations and clunkiness of a web browser front-end or the constraints of that concoction called JavaScript. You can easily front-end web services with real code doing real things at the client side.
Of course the reality is that most applications boil down to CRUD, and once you've moved anything data-centric close to the data such applications have very little left but presentation to implement on the client. Once your client is that thin it may as well be script and markup in a browser. The death of SilverLight meant the death of C# in the browser. If you want cheap you're looking at LAMP, so both C# and SQL Server are off the table there too.
Changing any of this changes the economics. You can find ASP.Net/SQL Server hosting, but it will never be as cheap as LAMP or even WAMP. The next step up in cost is probably Node.js hosting even on Azure these days. If you change the client from browser script and markup to anything else the cost increases because browser scripting is the cheapest skill on the planet today.
As I already said, unless you can do enough work at the client side to make performance and flexibility matter... even if you have C# programmers working for free it doesn't buy you much. But if the client development cost doesn't matter then sure, go ahead and build a C# client.
Using sophisticated client logic only makes sense when the common datastore is relatively low-usage. That can still be a ton of application domains. For example nobody in his right mind writes browser apps for mobile: by their nature they consume too much scarce, slow, and expensive bandwidth. These do as much as they can on the client, relying on hosted services merely for things like notifications, low-volume data access to resources impractical to hold on the device, and posting results and state data.
But nobody really considers mobile devices to be CRUD data entry platforms anyway.
At this stage it is 5 to 10 users but may increase in the future. Won't be using a VPN, i have been doinf some research and most likely to go with Azure database. my only concern isQuote:
Originally Posted by szlamany
it requires client IP to be whitelisted in the firewall settings, what means the list needs to be updated whenver the client IP changes
By resources i meant expertise, time and budget. I like @jmcilhinney idea of having a service to communicate data between client app and database
I'm not sure what Azure really brings to the table. You can probably find a cheaper option for database hosting even if you insist on using SQL Server.
But any scheme that is going to support monolithic coding will run into the issues of performance, reliability, and of security and visibility (your "whitelisting" of IP addresses for firewall penetration).
This is where web services came from: the idea was to replace robust high-performance protocols such as DCOM to interconnect n-tier applications with the good-enough, firewall-friendly, and more Internet-safe HTTP protocol. But before you can use HTTP you have to move away from monolithic design by moving as much data access and business logic as possible as close to the DBMS as possible.
That doesn't mean you clients can't still do a lot of crunching, but that's usually a special case. If you have a central DBMS than most likely your application is... data centric. The more you need to work against that central database the thinner your client tends to get.
All my web services run over SSL/HTTPS - security still has to be considered if the data is in any way sensitive.
Depends on what you're looking for... Azure gives you the ability to upscale and downscale on demand... with replication to multiple datacenters, allowing clients to be able to connect to the nearest center for performance... Google offers this kind of support as does Amazon Data Services ... not many others do... We currently support the use of the Amazon services for our product... a few are using Azure, but mostly for testing, and because our MSDN subscription gives use free azure services on a limited basis. But if in the future we think we can get more bang for the buck from Azure than we can from Amazon... eh, we'll move things over, tweak a couple of configuration items and our clients wouldn't notice the difference (except maybe for a short planned maintenance "outage.")Quote:
Originally Posted by dilettante
It's that ease of scalability where ADS and Azure (and the google offering, the name of which escapes me) really shine...
-tg
The security achieved by simply using HTTPS vs. HTTP is wildly overstated unless you are issuing and using client certificates. Since it costs you little but performance though, blind usage is probably a no-brainer in most cases. At least you can pretend you are "secure."
Cloud database hosting doesn't offer scalibility "for free" though, and requires a bit of effort to achieve, see:
Elastic Database features overview
You can usually get usage-based pricing with little effort.
Moving workload into the cloud front-ended by a web service (or the degenerate case of dumb client, i.e. browser-based application) is a well-known, simple request/response scenario that is far easier to provide simple scaling for. But this isn't "zero effort" either since you have to cope with multiple instances that won't always be synchronized.
Most usage of Azure is single-instance just to avoid dealing with the complexity. At that point scaling has been tossed out the window.
blind usage - no brainer - pretend... Word choices matter - you sound like you are smacking us over the head with this information.Quote:
Originally Posted by dilettante
Web service security is important. I issue a GUID upon initial successful credential validation and then use that GUID in every subsequent web service call. It's validated against a pool of known current logged in GUID's and if not found or timed out we refuse the service.
All of this done HTTPS so no data in clear text to be reviewed by bad guys.
It passed a HIPAA level security review by an outside firm that one of my clients hired - I feel good about what I've done for security.
No brainless, blind or pretend stuff going on here...
The point is that unless you really think you are a "hot" enough or critical enough target like a bank or a major service provider the odds anyone is going to try to tap into the Internet backbone or even sniff your WiFi traffic are very, very small. So HTTPS doesn't really buy you much.
If you have a regulatory requirement to use HTTPS it is another matter and sure, you'd use HTTPS as a matter of course. It still rarely matters in reality, but why take a chance? Thus a "no brainer."
I saw nothing in the OP's requirements to suggest the overhead is warranted though, and choosing HTTPS doesn't help solve his problem at all. After he has his problem solved he can always adopt the extra resource consumption of HTTPS trivially later on.