Web App Server Architecture

8/8/2019 Web App Server Architecture

1/17

HPTS Panel:Web Application ServerArchitecture

Scott Dietzen, Ph.D.CTO, Server Division

BEA Systems


2/17

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


3/17

Whats the same?

The vendors

Multi-tier client/server

replacement Thinner client

Service-based designcenter (re-use,integration)

Lighter-weight client

sessions Heavier-weight database

sessions

Synchronous &asynchronousprocessing,

Web Application Server =Next Gen. TP Monitor

Whats 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, contentmanagement,

Focus on stateful services (session-orientation)

Web services,


4/17

Winning architecture so far

Small number of biggerprocesses vs. Address-spaceisolation

JVM image size Java code safety

Re-entrant applicationlogic

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 ?


5/17

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 ServerArchitectural Differentiation


6/17

BrowsersWeb

Server

s

Servlet

Engines

Domains & Clusters

Object

Servers

Databases

Domain

Cluster Cluster

Cluster


7/17

#1 #2

Example: Session ProtectionVia 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


8/17

Types of ClusteredServices

1 Stateless

2 Conversational

3 Cached

4 Exactly-Once

State in

memoryPersistence Transactional

Semantics

No

Depends

onReplication

YesYesYes

Yes

Yes

Depends

Example

APIs

EJB/JMS/JDBC/

JCA factories,

EJB Stateless

JSP/Servlet Ses.,

EJB Stateful

JSP fragments,EJB Entity

JMS

destinations, JTA

Tx Managers,

Admin Server

Memory

Repl.

Optional

Depends

No

Optional


9/17

Complex software platforms do not commoditizeeasily -- 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 OverCommoditization


10/17

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?


11/17

Demand For Integration

Large companies may have 5K - 20K applications

Proliferation will continue

Todays 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 todays new apps are

built for Web browsers

Tomorrows will be builtfor Web services


12/17

Future Integration BrokersWill 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 mn 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 mn problem, get to critical mass, ISV ownership

Quality of service (Software clustering)

Operations, administration, & management

Security, caching, transactions, and so on


13/17

Web Services KeyDesign Considerations #1

Web Services should be coarse grained

Export services, not components/objects

Dont 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/17


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/17


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/17

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 (likenatural languages)


17/17

In Memory

Documents

Web App Server Architecture