LearnWebLogicOnline.com's Learn Oracle Weblogic 12c for Administrators
•Download as PPTX, PDF•
5 likes•1,750 views
Learn the essentials behind deploying and administering Oracle Weblogic through the eyes of an Oracle WebLogic certified expert and consultant with over 15 years experience. Check out our online video training course with hands-on tutorials at www.LearnWebLogicOnline.com This slide presentation on Oracle Weblogic 12c for Administrators introduces the audience to Oracle WebLogic 12c. This course is designed to simplify understanding the leading enterprise application server on the market today. If you have been hesitant to check out WebLogic or if you want to learn more about WebLogic features and best practices, then this course is for you. It will teach you how to manage an Oracle WebLogic 12c environment by introducing you to a variety of topics from domain configuration to runtime management to security through easy-to-understand lectures and hands-on lab work. There are over 14 lectures and labs spanning over 10 hours of digital content! Topics Domain creation and management Admin, Managed Servers WebLogic resources (JMS, JDBC, Clusters) Security (Domain, Application) Application deployment Node Manager High availability and load balancing Basic troubleshooting WebLogic Scripting Tool (WLST)
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (11)
Recently uploaded
Recently uploaded (20)
LearnWebLogicOnline.com's Learn Oracle Weblogic 12c for Administrators
- 1. Oracle WebLogic for Administrators The Full Course Instructor: Chris Parent Copyright 2015 LearnWebLogicOnline.com
- 2. Course Overview Copyright 2015 LearnWebLogicOnline.com
- 3. Who Should Take this Course? Administrators Developers too Copyright 2015 LearnWebLogicOnline.com
- 4. Prerequisites View my free Udemy course: Beginning Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 5. What You Need for this Course Capable computer Java Development Kit WebLogic 12c installer Copyright 2015 LearnWebLogicOnline.com
- 6. Installing WebLogic Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 7. Installation Methods Interactive using Oracle Universal Installer Silent using Response files Copyright 2015 LearnWebLogicOnline.com
- 8. Lab Exercise Refer to course material for Lab Exercise #1: Installing WebLogic Copyright 2015 LearnWebLogicOnline.com
- 9. Creating a Domain Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 10. Tools for Creating Domains Configuration Wizard Domain Template Builder WebLogic Scripting Tool (WLST) Copyright 2015 LearnWebLogicOnline.com
- 11. Domain Structure config/ servers/ bin/ security/ Copyright 2015 LearnWebLogicOnline.com config.xml jdbc/ jms/ nodemanager/ startup/ security/Security data Applications Log files Start and stop scripts Admin, managed, Node Manager Migration Hash file Demo certificates LDAP initialization
- 12. Lab Exercise Refer to course material for Lab Exercise #2: Creating a WebLogic Domain Copyright 2015 LearnWebLogicOnline.com
- 13. Admin Server Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 14. What is the Admin Server? Copyright 2015 LearnWebLogicOnline.com
- 15. Tools and APIs Interfaces: Admin Console Fusion Middleware Control Enterprise Manger Cloud Control WebLogic Scripting Tool (WLST) Ant tasks Copyright 2015 LearnWebLogicOnline.com APIs: JMX Java EE Management API Deployment API Logging API
- 16. Starting up the Admin Server $DOMAIN_HOME/bin/startWebLogic.sh (.bat) Copyright 2015 LearnWebLogicOnline.com
- 17. Admin Console Overview Configure and manage server lifecycle Configure Clusters Configure WebLogic services Configure security Deploy applications Monitor server and app performance View logs Manage deployment descriptors Configure Coherence Clusters Copyright 2015 LearnWebLogicOnline.com
- 18. Lab Exercise Refer to course material for Lab Exercise #3: Admin Console Copyright 2015 LearnWebLogicOnline.com
- 19. Managed Servers Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 20. What is a Managed Server? Copyright 2015 LearnWebLogicOnline.com
- 21. Configure a Managed Server Logical name Listen address Listen port Copyright 2015 LearnWebLogicOnline.com
- 22. Lab Exercise Refer to course material for Lab Exercise #4: Creating a Managed Server Copyright 2015 LearnWebLogicOnline.com
- 23. Data Sources Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 24. Data Sources Generic GridLink Multi data sources Java EE Copyright 2015 LearnWebLogicOnline.com
- 25. Generic Data Sources Copyright 2015 LearnWebLogicOnline.com Generic Data Source Database
- 26. GridLink Data Source Copyright 2015 LearnWebLogicOnline.com RAC Node A RAC Node BSCAN GridLink Data Source Fast connection failover (FCF) Runtime Connection Load Balancing GridLink Affinity Secure communication SCAN
- 27. Multi Data Source Copyright 2015 LearnWebLogicOnline.com Database Node A Database Node B Generic Generic Generic Multi Data Source Data sync
- 28. Configuring Data Sources Console or WLST Created as JDBC system module DOMAIN_HOME/config/jdbc/*.xml Copyright 2015 LearnWebLogicOnline.com
- 29. Supported Databases Oracle Thin Driver (XA, Non-XA) MySQL (non-XA) Third-party JDBC drivers DataDirect drivers for DB2, Informix, MSSQL, and Sybase Copyright 2015 LearnWebLogicOnline.com
- 30. Transactions Options XA – 2PC – global transactions Non-XA – local transactions Global Transactions (default) Transaction Protocols: Logging Last Resource Emulate Two-Phase Commit One-Phase Commit (Default) Copyright 2015 LearnWebLogicOnline.com
- 31. Lab Exercise Refer to course material for Lab Exercise #5: Creating a Generic Data Source Copyright 2015 LearnWebLogicOnline.com
- 32. Java Message Service Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 33. What is JMS? Java EE Standard Enables async communication between applications Messages can be binary, text, XML Copyright 2015 LearnWebLogicOnline.com
- 34. Point to Point Messaging Copyright 2015 LearnWebLogicOnline.com Producer Queue Consumer Consumer Consumer Consumer
- 35. Publish / Subscribe Messaging Copyright 2015 LearnWebLogicOnline.com Producer Topic Consumer Consumer Consumer Consumer
- 36. WebLogic JMS Architecture JMS server JMS connection host and factories JMS destinations JMS modules JNDI Persistent Storage Copyright 2015 LearnWebLogicOnline.com
- 37. WebLogic JMS Architecture Copyright 2015 LearnWebLogicOnline.com Destination Connection Factory JMS Server Persistent Storage JNDI
- 38. JMS Configuration config.xml JMS Server Module descriptor files JMS Configuration Resources (Destinations, Conn Factories) Copyright 2015 LearnWebLogicOnline.com
- 39. JMS Modules Application-related definitions for JMS resources System modules configjms subdirectory Owned by administrator Application modules Owned by developers Copyright 2015 LearnWebLogicOnline.com
- 40. JMS Resources in Modules Queue and topic destinations Connection factories Templates Quotas Distributed destinations Foreign servers Copyright 2015 LearnWebLogicOnline.com
- 41. Configuring WebLogic JMS 1. Persistent storage 2. JMS server 3. JMS system module 4. JMS destination Copyright 2015 LearnWebLogicOnline.com
- 42. Naming Requirements All resources must have a unique name Includes servers, machines, clusters, virtual hosts, all system resources Any name must be different than domain name Copyright 2015 LearnWebLogicOnline.com
- 43. Configuring JMS Server Done through Admin Console or WLST Define configuration parameters: persistent storage, paging defaults, templates Messaging logging Target: WebLogic server or Migratable target Copyright 2015 LearnWebLogicOnline.com
- 44. Configuring JMS System Module Done through Admin Console or WLST Target: WebLogic server instance or cluster Copyright 2015 LearnWebLogicOnline.com
- 45. Lab Exercise Refer to course material for Lab Exercise #6: JMS Resources Copyright 2015 LearnWebLogicOnline.com
- 46. Application Deployment Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 47. What can be Deployed? Enterprise application Web application EJB Resource Adapter Web service Java EE Library JDBC, JMS, WLDF modules Copyright 2015 LearnWebLogicOnline.com
- 48. What is Deployment? Package application or module Copy to server(s) or cluster Managing lifecycle Copyright 2015 LearnWebLogicOnline.com
- 49. Packaging Apps for Deployment Archive files Exploded archive directories Copyright 2015 LearnWebLogicOnline.com
- 50. Deployment Tools weblogic.Deployer Admin Console WLST Copyright 2015 LearnWebLogicOnline.com
- 51. weblogic.Deployer Command-line interface Copyright 2015 LearnWebLogicOnline.com java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic -password weblogic -deploy c:localfilesmyapp.ear
- 52. Admin Console Wizard-driven Manage and monitor deployment status Copyright 2015 LearnWebLogicOnline.com
- 53. WLST WLST syntax Copyright 2015 LearnWebLogicOnline.com deploy("examplesWebApp","C:/Oracle/Middleware/wlserver/samples/server/ examples/build/examplesWebApp")
- 54. Deployment Modes Copyright 2015 LearnWebLogicOnline.com stage Files copied to target servers Used for small to medium sized applications nostage Files not copied to target servers Requires same physical copy Used for larger applications external_stage Files not copied Managed by external process
- 55. Lab Exercise Refer to course material for Lab Exercise #7: Application Deployment Copyright 2015 LearnWebLogicOnline.com
- 56. Production Deployment Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 57. What is Production Deployment? Deployment follows well-defined process (DCLC) Integrated with SDLC and release management Supported with Deployment Plans, Names and Version Strings Copyright 2015 LearnWebLogicOnline.com
- 58. Deployment Life Cycle Development config Export config Deployment- time config Post- deployment config Copyright 2015 LearnWebLogicOnline.com
- 59. Deployment Names Deployment Names Default name is archive file without extension myApp.ear = myApp Can be specified at deployment time Deployment descriptor <application-name> <module-name> Copyright 2015 LearnWebLogicOnline.com
- 60. Deployment Versions Identify initial and subsequent deployments Allows zero-down upgrades Specified in MANFIEST.MF Copyright 2015 LearnWebLogicOnline.com Manifest-Version: 1.0 Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.) Weblogic-Application-Version: v920.beta
- 61. Deployment Plans Environment-specific configuration Overrides or substitutes DD property values Optional XML document Created by developers Copyright 2015 LearnWebLogicOnline.com
- 62. Workflow Example Copyright 2015 LearnWebLogicOnline.com myApp.ear reference-descriptor: devDataSource context-root: rev001a plan.xml Development myApp.ear reference-descriptor: QADataSource context-root: rev001a plan.xml Testing myApp.ear reference-descriptor: ProdDataSource context-root: registration plan.xml Staging
- 63. Application Installation Directory Separates config files from application files Manage with source control Oracle Best Practice Copyright 2015 LearnWebLogicOnline.com Install-root /app /planX Additional generated descriptors Deployment files (Archive/Exploded Archive) plan.xml
- 64. Auto-Deploying Applications Automatically deploy and update applications under /autodeploy Only supported in DEVELOPMENT mode Limited: Only deployed to Admin Server No entry in config.xml Security policies not supported Copyright 2015 LearnWebLogicOnline.com
- 65. Production Redeployment Zero down-time upgrade New version alongside old version Client connections managed by WebLogic Eliminates need for redundant servers Supports administration mode Copyright 2015 LearnWebLogicOnline.com
- 66. In-place Redeployment Old version immediately replaced with new version Zero-Interruption not guaranteed Default redeployment method Required for apps that do not specify version Copyright 2015 LearnWebLogicOnline.com
- 67. Lab Exercise Refer to course material for Lab Exercise #9: Production Deployment Copyright 2015 LearnWebLogicOnline.com
- 68. Managing Applications Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 69. Managing Applications Admin Console WLST JMX Copyright 2015 LearnWebLogicOnline.com
- 70. Going Offline Restrict client access Place application into ADMIN MODE Undeploy application Copyright 2015 LearnWebLogicOnline.com
- 71. Deployment Order Default Order 1. JDBC system modules 2. JMS system modules 3. Java EE libraries and packages 4. Application and standalone modules 5. Startup classes Copyright 2015 LearnWebLogicOnline.com
- 72. Changing Deployment Order Applications and modules Admin Console or Programmatically AppDeploymentMBean DeploymentOrder attribute Default Order value of 100 Deployed alphabetically with same Order Value Copyright 2015 LearnWebLogicOnline.com
- 73. Lab Exercise Refer to course material for Lab Exercise #8: Managing Applications Copyright 2015 LearnWebLogicOnline.com
- 74. WebLogic Clusters Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 75. What is a Cluster Copyright 2015 LearnWebLogicOnline.com JDBC, JNDI, JMS WS, EJBs, Apps
- 76. Benefits and Capabilities Scalability High Availability Application Failover Server Migration Load Balancing Copyright 2015 LearnWebLogicOnline.com
- 77. What can be Clustered Servlets JSPs EJBs RMI objects JMS resources JDBC connections Coherence clusters and servers Timer services Copyright 2015 LearnWebLogicOnline.com
- 78. Cluster Communications IP Multicast uses UDP broadcast IP Unicast uses TCP/IP sockets Copyright 2015 LearnWebLogicOnline.com
- 79. Basic Cluster Architecture Copyright 2015 LearnWebLogicOnline.com Database Load Balancer Combined-Tier Architecture
- 80. Load Balancing Servlets and JSPs EJBs and RMI objects JMS Copyright 2015 LearnWebLogicOnline.com
- 81. Load Balancing HTTP Requests Proxy Plug-ins Netscape Apache Oracle HTTP Server Microsoft IIS WebLogic Server with HttpClusterServlet Round-robin Supports HTTP session persistence Copyright 2015 LearnWebLogicOnline.com
- 82. Load Balancing: External LB Hardware LB supported Must support: Passive cookie persistence Active cookie persistence SSL persistence Copyright 2015 LearnWebLogicOnline.com
- 83. Load Balancing EJBs and RMI Round Robin Weight-based Random Server Affinity Copyright 2015 LearnWebLogicOnline.com
- 84. Load Balancing JMS Server affinity with distributed destinations Target multiple JMS servers to migratable target Target Connection Factory to multiple targets Copyright 2015 LearnWebLogicOnline.com
- 85. Detecting Failures in a Cluster #1 Socket connections to a peer server Copyright 2015 LearnWebLogicOnline.com X
- 86. Detecting Failures in a Cluster #2 Heart beat messages Broadcast every 10 seconds 3 missed heartbeats = failed server Copyright 2015 LearnWebLogicOnline.com Heartbeat 1 Heartbeat 2 Missed 1 Missed 2 Missed 3
- 87. Failover for Servlets and JSPs Hardware load balancers Proxy plug-ins Copyright 2015 LearnWebLogicOnline.com
- 88. HTTP Session State Replication In-memory JDBC-based Coherence*Web Copyright 2015 LearnWebLogicOnline.com
- 89. Whole Server Migration Copyright 2015 LearnWebLogicOnline.com Machine A Machine B
- 90. Service-Level Migration Copyright 2015 LearnWebLogicOnline.com Machine A Machine B Managed Server 2 Managed Server 1
- 91. Lab Exercise Refer to course material for Lab Exercise #10: Clusters Copyright 2015 LearnWebLogicOnline.com
- 92. Managing Server Lifecycle Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 93. What is Node Manager WebLogic utility Remotely control WebLogic servers Optional but very convenient Copyright 2015 LearnWebLogicOnline.com
- 94. Node Manager Features Start, shutdown and restart Admin Server Start, shutdown, suspend, and restart Managed Servers Restart failed servers Copyright 2015 LearnWebLogicOnline.com
- 95. Implementations Java-based Node Manager Script-based Node Manager Copyright 2015 LearnWebLogicOnline.com
- 96. Copyright 2015 LearnWebLogicOnline.com Node Manager Admin Server Machine A Node Manager Managed Server 1 Machine B Node Manager Managed Server 2 Machine C WLST JMX Admin Console
- 97. Copyright 2015 LearnWebLogicOnline.com Admin Server Machine A Node Manager Managed Server 1 Machine B Admin Console Starting a Managed Server 1. Issue command to start MS1 2. AS invokes NM 4. MS1 fetches config 3. NM starts MS1 5. MS1 stores config
- 98. Configuring Node Manager nodemanager.properties – general config nodemanager.domains nm_password.properties boot.properties Copyright 2015 LearnWebLogicOnline.com
- 99. Lab Exercise Refer to course material for Lab Exercise #12: Node Manager Copyright 2015 LearnWebLogicOnline.com
- 100. Scaling out WebLogic Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 101. The Real World Copyright 2015 LearnWebLogicOnline.com
- 102. The Real World Copyright 2015 LearnWebLogicOnline.com Machine A Machine B Machine C Domain
- 103. Tools for Deployment Managed server templates Pack / Unpack commands Copyright 2015 LearnWebLogicOnline.com
- 104. The Process 1. Create WebLogic machines 2. Create and assign managed servers 3. Install WebLogic on all machines 4. Create managed server template using pack command 5. Unpack template on each machine Copyright 2015 LearnWebLogicOnline.com
- 105. Lab Exercise Refer to course material for Lab Exercise #12: Distributed Deployment Copyright 2015 LearnWebLogicOnline.com
- 106. WebLogic Security Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 107. Secure the Host – User Accounts Use OS permissions to protect data stored on disk security LDAP, persistent stores, keystores Limit number of user accounts Create an OS group to only contain: Installation user Domain creation and Node Manager user Restrict access to Oracle home, WebLogic home, Domain home Copyright 2015 LearnWebLogicOnline.com
- 108. Secure Installation Do not install the sample applications and code Remove Derby Database after installation Apply latest CPU from Oracle Copyright 2015 LearnWebLogicOnline.com
- 109. Creating a Secure Domain Production mode Omit credentials when issuing WLST commands Copyright 2015 LearnWebLogicOnline.com
- 110. Securing a Domain Configure password validation rules Configure user lockout Configure node manager security Enable auditing Disable remote Mbean access Set message timeout Use SSL Copyright 2015 LearnWebLogicOnline.com
- 111. Domain-wide Admin Port Separates admin traffic from application traffic Requires SSL Reduces risk for transmitting server config information in plain text Provides a dedicated port and listening thread Helpful during a DoS attack Copyright 2015 LearnWebLogicOnline.com
- 112. SSL in WebLogic Copyright 2015 LearnWebLogicOnline.com Browser WS Client Proxy Admin Server Node Manager Managed Server Default Providers App Code LDAP Server 1-way 1-way 1-way 1-way 1 or 2-way 1 or 2-way 1 or 2-way 1 or 2-way 1 or 2-way
- 113. Security Realms Security Providers Users, groups, security roles Policies Copyright 2015 LearnWebLogicOnline.com
- 114. Users Entities authenticated against security realm Person, client application, WLS instance User is assigned an identity Associated with groups or roles Copyright 2015 LearnWebLogicOnline.com
- 115. Groups Logically ordered sets of users By function or department Easier to manage groups than users Copyright 2015 LearnWebLogicOnline.com
- 116. Security Roles Privilege granted to users or groups Dynamic Can be scoped to an application unlike groups Copyright 2015 LearnWebLogicOnline.com
- 117. Security Policies Protects resources Association between resource and user/group/role Policy conditions define when/how policy is enforced Copyright 2015 LearnWebLogicOnline.com
- 118. Security Providers Provide security services to protect resources Default, third-party, custom developed Copyright 2015 LearnWebLogicOnline.com
- 119. Security Providers Copyright 2015 LearnWebLogicOnline.com Authentication Identity Assertion Principal Validation Authorization Adjudication Role Mapping Credential Mapping Certificate Lookup and Validation Auditing
- 120. Security Provider Database Copyright 2015 LearnWebLogicOnline.com Security Provider Databases Default groups, roles, policies Defined users, group, roles Security Providers Defined scoped roles and policies WebLogic Resources Default global roles and security policies Defined global roles
- 121. Security Provider Database Embedded LDAP Server Production Quality Supports 10,000 or fewer users RDBMS Security Store Copyright 2015 LearnWebLogicOnline.com
- 122. Authentication Provider Default WebLogic Authentication Provider Embedded LDAP Stores users, groups, roles, policies Copyright 2015 LearnWebLogicOnline.com
- 123. Lab Exercise Refer to course material for Lab Exercise #9: Security Realm Copyright 2015 LearnWebLogicOnline.com
- 124. Intro to WLST Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 125. What is WebLogic Scripting Tool? Command-line scripting environment Create, manage, and monitor domains Based on Jython Set of WL-specific scripting functions Copyright 2015 LearnWebLogicOnline.com
- 126. Online and Offline Modes Online Connect to running Admin Server Manage security data, configuration of active domain Offline Create and extend domains Copyright 2015 LearnWebLogicOnline.com
- 127. Command Types Browse Control Customization Deployment Diagnostics Editing Information Life Cycle Node Manager Tree Persistent Store Copyright 2015 LearnWebLogicOnline.com
- 128. Mbeans Managed Java object Follows JMX design specification Represents an application or WebLogic resource Exposes: attributes and operations Copyright 2015 LearnWebLogicOnline.com
- 129. Mbean Hierarchy Organized like a file system with a root directory Mbean hierarchy = disk drive Mbean types and instances = directories Mbean attributes and operations = files Copyright 2015 LearnWebLogicOnline.com
- 130. Different Hierarchies Configuration (Domain and Server) Runtime (Domain and Server) Copyright 2015 LearnWebLogicOnline.com
- 131. Navigating MBeans Connect to domain (offline or online) Use cd(), ls(), pwd() commands Copyright 2015 LearnWebLogicOnline.com
- 132. Locating MBeans Use find() to search based on name or type Returns list of Mbean paths Use getpath() to return Mbean object Copyright 2015 LearnWebLogicOnline.com
- 133. Editing Mbeans Online Copyright 2015 LearnWebLogicOnline.com edit startEdit Make changes save activate stopEdit
- 134. Interactive WLST Invoke interpreter using wlst.sh Copyright 2015 LearnWebLogicOnline.com cd ORACLE_HOME/oracle_common/common/bin ./wlst.sh
- 135. Connect to running Domain Start interactive WLST Use connect() connect([username, password], [adminServerName], [url], [timeout]) Copyright 2015 LearnWebLogicOnline.com wls:/offline> connect('adminusername','adminpassword','t3://localhost:7001')
- 136. WLST Example Copyright 2015 LearnWebLogicOnline.com [1] connect("username","password") [2] edit() [3] startEdit() [4] svr = cmo.createServer("managedServer") [5] svr.setListenPort(8001) [6] svr.setListenAddress("address") [7] save() [8] activate(block="true")
- 137. Lab Exercise Refer to course material for Lab Exercise #13: WLST Copyright 2015 LearnWebLogicOnline.com
- 138. Course Conclusion Course: Oracle WebLogic for Administrators Copyright 2015 LearnWebLogicOnline.com
- 139. What We’ve Learned Install WebLogic Create a domain Admin Console Create WebLogic resources (JDBC, JMS) Security Deploying and managing applications Clusters Node Manager WLST Copyright 2015 LearnWebLogicOnline.com
- 140. What’s Next – Future Lectures Dedicated courses on focused topics Advanced security, JMS, JDBC, Clusters, Performance Tuning Other Fusion Middleware products (SOA 12c, BPM, IDM) Developer Tools Sandbox and SDLC support Copyright 2015 LearnWebLogicOnline.com
Editor's Notes
- The Administration Server operates as the central control entity for the configuration of the entire domain. It maintains the domain's configuration documents and distributes changes in the configuration documents to Managed Servers. You can also use the Administration Server as a central location from which to monitor all resources in a domain. Each Oracle WebLogic Server domain must have one server instance that acts as the Administration Server.
- Walk through the admin console Log in Go over change center Domain structure “How do I” box will include links to online help tasks based on where you are in the admin console Tool bar Bread crumb navigation System status
- Managed Servers host business applications, application components, Web services, and their associated resources. To optimize performance, Managed Servers maintain a read-only copy of the domain's configuration document. When a Managed Server starts up, it connects to the domain's Administration Server to synchronize its configuration document with the document that the Administration Server maintains. For production environments that require increased application performance, throughput, or high availability, you can configure two or more Managed Servers to operate as a cluster. A cluster is a collection of multiple Oracle WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability. In a cluster, most resources and services are deployed identically to each Managed Server (as opposed to a single Managed Server), enabling failover and load balancing. A single domain can contain multiple Oracle WebLogic Server clusters, as well as multiple Managed Servers that are not configured as clusters. The key difference between clustered and non-clustered Managed Servers is support for failover and load balancing. These features are available only in a cluster of Managed Servers. For more information about the benefits and capabilities of an Oracle WebLogic Server cluster, see "Understanding WebLogic Server Clustering" in Administering Clusters for Oracle WebLogic Server.
- Machine definitions that identify a particular, physical piece of hardware. A machine definition is used to associate a computer with the Managed Servers it hosts. This information is used by Node Manager in restarting a failed Managed Server, and by a clustered Managed Server in selecting the best location for storing replicated session data. For more information about Node Manager, see "Node Manager Overview" in the Administering Node Manager for Oracle WebLogic Server. Network channels that define default ports, protocols, and protocol settings that a Managed Server uses to communicate with clients. After creating a network channel, you can assign it to any number of Managed Servers and clusters in the domain. For more information, see "Configuring Network Resources" in Administering Server Environments for Oracle WebLogic Server. Virtual hosting, which defines a set of host names to which Oracle WebLogic Server instances (servers) or clusters respond. When you use virtual hosting, you use DNS to specify one or more host names that map to the IP address of a server or cluster. You also specify which Web applications are served by each virtual host.
- Security providers, which are modular components that handle specific aspects of security, such as authentication and authorization. Resource adapters, which are system libraries specific to Enterprise Information Systems (EIS) and provide connectivity to an EIS. Diagnostics and monitoring services. JDBC data sources, which enable applications to connect to databases. Mail sessions. XML entity caches and registry of XML parsers and transformer factories. Messaging services such as JMS servers and store-and-forward services. Persistent store, which is a physical repository for storing data, such as persistent JMS messages. It can be either a JDBC-accessible database or a disk-based file. Startup classes, which are Java programs that you create to provide custom, system-wide services for your applications. Work Managers, which determine how an application prioritizes the execution of its work based on rules you define and by monitoring actual run-time performance. You can create Work Mangers for entire Oracle WebLogic Server domains or for specific application components. Work Contexts, which enable applications to pass properties to a remote context without including the properties in a remote call.
- Generic Data Sources—Generic data sources and their connection pools provide connection management processes that help keep your system running efficiently.You can set options in the data source to suit your applications and your environment. GridLink Data Sources—An event-based data source that adaptively responds to state changes in an Oracle RAC instance. Multi data sources—An abstraction around a group of generic data sources that provides load balancing or failover processing.
- Generic data sources provide database access and database connection management. Each data source contains a pool of database connections that are created when the data source is created and at server startup. Applications reserve a database connection from the data source by looking up the data source on the JNDI tree or in the local application context and then calling getConnection(). When finished with the connection, the application should call connection.close() as early as possible, which returns the database connection to the pool for other applications to use.
- A single GridLink data source provides connectivity between WebLogic Server and an Oracle Database service, which may include multiple Oracle RAC clusters. It uses the Oracle Notification Service (ONS) to adaptively respond to state changes in an Oracle RAC instance. An Oracle Database service represents a workload with common attributes that enables administrators to manage the workload as a single entity. You scale the number of GridLink data sources as the number of services increases in the data base, independent of the number of nodes in the cluster. A GridLink data source includes the features of generic data sources plus the following support for Oracle RAC:
- XA – WLS automatically selects 2 phase commit for global transcation processing Non XA – local trans are supported. WLS can support global transacations with non-XA drivers by default
- This lab will walk through setting up Derby database and creating a data source for it
- https://docs.oracle.com/middleware/1213/wls/INTRO/jms.htm#INTRO228 JMS server a managed message container for a set of JMS queues and topics. A JMS server's primary responsibility for its 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. JMS servers also manage message paging on destinations, and, optionally, can manage message and/or byte thresholds, as well as server-level quota for its targeted destinations. As a container for targeted destinations, any configuration or run-time changes to a JMS server can affect all the destinations that it hosts. JMS application gains access to WebLogic JMS by (a) obtaining a connection factory reference from JNDI, (b) obtaining a connection from this factory, and finally (c) using the connection to send or receive messages. JMS messages flow from an application, through its connection host, and then to any destination on a JMS server that is in the same cluster as the connection host. An application can use either default connection factories or custom connection factories that are configured using a JMS module. JMS destinations: hold JMS messages and are hosted on JMS servers. WebLogic JMS applications typically obtain JMS destination references via JNDI and then send and receive messages to these destinations using their respective JMS connections. A single logical WebLogic destination can be configured to be distributed across multiple JMS servers within the same cluster. A WebLogic JMS client can transparently communicate with any WebLogic JMS destination that is hosted in the same cluster as the client's connection host. 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 Naming and Directory Interface): provides a lookup facility for JMS connection factories and destinations 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
- JMS modules that you configure this way are considered system modules. JMS system modules are owned by the Administrator, who can at any time add, modify, or delete resources. System modules are globally available for targeting to servers and clusters configured in the domain, and therefore are available to all applications deployed on the same targets and to client applications.
- These are JMS resources that are defined as part of a JMS module Quute or topic identifies a point to point or pub/sub resource. Each is targeted to a JMS server. JMS server is responsible for pesisting messages and to maintain state of durable subscribers for those destinations CF enable clients to create JMS connections. The CF allows an admin to tune/specify options as to how those connections are created. WebLogic server comes with default CF already deployed. Default CF is not tunable a JMS template is a way to define multiple destinations with similar options Quotas – you can define quotas on destinations that specify the maximum number of messages or bytes for a destination Distributed destination – is a single set of destinations that are distributed across multiple servers within a cluster but are accessible to a client as a single endpoint Apps that use distributed are more highly available because WLS provides load balancing and failover for the members of a distributed destination automatically. Foreign JMS server allows you to reference third party JMS providers from within a local jNDI tree.
- Configure resources first Describe how applications use the resources
- WebLogic Server implements the Java EE 6 specification. Java EE 6 includes a deployment specification, JSR-88, that describes a standard API used by deployment tools and application server providers to configure and deploy applications to an application server.
- What does it mean to deploy?
- https://docs.oracle.com/middleware/1213/wls/DEPGD/deployunits.htm#DEPGD143 You may choose to deploy from an exploded archive directory under the following circumstances: You want to perform partial updates of an enterprise application after deployment. Deploying enterprise applications as an exploded archive directory makes it easier to update individual modules of the application without having to re-create the archive file. You are deploying a Web application or enterprise application that contains static files that you will periodically update. In this case, it is more convenient to deploy the application as an exploded directory, because you can update and refresh the static files without re-creating the archive. You are deploying a Web application that performs direct file system I/O through the application context (for example, a Web application that tries to dynamically edit or update parts of the Web application itself). In this case, the modules that perform the I/O operations should have a physical file system directory in which to work; you cannot obtain a file when the application is deployed as an archive, as per the specification.
- weblogic.Deployer provides a command-line based interface for performing both basic and advanced deployment tasks. Use weblogic.Deployer when you want command-line access to WebLogic Server deployment functionality, or when you need to perform a deployment task that is not supported using the WebLogic Server Administration Console. class="sect2" infotype="Concept"\\
- The WebLogic Server Administration Console provides a series of Web-based deployment assistants that guide you through the deployment process. The WebLogic Server Administration Console also provides controls for changing and monitoring the deployment status, and changing selected deployment descriptor values while the deployment unit is up and running.
- The WebLogic Scripting Tool (WLST) is a command-line interface that you can use to automate domain configuration tasks, including application deployment configuration and deployment operations. See Understanding the WebLogic Scripting Tool for more information. class="sect2" infotype="Concept"
- The deployment staging mode determines how deployment files are made available to target servers that must deploy an application or standalone module. WebLogic Server provides three different options for staging files: stage mode, nostage mode, and external_stage mode. https://docs.oracle.com/middleware/1213/wls/DEPGD/deploy.htm#DEPGD235 The Administration Server first copies the deployment unit source files to the staging directories of target servers. (The staging directory is named stage by default, and it resides under the target server's root directory.) The target servers then deploy using their local copy of the deployment files. The Administration Server does not copy deployment unit files. Instead, all servers deploy using the same physical copy of the deployment files, which must be directly accessible by the Administration Server and target servers. The Administration Server does not copy deployment files. Instead, the administrator must ensure that deployment files are distributed to the correct staging directory location before deployment (for example, by manually copying files prior to deployment).
- DCLC is deployment configuration lifecycle
- https://docs.oracle.com/middleware/1213/wls/DEPGD/config.htm#DEPGD167 Development configuration—During development, a programmer creates Java EE deployment descriptors for an application or module. The programmer also creates WebLogic Server deployment descriptors to configure the application for deployment to a WebLogic Server development environment. See Developing Applications for Oracle WebLogic Server. Note: Applications developed outside of the WebLogic Server development environment (for example, a sample or third-party Java EE application such as PetStore) may include only Java EE descriptors. Export configuration—Before releasing an application from development, a programmer or designer may optionally export the application's deployment configuration to a WebLogic Server deployment plan. Exporting a configuration creates deployment plan variables for all or a subset of the deployment properties already defined by a developer in the application's WebLogic Server deployment descriptor files. See Exporting an Application for Deployment to New Environments. Exporting an application helps deployers in other areas of the organization (such as engineers on the QA team or production administrators) easily deploy the application to environments that differ from the programmer's development environment. The ideal deployment plan includes all of the properties that a deployer needs to change before deploying the application in a new environment. Deployment-time configuration—An administrator or deployer configures the application before deploying the application into the target environment. Deployment-time configuration may use: The same WebLogic Server deployment configuration and deployment plan created during development. Modified versions of the development configuration and deployment plan. A custom deployment plan that the deployer previously created for the environment, depending on the deployment configuration workflow for your organization. See Deploying Applications and Modules with weblogic.Deployer. Post-deployment configuration—After an application has been deployed to a target environment, an administrator or deployer can reconfigure the application by redeploying with a new deployment plan or by using the WebLogic Server Administration Console to update and redeploy an existing deployment plan. See Redeploying Applications in a Production Environment and Managing Deployed Applications.
- In addition to a deployment name, an application or module can also have an associated version string. The version string distinguishes the initial deployment of the application from subsequent redeployed versions. For example, you may want to later update the application to fix problems or add new features. In production systems, it is critical to maintain a version string for both the initial and subsequent deployments of an application. Doing so allows you to update and redeploy an application version without interrupting service to existing clients. See Redeploying Applications in a Production Environment for more information. Should be provided by development
- Deployment plans help the administrator easily modify an application's WebLogic Server configuration for deployment to multiple, differing WebLogic Server environments without modifying the deployment descriptor files included in the application archive.
- The development team, cooperating with administrators and deployers, creates a master deployment plan for use with all target environments. The number of target environments will vary depending on your organizational structure. Common deployment environments include one or more Quality Assurance (QA) or testing domains, staging domains, and production domains. The deployment plan that the team creates at this phase defines variables for all configuration properties that are known to differ between each target environment. For example, the plan might define empty variables for resource names that differ between environments and must be configured before the application can be deployed. The plan may also define default values for common tuning parameters that deployers may want to change in their environments. For more information about creating a deployment plan during development, see Exporting an Application for Deployment to New Environments. When a version of the application is ready to be released, the development team packages the application deployment files and delivers both the deployment files and a master deployment plan to deployers for each target environment. Each deployer uses the WebLogic Server Administration Console to install the application and identify the deployment plan to use for configuration. The WebLogic Server Administration Console validates the overall deployment configuration based on the resources available in the target domain. The Console then presents a list of configurable properties defined in the plan (as well as any invalid properties) to the deployer for editing. The deployer uses the WebLogic Server Administration Console to interactively configure properties that were defined in the deployment plan. Deployment plan variables that have null values, or invalid values for the target WebLogic Server instances or clusters, must be configured before the application can be deployed. Deployment plan variables that already have valid values need not be changed before deployment. Deployers in each environment agree to limit their configuration changes to those properties defined in the deployment plan. If additional configuration changes are required, the deployer must communicate those requirements to the development or design team that modifies the master deployment plan.
- The application installation directory separates generated configuration files from the core application files, so that configuration files can be easily changed or replaced without disturbing the application itself. The directory structure also helps you to organize and maintain multiple versions of the same application deployment files. Oracle recommends copying all new production deployments into an application installation directory before deploying to a WebLogic Server domain. Deploying from this directory structure helps you easily identify all of the files associated with a deployment unit—you simply deploy the installation root using the WebLogic Server Administration Console, and the Console automatically locates associated files such as deployment plans and WebLogic Server deployment descriptors that were generated during configuration. infotype="Task"
- https://docs.oracle.com/middleware/1213/wls/DEPGD/redeploy.htm#DEPGD266
- https://docs.oracle.com/middleware/1213/wls/DEPGD/redeploy.htm#DEPGD266
- https://docs.oracle.com/middleware/1213/wls/DEPGD/managing.htm#DEPGD300 Makes an application unavailable for processing client requests, but does not remove the deployment from the WebLogic Server domain. Stopping an application places the deployment in administration mode, which allows you to perform internal testing using a configured administration channel. Makes an application unavailable for processing client requests and removes WebLogic Server-generated deployment files from the domain.
- http://docs.oracle.com/cd/E11035_01/wls100/cluster/overview.html 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.
- Multicast is a simple broadcast technology that enables multiple applications to "subscribe" to a given IP address and port number and listen for messages Multicast broadcasts messages to applications, but it does not guarantee that messages are actually received. If an application's local multicast buffer is full, new multicast messages cannot be written to the buffer and the application is not notified when messages are "dropped." Because of this limitation, WebLogic Server instances allow for the possibility that they may occasionally miss messages that were broadcast over multicast. The WebLogic Server multicast implementation uses standard UDP multicast to broadcast the cluster messages to a group that is explicitly listening on the multicast address and port over which the message is sent. Since UDP is not a reliable protocol, WebLogic Server builds its own reliable messaging protocol into the messages it sends to detect and retransmit lost messages. The WebLogic Server unicast protocol uses standard TCP/IP sockets to send messages between cluster members. Since all networks and network devices support TCP/IP sockets, unicast simplifies out-of-the-box-cluster configuration. It typically requires no additional configuration, regardless of the network topology between cluster members. Additionally, unicast reduces potential network errors that can occur from multicast address conflicts. WebLogic Server uses unicast as its default cluster protocol. Unicast is the default protocol because it simplifies out of the box cluster configuration and because it is likely to meet the majority of user requirements. However, Oracle fully supports both protocols equally. Both protocols require that the cluster members get sufficient processing time to send and receive cluster messages in a timely fashion. This prevents unnecessary cluster membership changes and the inherent resynchronization costs associated with leaving and rejoining the cluster. It is recommended that you eliminate unnecessary cluster membership changes due to over-utilization of available resources. When using unicast in particular, make sure that the group leaders are not resource constrained since they act as the message relay to deliver a cluster message to the rest of the cluster. Any slowness on their part can impact multiple cluster members and even result in the group electing a new group leader. Contrast this with multicast, where a slow member can only really impact its own membership to the cluster. Multicast clusters are generally more efficient in terms of cluster message propagation, and therefore tend to be more resilient to oversubscription of resources. For these reasons, multicast may be a better option for very large clusters with high throughput requirements, provided the network environment supports WebLogic Server cluster UDP requirements. Taken from https://docs.oracle.com/middleware/1213/wls/CLUST/features.htm#CLUST697
- Web Tier The Web tier provides static content (for example, simple HTML pages) to clients of a Web application. The Web tier is generally the first point of contact between external clients and the Web application. A simple Web application may have a Web tier that consists of one or more machines running Apache, Netscape Enterprise Server, or Microsoft Internet Information Server. Presentation Tier The presentation tier provides dynamic content (for example, servlets or Java Server Pages) to clients of a Web application. A cluster of WebLogic Server instances that hosts servlets and/or JSPs comprises the presentation tier of a Web application. If the cluster also serves static HTML pages for your application, it encompasses both the Web tier and the presentation tier. Object Tier The object tier provides Java objects (for example, Enterprise JavaBeans or RMI classes) and their associated business logic to a Web application. A WebLogic Server cluster that hosts EJBs provides an object tier.
- Passive Cookie Persistence Passive cookie persistence enables WebLogic Server to write a cookie containing session parameter information through the load balancer to the client. For information about the session cookie and how a load balancer uses session parameter data to maintain the relationship between the client and the primary WebLogic Server hosting a HTTP session state, see Load Balancers and the WebLogic Session Cookie. Active Cookie Persistence You can use certain active cookie persistence mechanisms with WebLogic Server clusters, provided the load balancer does not modify the WebLogic Server cookie. WebLogic Server clusters do not support active cookie persistence mechanisms that overwrite or modify the WebLogic HTTP session cookie. If the load balancer's active cookie persistence mechanism works by adding its own cookie to the client session, no additional configuration is required to use the load balancer with a WebLogic Server cluster. SSL Persistence When SSL persistence is used, the load balancer performs all encryption and decryption of data between clients and the WebLogic Server cluster. The load balancer then uses the plain text cookie that WebLogic Server inserts on the client to maintain an association between the client and a particular server in the cluster.
- The round-robin algorithm cycles through a list of WebLogic Server instances in order. For clustered objects, the server list consists of WebLogic Server instances that host the clustered object. For proxy plug-ins, the list consists of all WebLogic Server instances that host the clustered servlet or JSP. Simple to configure and use
- Server affinity is supported for JMS applications that use the distributed destination feature; this feature is not supported for standalone destinations. If you configure server affinity for JMS connection factories, a server instance that is load balancing consumers or producers across multiple members of a distributed destination will first attempt to load balance across any destination members that are also running on the same server instance. You can establishing load balancing for JMS servers by targeting them to migratable servers You can establish transparent cluster wide access targeting conn factory to the cluster
- https://docs.oracle.com/middleware/1213/wls/CLUST/failover.htm#CLUST202 WebLogic Server instances monitor the use of IP sockets between peer server instances as an immediate method of detecting failures. If a server connects to one of its peers in a cluster and begins transmitting data over a socket, an unexpected closure of that socket causes the peer server to be marked as "failed," and its associated services are removed from the JNDI naming tree.
- https://docs.oracle.com/middleware/1213/wls/CLUST/failover.htm#CLUST202 If clustered server instances do not have opened sockets for peer-to-peer communication, failed servers may also be detected via the WebLogic Server heartbeat. All server instances in a cluster use multicast or unicast to broadcast regular server heartbeat messages to other members of the cluster. Each heartbeat message contains data that uniquely identifies the server that sends the message. Servers broadcast their heartbeat messages at regular intervals of 10 seconds. In turn, each server in a cluster monitors the multicast or unicast address to ensure that all peer servers' heartbeat messages are being sent. If a server monitoring the multicast or unicast address misses three heartbeats from a peer server (for example, if it does not receive a heartbeat from the server for 30 seconds or longer), the monitoring server marks the peer server as "failed." It then updates its local JNDI tree, if necessary, to retract the services that were hosted on the failed server. In this way, servers can detect failures even if they have no sockets open for peer-to-peer communication.
- In-memory replication Using in-memory replication, WebLogic Server copies a session state from one server instance to another. The primary server creates a primary session state on the server to which the client first connects, and a secondary replica on another WebLogic Server instance in the cluster. The replica is kept up-to-date so that it may be used if the server that hosts the servlet fails. JDBC-based persistence In JDBC-based persistence, WebLogic Server maintains the HTTP session state of a servlet or JSP using file-based or JDBC-based persistence. For more information on these persistence mechanisms, see "Configuring Session Persistence" in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server. Coherence*Web You can use Coherence*Web for session replication. Coherence*Web is not a replacement for WebLogic Server's in-memory HTTP state replication services. However, you should consider using Coherence*Web when an application has large HTTP session state objects, when running into memory constraints due to storing HTTP session object data, or if you want to reuse an existing Coherence cluster.
- In a WebLogic Server cluster, most services are deployed homogeneously on all server instances in the cluster, enabling transparent failover from one server instance to another. In contrast, "pinned services" such as JMS and the JTA transaction recovery system are targeted at individual server instances within a cluster—for these services, WebLogic Server supports failure recovery with migration, as opposed to failover. Migration in WebLogic Server is the process of moving a clustered WebLogic Server instance or a component running on a clustered server 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. See Chapter 8, "Service Migration." To make JMS and the JTA transaction system highly available, WebLogic Server provides 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 fails—migration 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.
- JMS, JTA transacation recovery services are pinned Migratable servers Whole server migration is automatic or manual Server is restarted …. If that fails then it is migrated
- JMS, JTA transacation recovery services are pinned Migratable servers Whole server migration is automatic or manual Server is restarted …. If that fails then it is migrated
- Using the WebLogic Scripting Tool (or SSH client for script-based Node Manager only), you connect to a Node Manager process on the machine that hosts the Administration Server and issue commands to start, shut down, or restart an Administration Server. The relationship of an Administration Server to Node Manager varies for different scenarios. An Administration Server can be under Node Manager control—You can start it, monitor it, and restart it using Node Manager. An Administration Server can be a Node Manager client—When you start or stop Managed Servers from the WebLogic Server Administration Console, you are accessing Node Manager using the Administration Server. An Administration Server supports the process of starting up a Managed Server with Node Manager—When you start a Managed Server with Node Manager or a start script, the Managed Server contacts the Administration Server to obtain pending configuration updates. The restart feature is configurable. Node Manager's default behavior is to: Automatically restart server instances under its control that fail. You can disable this feature. Restart failed server instances no more than a specific number of times. You define the number of restarts by setting the RestartMaxproperty in a Node Manager startup.properties file.
- Java-based Node Manager runs within a Java Virtual Machine (JVM) process. Oracle recommends that you run it as a Windows service on Windows platforms and as an operating system service on UNIX platforms, allowing it to restart automatically when the system is rebooted. You can configure Java-based Node Manager using the Configuration Wizard or WLST offline. Script-based Node Manager is not recommended for production environments. However, depending on the security requirements for the environment in which you are using Node Manager, the script-based implementation may be acceptable. The advantage of the script-based Node Manager is that it can remotely manage server instances over a network that has been configured to use SSH. No additional server installation is required. The scripts merely have to be copied to the remote machine.
- In this diagram, Machine A hosts the Administration Server, and Machine B and Machine C host Managed Servers. Each machine contains a Node Manager instance. Using Node Manager, you can start, monitor and restart the Administration Server in Machine A. By using the Administration Server as a Node Manager client, you can start or stop Managed Servers in Machine B and Machine C. You can use the WebLogic Server Administration Console, WLST, or a JMX client to access Node Manager. You can use WLST commands to start, stop, and monitor a server instance when WLST is either connected directly to the Node Manager instance, or when WLST is connected to the Administration Server. When using the WebLogic Server Administration Console, you access Node Manager using the Administration Server. You can also use a JMX client to communicate with the Administration Server.
- In this diagram, Machine A hosts the Administration Server, and Machine B and Machine C host Managed Servers. Each machine contains a Node Manager instance. Using Node Manager, you can start, monitor and restart the Administration Server in Machine A. By using the Administration Server as a Node Manager client, you can start or stop Managed Servers in Machine B and Machine C. You can use the WebLogic Server Administration Console, WLST, or a JMX client to access Node Manager. You can use WLST commands to start, stop, and monitor a server instance when WLST is either connected directly to the Node Manager instance, or when WLST is connected to the Administration Server. When using the WebLogic Server Administration Console, you access Node Manager using the Administration Server. You can also use a JMX client to communicate with the Administration Server.
- In the real world production enterprise applications are deployed across multiple servers to increaes throughput and to improve SLAs. To date we’ve only discussed a single server topology where we have an admin server and a single server on the same machine host. In order to support a distributed deployment we must scale out our WebLogic domain.
- As I mentioned in the early part of this course way back when, a domain is merely a logical construct. It can span one or more hosts and can include any number of WebLogic servers. In a real world production deployment it is ideal to spread a WebLOgic domain across multiple machines not only for performance reasons but for high availability as well. The reason why WebLOgic is #1 when it comes to enterprise middelware is its performance and fault tolerance characteristics. WebLogic was built with scaling, elasticitiy and the cloud in mind. Hence the letter ‘c’ in WebLogic 12c. This course won’t cover the cloud elasticity, but I will go over how to install and deploy WebLogic across multiple hosts.
- https://docs.oracle.com/middleware/1213/wls/LOCKD/GUID-E5E57EA2-90AC-49E5-AF35-E217B8980BDC.htm#LOCKD129
- An Administration Port limits all administrative traffic between server instances in a WebLogic Server domain to a single port. When the server is run without an Administration Port, an application can inadvertently transmit confidential server configuration on the wire in clear-text. Running the server with an Administration Port significantly reduces the chances of this happening. Furthermore, having an Administrative Port configured is helpful should a Denial of Service (DoS) attack occur because the resources for handling requests for, and the limitations on Administration Port requests are separate from those of the rest of the server.
- A security realm comprises mechanisms for protecting WebLogic resources. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. A user must be defined in a security realm in order to access any WebLogic resources belonging to that realm. When a user attempts to access a particular WebLogic resource, WebLogic Server tries to authenticate and authorize the user by checking the security role assigned to the user in the relevant security realm and the security policy of the particular WebLogic resource. class="sect2"
- When users want to access WebLogic Server, they present proof material (for example, a password or a digital certificate) typically through a JAAS LoginModule to the Authentication provider configured in the security realm. If WebLogic Server can verify the identity of the user based on that username and credential, WebLogic Server associates the principal assigned to the user with a thread that executes code on behalf of the user. Before the thread begins executing code, however, WebLogic Server checks the security policy of the WebLogic resource and the principal (that the user has been assigned) to make sure that the user has the required permissions to continue.
- Managing groups is more efficient than managing large numbers of users individually. For example, an administrator can specify permissions for 50 users at one time by placing the users in a group, assigning the group to a security role, and then associating the security role with a WebLogic resource via a security policy.
- Are computed and granted to users or groups dynamically, based on conditions such as user name, group membership, or the time of day. Can be scoped to specific WebLogic resources within a single application in a WebLogic Server domain (unlike groups, which are always scoped to an entire WebLogic Server domain).
- A security policy is an association between a WebLogic resource and one or more users, groups, or security roles. Security policies protect the WebLogic resource against unauthorized access. A WebLogic resource has no protection until you create a security policy for it. A policy condition is a condition under which a security policy will be created. WebLogic Server provides a set of default policy conditions. WebLogic Server includes policy conditions that access the HTTP Servlet Request and Session attributes and EJB method parameters. Date and Time policy conditions are included in the Policy Editor. Security policies replace access control lists (ACLs) and answer the question "Who has access to a WebLogic resource?" A security policy is created when you define an association between a WebLogic resource and one or more users, groups, or security roles. You can optionally define date and time constraints for a security policy. A WebLogic resource has no protection until you assign it a security policy. You assign security policies to any of the defined WebLogic resources (for example, an EJB resource or a JNDI resource) or to attributes or operations of a particular instance of a WebLogic resource (an EJB method or a servlet within a Web application). If you assign a security policy to a type of WebLogic resource, all new instances of that resource inherit that security policy. Security policies assigned to individual resources or attributes override security policies assigned to a type of WebLogic resource.
- Security providers are modules that provide security services to applications to protect WebLogic resources
- Authentication providers allow WebLogic Server to establish trust by validating a user. The WebLogic Server security architecture supports Authentication providers that perform: username/password authentication, certificate and digest authentication directly with WebLogic Server, and HTTP certificate authentication proxied through an external Web server.
- A security provider database contains the users, groups, security roles, security policies, and credentials used by some types of security providers to provide security services (see Figure 4-1). For example: an Authentication provider requires information about users and groups; an Authorization provider requires information about security policies; a Role Mapping provider requires information about security roles, and a Credential Mapping provider requires information about credentials to be used to remote applications. These security providers need this information to be available in a database in order to function properly.
- WebLogic Server uses its embedded LDAP server as the database that stores user, group, security roles, and security policies for the WebLogic security providers. The embedded LDAP server is a complete LDAP server that is production quality for reasonably small environments (10,000 or fewer users). For applications that need to scale above this recommendation, the embedded LDAP server can serve as an excellent development, integration and testing environment for future export to an external LDAP server for production deployment. The embedded LDAP server supports the following access and storage functions: RDBMS is out of scope for this course XACML Authorization and Role Mapping providers WebLogic Credential Mapping provider PKI Credential Mapping provider The following providers for SAML 1.1: SAML Identity Assertion provider V2 SAML Credential Mapping provider V2 The following providers for SAML 2.0: SAML 2.0 Identity Assertion provider SAML 2.0 Credential Mapping provider Default Certificate Registry
- An MBean is a managed Java object, similar to a JavaBeans component, that follows the design patterns set forth in the JMX specification. An MBean can represent a device, an application, or any resource that needs to be managed. MBeans expose a management interface that consists of the following: http://docs.oracle.com/javase/tutorial/jmx/mbeans/