Stand alone web server vs Apache/IIS

I'm developing a rather complex application with both win32 and web access. Server side implementation is custom, and it's going to be hosted in our company. The HTTP server could be implemented as a stand alone Indy (or another) HTTP server or more traditionally with Apache/IIS.

I'd like to know what are the advantages/disadvanta开发者_JS百科ges of stand alone HTTP server vs Apache/IIS, in terms of security or anything else you consider relevant.

I would say it depends on your needs and expectations. It is a big difference if you are writing a custom plain http server with maybe even ISAPI support etc..., or you are writing highly specialized http server / proxy / etc... that does only narrow specialized tasks. For instance I have such specialized proxy and a specialized ISAPI module handling framework. There are not so few advantages I would say. So pros are:

1. Ease of deployment. Try to deploy apache with your application to each and every machine
2. Better performance, smaller memory footprint. Try to use apache on low end laptops
3. Better security. Because you do only narrow tasks, chances of breach are a lot smaller. Apache does it all so chances of breach are a lot higher.
4. Complete control over the workings of such server and control over code. If you need slightly different behavior or new features, you got it.
5. If you are running ISAPI modules as I do, you can sandbox them in separate processes and achieve better stability. If one module / request crashes, the others are not hurt.

The cons:

1. Writing yet another http server
2. Learning the protocols and inner workings from zero
3. Way higher number of bugs and higher chances of errors because code is not yet battle hardened. This needs time to settle in.
4. Because you have narrow focus, you are not so versatile as Apache for comparison. Not necessarily bad as stated earlier.

My verdict would be like this. If you just need a plain http server for serving some content and you will host that in house, on one or few servers, go for Apache. If you are making a specialized http handling piece of code, that will be installed a lot and you need control, then develop your own. Trust me it is worth the time. I am so glad now, that I stuck to this back then, when we were deciding the very same thing. Now I have a lot of laptop installations of the software which is quite complex and I cannot imagine having to install Apache on each and every laptop. And then configuring it to work as I need it to.

And Indy (with all its troubles and quirks) has proven to be a very stable out of the box web server. ICS is the same here probably, but I haven't used it yet for this so I cannot say. Setting up Indy HTTP server is ridiculously easy.

Just my two cents ;)

By "stand alone web server" do you mean embedded in your application? I've never used Indy, but I have worked on several Java apps using the Jetty library. The main advantages of this over an Apache/IIS proxy to an app server are easier deployment and configuration since the web service is tightly integrated into the app with nothing extra to install.

If you have existing apps though, and this new app is permitted to be deployed to the same environment, I'm pretty sure your sys admins will want you to use the existing app server. Nobody likes extra operational complexity even if it's slightly easier for you to build. Adding another app to an app server is trivial.

Other considerations are:

Security: Network config, log files, access controls, etc. will all have different implementations from your Apache/IIS systems and different usually means worse security. Simple things like SSL authentication that your sys admins understand with Apache/IIS will work differently with an embedded web server.

Performance: The embedded server is probably a little more efficient, but a little less scalable. Your coding decisions greatly impact this and with embedded servers it's easy to screw it up.

Development: I find embedded servers much easier to work on since I can run them as simple Java apps instead of web apps, e.g. an Eclipse Java view instead of J2EE view with Tomcat integration.

I know this is answer is from a Java viewpoint, but I hope the general ideas apply to Delphi.

IIS and Apache are well understood http servers.

The only advantage of having your own http server is to simplify deployment which is probably not going to be an advantage assuming that server-side portion of your application is going to be exclusively hosted in your company.

Another advantage can be performance, you could achieve higher throughput and better response times with custom made http server. But other than ease of deployment and performance, I can't see any other advantage.

There are plenty of disadvantages though

• you are writing code that has been already written
• you will need to justify and explain new developers why IIS and Apache wasn't suitable
• you will need to document and train others how to use such a http server. for example new developers are expected to know how to setup SSL certificate or GZIP compression on IIS/Apache, however they will have to learn from you how to do it in your http server and whether it's supported feature at all
• if this is your first http server to write, you will need to spend lot of time on learning and studying various standards and conventions that are outside of your primary business domain which your application really targets.

I generally develop as a stand alone so I get a better debugging experience, and then deploy as an ISAPI dll.

I have had several occasions where I wondered about this also.

I also have been working on some IInternetProtocol implementations, to enable Internet Explorer to work with alternative URL schema's.

So I started an open source project some time ago: http://xxm.sourceforge.net/

It enables you to switch freely between an ISAPI extension, a stand-alone server, and perhaps more later. (An Apache module and a Firefox protocol handler are in the making.)

Delphi code and HTML are combined into the same source-files much like other web-scripting languages, but uses the (fast) Delphi compiler to build the libraries used to run the website.

I have written several application that implement the Indy HTTP Stack and provide web services. This can be both easy and complex. The complexity comes when you start working with threads as you need to be aware of how Indy creates threads for HTTP requests. So integrating it with your server code may require some thought, especially if the server is connecting to a data source or common controls of some type.

Also, you need to manage all the security, access to files, and almost everything else a regular web server will do yourself. Here's where you may come unstuck because there are limited examples for Indy.

Having said that, I've found the Indy 10 HTTP Server to be robust and works very well if you are targeting specific requirements, such as just serving up XML based on something your app is doing. You have complete control over what the server is doing and you can opt for different deployment models - Windows Service, Stand-Alone App, etc...

If you have a well designed thread-safe app then implementing HTTP on top of it can be as simple as dropping the Indy HTTP Server component onto a form or unit. No need to duplicate any code just for the web stuff.

I always focus on ISAPI and use IDDebugger for debugging this process. This gives you the best of both worlds, your debugging against the same version you ultimately deploy. Unfortunately I don't develop for Apache so can't speak to its ease of development.

Since I use this method, I never have to worry about changes between the standalone and ISAPI versions not being synced, and can easily drop a customers version into my test environment to duplicate any specific behavior and then test against that behavior with a fix and be absolutely sure that it will work when deployed in the field.

There are way too many things to worry about to even consider using a standalone web server facing the internet. Its far better to put that worry (and many years of experience) into the hands of IIS/Apache.