What is the difference between application server and web server?

What is the difference between application server and web server? - webserver

What is the difference between application server and web server?

Most of the times these terms Web Server and Application server are used interchangeably.
Following are some of the key differences in features of Web Server and Application Server:
Web Server is designed to serve HTTP Content. App Server can also serve HTTP Content but is not limited to just HTTP. It can be provided other protocol support such as RMI/RPC
Web Server is mostly designed to serve static content, though most Web Servers have plugins to support scripting languages like Perl, PHP, ASP, JSP etc. through which these servers can generate dynamic HTTP content.
Most of the application servers have Web Server as integral part of them, that means App Server can do whatever Web Server is capable of. Additionally App Server have components and features to support Application level services such as Connection Pooling, Object Pooling, Transaction Support, Messaging services etc.
As web servers are well suited for static content and app servers for dynamic content, most of the production environments have web server acting as reverse proxy to app server. That means while servicing a page request, static contents (such as images/Static HTML) are served by web server that interprets the request. Using some kind of filtering technique (mostly extension of requested resource) web server identifies dynamic content request and transparently forwards to app server
Example of such configuration is Apache Tomcat HTTP Server and Oracle (formerly BEA) WebLogic Server. Apache Tomcat HTTP Server is Web Server and Oracle WebLogic is Application Server.
In some cases the servers are tightly integrated such as IIS and .NET Runtime. IIS is web server. When equipped with .NET runtime environment, IIS is capable of providing application services.

This is a detailed answer with some scenarios to clearly understand the difference and similarity, and how both can work in conjunction.
Application Server is a term that sometimes is mixed with a web server. While a web server handles mainly HTTP protocols, the application server deals with several different protocols, including, but not limited, to HTTP.
The Web server's main job is to display the site content and the application server is in charge of the logic, the interaction between the user and the displayed content. The application server is working in conjunction with the web server, where one displays and the other one interacts.
The information traveling back and forth between the server and its client is not restricted to simple display markup, but to interaction between the two.
In most cases, the server creates this interaction through a component API, such as J2EE (Java 2 Platform), EJB (Enterprise JavaBean) and other different application software models.
An example:
The best way to understand the difference between the scenarios where an application server works with the web server versus a scenario where there isn't an application server is through an online store.
Scenario 1: Web server without an application server
you have an online store with only a web server and no application server. The site will provide a display where you can choose a product from. When you submit a query, the site performs a lookup and returns an HTML result back to its client. The web server sends your query directly to the database server (be patient, I will explain this one in our next nugget) and waits for a response. Once received, the web server formulates the response into an HTML file and sends it to your web browser. This back and forth communication between the server and database server happens every time a query is run.
Scenario 2: Web server with an application server
if the query you want to run has already been done previously and no data has changed since then, the server will generate the results without having to send the request to the database server. This allows a real-time query where a second client can access the same info and receive real time, reliable information without sending another duplicate query to the database server. The server basically acts as an intermediate between the database server and the web server. This allows the information pulled to be reusable while in the first scenario, since this info is embedded in a particular and "customized" HTML page, this is not a reusable process. A second client will have to request the info again and receive another HTML embedded page with the info requested -highly inefficient. Not to mention that this type of server is very flexible due to its ability to manage its own resources, including security, transaction processing, messaging and resource pooling.
To support such a variety of complex tasks this server must have a built in redundancy, great processing power and high amount of RAM to handle all the data it's pulling in real time.

Both terms are very generic, one containing the other one and vice versa in some cases.
Web server: serves content to the web using http protocol.
Application server: hosts and exposes business logic and processes.
I think that the main point is that the web server exposes everything through the http protocol, while the application server is not restricted to it.
That said, in many scenarios you will find that the web server is being used to create the front-end of the application server, that is, it exposes a set of web pages that allow the user to interact with the business rules found into the application server.

Web server
Run python -m 'SimpleHTTPServer' and go to http://localhost:8080. What you see is a web server at its workings. The server simply serves files over HTTP stored on your computer. The key point is that all this is done on top of the HTTP protocol. There also exist FTP servers for example which do exactly the same thing (serving stored files) but on top of a different protocol.
Application server
Say we have a tiny application like below (snippet from Flask).
#app.route('/')
def homepage():
return '<html>My homepage</html>'
#app.route('/about')
def about():
return '<html>My name is John</html>'
The small example program maps the URL / to the function homepage() and the /about to the function about().
To run this code we need an application server (e.g. Gunicorn) - a program or module that can listen for requests from a client and using our code, return something dynamically. In the example we simply return some very bad HTML.
What's the business logic all the other people talk about? Well, since a URL maps to somewhere specifically in our codebase, we are hypothetically showing some logic about how our program works.
Recapping
web server - serves files stored somewhere (most commonly .css, .html, .js). Common web servers are Apache, Nginx or even Python's SimpleHTTPServer.
application server - serves files generated on the fly. Essentially most web servers have some sort of plugins or even come with built-in functionality to do that. There exist also strict application servers like Gunicorn (Python), Unicorn (Ruby), uWSGI (Python), etc.
Notice that you can actually build a web server with the code of the application server. This is done in some cases during development where you do not want to have a gazillion of different servers running on your computer.

As Rutesh and jmservera pointed out, the distinction is a fuzzy one. Historically, they were different, but through the 90's these two previously distinct categories blended features and effectively merged. At this point is is probably best to imagine that the "App Server" product category is a strict superset of the "web server" category.
Some history. In early days of the Mosaic browser and hyperlinked content, there evolved this thing called a "web server" that served web page content and images over HTTP. Most of the content was static, and the HTTP 1.0 protocol was just a way to ship files around. Quickly the "web server" category evolved to include CGI capability - effectively launching a process on each web request to generate dynamic content. HTTP also matured and the products became more sophisticated, with caching, security, and management features. As the technology matured, we got company-specific Java-based server-side technology from Kiva and NetDynamics, which eventually all merged into JSP. Microsoft added ASP, I think in 1996, to Windows NT 4.0. The static web server had learned some new tricks, so that it was an effective "app server" for many scenarios.
In a parallel category, the app server had evolved and existed for a long time. companies delivered products for Unix like Tuxedo, TopEnd, Encina that were philosophically derived from Mainframe application management and monitoring environments like IMS and CICS. Microsoft's offering was Microsoft Transaction Server (MTS), which later evolved into COM+. Most of these products specified "closed" product-specific communications protocols to interconnect "fat" clients to servers. (For Encina, the comms protocol was DCE RPC; for MTS it was DCOM; etc.) In 1995/96, these traditional app server products began to embed basic HTTP communication capability, at first via gateways. And the lines began to blur.
Web servers got more and more mature with respect to handling higher loads, more concurrency, and better features. App servers delivered more and more HTTP-based communication capability.
At this point the line between "app server" and "web server" is a fuzzy one. But people continue to use the terms differently, as a matter of emphasis. When someone says "web server" you often think HTTP-centric, web UI, oriented apps. When someone says "App server" you may think "heavier loads, enterprise features, transactions and queuing, multi-channel communication (HTTP + more). But often it is the same product that serves both sets of workload requirements.
WebSphere, IBM's "app server" has its own bundled web server.
WebLogic, another traditional app server, likewise.
Windows, which is Microsoft's App Server (in addition to being its File&Print Server, Media Server, etc.), bundles IIS.

As many have said before, web servers handle HTTP petitions, while application servers handle petitions for distributed components.
So, maybe the easiest way to understand the difference is to compare the two products in regards to programming environment they offer.
Web Server -> Programming Environment
IIS : ASP (.NET)
Tomcat : Servlet
Jetty : Servlet
Apache : Php, CGI
Application Servers -> Programming Environment
MTS : COM+
WAS : EJB
JBoss : EJB
WebLogic Application Server : EJB
The crucial difference is that application servers support some distributed component technology, providing features like remote invocation and distributed transactions, like EJB in Java world or COM+ on Microsoft platform. Http server often support some more simple programming environments, often scripting, like ASP (.NET) in case of Microsoft or Servlet--based, including JSP and many other in case of Java or PHP and CGI in case of Apache.
Other capabilities like load-balancing, clustering, session-failover, connection pooling etc. that used to be in the realm of application servers, are becoming available on web servers as well directly or through some third party products.
Finally, it is worth noting that the picture is further distorted with "lightweight containers" like Spring Framework, that often supplement the purpose of application servers in more simple manner and without the application server infrastructure. And since distribution aspect in applications is moving from distributed component towards service paradigm and SOA architecture, there is less and less space left for traditional application servers.

In short,
The web server is a server that serves static web pages to users via HTTP requests.
The application server is a server that hosts the business logic for a system.
It often hosts both long-running/batch processes and/or interop services not meant for human consumption (REST/JSON services, SOAP, RPC, etc).

The main difference between Web server and application server is that web server is meant to serve static pages e.g. HTML and CSS, while Application Server is responsible for generating dynamic content by executing server side code e.g. JSP, Servlet or EJB.
Which one should i use?
Once you know the difference between web and application server and web containers, it's easy to figure out when to use them.
You need a web server like Apache HTTPD if you are serving static web pages. If you have a Java application with just JSP and Servlet to generate dynamic content then you need web containers like Tomcat or Jetty. While, if you have Java EE application using EJB, distributed transaction, messaging and other fancy features than you need a full fledged application server like JBoss, WebSphere or Oracle's WebLogic.
Web container is a part of Web Server and the Web Server is a part of Application Server.
Web Server is composed of web container, while Application Server is composed of web container as well as EJB container.

A Web server exclusively handles HTTP/HTTPS requests. It serves content to the web using HTTP/HTTPS protocol.
An application server serves business logic to application programs through any number of protocols, possibly including HTTP. The application program can use this logic just as it would call a method on an object. In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on Java EE (Java Platform, Enterprise Edition) application servers.
The main point is that the web server exposes everything through the http protocol, while the application server is not restricted to it.
An application server thus offers much more services than an web server which typically include:
A (proprietary or not) API
Load balancing, fail over...
Object life cycle management
State management (session)
Resource management (e.g. connection pools to database)
Most of the application servers have Web Server as integral part of them, that means App Server can do whatever Web Server is capable of. Additionally App Server have components and features to support Application level services such as Connection Pooling, Object Pooling, Transaction Support, Messaging services etc.
An application server can (but doesn't always) run on a web server to execute program logic, the results of which can then be delivered by the web server. That's one example of a web server/application server scenario.
A good example in the Microsoft world is the Internet Information Server / SharePoint Server relationship. IIS is a web server; SharePoint is an application server. SharePoint sits "on top" of IIS, executes specific logic, and serves the results via IIS.
In the Java world, there's a similar scenario with Apache and Tomcat, for example.
As web servers are well suited for static content and app servers for dynamic content, most of the production environments have web server acting as reverse proxy to app server. That means while service a page request, static contents such as images/Static html is served by web server that interprets the request. Using some kind of filtering technique (mostly extension of requested resource) web server identifies dynamic content request and transparently forwards to app server.
Example of such configuration is Apache HTTP Server and BEA WebLogic Server. Apache HTTP Server is Web Server and BEA WebLogic is Application Server.
In some cases, the servers are tightly integrated such as IIS and .NET Runtime. IIS is web server. when equipped with .NET runtime environment IIS is capable of providing application services
Web Server Programming Environment
Apache PHP, CGI
IIS (Internet Information Server) ASP (.NET)
Tomcat Servlet
Jetty Servlet
Application Server Programming Environment
WAS (IBM's WebSphere Application Server) EJB
WebLogic Application Server (Oracle's) EJB
JBoss AS EJB
MTS COM+

The border between these two are getting ever so thinner.
Application servers expose business logic to clients. That means application servers comprise of a set of methods (not exclusively though, can even be a networked computer allowing many to run software on it) to perform business logic. So it will simply output the desired results, not HTML content. (similar to a method call). So it is not strictly HTTP based.
But web servers pass HTML content to web browsers (Strictly HTTP based). Web servers were capable of handling only the static web resources, but the emergence of server side scripting allowed web servers to handle dynamic contents as well. Where a web server takes in the request and directs it to relevant scripts (PHP, JSP, CGI scripts, etc.) to CREATE HTML content to be sent to the client. Once the content is received, web server will send the HTML page to the client.
However, nowadays both these servers are used together.
Where web server takes the request and then calls a script to create the HTML content. Then, the script will again call an application server LOGIC (e.g. Retrieve transaction details) to fill the HTML content.
So both the servers are used effectively.
Therefore ....
We can safely say that nowadays, in most of the cases, web servers are used as a subset of application servers. BUT theatrically it is NOT the case.
I have read many articles about this topic and found this article quite handy.

In Java terms, there's one more: web container (or more strictly, servlet container). It's, say, in between web server and application server.
A web container in Java terms is an application server that basically only implements the JSP/Servlet part of Java EE and lacks several core parts of Java EE, such as EJB support. An example is Apache Tomcat.

An application server is typically designed and deployed to facilitate longer running processes that will also be more resource intensive.
A web server is used for short bursts that are not resource intensive, generally. This is mostly to facilitate serving up web based traffic.

A web server runs the HTTP protocol to serve web pages. An application server can (but doesn't always) run on a web server to execute program logic, the results of which can then be delivered by the web server. That's one example of a web server/application server scenario.
A good example in the Microsoft world is the Internet Information Server / SharePoint Server relationship. IIS is a web server; SharePoint is an application server. SharePoint sits "on top" of IIS, executes specific logic, and serves the results via IIS.
In the Java world, there's a similar scenario with Apache and Tomcat, for example.

An application server is a machine (an executable process running on some machine, actually) that "listens" (on any channel, using any protocol), for requests from clients for whatever service it provides, and then does something based on those requests. (may or may not involve a respose to the client)
A Web server is process running on a machine that "listens" specifically on TCP/IP Channel using one of the "internet" protocols, (http, https, ftp, etc..) and does whatever it does based on those incoming requests... Generally, (as origianly defined), it fetched/generated and returned an html web page to the client, either fetched from a static html file on the server, or constructed dynamically based on parameters in the incoming client request.

On a first hand, a web server serves web content (HTML and static content) over the HTTP protocol. On the other hand, an application server is a container upon which you can build and expose business logic and processes to client applications through various protocols including HTTP in a n-tier architecture.
An application server thus offers much more services than an web server which typically include:
A (proprietary or not) API
Object life cycle management,
State management (session),
Resource management (e.g. connection pools to database),
Load balancing, fail over...
AFAIK, ATG Dynamo was one of the very first application server in late 90's (according to the definition above). In early 2000, it was the reign of some proprietary application servers like ColdFusion (CFML AS), BroadVision (Server-side JavaScript AS), etc. But none really survived the Java application server era.

Biggest difference is a Web Server handles HTTP requests, while an Application server will execute business logic on any number of protocols.

Actually Apache is a web server and Tomcat is an application server. When as HTTP request comes to web server. Then static contents send back to browser by web server. Is there and logic do to done, then that request send to the application server. after processing the logic then response send to web server and send to the client.

Basic understanding :
In client server architecture
Server :> Which serves the requests.
Client :> Which consumes service.
Web server & Application server are both software applications which act as servers to their clients.
They got their names based on their place of utilization.
Web server :> serve web content
:> Like Html components
:> Like Javascript components
:> Other web components like images,resource files
:> Supports mainly web protocols like http,https.
:> Supports web Request & Response formats.
Usage --
we require low processing rates,
regular processing practices involves.
Eg: All flat servers generally available ready-made which serves only web
based content.
Application server :> Serve application content/component data(Business data).
:> These are special kind which are custom written
designed/engineered for specific
purpose.some times fully unique in
their way and stands out of the crowd.
:> As these serves different types of data/response contents
:> So we can utilize these services for mobile client,web
clients,intranet clients.
:> Usually application servers are services offered on different
protocols.
:> Supports different Request& Response formats.
Usage --
we require multi point processing,
specialized processing techniques involves like for AI.
Eg: Google maps servers, Google search servers,Google docs servers,Microsoft 365
servers,Microsoft computer vision servers for AI.
We can assume them as tiers/Hierarchies in 4-tier/n-tier architecture.
So they can provide
load balancing,
multiple security levels,
multiple active points,
even they can provide different request processing environments.
Please follow this link for standard architecture analogies:
https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ee658120(v%3dpandp.10)

All of the above is just over-complicating something very simple. An application server contains a web server, an application server just has a couple more additions/extensions to it than standard web servers. If you look at TomEE as an example:
CDI - Apache OpenWebBeans
EJB - Apache OpenEJB
JPA - Apache OpenJPA
JSF - Apache MyFaces
JSP - Apache Tomcat
JSTL - Apache Tomcat
JTA - Apache Geronimo Transaction
Servlet - Apache Tomcat
Javamail - Apache Geronimo JavaMail
Bean Validation - Apache BVal
You will see that Tomcat (Web container/server) is just another tool in the app servers arsenal. You can get JPA and the other tech in the web server as well if you want, but the application servers just package all of these things for your convenience. To be fully classified as an app server you essentially need to comply with a list of tools set forth by some standard.

There is not necessarily a clear dividing line. Nowadays, many programs combine elements of both - serving http requests (web server) and handling business logic (app server)

IMO, it's mostly about separating concerns.
From a purely technical point of view, you can do everything (web content + business logic) in a single web server. If you'd do that, then the information would be embedded inside requested the HTML content. What would be the impact?
For example, imagine you have 2 different apps which renders entirely different HTML content on the browser. If you would separate the business logic into an app-server than you could provide different web-servers looking up the same data in the app-server via scripts. However, If you wouldn't separate the logic and keep it in the web-server, whenever you change your business model, you would end up changing it in every single web-server you have which would take more time, be less reliable and error-prone.

Application server and web server both are used to host web application. Web Server is deal with web container on the other hand Application Server is deal with web container as well as EJB (Enterprise JavaBean) container or COM+ container for Microsoft dot Net.
Web Server is designed to serve HTTP static Content like HTML, images etc. and for the dynamic content have plugins to support scripting languages like Perl, PHP, ASP, JSP etc and it is limited to HTTP protocol. Below servers can generate dynamic HTTP content.
Web Server's Programming Environment:
IIS : ASP (.NET)
Apache Tomcat: Servlet
Jetty: Servlet
Apache: Php, CGI
Application Server can do whatever Web Server is capable and listens using any protocol as well as App Server have components and features to support Application level services such as Connection Pooling, Object Pooling, Transaction Support, Messaging services etc.
Application Server's Programming Environment:
MTS: COM+
WAS: EJB
JBoss: EJB
WebLogic Application Server: EJB

While there may be overlaps between the two (some web servers may even be used as application servers) the biggest difference IMHO is in the processing model and the session management:
In Web server processing model, the focus is on handling requests; the notion of "session" is pretty much virtual. That is to say that "session" is simulated by transferring the representation of state between client and server (hence REST) and/or serializing it to an external persistent storage (SQL Server, Memcached etc).
In Application server the session is usually more explicit and often takes form of an object living in memory of the application server for the entire duration of the "session".

From https://en.wikipedia.org/wiki/Web_server
A web server is a computer system that processes requests via HTTP, the basic network protocol used to distribute information on the World Wide Web. The term can refer to the entire system, or specifically to the software that accepts and supervises the HTTP requests.
From https://en.wikipedia.org/wiki/Application_server#Application_Server_definition
An application server runs behind a web Server (e.g. Apache or Microsoft Internet Information Services (IIS)) and (almost always) in front of an SQL database (e.g. PostgreSQL, MySQL, or Oracle).
Web applications are computer code which run atop application servers and are written in the language(s) the application server supports and call the runtime libraries and components the application server offers.

web server: for every URL, it returns a file. That's all it does. The file is static content, meaning, it is stored somewhere in the server, before you make your request. Most popular web servers are apache http and nginx.
application server: for every URL, it runs some code, written in some language, generates a response, and returns it. The response doesn't exist in advance, it is generated for your particular request, that is, it is dynamic content. Application servers are different for each language. Some popular examples are tomcat/jetty for java, uwsgi/gunicorn for python.
Almost every page you visit uses both. The static content (eg, images, videos) is served by the web server, and the rest (the parts that are different between you and other users) are generated by the application server.

IBM makes a really nice comparison between the two:
By strict definition, a web server is a common subset of an application server.
A web server delivers static web content—e.g., HTML pages, files, images, video—primarily in response to hypertext transfer protocol (HTTP) requests from a web browser.
An application server typically can deliver web content too, but its primary job is to enable interaction between end-user clients and server-side application code—the code representing what is often called business logic—to generate and deliver dynamic content, such as transaction results, decision support, or real-time analytics. The client for an application server can be the application’s own end-user UI, a web browser, or a mobile app, and the client-server interaction can occur via any number of communication protocols.
In practice, however, the line between web servers and application servers has become fuzzier, particularly as the web browser has emerged as the application client of choice and as user expectations of web applications and web application performance have grown.
Most web servers support plug-ins for scripting languages (e.g., ASP, JSP, PHP, Perl) that enable the web server to generate dynamic content based on server-side logic. And an increasing number of application servers not only incorporate web server capabilities, but use HTTP as their primary protocol and support other protocols (e.g., CGI and CGI variants) for interfacing with web servers. They also allow web applications to leverage services like reverse proxy, clustering, redundancy, and load balancing—services that improve performance and reliability and allow developers to focus less on infrastructure and more on coding.
To make matters more confusing, many web servers and some application servers are referred to, or refer to themselves, as web application servers.
The bottom line is that today’s most popular web servers and application servers are hybrids of both. Most of the increasingly rich applications you use today feature a combination of static web content and dynamic application content, delivered via a combination of web server and application server technologies.

Drawing my conclusion from posts of awesome SO evangelists above, I conclude that both are software that resides on actual metal servers(physical servers). Both work hand in hand to get service to the end-user. Then, depending on the setup, we can choose what to call it, which means how to describe it depends on the actual setup in use. If they both reside on the same bare metal(physical server), we call it web and application server...simple! If on separate machines, obviously, we have two distinct bare metals(physical servers) at our hands. Then we can label these servers according to their function: one web server and the other application server.

It depends on the specific architecture. Some application servers may use web protocols natively (XML/RPC/SOAP over HTTP), so there is little technical difference. Typically a web server is user-facing, serving a variety of content over HTTP/HTTPS, while an application server is not user-facing and may use non-standard or non-routable protocols. Of course with RIA/AJAX, the difference could be further clouded, serving only non-HTML content (JSON/XML) to clients pumping particular remote access services.

Related

SOAP Web Services with load balancing

My customer has 2 Windows Server 2019.
On both of them, an instance of a SOAP Web Service is running.
URLs:
https://host1.domainname.com/SOAPService
and
https://host2.domainname.com/SOAPService
Now, the requirement of the customer is to provide a single, unique URL that the clients can use to consume the SOAP WebService(s).
I read through several websites and if I got it right, I need a tool that is called "reserve proxy"... Using this tool, clients can access the webservice by using an URL such as https://host.domainname.com/SOAPService and the tool will automatically route the request to the available webservice.
Correct?
I also have an architectural question:
On which machine do I have to run such a Reserve Proxy?
Is it on host1 or host2 or do I need a dedicated machine (like a supervisor)?
If it is a dediciated machine, how can I apply high availability of this Reverse Proxy? E.g. is it possible to run 2 Reserve Proxies in parallel on different machines? Which tool could afford this?
Thanks

Exe as Webservice Endpoint

I got a webservice endpoint and I stumple upon how to correctly implement it.
It seems to be an parameterized exe-file which returns an XML Reply.
There is no documentation.
I am used to soap, wcf and rest but this is completely unknown to me, has anyone a guide or a best case how to implement such a service?
I can consume it with a HTTP GET but there are some questions left to me:
I know the questions are quite broad... But I could not find anything about it in the interwebz.
Is there a secure way to publish exe files as webservice?
Are there any critical downsides implementing such an interface?
Make I myself a fool and this is just an alias?
Example Url:
http://very.exhausting.company/Version/SuperStrange.exe?parameter=String

Web servers
What you call a webservice endpoint is nothing else than a web server listening on some host (normally 0.0.0.0) and some port on a physical or virtual machine and responding with some HTTP response to HTTP requests sent to that host, port and URIs that the web server cares to process.
Any web server is itself an application or a static or dynamic component of an application as the following examples illustrate:
JBoss, Glassfish, Tomcat etc. are applications, known as application servers, into which containers/servlets/plugins implementing web servers and corresponding endpoints are deployed. These listen on some port exposing generic web servers routing requests to those containers and their servlets;
a fat jar started with java -jar on a JVM which deploys a vert.x verticle featuring a vert.x HttpServer listening on some port is nothing else than a web server;
an interpreter such as node.js parsing and executing JavaScript code based on the express module will most likely deploy a web server on some port;
finally, a statically or dynamically linked application written in languages such as C++ or Go can expose a web server listing on some port.
All of the above cases feature different deployment mechanisms, but what they deploy is essentially the same: a piece of software that listens for HTTP requests on some port, executes some logic based on request and returns HTTP responses to the caller.
Your windows exe file is most likely a statically linked application that provides a web server.
Protocols
So we know you have a web server as it reacts to an HTTP GET. How does it relate to REST, SOAP etc? Effectively, REST, SOAP etc are higher level protocols. TCP is the low level, HTTP is based on top of that and your server supports that. REST, SOAP and everything else that you mention are higher level protocols that are based, among others, on HTTP. So all you know is that your application (web server) supports HTTP, but you do not know which higher level data exchange protocol it implements. It definitely implements some, at least a custom one that its author came up with to exchange data between a client and this application.
You can try to reverse engineer it, but it is not clear how would you find out about all possible endpoints, arguments, payload structures, accepted headers etc. Essentially, you have a web server publishing some sort of an API, but there is no generic way of telling what that API is.
Security
The world around you does not have to know how the API is published. You can put any of the above 4 web server implementations behind exactly the same firewall or a reverse proxy with SSL termination exposing just one host and port over SSL. So there is no difference in security, with respect to the world, whether you deploy it as exe or as a war into JBoss. This is not to say, that your exe file is secure: depending on how it is implemented it may allow all sorts of attacks, but again, this is equally true for any mechanism.

How can I interact with PHP or the other scripting language in my Web server?

I have written a web server in C and I want to add some scripting language support like (PHP,...) to the server.
How can I interact with PHP and other scripting language?
How send them requests and get responses?
Is there any document or guide about web server developing or web server architecture?

The first thing that comes to mind is to use CGI or FastCGI (see http://en.wikipedia.org/wiki/FastCGI). That's how nginx (a popular web server also written in C) supports PHP, for example.
It's much faster to add support for FastCGI and then rely on software like PHP-FPM (PHP FastCGI implementation) rather than to write your own PHP module. However, you will have to run an extra background process, listening to its own UNIX socket or TCP port.
Another possibility is to execute CLI handler for corresponding language (eg. CLI PHP) upon HTTP request, but I suspect that performance will be much lower.
For example, user requests /something.php?query=parameter from your web server. Your web server looks for something.php file in specified folder (your web servers config file), then executes (interprets) it using PHP CLI, waits for response and passes that response back to web user.

What is the difference between IBM HTTP Server vs Wepsphere Application Server?

I would like to know the difference between IBM HTTP Server and Wepsphere Application Server. Also i am planning to use WAS. Do i still need the IBM HTTP Server?

From here:-
IBM HTTP Server
IBM® HTTP Server is a full-featured web server that is included with
other products such as IBM WebSphere® Application Server at no charge.
You can use this web server for projects that do not warrant the
expense of a priced and supported HTTP server. The IBM HTTP Server is
based on the Apache HTTP Server and provides a rich set of Apache
features in addition to IBM enhancements.
From here:-
Wepsphere Application Server
IBM® WebSphere® Application Server offers options for a faster, more
flexible Java application server runtime environment with enhanced
reliability and resiliency. It supports single server environments and
medium-sized configurations, as well as dynamic web applications
requiring web tier clustering over multiple application server
instances.
Do i still need the IBM HTTP Server?
Wiki has the answer for it:-
It works with a number of Web servers including Apache HTTP Server,
Netscape Enterprise Server, Microsoft Internet Information Services
(IIS), IBM HTTP Server for i5/OS, IBM HTTP Server for z/OS, and IBM
HTTP Server for AIX/Linux/Microsoft Windows/Solaris. It uses port 9060
for connection as the default administration port and port 9080 as the
default website publication port. In case you install more WebSphere
instances these values will be changed.

A http server is used for routing web requests to a WAS in a typical enterprise scenario. If you are building small apps, and do not need ejbs, just use the http server. If you need ejbs, just use WAS. However, if you need functionality like routing requests to WAS because you do not want the user to hit the WAS directly for security reasons, then use HTTP in front of WAS.

WebSphere is an implementation of J2EE (originally Java 2 but versions handle up to J6EE). This varies from a normal web server in that the latter typically had the task of running scripts or programs using operations that were quite expensive for CPU load. Modern web servers do not have as much penalty but Java based solutions still have their advantages.
For test/dev environments, one does not need to have a web server in front. One can go directly to a WebSphere port (often port 9080) that provides a Java web implementation and not have the administrative burden of the care and feeding of a web server. On the other hand, IBM recommends using a web server for production (especialy for larger production loads). If one does use a web server, there are several that are supported. IBM HTTPS Server is a blue-washed version of Apache (there are some modules that are not supported but there are also lots of extra features to bind easily with WAS).

All the answers are good so let me give my cents ,
Websphere as other java applications, was made to work with dinamic contents .
apache or IHS that is apache IBM plugins can handle with all kinds of http/https requests , static , dinamic , proxy ,cache at the client tags, balance and so on ...
just using apache over java aplications is not the best ,
the best is allow apache handle all static downloads without call it from application server ,
like images and fixed htmls and left application server handle the just dinamic contents .
at this way we can optimize the environment , so development should create a pattern to dispose static and dinamic at different virtual direct like /jsp for dinamic and the rest as static , if not apache cache can be used instead for not overload the application server .
to make the story short , apache is so powerful ans can help a lot the application server sparing the work , a simple and effective usage is done to forward the port using default port 80/443 for http/https instead usual high ports on java application servers , make the apache deliver https is a best option too , instead left java application server care of it , so there is a lot of reasons to use Apache or IHS in front of application servers.