Application Servers Support Model

tukwilagleefulInternet and Web Development

Oct 31, 2013 (4 years and 8 months ago)


Application Servers

Support Model

Support Model Overview

Related to the Application Server Standards position Paper recently
announced for ITSS, this document will outline the elements and scope
of a proposed support model for such a standard.


The background for this technology and standards for ITSS can be
found at

re are several

issues ra
ised in this document
which have support

There needs to be a standard, packaged and maintained build of
Tomcat held on a reference site for all ITSS implementations. This
may, for example, take the form of a specific build level of the
ard distribution with some documented configurations and/or

Application Servers are a class of server platforms that allow remotely
initiated invocation of program or application execution. They are also
called Web Application Servers dependin
g upon their implementation.

Some examples of Application Server technologies are:


J2EE servers


CORBA servers


Microsoft DCOM servers

Of these technologies, only Java J2EE technology servers are being
considered for this document due to the fact that o
nly this framework
is broadly deployed at Stanford University. Also, J2EE is the most
likely to remain open in terms of interface definitions for the
foreseeable future. Supplemental guidelines will be created for other
technologies as needed. Currently,

the following J2EE compliant
application servers are being used at Stanford University (just within



Technology Strategy and Support









This proliferation of product deployment
s is complex, expensive and
largely unnecessary. It is consistent with the strategic principles of
ITSS to reduce the number of these platforms to the fewest possible
and implement them in the most cost
effective and robust manner.

Application Server Stan

If J2EE programming and protocol standards are supported by all the
above products, then the fundamental basis for choosing one product
over may seem somewhat arbitrary. However, there are some
differentiating characteristics between these products.
There are both
technology and non
technology differentiators which drive selection.

Some products have been implemented simply because of ERP product
implementation (vendor choice). Some were simply the favorite of a
developer involved on a project. Othe
rs were selected because they
were available as opensource software (OSS) or otherwise use a free
license from a manufacturer. None of these motivations should
constitute the basis for a standard for application server strategy.

Technology Drivers for Se
lection of Application Server

The following are the high
level characteristics that should be part of
the standard product selection criteria for application servers.


Open standards (adherence to and at pace with)


Ease of deployment and management




Fault tolerance


Remote monitoring


Platform support





On the basis of the above criteria, not all J2EE compliant application
servers are equally appropriate for enterprise service deployment at
Stanford University. For example, to

achieve the scalability and fault
tolerance of application servers, product specific capabilities are
generally used. This is because there is no standard execution state
management protocol within J2EE. Each vendor product that does
scalability and fau
tolerance (clustering), does so differently. Some
do not have these capabilities at all but could be adapted/extended to
perform in this way.

technology Drivers for Selection of Application Server


Purchase and licensing costs


Support costs


ty of company or OSS project


Adoption by vendors

Open Standards, Open Source and “Free” Software

The greatest motivation for open standards in the development of
application server programs is the portability of the code. For
example, a JSP (Java Server
Page) written to the J2EE Servlet API

will be directly executable on any compliant server. This is true as
long as no product specific features are called. For this reason, it is
vital that developers at Stanford University only write standards based
de. Sometimes this may require a programmer to ignore
“shortcuts” offered by a specific vendor (e.g. a non
standard based
Java class offered).

Just because a product is opensource software (OSS), this does not
mean that it was necessarily written to open

standards or that it is well
architected. By open standards, it is meant a non
consortia contributed, peer reviewed and documented technology and
protocol standard. However, there is certainly a trend for ITSS to
consider and adopt OSS when

it’s as good as the competition.

No software is free. OSS or vendor donated software must be
integrated, deployed and maintained. All these factors will be
considered in the consideration by ITSS of any software for enterprise
use at Stanford Universit

Implementations and Products: Keep It Simple...

The J2EE multi
tier architecture

is prevalent for most web applications
(fig. 1). For sustainability, the most simple standard architecture and
implementation that will satisfy the application requireme
nts should be
employed. Currently for ITSS, there are few if any such requirements
identified which justify the use of Enterprise Java Bean (EJB)
technology. This technology, while elegant and powerful, adds
considerable complexity to design and support.


Support Issues

Given the selection of Tomcat as the platform of J2EE standard choice
for ITSS, it is additionally important that a limited set of versions of
this product be used for development and production. It is

important that a centrally offered version be maintained by TSS as
reference for use by all ITSS. The selection and review of this
standard version will be performed by the ITSS Application Architect

on an as needed basis.

Currently, it is ve
ry unlikely that a particular support question could
not be answered through the extensive network of contributors and
user communities that collectively support Tomcat today. However, it
is conceivable that some vendor support will be required and the
cess to such support should be explored as needed.

Only maintain state info for info you can afford to lose.

LB discussions…very useful for web apps and for sticky sessions.


Tomcat is currently the product that should be supported and deployed
s the ITSS standard for J2EE web applications. It is the official
standard implementation of the Java Servlet API and offers broad
adoption, good performance and tracks the specifications of J2EE.

The use of EJB’s should be strictly limited to demonstrat
ed need and
will be reviewed for that need by a IT architectural review
. As of this
writing, BEA WebLogic is the Application Server product that should be
used in support of EJB’s in ITSS
when this technology is required
Enterprise applications which ar
e being built (in
house or by a third
party) should adhere to the same standards and their use will also be
reviewed by the same IT architectural review described above.

Enterprise applications that are being considered for purchase and
which already dive
rge from these standards should have additional
ongoing support and complexity costs budgeted. Projects which select
or otherwise implement a product other than Tomcat as an J2EE
application servers will be required to fund the support of this choice
ide the standard systems administration model. Also, enterprise
application vendors should be interviewed by ITSS IT architects for the

reliance upon a specific product other Tomcat.






v i

ht t p://j ak ar t a.apac he.or g/t omc at/i ml

v i i

ht t p://www.j bos s.or g/i ml?modul e= ht ml &op= us e
r di s pl ay &i d= o ver vi ew

v i i i

ht t p://www.bea.c om/f r amewor k.j s p?CNT= i m&FP=/c ont e nt/pr o duc t s/s er ve r


x ng_enterprise_applications_2e/introduction/introd


Elected by the ITSS Technology Strategist


Overseen by the Technology Strategist for ITSS