HPTS Panel: Web Application Server Architecture
description
Transcript of HPTS Panel: Web Application Server Architecture
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