bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Introduction to WebLogic Server and WebLogic Express

WebLogic Server Services

The following sections describe WebLogic Server services:

- "WebLogic Server as a Web Server" on page -1

- "WebLogic Server Security Service" on page -3

- "WebLogic Server Clusters" on page -6

- "Server Management and Monitoring" on page -9

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, Netscape Enterprise 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 security component of WebLogic Server has been completely redesigned in this version to offer a level of flexibility and control never before available with any application server platform. The new security architecture in WebLogic Server isolates the application developer from the intricacies of security implementation while allowing the use of the latest security technologies as implemented by a company's development staff or a security vendor.

The security framework in WebLogic Server is based on a set of Service Provider Interfaces (SPIs) used to develop security services for the WebLogic Server environment. SPIs are available for Authentication, Authorization, Auditing, Public Key Infrastructure (PKI), Credential Mapping, and User Profiles. You now have the choice of either using the out-of-the-box security services provided by BEA or using the SPIs to create customized security services for the WebLogic Server. The customized security services can be integrated into the WebLogic Server management environment so that all configuration and monitoring can be done through the WebLogic Server Administration Console.

The open security architecture in WebLogic Server allows you to use existing security products while taking advantage of new security technologies available in the marketplace. You also have the choice of security technologies and vendors. Security products can be "mixed and matched" to create complete custom security solutions.

The security architecture in WebLogic Server uses Java Standards (where applicable) to create a framework that unifies security enforcement and presents security as a service to other WebLogic Server components. The following Java security standards are supported in WebLogic Server:

- The Java Crytography Extension (JCE)—A set of packages that provide a framework for encryption using strong ciphers, key generation and agreement, and Message Authentication Code algorithms.

- The Java Secure Socket Extension (JSSE)—A set of packages that support and implement SSL and TLS, making those protocols and capabilities programmatically available.

- Java Authentication and Authorization Services (JAAS)—A set of packages that provide a framework for user-based authentication and access control. WebLogic Server uses the authentication classes of JAAS only.

- The Java Security Manager (JSM)—The security manager for the Java virtual machine (JVM). The security manager works with the Java API to define security boundaries through the java.lang.SecurityManager class, enabling programmers to establish a custom security policy for their Java applications.

Figure 2-1 illustrates the WebLogic Security Service.

Figure 2-1 The WebLogic Security Service

WebLogic Server now offers a dynamic, role-based authorization scheme that can be applied to all WebLogic Server resources. You are no longer constrained by the limitations of the declarative security model in J2EE. The Authorization service included with WebLogic Server 7.0 includes an embedded entitlement engine that allows you to create simple prose-based rules for dynamically assigning roles and calculating access privileges. Application developers are freed from having to write application code to implement complex business policies because the entitlements engine separates the tasks of business policy creation and application creation.

All user profile and entitlement data can be stored in the system data store integrated with WebLogic Server 7.0. The system data store is a scalable data store optimized for quick data reads. In addition to the system data store, you can configure one or more LDAP stores to provide a single unified profiling system from multiple back-end sources.

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-2 is a sample snapshot from an Administration Console session.

Figure 2-2 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.