Transcript analyst presentaiton

Distributed Computing
with
The BEA WebLogic Server
Dean Jacobs
Architect
BEA Systems
Outline
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
• WebLogic Server
• Clustered Services
• Clustering Infrastructure
• Web Services
Application Server Components
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
Browsers
Web
Server
Servlet
Engine
Object
Server
Database
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
Browsers
#2
Web
Servers
#3
Servlet
Engines
(JSP)
#4
Object
Servers
(JMS/EJB)
Database
(JDBC)
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
memory
1 Stateless
No
2 Conversational
Yes
Persistent
Transactional
Reads
EJB/JMS/JDBC/JCA
factories, JSP SSS,
EJB Stateless/Entity
JSP SSS,
EJB Stateful
No
3 Cached
Yes
Some
No
4 Optimistic
Yes
Yes
Some
5 Migratable
Yes
APIs
Yes
Yes
JSP fragments,
EJB Entity
EJB Entity
JMS destinations,
JTA Tx Managers,
Admin Server
1 Stateless Services
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
Server 1
Server 2
O1
O2
acme
acme
eng
eng
grompler
O1 O2
grompler
O1 O2
O1 O2
Client
2 Conversational Services
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
#1
#2
A
B
B
AC
B
Browser
Web
Servers
C
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
Browsers
Web
Servers
Cluster
Servlet
Engines
Object Databases
Servers
Domain Startup
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
Domain
Machine
Server
Server
Node
Manager
Admin
Server
SNMP
Monitoring
Browser
Configuration
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, coarsegrained interactions
• Distributed system plumbing to support asynchronous, longrunning 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