Introduction to WebLogic Server and WebLogic Express

WebLogic Server Services

The following sections describe WebLogic Server services:

WebLogic Server as a Web Server

WebLogic Server can be used as the primary Web server for advanced Web-enabled applications. A J2EE Web application is a collection of HTML or XML pages, JavaServer Pages, servlets, Java classes, applets, images, multimedia files, and other types of files.

How WebLogic Server Functions as a Web Server

A Web application runs in the Web container of a Web server. In a WebLogic Server environment, a Web server is a logical entity, deployed on one or more WebLogic Servers in a cluster.

The files in a Web application are stored in a directory structure that, optionally, can be packed into a single .war (Web ARchive) file using the Java jar utility. A set of XML deployment descriptors define the components and run-time parameters of an application, such as security settings. Deployment descriptors make it possible to change run-time behaviors without changing the contents of Web application components, and they make it easy to deploy the same application on multiple Web servers.

Web Server Features

When used as a Web server, WebLogic Server supports the following functionality:

Virtual hosting
Support for proxy server configurations
Load balancing
Failover

This section describes how each function is supported by WebLogic Server.

Virtual Hosting

WebLogic Server supports virtual hosting, an arrangement that allows a single WebLogic Server instance or WebLogic Server cluster to host multiple Web sites. Each logical Web server has its own host name, but all Web servers are mapped in DNS to the same cluster IP address. When a client sends an HTTP request to the cluster address, a WebLogic Server is selected to serve the request. The Web server name is extracted from the HTTP request headers and is maintained on subsequent exchanges with the client so that the virtual host name remains constant from the client's perspective.

Multiple Web applications can be deployed on a WebLogic Server, and each Web application can be mapped to a virtual host.

Using Proxy Server Configurations

WebLogic Server can be integrated with existing Web servers. Requests can be proxied from a WebLogic Server to another Web server or, using a native plug-in supplied with WebLogic Server, from another Web server to WebLogic Server. BEA supplies plug-ins for Apache Web Server, Sun One Web Server, and Microsoft Internet Information Server.

The use of proxy Web servers between clients and a set of independent WebLogic Servers or a WebLogic Server cluster makes it possible to perform load balancing and failover for Web requests. To the client, there appears to be only one Web server.

Load Balancing

You can set up multiple WebLogic Servers behind a proxy server to accommodate large volumes of requests. The proxy server performs load-balancing by distributing requests across the multiple servers in the tier behind it.

The proxy server can be a WebLogic Server Web server, or it can be an Apache, Netscape, or Microsoft Web server. WebLogic Server includes native code plug-ins for some platforms that allow these third-party Web servers to proxy requests to WebLogic Server.

The proxy server is set up to redirect certain types of requests to the servers behind it. For example, a common arrangement is to configure the proxy server to handle requests for static HTML pages and redirect requests for servlets and JavaServer Pages to a WebLogic Server cluster behind the proxy.

Failover and Replication

When a Web client starts a servlet session, the proxy server may send subsequent requests that are part of the same session to a different WebLogic Server. WebLogic Server provides session replication to ensure that a client's session state remains available.

There are two types of session replication:

JDBC session replication is used with a WebLogic Server cluster or with a set of independent WebLogic Servers. It does not require the WebLogic Server clustering option.
In-memory session replication requires the WebLogic Server clustering option.

JDBC session replication writes session data to a database. Once a session has been started, any WebLogic Server the proxy server selects can continue the session by retrieving the session data from the database.

When a WebLogic Server cluster is deployed behind a proxy server, servlet sessions can be replicated over the network to a secondary WebLogic Server selected by the cluster, thus avoiding the need to access a database. In-memory replication uses fewer resources and is much faster than JDBC session replication, so it is the best way to provide failover for servlets in a WebLogic Server cluster.

WebLogic Server Security Service

The open, flexible security architecture of WebLogic Server delivers advantages to all levels of users and introduces an advanced security design for application servers. Companies now have a unique application server security solution that, together with clear and well-documented security policies and procedures, can assure the confidentiality, integrity and availability of the server and its data.

The key features of the new WebLogic Security Service include:

A comprehensive and standards-based design.
End-to-end security for WebLogic Server-hosted applications, from the mainframe to the Web browser.
Legacy security schemes that integrate with WebLogic Server security, allowing companies to leverage existing investments.
Security tools that are integrated into a flexible, unified system to ease security management across the enterprise.
Easy customization of application security to business requirements through mapping of company business rules to security policies.
Easy updates to security policies.
Easy adaptability for customized security solutions.
A modularized architecture, so that security infrastructures can change over time to meet the requirements of a particular company.
Support for configuring multiple security providers, as part of a transition scheme or upgrade path.
A separation between security details and application infrastructure, making security easier to deploy, manage, maintain, and modify as requirements change.
Default, WebLogic security providers that provide you with a working security scheme out of the box.
Customization using WebLogic custom security providers
Unified management of security rules, security policies, and security providers through the WebLogic Server Administration Console.
Support for standard J2EE security technologies such as the Java Authentication and Authorization Service (JAAS), Java Secure
Sockets Extensions (JSSE), and Java Cryptography Extensions (JCE).

For more information about the WebLogic Security Service, see Introduction to WebLogic Security.

WebLogic Server Clusters

A WebLogic Server cluster is a group of WebLogic Server instances that work together to provide a powerful and reliable Web application platform. A cluster appears to its clients as a single server but it is, in fact, a group of servers acting as one. It provides two key benefits that are not provided by a single server: scalability and availability.

Using WebLogic Server Clusters provides complete information about planning and configuring WebLogic Server clusters.

Benefits of Using Clusters

WebLogic Server clusters bring scalability and high-availability to J2EE applications in a way that is transparent to application developers. The benefit of scalability is that it expands the capacity of the middle tier beyond that of a single instance of WebLogic Server or a single computer. The only limitation on cluster membership is that all WebLogic Server instances must be able to communicate by IP multicast. New WebLogic Servers can be added to a cluster dynamically to increase capacity.

A WebLogic Server cluster also guarantees high availability by using the redundancy of multiple servers to insulate clients from failures. The same service can be provided on multiple servers in a cluster. If one server fails, another can take over. The ability to have a functioning server take over from a failed server increases the availability of the application to clients.

Cluster Architecture

A WebLogic Server cluster consists of a number of WebLogic Server instances deployed on a network, coordinated with a combination of Domain Name Service (DNS), JNDI naming tree replication, session data replication, and WebLogic RMI.

Web proxy servers between Web clients and the WebLogic Server cluster coordinate clustering services for servlets and JavaServer Pages. Web proxy servers can be other WebLogic Servers, or third-party Web servers from Netscape, Microsoft, or Apache, used with a plug-in supplied with WebLogic Server.

Web clients connect with a WebLogic Server cluster by directing requests to a proxy server. Java RMI-based clients connect with a WebLogic Server cluster using a cluster address defined on the network.

Server-side code also benefits from the load-balancing and failover services provided by a WebLogic Cluster. In J2EE applications, most application code runs in the middle tier and can use services distributed among several WebLogic Servers. For example, a servlet running on WebLogic Server A could use an enterprise bean on WebLogic Server B and read messages from a JMS Queue on WebLogic Server C.

How a WebLogic Server Cluster Is Defined in a Network

WebLogic Server services are accessed through DNS, the standard naming service for resources on a network, including the Internet. DNS maps IP addresses, such as 170.0.20.1, to names, such as mycomputer.mydomain.com or www.bea.com. Each instance of WebLogic Server runs on the network at a unique IP address. A client connects to a WebLogic Server by encoding in a URL its name and the number of the port where it is listening for connections.

For example, a WebLogic Server instance running on a computer named onyx, configured to listen on port 7701, can be accessed with a Web browser using the following URL: http://onyx:7701. For this connection to succeed, the name server on the network must be able to resolve the name onyx in the local domain. If the destination server is in another domain on the Internet, the full domain name, for example, http://onyx.bea.com:7701, must be supplied.

An additional DNS entry maps the names of all WebLogic Server instances participating in a cluster to a single cluster name. Clients connect to the cluster using the cluster name or through a Web proxy server that directs requests into the cluster. When DNS performs a lookup on a cluster name, it returns a list of all the servers that belong to the cluster. A client usually selects the first server in the list, and if it gets no response, tries the second server, working its way through the list until it gets a response.

DNS provides the initial load-balancing service that distributes requests across the servers in the cluster. Each DNS responds to a lookup on the cluster name, by rotating the list of servers by one, so that eventually each server gets a turn.

An intelligent router, proxy server, firewall, or other software operating on the network may override DNS and select the initial server based on machine load, network traffic, or other dynamic load-balancing criteria.

The initial WebLogic Server connection provides the naming service for the client. It looks up the service requested by the client and chooses a server from the cluster to handle the request, using a load-balancing algorithm configured in WebLogic Server.

How WebLogic Servers in a Cluster Communicate

WebLogic Servers in a cluster communicate with each other using IP multicast to replicate certain classes of information to all servers in the cluster. A common multicast address is configured for each server instance in the cluster. When one server sends a message to the cluster's multicast address, all servers receive the message. This process is much more efficient than having servers send point-to-point messages. However, it does require all the servers in a cluster to be on a network with multicast support. Multicast does not work on the Internet, so a cluster cannot traverse the Internet.

For some services, the cluster selects primary and secondary WebLogic Servers. If the primary WebLogic Server starts processing a request and then becomes unavailable, the secondary server can take over processing of the request without interruption. The primary server replicates state to the secondary server using a server-to-server connection.

Most services can be deployed on any number of WebLogic Servers in a cluster. As each service is deployed, the WebLogic Server uses IP multicast to add the service to a cluster-wide naming tree. Any server in the cluster can find a WebLogic Server to provide a given service by looking up the service in the cluster-wide naming tree. When more than one server can provide a service, the cluster uses a configurable load-balancing algorithm to choose a server.

Clustered Services

Most WebLogic Server services can be clustered; that is, they can be deployed on an unlimited number of servers in the cluster. The cluster selects the WebLogic Server instance that will provide a service. Once that server has been selected and stateful objects have been instantiated on the server, the client is pinned to that WebLogic Server until it has finished with the service. If a WebLogic Server hosting a pinned object fails, the client must detect the failure and create another instance on another server in the cluster.

To provide more resilient failover, a WebLogic Server cluster avoids pinning an object to a server unless absolutely necessary. In some cases the cluster replicates the stateful object to a backup server to enable failover for the service.

Web applications can be clustered, as described in the section WebLogic Server as a Web Server. Servlet sessions are replicated to a secondary server, allowing the cluster to recover from a failure transparently.

All Enterprise JavaBeans can be clustered. They can be deployed on an unlimited number of servers in a WebLogic Server cluster. However, not all EJB instances can be clustered. An application can get the home interface for an EJB from any server where the bean has been deployed, and it can use that home interface to create bean instances. If the server that provides the home interface fails, a home interface can be retrieved from another server without interrupting the application.

Some types of EJB instances, including stateless session beans and read-only entity beans, can always be clustered. Stateful session beans can be clustered using in-memory replication to provide failover. Read-write entity beans are always pinned to the server where they are instantiated. If the server hosting a read-write entity bean fails, the entity bean will automatically fail-over if it is safe to do so. Otherwise, fail-over occurs on the next transaction and the entity bean instance is recreated by the remote stub on another server in the cluster.

A JDBC metapool provides clustering for JDBC connection pools deployed on multiple servers in a WebLogic Server cluster. When a client requests a connection from the metapool, the cluster selects the server that will provide the connection, allowing load-balancing and protection against server failure. Once a client has a connection, the state maintained by the JDBC driver makes it necessary to pin the client to the host WebLogic Server.

JMS objects can be distributed among the servers in a cluster. Connection factories (which clients use to establish a connection to a destination) and destinations can be deployed on multiple servers in a cluster. By distributing destinations and connection factories throughout a cluster, administrators can manually balance the load for JMS services.

Server Management and Monitoring

WebLogic Server administration is accomplished by setting attributes for the servers in a domain, using either the Administration Console or the command-line interface. The Administration Console is a Web browser application that allows you to configure WebLogic Server services, manage security, deploy applications, and monitor services dynamically.

Both the Administration Console and the command-line interface connect to the Administration Server.

Administration Server

The Administration Server is the WebLogic Server used to configure and manage all the WebLogic Servers in its domain. A domain may include multiple WebLogic Server clusters and independent WebLogic Server instances. If a domain contains only one WebLogic Server, then that server is the Administration Server. In a domain with multiple instances of WebLogic Server, the first instance to start must be the Administration Server.

Administration Console

The WebLogic Server Administration Console runs in a Web browser. It displays the components of the domain it administers, including clusters and independent WebLogic Servers, in a graphical tree in the left pane. The right pane displays details about the object selected in the left pane. Figure 2-1 is a sample snapshot from an Administration Console session.

Figure 2-1 Administration Console

Administration Console

To use the Administration Console to configure a service, select an item in the left pane, and then choose the Configuration tab in the right pane. The Administration Console displays the configurable attributes in the right pane. You can use the online help to find detailed information about the displayed attributes.

The usual process for configuring a service in the Administration Console is to configure the service and then select the targets (WebLogic Servers) to which you want to deploy the service.

Each deployed service keeps run-time statistics, which you can view in the Monitoring tab in the right pane of the Administration Console.