distributed computing with the bea weblogic server dean jacobs architect bea systems
TRANSCRIPT
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