Transcript Analyst Conference - HPTS

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
• What’s the same?
– The vendors
– Multi-tier client/server
replacement
– Thinner client
– Service-based design
center (re-use,
integration)
– Lighter-weight client
sessions
– Heavier-weight database
sessions
– Synchronous &
asynchronous
processing, …
–
–
–
–
–
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, content
management, …
– Focus on stateful services (sessionorientation)
– Web services, …
J2EE Architectures
• Winning architecture so far
– Small number of bigger
processes vs. Address-space
isolation
• JVM image size
• Java code safety
• Re-entrant application
logic
– Predominately Java-based
• Porting/certification costs
• Time to market
• Troubleshooting
… with C optimizations
(socket muxing, SSL, …)
– Modeled after first successes
• 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 ?
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
Browsers
Web
Servers
Cluster
Servlet
Engines
Object Databases
Servers
Example: Session Protection
Via Memory Copy
• Primary/secondary replication of Session State
#1
#2
A
B
B
AC
B
Browser
C
Web
Servers
(or WAP
Gateway)
Servlet/JSP Engines
(& EJB Session Beans)
Types of Clustered
Services
State in Memory Persistence
memory Repl.
1 Stateless
No
2 Conversational
Yes
3 Cached
4 Exactly-Once
Yes
Yes
Transactional
Semantics
Example
APIs
EJB/JMS/JDBC/
JCA factories,
EJB Stateless
Optional
Depends
No
JSP/Servlet Ses.,
EJB Stateful
Optional
Depends
Yes
Depends on
Replication
Yes
JSP fragments,
EJB Entity
JMS destinations,
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
– Microsoft
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