Distributed Computing with

The BEA WebLogic Server

Dean Jacobs

Architect

BEA Systems

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

• WebLogic Server

• Clustered Services

• Clustering Infrastructure

• Web Services

Outline

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Browsers Web Server DatabaseServlet

Engine

Application Server Components

Object Server

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Java 2 Enterprise Edition (J2EE)

The Application Server platform for Java

• Java Servlets / Java Server Pages (JSP) • Enterprise Java Beans (EJB)

– Stateless Session, Stateful Session, Entity

• Java Messaging Service (JMS)• Remote Method Invocation (RMI)• Java Database Connection (JDBC)• Java Connector Architecture (JCA)• Java Naming & Directory Interface (JNDI)• Java Transaction API (JTA)

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

The BEA WebLogic Server

• All Java, clean-room implementation of the J2EE

• Shipping basic APIs since 1996

• Most widely-used Application Server on the market

• Won every major industry award

• Associated BEA product: TUXEDO – Distributed TP Monitor– Originally developed at Bell Labs in 1984– Widely used for 24x7 OLTP applications– WLS and TUXEDO teams have been combined

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

WebLogic Clusters

• A WebLogic cluster is a collection of servers that coordinate their actions to provide scalable and highly-available services

• Scalable services – Add or remove servers as needed– Load balance requests– Concentrate communication

• Highly-available services – No single point of failure– Failover requests

Load Balancing & Failover Points#1 #2 #3 #4

Browsers Web Servers

Servlet Engines (JSP)

WebLogic Cluster Architecture

Object Servers

(JMS/EJB)

Database (JDBC)

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

• WebLogic Server

• Clustered Services

• Clustering Infrastructure

• Web Services

Outline

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Scalability Tradeoffs

• WebLogic offers a variety of options that allow a trade-off between scalability and availability/consistency

• These options are associated with services that maintain state in memory between invocations

• For services where such state is not fundamentally persistent, WebLogic offers in-memory primary/secondary replication to improve availability (at the expense of some scalability)

• For services where such state is fundamentally persistent, WebLogic offers “non-transactional” reads to improve scalability (at the expense of some consistency)

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Non-Transactional Reads

• Application Servers are often used for pre-fullfillment browsing, which does not require transactional reads– Classic example: airline reservations– New-age example: on-line catalog shopping

• Essential to provide scalable, non-transactional reads; within one transaction, allow data to– be stale – change, perhaps even move backward in time (after failover) – come from different database snapshots

• Databases also do this; the real issue is whether the Application Server further weakens database consistency guarantees

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Types of Clustered Services

1 Stateless

2 Conversational

3 Cached

4 Optimistic

5 Migratable

State in memory

Persistent Transactional Reads

No

No

No

Some

YesYesYes

Yes

Yes

Yes

Yes

Some

APIs

EJB/JMS/JDBC/JCA factories, JSP SSS, EJB Stateless/Entity

JSP SSS, EJB Stateful

JSP fragments, EJB Entity

EJB Entity

JMS destinations, JTA Tx Managers,Admin Server

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Server 1

O1 O2

eng

acme

O1

grompler

Server 2

O1 O2

eng

acme

O2

grompler

Client

O1 O2

1 Stateless Services

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

#1 #2

2 Conversational Services

Browser

Web Servers

Servlet Engines

BA B

C

B C

A

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

3 Cached Services

• Caches data obtained during an invocation so it can be read in subsequent invocations by the same or other clients

• Multiple instances in the cluster

• Flush at regular intervals (TTL)– Best when data is frequently updated

• Flush after an update completes– Best when data is infrequently updated– Implemented using multicast– Manual flush API to allow notification of “backdoor” updates

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

3 Cached Services

• EJB - “Read-only” entity beans– Flush at regular intervals or when an update occurs– Non-transactional reads

• JSP - Tags to cache computed page fragments in memory– Flush at regular intervals

• In general, as the cache moves closer to the user– the benefit of a cache hit increases, however– it is harder to keep the data in sync

• The next step would be to cross the Internet (Akamai/Inktomi)– Worthwhile only for data that will be hit many times per sync– More natural to pre-load and refresh at regular intervals (data

warehouse) or after update (data replication)

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Transactional Reads

• Authoritative copy of the state in a database

• The service maintains a copy in memory between invocations

• Reads by any client use the in-memory copy

• The challenge: Maintain consistency with the database given updates that go through other instances or the “backdoor”

• Possible solutions Distributed concurrency control Centralized lock manager Use the database Partition so exactly one copy of each data item

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

4 Optimistic Services

• Use the database to implement optimistic concurrency control for transactions with writes– No protection for read-only transactions

• Upon commit, compare the before-and-after values of fields that were read and throw a concurrency exception if they don’t match– Can be done fairly efficiently using UPDATE-WHERE– Does not require modification of the database schema

• To minimize the likelihood of such exceptions, flush after updates occur (but not within the transaction)

• Does not ensure serializability in that, for example, an increment and decrement of the same field will look like it was not modified– This is a feature in that it allows safe but non-serializable transactions

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

5 Migratable Services

• Partition the data and assign each item to exactly one instance

• Concurrency control can then be local to the instance

• Must be restarted or migrated upon failure of the instance– Assume data is persistent and service re-establishes state on its own

• Limitations on usage– Applications may lose co-location– May be hard to partition the data– Problematic to query across partitions– No backdoor updates

• JMS Destinations, JTA Tx Managers, Admin Server

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

• WebLogic Server

• Clustered Services

• Clustering Infrastructure

• Web Services

Outline

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Clusters and Domains

• Clusters– The scope of load balancing and failover– More tightly-coupled to facilitate this functionality: multicast is used to

• derive cluster membership• advertise which services are available on which servers

• Domains– The scope of operations, administration, and management– Boundary of resource ownership– Boundary of non-interposed transactions– A domain may contain many clusters

Browsers Web Servers

Servlet Engines

Domains - Clusters - Tiers

Object Servers

Databases

Domain

Cluster ClusterCluster

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Domain

Machine

Node Manager

Browser

ServerAdmin

Server Server

ConfigurationRepositoryMonitoring

SNMP

Domain Startup

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Distribution of Configuration and Deployment Information

• The Admin Server uses a special data replication protocol

• Updates packaged as incremental deltas between versions

• Data can be persistently cached on local disks– Speeds startup by reducing the amount of data to be transferred– Allows startup/restart when the Admin Server is unreachable

• Seamlessly integrates two distribution methods– One-phase Servers commit to new data as soon as it is received– Two-phase Prepare and commit phases with the possibility of abort

• Ensures a temporarily unavailable server eventually receives all committed updates– Sends regular multicast heartbeats containing the current version number

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Node Manager

• Starts up and shuts down its servers

• Monitors the health of its servers– blocks on a socket receive– periodically invokes areYouOK() servlet– subsystems in server can register with this servlet

• Option to automatically restart failed or ailing servers– Attempts to gracefully shutdown ailing servers using a lifecycle API– Limited number of restart attempts to avoid thrashing

• Alternatively, a server can be managed by an HA framework– Faster failover– Works even if machine fails or failed process can’t be killed

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Migratable Services

• A migratable service can be deployed on a fixed server– Availability by restart, manual migration, or HA framework

• A migratable service can be deployed to a named target associated with a list of potential hosts

• All services deployed on a target are instantiated on the same host

• If the host fails, the services are automatically migrated together

• Sophisticated machinery to avoid split-brain syndrome– Action only if cluster contains a quorum– Paxos algorithm used to elect a leader that chooses hosts and renews leases– Chosen host must check lease before servicing each request– A new host cannot take over until the previous lease times out

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

• WebLogic Server

• Clustered Services

• Clustering Infrastructure

• Web Services

Outline

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Characteristics of Web Services

• Asynchronous– Any participant can initiate communication with any other participant– May send requests or responses

• Long-running– Operations can take a long time to complete– Essential to manage the context on each end during this time

• Loosely-coupled– Industry-standard, low-functionality protocols enhance interoperability– Self-describing payloads enhance compatibility

• Coarse-grained– Remotely-invoked operations have significant size– Document transfer an attractive model

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

J2EE Application Servers are largely designed for synchronous short-running interactions with

proprietary (programmatic) clients

Web Services Platform Requirements

• XML over HTTP/SMTP/... to support loosely-coupled, coarse-grained interactions

• Distributed system plumbing to support asynchronous, long-running interactions with neutral programmatic clients

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

WebLogic Server Web Services Platform

• Support for neutral clients– XML over HTTP/SMTP/… of prime importance– Support enhancements for functionality and performance (at the expense

of loose coupling and perhaps neutrality)

• Tie into the front end of JMS– Support for neutral clients– Neutral and long-running clients cannot use JMS Sessions– Reliability and ordering guarantees, if any, must be otherwise achieved – A session-less front end can be made more scalable and available– Message driven beans to invoke services and send responses

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

WebLogic Server Web Services Platform

• Tie into session management– Map external conversation IDs to internal session IDs– Simultaneous access by several operations in a cluster– Vanilla entity beans reliable but hit the disk every time– “Non-persistent” entity beans to trade reliability for performance– Place in cluster relative to incoming and outgoing JMS Destinations

• Long-running transactions– Compensating transactions?

• Administration– Monitoring, tracing, debugging across loosely-coupled systems

• Security– Third-party authentication and user profile services

www.bea.com