|
|
|
|
| |
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.
When used as a Web server, WebLogic Server supports the following functionality:
This section describes how each of these functions is supported by WebLogic Server.
WebLogic Server supports virtual hosting, an arrangement that allows a single WebLogic Server or WebLogic 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 hostname 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 Cluster makes it possible to perform load balancing and failover for Web requests. To the client, there appears to be only one Web server.
You can set up multiple WebLogic Servers behind a proxy server to accommodate large volumes of requests. The proxy server performs load-balancing, distributing requests across the multiple servers in the tier behind it.
The proxy server can be a WebLogic 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 Cluster behind the proxy.
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 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 Cluster is deployed behind a proxy server, servlet sessions can be replicated over the network to a secondary WebLogic Server selected by the cluster, 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 when you have a WebLogic Cluster.
WebLogic Server provides security for applications through a service called a security realm. A security realm provides access to two services:
A realm has access to a store of users and groups and can authenticate a user by testing a user-supplied credential (usually a password) against the username and credential in the security store. Web browsers support authentication by requesting a username and password when a Web client tries to access a protected WebLogic Server service. Other WebLogic Server clients supply usernames and credentials programmatically when they establish WebLogic Server connections.
WebLogic Server services are protected with Access Control Lists (ACLs). An ACL is a list of users and groups who are authorized to access a service. Once it has authenticated a user, WebLogic Server checks the ACL for a service before allowing the user to access the service.
The security realm is pluggable-you can use the default File realm, an alternative realm supplied with WebLogic Server, or you can create your own realm. The default File realm stores users, passwords, groups, and ACLs in an encrypted file. The file is managed through the Administration Console.
WebLogic Server includes alternative realms that access an external store of users and groups and sometimes ACLs. Alternative realms are provided for these external security systems:
A custom realm can be developed for use in WebLogic Server by implementing the WebLogic Realm interfaces. WebLogic Server supports realms with a built-in caching system, to minimize calls into the external store. Any features that are not implemented in a custom realm fall back on the default File realm. For example, it is common to develop a custom realm that uses an external store for users and groups, but to maintain ACLs in the File realm.
WebLogic Server supports the Secure Sockets Layer (SSL) protocol, which protects data transferred over a wire. SSL is the standard protocol for secure Web connections. WebLogic Server supports SSL on Web (HTTPS) connections and in stand-alone Java clients that use RMI-based services.
To provide SSL, you must first purchase a Server ID for your WebLogic Server from a certificate authority, such as VeriSign or GTE Cybertrust. When a client establishes a secure connection, WebLogic Server sends its certificate to the client, allowing the client to verify that the connection is proper. Clients examine the certificate to make sure that it has not expired, matches the server that sent it, and is signed by a recognized certificate authority. The server and client then exchange encryption keys and establish a secure connection.
WebLogic Server can also be configured to require mutual authentication, which requires a client to submit a client certificate that the server must validate before accepting a connection.
A WebLogic Cluster is a group of WebLogic Servers 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.
WebLogic 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 WebLogic Server or a single computer. The only limitation on cluster membership is that all WebLogic Servers must be able to communicate via IP multicast. New WebLogic Servers can be added to a cluster dynamically to increase capacity.
A WebLogic 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.
A WebLogic Cluster consists of a number of WebLogic Servers 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 Cluster coordinate clustering services for servlets and JavaServer Pages. Web proxy servers can be 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 Cluster by directing requests to a proxy server. Java RMI-based clients connect with a WebLogic 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 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 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 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 the WebLogic Servers 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 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.
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 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 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 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 application must create a new instance.
A JDBC metapool provides clustering for JDBC connection pools deployed on multiple servers in a WebLogic 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. Each destination (message Queue or Topic) is managed by a single WebLogic Server in the cluster. But connection factories, which clients use to establish a connection to a destination, 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.
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 Clusters and independent WebLogic Servers. 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.
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
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.
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|
