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