Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Distributed Computing with The BEA WebLogic Server Dean Jacobs Architect BEA Systems."— Presentation transcript:

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

2 WebLogic Server Clustered Services Clustering Infrastructure Web Services Outline

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

4 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)

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 Browsers Web Servers Servlet Engines (JSP) WebLogic Cluster Architecture Object Servers (JMS/EJB) Database (JDBC)

8 WebLogic Server Clustered Services Clustering Infrastructure Web Services Outline

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 1 Stateless 2 Conversational 3 Cached 4 Optimistic 5 Migratable State in memory Persistent Transactional Reads No Some Yes Some APIs EJB/JMS/JDBC/JCA factories, JSP SSS, EJB Stateless/Entity JSP SSS, EJB Stateful JSP fragments, EJB Entity JMS destinations, JTA Tx Managers, Admin Server

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

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

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-load and 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 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 6Distributed concurrency control 6Centralized lock manager 4Use the database 4Partition 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 WebLogic Server Clustered Services Clustering Infrastructure Web Services Outline

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 Browsers Web Servers Servlet Engines Domains - Clusters - Tiers Object Servers Databases Domain Cluster

22 Domain Machine Node Manager Browser Server Admin Server Configuration Repository Monitoring SNMP 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 WebLogic Server Clustered Services Clustering Infrastructure Web Services Outline

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

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


Download ppt "Distributed Computing with The BEA WebLogic Server Dean Jacobs Architect BEA Systems."

Similar presentations


Ads by Google