Distributed Computing with The BEA WebLogic Server

1. Distributed Computing with The BEA WebLogic Server Dean Jacobs Architect BEA Systems

2. Outline • WebLogic Server • Clustered Services • Clustering Infrastructure • Web Services

3. Application Server Components Web Server Servlet Engine Object Server Browsers Database

4. Java 2 Enterprise Edition (J2EE) • The Application Serverplatform 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)

5. 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

6. 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

7. Load Balancing & Failover Points #1 #2 #3 #4 WebLogic Cluster Architecture Servlet Engines (JSP) Object Servers (JMS/EJB) Database (JDBC) Browsers Web Servers

8. Outline • WebLogic Server • Clustered Services • Clustering Infrastructure • Web Services

9. 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)

10. 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

11. Types of Clustered Services State in memory Persistent Transactional Reads APIs EJB/JMS/JDBC/JCA factories, JSP SSS, EJB Stateless/Entity 1 Stateless No JSP SSS, EJB Stateful 2 Conversational Yes No JSP fragments, EJB Entity 3 Cached Yes Some No 4 Optimistic Yes Yes Some EJB Entity JMS destinations, JTA Tx Managers, Admin Server 5 Migratable Yes Yes Yes

12. 1 Stateless Services Server 1 Server 2 O1 O2 acme acme eng eng grompler grompler O1 O2 O1 O2 O1 O2 Client

13. #1 #2 2 Conversational Services A B B C A B Browser C Web Servers Servlet Engines

14. 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

15. 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-loadand refresh at regular intervals (data warehouse) or after update (data replication)

16. Transactional Reads • Authoritative copy of the state in a database • The service maintains a copyin 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

17. 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

18. 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

19. Outline • WebLogic Server • Clustered Services • Clustering Infrastructure • Web Services

20. 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

21. Domains - Clusters - Tiers Domain Cluster Cluster Cluster Browsers Web Servers Servlet Engines Object Servers Databases

22. Domain Machine Server Server Admin Server Node Manager SNMP Browser Monitoring Configuration Repository Domain Startup

23. 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

24. 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

25. 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

26. Outline • WebLogic Server • Clustered Services • Clustering Infrastructure • Web Services

27. 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

28. 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

29. 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

30. 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

31. www.bea.com