WebLogic Application Deployment - AdminConsole

Deploy An Application through WebLogic Admin Console:

 1. Prepare deployment file with the following extension ( JAR, WAR,EAR,MAR ) JAR : Java Archive File WAR : Web Application Archive File EAR :Enterprise Application Archive File MAR : Metadata Application Archive File
 2. Copy the file that planning to deploy into the server.
 3. Plan where you want to deploy ( Application Server ) .

Note : Servers can be converted from Development to production and production to development.
 4. Make sure All servers up and running .

 Case1 : Deploy application in Managed severs present in one cluster .
 Case 2 : Deploy application in one of the Managed server that present in two clusters .
 Case 3 : Deploy application in all Managed servers that are in different clusters .



  Case 1 : Deploy application in Managed severs that are present in one cluster .
1. Managed Servers in selected cluster are up and Runnung.
 

2. Click on Deployment

 3. Click on Lock and Edit to enable the new button.

 4. Click on Install : Install Application Assistant will display . select the application you are trying to install than Click Next.

 5. Select the target to install the application

 6. Type the name of the application . click finish to complete .

 7. Click activate the changes .

 8. Choose the deployed application click on start > Choose Servicing All Request. Verify Status changed to Active .

 9. Testing the Application Applications are up and running :

10. Verify the application directory is created in the Managed server stage directory :

 C:\WEBLOGICTRAING\wlsDomains\Demo1\servers\Demo1_MS1\stage>ls -ltr total 0
drw-rw-rw- 2 mahi 0 0 2015-05-27 23:21 benefits_Ver1.0
drw-rw-rw- 2 mahi 0 0 2015-05-30 15:50 ShoppingCart_Application C:\WEBLOGICTRAING\wlsDomains\Demo1\servers\Demo2_MS3\stage>ls -ltr total 0
drw-rw-rw- 2 mahi 0 0 2015-05-27 23:21 benefits_Ver1.0
drw-rw-rw- 2 mahi 0 0 2015-05-30 15:50 ShoppingCart_Application

Configuring Node Manger and Machine

To configure Node manager we need to configure the Machine on the WebLogic domain. This machine can be defined with Name, type of the OS. Usually this OS type could be

1. Unix 
2. Virtual and
3. Others(non-Unix that is Windows).

Configuring Node Manager

You could configure a Node Manager in the WebLogic Domain can be of two types:

• Per Domain
• Per Machine

Here each one has its significance. Per domain is easy to maintain, when same machine is used for multiple WebLogic domains with different business environment then better to have per domain.

If all WebLogic domains related to same business unit then we can use per machine nodemanager. Example, Customer supporting domain, its OHS domain, integration domains we can use single nodemanager for all of them together. You need to ensure that nmErolled for all these domains.



Step2 :

Create Machine for Windows(Other ) and Unix

Creating Node Manager  on  Unix :

Creating Node Manager on  Windows

Node Manager Monitoring






Configuration of Node Manager properties :

Here I've Windows hosted Administration server and also I have VirtualBox having Guest OS as Precise64 which is Ubuntu Linux. So I configured two managed servers assigned in the Windows and two more in the Linux box. The final summary of machines in the domain are as follows:



Machines summary details

Select the Machine and assign the servers



Add Managed Servers .



From Admin console click on Machines  Select Servers Tab > add button in the Work area.



Select above created Machine and click Add . Select the Managed server from DropDown.

Similar  add Managed Servers to Unix Machine .

After Adding the Machines Go to the Summary

Managed Serves Summary

Start Run the Managed serves .. If the

Status of the Node Manager is Inactive  verify  Node Manager properties and update the values :

Make sure

ListenAddress  = <Host Name >  replace LocalHost to <HostName>

SecurListener = False      < Replace from True > 

Starting NodeManager from Domain bin directory

Configuring Node manager properties on a machine

Manager Server can Start even it is in Failed NOT Restartable  status using the Node Manager

Server status FAILED_NOT_RESTARTABLE

Node Manger creates Boot Identity for every WebLogic server that is controlled by Node Manager .

Node manager  monitor and creates process Id contain file .

Configuring Managed Servers

In WebLogic we have three choices for Configuring the Managed servers.

1.  Admin console . 
2. config.sh / config.cmd ( configuration wizard) 
3. WLST 

1. Using Administration console

1. Log in to admin console with your credentials
2. In the Left pane, expand the Environment in the Domain Structure > select the Server  
3. In the work-area that right side, click on the New button to Creating the Managed Servers 

Adding New managed server -  Click on New button

Update the New Managed server attribute values

Summary of Servers - Newly created managed server visible

 when does the managed server named directory will be created?
Lets check the servers directory in the domain directory... Here no new server name it will not created when it is configured.It will be

WebLogic Domain directory

Starting of Managed Servers  Syntax

Here I have a Linux environment where I can use startManagedServer.sh for those who are using Windows platform can use startManagedServer.cmd.

 vagrant@precise64:~/wlsdomain/Demo2_Domain/bin$ ./startManagedWebLogic.sh Demo2_MS1 http://192.168.33.10:8001
 

Managed servers directory will be created after First Time it Started.

2. Using the configuration Wizard to create Managed servers

To invoke the configuration Wizard we have to navigate to $WL_HOME/common/bin directory.
To run the wizard in Windows platform you have to use config.cmd script and in the Unix platform config.sh provided that platform must support X-Windows (X11 forwarding).

Here, I have Windows sample:

Invoking WebLogic domain Configuration Wizard

Configuration Wizard Choose existing Domain 

Select the Managed Servers for configuration

Add the Managed Servers - provide Name, Listen Address, Port

Skip Cluster, Machine Configurations

Configuration Summary - Added two managed servers to Domain Demo1

Configuration Progress

Finally Successful configuration changes to the Demo1 Domain 

3. Create Managed Server using WLST

Ref: Create Online managed server

6. Application Deployment

Application Deployment

The term application deployment refers to the process of making an application, library, or module available for processing client requests in a WebLogic Server domain. This process is actually unpacking the application package components, putting them into directories, and preparing them to work via WebLogic Server and resources.

Deployment components and terminology

Before we dive deeper into the deployment process let's introduce the following terms:

Applications: The definition of an application is not that simple. An application for an end user can be a whole chain of components from user interface to database, although the user is not aware of all these components. So an application consists of a program or group of programs designed for end users. Application software can be divided into two general classes: systems software and applications software. Systems software consists of low-level programs that interact with the computer at a very basic level.

Application module: It is an XML document that configures JEE resources such as JDBC, JMS, and EJBs. Application modules can be deployed as standalone modules in which their resources are bound to the global JNDI tree

Application install directory: It is a WebLogic Server directory structure, designed to help organize deployment files, and generate deployment configuration artifacts for an application or module. Also referred to as an application root directory.

Application version: A string value that identifies the version of a deployed application. It is located in the manifest file.

Deployment configuration: The process of defining the deployment descriptor values required to deploy an application to a particular WebLogic Server domain.

Deployment descriptor: It is an XML document used to define the J2EE behavior or WebLogic Server configuration of an application or module at deployment time.

Deployment plan: It is an XML document that defines an application's WebLogic Server deployment configuration for a specific WebLogic Server environment. A deployment plan resides outside the application's archive file, and can apply changes to deployment properties stored in the application's existing WebLogic Server deployment descriptors.

Distribution: It is the process by which WebLogic Server copies deployment source files to target servers for deployment Production redeployment: It is the WebLogic Server redeployment strategy that deploys a new version of a production application alongside an older version, while automatically managing HTTP connections to ensure uninterrupted client access.

Staging mode: It is the method WebLogic server uses to make deployment files available to target servers in a domain. Staging modes determine whether files are distributed to target WebLogic Managed Servers before deployment, or not.

The deployment standard: JSR-88 The following diagram shows the components of a JSR-88-compliant deployment API (Application Programming Interface).

All these following XMLs are standard JEE descriptor files:

• application.xml: This is the global application configuration file, which contains the common settings for all application modules contained in the EAR (Enterprise Archive). 
• ejb-jar.xml: This is the deployment descriptor when deploying an EJB application.
• web.xml: This represents the core of a generic Java web application. It provides configuration and deployment information for the Web components that comprise a Web application contained in a WAR (Web Application Archive).
• WebLogic.xml: This is the WebLogic-specific deployment descriptor file. The WebLogic.xml deployment descriptor follows a WebLogic-specific schema that is used only by Oracle WebLogic Server. It allows you to enable and configure Web application features that are not part of the JEE specification, such as changing the default root URL path of the Web application or directing application log messages to a dedicated log file. 
•  WebLogic-application.xml: This is the WebLogic server-specific deployment descriptor extension for the application.xml. Like all the other WebLogic-application.xml WebLogic-application.xml WebLogic-specific descriptor files, this file also enables the use of specific WebLogic features that are not a part of the JEE standards. 
• WebLogic-ejb-jar.xml: This is the WebLogic-specific descriptor for deploying an EJB application the WebLogic-ejb-jar.xml deployment descriptor follows a schema that is used only by Oracle WebLogic Server. It allows you to enable and configure EJB features that are not part of the JEE specification, such as clustering, load balancing, and failover for remote EJBs, tuning EJB performance using pool and cache settings, and many more.
• plan.xml: This is an optional XML file associated with an application; it resides outside an application archive and sets or overrides the values in the JEE deployment descriptors. It allows a single application to be easily customized to multiple deployment environments.

8. Configuration of JMS Bridges in WebLogic on Xubuntu

We can configure the JMS bridge between two different JMS providers. Here the JMS provider could be a WebLogic Domain or it could be third party JMS provider such as IBM MQ series or IBM WebSphere, Apache Active MQ.

Through the TOPIC/QUEUE we can send the message and receive the messages but through them we cannot save the messages. Whenever the Destination is online the user can receive the messages. So to overcome this Bridges are used and with them we can store the messages and whenever the user is online then the user receives the messages.

Before configuring the Bridges we need to configure the JMS Servers and JMS modules and in Bridges we need to configure the JMS bridge source and target.

JMS Bridge configuration

Procedure for the configuration of the JMS servers.
Expand Services -> Select the JMS server

Prerequisites for Bridge configuration

Source

• Connection URL : t3://JMS Destination Host:Port (may be cluster address or admin)
• Connection Factory JNDI : jndi/hdfccf
• JMS Destination JNDI : jndi/hdfct (topic)

Target

• Connection URL : t3:// JMS Destination Host:Port (may be cluster address or admin)
• Connection Factory JNDI : jndi/axiscf
• JMS Destination JNDI : jndi/axist

Give the name and select the Adapter name as NoTX as we are configuring the Non XA transactions and give the source connection url and give the source connection factory name under Connection Factory JNDI name and source topic or queue in Destination JNDI Name.

The same process should be done for the destination also and this should be also be configured at the same server under which the source is configured.

Name can be configured as per requirement and select the Adapter JNDI name depending the XA or Non XA transactions and it should be observed that the destination URL is given and the destinations connection factory under connection factory JNDI name and destination topic or Queue under destination Jndi name.



JMS Bridge Source Configuration

JMS Bridge Target destination configuration

Configuring a Bridge
From the Message services select the Bridges expand it. Click new button if it is production you need to acquire the lock and then do this.

JMS Bridge configuration properties

Selection of Source in Bridge configuration

Select the Source destination as per the specification HDFC source and press Next button
Select the type of messaging Provider

JMS Destination Message provider for Source

JMS Target destination provider details select as WebLogic

JMS Bridge configuration Target destination

Select the destination messaging provider and select the messaging provider as WebLogic and if it is any other JMS providing server then select the other server.

JMS Bridge target configuration

Finally you need to target the JMS Bridge to cluster or admin server as per the project needs. Here is sample showing Admin server as target.

Select the server on to which the messaging bridge should be targeted. As we are in the non-production environment we are proceeding with the only Admin Server. In the real time process we need to target them on to the cluster for the better availability and better performance.


Final step of JMS Bridge configuration

Press the ‘Finish’ button

Monitoring Bridges
After the bridge has been created once we need to check the state and description (state should be active and description should be Forwarding messages state). Select the Bridges  select the created bridge and  select the monitoring tab and in this we can find the below screen shot.

JMS Bridge status monitoring

13.c WebLogic Security: JMS Queue deliver to Authenticated users

Securing WebLogic JMS Resources

By default, destinations are not protected. This means that any valid user for a WebLogic server instance can send, receive, and browse messages on a destination. Security policies allows only users defined by the policy condition to have access control of the destination.

There are two ways of securing the JMS resources.
1.At the JMSModule level (Group level), where a single security policy is specified for a set of JMS resources.
2.At the individual JMS resource level, which provides much more grained controlled over the operations that you want to secure.

Here I am illustrating the usage of single User allowed to access a Queue send and receive messages.

Steps to configure security for JMS distributed queue.

1. Setting the security policy.

JMS Queue Configuration

 1.1. Login into the Admin server console –> Navigate to the Distribute Queue that needs to be secured.
1.2. Click on the security tab –> Policies sub tab. We can see a small drop down list, which lists the set of the operations that can be protected.

Selecting Predicate List

1.3. Click Add Conditions to add the policy conditions as Shown

Setting up the Policy condition

1.4. From the predicate list, specify the policy conditions. We would select the 'User' from the drop down list for demo purpose.

1.5. Click on User Hari check box and save it.

JMS Queue adding user 'Hari'

Now all set to test our secure JMS messaging.

In the JMS Destination lookup code, we need to pass the username and password who has the access permissions on the resource.

env.put(Context.SECURITY_PRINCIPAL, “Username”);
env.put(Context.SECURITY_CREDENTIALS, “password”);

To send a JMS message to the queue with the user credentials, execute the below QueueSend.java program.

package jms.test;
import java.io.BufferedReader; 
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Hashtable;
import javax.jms.*;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class QueueSend
{
public final static String JNDI_FACTORY="weblogic.jndi.WLInitialContextFactory";
public final static String JMS_FACTORY="CF";
public final static String QUEUE="Queue";
private QueueConnectionFactory qconFactory;
private QueueConnection qcon;
private QueueSession qsession;
private QueueSender qsender;
private Queue queue;
private TextMessage msg;
public void init(Context ctx, String queueName)     throws NamingException, JMSException
{
qconFactory = (QueueConnectionFactory) ctx.lookup(JMS_FACTORY);
qcon = qconFactory.createQueueConnection();
qsession = qcon.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
queue = (Queue) ctx.lookup(queueName); 
qsender = qsession.createSender(queue);
msg = qsession.createTextMessage();
qcon.start();   
} 
public void send(String message) throws JMSException {
msg.setText(message);
qsender.send(msg);
} 
public void close() throws JMSException {
qsender.close();
qsession.close();
qcon.close();
}
public static void main(String[] args) throws Exception {
if (args.length != 1) {
System.out.println("Usage: java examples.jms.queue.QueueSend WebLogicURL");
return;
}
InitialContext ic = getInitialContext(args[0]);
QueueSend qs = new QueueSend();
qs.init(ic, QUEUE);
readAndSend(qs);
qs.close();
}
private static void readAndSend(QueueSend qs)     throws IOException, JMSException 
{     
BufferedReader msgStream = new BufferedReader(new InputStreamReader(System.in));
 String line=null;
boolean quitNow = false;
do {
System.out.print("Enter message (\"quit\" to quit): \n");
line = msgStream.readLine();
if (line != null && line.trim().length() != 0) {
qs.send(line);
System.out.println("JMS Message Sent: "+line+"\n");
quitNow = line.equalsIgnoreCase("quit");
}
}
 while (! quitNow); 
}
private static InitialContext getInitialContext(String url)     throws NamingException
{
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
env.put(Context.PROVIDER_URL, url);
env.put(Context.SECURITY_PRINCIPAL, "Hari");
env.put(Context.SECURITY_CREDENTIALS, "welcome1");
return new InitialContext(env);
}
}

JMS Queue Send program execution

package jms.test;

import java.util.Hashtable;
import javax.jms.*;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class QueueReceive implements MessageListener
{
public final static String JNDI_FACTORY="weblogic.jndi.WLInitialContextFactory";
public final static String JMS_FACTORY="CF";
public final static String QUEUE="Queue";
private QueueConnectionFactory qconFactory;
private QueueConnection qcon;
private QueueSession qsession;
private QueueReceiver qreceiver;
private Queue queue;
private boolean quit = false;
public void onMessage(Message msg)
{
try {
String msgText;
if (msg instanceof TextMessage) {
msgText = ((TextMessage)msg).getText();
}
 else
 {
msgText = msg.toString();
}
System.out.println("Message Received: "+ msgText );
if (msgText.equalsIgnoreCase("quit")) {
synchronized(this) {
quit = true;
this.notifyAll(); // Notify main thread to quit
}
}
} catch (JMSException jmse) {
System.err.println("An exception occurred: "+jmse.getMessage());
}
}
public void init(Context ctx, String queueName)
throws NamingException, JMSException
{
qconFactory = (QueueConnectionFactory) ctx.lookup(JMS_FACTORY);
qcon = qconFactory.createQueueConnection();
qsession = qcon.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
queue = (Queue) ctx.lookup(queueName);
qreceiver = qsession.createReceiver(queue);
qreceiver.setMessageListener(this);
qcon.start();
}
public void close()throws JMSException
{
qreceiver.close();
qsession.close();
qcon.close();
}
public static void main(String[] args) throws Exception {
if (args.length != 1) {
System.out.println("Usage: java examples.jms.queue.QueueReceive WebLogicURL");
return;
}
InitialContext ic = getInitialContext(args[0]);
QueueReceive qr = new QueueReceive();
qr.init(ic, QUEUE);
System.out.println("JMS Ready To Receive Messages (To quit, send a \"quit\" message).");
 synchronized(qr) {
 while (! qr.quit) {
 try {
 qr.wait();
 } catch (InterruptedException ie) {}
 }
 }
 qr.close();
}
private static InitialContext getInitialContext(String url)
throws NamingException
{
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
env.put(Context.PROVIDER_URL, url);
env.put(Context.SECURITY_PRINCIPAL, "Hari");
env.put(Context.SECURITY_CREDENTIALS, "welcome1");
return new InitialContext(env);
}
}

Note Here: In the program if you are unable to compile change the HashTable line...

        Hashtable<String,String> env= new Hashtable<String,String>();
 
Now execute the QueueRecive.java program as below to check to verigy Hari user is recived messages or not

JMS Queu Receive Program execution output