Weblogic Application Server

Basic Concepts

By - Anuj Tomar

Topics to be covered

> Introducing Oracle Weblogic Application Server

> Configuring a Simple Domain

> Using Administration Console and WLST

> Configuring Managed Servers

> Configuring Node Managers

> Deployment Concepts

> Understanding JDBC and Configuring Data Sources

> Setting Up Java Message Service (JMS) Resources

> Introduction to Clustering

> Protecting Against Attacks

2

Introducing Oracle Weblogic Application Server> Oracle WebLogic Server is a scalable, enterprise-ready Java

Platform, Enterprise Edition (Java EE) application server. The WebLogic Server infrastructure supports the deployment of many types of distributed applications and is an ideal foundation for building applications based on Service Oriented Architectures (SOA).

> WebLogic Server enables enterprises to deploy mission-critical applications in a robust, secure, highly available, and scalable environment

3

4

Weblogic Server versions

5

> WebLogic Server 12c Release 2 (12.1.2) - July 11, 2013 > WebLogic Server 12c Release 1 (12.1.1) - Dec 1, 2011 > WebLogic Server 11gR1 PS5 (10.3.6) - February 26, 2012 ………> WebLogic Server 11gR1 PS1 (10.3.2) - November 2009> WebLogic Server 11g (10.3.1) - July 2009> WebLogic Server 10.3 - August 2008 > WebLogic Server 10.0 - March 2007 ………> WebLogic Tengah 3.0 - January 1998 > WebLogic Tengah - November 1997 

>  the biggest difference is that the versions have updated support for the latest J2EE specifications & bug fixes/new features, 12c supports Java EE 6 & JDK7

Installing Oracle WebLogic Server

> Installing WebLogic Server Using Both the Graphical User Interface (GUI) and Command Line

/home/Oracle/jdk7_15/jdk1.7.0_15/bin/java -jar wls_xxxx.jar

/home/Oracle/jdk7_15/jdk1.7.0_15/bin/java –d64 –jar wls_xxxx.jar

> Silent Installation:

java -jar wls1033_generic.jar -mode=silent -silent_xml=path_to_silent.xml

> Navigating the WebLogic Server Online and Offline Documentation> Online Documentation:http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html> Offline Documentation:You can download the same from above link or use contextual help associated with items on weblogic console under help section.

6

silent.xml

Contents of the WebLogic Server Directory Structure

7

> 7

Domain name

Start and stop scripts

Root configuration for the domain

Configuration files for WLDF, JDBC, JMS, and Security

Pending configuration changes

Subdirectory for each Managed Server in the domain

Configuring a Simple Domain

> Comparing Administration and Managed Servers – Admin Servers> What is Admin Server?

> Central configuration controller for the entire domain

> What else does it do?> Hosts the Administration Console> Enables you to start and stop servers from a central location> Enables you to deploy applications within the domain

> Guidelines:> There must be exactly one* Administration Server in domain> An Administration Server controls only one domain.> For production use, it is recommend not hosting application logic or resources on

the Administration Server

*The Administration Server does not need to run at all times, but is required for making configuration and deployment changes to a running domain.

8

weblogic_domain_installation10.3.6.txt

Configuring a Simple Domain -2

> Comparing Administration and Managed Servers – Managed Servers> A running instance that hosts applications and resources needed by those

applications - The real work horses in a WebLogic domain> Each Managed Server is independent of all other Managed Servers in the

domain (unless they are in a cluster, defined later)> You can have as many Managed Servers in a domain as you need> Individual Managed Servers are typically added for capacity and application

isolation

> Admin Server to Managed Server Interaction> The Administration Server stores the master copy of the domain configuration,

including the configuration for all managed servers in the domain> Each Managed Server stores a local copy of its configuration. > When a Managed Server starts, it connects to the Administration Server to

synchronize the configuration> When configuration is changed, the Administration Server sends changed

configuration to Managed Servers

9

Using Administration Console and WLST> Identifying Dynamic and Non-dynamic Attribute Changes in the

Administration Console

> Customizing Monitoring Tables within the Administration Console

> Using the WebLogic Scripting Tool (WLST) Command-line Utility

 

> WLST offline - analogous to the Configuration Wizard

> WLST online - analogous to the Admin Console

10

<WL_HOME>/common/bin/wlst.sh wls:offline/>startServer('AdminServer','mydomain','t3://localhost:7001','weblogic','weblogic','<WL_DOMAIN_DIR>','true')

wls:/offline> connect('weblogic','weblogic','t3://localhost:8001')wls:/mydomain/serverConfig>

Configuring Managed Servers

> Configuring Managed Servers Using the Administrative Console> In Console after lock & edit Create new managed server & Provide following

details> ServerName/Listen Address/Port/SSL Listen Port

> Starting Managed Servers> Start using Admin Console(if Node manager is configured)> /<DOMAIN_NAME>/bin/startManagedWebLogic.sh <managed_server_name> <admin_url>> The startManagedWebLogic script does the following:

> Calls the startWebLogic script, which sets the environment variables by invoking WL_HOME\user_projects\domains\DOMAIN_NAME\bin\setDomainEnv.cmd (setDomainEnv.sh on UNIX), where WL_HOME is the location in which you installed WebLogic Server.

> Invokes the java weblogic.Server command, which starts a JVM that is configured to run a WebLogic Server instance.

> When the server successfully completes its startup process, it writes the following message to standard out (which, by default, is the command window):

> <Notice> <WebLogicServer> <000360> <Server started in RUNNING mode>

11

Configuring Managed Servers - 2

> Configuring Managed Servers on a Computer Separate from the Administration Server

1. First create the domain on the node of the Administration Server.2. Initiate the pack command with the necessary options.3. Transfer the domain jar file to the second node.4. 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.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

> Explaining Administration and Managed Server Independence (MSI)

12

Configuring Managed Servers - 3

> Managed Server Independence (MSI)

> To prevent the Administration Server from becoming a single point of failure,

> MS can retrieve its configuration directly by reading a copy of the config.xml file and other files located on the Managed Server's own file system.

> MS uses cached application files to deploy the applications that are targeted to the server.

> You cannot change a Managed Server's configuration until it is able to restore communication with the Administration Server.

13

BACKUP AND RECOVERY

> • 1.Backup and Recovery Strategy • 2.Full Offline Backup and Recovery • 3.Online and Offline Domain Backup • 4.Offline Domain Recovery • 5.Instance Home Backup and Recovery

14

Configuring Node Managers

> What is Node Manager> Utility/process running on a physical server that enables you to start,

stop, suspend, and restart WebLogic Server instances remotely> Must run on each physical server that hosts WebLogic Server instances

that you want to control with Node Manager> Optional, but required to start/stop servers using the Administration

Console

> Defining the Oracle WebLogic Server Machine> A machine definition is used to associate a computer with the Managed

Servers it hosts. > Used by Node Manager in restarting a failed Managed Server> Used by a clustered Managed Server in selecting the best location for

storing replicated session data

> Configuring a Machine and Assign Servers to it by Using the Console

15

Configuring Node Managers

> Describing How to Start and Stop Procedures> Node Manager accepts commands from Administration Servers

running on the same machine and on trusted hosts. Trusted hosts are identified by IP address or DNS name in the nodemanager.hosts

> WebLogic Server installation process installs Node Manager as an operating system service: a daemon on UNIX systems, or a Windows service on Windows systems

> By default, the operating system service starts up Node Manager to listen on localhost:5556

> you must uninstall the default Node Manager service, then reinstall it to listen on a non-localhost listen address

16

Reconfigure Startup Service for Windows Installations> The directory WL_HOME\server\bin (where WL_HOME is the top-

level directory for the WebLogic Server installation) contains uninstallNodeMgrSvc.cmd, a script for uninstalling the Node Manager service, and installNodeMgrSvc.cmd, a script for installing Node Manager as a service.

> Delete the service using uninstallNodeMgrSvc.cmd.

> Edit installNodeMgrSvc.cmd to specify Node Manager's listen address and listen port.

> Make the same edits to uninstallNodeMgrSvc.cmd as you make to installNodeMgrSvc.cmd, so that you can successfully uninstall the service in the future, as desired.

> Run installNodeMgrSvc.cmd to re-install Node Manager as a service, listening on the updated address and port

17

Start/Stop servers using node manager & wlst> Start and Stop Procedures

> It is recommended that you install Node Manager to run as a startup service> Allows Node Manager to start up automatically each time the system is restarted> Scripts for start/stop : WL_HOME\server\bin> scripts set the required environment variables and start Node Manager

in WL_HOME/common/nodemanager

> Start a managed sever using node manager & wlst > Connect via wlst to admin> start('managedServerName','Server')> state('serverName','Server')OR> Start wlst do not connect to admin:> nmConnect('username','password','nmHost','nmPort',

'domainName','domainDir','nmType')> nmStart('serverName') > nmServerStatus('serverName') > nmKill('serverName')

18

LOG MANAGEMENT

> Log Monitoring > WebLogic Server subsystems use logging services to provide information about

events such as the deployment of new applications or the failure of one or more subsystems

> Server logs: DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_NAME.log

> Subsystem logs written to server logs like JDBC/JMS etc:> Domain/Access/nodemanager/stdout logs can be monitred as well to trobleshoot

the issues> Example:> ####<Mar 22, 2014 10:55:51 PM CST> <Notice> <WebLogicServer>

<MyComputer> <examplesServer><main> <<WLS Kernel>> <> <adminuser> <1080575353555> <BEA-000360> <Server started in RUNNING mode>

> Administration Console Log Management 

> Update log configuration in Servers

> Log rotation, no of days to keep logs or by size many options available in configuration

19

LOG MANAGEMENT

> Log Filtering> Log filters provide control over the log messages that get published> to filter out messages of a certain severity level, from a particular subsystem, or

according to specified criteria> Only the log messages that satisfy the filter criteria get published.

> Log Filter Expressions> The Console provides a number of controls for constructing log filter rule

expressions> You can update different combinations here and they will be updated in the

domain log file if conditions are met 

20

Deployment Concepts

> Configuring and Deploying Web Applications Via the Administration Console

> Deployment Types> Jar,war,ear> EJB> Resource Adapters etc

> Deployment Operations> Install> Update> Delete> Start> Stop

> Application States> NEW-PREPARED-ADMIN-FAILED-ACTIVE

21

Deployment Concepts

> Two Phase Deployment> Prepare Phase

> distributes or copies files and prepares the application and its components for activation> Validation of distributed items and performing error checks on them

> Activate Phase> actual deployment, or activation, of the application and its component with the relevant

server subsystem> After the activate phase, the application is made available to clients

> Staging Modes> Nostage – deafult for admin serverA server will run applications deployed to it directly from their source directories> Stage – default for managed serversAdministration Server copies source files to the staging directory on target serversThe target servers then initialize and run the application from this directory.> External_stagethe user, and not WebLogic Server, ensures that application files are copied to the server's staging directory before deployment

22

Deployment Concepts

> Autodeployment > Auto-deployment is a method for quickly deploying an application to a stand-

alone server (Administration Server) for evaluation or testing.> It is recommended that this method be used only in a single-server development

environment.>  application is copied into the \autodeploy directory of the Administration Server> Administration Server detects the presence of the new application and deploys it

automatically> Auto-deployment is intended for use with a single server target in a development

environment.> Only development mode allows you use the auto-deployment feature

> Manual Deployment > Deploy Using Admin Console> Deploy using Command Line (weblogic.Deployer)> Deploy Using WLST

23

Deployment Concepts

> Deployment Using Administration Console > Login to Console> Got to deployments link and from there you can delete/install/update the

new/existing applications

> Deployment Using Command Line (weblogic.Deployer)> Set up your local environment so that WebLogic Server classes are in your

system CLASSPATH and the JDK is available. You can use the setenv script located in your server's /bin directory to set the CLASSPATH.

> java weblogic.Deployer [Connection Arguments] [User Credentials Arguments] COMMAND-NAME command-options [Common Arguments]

> Example> java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic -password weblogic -

deploy c:\localfiles\myapp.ear> java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic -password weblogic -

deploy -targets ManagedServer-1,ManagedServer-2 c:\localfiles\myapp.ear

24

Deployment Concepts

> Deployment using wlst

> Deploy, undeploy, and redeploy applications and standalone modules to a WebLogic Server instance.

> Start and stop a deployed application.

> Syntax for deploying:> deploy(appName, path, [targets], [stageMode], [planPath], [options])

> wls:/mydomain/serverConfig/Servers> progress= deploy(appName=‘AnyApp', path=‘/usr/local/opt/myapp',createplan='true')

> wls:/mydomain/serverConfig/Servers> deploy('demoApp', 'c:/myapps/demos/app/demoApp.ear', targets='myserver', planPath='c:/myapps/demos/app/plan/plan.xml', timeout=120000)25

Deployment Concepts> listApplications

> wls:/mydomain/serverConfig> listApplications() – Shows a list of all apps deployed in wls

> Redeploy: Reloads classes and redeploys a previously deployed application.> redeploy(appName, [planPath], [options])> wls:/mydomain/serverConfig> progress=redeploy('myApp' 'c:/myapps/plan.xml')> wls:/mydomain/serverConfig/Servers> progress.getState()

> startApplication> Starts an application, making it available to users. The application must be fully configured and available in

the WebLogic domain.> startApplication(appName, [options])> wls:/mydomain/serverConfig/Servers> startApplication('BigApp', stageMode='NOSTAGE')

> stopApplication - Stops an application, making it unavailable to users. > stopApplication(appName, [options])> wls:/offline> stopApplication('BigApp')

> undeploy> undeploy(appName,[targets],[options])> wls:/mydomain/serverConfig> undeploy('businessApp', timeout=60000)

26

JDBC – Java Database Connectivity

27

> What is JDBC:> It is an API for accessing databases in uniform way

> JDBC Provides:> Platform independent access to databases> Location Transparency> Support for both two tier and multi tier models for

database access

Understanding JDBC and Configuring Data Sources

28

JDBC

>

29

Setting Up Java Message Service (JMS) Resources> How Oracle WebLogic Server JMS is implemented

> The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems. Specifically, JMS

> Enables Jfava applications sharing a messaging system to exchange messages> Simplifies application development by providing a standard interface for creating,

sending, and receiving messages> Uses MDBs to transactionally receive messages from multiple JMS providers> Messages forwarded transactionally by the WebLogic Messaging Bridge to other

JMS providers> Seamless integration with BEA Tuxedo messaging provided by WebLogic

Tuxedo Connector

30

Setting Up Java Message Service (JMS) Resources> Configuring WebLogic JMS

> Create JMS servers and target to a WebLogic Server instance – specify either JDBC/Filestore for persistent storage of messages

> Create and/or customize values for JMS servers, connection factories, queue and topic destinations, distributed destinations

> Distributed Queues provides high availability for JMS Messaging> Configure a WebLogic Messaging Bridge to forward messages (including

transactional messages) between any two messaging products

31

Introduction to Clustering> A cluster is a group of Managed Servers running simultaneously and

working together to provide increased scalability and reliability > Scalability: through parallelism > Reliability/Availability: through replication and redundancy

> A cluster appears as a single instance to most clients.

> Cluster Guidelines> All servers in a cluster must also be in the same domain.> All servers within a cluster must be at the same Maintenance Pack level.> Clustered servers can be on the same or different machines.> You can have multiple clusters in a domain.

> Target application & resources on cluster for High availability & scalability

32

Introduction to Clustering

> Load Balancing in a Cluster

> For JSPs and Servlets: load balancing is external> Web server proxy plug-in (round robin)> 3rd party hw or sw load balancer

> EJBs and RMI Objects: load balancing is done at connection> Objects are cluster-aware> Load balancing algorithm is stored in the clustered object’s stub> Objects are available on all cluster members; remote objects

connect/use according the LB algorithm in the stub> Load balancing algorithms: Round robin, weighted, random, server

affinity

33

Communication in a Cluster

• Peer to Peer using Sockets - used for:• Accessing non-clustered objects deployed to another clustered

server instance on a different machine.• Replicating HTTP session states and stateful session EJB states

between a primary and secondary server instance.• Accessing clustered objects that reside on a remote server

instance. • Peer to Peer using Unicast or Multicast - used for:

• Cluster-wide JNDI updates• Heartbeats

• Cluster-wide JNDI tree• Lists local resources and resources available throughout the cluster• List is maintained on all servers in the cluster

34

Communication in a Cluster

35

Multicast UnicastOnly option in pre-10.0 versions of WLS, continues to exist in version 10+ Available from WLS 10.0 onwardsUses UDP Multicast Uses TCP/IPRequires additional configurations to Routers, TTL when clustering across multiple subnets.

Requires no additional configuration to account for network topology.

Requires configuring the Multicast Listen Address and Port.  May need to specify the Network Interface to use on machines with multiple NICs.

Simply specify the listen address.  Supports using the Default Channel or a Custom Network Channel for cluster communication.

Each message delivered directly to and received directly from the network

Each message delivered to a group leader, which retransmits the message to other group members (N – 1) and any other group leaders (M – 1), if they exist.  The other group leaders then retransmit the message to their group members resulting in up to NxM network messages for every cluster message. Message delivery to each cluster member takes between 1 and 3 network hops.

Every server sees every other serverGroup leaders act as a message relay point to retransmit messages to its group members and other group leaders.

Cluster membership changes require 3 consecutive missed heartbeat messages to remove a member from the cluster list.

Cluster membership changes require only a single missed heartbeat message to remove a member from the cluster.

CLUSTER CONFIGURATION

> Create and Configure a Cluster 

> Extending a Cluster 

> Controlling Clustered Servers

>  Deploying Applications to a Cluster

36

SECURITY ARCHITECTURE

> WebLogic Server Security Architecture > Using Java standards (where applicable) create an

architecture that unifies security enforcement and present it as a service to other components.

> Provide consistent and unified protection for all resources hosted on WebLogic Server:

> WebLogic Server supports the Secure Sockets Layer (SSL) protocol to secure the communication between clients and server

37

SECURITY ARCHITECTURE

> Security Realms> A Security Realm is a collection of system resources

and security service providers.> Only one security realm can be active at a given time.

A single security policy is used in any realm.> Users must be recognized by an authentication

provider of the security realm

> Admin tasks include creating security realms.

> Embedded LDAP Server> In WLS users, groups, and authorization information

is stored in an embedded LDAP server38

SECURITY ARCHITECTURE

> Users and Groups> Users are entities that use WLS such as:

> Application end users> Client applications> Other WebLogic Servers

> Groups are:> Logical sets of users> Are more efficient for managing a large number of

users

> Create user and assign to different groups in Console

39

Protecting Against Attacks - SSL

> Process of Configuring Secure Sockets Layer (SSL)> Secure Socket Layer (SSL) is a protocol that enables:

> Connection security through encryption> A server to authenticate to a client> A client to authenticate to a server (optional)> Data integrity such that data that flows between a client and

server is protected from tampering by a third party

> Enable SSL port in managed server & provide SSL Port

> Configure Identity & trust stores

> Generate private key & store in keystore then create a corresponding CSR to CA which will send the signed certificate

> Import the certificate in keystore

40

Protecting Against Attacks - SSL

> The keytool Utility> keytool is a standard J2SE SDK utility for

managing:> Generation of private keys and corresponding digital

certificates> Keystores (databases) of private keys and associated

certificates> The keytool utility can display certificate and

keystore contents

41

Protecting Against Attacks - SSL

42

Command Descriptionkeytool -genkey -keystore keystorename -storepass keystorepassword

Generates a new private key entry and self-signed digital certificate in a keystore. If the keystore does not exist, it is created.

keytool -import -alias aliasforprivatekey -file privatekeyfilename.pem-keypass privatekeypassword-keystore keystorename -storepass keystorepassword

Updates the self-signed digital certificate with one signed by a trusted CA.

keytool -import -alias aliasfortrustedca -trustcacerts -file trustedcafilename.pem -keystore keystorename -storepass keystorepassword

Loads a trusted CA certificate into a keystore. If the keystore does not exist, it is created.

keytool -certreq -alias alias-sigalg sigalg-file certreq_file-keypass privatekeypassword-storetype keystoretype-keystore keystorename-storepass keystorepassword

Generates a Certificate Signing Request (CSR), using the PKCS#10 format, and a self-signed certificate with a private key.Stores the CSR in the specified certreq_file, and the certificate/private key pair as a key entry in the specified keystore under the specified alias.

keytool -list -keystore keystorename Displays what is in the keystore.

keytool -delete -keystore keystorename -storepass keystorepassword -aliasprivatekeyalias

Deletes the entry identified by the specified alias from the keystore.

keytool -help Provides online help for keytool.