Index Changes
Page Difference

Difference between version and version     

Back to Extended Management Actions, or Extended Management Actions Info


At line 1 added 5 lines.
%%tabbedSection
%%tab-FeatureUsage
__Refer the design tab for the design and architecture of the extended management actions__
At line 2 changed 1 line.
__Requirement__: \\
BPEL SE supports [persistence |http://wiki.open-esb.java.net/Wiki.jsp?page=BPELSEPersistenceAndRecovery] and [monitoring|http://wiki.open-esb.java.net/Wiki.jsp?page=BPELMonitor]. Usage of BPEL SE over time would result in the accumulation of the data in the persistence store.
At line 9 added 31 lines.
! 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. Primarily persistence data is used to recover instances from events such as system crashes. 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.
! Scope:
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.
[{Image src='http://wiki.open-esb.java.net/attach/ExtendedManagementActions/ManagementActions.png' width='' height='' align='left|center|right' }]
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.
%%
%%tab-Design
! __Requirement__: \\
At line 11 changed 1 line.
__Scope__: \\
! __Scope__: \\
At line 13 changed 3 lines.
* 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.
* 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.
At line 17 changed 1 line.
__Solution__: \\
! __Solution__: \\
At line 58 added 2 lines.
__MBean API__ \\
At line 26 changed 1 line.
{{{
%%(color:#990000;){{{
At line 92 added 33 lines.
}}}%%
where, \\
** 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 <Action> 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.
%%(color:#990000;){{{
/**
* 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;
At line 126 added 1 line.
%%
At line 53 removed 1 line.
An example instance document of this could be
At line 129 added 7 lines.
! __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
At line 65 changed 1 line.
<ns0:Enabled>false</ns0:Enabled>
<ns0:Enabled>true</ns0:Enabled>
At line 75 changed 1 line.
<ns0:Enabled>false</ns0:Enabled>
<ns0:Enabled>true</ns0:Enabled>
At line 90 changed 1 line.
[{Image src='' width='' height='' align='left|center|right' }]
[{Image src='http://wiki.open-esb.java.net/attach/ExtendedManagementActions/ManagementActions.png' width='' height='' align='left|center|right' }]
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:Action>
<ns0:MBeanKey>ManagementActions</ns0:MBeanKey>
<ns0:OperationName>purgePersistenceData</ns0:OperationName>
<ns0:DisplayName>Purge persistence data</ns0:DisplayName>
<ns0:Description>Deletes persistence data</ns0:Description>
<ns0:Enabled>true</ns0:Enabled>
</ns0:Action>
}}}
! __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.
%%
%%
%%tabbedSection
----
* Back to [SystemicQualities.Monitoring]
G'day, Anonymous Guest

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-15) was last changed on 03-Mar-09 02:31 AM, -0800 by Gopalan Suresh Raj