1 / 17

HPTS Panel: Web Application Server Architecture

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

dewei
Télécharger la présentation

HPTS Panel: Web Application Server Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HPTS Panel:Web 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 • 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, … • 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, …

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

  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 Multicastvs. 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. #1 #2 Example: Session Protection Via Memory Copy • Primary/secondary replication of Session State A B B C A B 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 Depends Yes 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 • 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

  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 m×n 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 • 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

  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

More Related