Re: Discussion topic#1: App Servers

Ganesan, Kumaravel (STSD) wrote:

> 
> - a thougt/proposal :
> 
> App Server Clustering Component :
> 
>             In any large enterprise system ,  there may be muliple
> application server that are used to handle load sharing and load
> balancing. In this high availability context , the proposed component
> can support the following features
> 
> Distributed deployment of appserver components
> To address load balancing in heterogenous app servers (what is the
> Business need --- ?)
>             - it needs seemless deployment of applications (abstract
> webserver ??)
>             - deploy on one node - deploy on all other node
>             - state replication across different servers
> Runtime app.server node identification.
> etc...
>  
>  

That is an interesting thought.

I believe we should steer clear of app server internal things (like 
state replication). Nobody should be deploying the same app across 
different back ends as one unified front end, as it is doomed to end up 
in a disaster of one sort of another. I don't even have fond memories of 
doing partial updates of a live system one node at a time, as there is a 
period when state is shared between two versions of your app, and there 
are potentially different behaviours of the app depending on where stuff 
gets routed.

I do think something that rolls out an update to a set of boxes is 
important, and important its done fast, such as by copying the WAR/EAR 
files to the individual app servers' file systems, then, once every box 
is ready, flipping them over to the new release. You need to think a lot 
about rollback actions too: it may be ok for one node to fail to update 
(in which case it has to be taken out of the load balancing), but if 
more than one fail to update, then its emergency rollback time (which 
implies keeping an old copy of the previous app around).

You need

-good diagnosis of trouble
-a component that is happy if a subset of the things it deploys is 
working, enough for the SLA to be met
-reporting of trouble (i.e, even if you are within the SLA, its 
important to warn that some of the nodes are down). Maybe this comes for 
free if you make part of your state JMX visible.

Another thing to think about is: JNDI access to smartfrog attributes 
from an EAR application

EAR apps are built on the expectation that configuration is via JNDI 
URLs, offering access to some hierarchy of read-only or read-write 
state. This can be simple (tomcat's read only access to a configuration 
file), better (JBoss), or even access to a fully replicated LDAP server 
like ActiveDirectory.

Could we have a JAR that offers read access to part of the smartfrog 
graph from anything hosted in an app server, just by it starting off 
with the right URL and having the right security permissions? That would 
let people use smartfrog as a configuration source, without knowing. It 
also lets things get at the data without running in the same JVM, which 
lets stuff in unsecured, unsigned JARs access the graph. This is 
important because you dont want to try and turn security on in an app 
server that was never designed for it -even hibernate refuses to work in 
with signed JARs (it tries to compile new classes into sealed packages).

-steve



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642