Scribd Logo
Upload

Welcome to Scribd!

  • 74 views

    Web App Server Architecture

    Uploaded by

    santhsohdruv
    The document discusses the architecture of web application servers and their role as the next generation of transaction processing monitors. It covers how web application servers are similar to traditional TP monitors in areas like multi-tier client/server design, but are different in terms of larger market size and focus on stateful web services. The document also summarizes key considerations for web application server architecture, clustering services, and the future of application integration platforms.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPT, PDF, TXT or read online from Scribd

    Web App Server Architecture

    Uploaded by

    santhsohdruv
    74 views17 pages
    The document discusses the architecture of web application servers and their role as the next generation of transaction processing monitors. It covers how web application servers are similar to traditional TP monitors in areas like multi-tier client/server design, but are different in terms of larger market size and focus on stateful web services. The document also summarizes key considerations for web application server architecture, clustering services, and the future of application integration platforms.

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PPT, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document discusses the architecture of web application servers and their role as the next generation of transaction processing monitors. It covers how web application servers are similar to traditional TP monitors in areas like multi-tier client/server design, but are different in terms of larger market size and focus on stateful web services. The document also summarizes key considerations for web application server architecture, clustering services, and the future of application integration platforms.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPT, PDF, TXT or read online from Scribd
    Download as ppt, pdf, or txt
    74 views17 pages

    Web App Server Architecture

    Uploaded by

    santhsohdruv
    The document discusses the architecture of web application servers and their role as the next generation of transaction processing monitors. It covers how web application servers are similar to traditional TP monitors in areas like multi-tier client/server design, but are different in terms of larger market size and focus on stateful web services. The document also summarizes key considerations for web application server architecture, clustering services, and the future of application integration platforms.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPT, PDF, TXT or read online from Scribd
    Download as ppt, pdf, or txt
    of 17

    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
    – J2EE in general
    – WebLogic in specific
    • Instead of J2EE vs. .NET, …
    • Integration “in the large”
    – The next J2EE (& .NET) frontier
    Web Application Server =
    Next Gen. TP Monitor
    • What’s different
    – Market size (e.g., BEA 10K customers)
    • What’s the same?
    – Java (and C#)
    – The vendors
    – J2EE/ Standard APIs
    – Multi-tier client/server
    replacement – Deployment scale: Clients, Integration
    – Thinner client – Web UI & protocol stack
    – Service-based design • Multichannel
    center (re-use,
    integration) – Browsers
    – Text messaging (IM, SMS, …)
    – Lighter-weight client
    sessions – Voice
    – Heavier-weight database – And programmed client
    sessions • Personalization, portal, content
    – Synchronous & management, …
    asynchronous – Focus on stateful services (session-
    processing, … orientation)
    – Web services, …
    J2EE Architectures

    • Winning architecture so far • Still seeking traction?


    – Small number of bigger – Legacy TP Monitor kernels
    processes vs. Address-space • E.g., Tuxedo/M3,
    isolation TX Series/Comp. Broker,
    • JVM image size CICS?
    • Java code safety • Impedance mismatch
    • Re-entrant application with Java runtime
    logic • Time to market
    – Predominately Java-based • JVM runtime
    • Porting/certification costs modification?
    – OODBMS
    • Time to market
    • Troubleshooting • E.g., Gemstone
    – ? ORDBMS ?
    … with C optimizations
    (socket muxing, SSL, …)
    – Modeled after first successes
    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, …
    Domains & Clusters
    Domain

    Cluster
    Cluster Cluster

    Browsers Web Servlet Object Databases


    Servers Engines Servers
    Example: Session Protection
    Via Memory Copy

    • Primary/secondary replication of Session State

    #1 #2 A

    B
    B
    ACB

    Browser
    C
    Web
    Servers
    (or WAP Servlet/JSP Engines
    Gateway) (& EJB Session Beans)
    Types of Clustered
    Services

    State in Memory Persistence Transactional Example


    memory Repl. Semantics APIs
    EJB/JMS/JDBC/
    1 Stateless No JCA factories,
    EJB Stateless

    2 Conversational Yes JSP/Servlet Ses.,


    Optional Optional
    EJB Stateful
    Depends on JSP fragments,
    3 Cached Yes Depends Depends Replication EJB Entity
    JMS destinations,
    4 Exactly-Once Yes No Yes Yes 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, 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
    –
    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?…
    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 …
    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

    You might also like