Use admin programs (JMX)
Overview
We can administer WAS and the applications through tools that come with WAS or through programming with the Java APIs. Tools that come with WAS include...
- wsadmin
- admin console
- administrative command-line tools
These admin tools provide most of the functions that we need to manage WAS and the applications that run in WAS. Use the command-line tools from automation scripts to control the servers. Scripts that are written for the wsadmin scripting tool offer a wide range of possible custom solutions that we can develop quickly.
Investigate these tools with the Java APIs to determine the best ways to administer WAS and the applications. For information on the Java APIs, view the APIs documentation.
- No action required for WAS JMX APIs:
Each JVM in WAS includes an embedded implementation of JMX. In WAS v5, the JVMs contain an implementation of the JMX 1.0 specification. In WAS v6.0 and later, the JVMs contain an implementation of the JMX 1.2 specification. The JMX 1.0 implementation used in V5 is the TMX4J package that IBM Tivoli products supply. The JMX 1.2 specification used in V6.0 and later is the open source mx4j package. The JMX implementation change across the releases does not affect the behavior of the JMX MBeans in the appserver. No Application Server admin APIs are altered due to the change from the JMX V1.0 specification to the JMX V1.2 specification.
- Action might be required for custom MBeans:
The JMX V1.2 specification is compatible with the earlier JMX V1.0 specification. However, we might need to migrate custom MBeans that are supplied by products other than the appserver from V5 to V6.0 and later. The primary concern for these custom MBeans is related to the values that are used in key properties of the JMX ObjectName class for the MBean. The open source mx4j implementation more stringently enforces property validation according to the JMX 1.2 specification. Test the custom MBeans that you deployed in V5 in V6.0 and later, to ensure compatibility.
WAS supports access to the admin functions through a set of Java classes and methods. We can write a Java program that performs any of the administrative features of the WAS admin tools. We can also extend the basic WAS admin system to include our own managed resources.
You can prepare, install, uninstall, edit, and update applications through programming.
Preparing an application for installation involves collecting various types of WAS-specific binding information to resolve references defined in the application deployment descriptors. This information can also be modified after installation by editing a deployed application. Updating consists of adding, removing or replacing a single file or a single module in an installed application, or supplying a partial application that manipulates an arbitrary set of files and modules in the deployed application. Updating the entire application uninstalls the old application and installs the new one. Uninstalling an application removes it entirely from the WAS configuration.
Manage WAS applications through programming
- Create a JMX remote client program by using the JMX remote API (JSR 160)..
- Create a custom Java administrative client program using the Java admin APIs.
- Extend the WAS admin system with custom MBeans.
- Deploy and manage a custom Java admin client program for use with multiple Java EE appservers.
Results
Depending on which tasks you complete, we have created our own administrative program, extended the WAS admin console, connected and managed vendor servers, or managed the applications through programming.
Next steps
We can continue to administer WAS and the applications through programming or in combination with the tools that come with the WAS. 
Related concepts
Java Management Extensions
Create a custom Java admin client program using WAS admin Java APIs
Create a JMX client program using the JMX Remote API
Extending the WAS admin system with custom MBeans
Administrative programs for multiple Java EE appservers
Deploy and managing a custom Java admin client program with multiple Java EE appservers
JMX V1.0 to JMX V1.2 migration
JMX interoperability
Managed object metadata
Additional Application Programming Interfaces (APIs)