This topic describes how to develop an administrative client program that utilizes WebSphere Application Server administrative APIs and Java Management Extensions (JMX).
WebSphere Application Server administrative APIs provide control of the operational aspects of your distributed system as well as the ability to update your configuration. This topic also demonstrates examples of MBean operations. For information, view the Administrative API documentation, the JMX API documentation, or the MBean API documentation.
Properties connectProps = new Properties(); connectProps.setProperty( AdminClient.CONNECTOR_TYPE, AdminClient.CONNECTOR_TYPE_SOAP); connectProps.setProperty(AdminClient.CONNECTOR_HOST, "localhost"); connectProps.setProperty(AdminClient.CONNECTOR_PORT, "8879"); AdminClient adminClient = null; try { adminClient = AdminClientFactory.createAdminClient(connectProps); } catch (ConnectorException e) { System.out.println("Exception creating admin client: " + e); }
The example sets up a Properties object with the properties that are required to get to your server. In this case, you use the Simple Object Access Protocol (SOAP) connector to reach the server; for the connector type, use the value: AdminClient.CONNECTOR_TYPE_SOAP.
To access a remote host instead of a local host, use a network resolvable name for that host.
In a single server installation, the default port number for the
application server SOAP connector is 8880. In a Network Deployment installation, the default port number for the deployment manager
SOAP connector is 8879.
Depending on factors such as your desired protocol and security environment, you might need to set other properties. For more detailed information about the AdminClient interface and additional creation examples, refer to the AdminClient interface in the Java Management Extensions (JMX) API documentation.
[domainName]:property=value[,property=value]*For WebSphere Application Server, the domain name is WebSphere and the key properties defined for administration are as follows:
type | The type of MBean. For example: Server, TraceService, Java virtual machine (JVM). |
name | The name identifier for the individual instance of the MBean. |
cell | The name of the cell that the MBean is running. |
node | The name of the node that the MBean is running. |
process | The name of the process that the MBean is running. |
Some MBeans in WebSphere Application Server use additional key properties. An MBean without key properties can be registered with the MBean server in a WebSphere Application Server process. However, such an MBean cannot participate in the distributed enhancements that WebSphere Application Server adds, for example, request routing, distributed event notification, and so on. If you know the complete set of key properties for an ObjectName instance, you can use it to find the MBean it identifies. However, finding MBeans without having to know all of their key properties is usually more practical and convenient. Use the wildcard character asterisk (*) for any key properties that you do not need to match. The following table provides some examples of object names with wildcard key properties that match single or multiple MBeans.
*:type=Server,* | All MBeans of type Server |
*:node=Node1,type=Server,* | All MBeans of type Server on Node1 |
*:type=JVM,process=server1,node=Node1,* | The JVM MBean in the server named server1 node Node1 |
*:process=server1,* | All MBeans in all servers named server1 |
*:process=server1,node=Node1,* | All MBeans in the server named server1 on Node1 |
String nodeName = "MyNode"; String query = "WebSphere:type=NodeAgent,node=" + nodeName + ",*";
ObjectName queryName = new ObjectName(query);
ObjectName nodeAgent = null; Set s = adminClient.queryNames(queryName, null); if (!s.isEmpty()) nodeAgent = (ObjectName)s.iterator().next(); else System.out.println("Node agent MBean was not found");
By using a wildcard for the remaining key properties, this pattern matches the object names for all MBeans of the type NodeAgent on the node MyNode. Because only one node agent per node exists, this information is sufficient to identify the MBean that you want.
The AdminClient interface performs the remote call to the AdminService interface to obtain the set of MBean object names that match the query. The null second parameter to this method is a query expression (QueryExp) object that you can use as an additional query over the MBeans that match the ObjectName pattern in the first parameter.
The element is the MBean ObjectName instance of the node agent.
For the MBeans provided by WebSphere Application Server, you can find information about the interfaces they support in the MBean API documentation. The following example invokes one of the operations available on the NodeAgent MBean that you located previously. The following example starts the MyServer application server:
String opName = "launchProcess"; String signature[] = { "java.lang.String" }; String params[] = { "MyServer" }; try { adminClient.invoke(nodeAgent, opName, params, signature); } catch (Exception e) { System.out.println("Exception invoking launchProcess: " + e); }The AdminClient.invoke method is a generic means of invoking any operation on any MBean. The parameters are:
The launchProcess operation in the example has a single parameter which is a string that identifies the server to start.
The invoke method returns an object instance, which the calling code can use to cast to the correct return type for the invoked operation. The launchProcess operation is declared void so that you can ignore the return value in this example.
adminClient.addNotificationListener(nodeAgent, this, null, null);
In this example, the first parameter is the ObjectName for the node agent MBean. The second parameter identifies the listener object, which must implement the NotificationListener interface. In this case, the calling object is the listener. The third parameter is a filter that you can use to indicate which notifications you want to receive. When you leave this value as null, you receive all notifications from this MBean. The final parameter is a handback object that you can use to set the JMX API to return to you when it emits a notification.
If your MBean is located on another server in the cell, you can receive its notifications even though your administrative client program might be connected to the deployment manager server. All notifications flow to the upstream server. For example, a notification from an application server first flows to the local node agent and then to the deployment manager.
Another enhanced feature that Application Server provides is the ability to register as a notification listener of multiple MBeans with one call. This registration is done through the addNotificationListenerExtended method of the AdminClient interface, an extension of the standard JMX addNotificationListener method. This extension method even lets you register for MBeans that are not currently active. This registration is important in situations where you want to monitor events from resources that can be stopped and restarted during the lifetime of your administrative client program.
public void handleNotification(Notification n, Object handback) { System.out.println("***************************************************"); System.out.println("* Notification received at " + new Date().toString()); System.out.println("* type = " + ntfyObj.getType()); System.out.println("* message = " + ntfyObj.getMessage()); System.out.println("* source = " + ntfyObj.getSource()); System.out.println( "* seqNum = " + Long.toString(ntfyObj.getSequenceNumber())); System.out.println("* timeStamp = " + new Date(ntfyObj.getTimeStamp())); System.out.println("* userData = " + ntfyObj.getUserData()); System.out.println("***************************************************"); }
Related tasks
Creating a custom Java administrative client program using WebSphere Application Server administrative Java APIs
Using application clients