A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm still wondering how to design a service with a thick client (ie. more than just a web browser) and a database, for a mix of intranet and internet and stand-alone users.
* Is it possible (security-wise) to install a database such that it's exposed to the internet? Is there any database that supports this? Does any database engine have enough robustness? The advantage would be that the client software could then simply use database APIs (over the internet or intranet or locally). Or, is it always necessary to hide the database behind a web server?
* Alternatively, how can one design server-side software such that it can be used with (from the internet) or without (from the intranet or on a stand-alone machine) a web server? I think I understand the client side (e.g. it sends and receives XML, either via http to a web server or via any other transport to an app-specific service which interfaces to the database), but I don't understand the server-side. If on the server side, the "app-specific service which interfaces to the database" is usually run as a web server extension, how do you write or layer it so that it can also be run without a web server?
* Yes, it is possible to install a database such that it is presented to the Internet. I personally don't know of any off hand today, but several years ago, it was quite common to offer scientific metadata this way (and the actual data files were flat files fetched via ftp).
I think the predominant barriers to such practices are A) the user needs to know SQL and the database schema to some extent in order to get any use out of it and B) while a lot of information is available on optimizing databases, very little info is out there on securing databases on levels other than the tablespace. Given those constraints, the web server as an interface/firewall is an extremely attractive alternative.
* Strictly speaking, the database server doesn't care. It receives a request on a particular socket, and it responds to that request. From the database's perspective, there's no difference between a local request and one from the Internet. (The DBA can configure the database to only respond requests originating from a specified IP address range, but the actual response is the same regardless.)
However, the client software does need "database drivers" that allow it to format the request the way the database expects, and parse the response into a record set that you can work with. (Otherwise, it's basically a byte stream both ways, not XML or HTTP)
Most high programming languages (specifically Java, C, C++, C#, VB, ASP, PHP, Perl, Python and Ruby that I know of) offer libraries that include the necessary drivers and allow you to make connections directly to the database and submit queries or prepared statements, and receive a record set in response. These libraries are used regardless of whether you're formatting the output for the web browser or displaying it via a desktop application.
* There are some exceptions. We refer to them as Access style databases. They were usually bundled by the vendor as both a database and a front end, and as such, do not easily accomodate TCP/IP style connections. That said, there are drivers available but you will have to do a little more work setting everything up.
* In general the only problem you will have to deal with is checking for and gracefully failing if the database - for whatever reason - is not available.
Thursday, July 06, 2006
i have looked at this too, security is probably the biggest issue, whats to stop a hacker doing a brute force password attack on your open database connection, then they could trash the entire database
you could use things like vpn or zebedee to encrypt your database traffic, that way the user has to login to a vpn first, then initiate a database connection.
we found that things like citrix, remote desktop and vnc etc are much faster then database over vpn, especially when there is a lot of data involved plus you don't have the issue of making sure everyones software is uptodate with the database definitions.
> A) the user needs to know SQL
Right, but I was expecting the thick client software on the user's machine (and/or a server-side service sitting on top of the database) to do that: accept user input, know the database schema, create and emit SQL statements, post-process the results for display.
> very little info is out there on securing databases on levels other than the tablespace
Is that so? Like how about just using SSL etween the client and the database?
The reasons why I'm nervous about it are:
- This (web and database servers and security) isn't my expertise
- I've heard an IT guy say he won't even put IIS in a DMZ (it's too insecure), so I can only imagine what he'd think of putting a database server in a DMZ?
A section like http://dev.mysql.com/doc/refman/5.1/en/security-against-attack.html says "In any case, you should be very careful about creating grant table entries using hostname values that contain wildcards" as if MySQL (for example) isn't designed to be exposed to the internet. If MySQL is not, are there any database servers which *are* safe to expose?
One clue towards securing databases is, apparently, to use only stored procedures; but I think I'm not so worried about malicious authorised users as I am about unauthorized non-users.
> However, the client software does need "database drivers" ....
Yes I know about that kind of thing: that's the part I'm most familiar with.
> Given those constraints, the web server as an interface/firewall is an extremely attractive alternative.
It's certainly common. Do you have any thoughts then on how to layer the server-side implementation so that the useful bits of it can also be deployed (on an intranet and especially on an isolated workstation) without a web server in the middle?
The options I've gleaned from http://discuss.joelonsoftware.com/default.asp?design.4.352256.16 are:
* Code server-side logic as stored procedures in the database
* Don't consider PHP because it's only really ever run as part of a Web server
* Use Python or Perl because you can host them in client application: http://docs.python.org/ext/embedding.html or http://perldoc.perl.org/perlembed.html
* Write a server-side library in C or C++, callable from Web-embedded PHP (when run with a web server) or directly from the client (if run without a web server)
* Write a server-side libray in C#, callable from a web extension or (if there's no web server) directly from a C# client.
> whats to stop a hacker doing a brute force password attack on your open database connection
Equally what's to stop them from attacking your web server? Perhaps the server takes longer and longer to reply, or disables the account of the username being attacked, or begins to ignore that remote IP address.
> citrix, remote desktop and vnc etc are much faster then database over vpn
Wouldn't that depend on the characteristics of the data and the application: e.g. on the ratio of the data requested to the data displayed?
> plus you don't have the issue of making sure everyones software is uptodate with the database definitions
I want thick client software and an optional replica of the database on the end-user machine anyway, so that the user can work offline: that's the reason why I'm asking how to reuse server-side code when there's no web server in the middle.
Also, to give an example, I have an app that uses VB 6.0, SQL Server on a web server. I use an Access database for "off-line" viewing, which I export the data from the SQL server database. Users can use VPN to directly connect to the "production" database.
I soon plan to start writing some web pages to interface with the data. But as you can see this system is NOT exposed to the internet.
"Equally what's to stop them from attacking your web server? "
Web server companies know that their software will be under attack and are constantly fixing issues and vulnerabiities. Database companies do not expect you to put your database directly on the Internet so the vulnerabilites exposed when doing so get less attention. It's just not the common mode of operation for a database.
I would NEVER expose a database directly on the Internet. Wrap it up in web service calls. Use defense in depth...
Friday, July 07, 2006
A "web service" doesn't have to imply HTTP (i.e. "web") at all. In practice most do though because the alternative means a lot of wheel reinvention.
Still, you could build an application server that uses some ad-hoc protocol over TCP. Even use a relatively connectionless HTTP-like approach:
... or use moderate connection persistence.
Or you can use DCOM, DCOM over HTTP, CORBA, MSMQ, MQSeries, or other protocols if you have an application server in place that supports those.
But I still suspect the vast majority use a web server as an application server.
Friday, July 07, 2006
When you have a web server and a database server at the back-end, I think that you don't always have:
1) Code loaded as web server extension
2) Talking directly to the database server
Instead you sometimes have *3* layers at the back end:
1) Code loaded as web server extension
2) Talking to an out-of-process business logic application
3) Which interfaces to the database server
When there *are* 3 layers, what protocols are typically used between layers 1 and 2?
Also what term[s] should I use to Google for more information on this architecture? When I search for "application server" I find things like http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZopeArchitecture.stx ... so it seems that "application server" is something of a synonym for "web server" ... I'm finding it hard to discover something that tells me about the interface between a web server and a separate non-web application server.
Christopher, I think you're overthinking the entire issue.
There is a solution called the "model-view-controller" design pattern. In a nutshell, it recommends that you break up your code into a datasource layer, a logic processing layer and a presentation layer. In practice, it's never as simple as that, but it does help tremendously to organize your code along those lines.
The key benefit to this design pattern is that within any given layer, you can swap the components without having to recode the other layers. The classic example cited is that you can build your application using an Oracle database (as the data source), Java beans (as the logic) and HTML displayed in the web browser (as the presentation layer). When you're ready to switch to AJAX, you only have to transform the HTML; the Java beans code and the Oracle db stuff stay the same.
It sounds like this is what you're trying to do - you want to be able to swap presentation layer from thin client to thick client without having to recode your entire application.
If you can find a copy of it, I recommend you skim through Marty Hall's "Core Web Programming" ( http://www.corewebprogramming.com ), particularly the sections on programming with Servlets, JSP, Swing and Applets. He will literally demonstrate how you can have both a desktop application and a web browser connect to the same browser, with a minimum of redundant code.
(I'm emphasizing "skim" because if you're using something other than Java, you don't want to get bogged down in the details. I've taken his concepts and done this in VB and ASP quite easily.)
Monday, July 10, 2006
"...how you can have both a desktop application and a web browser connect to the same browser..."
That should be "connect to the same database." Sorry.
Monday, July 10, 2006
> He will literally demonstrate how you can have both a desktop application and a web browser connect to the same browser, with a minimum of redundant code.
Do both these scenarios connect via a web server, or does he explain how to run and interface to a controller layer that's deployed without a web server?
In the abstract, his scenarios connect to the controller layer without an intervening web server. However, I do admit that I phrased my answer that way is because one of his scenarios does implement an extremely bare bones web server to demonstrate that the data can be passed around via the HTTP protocol.
He also does offer techniques for doing it via Remote Procedure Calls (RPC), Remote Method Invokation (RMI) and SOAP that I remember. I'm sure the same thing can be done via COM objects but I wouldn't know how to do that off hand.
But to answer what I think is the real question: no, you do not have to install an actual web server product such as Apache or IIS if you don't want to; but you certainly can make it optional.
Tuesday, July 11, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz