Index Changes
This is version 13. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]
Refer the design tab for the design and architecture of the extended management actions

BPEL SE supports persistence and monitoring. Usage of BPEL SE over time would result in the accumulation of the data in the persistence store.

Purging scripts:

Users would like to have more free space by deleting old and unwanted records. This applies to both persistence data store and monitoring data store. It's relevance and importance is felt more for monitoring, since monitoring records a whole lot more events than persistence. Providing out of the box scripts to do purging will take out the hassle from end users to write such scripts. The hassle is more pronounced for persistence data since persistence schema is not exposed like monitoring schema.

Archiving scripts:

Post Sierra release. Sierra release is scheduled somewhere around 2nd quarter of 2008.

Users would like to back up their data before purging or back up their data for various reasons such as auditing or providing analytics. While we recognize that providing out of the box archiving scripts would be useful, we had to drop it for Sierra due to time constraints. At the same time since the monitoring schema is exposed to the users, it is expected that monitoring users writing archival scripts on the exposed schema is not unreasonable. Persistence data is used to recover instances in the unlikely events such as crash of BPEL SE. It is not directly used by the end user and hence is felt that there won't be a requirement to archive the persistence data.


This feature is provided as a developer version of the feature. We would like to get more feedback before we proceed with more advanced requirements which provide options such as parameters to the purging and archiving scripts. Some such parameters could be; date, state of instances, type of instances and so on. Would the users appreciate such an out of box solution or would they prefer writing their own scripts as DB ownership issues pop up in enterprise deployments?

Hence the scope of this feature doesn't include cluster support. It is only applicable for single engine users and is provided conveniently from the NB runtime GUI.

Quick Walk Through:

When a user right clicks on a component say BPEL-SE in the NB runtime, user sees the following actions.

The actions are enabled depending on the state of the BPEL-SE. Purge data action for persistence is enabled if the engine's persistence is turned on. Likewise for purging monitoring data.


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 12-Dec-07 15:38 PM, -0800 by Kiran K Bhumana