8/8/2019 Web App Server Architecture
1/17
HPTS Panel:Web Application ServerArchitecture
Scott Dietzen, Ph.D.CTO, Server Division
BEA Systems
8/8/2019 Web App Server Architecture
2/17
SIGMOD redux
The role of the Web application server
Next generation TP Monitor
Transarc IBM
WebLogic BEA
New name essential for investment & competition
Architecture
J2EE in general WebLogic in specific
Instead of J2EE vs. .NET,
Integration in the large
The next J2EE (& .NET) frontier
Agenda
8/8/2019 Web App Server Architecture
3/17
Whats the same?
The vendors
Multi-tier client/server
replacement Thinner client
Service-based designcenter (re-use,integration)
Lighter-weight client
sessions Heavier-weight database
sessions
Synchronous &asynchronousprocessing,
Web Application Server =Next Gen. TP Monitor
Whats different
Market size (e.g., BEA 10K customers)
Java (and C#)
J2EE/ Standard APIs
Deployment scale: Clients, Integration Web UI & protocol stack
Multichannel
Browsers
Text messaging (IM, SMS, )
Voice And programmed client
Personalization, portal, contentmanagement,
Focus on stateful services (session-orientation)
Web services,
8/8/2019 Web App Server Architecture
4/17
Winning architecture so far
Small number of biggerprocesses vs. Address-spaceisolation
JVM image size Java code safety
Re-entrant applicationlogic
Predominately Java-based
Porting/certification costs Time to market
Troubleshooting
with C optimizations(socket muxing, SSL, )
Modeled after first successes
J2EE Architectures
Still seeking traction?
Legacy TP Monitor kernels
E.g., Tuxedo/M3,TX Series/Comp. Broker,
CICS? Impedance mismatch
with Java runtime
Time to market
JVM runtime
modification? OODBMS
E.g., Gemstone
? ORDBMS ?
8/8/2019 Web App Server Architecture
5/17
One J2EE image or specialized processes(e.g., Web container/EJB container)
Performance & scaling Web vs. component performance
A plea for ECPerf
Quality of service/ clustering Service replication, routing, load balancing, and failover
Heartbeat protocol: IP Multicast vs. point-to-point Session protection & migration
Memory copy vs. Database persistence
Session partitioning within Clusters
Caching & data replication Content vs. Object
Time to live vs. Event-based revocation
Multi-container standards (e.g., Akamai) vs.Intra-container
Maturity, transactions, security,
Web Application ServerArchitectural Differentiation
8/8/2019 Web App Server Architecture
6/17
BrowsersWeb
Server
s
Servlet
Engines
Domains & Clusters
Object
Servers
Databases
Domain
Cluster Cluster
Cluster
8/8/2019 Web App Server Architecture
7/17
#1 #2
Example: Session ProtectionVia Memory Copy
Primary/secondary replication of Session State
Browser
Web
Servers
(or WAP
Gateway) Servlet/JSP Engines(& EJB Session Beans)
BA B
C
B C
A
8/8/2019 Web App Server Architecture
8/17
Types of ClusteredServices
1 Stateless
2 Conversational
3 Cached
4 Exactly-Once
State in
memoryPersistence Transactional
Semantics
No
Depends
onReplication
YesYesYes
Yes
Yes
Depends
Example
APIs
EJB/JMS/JDBC/
JCA factories,
EJB Stateless
JSP/Servlet Ses.,
EJB Stateful
JSP fragments,EJB Entity
JMS
destinations, JTA
Tx Managers,
Admin Server
Memory
Repl.
Optional
Depends
No
Optional
8/8/2019 Web App Server Architecture
9/17
Complex software platforms do not commoditizeeasily -- Too many touch points & extensions
Windows, Macintosh
Solaris, HP-UX, AIX, Linux, (POSIX)
Oracle, DB2, SQL Server, (SQL)
WebLogic, WebSphere, iAS, (J2EE) Industry seeks to amortize development cost
2000 person years?
ISVs seek to reduce testing costs
SIs seek repeatable business practices So application servers will be a winner take most
opportunity
At (or soon to be at) critical mass
J2EE: BEA, IBM, Oracle Microsoft
Consolidation OverCommoditization
8/8/2019 Web App Server Architecture
10/17
Java/J2EE vs. Microsoft .NET
Competition is good fun
Coexistence will be the rule
Best news: Web services convergence
Java/J2EE advantages
Emerging Battle Royale
Stay tuned?
8/8/2019 Web App Server Architecture
11/17
Demand For Integration
Large companies may have 5K - 20K applications
Proliferation will continue
Todays state of the art---
Point-to-point or few-to-few Proprietary, and
Developed after the fact
---is expensive, fragile, and does not scale
Build to integrate is the future As todays new apps are
built for Web browsers
Tomorrows will be builtfor Web services
8/8/2019 Web App Server Architecture
12/17
Future Integration BrokersWill Be Build On App.Servers (J2EE & .NET)
Common application container
Components (session & message-driven beans)
Messaging & pub/sub (JMS queues/topics)
Web container (JSP & Servlet container)
Web platform (HTTP, sessions, Web server/hardware )
Integration boundaries
Web services/XML platform
Standard adapter container Eliminate mn problem, get to critical mass, ISV ownership
Quality of service (Software clustering)
Operations, administration, & management
Security, caching, transactions, and so on
Common application container
Components (session & message-driven beans)
Messaging & pub/sub (JMS queues/topics)
Web container (JSP & Servlet container)
Web platform (HTTP, sessions, Web server/hardware )
Integration boundaries
Web services/XML platform
Standard adapter container Eliminate mn problem, get to critical mass, ISV ownership
Quality of service (Software clustering)
Operations, administration, & management
Security, caching, transactions, and so on
8/8/2019 Web App Server Architecture
13/17
Web Services KeyDesign Considerations #1
Web Services should be coarse grained
Export services, not components/objects
Dont fall into the objects-everywhere trap!
The goal is to surface the minimal, elegant binding
Corollary: Web services do not replace binary protocols
Intra-application prefer binary (RMI, JMS) Easier, faster
Inter-application prefer Web services
Drawing the ideal, re-useable service boundaries Divine the broadly re-usable services for integration
Balance crossing costs
This is more art more than science Beautiful application architecture remains the key
8/8/2019 Web App Server Architecture
14/17
Web Services KeyDesign Considerations #2
Ensure loose coupling
Presume nothing about your client
Expect WSDL to live longer than Java components
I.e., services outlive object & data model
So even if Java is your design center,decouple Web services from your application
component model Easily accomplished with wrapper Beans
Increases flexibility
Reduces fragility
8/8/2019 Web App Server Architecture
15/17
Web Services KeyDesign Considerations #3
Use synchronous and asynchronous models appropriately
Prefer synchronous
For query When the result is needed for subsequent processing
For conversational operations
Prefer asynchronous
Most everywhere else Asynchrony generally more natural for app to app communications
Hides mismatches in availability, performance, etc.
Localizes failures
Essential for more complex, multi-party interactions
8/8/2019 Web App Server Architecture
16/17
Web Services Realities
Web services are computationally expensive
But so is HTML
Dynamic discovery will be most useful
At development time
Among trusted trading partners
On Intranets
Web services infrastructure is easy --Defining the industry vocabularies is hard.Growth will come
Top/down Consortia & standards bodies
Bottom/up Trading communities & companies (likenatural languages)
8/8/2019 Web App Server Architecture
17/17
In Memory