HPTS Panel: Web Application Server Architecture

1
HPTS PanelWeb Application Server Architecture

• Scott Dietzen, Ph.D.
• CTO, Server Division
• BEA Systems

2
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

3
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, content management,
• Focus on stateful services (session-orientation)
• Web services,

• Whats 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,

4
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 ?

5
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,

6
Domains Clusters
Domain
Cluster
Cluster
Cluster
Browsers
Web Servers
Servlet Engines
Object Servers
Databases
7
Example Session Protection Via Memory Copy

• Primary/secondary replication of Session State

A
B
A B
B C
Browser
C
Web Servers (or WAP Gateway)
Servlet/JSP Engines ( EJB Session Beans)
8
Types of Clustered Services
State in memory
Transactional Semantics
Example APIs
Memory Repl.
Persistence
EJB/JMS/JDBC/ JCA factories, EJB Stateless
1 Stateless
No
JSP/Servlet Ses., EJB Stateful
2 Conversational
Yes
Optional
Optional
Depends on Replication
JSP fragments, EJB Entity
3 Cached
Yes
Depends
Depends
JMS destinations, JTA Tx Managers, Admin Server
4 Exactly-Once
Yes
Yes
Yes
No
9
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

10
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?
11
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 built for Web services

12
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 mn problem, get to critical mass, ISV
  ownership
• Quality of service (Software clustering)
• Operations, administration, management
• Security, caching, transactions, and so on

13
Web Services Key Design 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

14
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

15
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

16
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)

17
In Memory