HPTS Panel Web Application Server Architecture Scott Dietzen

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 • Web. Logic BEA – New name essential for investment & competition • Architecture – J 2 EE in general – Web. Logic in specific • Instead of J 2 EE vs. . NET, … • Integration “in the large” – The next J 2 EE (&. 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 10 K customers) Java (and C#) J 2 EE/ 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, …

J 2 EE 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/M 3, 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 J 2 EE 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 Browsers Web Serve rs Cluster Servlet Engine s Object Databases Servers

Example: Session Protection Via Memory Copy • Primary/secondary replication of Session State #1 #2 A B BC AB Browser C Web Servers (or WAP Gateway) Servlet/JSP Engines (& EJB Session Beans)

Types of Clustered Services State in Memory Persistenc Transactional e memory Repl. Semantics 1 Stateless No 2 Conversational Yes Optional 3 Cached Yes Depends 4 Exactly-Once Yes No Yes Depends on Replicatio n Yes Example APIs EJB/JMS/JDB C/ JCA factories, EJB Stateless JSP/Servlet Ses. , EJB Stateful 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, DB 2, SQL Server, … (SQL) Web. Logic, Web. Sphere, i. AS, … (J 2 EE) • 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 – J 2 EE: BEA, IBM, Oracle – Microsoft

Emerging Battle Royale • Java/J 2 EE vs. Microsoft. NET – Competition is good fun – Coexistence will be the rule – Best news: Web services convergence • Java/J 2 EE advantages Stay tuned? …

Demand For Integration • Large companies may have 5 K - 20 K 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 (J 2 EE &. 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