Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What is an application server?

0 views
Skip to first unread message

Rich Teer

unread,
Nov 3, 2003, 7:01:26 PM11/3/03
to
Hi all,

In simple terms, just what is an application server?
I mean, taking some osrt of database driven web application
(written in PHP or JSP, for example) as an example, I can see
where one would need one or more web servers (for HTTP), and
I can see that a separate database server is pretty much
mandatory. I just don't understand how one can put another
layer between these two.

TIA for any illumination,

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Josh McKee

unread,
Nov 3, 2003, 7:17:15 PM11/3/03
to
On Tue, 04 Nov 2003 00:01:26 GMT, Rich Teer <rich...@rite-group.com>
wrote:

>Hi all,
>
>In simple terms, just what is an application server?
>I mean, taking some osrt of database driven web application
>(written in PHP or JSP, for example) as an example, I can see
>where one would need one or more web servers (for HTTP), and
>I can see that a separate database server is pretty much
>mandatory. I just don't understand how one can put another
>layer between these two.
>
>TIA for any illumination,

This should probably help you out:

http://www.aceshardware.com/read.jsp?id=50000347

Josh

Keith Michaels

unread,
Nov 3, 2003, 7:46:52 PM11/3/03
to
In article <Pine.SOL.4.58.0311031556240.6007@zaphod>,

Rich Teer <rich...@rite-group.com> writes:
|> Hi all,
|>
|> In simple terms, just what is an application server?
|> I mean, taking some osrt of database driven web application
|> (written in PHP or JSP, for example) as an example, I can see
|> where one would need one or more web servers (for HTTP), and
|> I can see that a separate database server is pretty much
|> mandatory. I just don't understand how one can put another
|> layer between these two.

Back in the olden days (pre-web) there were just clients and
servers, and sometimes database servers. The term "application
server" came to describe where you ran your business logic.
Now web servers run business logic via servlets and EJBs, so
they're really application servers. You don't need another
server unless you want to isolate business logic from web services.

Rich Teer

unread,
Nov 3, 2003, 10:35:04 PM11/3/03
to
On Tue, 4 Nov 2003, Josh McKee wrote:

> This should probably help you out:
>
> http://www.aceshardware.com/read.jsp?id=50000347

Thanks; that's an interesting article - but not too helpful
in defining what an app server is. Although I did gather
that they replaced an Apache/PHP solution with an app server,
I'm not sure how that would fit into the context of say
a shopping cart or something.

Rich Teer

unread,
Nov 3, 2003, 10:51:35 PM11/3/03
to
On Tue, 4 Nov 2003, Keith Michaels wrote:

> Back in the olden days (pre-web) there were just clients and
> servers, and sometimes database servers. The term "application
> server" came to describe where you ran your business logic.
> Now web servers run business logic via servlets and EJBs, so
> they're really application servers. You don't need another
> server unless you want to isolate business logic from web services.

OK, I've got that. I must be missing something here, because
I still don't quite grok it.

I'm thinking of a hyperthetical appliction, some sort of
dynamic database driven site. I can visualise how one would
implement this in say PHP: the PHP scripts get executed by
Apache (performing SELECTs etc. with the database), which then
outputs HTML which gets rendered by the user's browser. Would
an application server sit "between" the Apache/PHP combo and
the database, or would it be more accurate to say that in this
example, Apache/PHP *is* the app server (albeit perhaps a crude
one)? If that is the case, would it also be accurate to say
that even Apache with CGI scripts would be (an ever cruder)
application server?

Brad Lanam

unread,
Nov 4, 2003, 1:50:12 AM11/4/03
to
In article <Pine.SOL.4.58.0311031934340.6007@zaphod>, Rich Teer wrote:
> OK, I've got that. I must be missing something here, because
> I still don't quite grok it.

Well, a real-world (but not really great) example of a
3-tiered application I worked on: the California
smog check 2 application:
modem server - handled connections, messages back
and forth to smog check machines.
app server - accepted messages from modem server,
reformatted and sent to database server.
database server - database + business logic.
In this case, the app server was really stupid, since
all the business logic was implemented in the database.
This is a many to fewer to one sort of tier. This was
w/Oracle 6, and the database connections on the database
server ate up a lot of memory on the DB server. So creating
48 persistent connections for each of the 5 modem servers was
out of the question. They had not enough memory on an E1000
for the DB.

This is fairly typical -- many connections, most of which
are not busy, or are waiting for i/o. Fewer application
servers to handle the requests and feed them to the database.

> [...]


> the database, or would it be more accurate to say that in this
> example, Apache/PHP *is* the app server (albeit perhaps a crude

> [...]

Sure, this is a two-tiered app-server+database.

The trouble is, as the application grows, so do the resources
you need to run the web server.

If you end up with a huge program running inside of each
web server, you will end up using up a lot of resources
just to deliver a picture or static web page over the web
to a client browser.

You want the web server to do what it does best. So you have
the web server ask the application for the results.
The web server could ask a different application engine for
other information. And the database handles requests from both
types of applications.

Again, many connections, most of which are not busy, stuck
in keep-alive state or waiting for i/o.

-- Brad

--
-- Brad Lanam b...@gentoo.com

Ian Fitchet

unread,
Nov 4, 2003, 4:44:24 AM11/4/03
to
Brad Lanam <b...@seer.gentoo.com> writes:

> In this case, the app server was really stupid, since
> all the business logic was implemented in the database.

This is symptomatic of why the ideal of a 3-tier model collapses into
two (or fewer!). In the ideal case you have the given three layers:

- database
- business logic
- display

each of which runs in its own suitably confined layer (whether the
confinement is physically separate machines, firewalled, separate
processes or whatever). This lets you change database or display
mechanism or business logic with ease. The database runs on the
database server, the business logic on your application server and
the display on, say, the webserver.

But it doesn't as the first thing to fail is the distinction between
business logic and display as most systems are destined for a single
display mechanism (HTML, say) and so assumptions about that display
mechanism are buried in the business logic. The purists would have
the business logic output some intermediate code (XML, say) suitable
for translation into your favoured display mechanism. The standard
business logic environments (J2EE, say) have plenty of friendly
support for generating the display directly and it's all too easy to
do it yourself rather than code for an intermediary form which the
same-development-language display layer promptly has to decode to
display. How inefficient is that?

The second to go is the purity of the database as database guys have
been quite properly trained to provide functionality in the DB by way
of stored procedures. It doesn't take long for those stored
procedures to support the application much more than ensuring data is
committed to reliable backing store requires. A stored procedure
that is clever about how it stores data quickly because it "knows"
about the data and how it is manipulated becomes a vital part of the
application.

There are lots of good reasons for letting this happen as often as
you can say efficient but it doesn't help clarity of design nor
portability, modularity, supportability (and virtually everything
else bar efficiency). However the result is that the goal of running
your business logic on your application server is lost as you are
really authoring a database helper cum display engine on your
webserver.

As the genre of n-tier models matures it's getting better especially
with the opportunity to support more output media (mobile phone
browsers as well as traditional browsers, say).

Cheers,

Ian

Josh McKee

unread,
Nov 4, 2003, 10:10:05 AM11/4/03
to
On Tue, 04 Nov 2003 03:35:04 GMT, Rich Teer <rich...@rite-group.com>
wrote:

>On Tue, 4 Nov 2003, Josh McKee wrote:


>
>> This should probably help you out:
>>
>> http://www.aceshardware.com/read.jsp?id=50000347
>
>Thanks; that's an interesting article - but not too helpful
>in defining what an app server is. Although I did gather
>that they replaced an Apache/PHP solution with an app server,
>I'm not sure how that would fit into the context of say
>a shopping cart or something.

Sorry Rich, I think that I gave you the wrong link. This one might be
better:

http://www.aceshardware.com/read.jsp?id=45000240

Josh

Rich Teer

unread,
Nov 4, 2003, 1:00:34 PM11/4/03
to
On Tue, 4 Nov 2003, Josh McKee wrote:

> Sorry Rich, I think that I gave you the wrong link. This one might be
> better:
>
> http://www.aceshardware.com/read.jsp?id=45000240

Yes, that one is better - thanks.

Dr. David Kirkby

unread,
Nov 5, 2003, 10:16:38 AM11/5/03
to

Is is a Microsoftism, so they can hire you software which you run from
their 'application server'??? I always wanted to run my applications
at Microsoft, rather than locally. It seems to make best use of the
internet bandwidth!!

I believe that is the way MS are trying to get people to head.

--

"The day Microsoft makes something that doesn't suck is probably
the day they start making vacuum cleaners." -Ernst Jan Plugge.

Dr. David Kirkby Ph.D
Author of 'atlc' http://atlc.sourceforge.net/

Josh McKee

unread,
Nov 5, 2003, 11:36:39 AM11/5/03
to
On Wed, 05 Nov 2003 15:16:38 +0000, "Dr. David Kirkby"
<drki...@ntlworld.com> wrote:

>Rich Teer wrote:
>>
>> Hi all,
>>
>> In simple terms, just what is an application server?
>> I mean, taking some osrt of database driven web application
>> (written in PHP or JSP, for example) as an example, I can see
>> where one would need one or more web servers (for HTTP), and
>> I can see that a separate database server is pretty much
>> mandatory. I just don't understand how one can put another
>> layer between these two.
>>
>> TIA for any illumination,
>>
>> --
>> Rich Teer, SCNA, SCSA
>>
>> President,
>> Rite Online Inc.
>>
>> Voice: +1 (250) 979-1638
>> URL: http://www.rite-online.net
>
>Is is a Microsoftism, so they can hire you software which you run from
>their 'application server'??? I always wanted to run my applications
>at Microsoft, rather than locally. It seems to make best use of the
>internet bandwidth!!
>
>I believe that is the way MS are trying to get people to head.

Application servers are not a Microsoftism. Many companies including
Sun, IBM, and Oracle offer application servers. In addition there are
many smaller companies that sell application servers. And if you're
looking for a free one there's the Tomcat project that integrates with
Apache. Microsoft's IIS server has application server
functionality...and is actually quite nice.

Josh

Torsten Kirschner

unread,
Nov 5, 2003, 10:28:48 PM11/5/03
to

"Rich Teer" <rich...@rite-group.com> skrev i melding
news:Pine.SOL.4.58.0311031934340.6007@zaphod...

http://java.sun.com/j2ee/ describes the J2EE platform.
Other application servers include CICS. [No kidding, and IBM with that
background is a major contributor to J2EE.]

Web applications
On a practical note, J2EE actually contains two types of application server,
the
web container and the EJB container. Stuff like PHP, Perl/CGI etc. is
equivalent to the
web container. I believe Tomcat is the reference implementation for this.
A web container can do lots of stuff, including connections to databases.
Servlets,
JSPs and JavaBeans are fine. For many kinds of applications, this part may
well
suffice.

Enterprise applications
The EJB container and the rest of the J2EE standard are quite a different
ballgame.
This part competes with CICS and heavily re-uses existing standards like
CORBA,
LDAP, MQ etc. Distributed objects, threads and transactions are the main
idea here.
While J2EE "by the book" certainly wants everybody to reduce the web
container to
handle only presentation logic and do all kinds of application logic in the
EJB
container, one should really ask themselves whether that is at all
necessary.
In addition, some types of EJBs, namely entity beans, are an abstraction of
database functionality which works nice on overhead foils, but can really
suck
when it comes to attempting high performance or even correct
implementations.
Also, the entire J2EE platform is much more dynamic than it appears.
Enterprise-
class functionality is being added in every release of the framework (1.3,
1.4,
1.5, ...). While this is very nice, it also means that one is encouraged to
re-
design and re-implement last years expensive workarounds once more.

In order to develop for the J2EE platforms, a Java compiler and Emacs are no
longer enough. You will gain very much from using IDEs like Websphere
Studio,
JBuilder, JDeveloper etc.

Anyway, with Solaris 9 comes the Sun implementation of all of this server
stuff -
for free.

Ben

unread,
Nov 6, 2003, 11:46:07 PM11/6/03
to

Seems it's blurred these days. What about a specific application in the
strict sense; the mode of communication: SMTP, firewall, HTTP, etc.
Seems a lot of folk get the notion that a JSP/EJB (like Weblogic or
Websphere) server is *the* definition of "application-server". Which
that really just falls under a HTTP server that happens to mediate some
SQL.

0 new messages