The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Server-side architecture question

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?
Christopher Wells Send private email
Thursday, July 06, 2006
 
 
* 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.
TheDavid
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.
bumperbox Send private email
Friday, July 07, 2006
 
 
> 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.
Christopher Wells Send private email
Friday, July 07, 2006
 
 
> 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.
Christopher Wells Send private email
Friday, July 07, 2006
 
 
"Equally what's to stop them from attacking your web server? "

The last time I checked it was easier to hack a database the a server that's locked down tight.  An open database on the internet can expose more vulnerabilities.
J.B. Send private email
Friday, July 07, 2006
 
 
I would go with the VPN route if your app has allot of interaction with resources locally, or Citrix or RD if not.  Either way you can have your thick client.
J.B. Send private email
Friday, July 07, 2006
 
 
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.
J.B. Send private email
Friday, July 07, 2006
 
 
"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...
anon
Friday, July 07, 2006
 
 
+1 for web services.

Database performance will suck across an internet connection.
Mike S Send private email
Friday, July 07, 2006
 
 
> +1 for web services.

Can you implement a web service without there being a web server (e.g. if you want to install client and service on the same disconnected machine, or install it on an intranet)?
Christopher Wells Send private email
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:

connect
request
response
disconnect

... 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.
j. freling
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 Wells Send private email
Friday, July 07, 2006
 
 
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.)
TheDavid
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.
TheDavid
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?
Christopher Wells Send private email
Monday, July 10, 2006
 
 
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.
TheDavid
Tuesday, July 11, 2006
 
 
Thanks.
Christopher Wells Send private email
Wednesday, July 12, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz