HPTS Panel:

Web Application Server

Architecture

Scott Dietzen, Ph.D.

CTO, Server Division
BEA Systems
Agenda
• 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
 Web Application Server =
Next Gen. TP Monitor
• What’s different
– Market size (e.g., BEA 10K customers)
• What’s the same?
– Java (and C#)
– The vendors
– J2EE/ Standard APIs
– Multi-tier client/server
replacement – Deployment scale: Clients, Integration
– Thinner client – Web UI & protocol stack
– Service-based design • Multichannel
center (re-use,
integration) – Browsers
– Text messaging (IM, SMS, …)
– Lighter-weight client
sessions – Voice
– Heavier-weight database – And programmed client
sessions • Personalization, portal, content
– Synchronous & management, …
asynchronous – Focus on stateful services (session-
processing, … orientation)
– Web services, …
 J2EE Architectures

• Winning architecture so far • Still seeking traction?

– Small number of bigger – Legacy TP Monitor kernels
processes vs. Address-space • E.g., Tuxedo/M3,
isolation TX Series/Comp. Broker,
• JVM image size CICS?
• Java code safety • Impedance mismatch
• Re-entrant application with Java runtime
logic • Time to market
– Predominately Java-based • JVM runtime
• Porting/certification costs modification?
– OODBMS
• Time to market
• Troubleshooting • E.g., Gemstone
– ? ORDBMS ?
… with C optimizations
(socket muxing, SSL, …)
– Modeled after first successes
Web Application Server
Architectural Differentiation
• 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, …
Domains & Clusters
Domain

Cluster
Cluster Cluster

Browsers Web Servlet Object Databases

Servers Engines Servers
 Example: Session Protection
Via Memory Copy

• Primary/secondary replication of Session State

#1 #2 A

B
B
ACB

Browser
C
Web
Servers
(or WAP Servlet/JSP Engines
Gateway) (& EJB Session Beans)
 Types of Clustered
Services

State in Memory Persistence Transactional Example

memory Repl. Semantics APIs
EJB/JMS/JDBC/
1 Stateless No JCA factories,
EJB Stateless

2 Conversational Yes JSP/Servlet Ses.,

Optional Optional
EJB Stateful
Depends on JSP fragments,
3 Cached Yes Depends Depends Replication EJB Entity
JMS destinations,
4 Exactly-Once Yes No Yes Yes JTA Tx Managers,
Admin Server
Consolidation Over
“Commoditization”
• Complex software platforms do not commoditize
easily -- 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
–
Emerging Battle Royale
• Java/J2EE vs. Microsoft .NET
– Competition is good fun
– Coexistence will be the rule
– Best news: Web services convergence
• Java/J2EE advantages

Stay tuned?…
Demand For Integration
• Large companies may have 5K - 20K applications
• Proliferation will continue
• Today’s 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 today’s new app’s are
built for Web browsers
– Tomorrow’s will be built
for Web services
Future Integration Brokers
Will 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 m×n problem, get to critical mass, ISV ownership
• Quality of service (Software clustering)
• Operations, administration, & management
• Security, caching, transactions, and so on …
 Web Services Key
Design Considerations #1
Web Services should be “coarse grained”
• Export services, not components/objects
– Don’t 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
Web Services Key
Design 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
 Web Services Key
Design 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
 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 (like
natural languages)
In Memory