Distributed Computing

with
The BEA WebLogic Server

Dean Jacobs
Architect
BEA Systems
Outline
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• WebLogic Server
• Clustered Services
• Clustering Infrastructure
• Web Services
Application Server Components
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Web Servlet Object

Browsers Database
Server Engine 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
 WebLogic Cluster Architecture

Load Balancing & Failover Points

#1 #2 #3 #4

Servlet Object Database

Browsers Web
Engines Servers (JDBC)
Servers
(JSP) (JMS/EJB)
Outline
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• WebLogic Server
• Clustered Services
• Clustering Infrastructure
• Web Services
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
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

State in Persistent Transactional APIs

memory Reads
EJB/JMS/JDBC/JCA
1 Stateless No factories, JSP SSS,
EJB Stateless/Entity
JSP SSS,
2 Conversational Yes No EJB Stateful

JSP fragments,
3 Cached Yes Some No EJB Entity

4 Optimistic Yes Yes Some EJB Entity

JMS destinations,
5 Migratable Yes Yes Yes JTA Tx Managers,
Admin Server
1 Stateless Services
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Server 1 Server 2

O1 O2

acme acme

eng eng

grompler grompler
O1 O2 O1 O2

O1 O2

Client
2 Conversational Services
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

#1 #2 A

B
B
ACB

Browser
C
Web
Servers
Servlet
Engines
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
Outline
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• WebLogic Server
• Clustered Services
• Clustering Infrastructure
• Web Services
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
 Domains - Clusters - Tiers
Domain

Cluster
Cluster Cluster

Browsers Web Servlet Object Databases

Servers Engines Servers
Domain Startup
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Domain

Machine

Server Server

Node
Manager

Admin
Server

SNMP Configuration
Monitoring Browser Repository
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
Outline
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• WebLogic Server
• Clustered Services
• Clustering Infrastructure
• Web Services
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
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

J2EE Application Servers are largely designed

for synchronous short-running interactions with
proprietary (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