Explore topic-wise InterviewSolutions in .

A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that CONSTITUTE a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by ADDING additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the INCREMENTAL server instances. Each server instance in a cluster must run the same version of WebLogic Server.

 Benefits of clustering:

Scalability:

 The capacity of an APPLICATION deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster WITHOUT interruption of service, the application continues to run without impact to clients and end users.

High-Availability:

In a WebLogic Server cluster, application processing can continue when a server instance fails. You "cluster" application components by deploying them on multiple server instances in the cluster, so, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.

A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.

 Benefits of clustering:

Scalability:

 The capacity of an application deployed on a WebLogic Server cluster can be increased dynamically to meet demand. You can add server instances to a cluster without interruption of service, the application continues to run without impact to clients and end users.

High-Availability:

In a WebLogic Server cluster, application processing can continue when a server instance fails. You "cluster" application components by deploying them on multiple server instances in the cluster, so, if a server instance on which a component is running fails, another server instance on which that component is deployed can continue application processing.

• The non-SSL LISTEN port for the Administration Server's DEFAULT network configuration is 7001 by default.
•  The SSL listen port for the Administration Server's default network configuration is 7002 by default.
• WebLogic Admin servers and Managed servers could communicate with Admin port which is separate network CHANNEL. So that other communications can be run on different networks.

A domain template is a JAR file default one is wls.jar file, which is '/bea/weblogic81/common/templates/domains/, it has all the features that is required for the STANDARD WEBLOGIC domain, we can even create domain template of our own configuration. by this template we dont have to configure EVERY time we create a NEW domain.

 By using template we can:

• Create servers.
• Clusters.
• Machines.
• Configure services such as JMS, JDBC, Applications

A domain template is a jar file default one is wls.jar file, which is '/bea/weblogic81/common/templates/domains/, it has all the features that is required for the standard weblogic domain, we can even create domain template of our own configuration. by this template we dont have to configure every time we create a new domain.

 By using template we can:

• JMS (Java Message Service) is a standard API for accessing enterprise messaging systems. Specifically, WebLogic JMS:
• Enables Java applications sharing a messaging system to exchange messages.
• SIMPLIFIES application development by providing a standard interface for creating, sending, and receiving messages.
• Using the Administration Console, you define configuration attributes to:

1. CREATE JMS servers and target a WebLogic Server instance or a Migratable Target where the JMS server will be deployed.
2.  Create and/or customize values for JMS servers, connection factories, destinations (queues and topics), JMS templates, destination SORT order (using destination keys), persistent STORES (FILE or JDBC), paging stores, session pools, and connection consumers.
3.  Define message and/or bytes thresholds and quotas, as well as a maximum allowable message size on your JMS servers, destinations, and templates.

Enable any desired WebLogic JMS features, such as:

Server clustering using multiple connection factories.

• High availability and load balancing for destinations across a cluster by using distributed destinations.
• Persistent messages and durable subscribers.
• Paging out message bodies during peak load periods to free up memory.
• Controlling message flow during peak load periods, including blocking message producers.
• Establishing a message expiration policy to ensure that expired messages are cleaned up immediately.
• Preventing message quota errors by temporarily blocking message producers from sending messages to a destination when it exceeds its specified maximum message quota.
• Concurrent message processing via session pools.

Enable any desired WebLogic JMS features, such as:

Server clustering using multiple connection factories.

There are two MODES: Development and production mode:

 Development mode:

1. You use development mode while you are developing your applications. Development mode uses a relaxed security CONFIGURATION and enables you to auto-deploy applications.
2. You can use the demonstration digital CERTIFICATES provided by the WebLogic Server security services. With these certificates, you can design your application to work within environments secured by SSL.
3. WebLogic Server instances can automatically deploy and update applications that reside in the domain_name/applications directory.
4. When you start a server, the server automatically renames (rotates) its local server log file as server-name.log.n. For the REMAINDER of the server session, the server rotates its local log file whenever the size of the file reaches 500 kilobytes.
5. The default number of threads available to Execute Queues is 15.

 The default capacity is 15 JDBC connections.

 Production mode:

1.  You use production mode when your application is running in its final form. A production domain uses full security and may use clusters or other advanced features.
2. A warning message is displayed if you use the demonstration digital certificates.
3. The auto-deployment feature is disabled, so you must use the WebLogic Server Administration Console or the weblogic.Deployer TOOL.
4. A server rotates its local log file after the size of the file reaches 500 kilobytes.
5. The default number of threads available to Execute Queues is 25.
6. The default capacity is 25 JDBC connections.

There are two modes: Development and production mode:

 Development mode:

 The default capacity is 15 JDBC connections.

 Production mode:

• Choose the DB type (Oracle, Sybase, Mysql, etc...).
• Then choose the driver type for the DB.
• Give the connection pool name.
• Give the DB Service ID, schema name and password.
• Then it will ASK for testing the connection pool/DataSource.
• After successful connection, it will ask you to CREATE and deploy the connection pool target to server or cluster. After CREATING new connection pool always point the jdbcstore to the connection pool created. This is required because A JMS JDBC store will be used for persistent messaging.
• After each JDBC connection, we have to restart the server if there is startup classes dependancy exists otherwise no restart required in WebLogic 9.x and higher versions.

• BACKUP the configuration by rename config.xml with config.xml_date
• Configure the changes in the startManagedWebLogic.sh /cmd with weblogic home and JAVA home and GIVE the admin severs URL UPDATED
• Go to weblogic admins console and add a managed server and give the IP and port of the managed server. all the changes CONFIRMED then start the server using startManagedWebLogic.sh script present in the domain bin.

When you upgrade a domain to WebLogic Server 8.1, consider upgrading your JVM to JRockit. WebLogic JRockit is a JVM designed for running server-side applications in Windows and Linux running on Intel architectures. For server-side applications, JRockit has these advantages over other virtual machines:

 It employs adaptive optimization, which detects and removes bottlenecks in the deployed APPLICATION.

 It is designed specifically for the special requirements of server-side applications, which tend to be parallel and thread-intensive, to RUN for longer periods of time, and not to use graphical interfaces.

 You can monitor JRockit using the WebLogic Server Administration Console.

 Steps to change:

 In the server start scripts, set JAVA_HOME (or equivalent) shell variables to point to the JRockit root directory. For example, change:

@rem Set user-defined variables.

set JAVA_HOME=WL_HOMEjdk131

 where WL_HOME is the WebLogic Server 7.0 installation directory, to

@rem Set user-defined variables.

set JAVA_HOME=WL_HOMEjrockit81_141_02

 where WL_HOME is the WebLogic Server 8.1 installation directory.

 Change the domain’s config.xml to use the JRockit javac.exe. For example, change

JavaCompiler="WL_HOMEjdk131binjavac"

 where WL_HOME is the WebLogic Server 7.0 installation directory, to

JavaCompiler=WL_HOMEjrockit81_141_02binjavac”

where WL_HOME is the WebLogic Server 8.1 installation directory.

 Remove from server start scripts any switches specific to the Sun JVM. For example, from the start command:

ECHO on "%JAVA_HOME%binjava" -HOTSPOT .... weblogic.Server delete “-hotspot”.

When you upgrade a domain to WebLogic Server 8.1, consider upgrading your JVM to JRockit. WebLogic JRockit is a JVM designed for running server-side applications in Windows and Linux running on Intel architectures. For server-side applications, JRockit has these advantages over other virtual machines:

 It employs adaptive optimization, which detects and removes bottlenecks in the deployed application.

 It is designed specifically for the special requirements of server-side applications, which tend to be parallel and thread-intensive, to run for longer periods of time, and not to use graphical interfaces.

 You can monitor JRockit using the WebLogic Server Administration Console.

 Steps to change:

 In the server start scripts, set JAVA_HOME (or equivalent) shell variables to point to the JRockit root directory. For example, change:

@rem Set user-defined variables.

set JAVA_HOME=WL_HOMEjdk131

 where WL_HOME is the WebLogic Server 7.0 installation directory, to

@rem Set user-defined variables.

set JAVA_HOME=WL_HOMEjrockit81_141_02

 where WL_HOME is the WebLogic Server 8.1 installation directory.

 Change the domain’s config.xml to use the JRockit javac.exe. For example, change

JavaCompiler="WL_HOMEjdk131binjavac"

 where WL_HOME is the WebLogic Server 7.0 installation directory, to

JavaCompiler=WL_HOMEjrockit81_141_02binjavac”

where WL_HOME is the WebLogic Server 8.1 installation directory.

 Remove from server start scripts any switches specific to the Sun JVM. For example, from the start command:

echo on "%JAVA_HOME%binjava" -hotspot .... weblogic.Server delete “-hotspot”.

Sun Hotspot JDK default for Development installation, JRockit is for Production mode for WebLogic 11G and 12C. Operating ENVIRONMENT also factor to select the Certified JDK JVM. If you want to change you need to specify it.

Sun Hotspot JDK default for Development installation, JRockit is for Production mode for WebLogic 11g and 12c. Operating environment also factor to select the Certified JDK JVM. If you want to change you need to specify it.

An APPLICATION-specific XML-based deployment descriptor file named web.xml, which lists your application's J2EE components and their configurations as J2EE modules. Each J2EE module is a collection of one or more J2EE components of the same container type (Web or EJB) that are REPRESENTED by one component deployment descriptor for that type in the web.xml file.

A WEBLOGIC-specific deployment descriptor file named weblogic.xml, which DEFINES how named resources in the web.xml file are mapped to WebLogic Server resources. Examples of weblogic.xml attributes include HTTP session parameters, HTTP cookie parameters, JSP parameters, resource references, SECURITY role assignments, and container attributes.

An application-specific XML-based deployment descriptor file named web.xml, which lists your application's J2EE components and their configurations as J2EE modules. Each J2EE module is a collection of one or more J2EE components of the same container type (Web or EJB) that are represented by one component deployment descriptor for that type in the web.xml file.

A WebLogic-specific deployment descriptor file named weblogic.xml, which defines how named resources in the web.xml file are mapped to WebLogic Server resources. Examples of weblogic.xml attributes include HTTP session parameters, HTTP cookie parameters, JSP parameters, resource references, security role assignments, and container attributes.

Modules and applications have DEPLOYMENT descriptors—XML documents—that DESCRIBE the contents of the directory or JAR FILE. Deployment descriptors are text documents formatted with XML tags. The J2EE specifications DEFINE standard, PORTABLE deployment descriptors for J2EE modules and applications.

Modules and applications have deployment descriptors—XML documents—that describe the contents of the directory or JAR file. Deployment descriptors are text documents formatted with XML tags. The J2EE specifications define standard, portable deployment descriptors for J2EE modules and applications.