BEA WEBLOGIC SERVER

Achieving Scalability and High

Availability for E-Commerce and
Other Web Applications

Clustering the BEA WebLogic Application Server

June 1999
Executive Summary

Server-side Java technologies have grown up over the past year. Spearheaded by BEA, IBM,
Sun, HP, and Oracle, Java-based Web application servers have emerged as the preferred platform
for E-Business—that is, the best way to deliver information services (a.k.a., dynamic content)
across the Web. Today, Java and BEA WebLogic are deployed within numerous business-critical
Web applications, including systems for customer self-service, supply-chain & distribution-
channel management, trading, banking, provisioning, and so on. Deployments can be found in
large consumer-oriented Websites (Amazon.com, Priceline.com, WebMD.com), financial
services (FirstUSA, Charles Schwab), and telecommunications (Qwest, Covad
Communications). Successes like these have made WebLogic the market leader in systematic
Web application servers (Gartner Group) and Enterprise JavaBean technology (with 70% market
share according to Upstream Consulting).

The Internet has raised the bar for business-critical systems: It’s one thing to experience an
internal slowdown or outage, but it’s quite another when the failure directly impacts a customer
or business partner across the Web. Internet failures and performance glitches have become hot
news stories—so even contained problems will impact your credibility in the broader market.
What’s more, Internet users are increasingly demanding “dial tone” quality service—always
there and without noticeable delays. If you’re unable to deliver it, then your competitors are
going to get the opportunity to do so.

So high availability and scalability/performance are imperative for E-Business. Both depend
on transparent replication, load balancing, and failover—the combination of which we call
clustering. Software-based clustering protects your Web application investment by
• Assigning work requests across available servers for optimal resource utilization;
• Seamlessly rerouting requests in the event of a failure in either the system or application; and
• Allowing servers to be dynamically added or removed from the on-line cluster to
accommodate external changes in demand or internal changes in infrastructure.

The challenges of software-only clustering have been met by a combination of careful state
management and highly optimized protocols based on new commodity technologies such as IP
multicast. You should probably anticipate 16-18 months from when a vendor first offers general
availability of a full implementation of Enterprise JavaBeans (EJB) 1.0/1.1 (including both
session and entity beans) until that vendor can provide comprehensive clustering support that
includes EJB. BEA has been shipping EJB technology since 2Q97, and has provided clustering
services since 4Q98.

In general, experience with the BEA WebLogic Server has shown that Java and EJB do not pose
limitations on performance as previously believed, and in fact can deliver the levels of scalability
and high availability required for mission-critical Web-based applications. Performance
measurements show that WebLogic clusters are both fast and highly scalable across Unix, NT,
and AS/400 configurations:
• A single WebLogic server (running on a 6-way Unix processor) simultaneously served
50,000 active clients, executing over 2500 EJB round-trip method invocations per second.

1
• Remote Method Invocation (RMI) benchmarks have shown that the throughput of a
WebLogic cluster servicing 10,000 active client applications scales linearly up to 10 single-
processor PCs, providing a maximum of 7942 round-trip method invocations per second.
• A WebLogic cluster of 12 servers running on three 4-way PC servers was able to serve 2675
dynamic Web pages per second, or 231 million pages per day (a load 38% greater than what
the Internet’s busiest site, Yahoo!, reported for December ’98). In this benchmark, WebLogic
provided linear scaling—averaging 223 pages per second per CPU.

(Please note: There are no database I/O costs included in each of the above results, and hence
they should not be used for capacity planning. Nevertheless, they do prove out the performance
and scalability of Java, WebLogic, and our clustering solution.)

The most dramatic performance gains—up to an order of magnitude—generally result from

replacing the existing ad hoc infrastructure of CGI and PERL driving most commercial Websites
today. However, we have also been able to deliver two- and three-fold performance
improvements to customers replacing an existing proprietary Web application server (in some
cases, with very little impact on the existing Web applications).

Enterprise Java Prerequisites

The hyper-competitive Web application server market has dramatically matured over the past
year. Then, there were almost as many different programming models as there were application
servers. Now, Java 2 Enterprise Edition (J2EE or Enterprise Java for short) has emerged as
the standard programming model for E-Commerce and other Web applications. Enterprise Java
is now promoted as the standard for Web application servers by the likes of BEA, IBM, Sun,
Hewlett-Packard, Oracle, and Novell. As a result, compliance with the J2EE standards has
become the primary criteria in selecting Web application servers.

Using J2EE, dynamic Web content is constructed with Servlets (by which we mean HTTP
Servlets) and a set of tags and conventions for integrating static and dynamic HTML called Java
Server Pages (JSP) and its predecessor Java HTML (JHMTL). With JSP (and JHTML), it is
possible to develop Web content using standard Web publishing tools (like Macromedia
Dreamweaver, Symantec VisualPage, or Microsoft Front Page), and standard Java tools (like
Symantec VisualCafé, IBM Visual Age, Borland JBuilder, or Microsoft Visual J++). The Web
page compilation of JSP then provides for the automatic integration of dynamically generated
results from Java programs within existing HTML pages.

The J2EE standard for server-side business logic is Enterprise JavaBeans (EJB) and the host of
supporting services in Java Database Connectivity (JDBC), Remote Method Invocation
(RMI), Java Messaging Services (JMS), and the Java Naming and Directory Interface
(JNDI). The Enterprise JavaBean component model dramatically simplifies the task of
assembling business applications out of reusable parts, and makes it very easy to export business
services across the network. There are two types of Enterprise JavaBeans:
• Session beans -- Session beans encapsulate business services such as a bank teller. Session
beans are used exclusively by a particular client for the course of a transaction or session.

2
 When the session concludes, the bean is returned to the pool to serve another client. Session
beans can either be stateless or stateful. The bank teller might be best represented as a
stateless bean, while a Web retail agent that manages your shopping cart would be stateful.
Replicating stateful session beans requires the ability to reconstitute state on a new server in
the event that the hosting server fails.
• Entity beans – Entity beans are very different from session beans. An entity bean is globally
unique across a system as it encapsulates specific data items represented in a database. The
database may be relational or object-oriented (and the bean logic can be defined to work
across different databases and data models). Your personal account, your portfolio, and your
order are entity beans. Entity beans are not recycled in the sense of session beans, since you
don’t want your account to ever go away (unless you intentionally delete it). An entity bean
may nevertheless be deactivated—which entails garbage collecting the in memory
representation if it hasn’t been used for awhile so that it doesn’t take up space that could be
used by active beans.

The predominant drawback to the clustering technologies provided by the majority of Web
application servers today is that they do not yet support these Java-industry standards. Instead,
they require that you introduce proprietary tags into your Web content and proprietary logic into
your Java applications—limiting your investment protection by locking you into only deploying
on their server and locking you out of using business components developed for any other server.

BEA WebLogic Server provides the richest and most comprehensive implementation of the Java
2 Enterprise Edition standards, and has positioned itself well beyond the competition in the
clustering technologies.

3
Introduction

So if most every Web application server vendor has endorsed the J2EE standards (at least on
paper), how will vendors compete going forward? One sure-fire candidate for differentiation is
clustering.

The term “clustering” suggests the close cooperation of two or more replicated servers to ensure
fast, continuous service to users. Clustering for Web applications means delivering scalability
(via automated load balancing across replicas) and high availability (via automated failover
across replicas). Clustering services provided by Web application servers, then, must ensure the
following:
• No bottlenecks to scaling – New servers can be easily and dynamically added to the
configuration as necessary to meet increasing user demand, and that the overall request load
is optimally distributed among the servers so that resources remain fully utilized. As some of
our competitors have shown, it is very difficult to reliably manage application and user state
without introducing scaling bottlenecks.
• No single points of failure that could impact availability – Requests must automatically
failover from non-working components to working components. Moreover, application and
user state must be protected (via replication) to ensure that any failures that occur (e.g., a
server crash) can be fully masked from the user and application.
• Transparency to your applications and application developers – Your programmers should
not have to deal with the intricacies of replication, request routing, load balancing, and
failover. Moreover, you should be able to buy off-the-shelf application components, and
deploy them without modification on a clustered Web application server.
• Single-system image to your administrators – Your system administrators must be
empowered to manage clustered services and servers as a single logical resource. This greatly
simplifies operations and helps prevent any inadvertent introduction of inconsistencies
between peers in the cluster. In general, the management of clustered services should be
almost as easy as managing services that are not clustered.
• Hardware and operating system independence – Using Java software clustering, replicas
can be established across disparate hardware and operating system platforms. By not relying
on specific platform features, your investment is protected as you move components from
platform to platform.

BEA WebLogic Clustering

Enterprise Java and Web application servers present two particularly challenging aspects for a
clustering solution. First, they require integration with front-end Web servers, a fixed technology
that is external to the cluster. Second, they require back-end management of objects—which by
their nature have internal state—and the persistence mapping of at least some of those objects to
a database. Server object state ranges from client session state (user security credentials, Web
shopping cart contents) to business object contents (account balances). The hard part about
managing state is that excessive communication between servers—e.g., to replicate objects for
availability—can interfere with scalability.

4
In contrast, conventional middleware such as TP monitors generally support only stateless
services.

The BEA WebLogic Server provides an integrated implementation of the J2EE Enterprise
APIs. A BEA WebLogic Cluster is a group of WebLogic servers that coordinate their actions in
order to provide scalable, highly-available services in a transparent manner. Since the WebLogic
Server is written entirely in Java, WebLogic clusters are independent from the underlying
hardware and operating system. Thus a WebLogic cluster can be composed of, say, Intel
machines running Microsoft NT or Linux, large-scale Unix multiprocessors, and IBM AS/400s.
In contrast, platform-specific clustering solutions require that every node run the same operating
system. Of course, this allows them to use proprietary hardware—such as shared disks, multi-
tailed disks, and high-speed interconnects—for communication between servers. As an
alternative, WebLogic uses highly-optimized protocols based on new commodity technologies
such as IP multicast.

Two kinds of clustering are essential for Web application servers like BEA WebLogic Server:
• Web clustering, which ensures that the Web pages that your customer is requesting (e.g.,
portfolio view, order status) are available and delivered in near real time. Web page
clustering also requires the efficient replication of the user’s transient state (e.g., the contents
of a Web shopping cart or travel itinerary). Web application servers like BEA WebLogic
Server must deliver this quality of service for Web applications (i.e., clustering for Enterprise
Java’s Web integration services—Servlets and Java Server Pages for HTML or XML page
generation).
• Component/object clustering, which ensures that Enterprise JavaBean (EJB) business
services and objects (e.g., ordering & billing services, customer accounts, inventory) are both
efficient and available. With WebLogic, clustered EJB components can be easily invoked
from Servlets (for generating Web content); from other Enterprise JavaBeans; from Java
applets; from Java client applications; or even from Microsoft-based applications like Visual
Basic, Visual C++, PowerBuilder, or Active Server Pages (ASP). The latter uses are greatly
facilitated by WebLogic’s automatic wrapping of EJB components with a COM+ object for
easy inclusion within a Microsoft-oriented desktop.

Web clustering is mandatory for all Web application server products that target business-critical
deployments, with the WebLogic Server being no exception. (You will still find, however, that
our competitor’s schemes for state replication leave something to be desired.) Component/object
clustering, however, has traditionally been the domain of TP Monitors and Object Transaction
Managers (such as BEA TUXEDO and BEA WebLogic Enterprise, which was formerly “BEA
M3”). And yet, component/object clustering is now also provided within the WebLogic Server,
making it the first Web application server to offer both Web and EJB component clustering!

Of course, both kinds of clustering are essential for delivering mission-critical information
systems over the Web, whether that means to employees across corporate intranets or to business
partners and consumers across the Internet. The reason is scalability: as Web applications grow
in complexity, it often becomes necessary to partition the business processing: ten servers doing
portfolio management and ten servers doing on-line trading will often be superior to twenty
servers doing both at once. (Your non-Web IT infrastructure is similarly specialized.) However,

5
as soon as you partition your business processing, your business components become potential
points of failure and bottlenecks to scaling. Thus, support for both Web-oriented and application-
oriented clustering is essential for partitioning large Web applications both vertically—according
to business function—and horizontally—according to, say, account names or country regions.

WebLogic Clustering Architecture

Figure 1 shows a high-level view of the architecture of a BEA WebLogic Server cluster.

Figure 1: BEA WebLogic cluster architecture. BEA WebLogic Server provides software-based clustering to
ensure scalability and high availability for Web and Java deployments. WebLogic clustering uniquely supports
transparent replication, load balancing, and failover for both Web page generation (presentation logic) and
Enterprise JavaBeans components (business logic). There is only one type of WebLogic server, although the
figure does illustrate the specialization of servers for particular application tasks.

The Web-presentation front end supports the dynamic construction of HTML pages using Java
Servlets, Java Server Pages (JSP), and Java HTML (JHTML). The application-logic back end
hosts the business objects and components built with Enterprise JavaBeans (EJB), Java Remote
Method Invocation (RMI), and the Java Naming and Directory Interface (JNDI). Other back-end
Java Enterprise APIs, such as Java Database Connectivity (JDBC) and Java Messaging Services
(JMS), are clustered using RMI, EJB, and JNDI in much the same way as applications. The front
and back ends are made up of rather different components that must be clustered independently.

The Web-Presentation Front End. A WebLogic cluster may be located behind standard Web
servers such as Netscape Enterprise Server or Microsoft Internet Information Server (IIS). HTTP
requests (such as for static HTML files) from Web browsers may be handled by these Web
servers or the WebLogic front end. Requests for dynamically generated pages are proxied from

6
the Web servers to WebLogic Servlet/JSP engines. This is accomplished using Web server proxy
plug-ins, e.g., defined according to the Netscape API (NSAPI) or the Microsoft Internet Server
API (ISAPI).

The first line of clustering uses “DNS Round Robin” between the Web clients and the Web
servers. DNS, the Internet’s Domain Name Service, resolves a Web site’s name to a list of IP
addresses for the site’s Web servers. Each time it gets a lookup request, DNS shuffles the list of
addresses it returns. A Web client generally contacts the first server on the list provided by DNS.
After some timeout period, or if this server fails, the client makes another DNS request and
continues with a new server. This provides a simple form of load balancing and failover. It is
possible to install more sophisticated IP-level load balancing and failover schemes that, for
example, take into account Web server load, remove failed servers from the list returned by
DNS, and/or ensure that a client session is always handled by the same Web server (modulo
failures). Cisco’s Local Director is a popular example of such a product.

The second line of clustering is for dynamically generated pages and goes between the Web
servers and Servlet/JSP engines in the front end of the cluster. The Web server proxy plug-ins
perform load balancing and failover between the Servlet/JSP engines. They use a session-level
round-robin algorithm that is weighted by information about server load, which is piggybacked
onto HTTP responses. If the WebLogic front end is also configured to handle all HTTP requests
(so the standard Web servers are missing) then the situation is even simpler. Since the load
balancing and failover algorithm is part of the server, it uses information about server load that is
shared across the cluster as a matter of course. More importantly, this algorithm prefers the local
Servlet/JSP engine, unless the load is very unevenly distributed, so the request never has to leave
the address space of the JVM.

When a Web client first contacts a cluster of Web servers, a session is created that lasts until
some idle timeout expires. The Java standards include the notion of Servlet Session State, which
is automatically retained on the servers during the session. As an example, Servlet Session State
might be used to retain the contents of a shopping cart in a retail application. WebLogic clusters
provide for highly-available Servlet Session State using in-memory replication or transactional
disk-based replication, as described in more detail in the upcoming section on ‘stateful services.’

The Application-Logic Back End. In the back end, a user- or system-level service is clustered
by replicating the component (EJB) or object (RMI) that provides the service across several
different servers. Keep in mind that the client of an application service is itself a piece of code—
GUI, another component, business rule, etc. An unclustered service is invoked from an
application by calling the methods of a stub, which marshals the arguments and passes them to a
particular remote object. A clustered service is invoked by calling methods of a smart stub,
which additionally can find the possible instances of the service and switch between them as
needed for load balancing and failover. A variety of load balancing and failover algorithms are
provided (random, round robin, server-load based). It is possible to specify the particular
algorithm to use with a given service at the time that service is deployed.

The default is a transaction-level round-robin algorithm that attempts to co-locate all services
invoked within the same transaction. This algorithm takes server load into account only if the

7
stub is called within a server-side application, since load information is expensive to obtain on a
client. When the Servlet/JSP engine invokes a clustered back-end service, server-side load
balancing occurs. A programmed client may invoke a clustered service directly, resulting in
client-side load balancing, or it may have the service invoked on its behalf within the cluster for
server-side load balancing.

There are two forms of clustered back-end services: stateless, which are instance-neutral, and
stateful, which are instance-specific. These forms are treated quite differently within the cluster.

Stateless Services. A stateless service may not maintain state on behalf of an application, rather
like a conventional remote procedure call (RPC). It may of course access application state, but
only by loading it temporarily into memory from a database, file system, or other external
medium. The EJB component model provides a natural way of implementing stateless services,
namely stateless session beans. Stateless services can also be implemented as RMI objects, but
then it is up to the programmer to abide by this restriction.

The stateless service model has been widely advocated because it promotes scalability. There are
two reasons for this. First, it obviates the need to back up state in the interests of availability,
e.g., by replicating it within the cluster. Second, it allows load balancing to occur on every
invocation of the service. This is because the service is “instance-neutral,” i.e., it doesn’t matter
which instance of the service is invoked.

When a stateless service is deployed in a WebLogic cluster, an instance of the service is created
on each server that hosts it. A smart stub obtains references to these instances from the cluster-
wide naming service and switches between them as needed for load balancing and failover.
Retries occur only if it can be guaranteed that a failed operation did not have side effects, e.g.,
because it never got started, it was transactional and an abort clearly occurred, or it was declared
to be idempotent (without side effects). If such cases do not apply, application code may contain
explicit retries, perhaps after undoing side effects. Other than this, clustering is completely
transparent to the application.

WebLogic clusters support an important special case of stateless services: service factories that
create unclustered stateful service objects. The factory itself is stateless, so its stub can do load
balancing and failover in the usual way. The service objects created by the factory are not
clustered, however, and may therefore maintain state on behalf of an application. Since this state
is not backed up, it will be lost if the object fails. Application code must therefore contain an
explicit retry loop that creates a new instance of the object. EJB stateful session beans fit
naturally into this model, since they are not persistent. This model may also be used with RMI
objects.

Stateful Services. A stateful service may maintain state on behalf of an application. Such a
service is “instance-specific” in the sense that each request is intended for a particular instance of
the service. In a cluster, the state must be backed up in the interests of availability and can
migrate in the interests of load balancing or availability. The cluster must therefore provide some
kind of internal activation service that finds or creates service instances. If an instance can be

8
concurrently used by several clients, as is the case for persistent components such as EJB entity
beans that are accessed by a global key, then this service must ensure that conflicts do not arise.

• Database-oriented replication. One approach to state maintenance is to keep the state in a

database or other persistent store. This is particularly suitable for persistent components, but
may also be applied to transient objects. This approach scales like stateless services, and in
fact differs only in that the latter requires explicit disk reads/writes. The activation service
can avoid concurrency conflicts here simply by relying on underlying database locking. In a
WebLogic cluster, EJB entity beans default to this approach.

A related approach is to maintain a write-through cache, which keeps a current copy of the
state in memory to avoid subsequent reads. This makes it considerably harder to avoid
concurrency conflicts, and doing so can interfere with scalability. Databases are very good at
caching objects in memory and doing the minimal disk I/O necessary to provide transactional
protection. Application servers will not do much better for persistent components, and so
such caching may be best applied to transient objects that are used by a single client.

One exception is read-mostly data—such as pricing information—that does not require strict
transactional semantics. You would want such broadly-used data to be widely replicated for
the highest performance, but at the same time, cannot afford the very high cost of
simultaneously updating every such instance within a single transaction. Such “read mostly”
entity beans require relaxing strict transactional semantics to gain the desired efficiency. This
means that prices can be updated without locking out or rolling back pending transactions.

• Memory-based replication. A third approach is to keep a secondary copy in memory on

another machine. This is of course more susceptible to failures and is not suitable for
persistent components. The hard part here is determining when and how the state of an object
has changed. (Persistent components are generally just written out before transactions are
committed.) If the application programmer is made responsible, presumably through some
proprietary API, then the feature becomes harder to use. If the system is made responsible,
then the feature may be less efficient since unnecessarily large updates may be performed
more often than required.

In a WebLogic cluster, servlet session state, stateful session beans, and RMI objects can be
configured to use in-memory replication. The replication system takes care of transporting an
update delta from the primary copy to the secondary copy. Scalability comes from
distributing the primaries and secondaries across the cluster. This is in contrast to replication
systems that keep all of the objects on (1) a fixed-size subset of the servers, or (2) all of the
servers. Approach (1) typically means using a process pair of servers to hold session state.
All of the servers in the cluster will then “bottleneck” on their access to the primary state
server (which they each hit on every user request). Approach (2) requires so much “chatter”
back and forth between all of the server instances that after two or three nodes, you will see
reduced performance for each additional server in the cluster!

The Naming Service. Access to clustered services is obtained through a JNDI-compliant

naming service, which is itself replicated across the cluster so there is no single point of failure.

9
To offer an instance of a clustered service, a server advertises a provider at a particular node in
the replicated naming tree. Each server in the cluster adds a stub for this provider to a service
pool stored at the node in its copy of the tree. When a client looks up the service, it obtains a
smart stub that knows about the pool at this node. When the stub needs to find a provider for load
balancing or failover, it chooses from a list obtained from this pool. The replicated name space
plays a roll analogous to the shared memory bulletin board of BEA TUXEDO.

BEA WebLogic Clustering Goals

BEA WebLogic clustering was guided by several principals, which are embodied in
implementation that we described in the previous section. While we would rather not give away
all of our secrets, we can speak to how WebLogic clustering can impact your E-Business
technology infrastructure:

Minimize client and database connections. Client connections to servers are expensive—
security context must often be established and the overhead of maintaining client connections
(sockets being scarce resources) generally limits the scalability of the Web application server.
This principal suggests a model in which a client establishes a minimal number of connections to
the servers in the cluster.

WebLogic automatically multiplexes a single client connection across multiple conversations

with different server-side objects. Moreover, WebLogic provides for the automatic forwarding of
requests from server to server within the cluster, limiting the number of connections required
into the cluster. Database connections are similarly pooled so that even tens of thousands of
cached server-side components/objects can share a configurable number of DBMS connections.

While this no doubt appears obvious, many application server solutions on the market either
open up one additional network connection and/or one additional database connection for every
server-side object. These architectures simply cannot scale competitively.

Balance the load between client sessions, not within them. In general, the cluster is far more
efficient when a particular client’s requests can be serviced by a single server, and only rerouted
in the event of a failure. By reusing the same server during a session, you greatly increase the
likelihood that the referenced Web pages, entity beans, application state, database items, and so
on will all already be cached in local memory. This principal—known in computer science as
locality of reference—simply means that requests can be more efficiently handled when more of
the associated state and operations are local. Since there are many more concurrent clients than
servers in a typical Web cluster, the load can be just as effectively balanced without scattering a
particular client’s requests across several servers.

Yet, this “scattering” is precisely what several of the leading Web application servers do, and
“cluster thrashing” is the inevitable result. You’ll be rerunning the same file and database I/O on
multiple servers and/or making additional network communications to access state stored on
remote servers. Just as importantly, spreading transactions is expensive: If the resources accessed
by a particular transaction can be localized on a single database connection (even if it is spread

10
across multiple servers), the transaction can be processed on average in half the time (because no
two-phase commit is required). What’s more, you avoid database locking conflicts that
invariably lead to deadlock problems and often operator intervention. BEA WebLogic Server
provides this distributed beans, single database connection optimization automatically.

Persistent state belongs in the database. Databases are very good at caching objects in memory
and doing the minimal disk I/O necessary to provide transactional protection (which guarantees
no loss of data in the face of hardware outages and even non-redundant disk failures). Indeed,
they are optimized for precisely this task. Application servers will not do better than databases
for protecting persistent data—accounts, portfolios, orders, etc. Under the WebLogic EJB
implementation, then, the transactional “bean of record” is always in the backing database. This
means that we are always free to flush the WebLogic EJB cache without compromising your
data and applications. More importantly, this means that if ever a WebLogic server or application
were to fail, the transactional state of your application is fully (and automatically) recoverable
out of your existing database(s).

This no doubt seems natural. You have already hardened your relational or object databases
against failures. Why should you worry about hardening yet another moving part of a production
deployment? Nevertheless, there are competing application servers that provide their own
persistent stores juxtaposed between the application server and the database.

WebLogic’s clustering scheme also permits the capture of more important state data (such as the
contents of a complex Web order constructed over a 30 minute session) to be captured
transactionally so that even multiple server failures do not result in a user having to lose any
significant work. (This is implemented by allowing session state to be transparently captured as
entity beans.)

Transient state is best captured with redundant memory storage. Nevertheless, database I/O
is substantially more expensive than memory access or network communications. Generally,
more transient session state (e.g., security context, Web shopping cart contents) do not need to be
protected from multiple, simultaneous server failures. For transient application state, then, faster
redundant memory storage is often a better fit than database storage. WebLogic provides a
means for automatically capturing this session state redundantly, and transparently failing over to
the backup after an outage. (Failover includes automatically copying the session state to yet
another backup to protect against subsequent failures.)

Rich, configurable component caching. EJB components are cached in order to

• Avoid database queries – By caching specific entity beans (customer accounts & balances),
we can automatically prevent a read request (balance inquiry) from hitting the database.
• Avoid memory allocation – When a client requests an instance of a session bean (stateful or
stateless), one can be assigned out of the existing pool (just as a TP Monitor assigns a server
process to a particular client for a particular request). Similarly, when an entity bean instance
is requested, if the cache is full, an existing entity bean instance is chosen for replacement
(via a least recently used policy), and the contents of the new bean (instance variables) can
simply be copied in.

11
BEA WebLogic provides a configurable cache for controlling the number of object instances that
are active:
• For session beans and RMI objects, cache management means controlling the number of
instances running on a particular server. Limiting the number of session beans or RMI
objects available for client use prevents a particular server from thrashing as tens of
thousands of clients hammer it with requests.
• For entity beans, cache management means controlling the number of instances in memory at
the same time. If a server instead attempts to keep too many entity beans in memory at the
same time, it will begin paging. Paging can be very expensive, and is precisely the reason
that database clients limit the sizes of their caches.

Two EJB application servers on the market advertise replicating entity bean components across
caches. Entity bean replication is a dubious prospect for the typical read/write case requiring full
transaction semantics: To ensure the transactional integrity of multiple copies of a particular
entity bean, you will need to read from and/or write to all of those copies within a single unit of
work (ensured by a two phase commit). This makes access and/or updates much, much more
expensive (perhaps an order of magnitude) than without replication—compromising scalability.

Instead, BEA believes there are two models that best meet the needs of the large majority of
E-Business applications:
• For the typical read/write usage of entity beans where you expect that specific beans will not
be cached for long intervals (because other beans will replace them), the optimal solution is
not to replicate active instances across servers. With only a single active instance, access and
update are both very fast (since you’re only doing each operation once). Also, you avoid the
complexity associated with simultaneously connecting to and acquiring locks on each of the
cached copies. In the event of an application or system failure, the entity bean (including all
of its state) will be automatically recovered on another server. Thus, we optimize to provide
the fastest possible forward processing, and spend a bit more time to recover in the event of a
(presumably rare) failure. Transaction processing systems have been optimized this way for
decades.
• For read-mostly entity beans (such as pricing data), we allow replication on demand
(potentially across all of the servers in the cluster). While updates can be made at any time,
in-flight and pending transactions that only read the entity beans will complete using the
existing cached values. The user recognizes that this approach relaxes EJB’s normally strict
transaction semantics in order to ensure the highest possible performance for read-mostly
data.

Flexible application partitioning. While we attempt to minimize client connections, it is

nevertheless the case that certain requests may be better handled on a particular server in the
cluster. If, for example, the EJB component that contains my stock portfolio might already be
cached on another server in the cluster, then a read request may be dramatically cheaper if routed
appropriately. With WebLogic, a request is transparently forwarded from the server that initially
received it to whatever server is best suited to handle that request. (Client-side security identity is
preserved during request forwarding.)

12
By default, every server in a BEA WebLogic Server Cluster is homogeneous—hosting all of the
same application services. Automatic routing, however, frees your system administrator to
partition and dynamically repartition the business processing within the cluster as desired—for
example, specializing some servers to handle checking accounts and others to handle savings.

The clustering solution should not mandate a Web server. Unlike some Web application
servers, BEA WebLogic does not require that the user deploy a particular Web server (such as
Netscape Enterprise Server or Microsoft IIS). Indeed, unlike most of our competitors, BEA
WebLogic is able to act as the Web server itself in a fully clustered solution. As Web sites are
increasingly made up of personalized, dynamic content rather than static HTML files, you can
expect more Web servers to be replaced with Web application servers. Admittedly, this is not
where the majority of the market is today. That’s why WebLogic also provides high-
performance, clustered integration with your existing Web servers—offering a seamless means
for increasing the personalized, dynamic content on your Website over time without sacrificing
reliability.

13
Conclusion

As we looks at the Web application server marketplace in mid 1999, we believe BEA made three
fundamental decisions early on that have positioned us 12-18 months ahead of our nearest
competitors in clustering technology:
(1) We recognized that Web application scalability and fault tolerance depend on the clustering
of both Web presentation services as well as server-side business components, and both must
be addressed within any enterprise-grade Web application server.
(2) We began investing in the current Java-based kernel of the WebLogic application server in
1995 and have had production deployments since 1996 (two years earlier than several of our
competitors can date their application server efforts). So the WebLogic implementation of
replication, routing, load balancing, and failover is substantially more mature than the
competing solutions on the market.
(3) We made a stronger commitment to the Enterprise Java (now J2EE) standards then did our
competitors—believing then as we do now: that investment protection would be the single
most important customer requirement for Web applications. As a result, WebLogic was the
first Web application server to support each of following Java standards: EJB, JDBC, RMI,
Servlets, Java HTML, JMS, and JNDI. Our competitors, who talked about standards while
delivering proprietary alternatives, discovered that they now have to replace the internal
architecture of their application servers in order to make the shift to EJB, JDBC, and/or
Servlets/JSP, setting them well back in the marketplace.

About BEA Systems, Inc.

BEA Systems, Inc. is a leading provider of mission-critical Web and middleware solutions for
the world’s largest enterprises. BEA’s product line enables end-to-end, integrated solutions for
electronic commerce and business-critical systems. BEA products include BEA WebLogic, a
leading application server family providing EJB, enterprise Java, and CORBA technology
solutions; BEA TUXEDO, the industry’s market-share leader for distributed transaction
management software; and BEA eLink, a solution for integrating enterprise applications. BEA
also provides a comprehensive suite of consulting, education, and customer support offerings to
preserve and maximize technology investments in BEA products. BEA is headquartered in San
Jose, Calif., and has 52 offices in 24 countries. The company’s common stock trades on the
Nasdaq National Market under the symbol “BEAS.” Additional information on BEA is available
on the Internet at http://www.beasys.com.

BEA, TUXEDO, and WebLogic are registered trademarks of BEA Systems, Inc. eLink is a trademark of BEA Systems, Inc.
Sun, Sun Microsystems, Java, JavaServer Pages, and Enterprise JavaBeans are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States and other countries. All other company and product names may be trademarks of the
respective companies with which they are associated.

14