JEE Shared Containers

6 March 2009
 Standard app deployment is based on the App Server
architecture specified in the JEE specifications

Application Server

Embedded HTTP Server

Web EJB
Container
Servlets
Container
Http JSPs
HTTP Server SIP
EJBs
Portlet
HTTP
HTTP HTTP(s)
Serve
Serve
rr
HTTP(s) Plug-
Plug-
in
in Web Services Messaging
Plug-in
Plug-in
Engine Engine
Configuration
Configuration
File
File
Dynamic Cache Name Server Security
IIOP Data Replication JMX Transaction.
… … ….
JMS

Java Runtime Environment

• This presentation concentrates on Java Enterprise architectures.

• Runtime containers, protocols and other architectural components are mostly standardized
by the Java Enterprise specification from Sun Microsystems Inc.
 Production systems employ multiple App Server
instances for redundancy, giving excess capacity

Machine 1

App App
DMZ Machine 1 Server Server …
HTTP
Server
Machine 2
Load Balancer
App App
DMZ Machine 2 Server Server …
HTTP
Server

Internet DMZ Intranet

• For production systems (with scalability, failover, etc. requirements) you need more than
one App Server instance.

• Multiple App Server instances may run on the same machine.

 Applications often do not share App Servers
resulting in lots of machines with low utilization

Machine 1

Machine 3
App App
DMZ Machine 1
Machine 5
App
Server
App
Server …
HTTP Machine 7
App
Server
App
Server …
Server
App
Server
App
Server …
Load Balancer Server Server … Machine 2

Machine 4
App App
DMZ Machine 2
Machine 6
App
Server
App
Server …
HTTP Machine 8
App
Server
App
Server …
Server
App
Server
App
Server …
Server Server …
Internet DMZ Intranet

One Application Server could host multiple applications, but often this is not the case.
Many times different applications do not even share machines.

Result:
• a huge number of machines
• most of them running with very low utilization most of the time
 Big Idea – Shared Containers

• Create one large resource pool that can be used across multiple
JEE applications in a manner that does not increase risk to the
application or reduce performance
 Some new concepts have to be introduced into the
overall architecture to implement the Big Idea

• Allow applications to share the same resources

– CPU and memory of all available machines

• Define rules that specify how many resources an application actually

needs
– Establish mechanisms to provide these resources dynamically.
– If the resources are no longer needed, other applications can use them.

• Define rules for the situation that there are not enough resources for
all applications
– Prioritize requests
 How can sharing occur?

• Goal is to find a Multi-Tenant offering which would be accepted into

GM’s risk-averse culture providing high application isolation at low cost

• The next slides are intended to illustrate various ways that two JEE
applications can be hosted

• Illustrations are simplified to focus on core concepts

– A single middleware tier for each application is illustrated; clusters and/or
session affinity are not depicted
– Web and database servers are not illustrated
– Redundancy for high availability or workload demands are not illustrated
JEE Container Scenarios

High
Physical
Isolation

OS
Infrastructure Required

Virtualization

Progression
is assumed
to be non-
linear; Actual
TCO curve
has not been
computed

Dedicated
JVM per
App
Physical Isolation (current problem)

Scenario
• No sharing - Each application has its own
Physical Server, OS, WLS License, and
JVM.

Advantages
Physical Server Physical
• Server
Complete isolation, immune from anything
OS OS happening with the other application
• OS and JVM can be tuned to the
WLS License WLS License
application
JVM JVM
Disadvantages
App 1 App
•
2
Complete isolation comes at high cost
– Separate hardware
– Separate software licenses
• Often runs at low levels of utilization
JEE Container Scenarios

High
Physical
Isolation

OS
Infrastructure Required

Virtualization

Progression
is assumed
to be non-
linear; Actual
TCO curve
has not been
computed

Dedicated
JVM per
App
OS Virtualization (current solution)

Scenario
Physical Server
• Both applications share a Physical Server
Guest OS • Each application is isolated in its own OS

WLS License
Advantages
JVM • Reduces hardware costs
• Appears to application to be the same as
App 1 physical isolation
• Full range of tuning parameters
• OS container can be moved between
physical servers

Disadvantages
• Added cost of Hypervisor software and
Guest OS
management
WLS License • Software has to be licensed for each OS

JVM
App 2
JEE Container Scenarios

High
Physical
Isolation

OS
Infrastructure Required

Virtualization

Progression
is assumed
to be non-
linear; Actual
TCO curve
has not been
computed

Dedicated
JVM per
App
Dedicated JVM per App

Scenario
Physical Server • Both applications share a Physical Server,
WLS License, and OS
OS • Each application is isolated in its own JVM

Advantages
WLS License • Low tech
• Minimizes hardware and license costs
JVM • A rogue app in one JVM cannot affect the
other app
• JVMs can be tuned to the application
App 1
Disadvantages
• Each JVM has physical memory
requirements which limit how many JVMs
can be created
• Difficult to tune to app SLA as each app acts
JVM independent on shared machine
• Change control notifications/approvals can
become an issue
App 2
JEE Container Scenarios

High
Physical
Isolation

OS
Infrastructure Required

Virtualization

Progression
is assumed
to be non-
linear; Actual
TCO curve
has not been
computed

Dedicated
JVM per
App
Shared JVM for many Apps

Scenario
Physical Server • Both applications share a common JVM,
WLS License, OS, and Physical Server

OS Advantages
• Best suited for development
WLS License • Can run on small hardware with limited
memory
• Minimum cost solution
JVM
Disadvantages
• Performance of one app can affect the
App 1 •
other
CPU allocated to JVM thread,
performance affected by traffic to the app
• One app can corrupt JVM, which would
cause outage for other app upon JVM
restart
App 2 • Change control notifications/approvals can
become an issue
 Inhibitors to adoption of shared containers

• Is the application owner willing to share the application server

environment with others?

• Is it possible to define important and less important applications?

• Is it possible to identify a mixture of applications with varying

performance profiles, peak periods, etc.

• Is there enough trust of the automatic management functions of

the system?
Gartner - "Magic Quadrant for Enterprise
Application Servers, 2Q08" - 24 April 2008
App Virtualization using Demand-based Routing

Scenario
Physical Server
• Both applications share a Physical Server,
OS WLS License, and OS
• Each application is isolated in its own JVM
WLS License • Traffic to applications is throttled by on-
demand router according to SLA policies
JVM
Advantages
App 1 • Minimizes hardware and license costs
• A rogue app in one JVM cannot affect the
other app
Agent • Ability to tune to app SLA as policies dictate
resource consumption priorities
• Drives higher levels of machine utilization

JVM Disadvantages
• SLA priorities need to be negotiated between
App 2 app stakeholders
• Change control notifications/approvals can
become an issue
Agent • Added cost of “Virtual Enterprise” router
IBM Virtual Enterprise introduces an On Demand
Router (ODR) into the architecture
 On Demand Router (ODR) prioritizes requests and
balances load according to service policies

Prioritization and Routing and

Classification
Flow Control Load Balancing
Node
ST AM
High Stock 1
Importance Placement
Trading Executions
Node
ST AM
2

Medium Account Node Stock

ST FA
Importance Mngmt 3 Trading
Account
Node Mngmt
FA AM
WebSphere Virtual Enterprise 4
Financial Financial
Low On Demand Router (ODR)
Advice Advice
Importance Node
FA AM
5
Node Group
Application Demand
Resource State
Placement
Decisions
WebSphere Virtual Enterprise
Operational Policy
Decision Makers
Classification defines the mapping of requests to
Service Policies
 Comparison of server virtualization and application
infrastructure virtualization with IBM WVE

Server virtualization Application infrastructure virtualization with

IBM WVE

Scope •OS image (coarse) •Application (fine)

•Resource-focused •Application and resource focused

Consolidation Vertically stacked OS images •Vertically stacked virtual machines

•Policy-based workload management

Optimization Resource usage (for example, CPU) in Application SLAs

virtual machines

High availability Restart VM instances on alternate hosts Ensure that a minimum number of dynamic
when a host failure is detected cluster instances are always running

Reliability Cluster monitoring with visual alerts, Health monitoring of application servers with
determined by HA and capacity, and automatic correction or rerouting
manual operator intervention
Admission controlCheck the capacity requirements of the •Manage workload traffic
VM against the available capacity of the •Ensure that the node has capacity to run the
pool application server
 Possible Next Steps

• Determine if a “JEE Shared Container” offering should be added

– Create TCO models for “Demand-based Routing”, and “Dedicated JVM”
scenarios
– Compare against TCO model for “OS Virtualization”.

• Determine if BEA WebLogic, and Sun JES provide capabilities similar to

IBM’s “On Demand Router”

• Compare/contrast offerings to Appistry and GigaSpaces

• Ask GM’s IBM sales representative to conduct a WebSphere Virtual

Enterprise value assessment

• Ask GM’s IBM sales representative to schedule a WebSphere Virtual

Enterprise proof of technology (PoT) demonstration

• Perform a Proof of Concept