hpts panel: web application server architecture
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
HPTS Panel:Web Application Server
Architecture
Scott Dietzen, Ph.D.CTO, Server Division
BEA Systems
• 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
• 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, …
Web Application Server = Next Gen. TP Monitor
• What’s 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, …
• 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
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 ?
• 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 Server Architectural Differentiation
Browsers Web Servers
Servlet Engines
Domains & Clusters
Object Servers
Databases
Domain
Cluster ClusterCluster
#1 #2
Example: Session Protection Via 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
Types of Clustered Services
1 Stateless
2 Conversational
3 Cached
4 Exactly-Once
State in memory
Persistence Transactional Semantics
No
Depends onReplication
YesYesYes
Yes
Yes
Depends
ExampleAPIs
EJB/JMS/JDBC/JCA factories, EJB Stateless
JSP/Servlet Ses., EJB Stateful
JSP fragments, EJB Entity
JMS destinations, JTA Tx Managers,Admin Server
MemoryRepl.
Optional
Depends
No
Optional
• 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
Consolidation Over “Commoditization”
• 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?…
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 …
• 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