PowerPoint Presentation

WeblogicAdministration Guide1Road MapWeblogic Server ArchitectureInstallation & ConfigurationInstallation PrerequisitesInstallation Modes

2Weblogic Server Architecture.

3DomainA domain is a logically related group of weblogic server resources that you manage as a unit.A domain provides one point administration.A weblogic server domain can logically separate: Development, test and production applications.Organizational divisions

4Why use Domain ?A domain is an administration feature that :Is transparent to applications.Can be configured and administered, for technical or business reasons, even after applications are developed or in production.Weblogic server domains can be used to seprate :Development, test and production applications.Administration and operational responsibilites.Organizational or business divisions. 5ServerA server is an instance of weblogic.server executing a JVM.A server:Runs on a designated WLS machine.Has a dedicated amount of RAM.Is multi-threaded.

6Administration ServerAn administration server (admin) is the central point of control of a domain.An admin server:Store configuration information and logs for domain.Runs weblogic administration console.

7Managed ServerA managed server is any server in a domain that is not admin server.A managed Server:Contacts admin server for configuration information.Runs business applications in production environment.

8MachineA machine is a computer that hosts Weblogic Servers (S).A Machine :Runs a supported Operating system platform.Can host multiple weblogic server instances.

9ClusterA Cluster is a logical group of WLS server.Weblogic clusters provide automatic :Fault toleranceHigh AvailabilityLoad balancingA cluster is transparent to client.

10Installation & ConfigurationWeblogic server can be installed in three different ways.Graphical user interface mode (GUI).Console ModeSilent ModeBEA installer program supports a number of platforms including :Windows 2000, 2003, 7, XPSun SolarisLinuxHP-UnixAIX11Installation PrerequisitesComponentRequirementPlatform configurationA supported configuration of hardware, operating system, JDK, and database specific to the product you are installing.Processor1-GHz CPUHard disk driveA complete installation requires approximately 3.5 GB of disk space.MemoryA Minimum of 1 GB RAM, although we recommend 2 GB of RAM.Color bit depth display and sizeFor Graphical User Interface (GUI) mode installation, 8-bit color depth (256 colors) is required.For console-mode and silent-mode installation, there is no color bit depth requirement.JDKVersion 712Product distribution.Net installer:- This type downloads a small setup file that enables you to select the components to install on your system. The installer then downloads only the components you select. The net installer eliminates the need to download the entire product before installing it, and thereby reduces the time needed to complete the download, the disk space, and also the RAM required for installationPackage installer :- This type of installer downloads a standalone version of the installation program.For example, the Oracle WebLogic Server with Workshop for WebLogic installer contains Oracle WebLogic Server and related samples, Workshop and related samples, and the JRockit SDK and Sun JDK (for Windows and Linux platforms only).Generic installers (net and package):- This type of installer is a .jar file. It is the same as the package and net installers, except that it does not include JDKs. You can use this type of installer to install the product on UNIX machines on which Java is already installed.Link:- http://www.oracle.com/technetwork/middleware/weblogic/downloads/index.html

13Installation ModesGraphical-mode installation is an interactive, GUI-based method for installing your software. It can be run on both Windows and UNIX systemsConsole-mode installation is an interactive, text-based method for installing your software from the command line, on either a UNIX system or a Windows system.Silent-mode installation is a non-interactive method of installing your software that requires the use of an XML properties file for selecting installation options. You can run silent-mode installation from either a script or from the command line. Silent-mode installation is a way of setting installation configurations only once and then using those configurations to duplicate the installation on many machines.14

Starting the Installation Program on Windows

Graphical modeLog in to the Windows system.Go to the directory where you have downloaded the installation program.Go to the directory that contains the installation program.Double-click the installation file. For example, the name of the installation program for the Oracle WebLogic Server net installer for Windows is net_wls1031_win32.exe.The installation program begins to install the software.15

Starting the Installation Program on Windows Contd

Cosole ModeLog in to the target Windows system.Open a command prompt window.Go to the directory that contains the installation program.Launch the installation by entering the name of the installation program. For example, to start the Oracle WebLogic Server net installer for Windows in console mode, enter net_wls1031_win32.exe -mode=console

.16

Starting the Installation Program on Windows Contd

Silent ModeLog in to the Windows system.Create a silent.xml file that defines the configuration settings normally entered by a user during an interactive installation process, such as graphical-mode or console-mode installation. For information about creating a silent.xml file, see Section 5.3, "Creating a silent.xml File for Silent-Mode Installation."Open a command prompt window.Go to the directory that contains the installation program.Start the installer. For example, to launch the Oracle WebLogic Server installer on Windows, enter: wls1031_win32.exe -mode=silent -silent_xml=path_to_silent.xml Here, path_to_silent.xml is the full path of the silent.xml file.

.17

Starting the Installation Program on UNIX Contd

Graphical ModeLog in to the target UNIX system.

Go to the directory that contains the installation program.

Launch the installation by entering the following command:

chmod a+x file_name.bin ./file_name.bin

file_name.bin is the name of your installation program. For example, for Oracle WebLogic Server 10.3, the name of the net installer file for Solaris is net_wls1031_solaris32.bin.

The installation program begins to install the software..

.18

Starting the Installation Program on UNIX Contd

Console ModeTo start the console-mode installation process with .bin installation files, follow these steps:Log in to the target UNIX system.Go to the directory that contains the installation program.Launch the installation by entering the following command: chmod a+x file_name.bin ./file_name.bin -mode=console

.19

Starting the Installation Program on UNIX Contd

Silent ModeLog in to the target UNIX system.

Create a silent.xml file that defines the configuration settings normally entered by a user during an interactive installation process, such as graphical-mode or console-mode installation. For information about creating a silent.xml file, see Section 5.3, "Creating a silent.xml File for Silent-Mode Installation."Go to the directory that contains the installation program.Launch the installation program by entering the following command:

chmod a+x file_name.bin ./file_name.bin -mode=silent -silent_xml= path_to_silent.xmlfile_name.bin is the name of the installation file.path_to_silent.xml is the full path of the silent.xml file.An Installer window is displayed, indicating that the files are being extracted. No other prompt or text is displayed.

.20Installation StepsGUI mode

21Installation Steps ContdInstallation wizard

22Installation Steps ContdSelecting middleware home directory

23Installation Steps ContdRegistering for security updates

24Installation Steps ContdType of installation

25Installation Steps ContdSelecting products and components

26Installation Steps ContdType of JDK to be installed

27Installation Steps ContdProduct installation directories

28Installation Steps ContdInstallation summary

29Installation Steps ContdProduct getting installed

30Installation Steps ContdFinal result of the installation

31Creating Domain

32Creating Domain ContdConfiguration wizard to create a domainD:\oracle\middleware\common

33Creating Domain ContdGenerating a domain

34Creating Domain ContdSetting up domain name and location to create

35Creating Domain ContdConfiguring administrator username and password

36Creating Domain ContdSecuring environment and selecting the available JDK

37Creating Domain ContdType of configuration we want to implement.

38Creating Domain ContdProviding username and password to admin server

39Creating Domain ContdConfiguring a managed server

40Creating Domain ContdConfiguring a managed server

41Creating Domain ContdConfiguring a node manager

42Creating Domain ContdAssigning managed servers to the node managers

43Creating Domain ContdConfiguration summary of a domain

44Creating Domain ContdCreation of domain in -progress

45Boot.propertiesMany times we want to Alter WebLogic Admin Username and passwords on a Routine BasisIf you want to Reset The WebLogic Username and Password then Please follow the Steps mentioned Belowopen a Command Prompt and then run setDomainEnv.sh or setDomainEnv.cmd.Just for Safety Take a Backup of (D:\Oracle\Middleware\user_projects\domains\base_domain\security\*DefaultAuthenticatorInit.ldift*) file because in the Next Command which we are going to run is going to Create a New File DefaultAuthenticatorInit.ldift.In the Command Window Move inside your Domains Security DirectoryAnd then Run the Following Command:Example: D:\Oracle\Middleware\user_projects\domains\base_domain\security>java weblogic.security.utils.AdminAccount leninbabu lenin1234 .Syntax:java weblogic.security.utils.AdminAccount

46Boot.properties contd..NOTE:- There is a . (DOT) at the end of the Above command which represents the Current Directory. Here you can see that after this command Executes A new DefaultAuthenticatorInit.ldift file will be created in the Current Directory. In the Same command prompt Move inside the admin Server folder inside your domain. And then Just remname the data folder to something else .like data_OLD this is a way of taking safe backup.Example: D:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer> rename data data_OLDNow Similarly rename the boot.properties as well to an other File.Example: D:\Oracle\Middleware\user_projects\domains\base_domain\servers\AdminServer\security> rename boot.properties boot.properties_OLDAdd the following lines in boot.properties filesusername=password=Make sure that boot.properties file exists.If yes then Now start The Admin Server.

47ClusterWhat Is a WebLogic Server Cluster?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.48Cluster ContdHow Does a Cluster Relate to a Domain?A cluster is part of a particular WebLogic Server domain.A domain is an interrelated set of WebLogic Server resources that are managed as a unit.A domain includes one or more WebLogic Server instances, which can be clustered, non-clustered, or a combination of clustered and non-clustered instances.A domain can include multiple clusters.If a domain contains multiple clusters, each cluster in the domain has the same Administration Server.All server instances in a cluster must reside in the same domain; you cannot "split" a cluster over multiple domains. Similarly, you cannot share a configured resource or subsystem between domains.Clustered WebLogic Server instances behave similarly to non-clustered instances, except that they provide failover and load balancing.49Cluster ContdWhat Are the Benefits of Clustering?ScalabilityThe 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 servicethe application continues to run without impact to clients and end users.High-AvailabilityIn a WebLogic Server cluster, application processing can continue when a server instance fails.50Cluster ContdWhat Are the Key Capabilities of a Cluster?Application FailoverSimply put, failover means that when an application component (typically referred to as an "object" in the following sections) doing a particular "job"some set of processing tasksbecomes unavailable for any reason, a copy of the failed object finishes the job.WebLogic Server uses standards-based communication techniques and facilities including IP sockets and the Java Naming and Directory Interface (JNDI)to share and maintain information about the availability of objects in a cluster. These techniques allow WebLogic Server to determine that an object stopped before finishing its job, and where there is a copy of the object to complete the job that was interrupted.Information about what has been done on a job is called state. WebLogic Server maintains information about state using techniques called session replication and replica-aware stubs. When a particular object unexpectedly stops doing its job, replication techniques enable a copy of the object pick up where the failed object stopped, and finish the job.

51Cluster ContdWhat Are the Key Capabilities of a Cluster?Load BalancingLoad balancing is the even distribution of jobs and associated communications across the computing and networking resources in your environment. For load balancing to occur:There must be multiple copies of an object that can do a particular job.Information about the location and operational status of all objects must be available.WebLogic Server allows objects to be clustereddeployed on multiple server instancesso that there are alternative objects to do the same job. WebLogic Server shares and maintains the availability and location of deployed objects using unicast, IP sockets, and JNDI.52Cluster ContdWhat Types of Objects Can Be Clustered?A clustered application or application component is one that is available on multiple WebLogic Server instances in a cluster. If an object is clustered, failover and load balancing for that object is available. Deploy objects homogeneouslyto every server instance in your clusterto simplify cluster administration, maintenance, and troubleshooting.Load balancing is the even distribution of jobs and associated communications across the computing and networking resources in your environment. Following types of objects can be clustered in a WebLogic Server deploymentServletsJSPsEJBsRemote Method Invocation (RMI) objectsJava Messaging Service (JMS) destinationsJava Database Connectivity (JDBC) connections

53Load balancing clusterRound robin:- WebLogic Server uses the round-robin algorithm as the default load balancing strategyfor clustered object stubs when no algorithm is specified.This algorithm is supported for RMI objects and EJBs. It is also the method used by WebLogic proxy plug-ins.

The round-robin algorithm cycles through a list of WebLogic Server instances in order.

The advantages of the round-robin algorithm are that it is simple, cheap and very predictable. The primary disadvantage is that there is some chance of convoying.Convoying occurs when one server is significantly slower than the others. Because replica-aware stubs or proxy plug-ins access the servers in the same order, a slow server can cause requests to "synchronize" on the server, then follow other servers in order for future requests.54Load balancing cluster ContdWeight-Based Load BalancingThis algorithm applies only to EJB and RMI object clustering.Weight-based load balancing improves on the round-robin algorithm by taking into account a pre-assigned weight for each server.You can use the Server > Configuration > Cluster page in the Administration Console to assign each server in the cluster a numerical weight between 1 and 100, in the Cluster Weight field.This value determines what proportion of the load the server will bear relative to other servers.

55Load balancing cluster ContdRandom Load BalancingThis algorithm applies only to EJB and RMI object clustering.In random load balancing, requests are routed to servers at random. Random load balancing is recommended only for homogeneous cluster deployments, where each server instance runs on a similarly configured machine.A random allocation of requests does not allow for differences in processing power among the machines upon which server instances run. If a machine hosting servers in a cluster has significantly less processing power than other machines in the cluster, random load balancing will give the less powerful machine as many requests as it gives more powerful machines.Disadvantages of random load balancing include the slight processing overhead incurred by generating a random number for each request, and the possibility that the load may not be evenly balanced over a small number of requests.56Load balancing cluster ContdServer AffinityServer affinity turns off load balancing for external client connections; instead, the client considers its existing connections to WebLogic Server instances when choosing the server instance on which to access an object. If an object is configured for server affinity, the client-side stub attempts to choose a server instance to which it is already connected, and continues to use the same server instance for method calls. All stubs on that client attempt to use that server instance. If the server instance becomes unavailable, the stubs fail over, if possible, to a server instance to which the client is already connected.The purpose of server affinity is to minimize the number IP sockets opened between external Java clients and server instances in a cluster. WebLogic Server accomplishes this by causing method calls on objects to "stick" to an existing connection, instead of being load balanced among the available server instances.

57Load balancing cluster Contdround-robin-affinityserver affinity governs connections between external Java clients and server instances; round-robin load balancing is used for connections between server instances.weight-based-affinityserver affinity governs connections between external Java clients and server instances; weight-based load balancing is used for connections between server instances. random-affinityserver affinity governs connections between external Java clients and server instances; random load balancing is used for connections between server instances.58Load balancing cluster ContdServer affinity is supported for all types of RMI objects including JMS objects, all EJB home interfaces, and stateless EJB remote interfaces.The server affinity algorithms consider existing connections between an external Java client and server instances in balancing the client load among WebLogic Server instances. Server affinity:

Turns off load balancing between external Java clients and server instances Causes method calls from an external Java client to stick to a server instance to which the client has an open connection, assuming that the connection supports the necessary protocol.In the case of failure, causes the client to failover to a server instance to which it has an open connection, assuming that the connection supports the necessary protocol.59Load balancing cluster ContdServer affinity ExamplesContext from a clusterClient obtains context from the cluster. Lookups on the context and object calls stick to a single connection. Requests for new initial context are load balanced on a round-robin basis.

60Load balancing cluster ContdClient requests a new initial context from the cluster (Provider_ URL=clusteraddress) and obtains the context from MS1.Client does a lookup on the context for Object A. The lookup goes to MS1.Client issues a call to Object A. The call goes to MS1, to which the client is alreadyconnected. Additional method calls to Object A stick to MS1.Client requests a new initial context from the cluster (Provider_URL=clusteraddress) and obtains the context from MS2.Client does a lookup on the context for Object B. The call goes to MS2, to which the client is already connected. Additional method calls to Object B stick to MS2.61Load balancing cluster ContdServer Affinity and Failoverserver affinity has on object failover. When a Managed Server goes down, the client fails over to another Managed Server to which it has a connection.

62Load balancing cluster ContdClient requests new initial context from MS1.Client does a lookup on the context for Object A. The lookup goes to MS1.Client makes a call to Object A. The call goes to MS1, to which the client is alreadyconnected. Additional calls to Object A stick to MS1.The client obtains a stub for Object C, which is pinned to MS3. The client opens aconnection to MS3.MS1 fails.Client makes a call to Object A.The client no longer has a connection to MS1. Because the client is connected to MS3, it fails over to a replica of Object A on MS3.63Load balancing cluster ContdServer affinity and server-to-server connections server affinity does not affect the connections between server instances.

64Load balancing cluster ContdA JSP on MS4 obtains a stub for Object B.The JSP selects a replica on MS1. For each method call, the JSP cycles through the Managed Servers upon which Object B is available, on a round-robin basis.65Load balancing cluster ContdConnection with Load Balancing Hardwareprocedure for a client accessing a cluster through a load balancer.

66Load balancing cluster ContdWhen the client of a Web application requests a servlet using a public IP address:The load balancer routes the client's connection request to a WebLogic Server cluster in accordance with its configured policies. It directs the request to WebLogic Server A.WebLogic Server A acts as the primary host of the client's servlet session state. It uses the ranking system "Using Replication Groups" to select a server to host the replica of the session state. In the above, WebLogic Server B is selected to host the replica.The client is instructed to record the location of WebLogic Server instances A and B in a local cookie. If the client does not allow cookies, the record of the primary and secondary servers can be recorded in the URL returned to the client via URL rewriting.67Load balancing cluster ContdFailover with Load Balancing Hardware Should Server A fail during the course of the client's session, the client's next connection request to Server A also fails

68Load balancing cluster ContdIn response to the connection failure:The load balancing hardware uses its configured policies to direct the request to an available WebLogic Server in the cluster. In the above example, assume that the load balancer routes the client's request to WebLogic Server C after WebLogic Server A fails.

When the client connects to WebLogic Server C, the server uses the information in the client's cookie (or the information in the HTTP request if URL rewriting is used) to acquire the session state replica on WebLogic Server B. The failover process remains completely transparent to the client.

WebLogic Server C becomes the new host for the client's primary session state, and WebLogic Server B continues to host the session state replica. This new information about the primary and secondary host is again updated in the client's cookie, or via URL rewriting.69Server MigrationMigration in WebLogic Server is the process of moving a clustered WebLogic Server instance or a component running on a clustered instance elsewhere in the event of failure. In the case of whole server migration, the server instance is migrated to a different physical machine upon failure. In the case of service-level migration, the services are moved to a different server instance within the cluster. WebLogic Server provides feature for making JMS and the JTA transaction system highly available: migratable servers. Migratable servers provide for both automatic and manual migration at the server-level, rather than the service level.When a migratable server becomes unavailable for any reason, for example, if it hangs,loses network connectivity, or its host machine failsmigration is automatic. Upon failure, a migratable server is automatically restarted on the same machine if possible.If the migratable server cannot be restarted on the machine where it failed, it is migrated to another machine. In addition, an administrator can manually initiate migration of a server instance.70Server Migration ContdMigratable server A clustered server instance that migrates in its entirety, along with all the services it hosts. Migratable servers are intended to host pinned services, such as JMS servers and the JTA transaction recovery servers, but they can also host clusterable services. All services that run on a migratable server are highly available.Whole server migration A WebLogic Server instance to be migrated to a different physical machine upon failure, either manually or automatically.Service migration:Manual Service MigrationThe manual migration of pinned JTA and JMS-related services (for example, JMS server, SAF agent, path service, and custom store) after the host server instance fails. Automatic Service MigrationJMS-related services, singleton services, and the JTA Transaction Recovery Service can be configured to automatically migrate to another member server when a member server fails or is restarted.

71Server Migration ContdCluster leaderOne server instance in a cluster, elected by a majority of the servers, that is responsible for maintaining the leasing information.Cluster master One server instance in a cluster that contains migratable servers acts as the cluster master and orchestrates the process of automatic server migration, in the event of failure. Any Managed Server in a cluster can serve as the cluster master, whether it hosts pinned services or not.Singleton masterA lightweight singleton service that monitors other services that can be migrated automatically. The server that currently hosts the singleton master is responsible for starting and stopping the migration tasks associated with each migratable service.Candidate machinesa user-defined list of machines within a cluster that can be a potential target for migration.Target machinesa set of machines that are designated as allowable or preferred hosts for migratable servers.72Server Migration ContdLease tablea database table in which migratable servers persist their state, and which the cluster master monitors to verify the health and liveness of migratable servers.Administration Serverused to configure migratable servers and target machines, to obtain the run-time state of migratable servers, and to orchestrate the manual migration process.Floating IP addressan IP address that follows a server from one physical machine to another after migration.73Server Migration ContdLeasingLeasing is the process WebLogic Server uses to manage services that are required to run on only one member of a cluster at a time. Leasing ensures exclusive ownership of a cluster-wide entity. Within a cluster, there is a single owner of a lease. Additionally,leases can failover in case of server or cluster failure. This helps to avoid having a single point of failure. Features That Use LeasingAutomatic Whole Server MigrationUses leasing to elect a cluster master. The cluster master is responsible for monitoring other cluster members. It is also responsible for restarting failed members hosted on other physical machines. Leasing ensures that the cluster master is always running, but is only running on one server at a time within a cluster.74Server Migration ContdAutomatic Service MigrationJMS-related services, singleton services, and the JTA Transaction Recovery Service can be configured to automatically migrate from an unhealthy hosting server to a healthy active server with the help of the health monitoring subsystem. When the migratable target is migrated, the pinned service hosted by that target is also migrated. Migratable targets use leasing to accomplish automatic service migration.Singleton Services A singleton service is, by definition, a service running within a cluster that is available on only one member of the cluster at a time. Singleton services use leasing to accomplish this.75Server Migration ContdLeasing VersionsWebLogic Server provides two types of leasing functionality. Which one you use depends on your requirements and your environment.High-availability database leasingThis version of leasing requires a high-availability database to store leasing information. Non-database consensus leasingThis version of leasing stores the leasing information in-memory within a cluster member. This version of leasing requires that all servers in the cluster are started by Node Manager.

Within a WebLogic Server installation, you can use only one type of leasing. Although it is possible to implement multiple features that use leasing within your environment, each must use the same kind of leasing.When switching from one leasing type to another, you must restart the entire cluster, not just the Administration Server. Changing the leasing type cannot be done dynamically.

76Server Migration ContdLeasing VersionsWebLogic Server provides two types of leasing functionality. Which one you use depends on your requirements and your environment.High-availability database leasingThis version of leasing requires a high-availability database to store leasing information. Non-database consensus leasingThis version of leasing stores the leasing information in-memory within a cluster member. This version of leasing requires that all servers in the cluster are started by Node Manager.

Within a WebLogic Server installation, you can use only one type of leasing. Although it is possible to implement multiple features that use leasing within your environment, each must use the same kind of leasing.When switching from one leasing type to another, you must restart the entire cluster, not just the Administration Server. Changing the leasing type cannot be done dynamically.

77Server Migration ContdDetermining Which Type of Leasing To Use ?High-availability database leasingDatabase leasing basis is useful in environments that are already invested in a high-availability database, like Oracle RAC, for features like JMS store recovery. The high-availability database instance can also be configured to support leasing with minimal additional configuration. This is particularly useful if Node Manager is not running in the system.Non-database consensus leasingThis type of leasing provides a leasing basis option (consensus) that does not require the use of a high-availability database. This has a direct benefit in automatic whole server migration. Without the high-availability database requirement, consensus leasing requires less configuration to enable automatic server migration.Consensus leasing basis requires Node Manager to be configured and running. Automatic whole server migration also requires the Node Manager for IP migration and server restart on another machine. Hence, consensus leasing works well since it does not impose additional requirements, but instead takes away an expensive one.78Server Migration ContdHigh-availability Database LeasingIn this version of leasing, lease information is maintained within a table in a high-availability database.A high-availability database is required to ensure that the leasing information is always available to the servers.Each member of the cluster must be able to connect to the database in order to access leasing information, update and renew their leases.Servers will fail if the database becomes unavailable and they are not able to renew their leases.

79Server Migration ContdThe following procedures outline the steps required to configure your database for leasing.Configure the database for server migration. The database stores leasing information that is used to determine whether or not a server is running or needs to be migrated. Your database must be reliable. The server instances will only be as reliable as the database. Create the leasing table in the database. This is used to store the machine-server associations used to enable server migration. The schema for this table is located in WL_HOME/server/db/dbname/leasing.ddl, where dbname is the name of the database vendor. Set up and configure a data source. This data source should point to the database configured in the previous step.80Server Migration ContdNon-database Consensus LeasingIn Consensus leasing, there is no highly available database required. The cluster leadermaintains the leases in-memory. All the servers renew their leases by contacting the cluster leader, however, the leasing table is replicated to other nodes of the cluster to provide failover.The cluster leader is elected by all the running servers in the cluster. A server becomes a cluster leader only when it has received acceptance from the majority of the servers. If the Node Manager reports a server as shutdown, the cluster leader assumes that server to have accepted it as leader when counting the majority.Consensus leasing requires a majority of servers to continue functioning. Any time there is a network partition, the servers in the majority partition will continue to run while those in the minority partition will fail since they cannot contact the cluster leader or elect a new cluster leader since they will not have the majority of servers. If the partition results in an equal division of servers, then the partition that contains the cluster leader will survive while the other one will fail.If automatic server migration is enabled, the servers are required to contact the cluster leader and renew their leases periodically. Servers will shut themselves down if they are unable to renew their leases. The failed servers will then be automatically migrated to the machines in the majority partition.81Server Migration ContdServer Migration Processes and Communications Key processes in a cluster that contains migratable serversStartup Process in a Cluster with Migratable ServersAutomatic Whole Server Migration ProcessManual Whole Server Migration Process

Startup Process in a Cluster with Migratable ServersThe below example illustrates the processing and communications that occur during startup of a cluster that contains migratable servers.

The example cluster contains two Managed Servers, both of which are migratable. The Administration Server and the two Managed Servers each run on different machines. A fourth machine is available as a backupin the event that one of the migratable servers fails. Node Manager is running on the backup machine and on each machine with a running migratable server.

82Server Migration Contd

83Server Migration ContdThe administrator starts up the cluster.The Administration Server invokes Node Manager on Machines B and C to start Managed Servers 1 and 2, respectively.The Node Manager on each machine starts up the Managed Server that runs there.Managed Servers 1 and 2 contact the Administration Server for their configuration.Managed Servers 1 and 2 cache the configuration with which they started up. Managed Servers 1 and 2 each obtain a migratable server lease in the lease table. Because Managed Server 1 starts up first, it also obtains a cluster master lease.Managed Server 1 and 2 periodically renew their leases in the lease table, proving their health and liveness.84Server Migration ContdAutomatic Whole Server Migration Process

85Server Migration ContdMachine C, which hosts Managed Server 2, fails.Upon its next periodic review of the lease table, the cluster master detects that Managed Server 2's lease has expired.The cluster master tries to contact Node Manager on Machine C to restart Managed Server 2, but fails, because Machine C is unreachable. Note: If the Managed Server 2 lease had expired because it was hung, and Machine C was reachable, the cluster master would use Node Manager to restart Managed Server 2 on Machine C. The cluster master contacts Node Manager on Machine D, which is configured as an available host for migratable servers in the cluster. Node Manager on Machine D starts Managed Server 2.Managed Server 2 starts up and contacts the Administration Server to obtain its configuration.Managed Server 2 caches the configuration with which it started up.Managed Server 2 obtains a migratable server lease.86Server Migration ContdManual Whole Server Migration Process

87Server Migration ContdAn administrator uses the Administration Console to initiate the migration of Managed Server 2 from Machine C to Machine B.The Administration Server contacts Node Manager on Machine C.Node Manager on Machine C stops Managed Server 2.Managed Server 2 removes its row from the lease table.The Administration Server invokes Node Manager on Machine B.Node Manager on Machine B starts Managed Server 2.Managed Server 2 obtains its configuration from the Administration Server.Managed Server 2 caches the configuration with which it started up.Managed Server 2 adds a row to the lease table.

88JDBC89Java Message Service - JMSWhat Is Messaging? Messaging is a method of communication between software components or applications. A messaging system is a peer-to-peer facility: A messaging client can send messages to, and receive messages from, any other client. Each client connects to a messaging agent that provides facilities for creating, sending, receiving, and reading messages. Messaging enables distributed communication that is loosely coupled. A component sends a message to a destination, and the recipient can retrieve the message from the destination. However, the sender and the receiver do not have to be available at the same time in order to communicate. In fact, the sender does not need to know anything about the receiver; nor does the receiver need to know anything about the sender. The sender and the receiver need to know only what message format and what destination to use. In this respect, messaging differs from tightly coupled technologies, such as Remote Method Invocation (RMI), which require an application to know a remote application's methods. Messaging also differs from electronic mail (e-mail), which is a method of communication between people or between software applications and people. Messaging is used for communication between software applications or software components.Java Message Service JMS ContdWhat Is the Java Message Service ?An enterprise messaging system enables applications to asynchronously communicate with one another through the exchange of messages. A message is a request, report, and/or event that contains information needed to coordinate communication between different applications. A message provides a level of abstraction, allowing you to separate the details about the destination system from the application code.The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems that is implemented by industry messaging providers. Specifically, JMS:Enables Java applications that share a messaging system to exchange messagesSimplifies application development by providing a standard interface for creating, sending, and receiving messagesJava Message Service JMS ContdWhen Can You Use the JMS API?An enterprise application provider is likely to choose a messaging API over a tightly coupled API, such as Remote Procedure Call (RPC), under the following circumstances.The provider wants the components not to depend on information about other components' interfaces, so that components can be easily replaced.The provider wants the application to run whether or not all components are up and running simultaneously.The application business model allows a component to send information to another and to continue to operate without receiving an immediate response.Java Message Service JMS ContdFor example, components of an enterprise application for an automobile manufacturer can use the JMS API in situations like these.The inventory component can send a message to the factory component when the inventory level for a product goes below a certain level, so the factory can make more cars.The factory component can send a message to the parts components so that the factory can assemble the parts it needs.The parts components in turn can send messages to their own inventory and order components to update their inventories and to order new parts from suppliers.Both the factory and the parts components can send messages to the accounting component to update their budget numbers.The business can publish updated catalog items to its sales force.Java Message Service JMS Contd

Messaging in an Enterprise Application

Java Message Service JMS ContdJMS Architecture : Connecting

Java Message Service JMS ContdA JMS application is composed of the following parts. :-A JMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features.JMS clients are the programs or components, written in the Java programming language, that produce and consume messages. Messages are the objects that communicate information between JMS clients. Administered objects are preconfigured JMS objects created by an administrator for the use of clients. Native clients are programs that use a messaging product's native client API instead of the JMS API. An application first created before the JMS API became available and subsequently modified is likely to include both JMS and native clients.Java Message Service JMS ContdBelow figure illustrates the way these parts interactAdministrative tools allow you to bind destinations and connection factories into a Java Naming and Directory InterfaceTM (JNDI) API namespace.A JMS client can then look up the administered objects in the namespace and then establish a logical connection to the same objects through the JMS provider.

Java Message Service JMS ContdMessaging Domains Before the JMS API existed, most messaging products supported either the point-to-point or the publish/subscribe approach to messaging.Point-to-Point Messaging DomainThe queue or point-to-point model works by having a sender place messages to a queue, and the receiver will be able to read the messages from the queue.In queue, the sender knows where the message will be going. There is a specific sender and a specific receiver, and there is the intention of being acknowledged as such. In queue, you only have one receiver or consumer.In queue you do not have to worry about timing because the sender will have the luxury to send messages whenever he or she wants to. And the same goes for the receiver; he or she also has the liberty of reading it whenever he or she wants. In queue you will also be assured that as the sender you have successfully sent out your message because you will be notified by the receiver,Java Message Service JMS ContdPoint-to-Point Messaging Domain

Java Message Service JMS ContdPublisher or subscriber Model Publisher or subscriber model is also simply known as the topic model. Publisher or subscriber or the topic model works by disseminating messages by posting messages about a particular topic and having subscribers read them.In topic you only have a publisher and a subscriber or subscribers. In topic where in you can have your message be disseminated to a number of subscribers. Also, in topic, the publisher has to be continuously active for a subscriber to receive the messages. Otherwise the message will be reallocated.In topic there is no guarantee that the message will reach successfully to the user.Java Message Service JMS ContdPublisher or subscriber Model

Java Message Service JMS ContdWeblogic JMS Architecture and Environment

Java Message Service JMS ContdThe major components of the WebLogic JMS architecture include: A JMS server is an environment-related configuration entity that acts as management container for JMS queue and topic resources defined within JMS modules that are targeted to specific that JMS server. A JMS server's primary responsibility for its targeted destinations is to maintain information on what persistent store is used for any persistent messages that arrive on the destinations, and to maintain the states of durable subscribers created on the destinations. You can configure one or more JMS servers per domain, and a JMS server can manage one or more JMS modules.JMS modules contain configuration resources, such as standalone queue and topic destinations, distributed destinations, and connection factories, and are defined by XML documents that conform to the weblogic-jms.xsd schema.Java Message Service JMS ContdClient JMS applications that either produce messages to destinations or consume messages from destinations.JNDI (Java Naming and Directory Interface), which provides a server lookup facility. WebLogic persistent storage (a server instance's default store, a user-defined file store, or a user-defined JDBC-accessible store) for storing persistent message data.Java Message Service JMS ContdConfigurationConfiguration information can be further classified into environment-related information and application-related information.Environment-related information are the identification and definition of JMS servers, JDBC data sources, WebLogic persistent stores, and server network addresses. These system resources are usually unique from domain to domain.The configuration and management of these system resources are the responsibility of a administrator, who usually receives this information from an organization's system administrator or MIS department. To accomplish these tasks, an administrator can use the Administration Console, various command-line tools, such as Scripting Tool (WLST), or JMX APIs for programmatic administration.Java Message Service JMS ContdApplication-related definitions that are independent of the domain environment are the various Java EE application components configurations, such as EAR, WAR, JAR, RAR files, and JMS and JDBC modules.The application components are originally developed and packaged by an application development team, and may contain optional programs (compiled Java code) and respective configuration information (also called descriptors, which are mostly stored as XML files). In the case of JMS and JDBC modules, however, there are no compiled Java programs involved.These pre-packaged applications are given to Server administrators for deployment.Java Message Service JMS ContdResources in a JMS System ModuleConnection Factory:- Connection factories are resources that enable JMS clients to create JMS connections. A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously.Queue:- Defines a point-to-point destination type, which are used for asynchronous peer communications. A message delivered to a queue is distributed to only one consumer.Topic:- Defines a publish/subscribe destination type, which are used for asynchronous peer communications. A message delivered to a topic is distributed to all topic consumers.Distributed Queue:- Defines a set of queues that are distributed on multiple JMS servers, but which are accessible as a single, logical queue to JMS clients.Distributed queues can help with message load balancing and distribution, and have many of the same properties as standalone queues.

Java Message Service JMS ContdDistributed Topic:- Defines a set of topics that are distributed on multiple JMS servers, but which are accessible as a single, logical topic to JMS clients. Distributed topics can help with load balancing and distribution, and have many of the same properties as standalone topics.Foreign Server Configuration :A foreign server resource enables you to reference third-party JMS providers within a local WebLogic Server JNDI tree. With a foreign server resource, you can quickly map a foreign JMS provider so that its associated connection factories and destinations appear in the WebLogic JNDI tree as local JMS objects.Quota Configuration :- A quota resource defines a maximum number of messages and bytes, and is then associated with one or more destinations and is responsible for enforcing the defined maximums.

Java Message Service JMS ContdJMS Store-and-Forward (SAF) Configuration :- JMS SAF resources build on the WebLogic Store-and-Forward (SAF) service to provide highly-available JMS message production. For example, a JMS message producer connected to a local server instance can reliably forward messages to a remote JMS destination, even though that remote destination may be temporarily unavailable when the message was sent. JMS Store-and-forward is transparent to JMS applications; therefore, JMS client code still uses the existing JMS APIs to access remote destinations.Weblogic Server SecurityOracleSecurity Realms in WebLogic ServerThe security service in WebLogic Server simplifies the configuration and management of security while offering robust capabilities for securing your WebLogic Server deployment. Security realms act as a scoping mechanism. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. You can configure multiple security realms in a domain; however, only one can be the active security realm. WebLogic Server provides two default security realms:myrealmHas the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Role Mapping, and Credential Mapping providers configured by default.CompatibilityRealmProvides backward compatibility for 6.x security configurations. You can access an existing 6.x security configuration through the CompatibilityRealm.Security ProvidersSecurity providers are modular components that handle specific aspects of security, such as authentication and authorization. Although applications can leverage the services offered by the default WebLogic security providers, the WebLogic Security Service's flexible infrastructure also allows security vendors to write their own custom security providers for use with WebLogic Server.The WebLogic Administration Console allows you to administer and manage all your security providers through one unified management interface.The WebLogic Security Service supports the following types of security providers:Security Providers contd..AuthenticationAuthentication is the process whereby the identity of users or system processes are proved or verified. Authentication also involves remembering, ransporting, and making identity information available to various components of a system when that information is needed. Authentication providers supported by the WebLogic Security Service supply the following types of authentication:Username and password authenticationCertificate-based authentication directly with WebLogic ServerHTTP certificate-based authentication proxied through an external Web server

Security Providers contd..AuthorizationAuthorization is the process whereby the interactions between users and WebLogic resources are limited to ensure integrity, confidentiality, and availability. In other words, once a user's identity has been established by an authentication provider, authorization is responsible for determining whether access to WebLogic resources should be permitted for that user. An Authorization provider supplies these services.

LDAP Authentication Providers - stores user and group information in an external LDAP server. WebLogic Server provides LDAP Authentication providers that access Oracle Internet Directory, Oracle Virtual Directory, Open LDAP, Netscape iPlanet, Microsoft Active Directory and Novell NDS stores

Resources that can be securedA WebLogic resource represents an underlying WebLogic Server entity that can be protected from unauthorized access using security policies. Examples of WebLogic resources include Administrative resources, Server resources, Enterprise Applications (EARs), EJBs (JARs), and Web Applications (WARs).The main steps for securing a WebLogic resource are:Determine which WebLogic resource to secure.If you want to secure an EJB or Web application resource:Understand the options you have for securing these resources.Decide which technique you want to use. You can use Deployment Descriptors only, the Administration Console only, or a combination of the two.Decide which security deployment model to use. This depends on the security technique you choose.Resources that can be secured contd..

116Resources that can be secured contd..Use the WebLogic Administration Console to secure your WebLogic resource:Create users and groups, representations of individuals and collections of individuals, who may be granted a security role.Create security roles, which are dynamically computed privileges granted to users or groups based (optionally) on specific conditions. You can create global roles, which apply to all resources, or scoped roles which apply to selected resources. BEA recommends creating security roles and using them (rather than users or groups) to secure WebLogic resources, because doing so increases efficiency for administrators who work with many users.Create security policies, which are associations between the WebLogic server and a user, group, or security role, that specify who has access to the WebLogic Resource and under what conditions.117Weblogic security diagram

Security RelamBefore You Create a New Security Realm Before creating a new security realm, you need to decide:Which security providers you want to use. WebLogic Server includes a wide variety of security providers and, in addition, allows you to create or obtain custom security providers. A valid security realm requires an Authentication provider, an Authorization provider, an Adjudication provider, a Credential Mapping provider, a Role Mapping provider, and a CertPathBuilder. In addition, a security realm can optionally include Identity Assertion, Auditing, and Certificate Registry providers.What model to use to set security roles and security policies for Web application and EJB resources. These security roles and policies can be set through deployment descriptors or through the WebLogic Administration Console.

Security Relam contd..Creating and Configuring a New Security Realm

Define a name and set the configuration options for the security realm.Configure the required security providers for the security realm. A valid security realm requires an Authentication provider, an Authorization provider, an Adjudication provider, a Credential Mapping provider, a Role Mapping provider, and a CertPathBuilder. Optionally, define Identity Assertion, Auditing, and Certificate Registry providers.If you configured the Default Authentication, Authorization, Credential Mapping or Role Mapping provider or the Certificate Registry in the new security realm, verify that the settings of the embedded LDAP server are appropriate.Security Relam contd..Optionally, configure caches to improve the performance of the WebLogic or LDAP Authentication providers in the security realm.Protect WebLogic resources in the new security realm with security policies.If the security data (users and groups, roles and policies, and credential maps) defined in the existing security realm will also be valid in the new security realm, you can export the security data from the existing realm and import it into the new security realm.Protect user accounts in the new security realm from dictionary attacks by setting lockout attributes.Diagnostics FrameworkWLDF ArchitectureThe WebLogic Diagnostics Framework (WLDF) consists of a number of components that work together to collect, archive, and access diagnostic information about a WebLogic Server instance and the applications it hosts. This section provides an architectural overview of those components.Overview of the WebLogic Diagnostics FrameworkWLDF consists of the following:Data creators (data publishers and data providers that are distributed across WLDF components)Data collectors (the Logger and the Harvester components)Archive componentAccessor componentInstrumentation componentWatch and Notification componentImage Capture componentMonitoring DashboardOverview of the WebLogic Diagnostics Framework ContdData creators generate diagnostic data that is consumed by the Logger and the Harvester. Those components coordinate with the Archive to persist the data, and they coordinate with the Watch and Notification subsystem to provide automated monitoring. The Accessor interacts with the Logger and the Harvester to expose current diagnostic data and with the Archive to present historical data.Overview of the WebLogic Diagnostics Framework ContdMajor WLDF Component

Relationship of Data Creation Components to Data Collection ComponentsInvocations of the server logging infrastructure serve as inline data publishers, and the generated data is collected as events. (The logging infrastructure can be invoked through the catalog infrastructure, the debugging model, or directly through the Logger.)

Relationship of Data Creation Components to Data Collection Components ContdThe Instrumentation system creates monitors and inserts them at well-defined points in the flow of execution. These monitors publish data directly to the Archive.Components registered with the MBean Server may also make themselves known as data providers by registering with the Harvester. Collected data is then exposed to both the Watch and Notification system for automated monitoring and to the Archive for persistence.

ArchiveThe past state is often critical in diagnosing faults in a system. This requires that the state be captured and archived for future access, creating a historical archive. In WLDF, the Archive meets this need with several persistence components. Both events and harvested metrics can be persisted and made available for historical review.Relationship of the Archive to the Logger and the Harvester

Watch and NotificationThe Watch and Notification system can be used to create automated monitors that observe specific diagnostic states and send notifications based on configured rules.A watch rule can monitor log data, event data from the Instrumentation component, or metric data from a data provider that is harvested by the Harvester. The Watch Manager is capable of managing watches that are composed of a number of watch rules.

Data AccessorThe Accessor provides access to all the data collected by WLDF, including log, event, and metric data. The Accessor interacts with the Archive to get historical data including logged event data and persisted metrics.

Monitoring Dashboard and Request Performance PagesMonitoring DashboardThe Monitoring Dashboard displays the current and historical operating state of WebLogic Server and hosted applications by providing visualizations of metricruntime MBean attributes, which surface some of the more critical run-time performance metrics and the change in those metrics over time.Diagnostics Request Performance PageThe Diagnostics Request Performance page of the WebLogic Server Administration Console shows real-time and historical views of method performance information that is captured through the WLDF instrumentation capabilities.To view request performance information, you must first configure WLDF instrumentation to make that data available.

Diagnostic Image CaptureDiagnostic Image Capture support gathers the most common sources of the key server state used in diagnosing problemsImage Capture support includes:On-demand capture, which is the creation of a diagnostic image capture by means of an operation or command issued from the WebLogic Server Administration Console, WLST script, or JMX application.Image notification, which is automatically creating a diagnostic image capture in response to the triggering of an associated Harvester watch, Log watch, or Instrumentation watch rule. For example, a Harvester watch that monitors runtime MBean attributes in a running server can trigger an image notification if the metrics harvested from specific runtime MBean instances indicate a performance issue. Data in the diagnostic image capture can be analyzed to determine the likely causes of the issue.Diagnostic Image Capture Contd..Diagnostic Image Capture

Overall View of the WebLogic Diagnostics FrameworkBelow figure shows how all the parts of WLDF fit together