Application Servers Support Model

tukwilagleefulInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

80 εμφανίσεις




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.


Back
ground

The background for this technology and standards for ITSS can be
found at
:
http://tss.stanford.edu/files/Application%20Serr%20Standards.doc

The
re are several

issues ra
ised in this document
which have support
implications.

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
stand
ard distribution with some documented configurations and/or
patching.



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
i

-

CORBA servers
ii

-

Microsoft DCOM servers
iii


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
ITSS):


Product

Manufacturer


Technology Strategy and Support


OAS
iv

Oracle

JRun
v

Macromedia

Tomcat
vi

Apache.org

JBoss
vii

JBoss.org

WebLogic
viii

BEA


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
dard

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

-

Scalab
ility

-

Fault tolerance

-

Remote monitoring

-

Platform support

-

Security

-

Performance


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
lt
-
tolerance (clustering), does so differently. Some
do not have these capabilities at all but could be adapted/extended to
perform in this way.


Non
-
technology Drivers for Selection of Application Server

-

Purchase and licensing costs

-

Support costs

-

Viabili
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
ix

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
co
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
-
proprietary,
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
y.


Implementations and Products: Keep It Simple...

The J2EE multi
-
tier architecture
x

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.


Figure
1



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

therefore
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
xi

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
ac
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.



Summary

Tomcat is currently the product that should be supported and deployed
a
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
xii
. 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
outs
ide the standard systems administration model. Also, enterprise
application vendors should be interviewed by ITSS IT architects for the
actual

reliance upon a specific product other Tomcat.






i

http://java.sun.com/j2ee/

ii

http://www.omg.org/gettingstarted
/specintro.htm#CORBA

iii

http://www.microsoft.com/com/tech/DCOM.asp

iv

http://www.oracle.com/ip/deploy/ias/index.html

v

http://www.macromedia.com/software/jrun/

v i

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

v i i

ht t p://www.j bos s.or g/i ndex.ht 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 ndex.ht m&FP=/c ont e nt/pr o duc t s/s er ve r

ix

http://java.sun.com/products/servlet/index.html

x

http://java.sun.com/blueprints/guidelines/designi ng_enterprise_applications_2e/introduction/introd
uction3.
html

xi

Elected by the ITSS Technology Strategist

xii

Overseen by the Technology Strategist for ITSS