WebLogic Server 10.3 Tech Preview

I am so excited about the new features of WebLogic Server 10.3 which is in Tech Preview right now. So I thought I would share some of the cool features coming...

• In development Admin Console is deployed on demand the very first time someone access it. This will save memory and will speed up the development servers startup.
• Admin Console is now internally tuned for better response time.
• Light Weight Installer- Fine grained installer to reduce the footprint of the installation.

• Light Weight Runtime - If you are not using EJB, JMS, JCA you can disable those services to start WLS in a light weight mode.
• On Demand Internal Application Deployment - UDDI Explorer, Console, WS Test Client and their runtime can be be deployed on demand. This will also reduce the server's footprint when you are not using them.
• WLS 10.3 is shipping with JDK 6.
• Web 2.0 is now supported for building rich internet applications.
• Support for C# client with JMS will let .NET applications directly access JMS in WLS 10.3

and much more...

See http://e-docs.bea.com/wls/essex/TechPreview/pdf/feature_overview.pdf for more info.

Try WLS 10.3 TP

Audit WebLogic Server domain for configuration changes

In a typical WebLogic shop with more than one administrator managing the WebLogic domain(s) there is possibility that these admins can make changes without one others knowledge (at different times). To have an audit of all the configuration changes the "Configuration Audit Type" of the domain should be set. You can create the audit log entries in the administration server's server log by setting it to "Change Log" or "Change Audit" will forward it to the security audit log or "Change Log and Audit" will send it to both these logs.

See this section of edocs for more info on how to change this value.

I believe this is one of the hidden secrets in WLS. You can also audit any changes that were made and not activated but released in the audit log entries. Another main use of this feature could be to watch the security changes like who is adding new users, groups etc. The actual security audit provider only audit events like AUTHENTICATION, USERLOCKOUT etc.

Here are some sample configuration audit entries when I create a user called 'test' and added the user to the 'Administrator' group (other entries from the log file are removed for clarity):



####<Apr 1, 2008 5:12:07 PM EDT> <Info> <Configuration Audit> <BALA02> <AdminServer>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'>
<weblogic> <> <> <1207084327610> <BEA-159907>
<USER weblogic INVOKED ON Security:Name=myrealmDefaultAuthenticator METHOD listMemberGroups PARAMS test>

####<Apr 1, 2008 5:12:07 PM EDT> <Info> <Configuration Audit> <BALA02> <AdminServer>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'>
<weblogic> <> <> <1207084327626> <BEA-159907>
<USER weblogic INVOKED ON Security:Name=myrealmDefaultAuthenticator METHOD addMemberToGroup PARAMS Administrators; test>

####<Apr 1, 2008 4:59:48 PM EDT> <Info> <Configuration Audit> <BALA02> <AdminServer>
<[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'>
<weblogic> <> <> <1207083588603><BEA-159907>
<USER weblogic INVOKED ON Security:Name=myealmDefaultAuthenticator METHOD createUser PARAMS test; ****; >

As WebLogic doesn't have the concept of super admin, all the administrators are treated the same. So when you have more than one administrative user managing a domain, the configuration audit feature will help you find out which admin did what.

Would you like to have a view of WebLogic Server instances from a control tower ?!

If you have enterprise-wide management systems in place and are looking a way to integrate WebLogic Server instances then WebLogic Server SNMP is your option. You can use Simple Network Management Protocol (SNMP) to provide monitoring data from your WebLogic Server instances to your enterprise-wide management systems.

SNMP set of standards provides a framework for the definition of management information along with a protocol for the exchange of that information. The SNMP model assumes the existence of managers and agents. A manager is a software module responsible for managing part or all of the configuration on behalf of network management applications and users. An agent is a software module in a managed device responsible for maintaining local management information and delivering that information to a manager via SNMP. A management information exchange can be initiated by the manager (via polling) or by the agent (via a trap). Agents function as collection devices that gather and send data about the managed resource in response to a request from a manager.

WebLogic supports SNMP for a long time starting from version 5.1. WebLogic SNMP enables you to move towards a single management console and thus provide integrated systems management of WebLogic Server based applications. Also WebLogic SNMP enables you to connect WebLogic Server to popular management systems such as HP OpenView, IBM Tivoli, MRTG, and Sun SunNet Manager. This makes managing WebLogic Server more effective by providing a whole-system perspective instead of piecemeal solutions.

In WebLogic Server Version 10.x SNMP implementation went through a lot of changes. Some of the important changes are:

• WebLogic Server SNMP implementation now supports SNMPv3 with SNMPv1 and SNMPv2. SNMPv3 provides additional security compared to prior versions.

• Previously only one SNMP agent per domain which runs on the Administration Server now you can create multiple agents on different servers. This removes the dependency with Administration Servers.

• Now custome MBeans can be monitored using SNMP in addition to standard WLS MBeans.

• The old command-line utilities are not deprecated and a new command-line utility is introduced - weblogic.diagnostics.snmp.cmdline.Manager

• SNMP agents in WLS can now use TCP port in addition to UDP Port which was the only option in the previous versions. And many of the configuration changes in SNMP are now dynamic which doesn't require start.

For more information read the edocs - http://edocs.bea.com/wls/docs100/snmpman/snmpagent.html

With more and more system and server administrator coming to the paradigm of administering application servers and enterprise applications, this will provide them a way to integrate WebLogic with enterprise level monitoring solutions.

Does your WLS File Store grow in size?

JMS Server in WLS only removes the messages that are expired once in every expiration scan interval (A JMS Server level config). The destination may have expired message sitting in them if the expiration scan interval property is set to a high value. For ex. 1800 will cause the JMS Server to scan for expired messages once in 30 mins. Still applications cannot receive the expired messages - they will be sitting in the destination. But it doesn’t automatically do any compaction per se. So the file size of the WLS File Store may keep increasing. This might cause slow startup of the server.

You can perform manual offline compaction in the following ways:

• There is a Java command-line utility that can do this trick "weblogic.store.Admin". See Edocs for more info.
  

• A WLST command called "compactstore" can also do the same trick. See Edocs for more info.

Note that this compaction is supported only for WLS File Stores and not for JDBC Stores as they don't suffer with the same issue of compaction.

The Java command-line utility "weblogic.store.Admin can also be used to dump the contents of a store into an XML file for troubleshooting purpose.

Play Hide & Seek with Administration Console

Everyone who work with WLS knows that the Administration Console is the light weight web based UI provided by BEA for configuring, monitoring and managing a WLS domain. Automation and Scripting can be done in many ways. See this post for more info.

Exposing the console in your production environment might be security issue. In those cases you can either disable the console or hide it. Needless to say if you disable the console then your only option is to depend on command-line and scripting tools for any other administration activity or to even enable the console back. But hiding will provide a level or security.

To disable the console:

• In the admin console navigate to --> General --> Advanced Options --> Console Enabled. De-select that option to disable console (restart required).
  

To hide the cosole:

• Enable the administration port on the domain so that console can only be accessed on the 2-way secured admin port. This will force all the clients to have valid certificate installed in their client (browser) to access the console.
• In the admin console navigate to --> General --> Advanced Options --> Console Context Path and change the context-path of the console to something unique and only known to the administrators.

All is fine. But one of the common question is how can I enable the console once I disable them. Like I said earlier you have to rely on the scripting tool to enable the admin console once it is disabled. You either perform this action interactively or by running a WLST script. See the following sample WLST script for more info:

connect("username","password")
edit()
startEdit()
cmo.setConsoleEnabled(true)
save()
activate()
disconnect()
exit()

You have to restart the administration server to get the console back. Have fun playing hide and seek with the console!

In WLS 10.3 with the Light Weight Server Installer, you can choose not to install WLS Admin Console when you install WLS. Along with the other installation options, this provides a way to reduce the server installation footprint and runtime memory footprint. Can't wait to play with WLS 10.3, you can now download the Tech Preview at http://commerce.bea.com/showproduct.jsp?family=WLS&major=10.3Tech&minor=-1
(as of Nov 9, 2007 WLS 10.3 is only a Tech Preview Release). I will write more on the WLS 10.3 release which is build on BEA microService Architecture (mSA) soon. Read more about BEA mSA here http://www.bea.com/framework.jsp?CNT=msa.jsp&FP=/content/.

Is my Administration Server single point of failure?

The answer is No and Yes. Read on for more specific info....

WebLogic domain consists of Servers, Machines, Clusters, Applications and Configurations related to them. Administration sever is the controlling instance for the domain. It is the keeper of all the configuration. Ideally you don't want to host (target) any application or service that clients would access on the admin instance. Managed server(s) or cluster(s) are meant to host such applications and services that clients would access (servers other than admin server in a domain are called as managed servers).

Having said that, if an admin instance fails during the middle of the day what happens to my domain? It is the controlling instance so will it halt my domain? The answer is NO. Admin server will provide all the configurations to each managed server and they will be cached locally. There are limited dependency between the servers during runtime. So an admin server failure will not affect the running managed server(s) or cluster of managed server(s).

Alright, what about the "Yes" part of the above answer?! There are few services you will lose when an admin instance is not available. You cannot introduce any new configuration or change any existing configuration in the domain. Examples are: you cannot deploy new applications, you cannot change the JNDI name of a JMS destination hosted on one or more servers etc. You will also lose the domain log entries in the Domain Log file maintained by the administration server. Still you can use the Server Log maintained on each managed server for auditing or troubleshooting purpose. Also lastly the managed server(s) in the absence of admin server can only be started or restarted in Independence Mode (using the previously cached local configuration information).

• You are not expected to introduce new configuration or change any configuration on the fly in your production setup so losing the ability to do this will have literally no or little impact.
  
• You can use server log file entries for auditing and troubleshooting purposes.
  
• The managed server can be restarted or started if required during the absence of admin server using Independence Mode (which is a default setup now in WLS 10.x - no extra configuration required).

Admin server (for that matter any server in the domain) can be configured to automatically get restarted in case of failures using a feature called - whole server migration. I will talk about this in a later discussion.

So now you know why I said "No" and "Yes"! huh!

Managed Server Independence Mode

Starting from version 7 WebLogic managed servers can be started in the absence of an administration server. The feature that will enable a managed server to come up in the absence of administration server (MSI mode) is enabled by default. But some of the files required for MSI mode are only sent to the managed server only when another option (MSI file replication enabled) is ON.

This feature is same in version 8 except that the config.xml being copied and cached in the managed server is stored as msi-config.xml.

In version 9 the feature is still the same except that the complete config directory that contains the configuration file is copied by default to the managed servers. But some other files like the security (*.dat) file is not copied until the MSI file replication enabled option is ON.

Version 10 alleviate all the pains by making MSI mode and MSI file replication as a default option. So out of the box a managed server is enabled to run in independence mode. And all the files required to start a managed server by itself (/config dir and *.dat file) will be automatically copied to the managed server during startup and will be synced (automatically) with the master copy (in Admin Server).