In the previous chapter, you've managed to install the Oracle WebLogic Server software and discovered its different options, such as the GUI, the console, and the silent installation.
You are now busy making automated installation for your company based on scripts and XML templates for the various environments that are going to be used.
Your boss got inspired by you, and began installing his own WebLogic. One day, with sweat on his forehead, he came out of his office, and yelled, "My WebLogic installation has been successful!!" When you entered his office you saw that he was right. But now, he asked, "What's next?"
That's a good question…what's next?
Of course, you knew that only installing the software wouldn't be enough. Now the configuration part has to take place. This next step that you will have to take can be done in two ways:
- If you use your Oracle WebLogic with another product from the Oracle product stack, such as Oracle SOA Suite, Oracle WebCenter, or Oracle Service Bus, you will have to install this software before domain creation.
- If not, you can continue and follow the steps that are involved in creating a domain.
Firstly, it is a good thing to understand some concepts of Oracle WebLogic. For instance, what is a WebLogic domain? What is an administration server and what does it do?
A WebLogic domain is the bundled administration unit in which a WebLogic Server performs its tasks. Bundled in here are all kinds of tasks, such as leveraging applications, providing security, database access, tools, and much more.
A domain is a logically related group of Weblogic Servers that are managed as a unit. A central Weblogic Server, called the administration server, acts as the coordinator and is responsible for the management of the domain.
All other server instances except the Administration Server Instance are called Managed Server Instances. You usually deploy your applications in them.
A domain may also include WebLogic Server Clusters. Clusters are groups of WebLogic Servers that work together to provide scalability and high-availability for applications.
A minimal domain can contain only one WebLogic Server instance, which always functions as an Administration Server, but at the same time could be acting as a Managed Server. This could be the case when you are on a development system, but is not recommended for use in a production environment.
The following diagram shows a simple WebLogic domain configuration:
Before discussing the various components of a WebLogic domain, let's first create one!
We'll first start with a simple domain without cluster or any Managed Server. This is the simplest way. I'd rather like to recommend creating at least one Managed Server Instance. The extra effort needed is minimal.
The following steps need to be followed while configuring a working domain:
This is a schematic overview about how a domain is created:
- The first step to take is to run the
config.sh(*NIX) orconfig.bat(Windows). In a default WebLogic installation, (with no additional software, such as the SOA Suite or any other product installed) you can find it in the Middleware home,wlserver_10.3/common/bin. - The Middleware home depends on how you specified it during installation; it could be something such as
/u01/app/oracle/product/Middleware. - You can choose two modes: GUI or console. For this, we will use the GUI mode.
- WLST: You can create offline domains with the WebLogic Scripting Tool using templates.
After executing the
config.shthe screen appears similar to the following screenshot:
- Click Next to proceed.
Depending on the purpose of your domain, you can add software. For a simple domain, the base template is already selected. This base template, wls.jar is shipped with your WebLogic software, in the WebLogic Server Home, /common/templates.
Selection of the necessary options depends on the purpose for which your WebLogic Server will be used. The templates will be discussed later in this chapter.
You can fill in the name of your domain, as shown in the previous screenshot. Try to think of a smart name, such as the purpose for which it will be used. For instance when you use the domain for some finance applications, it could be called the finance_domain.
You have to fill in the administrator's username and password, as shown in the previous screenshot:
As shown in the previous screenshot, you have two options:
- Development Mode or Production Mode: The choice seems to be obvious. In production, you of course choose the Production Mode, but for the other stages you can choose either Development or Production Mode.
- For Production Mode you choose JRockit and for Development Mode you choose SUN Hotspot. This is recommended by Oracle.
In order to choose between Development Mode and Production Mode, please be aware of the following points:
- Stricter security policy: In Production Mode, there will be a stricter security policy at the server level. This means that a file called
boot.properties, which contains the encrypted administrator username and password, is not automatically generated. This is used to start up your WebLogic domain for authenticating the Administrator. - Automatic deployment: Automatic deployment of an application is enabled in Development Mode. So when you drop an application in a specific directory, it is automatically deployed by WebLogic Server. This is something that you would not want the default behavior to be in a production environment. In Production Mode, by default, this is switched off.
- Debugging: This is disabled by default in Production whereas in Development Mode it is enabled. The reason is apparent, since you usually do not do debugging in production because of the performance impact.
- JDK: Prod Mode: JRockit, Dev Mode: Sun: For development it does not matter what you choose, but for production it could be interesting to look at JRockit. It claims to be a very fast JVM with predictable performance. So when real-time hiccups are not wanted because of garbage collection, it might be interesting to look at JRockit. You have some more capabilities for real-time processing through smarter garbage collection. JRockit mission control gives good insight into JVM performance and other statistics.
As shown in the following screenshot, you can select optional components to configure, such as names of Managed Server instances and locations of JMS file stores. This could be a smart move, if you want to configure your domain with other than the default settings.
In the next section, you can configure some items such as the Administration Servers and Managed Servers.
- Configure the hostname as the Listen address and choose any available port. Managed Servers will be discussed later on in this book.
- You should configure a machine for your Node Manager configuration.
The Node Manager concept will be covered in Chapter 5, Managed Servers and Node Manager.
- To use the Node Manager with your Admin and Managed Servers, place them under the machine name. The deeper meanings of this will be discussed in Chapter 5,Managed Servers and Node Manager.
- Review and click Create.
Well, that was pretty easy, wasn't it? Now your domain will be created. As I mentioned before, it is better to walk through the GUI mode to get familiar with all kinds of topics, so later on we can get into the details.
After the creation of your domain is done, you now have to start it in order to login into the Administration Console. But before continuing, let's explain a few things.
By creating a domain, you define a collection of resources, such as:
- Managed Servers
- Clusters
- Database connections
- Security services
- Java EE applications
After the domain has been created, some files and directories are placed on your local server. Let's take a look:
domain-name:The name of this directory is the name of the domain.autodeploy:In development mode, WLS automatically deploys any applications or modules that you place in this directory. This directory provides a quick way to deploy applications in a development server. When the Oracle WebLogic Server instance runs in development mode, it automatically deploys any applications or modules that are placed in this directory.bin:This directory contains the scripts that are used for starting and stopping the Administration Server and the Managed Servers in the domain. These scripts are generally provided as.shfiles for UNIX and.cmdfiles for Windows. Thebindirectory can optionally contain other scripts of domain-wide interest, such as scripts to start and stop database management systems, full-text search engine processes, and so on.config:The current configuration and deployment state of the domain is stored into the configuration repository, represented as theconfig.xml. All configurations in WebLogic are stored as xml files in this directory. When the Admin Server boots, it reads this file and knows how its domain is configured. Managed Servers also use this configuration for their part/role within the domain.console-ext:This directory contains extensions to the Administration Console, which enables you to add content to Oracle WebLogic Server Administration Console, replace content, and change the logos, styles, and colors without modifying the files that are installed with Oracle WebLogic Server. For example, you can add content that provides custom monitoring and management facilities for your applications.init-info:This directory contains files that are used for WebLogic domain provisioning. You should not modify any files in this directory.lib:Any JAR files that you put in this directory are added to the Java systemCLASSPATHof each server instance in the domain when the server's Java Virtual Machine starts.pending:This directory contains the domain configuration files that represent the configuration changes that have been requested, but not yet been activated. After the configuration changes are activated, the configuration files are deleted from this directory. Configurations can be changed at runtime in the console of the Administration Server. Before they are implemented within the domain, they are temporarily stored in this directory.security:This directory holds the security-related files that are same for every Oracle WebLogic Server instance in the domain:SerializedSystemIni.dat.It also holds the security-related files that are needed only by the domain's Administration Server:DefaultAuthorizerInit.ldiftDefaultAuthenticatorInit.ldiftDefaultRoleMapperInit.ldift
servers:The server's directory that contains the subdirectories for the Administration and Managed Servers is created the first time the servers are started. This directory contains one subdirectory for each Oracle WebLogic Server instance in the domain. The subdirectories contain data that is specific to each server instance.tmp:This directory is used for temporarily storing files. You should not modify any files in this directory.user_staged_config:This directory is an alternative to theconfigdirectory, if the domain is set up such that the configuration information is "user-staged".
A domain is created based on a template. This template is a JAR (JAVA Archive) and it contains all the necessary components to create a simple WebLogic domain. The file is called wls.jar and is located in the WebLogic Server home under common/templates/domains after installation.
The types of template include:
- Domain template: It defines the full set of resources within a domain, including infrastructure components, applications, services, security options, and general environment and operating system options. The product installation includes a predefined Basic WebLogic Server Domain template. This template defines the core set of resources within a domain, including an Administration Server and basic configuration information.
- Extension template: It defines the applications and services that you can add to an existing domain, such as the Enterprise Manager, ADF Runtime libraries, or templates shipped in other Oracle products. The extension templates are located in the WebLogic Server home,
common/templates/applications.
Contents of the basic WLS template, wls.jar, are shown in the following screenshot:
One of the ways to create or use a template is the pack command (pack.sh/cmd).
The pack and unpack commands provide a simple, one-step method for creating domains and templates from the command line.
These shell scripts are available in $MW_HOME/wlserver_[ver]/common/bin.
Syntax of the pack command:
WL_HOME/common/bin/pack.sh -managed=true -domain=DOMAIN_PATH -template=DOMAIN_TEMPLATE -template_name=DOMAIN_TEMPLATE_NAME
Syntax of the unpack command:
WL_HOME/common/bin/unpack.sh -domain=DOMAIN_PATH -template=DOMAIN_TEMPLATE
You would also need pack and unpack commands to run a Managed Server on a machine that is remote from the Administration Server for the domain.
It is best to follow the procedure given next:
- First create the domain on the node of the Administration Server.
- Initiate the
packcommand with the necessary options. - Transfer the domain jar file to the second node.
- First install the Oracle WebLogic software here, and then unpack the domain. Use the same directory structure as on the first node, to have equally configured environments.
When packing a domain that contains Managed Servers, you should use the managed server=true option.
In the previous sections, we discussed domain creation through GUI, but there are some other ways to create a domain as well.
On *nix-like systems, there is usually no graphical environment available. You can solve this by exporting the GUI to your local desktop, with an XClient, such as XVNC or XMing, but if you don't do it or you give the option mode=console, you get a text-based representation of your GUI installation.
./config.sh mode=console
The output will be:
<---------------------------------------------------- BEA WebLogic Configuration Wizard ----------------------------------------------------> Welcome: -------- Choose between creating and extending a domain. Based on your selection, the Configuration Wizard guides you through the steps to generate a new or extend an existing domain. 1|Create a new WebLogic domain | Create a WebLogic domain in your projects directory. 2|Extend an existing WebLogic domain | Extend an existing WebLogic domain. Use this option to add applications and services, or to override existing database access |(JDBC) and messaging (JMS) settings. You can also incorporate additional functionality in your domain, for example, by including |AquaLogic Service Bus. Enter index number to select OR [Exit][Next]> 1 <---------------- BEA WebLogic Configuration Wizard ----------------> Select Domain Source: --------------------- Select the source from which the domain will be created. You can create the domain by selecting from the required components or by selecting from a list of existing domain templates. 1|Choose Weblogic Platform components | You can choose the Weblogic component(s) that you want supported in your domain. 2|Choose custom template | Choose this option if you want to use an existing template. This could be a custom created template using the Template Builder. Enter index number to select OR [Exit][Previous][Next]> 1 <---------------- BEA WebLogic Configuration Wizard ----------------> Application Template Selection: ------------------------------- Available Templates |_____WebLogic Server (Required)x Enter number exactly as it appears in brackets to toggle selection OR [Exit][Previous][Next]> 1 <---------------- BEA WebLogic Configuration Wizard ----------------> Application Template Selection: ------------------------------- Available Templates |_____WebLogic Server (Required)x ** Invalid input, not selectable Enter number exactly as it appears in brackets to toggle selection OR [Exit][Previous][Next]> …--> and so on.
Although WLST will be discussed later on in Chapter 13, WLST Makes an Administrator's Life Easier, let's take a sneak peek into the possibilities it has for you.
WLST is a scripting language which is based on the Python programming language. Because the WebLogic Domain software is JAVA-based, you will need the JAVA implementation of Python, which is called Jython. In fact this is where WLST does its work.
The following script is a very simple WLST script to create a WebLogic domain:
#================================================================
# Create a domain from the weblogic domain template.
#=================================================================
readTemplate('/u01/app/oracle/product/Middleware/common/templates/ domains/wls.jar')
cd('Servers/AdminServer')
#=================================================================
# Configure the Administration Server
#=================================================================
set('ListenAddress',''WLADMINIP'')
set('ListenPort', 9913)
#=================================================================
# Define the password for user weblogic. You must define the password before you
# can write the domain.
#=================================================================
cd('/')
cd('Security/base_domain/User/weblogic')
cmo.setPassword(AdminServerPassword)
# - OverwriteDomain:Overwrites domain when saving setOption('OverwriteDomain', 'true')
#=============================================================
# Write the domain, close the domain template and exit from the WLST
#===============================================================
writeDomain('/u01/app/oracle/product/Middleware/user_projects/ domains/wlsdom')
closeTemplate()
exit()
Be aware, that this is a very basic domain creation. If you create more advanced domains, such as a domain for the Oracle SOA suite, you should use more and more options to successfully create your domain, such as configuring JDBC, JMS, Resource adapters, and so on. This book is not about that, but perhaps in the future it may be included in an advanced version on WebLogic administration.
To run Oracle WebLogic Server itself, PATH and CLASSPATH environment variables are usable without any additional modification. Environment variables are set properly in start scripts, which call the setWLSEnv.sh script. The setWLSEnv.sh script is shipped with the WebLogic Server software.
The setWLSEnv script sets some WebLogic Server-specific settings, such as server CLASSPATH.
Start scripts and domain scripts are created during installation. It's possible to modify the start scripts' environment variables based on deployed applications' requirements. These start and domain scripts are created in the Domain directory, under /bin.
The scripts are:
setDomainEnv.sh:This script is used to set up all the environment variables and Java options required to run WebLogic Server, in the WebLogic Integration domain. It also calls thesetWLSEnv.shfrom the WebLogic Server home.startWeblogic.sh:This script is used to start the WebLogic Domain along with the Admin Server.stopWeblogic.sh:This script is used to stop the WebLogic Domain entirely.startManagedWeblogic.sh:This script is used to start a Managed Server instance from the command line.stopManagedWeblogic.sh:This script is used to stop a Managed Server instance from the command line.
When a domain is created, all the main basic configuration regarding the WebLogic Domain is stored in a file called config.xml. This file is stored under the WebLogic Domain directory, in the config directory.
The config.xml file consists of a series of XML elements. The Domain element is the top-level element, and all the other elements in the Domain are children of the Domain element. The Domain element includes child elements, such as the Server, Cluster, and Application elements. These child elements may have children themselves.
Editing the config.xml manually is not recommended, but if you do, you should edit it only when the WebLogic Domain is completely down, because it gets updated frequently during runtime.
The following is an example of a part of the config.xml:
<?xml version='1.0' encoding='UTF-8'?> <domain xmlns="http://xmlns.oracle.com/weblogic/domain" xmlns:sec="http://xmlns.oracle.com/weblogic/security" xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/security/xacml http://xmlns.oracle.com/weblogic/security/xacml/1.0/xacml.xsd http://xmlns.oracle.com/weblogic/security/providers/passwordvalidator http://xmlns.oracle.com/weblogic/security/providers/passwordvalidator/1.0/passwordvalidator.xsd http://xmlns.oracle.com/weblogic/domain http://xmlns.oracle.com/weblogic/1.0/domain.xsd http://xmlns.oracle.com/weblogic/security http://xmlns.oracle.com/weblogic/1.0/security.xsd http://xmlns.oracle.com/weblogic/security/wls http://xmlns.oracle.com/weblogic/security/wls/1.0/wls.xsd"> <domain xmlns="http://xmlns.oracle.com/weblogic/domain" xmlns:sec="http://xmlns.oracle.com/weblogic/security" xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/security/xacml http://xmlns.oracle.com/weblogic/security/xacml/1.0/xacml.xsd http://xmlns.oracle.com/weblogic/security/providers/passwordvalidator http://xmlns.oracle.com/weblogic/security/providers/passwordvalidator/1.0/passwordvalidator.xsd http://xmlns.oracle.com/weblogic/domain http://xmlns.oracle.com/weblogic/1.0/domain.xsd http://xmlns.oracle.com/weblogic/security http://xmlns.oracle.com/weblogic/1.0/security.xsd http://xmlns.oracle.com/weblogic/security/wls http://xmlns.oracle.com/weblogic/security/wls/1.0/wls.xsd"> <name>base_domain</name> <domain-version>10.3.3.0</domain-version> <security-configuration> <name>base_domain</name> <realm> <sec:authentication-provider xsi:type="wls:default-authenticatorType"> …………………………… <name>base_domain</name> <file-name>/u01/app/oracle/product/Middleware/logs/osb_trn_domain/osb_trn_domain.log</file-name> <rotation-type>none</rotation-type> </log> <server> <name>AdminServer</name> <log> <name>AdminServer</name> <date-format-pattern>MMM d, yyyy h:mm:ss a z</date-format-pattern> <file-name>/u01/app/oracle/product/Middleware/logs/osb_trn_domain/AdminServer.log</file-name> <rotation-type>none</rotation-type> …………………………
All configurable items that you can change end up here. Some deeper configuration items, such as JDBC and JMS, only have a top-level in the config.xml and a shortcut to their own configuration file.
For instance, when you configure a JDBC datasource named dataSource1, a file is created in the domain config/jdbc directory, usually named as dataSource1NNNN.xml.
In your config.xml, the following section will appear:
<jdbc-system-resource> <name>dataSource1</name> <target>AdminServer,ms1</target> <descriptor-file-name>jdbc/dataSource1-jdbc.xml</descriptor-file-name> </jdbc-system-resource> <jdbc-system-resource>
In designing your domain configuration, note the following restrictions:
- Each domain requires its own Administration Server for performing management activities.
- All Managed Servers in a cluster must reside in the same domain; you cannot split a cluster over multiple domains.
- All Managed Servers in a domain must run the same version of the WebLogic server software. The Administration Server may run either the same version as the Managed Servers in the domain, or a latest service pack.
- If you have created multiple domains, each domain must have its own database schema (if needed). For example, if you create a JDBC data source in one domain, you cannot use it with a Managed Server or cluster in another domain. Instead, you must create a similar data source in the second domain. Furthermore, two or more system resources cannot have the same name.
Besides the Administration Server and Managed Servers, a domain also contains the resources and services that Managed Servers and deployed applications can use in order to function properly.
Managed Servers can use the following components or resources:
- Machine definitions that identify a particular physical piece of hardware. A machine definition is used to associate a physical host with the Managed Servers it hosts. This information is used by Node Manager in restarting a failed Managed Server, and by a clustered Managed Server in selecting the best location for storing replicated session data.
- Network channels that define default ports, protocols, and protocol settings that a Managed Server uses to communicate with clients. After creating a network channel, you can assign it to any number of Managed Servers and clusters in the domain. You can configure whether a channel supports outgoing connections or not. You can independently configure network traffic for client connections and server connections, and physically separate client and server network traffic onto different listen addresses or listen ports. You can also use channels on a Managed Server to support different protocols.
- Virtual hosting, which defines a set of hostnames to which WebLogic Server instances (servers) or clusters respond. When you use virtual hosting, you use DNS to specify one or more hostnames that map to the IP address of a server or cluster. You also specify which Web applications are served by each virtual host.
Applications can use the following resources and services:
- Security providers, which are components that handle specific aspects of security, such as authentication and authorization, certificates, and digital certificates.
- Resource adapters and connection factories, which are system libraries specific to Enterprise Information Systems (EIS) and provide connectivity to an EIS.
- Diagnostics and monitoring services.
- JDBC data sources, which enable applications to connect to databases.
- Mail sessions.
- XML entity caches and registry of XML parsers and transformer factories.
- Messaging services such as JMS servers and store-and-forward services.
- Persistent store, which is a physical repository for storing data, such as persistent JMS messages. It can either be a JDBC-accessible database or a disk-based file.
- Startup classes, which are Java programs that you create to provide custom, system-wide services for your applications.
- Work Managers, which determine how an application prioritizes the execution of its work based on rules that you define and by monitoring actual run-time performance. You can create Work Managers for the entire WebLogic Server domains or for specific application components.
- Work Contexts, which enable applications to pass properties to a remote context without including the properties in a remote call.
- Clustering, to Failover and Loadbalance applications.