The WebLogic Server cluster option allows you to distribute client requests and back-end services among multiple cooperating WebLogic Servers. Programs in the client tier access the cluster as if it were a single WebLogic Server. As the workload increases, you can add WebLogic Servers to the cluster to share the work. The cluster uses a selectable load-balancing algorithm to choose a WebLogic Server in the cluster that is capable of handling the request.
When a request fails, another WebLogic Server that provides the requested service can take over. Failover is transparent whenever possible, which minimizes the amount of code that must be written to recover from failures. For example, servlet session state can be replicated on a secondary WebLogic Server so that if the WebLogic Server that is handling a request fails, the client's session can resume uninterrupted on the secondary server.
The backend tier contains services that are accessible to clients only through WebLogic Server. Applications in the backend tier tend to be the most valuable and mission-critical enterprise resources. WebLogic Server protects them by restricting direct access by end users. With technologies such as connection pools and caching, WebLogic Server uses back-end resources efficiently and improves application response.
Backend services include databases, enterprise resource planning ERP systems, mainframe applications, legacy enterprise applications, and transaction monitors. Existing enterprise applications can be integrated into the backend tier using the Java Connector Architecture JCA specification from Sun Microsystems.
WebLogic Server makes it easy to add a Web interface to an integrated backend application. A database management system is the most common backend service, required by nearly all WebLogic Server applications. Once opened, database connections are shared by all WebLogic Server applications that need database access. The expensive overhead associated with establishing a connection is incurred only once for each connection in the pool, instead of once per client request.
WebLogic Server monitors database connections, refreshing them as needed and ensuring reliable database services for applications. J2EE services include access to standard network protocols, database systems, and messaging systems. To build a WebLogic Server application, you must create and assemble components, using the service APIs when necessary. Containers provide the life cycle support and services defined by the J2EE specifications so that the components you build do not have to handle underlying details.
Web components provide the presentation logic for browser-based J2EE applications. EJB components encapsulate business objects and processes. Figure illustrates WebLogic Server component containers and application services. Figure Application Logic Layers. The following sections discuss the presentation layer, business logic, and application services. The presentation layer includes an application's user interface and display logic.
Most J2EE applications use a Web browser on the client machine because it is much easier than deploying client programs to every user's computer. In this case, the presentation logic is the WebLogic Server Web container. Client programs written in any programming language, however, must contain either logic to render HTML or their own presentation logic.
Web-based applications built with standard Web technologies are easy to access, maintain, and port. Web browser clients are standard for e-commerce applications. Both produce dynamic Web content by executing Java code on WebLogic Server each time they are invoked. Servlets, written entirely in Java, are more suited to Java programmers than to Web designers.
JSP pages are converted to servlets before they are executed on WebLogic Server, so ultimately JSP pages and servlets are different representations of the same thing.
When a client requests a. A client program that is not a Web browser must supply its own code for rendering the user interface. Non-browser clients usually contain their own presentation and rendering logic, depending on WebLogic Server only for business logic and access to back-end services.
This makes them more difficult to develop and deploy and less suited for Internet-based e-commerce applications than browser-based clients. RMI allows a client program to operate on a WebLogic Server object the same way it would operate on a local object in the client.
Java programs can use the Java Swing classes to create powerful and portable user interfaces. This means that Java RMI clients are not suited to e-commerce applications. They can be used effectively, however, in enterprise applications in which an internal network makes installation and maintenance viable. HTTP is the standard protocol for the Web. It allows a client to make different types of requests to a server and to pass parameters to the server. A servlet on WebLogic Server can examine client requests, retrieve parameters from the request, and prepare a response for the client, using any WebLogic Server service.
For example, a servlet might respond to a client program with an XML business document. Thus an application can use servlets as gateways to other WebLogic Server services. WebLogic Server provides a Web Services run-time component, which is a set of servlets and associated infrastructure needed to create a Web service. One element of the run-time is a set of servlets that handle SOAP requests from a client.
You do not need to write these servlets; they are automatically included in the WebLogic Server distribution. Unlike other Java WebLogic Server clients, you do not need to include the weblogic. The WebLogic Server EJB container hosts enterprise beans, providing life cycle management and services such as caching, persistence, and transaction management.
There are three types of enterprise beans: entity beans, session beans, and message-driven beans. The following sections describe each type in detail. An entity bean represents an object that contains data, such as a customer, an account, or an inventory item. Entity beans contain data values and methods that can be invoked on those values.
The values are saved in a database using JDBC or some other data store. Entity beans can participate in transactions involving other enterprise beans and transactional services. Entity beans are often mapped to objects in databases. An entity bean can represent a row in a table, a single column in a row, or an entire table or query result. Associated with each entity bean is a unique primary key used to find, retrieve, and save the bean. Bean-managed persistence—the bean contains code to retrieve and save persistent values.
Container-managed persistence—the EJB container loads and saves values on behalf of the bean. Other container-managed persistence mechanisms are available. Entity beans can be shared by many clients and applications. An instance of an entity bean can be created at the request of any client, but it does not disappear when that client disconnects. It continues to live as long as any client is actively using it.
When the bean is no longer in use, the EJB container may passivate it: that is, it may remove the live instance from the server. A session bean is a transient EJB instance that serves a single client. Session beans tend to implement procedural logic; they embody actions more than data.
The EJB container creates a session bean at a client's request. It then maintains the bean as long as the client maintains its connection to the bean. Sessions beans are not persistent, although they can save data to a persistent store if needed.
A session bean can be stateless or stateful. Stateless session beans maintain no client-specific state between calls and can be used by any client. They can be used to provide access to services that do not depend on the context of a session, such as sending a document to a printer or retrieving read-only data into an application.
A stateful session bean maintains state on behalf of a specific client. Stateful session beans can be used to manage a process, such as assembling an order or routing a document through a workflow process.
Because they can accumulate and maintain state through multiple interactions with a client, session beans are often the controlling objects in an application. Because they are not persistent, session beans must complete their work in a single session and use JDBC, JMS, or entity beans to record the work permanently.
Message-driven beans, introduced in the EJB 2. JMS routes messages to a message-driven bean, which selects an instance from a pool to process the message. Because they are not called directly by user-driven applications, they cannot be accessed from an application using an EJB home. A user-driven application can, however, instantiate a message-driven bean indirectly by sending a message to the bean's JMS Queue. WebLogic Server supplies the fundamental services that allow components to concentrate on business logic without concern for low-level implementation details.
It handles networking, authentication, authorization, persistence, and remote object access for EJBs and servlets. Standard Java APIs provide portable access to other services that an application can use, such as database and messaging services. A URI is a standardized string that specifies a resource on a network, including the Internet.
It contains a protocol specifier called a scheme , the network address of the server, the name of the desired resource, and optional parameters. In the following table, the scheme in a URI determines the protocol for network exchanges between a client and WebLogic Server. Table Network Protocols. The following sections provide more information about these protocols. A client issues a request that includes a URI. If the resource name is omitted, WebLogic Server returns the default Web page, usually index.
The request can include data parameters and message content. A request for a custom-coded servlet executes the corresponding Java class on WebLogic Server. A request for a JSP page causes WebLogic Server to compile the JSP page into a servlet, if it has not already been compiled, and then to execute the servlet, which returns results to the client.
T3 is an optimized protocol used to transport data between WebLogic Server and other Java programs, including clients and other WebLogic Servers. The EJB and JDBC services can be written as if they had sole use of a dedicated network connection because the T3 protocol invisibly multiplexes packets on the single connection. T3 is an efficient protocol for Java-to-Java applications because it avoids unnecessary network connection events and uses fewer OS resources. The protocol also has internal enhancements that minimize packet sizes.
RMI allows one Java program, called the server , to publish Java objects that another Java program, called a client , can execute. Alternatively, you can use APIs to create custom management utilities. The following sections provide an overview of system administration for the WebLogic Server component of your development or production environments:. Table describes common system administration tasks and associated technologies.
Table Choosing the Appropriate Management Technology. The Configuration Wizard guides you through the process of creating or extending a domain for your target environment. To automate the creation of domains, use the WebLogic Scripting Tool, which is a command-line scripting interface based on Jython. The unpack command expands the archive and creates the necessary start scripts and certain security and configuration files. In environments that you allow configuration changes to active domains, WebLogic Server automatically maintains a versioned archive of configuration files.
To receive real-time notifications that a domain's configuration has been modified, enable the configuration auditing feature. For tightly controlled production environments, configure the run-time domain to be read-only see " Restricting Configuration Changes " in Understanding Domain Configuration for Oracle WebLogic Server.
You can change the read-only setting if you need to roll in changes that have been tested and approved in a staging environment, or you can modify and test your staging environment, and then use a Web server to re-route requests from your production environment to the staging environment.
Web server plug-ins. Within individual applications, you can define your own data sources or database connections using JDBC, or connect to external systems using resource adapters. When you deploy such an application, WebLogic Server creates the data sources and connections for you. If you have not defined your own data sources or connections within an application, you can use the Administration Console or the WebLogic Scripting Tool to create the resources.
While use of Node Manager is optional, it provides additional life cycle benefits if your WebLogic Server environment hosts applications with high availability requirements.
The WebLogic Server Administration Console provides a graphical user interface for modifying or adding services to an active domain. See Administration Console Help. If you prefer a command-line interface, use the WebLogic Scripting Tool in interactive mode. Configure watch rules and notifications in the WebLogic Diagnostics Framework to automatically notify administrators of monitoring data events or integrate automated systems through JMX or JMS.
The WebLogic Server Administration Console provides a series of Web-based deployment assistants that guide you through the deployment process. To automate the deployment of applications, use the WebLogic Scripting Tool. You can also use the deployment API to write Java programs that deploy applications. To modify the configuration of a deployed application, use a text editor or IDE to modify the deployment descriptor.
Then either redeploy the application or use the deployment API to upload the modified deployment descriptor and cause the application container to re-read the deployment descriptor. Determine which data points you want to monitor and then instrument one or more beans to expose this data through JMX. Alternatively, use the WebLogic Server Diagnostics Service to insert instrumentation code into a running application and monitor its methods or monitor transactions that involve the application.
Use this technology to discover the cause of problems that cannot otherwise be discovered by scanning the available monitoring metrics. If you determine that the problem is within your application, you can prevent the problem from recurring by using JMX to expose attributes that indicate the application's health state is degrading. Work Managers configure how your application prioritizes the execution of its work.
Based on rules you define and by monitoring actual run-time performance, WebLogic Server can optimize the performance of your application and maintain service level agreements. You can separate administration traffic from application traffic in your domain by enabling the administration port.
In production environments, separating the two forms of traffic ensures that critical administration operations starting and stopping servers, changing a server's configuration, and deploying applications do not compete with high-volume application traffic on the same network connection.
The administration port only accepts communications that use SSL, and therefore secures your administrative requests. Many WebLogic Server operations generate logs of their activity. Each server has its own log as well as a standard HTTP access log. These log files can be configured and used in a variety of ways to monitor the health and activity of your servers and applications.
WebLogic Server includes several of its own standards-based, extensible utilities that you can use to create, manage, and monitor domains, or you can use WebLogic Server's management APIs to create custom management utilities. Table describes the utilities that are included with WebLogic Server. Use it to manage and monitor an active domain. The management capabilities include:. The Administration Server persists changes to attributes in the config.
Administration Console Online Help The online help is also available from the Administration Console by clicking on the Help link located in the tool bar at the top of the Console. In addition to WebLogic scripting functions, you can use common features of interpreted languages, including local variables, conditional variables, and flow control statements. You can extend the WebLogic scripting language by following the Jython language syntax. The Configuration Wizard creates the appropriate directory structure for a WebLogic Server domain, a config.
The wizard uses templates to create domains, and you can customize these templates to duplicate your own domains. You can also use the Configuration Wizard to add or remove services from an existing, inactive domain. You can run the Configuration Wizard through a graphical user interface GUI or in a text-based command-line environment.
This command-line environment is called console mode —do not confuse this mode with the Administration Console. You can also create user-defined domain configuration templates for use by the Configuration Wizard.
The Configuration Template Builder provides the capability to easily create your own domain templates, to enable, for example, the definition and propagation of a standard domain across a development project, or to enable the distribution of a domain along with an application that has been developed to run on that domain.
The templates you create with the Configuration Template Builder are used as input to the Configuration Wizard as the basis for creating a domain that is customized for your target environment.
You can use two Ant tasks provided with WebLogic Server to help you perform common configuration tasks in a development environment. Ant is a Java-based build tool similar to Make. The configuration tasks let you start and stop WebLogic Server instances as well as create and configure WebLogic Server domains. When combined with other WebLogic Ant tasks, you can create powerful build scripts for demonstrating or testing your application with custom domains.
Table describes APIs that you can use to create your own management utilities. Like SNMP and other management standards, JMX is a public specification and many vendors of commonly used monitoring products support it.
All WebLogic Server deployment tools, such as the Administration Console and wldeploy Ant task, use the deployment API to configure, deploy, and redeploy applications in a domain.
The WebLogic Diagnostic Service includes a set of standardized APIs that enable dynamic access and control of diagnostic data, as well as improved monitoring that provides visibility into the server. The interfaces are standardized to facilitate future enhancement and integration of third-party tools, while maintaining the integrity of the server code base.
The service is well suited to the server and the server's stack product components and targets operations and administrative staff as primary users. The Administration Console is a Web browser-based, graphical user interface that you use to manage a WebLogic Server domain. Clusters are groups of WebLogic Servers instances that work together to provide scalability and high-availability for applications. You deploy and manage your applications as part of a domain.
The Administration Server hosts the Administration Console, which is a Web application accessible from any supported Web browser with network access to the Administration Server. Managed Servers host applications. Administration Console Reference, which provides reference information for each page in the Console, including descriptions of the attributes you can set using the Console.
Messages including information, warning, and error messages can be generated and logged in the course of using the Administration Console. To use the Administration Console, use one of the supported Web browsers for your environment.
If your Web browser is not on this list of supported browsers, you may experience functional or formatting problems when using the Administration Console. If you have configured a domain-wide administration port, use that port number.
When the login page appears, enter the user name and the password you used to start the Administration Server you may have specified this user name and password during the installation process or enter a user name that belongs to one of the following security groups: Administrators, Operators, Deployers, or Monitors.
These groups provide various levels of access to system administration functions in the Administration Console. Using the security system, you can add or delete users to one of these groups to provide controlled access to the Console.
By default, the Administration Console is enabled. See Using the Change Center. This panel contains a tree structure you can use to navigate to pages in the Administration Console. Select any of the nodes in the Domain Structure tree to view that page. A series of links that show the path you have taken through the Administration Console's pages.
You can click on any of the links to return to a previously-visited page. The System Status panel reports on the number of information, error, and warning messages that have been logged.
The Change Center provides a way to lock a domain configuration so you can make changes to the configuration while preventing other accounts from making changes during your edit session. See How Change Management Works. The domain configuration locking feature is always enabled in production domains. It can be enabled or disabled in development domains. It is disabled by default when you create a new development domain. Make the changes you desire on the relevant page of the Console. Click Save on each page where you make a change.
When you have finished making all the desired changes, click Activate Changes in the Change Center. As you make configuration changes using the Administration Console, you click Save or in some cases Finish on the appropriate pages.
This does not cause the changes to take effect immediately. The changes take effect when you click Activate Changes in the Change Center. At that point, the configuration changes are distributed to each of the servers in the domain. If the changes are acceptable to each of the servers, then they take effect. If any server cannot accept a change, then all of the changes are rolled back from all of the servers in the domain.
The changes are left in a pending state; you can then either edit the pending changes to resolve the problem or revert the pending changes. You can revert any pending saved, but not yet activated changes by clicking Undo All Changes in the Change Center. You can revert any individual change by going to the appropriate page in the Administration Console and restoring the attribute to its previous value. Before you make changes, click Release Configuration in the Change Center to release the lock explicitly.
Stopping the Administration Server does not release the configuration lock. When the Administration Server starts again, the configuration lock is in the same state it was in when the Administration Server was shut down, and any pending changes are preserved. To provide a secure, predictable means for distributing configuration changes in a domain, WebLogic Server imposes a change management process that loosely resembles a database transaction.
The configuration of a domain is represented on the file system by a set of XML configuration files, centralized in the config.
When you edit the domain configuration, you edit a separate hierarchy of Configuration MBeans that resides on the Administration Server.
To start the edit process, you obtain a lock on the edit hierarchy to prevent other people from making changes. When you finish making changes, you save the changes to the edit hierarchy. The changes do not take effect, however, until you activate them, distributing them to all server instances in the domain. When you activate changes, each server determines whether it can accept the change.
If all servers are able to accept the change, they update their working configuration hierarchy and the change is completed. Some changes you make in the Administration Console take place immediately when you activate them. Other changes require you to restart the server or module affected by the change. These latter changes are called non-dynamic changes. Non-dynamic changes are indicated in the Administration Console with this warning icon:.
Changes to dynamic configuration attributes become available once they are activated, without restarting the affected server or system restart. These changes are made available to the server and run-time hierarchies once they are activated. Changes to non-dynamic configuration attributes require that the affected servers or system resources be restarted before they become effective. If a change is made to a non-dynamic configuration setting, no changes to dynamic configuration settings will take effect until after restart.
This is to assure that a batch of updates having a combination of dynamic and non-dynamic attribute edits will not be partially activated. Note that WebLogic Server's change management process applies to changes in domain and server configuration data, not to security or application data. You can view any changes that you have saved, but not yet activated, by clicking the View Changes and Restarts link in the Change Center. The Restart Checklist lists all servers for which non-dynamic changes have been activated, but which require restarts before the changes become effective.
When you use the Administration Console to deploy multiple applications, upon installing the applications, they are listed in the Console's Deployments page in the "distribute Initializing" state. After activating changes, they are listed in the "Prepared" state. To deploy the applications, select the application names on the Deployments page and click Start. High Availability The following WebLogic Server features and tools support the deployment of highly-available and scalable applications: WebLogic Server clusters provide scalability and reliability for your applications by distributing the work load among multiple instances of WebLogic Server.
System Administration System administration of a WebLogic Server environment includes tasks such as creating WebLogic Server domains; deploying applications; migrating domains from development environments to production environments; monitoring and configuring the performance of the WebLogic Server domain; and diagnosing and troubleshooting problems.
Diagnostic Framework The WebLogic Diagnostic Framework is a monitoring and diagnostic service that lets you create, collect, analyze, archive, and access diagnostic data generated by a running server and its deployed applications.
Security The WebLogic Server security architecture provides a comprehensive, flexible security infrastructure designed to address the security challenges of making applications available on the Web.
Client Options In addition to support for browser-based Web application clients, WebLogic Server also supports a variety of client types for creating rich GUI applications or simple command-line utilities.
0コメント