Application Server is the middle layer of the 3 tier architecture where youwell. It all very much depends on what are you trying to build and how you want to partition and manage your web applications. You will always need a web server, since the only way outside world can access your services is via http (aren't we back to era of dumb terminals :-). If you serve only static content or stateless web applications - that'll be all you need. As your site continues to grow - you'll be faced with the requirement to allocate multiple boxes to handle the load. If all you server continues to have is a stateless content - any hardware loadbalancer (such as Cisco local director) put in front of the web server farm is the best practical solution for loadbalancing/failover. Some other advanced features, like clustering support, ldap support/etc. in web servers may come handy as well.
build business logic that seperated from browser layer and database layer.Jim Richards wrote:
> At 04:24 PM 3/11/99 -0500, you wrote:
> >possibly dumb question: when i started on this Servlet journey a
> >few months ago, it was with the Hunter book and the *DK's from Sun.
> >at the time, it seemed feasible to build a servlet project with such
> >tools. now, everybody and his cat has an "Application Server" as part
> >of its package. it is by no means clear to me what such "Servers"
> >bring to the table. anyone able/willing to make a 25 words or less
> >"justification" for any specific AppServer?
>
> It allows the developer to abstract common functionality like authentication
> and page building to allow them to concentrate on just developing
> the business objects.
>
> 24 words ...
Once you introduce a real state and objects associated with that state (so you can't store them on the client) - you'll need to be able to synchronize the state across multiple web applications, running on multiple web servers. That could be done through various means (for example NES4.0 supports plugable session managers, so one can write for example jdbc-based session manager; some hardware loadbalancers support locality forwarding/etc.), but App. Server would generally do a job better, as it was originally designed for it. Of course you don't want to put all your stateless apps onto the app. server, cuz you immediately will loose on average latencies due to roundtrips. Therefor it may be advisable to partition your apps, so static and stateless apps run on the web server (let's call it a presentation logic) and state-aware apps are running in the app. server (let's call it a business logic).
As you continue to grow further, you may want to write transactional applications (which could initiate transactions across multiple databases for example). Modern app. servers have TP monitors integrated into them. API-wise - EJB API can be used to simplify writing of transactional applications.
Generally, I would agree there was a lot of confusion around the term "application server". I guess one can view application server as an integrated framework, which provides us with essential services to support web applications. Many would argue that Windows NT was an application server, as well as any solid ORB. Even Netscape Enterprise Server could be treated as a very simple application server. When you choose one - try to see if it supports services you require and especially how well it supports them (reliability-wise, performance-wise, ease-of-use/etc.)
Ruslan
S/MIME Cryptographic Signature