Index Changes
This is version 7. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]


Each components can have configurable operations that they want to expose. Today this is solved by providing a configuration MBean. And this configuration MBean provides only a pre-published set of APIs that are then also programmed into the common-client framework. But there are needs when more operations need to be exposed and the state of these operations is dependent on the state of the component. More flexibility is needed by the component to suggest what operations can be exposed and which one of those are enabled based on the state of the component.

For instance, if persistence is turned on, only then we want BPEL-SE to provide a "purge Data Action" in the list of BPEL-SE mbean actions. One way to do it is that the client (NB) has the code to see if the persistence is turned on or not. While it may solve such a simple scenario by putting such component specific logic in the client (NB) it is not a good idea since it forces the MBean clients to be aware of some component specific logic. Sometimes this could get trickier, for instance, in BPEL-SE even though persistence is turned on, if the engine is not shutdown and then started, persistence is not really turned on. In such situations, the UI doesn't really know if it can display the menu action "purge Data Action".

In summary, components need more Dynamic MBean actions, whose logic only the component understands. The MBean client can't be smart enough to understand the logic of the component to determine what operations are available and what operations are enabled/disabled.


  • No cluster support for now
  • No support of passing in parameters to the MBean operations
  • It is a prototype between BPEL-SE and NB runtime support.


Each component registers an MBean by the identifier "ManagementActions". something like - context.getMBeanNames().createCustomComponentMBeanName("ManagementActions") This ManagementActions MBean will have one MBean operation called, "getActions()". Netbeans knows the above information and will query the ManagementActions.getActions() on the component.

The getActions() API will return an XML string conformant to the XSD,

<xsd:schema xmlns:xsd="" targetNamespace="" xmlns:tns="" elementFormDefault="qualified"> <xsd:element name="root"> <xsd:complexType> <xsd:sequence> <xsd:element ref="tns:Action" maxOccurs="unbounded" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Action" type="tns:ActionType"/> <xsd:complexType name="ActionType"> <xsd:sequence> <xsd:element name="MBeanKey" type="xsd:string" minOccurs="0"/> <xsd:element name="OperationName" type="xsd:string" minOccurs="0"/> <xsd:element name="DisplayName" type="xsd:string"/> <xsd:element name="Description" type="xsd:string"/> <xsd:element name="Enabled" type="xsd:boolean" default="false" minOccurs="0"/> <xsd:element ref="tns:Action" maxOccurs="unbounded" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="isGroup" type="xsd:boolean" default="false"/> </xsd:complexType> </xsd:schema>


    • MBeanKey - This is the key with which any MBean registered on the Management server is to be identified. This design gives the flexibility for the component to organize and provide as many MBeans as the component sees fit to implement.
    • OperationName - MBean Operation that can be invoked upon (Operation defined on the MBean registered by the MBeanKey
    • DisplayName - Name that a client (NB) would use to display User
    • Description - Description of the operation
    • Enabled - Flag to hint the client to either enable or disable the action
    • isGroup - To determine if an node is a group or not

(Important: components need to consider internationalizing the UI aspect of this, namely DisplayName and Description values.)

common management API

Even though the scope doesn't include clustering, the common management API has been designed keeping cluster scenario in view. This API is also designed keeping in mind future requirements where the MBean operations may take parameters.

/** * Invokes an operation on an Extension MBean. * @param componentName * @param extensionName the name of the extension (e.g., Configuration, Logger, etc.) * @param operationName The name of the operation to be invoked. * @param parameters An array containing the parameters to be set when the operation is invoked * @param signature An array containing the signature of the operation. The class objects will be loaded using the same class loader as the one used for loading the MBean on which the operation was invoked. * @param targetName name of the target (e.g., server, Cluster1, StandloneServer2, etc.) * @param targetInstanceName name of the target instance (e.g., Cluster1-Instance1, Cluster2-Instance10, etc.) * @return The object returned by the operation, which represents the result of invoking the operation on the Extension MBean specified. * @throws ManagementRemoteException */ public Object invokeExtensionMBeanOperation(String componentName, String extensionName, String operationName, Object[] parameters, String[] signature, String targetName, String targetInstanceName) throws ManagementRemoteException;

Quick Walk Through:

When a user right clicks on a component say BPEL-SE in the NB runtime, NB will query the component MBean using the common management API mentioned above.

An example instance document of the above mentioned XSD could be

<?xml version="1.0" encoding="windows-1252"?>
<ns0:root  xmlns:xsi=''
   xsi:schemaLocation=' newXmlSchema.xsd'>
	            <ns0:DisplayName>Purge persistence data</ns0:DisplayName>
	            <ns0:Description>Deletes persistence data</ns0:Description>
            <ns0:Action isGroup="true">
                <ns0:DisplayName>Monitor Actions</ns0:DisplayName>
                <ns0:Description>Actions related to onitoring</ns0:Description>
                    <ns0:DisplayName>Purge data</ns0:DisplayName>
                    <ns0:Description>Purges monitoring data</ns0:Description>
                    <ns0:DisplayName>Archive data</ns0:DisplayName>
                    <ns0:Description>Archives monitoring data</ns0:Description>

The UI on NB most probably would look like,

When the user clicks on the action, "Purge Data", NB will query the MBean using the same common management API. NB will query corresponding component MBean and the operation specified in the corresponding xml section associated with the "Purge Data" action.

	            <ns0:DisplayName>Purge persistence data</ns0:DisplayName>
	            <ns0:Description>Deletes persistence data</ns0:Description>

Feed back:

Feedback and Todos to consider in future.

  • Some components may not keep the state (JBI component states, init, shutdown, started). It will be useful to accommodate those components by passing in a "state" value as part of the getAction() API. How do we support custom states? Perhaps a simple "string" parameter is sufficient. Please note that the common management API is already designed to take in parameters.
  • Involve HIE for their inputs on how to display the actions consistently across all components.
  • command line/scripting option should be made available
  • Could there be cases where we want to mix the configuration display with an action related to that configuration? If we want to address this case, we may need to enhance the configuration MBean support to take in actions associated with property changes.

JSPWiki v2.4.100
« Home Index Changes Prefs
This particular version was published on 11-Dec-07 20:06 PM, -0800 by Kiran K Bhumana