Hi Ruslan,
Thanks for the explanation. As a part of NES team can you give me some more
architectural insights ?
I do have a cluster of Web Servers connected through Cisco Locla Director
box. Because these servers ( WebLogic WebExpress ) do not use a persistent
session, I've used a so called 'sticky' (ip-based) sessions on Local
Director. Now I'm evaluating the NES 4.0 to see how it would fit into this
environment ( strongly believing that it's much faster then WebLogic ).
What scenario woudl you recommend for NES 4.0 ?
#1. As above. Local Director with sticky session, all NES servers maintain
their sessions in memeory separately.
BTW. SimpleSessionManager do not call the valueUnboud method of objects
implmenting HttpSessionBindingListener tied to session when the session is
invalidated. I saw your name as one of the authors therefore I mention it.
How can I report it as a bug ?
#2. Use the Cisco box for failover and load balancing and implement
persistent sessions in NES servers e.g. through MMapSessionManager or
customized Session Manger using JDBC ? How does it scale comparing to the
first scenario ?
#3. 3 Tier approach similar to what you wrote about app server. Cisco box (
tier I )distrbutes among groups of servers. Second tier consists of one NES
server serving static pages and graphics and distributing the load ( through
NSAPI stub ) among all servers with business/presentation ( servlets )
logic. All app/web servers share the sessions through files/db as above.
My servlets interact with only with a database and file servers and serve
html clients ( browsers ).
thanks
Jacek
> -----Original Message-----
> From: Ruslan Belkin [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, November 05, 1999 18:45
> To: [EMAIL PROTECTED]
> Subject: Re: why Application Servers
>
> Francis Ip wrote:
>
> Application Server is the middle layer of the 3 tier architecture where
> you
> 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 ...
>
> well. 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.
>
> 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
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
