Java CAPS Management and Monitoring APIs

This topic provides information on common management and monitoring tasks. The management and monitoring APIs are not installed during the Java^TM Composite Application Platform Suite (Java CAPS) installation; they are packaged as EM_API_KIT.zip. This ZIP file is on ESB_API_Kit.zip. You need to extract EM_API_KIT.zip to your root Java CAPS 6 installation directory. If you extract the file to another directory you need to set the JAVA_HOME, JAVA_CAPS, and the ENGINE_HOME environment variables in env.bat. For information on how to do this, see To Modify the Environment Variables in env.bat. Also included with the ZIP file are JavaDocs, Java samples, and Groovy scripting samples that demonstrate how to use the APIs.

If you have any questions or problems, see the Java CAPS Support web site at http://goldstar.stc.com/support.

To access all the Java CAPS documentation in HTML format on the Sun Developer Network (SDN) web site, go to http://developers.sun.com/docs/javacaps/.

You can also access the Java CAPS documentation on the SDN web site by clicking the HELP tab in Enterprise Manager.

The HELP tab in the Java CAPS Uploader opens the “Installing Java CAPS Components Using the Java CAPS Uploader” topic.

What You Need to Know

• Java CAPS Management Client

• Getting Started Using APIs

• Connecting to the Server Through APIs

• The Alert Management API

• Services — JavaCAPSManagementAPI

• Writing Java Code to Access APIs Using Java Code Samples

• Setting Up Databases

• Using Oracle and Other Databases for Alert Persistence

• Setting Up Scripting Engines

You expose management and monitoring using:

• A common API

  The client API kit is installable from the Java Composite Application Platform Suite (Java CAPS) Installer and is packaged along with the Groovy scripting engine, Groovy libraries, and samples.

• JSR 223 Scripting

  All management capabilities are exercisable from any language that supports JSR 223 scripting for the Java platform. Currently this includes 25 different scripting languages, including Groovy, JRuby, Jython, JACL, etc.

• Sun Java System Application Server Admin Console

  All JBI administration use-cases are built into the Sun Java System Application Server Admin Console. This enables administrators to administer their domain runtimes and components remotely using a browser.

• Command-line interface

  The AS Admin command-line interface that comes with the Sun Java System Application Server enables you to manager your application server environment. All JBI administration use-cases have been integrated into the AS Admin command-line interface. In addition, the command-line interface that used to manage non-JBI components is also available for you to use.

• Ant

  asant enables you to run ant scripts on the Sun Java System Application Server. All JBI administration use-cases have been integrated into the Sun Java System Application Server's asant, and are available to exercise though any ant scripting that is available to you.

• Java CAPS Enterprise Manager

  Use Enterprise Manager to remotely to administer your non-JBI based components.

• NetBeans Administration plugins

  The JBI Manager that comes with NetBeans IDE enables developers to manage the JBI runtimes component containers and composite applications. The Composite Application Project System (CASA) enables developers to deploy and manage lifecycle operations during development.

Java CAPS Management Client

This topic introduces you to the Java CAPS Management Client and the clients that use the API set with JBI based Java CAPS runtime and Non-JBI based Java CAPS runtime.

• Scripting client — Use any JSR 223 scripting client, such as Groovy, JRuby, Jython, or JACL. See Setting Up Scripting Engines for additional information.

  ---

  Note –

  Groovy samples are included with the Java CAPS Release 6 delivery.

  ---

• CLI client — Exercise the APIs using your own Command-line Interface client that you built using predefined functioning code, preferably Java.

• Other Web/GUI clients — Exercise the APIs using your custom Web/GUI client.

Examples of Typical Client Usage

  try {
    // Get the Management Client
    ManagementClient client = ManagementClientFactory.getInstance
    ("localhost", 4848, "admin", "adminadmin");

    // Get the Administration Service
    AdministrationService administrationService = 
    client.getService(AdministrationService.class);
    // ... Use the Administration Service ...

    // Get the Configuration Service
    ConfigurationService configurationService = 
    client.getService(ConfigurationService.class);
    // ... Use the Configuration Service ...

    // Get the Deployment Service
    DeploymentService deploymentService = 
    client.getService(DeploymentService.class);
    // ... Use the Deployment Service ...

    // Get the Installation Service
    InstallationService installationService = 
    client.getService(InstallationService.class);
    // ... Use the Installation Service ...

    // Get the Runtime Management Service
    RuntimeManagementService runtimeManagementService = 
    client.getService(RuntimeManagementService.class);
    // ... Use the Runtime Management Service ...

    // Get the JMS Management Service
    JmsManagementService jmsManagementService = 
    client.getService(JmsManagementService.class);
    // ... Use the JMS Management Service ...

    // Get the Alert Management Service
    AlertManagementService alertManagementService = 
    client.getService(AlertManagementService.class);
    // ... Use the Alert Management Service ...

    // Get the Log Management Service
    LogManagementService logManagementService = 
    client.getService(LogManagementService.class);
    // ... Use the Log Management Service ...

  } catch (ManagementRemoteException exception) {
    // Format the exception and print it.
    String formattedExceptionResult= 
    ManagementRemoteExceptionProcessor.processTaskException(exception);
    System.out.println(formattedExceptionResult);
  }
    

JavaDocs

The JavaDocs contain a complete list of all the classes in the API. They are included with the Java CAPS delivery as zipped files.

Targets

A target provides the scope of an administrative operation. Directing a command at multiple targets effectively increases the scope of that command. If multiple targets are specified, the success or failure of each target is reported separately. In other words the result of the operation on all targets is not “rolled up” into a summary status. The following table describes the scope of each target type.

Two of the target option names are constant: “domain” and “server.” They represent an instance of an operator and are replaceable with a name specific to the current template.

The samples that are pertinent to this topic, such as AdministrationServiceSample.groovy, are included with the delivery as zipped files.

Getting Started Using APIs

The Java Composite Application Platform Suite (Java CAPS) APIs are available for users and developers to create applications and web pages.

To Start Using APIs to Create Applications

The following task includes everything a you need to create an application using the Java CAPS APIs. If you are connecting using the Sun Java System Application Server (SJSAS) that you installed during the Java CAPS Installation you do not need any additional JAR files in your working directory. However, if you are connecting remotely, you need the following JAR files in your working directory:

• When connecting through just the RMI protocol using the JSR-160 MX URL you need these JAR files:

  %CAPS_MANAGEMENT_HOME%\api\caps.management.client.jar; %SJSAS_HOME%\jbi\lib\jbi-admin-common.jar; %SJSAS_HOME%\lib\javaee.jar;

• When connecting through the HTTP/HTTPS protocols, you need these JAR files:

  %CAPS_MANAGEMENT_HOME%\api\caps.management.client.jar; %SJSAS_HOME%\jbi\lib\jbi-admin-common.jar; %SJSAS_HOME%\lib\javaee.jar; %SJSAS_HOME%\lib\appserv-deployment-client.jar; %SJSAS_HOME%\lib\appserv-ext.jar; %SJSAS_HOME%\lib\appserv-rt.jar; %SJSAS_HOME%\lib\jmxremote_optional.jar

1. Use this example to connect to the JMX URL

   String hostName = "localhost"; int jrmpPortNumber = 8686; String userName = "admin", password = "adminadmin"; boolean isRemoteConnection = true; String jrmpURLString = "service:jmx:rmi:///jndi/rmi://" + hostName + ":" + jrmpPortNumber + "/jmxrmi"; CAPSManagementClient managementClient = CAPSManagementClientFactory.getInstance(jrmpURLString, userName, password, isRemoteConnection);

2. Get the service you need to write your application, for example the AdministrationService.

   // get services CAPSAdministrationService administrationService = managementClient.getService(CAPSAdministrationService.class);

3. After creating the application, for example JBIRuntime, invoke the application.

   // use the service, System.out.println("The JBI Runtime is "+(administrationService.isJBIRuntimeEnabled()? "Enabled." : "NOT Enabled."));

Connecting to the Server Through APIs

Java CAPS currently provides seven options for you to connect to the Sun Java System Application Server using APIs.

CAPSManagementClientFactory Client Usage

Option 1: host, port, userName, password

/** Only relevant piece of code is shown */
ManagementClient client = CAPSManagementClientFactory.getInstance("127.0.0.1", 
                                                              4848, 
                                                              "admin", 
                                                              "adminadmin");
// ... Invoke operations on the returned CAPSManagementClient object ...

Option 2: host, port, userName, password, connectionType

/** Only relevant piece of code is shown */
ManagementClient client = CAPSManagementClientFactory.getInstance("127.0.0.1", 
                                                              4848, 
                                                              "admin", 
                                                              "adminadmin", 
                                                              ConnectionType.HTTP);
// ... Invoke operations on the returned CAPSManagementClient object ...

Option 3: url, userName, password, isRemoteConnection

/** Only relevant piece of code is shown */
ManagementClient client = CAPSManagementClientFactory.getInstance(
       "service:jmx:rmi:///jndi/rmi://localhost:22287/management/rmi-jmx-  connector",
       "admin", "adminadmin", false);
// ... Invoke operations on the returned CAPSManagementClient object ...

Option 4: MBeanServerConnection

/** Only relevant piece of code is shown */
MBeanServerConnection connection = ... // Get the MBeanServerConnection 
ManagementClient client = CAPSManagementClientFactory.getInstance(connection);
// ... Invoke operations on the returned CAPSManagementClient object ...

Option 5: MBeanServerConnection, isRemoteConnection (true/false)

/** Only relevant piece of code is shown */
MBeanServerConnection connection = ... // Get the MBeanServerConnection 
ManagementClient client = CAPSManagementClientFactory.getInstance(connection, true);
// ... Invoke operations on the returned CAPSManagementClient object ...

Option 6: host, port, userName, password, connectionType, promtUserForMasterPassword(true/false)

/** Only relevant piece of code is shown */
ManagementClient client = 
CAPSManagementClientFactory.getInstance("127.0.0.1", 
                                                     8686, 
                                                     "admin", 
                                                     "adminadmin", 
                                                     ConnectionType.JRMP, 
                 


                                             false);
// ... Invoke operations on the returned CAPSManagementClient object ...

Option 7: hostName, portNumber, userName, password, connectionType, keyStoreFileLocation, masterPassword, promptForMasterPassword (true/false)

/** Only relevant piece of code is shown */
ManagementClient client = 
CAPSManagementClientFactory.getInstance
                                                     ("127.0.0.1",
                                                     8686, 
                                                     "admin", 
                                                     "adminadmin", 
                                                     ConnectionType.JRMP,
                                                     "C:/CAPS6/Glassfish/
                                                     domains/domain1/
                                                     config/keystore.jks",
                                                     "changeit", 
                                                     true);
// ... Invoke operations on the returned CAPSManagementClient object ...

Connection Type Definition

public enum ConnectionType {
    HTTP("s1ashttp"), 
    HTTPS("s1ashttps"), 
    JRMP("jmxrmi"), 
    IIOP("iiop");
    
    // ... Implementation ...
    /** @return the protocol */
    public String getProtocol();
    /** @return the protocol description */
    public String getDescription();    
}

CAPSManagementClientFactory Definition

/** Only relevant piece of code is shown */
public class CAPSManagementClientFactory {

    // Option 1 - host, port, userName, password
    public static CAPSManagementClient getInstance(String hostName, int portNumber,
                String userName, String password) throws ManagementRemoteException {
                
        // ... Implementation ...                
    }

    // Option 2 - host, port, userName, password, connectionType 
    public static CAPSManagementClient getInstance(String hostName, int portNumber,
                String userName, String password, ConnectionType connectionType)
                throws ManagementRemoteException {
                
        // ... Implementation ...                
    }
    
    // Option 3 - url, userName, password, isRemoteConnection
    public static CAPSManagementClient getInstance(String url, String userName, 
                String password, boolean isRemoteConnection) throws 
ManagementRemoteException {
                
        // ... Implementation ...                
    }
    

    // Option 4 - MBeanServerConnection
    public static CAPSManagementClient getInstance(MBeanServerConnection connection)
            throws ManagementRemoteException {
            
        // ... Implementation ...                
    }

    // Option 5 - MBeanServerConnection, isRemoteConnection
    public static CAPSManagementClient getInstance(MBeanServerConnection connection, 
                boolean isRemoteConnection) throws ManagementRemoteException {
                
        // ... Implementation ...                
    }

    // Option 6 - host, port, userName, password, connectionType, 
    promtUserForMasterPassword(true/false)
    public static CAPSManagementClient getInstance(String hostName, int portNumber,
            String userName, String password, ConnectionType connectionType,
            boolean promptForPasswordFlag) throws ManagementRemoteException {
                
        // ... Implementation ...                
    }

    // Option 7 - hostName, portNumber, userName, password, connectionType, 
    keyStoreFileLocation, 
    //            masterPassword, promptForMasterPassword (true/false)
    public static CAPSManagementClient getInstance(String hostName, int portNumber,
            String userName, String password, ConnectionType connectionType,
            String trustStoreFilePath, String trustStorePassword,
            boolean promptForPasswordFlag) throws ManagementRemoteException {
                
        // ... Implementation ...                
    }
}

The Java CAPS Management API samples that are pertinent to this topic, such as AdministrationServiceSample.groovy, are included with the delivery as zipped files.

The Alert Management API

With releases 6 the capabilities of the Alert Management Service have been increased to provide more control for the user. The service is now divided into three services:

• Alert Administration Service enables monitoring and control of the alerts stored in the event database in Enterprise Manager

• Alert Configuration Service on the Sun Java System Application Server (SJSAS) provides more control over the persistence of alerts generated in the event management component.

• Alert Notification Service on SJSAS provides more control over the type of alerts that are delivered to a scripting client from the event management component

Persistence on and journaling off means that the removal of events are completed upon delivery to all current clients.

Persistence on and journaling on means there is no removal of the events. Remember, if the removable policy is enabled, the events will removed.

Support for Databases

The Alert Management API supports five databases:

• Derby, which is delivered with the Sun Java System Application Server installation

• Oracle

• Sybase

• DB2

• PointBase

You must start your database prior to using the Java CAPS APIs.

AlertConfigurationService

The AlertConfigurationService enables the Enterpriser Manager and other management clients to manage and control the delivery reliability of alerts from applications or JBI based components to their clients. Enterprise Manager always receives alerts when it is started, while all other clients are required to register in order to receive alerts. The configuration to manage includes the enabling and disabling of the persistence of alerts in the database as well as the policy to manage the deletion of alerts.

Users of earlier releases of Java CAPS must enable persistence and journaling to obtain the functionality to which they are accustomed.

Persisted Alerts Removal Policy

The composite removal policy is defined by controlling three items:

• Alerts Count

  The maximum number of alerts that can be persisted. When this policy is enforced, the oldest-generated alerts are removed.

• Alerts Age

  The maximum amount of time, that is, “age,” that an alert can be persisted.

• Alerts Level

  Every generated alert has one priority level, from low to high, associated with it:

  • INFO

  • WARNING

  • MINOR

  • MAJOR

  • CRITICAL

  • FATAL

  All the alerts that have a lower priority up to the defined level are removed.

The implementation is based upon a “first come first served” policy, as described in the Alert Configuration Service API. The policy is a combination of all the defined policy items, an “and” condition, and is applied even if the result of the executed policy item nullifies the execution of the next policy item.

By default, persistence is set to “not enabled.” If you change the persistence default to “enabled” but journaling is not “on,” you do not need to set the policy. However, if journaling is set to “on,” you can set the policy for Alerts Count, Alerts Age, and Alerts Level.

Alert Configuration Service API

* Enable alerts persistence in the alerts database.
     * enabling it allow for reliable alerts delivery in
     * case of delivery channel failure or Application 
     * server restart.
     *  
     * @param enableJournaling 
     *                    true - will prevent the system from
     *                           removing alerts after they 
     *                           are delivered. The alert stay 
     *                           in the database until the 
     *                           user removes them.
     *                    false - The system will remove the alert
     *                            upon acknowledgment from 
     *                            the reliable client in case one was
     *                            setup or upon send the alert to 
     *                            all the non reliable client/s.
     * @throws ManagementRemoteException if JMX related exception is 
     *         thrown or the list of target name is null or empty.
     */
     public void enableAlertsPersistence(Boolean enableJournaling) throws 
     *        ManagementRemoteException;
    
     /**
     * Disable alerts persistence in the alerts database.
     * 
     * @throws ManagementRemoteException if JMX related exception is 
     *         thrown or the list of target name is null or empty.
     */
     public void disableAlertsPersistence() throws ManagementRemoteException;
      
     
     /**
     * @return the last setting of alert persistence enabling operation.
     *         true if enable otherwise false.
     * @throws ManagementRemoteException if JMX related exception.
     */
     public  Boolean isAlertsPersistenceEnabled()throws 
     * ManagementRemoteException;
    
    /**
     * @return the last setting of alert journal enabling operation.
     *         true if enable otherwise false.
     * @throws ManagementRemoteException if JMX related exception.
     */
    public Boolean isAlertsJournalEnabled()throws ManagementRemoteException;
     
    /**
     * set the JNDI name of the data source database to be used 
     * for persistence. if not provided at least once the persistence 
     * will be disabled even if enableAlertsPersistence was set to true.
     * 
     * @param jndiName - of the data source to be used in conjunction with 
     *   enableAlertsPersistence set to true
    
     * @throws ManagementRemoteException if JMX related exception is 
     *         thrown orjndiName parameter is null or empty.  
     */
    public void setPersistenceDataSourceJndiName(String jndiName) throws 
    * ManagementRemoteException;
    /**
    
     * @return the last set JNDI name for the alert persistence data source.
     * @throws ManagementRemoteException
     */
    public String  getPersistenceDataSourceJndiName() throws ManagementRemoteException;
    
    /**
     * set the database type to be used for persistence.
     * Derby is the assumed default database. If different database is 
     * used this method should be called prior to enabling the persistence.
     * 
    
     * @param dbtype - one of the predefined typed defined in {@link 
     *             com.sun.caps.management.api.alerts.AlertPersistenceDBType}
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public void setPersistenceDataBaseType(AlertPersistenceDBType dbtype) throws 
     *             ManagementRemoteException;
    
    /**
     * @return The return value represent the last set DB type 
     *             {@link com.sun.caps.management.api.alerts.AlertPersistenceDBType}
     *             for each.
     * @throws ManagementRemoteException if JMX related exception is thrown.     */
    public AlertPersistenceDBType  getPersistenceDataBaseType() throws 
    ManagementRemoteException;
    
    /**
     * Set the maximum time a persisted alert will be stored in the alert database 
     * before it will be deleted as part of the removal policy 
     * @param timeToLive - maximum time in millisecond.
     * 
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public void setPersistedAlertsMaxAge(Long timeToLive) throws 
    ManagementRemoteException;
   
    /**
     * return the last setting for the allowed persisted alert age.
     * A value of 0 current time which could cause all persisted alerts to be deleted.
     * A negative value this policy element is ignored.   
     * @return  the returned value  representing as time in milliseconds set for each.
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public Long getPersistedAlertsMaxAge() throws ManagementRemoteException;
   
    /**
     * set the maximum number of  alerts allowed to be persisted  before it will be 
     * deleted as part of the removal policy
     * @param size - Maximum number of alerts.
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public void setPersistedAlertsMaxCount(Long size) throws ManagementRemoteException;
    
    /**
     * return the last setting for the  maximum of  alerts allowed to be persisted.
     * A value of 0 mean no alerts persisted. It behave as if the user 
     *  set enableAlertsPersistence to false
     *   
     * A negative value this policy element is ignored.
     * @return the returned value represent the maximum number of alerts allowed to be 
     *         persisted on each target.
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public Long getPersistedAlertsMaxCount() throws ManagementRemoteException;
    
    /**
     *  The priority based alert level that will be part of the removal policy.
     *  the priorities are as follows (from low to high):
     *  INFO,WARNING,MINOR,MAJOR,CRITICAL,FATAL.
     *  all alerts from the provided level and below will be candidates for removal.
     *  
     * @param level - an AlertLevelType representing the level.
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public void setPersistedAlertsLevel(AlertLevelType level) throws 
    ManagementRemoteException;
    /**
     * @return  the returned value represent the last setting for the level of alerts 
     *          that allowed to be removed from persistence for each target.
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public AlertLevelType getPersistedAlertsLevel() throws ManagementRemoteException;
   
   
    /**
     * set the effective policy for the removal of persisted alerts.
     * @param policyList - an array of AlertRemovalPolicyType where the priority
     *                     of the given policy is defined by its position in the list.
     *                     i.e the lower the index that policy will be applied first.
     *                     possible values are:
     *                     ALERTS_AGE,ALERTS_COUNT,ALERTS_LEVEL.
     *                     
     *                     null value or empty array indicate no policy will be 
     *                     enforced.
    
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public void setPersistedAlertsRemovelPolicy(AlertRemovalPolicyType[] policyList) 
    *          throws ManagementRemoteException;
    
    /**
     * @return the return value representing an array the last setting the policy used 
     *         when persisted alerts are to be removed. An empty array mean no policy 
     *         is enforced.
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public String[] getPersistedAlertsRemovalPolicy() throws ManagementRemoteException;
   
    
    /**
     * enable or disable the ability to use removal policy.
     * @param enableExecuation -  true the current setting is enforced. False the 
     *           current policy is ignored.
    
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public void enablePersistedAlertsPolicyExecution(Boolean enableExecution) throws
    *            ManagementRemoteException;
    
    /**
     * @return the returned value represent the last setting that enable/disable the 
     *         removal policy
     * @throws ManagementRemoteException
     */
    public Boolean isPersistedAlertsPolicyExecutionEnabled()throws 
    *          ManagementRemoteException;
    
    /**
     * set how often the persisted alerts removal policy will be executed.
     * @param excutionInterval - The interval is defined in milliseconds.  
    
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public void setPersistedAlertsRemovelPolicyExecInterval(Long excutionInterval)
    *          throws ManagementRemoteException;
    
    /**
     * @return the returned value representing The last interval setting of 
     *         the persisted alerts removal policy will be executed.
     * @throws ManagementRemoteException if JMX related exception is thrown.
     */
    public Long getPersistedAlertsRemovelPolicyExecInterval() throws 
     *         ManagementRemoteException;
    
    /**
     * Set the persisted alerts table name.
     * Note: if the same database is used across the whole enterprise. it
     *       must be unique for each domain used.  
     * @param tableName - the table name to be used for the stored alerts
     * @throws ManagementRemoteException
     */
    public void setAlertTableName(String tableName) throws ManagementRemoteException;
    
    
    /**
     * @return The current assign persisted alerts table name.
     * @throws ManagementRemoteException
     */
    public String getAlertTableName() throws ManagementRemoteException;
    /**
     * 
     * @return return the total number of alerts currently persisted. This value 
     * is volatile and may V between two sequential calls to this method.
     * @throws ManagementRemoteException
     */
    public  Integer getPersistedAlertsCount() throws ManagementRemoteException;
   
    /**
     * the API allows the caller to set all the parameters defined in the other API in
     * this interface. All the setting are applied prior to enabling the persistence.
     * @param enableJournaling
     *                    true - will prevent the system from removing alerts after 
     *                           they are delivered. The alert stay in the database 
     *                           until the user remove them.
     *                    false - The system will remove the alert upon acknowledgment 
     *                            from the reliable client in case one was setup or 
     *                            upon send the alert to all the non reliable client/s.
     * @param jndiName - JNDI name of the data source database to be used for 
     * persistence.
     * @param dbtype - one of the predefined typed defined in 
     *                    {@link com.sun.caps.management.api.alerts.
     *                     AlertPersistenceDBType}
     * @param timeToLive -  maximum time in millisecond.
     * @param maxCount - Maximum number of alerts.
     * @param level -  an AlertLevelType representing the level.
     * @param policyList - an array of AlertRemovalPolicyType where the priority
     *                     of the given policy is defined by its position in the list.
     *                     i.e the lower the index that policy will be applied first.
     *                     possible values are:
     *                     ALERTS_AGE,ALERTS_COUNT,ALERTS_LEVEL.
     * @param enablePolicyExecution - true the current setting is enforced. False the 
     *         current policy is ignored.
     * @param interval The interval the policy will be executed (is defined in 
     *         milliseconds). 
     * @param inMemoryCacheSize - The interval is defined in milliseconds. 
    
     * @throws ManagementRemoteException if JMX related exception is thrown or 
     *         the list of target names is null or empty.
     */
     public void enableAlertsPersistence(Boolean enableJournaling,String jndiName,
                                         AlertPersistenceDBType dbtype,Long timeToLive,
                                         Long maxCount,AlertLevelType level,
                                         AlertRemovalPolicyType[] policyList,
                                         Boolean enablePolicyExecution,Long interval,
                                         Integer inMemoryCacheSize) throws 
     *                                   ManagementRemoteException;

AlertNotificationService

The Alert Notification Service notifies the client, such as Groovy, of an event. However, for the client to receive notifications it must subscribe using the Alert Notification Service API. There is a noticeable change between prior releases and Release 6 regarding reliable and non-reliable clients. With Release 5.1.x, the client was reliable, meaning that no events could be removed until their delivery was confirmed. With Release 6, a client can be non-reliable, which means there is no guarantee the client will receive every event. In Release 6, the last client set as “reliable” makes all clients before it unreliable.

Alerts Notification Service API

/**
     * request to the event management system to get an events that satisfy the
     * filter provided. The method will validate the call-back object for the 
     * call-back method name and parameter (see below for more information).
     * This method allow the caller to register multiple time with diffrent
     * filtering,target and call-back parameters.
     * 
     * @param filter - the filter that will be applied to the events prior to 
     *                 forwarding them to this client. the valid keys for the map
     *                 are defined in  {@link com.sun.caps.management.api.alerts.
     *                 AlertNotificationFilterElementType}.
     *                 For the ALERTSEVERITY type the valid value are define in
     *                 {@link com.sun.caps.management.api.alerts.AlertLevelType#}.
     *                 
     * @param targetNames - the server instances that is subscription will initially be
     *                      filtered on. if targetNames is/are defined it/they have 
     *                      precedence over the servername element in the filter 
     *                      mentioned above.
     *                  
     * @param CallbackObject an instance of the client object that contain the 
     *                       call back method to be called when event received 
     *                       from the server.
     * @param methodName the method name to be invoke when event received from the 
     *                       server.
     *       IMPORTANT: THE METHOD MUST HAVE ONE PARAMETER OF TYPE 
     *                      {@link com.sun.caps.management.api.alerts.Alert"} ALERT.
     * 
     * @param requireReliableDelivery - true mean this client request that all events 
     *                       should be delivered to him reliably otherwise the client 
     *                       may miss event.
     *       IMPORTANT: THE SYSTEM ALLOW ONLY ONE RELIABLE CLIENT. THE  LAST CLIENT
     *                       TO SET IT TO TRUE TAKES OVER THE RELIABLE DELIVERY. IT 
     *                       WILL AFFECT ALL THE SUBSCRIPTIONS DONE BY THE CLIENT IN 
     *                       THE CURRENT APPLICATION SESSION.
     *                  
     * @param exceptionCallBack an instance of the client object that contain the call 
     *                       back method to be called when an connectivity exception 
     *                       is generated by this service.
     * 
     * @param exceptionMethodName the method name to be invoke when an exception is 
     *                       generated by this service.
     *       IMPORTANT: THE METHOD MUST HAVE ONE PARAMETER OF TYPE 
     *                       {@link java.lang.Exception} EXCEPTION. 
     *       
     *       NOTE: the exception call be should be the same for all subscriptions 
     *                       calls otherwise the last the exception call back 
     *                       defined by the last subscription will be used.
     *     
     * @return Unique identification string that need to be used in the un-subscribe 
     *                       operation.
     *                             
     * @throws ManagementRemoteException 
     *         1. if fail to communicate with the event management system 
     *         2. unable to invoke call back method because of invalid parameter.
     */
    public String subscribe(Map filter,String[] targetName,Object CallbackObject,String
     *          methodName, Boolean requireReliableDelivery,Object exceptionCallBack,
                String exceptionMethodName) throws ManagementRemoteException;
    
    /**
     * request the event management system to stop forwarding events to this client 
     * based on the subscription the caller made using the subscribe method.
     * once all the caller unsubscribe all the IDs any events that are waiting 
     * to be delivered to this client will be discarded.
     * 
     * @param - subscriptionIDs A list of IDs return by the subscribe call/s  that the
     *          caller wish to unsubscribe from.
     *                 
     * @throws ManagementRemoteException if fail to communicate with the Domain server.
     */
    public void unsubscribe(String[] subscriptionIDs) throws ManagementRemoteException;
    
    /**
     * utility method that returns the parameters the client used to subscribe for 
     * alerts for the given subscription ID.
     * 
     * @param - subscriptionIDs list return by the subscribe call/s.
     *          
     * return a map keyed IDs on the provided as a parameter and values as 
     *        SubcriptionInformationinstances.
     *        @see com.sun.caps.management.api.alerts.SubcriptionInformation 
     * @throws ManagementRemoteException if fail to communicate with the Domain server.
     */
    public Map getSubscriptionInformation(String[] subscriptionIDs);

Services — JavaCAPSManagementAPI

Currently there are ten Java CAPS Management Client API services:

• Administration

• Runtime Management

• Configuration

• Deployment

• Installation

• Performance Measurement

• Alert Management

• Alert Administration

• Alert Notification

• Alert Configuration

• JMS Management

• Log Management

• BPEL Management

• Data Management (MDM)

• Sun Adapters Management

• Target Option Behavior for the Management Client

There is also a Target option. It's behavior for the Java CAPS Management Client is also part of Services. Depending upon the values you specify, this option causes the install and deploy commands to behave differently. For details, see Target Option Behavior for the Management Client.

The sample files for the services (for example: AdministrationServiceSample.groovy) and the Target option behavior are zipped, and are included with the Java CAPS 6 delivery.

Administration Service

The Administration Service enables

• Descriptors of component containers, shared libraries, service assemblies, and service units

• Consuming and provisioning endpoints exposed by all component containers

• Operations to retrieve the WSDL and XSD resources associated with each endpoint

Runtime Management Service

The Runtime Management Service:

• Enables lifecycle operations, such as start, stop, and shutdown

• Enables lifecycle operations, such as enable and disable, for Java EE applications

• Provides operations to list component containers, shared libraries, and applications for both JBI and Java EE

Configuration Service

The Configuration Service enables you:

• To configure component containers, the JBI runtime, etc.

• To configure logging for component containers and the JBI runtime

• To manage application configurations and manage application variables

• To verify application configurations before deployment

Deployment Service

The Deployment Service enables you to deploy and un-deploy:

• JBI Service Assemblies

• Java EE artifacts, such as enterprise archives (EAR files), EJB modules, web archives (WAR files), and Java EE connectors, application clients, etc.

Installation Service

The Installation Service enables you to:

• To install and uninstall JBI component containers and shared libraries

• To upgrade component containers without undeploying existing artifacts

Performance Measurement Service

The Performance Measurement Service attempts to address performance characterization for developers and administrators.

• JBI Framework

  • StartTime

  • StartupTime

  • Component count

  • Endpoint count

  • ServiceAssembly count

• Normalized Message Router (NMR)

  • Time spent in each component

  • Time spent in DeliveryChannel

  • Time spent in NMR

  • Per Component/Endpoint

  • Queried by Component/Endpoint

• Component Endpoints

  • UpTime

  • Total sent/received requests, such as “in” messages

  • Total sent/received replies, such as “out” messages

  • Total sent/received faults

  • Total completed exchanges, such as consumed/provided

  • Total active exchanges, such as consumed/provided

  • Total error exchanges, such as consumed/provided

  • Response Time

  • Status Time

  • Active MessageIds

  • Waiting MessageIds

Alert Management Service

Alert Administration Service

Alert Notification Service

Alert Configuration Service

JMS Management Service

Log Management Service

BPEL Management Service

The BPEL Management Service supports two types of API method names:

• Java CAPS (non-JBI based components)

• Java CAPS (JBI based components)

These APIs are in addition to the APIs exposed for BPEL from the configuration service.

Master Data Management (MDM) Service

This API service provides the capability to integrate and manage data and applications in a complex and distributed enterprise business environment, including the following data management products:

• Master Index Studio (formerly eView Studio and Single Patient View)

• Data Integrator (formerly eTL Integrator)

• Data Quality

• Data Services

• Data Migrator

Sun Adapters Management Service

Target Option Behavior for the Management Client

The --target option causes the install and deploy commands to behave differently. Depending upon the option value specified, these differences can be radical.

Two of the target option names are constant: “server” and “domain.” They represent an instance of an operator and are replaceable with a name specific to the current template.

Writing Java Code to Access APIs Using Java Code Samples

Use the Java code samples to write your own Java Code to access the APIs. The samples are included with the software delivery as zipped files.

When the Alert Management Subsystem receives alerts it sends them to subscribers, such as Enterprise Manager or Groovy. There are two ways the process works.

• When persistence is not turned on alerts are sent directly to all subscribers that use the client API. If there are no subscribers the alerts are dropped.

• When persistence is turned on alerts are sent to a database. If there are no subscribers the alerts are persisted in the database until subscribers are ready to consume them. Optionally, you can enable journaling, which ensures that the alerts are never deleted.

Setting Up Databases

Derby is the database that ships with Java CAPS. However, you can set up and use another database. But remember, you are limited to using a database that Java CAPS supports.

• Derby

• Oracle

• Sybase

• DB2

• PointBase

As an option to the following procedure, you could replace steps 4-6 by using the Alert Configuration Management API to write a groovy script or small Java utility. For an example of this see the JavaCAPS6/ESB_API_KIT/samples directory, if JavaCAPS6 is the directory where you extracted EM_API_KIT.zip.

Remember that the last command you script or program and then execute should be enabling persistence in the specified database. Examples of methods from the Alert Configuration Service API are setPersistenceDataSourceJndiName, getPersistenceDataSourceJndiName, setPersistenceDataBaseType, getPersistenceDataBaseType, and optionally setAlertTableName.

In case the database has a limit to the table name, for example Oracle is limited to 30 characters, the auto-generated table may exceed that limit. Use the Alert Configuration API (SetAlertTableName) to set the table name. Keep in mind that each domain must have unique table name to prevent events from one domain appearing in another domain.

To Set Up a Database Using Enterprise Manager

1. Start the domain you want to use.

2. Use the Sun Java System Application Server Admin Console or AS Admin command-line utility to set up a connection pool and resource.

   ---

   Note –

   Record the name you assign to the resource name.

   ---

   For detailed instructions on how to perform this task see Admin Console online help.

3. Start the selected database.

4. Start Enterprise Manager and add the domain you started in step 1.

5. Launch the Alert Configuration screen (for information see Monitoring Java EE Components).

   1. Select the database type that matches the database you selected.

   2. Enter the JNDI name.

      ---

      Note –

      This is the resource name you created in step 2.

      ---

6. Enable persistence and journaling, and then click Save to commit the changes.

   ---

   Note –

   When you enable persistence you do not have to enable journaling; that is, journaling is optional when persistence is enabled.

   ---

To Set Up a Database Using a Scripting Utility

1. Start the domain you want to use.

2. Use the Sun Java System Application Server Admin Console or AS Admin command-line utility to set up a connection pool and resource.

   ---

   Note –

   Record the name you assign to the resource name.

   ---

   For detailed instructions on how to perform this task see Admin Console online help.

3. Start the selected database.

4. Write a scripting utility to call the appropriate APIs.

   setPersistenceDataSourceJndiName

   setPersistenceDataBaseType(AlertPersistenceDBType dbtype)

   (Optional) setAlertTableName(String tableName)

   enableAlertsPersistence(Boolean enableJournaling)

   Or, optionally, to execute all of the above APIs, use:

   enableAlertsPersistence(Boolean enableJournaling,String jndiName,
                                       AlertPersistenceDBType dbtype,Long timeToLive,
                                       Long maxCount,AlertLevelType level,
                                       AlertRemovalPolicyType[] policyList,
                                       Boolean enablePolicyExecution,Long interval,
                                       Integer inMemoryCacheSize) throws
   *                                   ManagementRemoteException;

   ---

   Note –

   The order here is not set and can be altered except for enabling persistence, which must be last.

   ---

Using Oracle and Other Databases for Alert Persistence

Oracle, and the other supported databases besides Derby, are also capable performing alert persistence. However, there a number of changes you must perform to get it to work.

If you plan to use Oracle instead of Derby for alert persistence, make sure you read this topic.

To Set Up an Oracle Database for Alert Persistence

1. Modify the eventmanagement.properties file under appserver/domains/domain1/jbi/config.

   1. Modify the DatabaseType to ORACLE.

   2. Change the AlertTablename to EMHOSTNAMEVistastccom8080.

      ---

      Note –

      This step is required as the default name, EVENTMANAGEMENTHOSTNAMEistastccom8080, exceeded Oracle's 30-character limit for table names.

      ---

   3. Change the DBJndiName to OracleXPDB.

      ---

      Note –

      You create this in the Admin Console; this is noted in step 2.

      ---

   4. Change PersistenceEnbled to true.

   5. Using Enterprise Manager, set the values for DatabaseType, DBJndiName, and PersistenceEnabled in the normal Alert Management Config Agent.

      ---

      Note –

      The database scripts should probably be run before enabling persistence. The table name must be changed in the file manually.

      ---

2. Create the JDBC connection pool and resource in the Sun Java System Application Server Admin Console.

   1. Add the location of classes12.zip to the classpath, JVM Settings->Path Settings->Classpath Suffix, and then restart the domain.

      ---

      Note –

      This is needed to get the datasource for Oracle.

      ---

   2. Create the Connection Pool for Oracle.

      1. Enter a name, such as OracleXPPool, but this name can be your choice.

      2. Select javax.sql.DataSource for the Resource Type.

      3. Select Oracle for the Database Vendor.

      4. Set the appropriate properties:

         1. User: eventdb_user

         2. DatabaseName: orcl

            ---

            Note –

            This and other database specific configurations may change depending on how you configured the Oracle database.

            ---

         3. Password: eventdb_user

         4. ServerName: hostname

            ---

            Note –

            This is the server where the database is running.

            ---

         5. PortNumber: 1521

         6. URL: jdbc:oracle:thin:@hostname:1521:orcl

            ---

            Caution –

            This URL may actually override the other settings; it should match the other settings.

            ---

      5. Create the JDBC Resource.

         1. Enter a JNDI Name, for example OracleXPDB.

            ---

            Note –

            This should match what is set in the Alert Management Config Agent/eventmanagement.properties file mentioned above.

            ---

         2. Select the appropriate Pool Name; in our example we used OracleXPPool.

3. Create the user, tables, etc. needed for alert persistence and journaling manually.

   ---

   Note –

   This is automatically done for Derby.

   ---

   There are database scripts that are packaged in the jbi_rt.jar file under appserver/jbi/lib. However there are some errors, so you need to be correct these scripts manually.

   • The example scripts have been modified to work with an Oracle 10 GB database; see Oracle Script Examples.

   • Run the create_event_store_user.sql and create_event_store_schema.sql scripts, in that order, with the system (admin) user.

   • Corrections made in this example:

     • Set the absolute path to tablespace data files (database installation dependent)

     • Modify the command to match Business Process persistence

     • Comment out the second data file

     • Move the comments

     • Fix the table name references to match user schema and table name, which were set above in eventmanagement.properties

     • Fix the column reference; that is, change the second column name from event_timestamp to timestamp

     • Change the datatype from timestamp to decimal

     • Fix the reference for sequence

Oracle Script Examples

truncate_event_store_schema.sql

TRUNCATE TABLE eventdb_user.EMHostNameVistastccom8080;

create_event_store_schema.sql

create table eventdb_user.EMHostNameVistastccom8080(
  	id NUMBER CONSTRAINT ID_PK PRIMARY KEY, 
			timeStamp decimal,
 		physicalHostName varchar(256),
			environmentName varchar(256),
			logicalHostName varchar(256),
			serverType varchar(256), 
			serverName varchar(256), 
			componentType varchar(256),
			componentProjectPathName varchar(1024),
			componentName varchar(256),
			eventType varchar(256),
			severity integer,
			operationalState int,
			messageCode varchar(256),
			messageDetail varchar(4000),
			observationalState int,
			deploymentName varchar(256));
);
-- INSERT statement need to use it to insure autoincrement functionality
CREATE SEQUENCE eventdb_user.autoincrement_id; 
create index  eventTime on eventdb_user.EMHostNameVistastccom8080(timeStamp);

create_event_store_user.sql

--Create a tablespace named EVENTDB_USER_DB. Change this value if a different 
name is desired.
--Specify the name and the location of the file where the data related to
the tablespace 
--created above will be stored. The location is by default the location determined by
--the database server/instance on which this script is run
--For example, for Windows c:\MyDatafiles\EVENTDB_USER_DB.dat, for Unix
/dev/home1/EVENTDB_USER_DB.dat
--Note that the name of the actual file need not be EVENTDB_USER_DB.dat
--Specify the size constraints

	-- Window and Oracle 9i there is a limitation on file size, it is 2 GB. 
This by default creats 4GB, add more files if you need more than 4 GB.
	--- provide abosolute path if you preference is not default location 
'C:\OracleDirectory\EVENTDB_USER_DB.dat' SIZE 2000M,

CREATE TABLESPACE EM_EVENTSTORE_DB
 DATAFILE
	'C:\oracle\product\10.2.0\oradata\orcl\EVENTDB_USER_DB.dat' SIZE 512M REUSE 
AUTOEXTEND ON NEXT 2048M MAXSIZE UNLIMITED;

	-- 'C:\oracle\product\10.2.0\oradata\orcl\EVENTDB_USER_DB1.dat' SIZE 512M 
REUSE AUTOEXTEND ON NEXT 2048M MAXSIZE UNLIMITED --- provide abosolute path 
if you preference is not defaultlocation 'C:\OracleDirectory\EVENTDB_USER_DB1.dat' 
SIZE 2000M
        -- when TABLESPACE is created with these options performance is degrading 
gradually as more and more records added to schema  EXTENT MANAGEMENT LOCAL SEGMENT 
SPACE MANAGEMENT AUTO


--Create a new user EVENTDB_USER. Change the name if so desired. Password will 
be same as
--the user name by default. This username and password will be used to create the 
--connection pool on the application server. Also specify the tablespace 
and the quota on
--the tablespace the user has. Note that if you used a different tablespace 
name above,
--you will have to specify that tablespace name here.

CREATE USER EVENTDB_USER IDENTIFIED BY EVENTDB_USER
DEFAULT TABLESPACE EM_EVENTSTORE_DB
QUOTA UNLIMITED ON EM_EVENTSTORE_DB
TEMPORARY TABLESPACE temp
QUOTA 0M ON system;

--Modify the user name if the default user name was changed

GRANT CREATE session to EVENTDB_USER;
GRANT CREATE table to EVENTDB_USER;
GRANT CREATE procedure to EVENTDB_USER;

drop_event_store_schema.sql

DROP TABLE eventdb_user.EMHostNameVistastccom8080;
drop sequence eventdb_user.autoincrement_id;

drop_event_store_user.sql

--Drop the user that was created earlier. Note that if you chose a 
different name for the 
--user while creating the user, you will have to specify that name here.
DROP USER EVENTDB_USER CASCADE;

--Drop the tablespace that was created earlier. Note that if you chose a 
different name for 
--the tablespace while creating the user, you will have to specify that name here.
DROP TABLESPACE EM_EVENTSTORE_DB INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS;

--Manually delete the datafiles that were created. If you used the defaults 
while creating
--the datafiles, the names would be EVENTDB_USER_DB1.dat'and 'EVENTDB_USER_DB2.dat'

Setting Up Scripting Engines

The Java CAPS Management and Monitoring API should be callable from any JSR-223 Scripting Environment. This section documents how to set up these scripting engines like Groovy, JRuby, Jython (Java Python), JACL (Java TCL) or one of the 25 other JSR-223 scripting engines capable of calling the Java CAPS Management and Monitoring APIs that are currently available . You can use these instructions to setup your own environment to invoke these APIs from the JSR-223 Scripting Environment of your choice.

Downloading, Installing, and Setting Up A Scripting Environment

For the purposes of this topic, we will focus on four scripting engines:

• Groovy: The Java CAPS Management and Monitoring API has been tested and works with Groovy 1.0, Groovy 1.1 beta 1, and with the latest Groovy 1.1 beta 2. Use the installation instructions that are available to install the engine, and ensure that it runs properly. Download Groovy from http://groovy.codehaus.org/.

• JRuby: The Java CAPS Management and Monitoring API has been tested and works with JRuby 1.0 and with the latest JRuby 1.0.1. Use the installation instructions that are available to install the engine, and ensure that it runs properly. Download JRuby from http://jruby.codehaus.org/.

• Jython (Java Python): The Java CAPS Management and Monitoring API has been tested and works with Jython 2.2 RC1 and with the latest Jython 2.2. Use the installation instructions that are available to install the engine, and ensure that it runs properly. Download Jython from http://www.jython.org/Project/index.html.

• JACL (Java TCL): The Java CAPS Management and Monitoring API has been tested and works with the latest JACL 1.4.0. Use the installation instructions that are available to install the engine, and ensure that it runs properly. You may have to modify jaclsh.bat in the bin folder as described in the readme.txt file that is included with the download. My bin/jaclsh.bat looks like this after modification. Download JACL from http://tcljava.sourceforge.net/docs/website/index.html.

The sample files for the services (for example: AdministrationServiceSample.groovy) and the Target option behavior are zipped, and are included with the Java CAPS 6 delivery.

Setting Up a Scripting Environment to Invoke Java CAPS Management and Monitoring APIs

There are two files that are necessary before you set up your scripting environment to invoke Java CAPS Management and Monitoring APIs:

• env.bat

• caps.management.client.jar

These files are included with the Java CAPS delivery.

After downloading env.bat and caps.management.client.jar, modify the environment variables in env.bat.

To modify environment variables, click To Modify the Environment Variables in env.bat.

To Modify the Environment Variables in env.bat

1. Set the JAVA_HOME variable to the JDK/JRE Home folder where your JDK or JRE is installed.

   For example: set JAVA_HOME=C:\java\jdk1.6.0.

2. Set the SJSAS_HOME variable to the SJSAS Home folder where your Sun Java System Application Server is installed.

   For example: set SJSAS_HOME=C:\CAPS6\SJSAS.

3. Set the CAPS_MANAGEMENT_HOME variable to the folder where you saved the Java CAPS Management and Monitoring API Java archive file locally.

   For example: set CAPS_MANAGEMENT_HOME=C:\scripting\engines\common.

4. Set the ENGINE_HOME variable to your Scripting Engine Home folder where your scripting engine is installed.

   For example: set ENGINE_HOME=C:\scripting\engines\groovy\groovy-1.1-beta-2.

   ---

   Note –

   You are now ready to run the scripting samples.

   ---

Using a Scripting Language to Exercise the Java CAPS Management and Monitoring APIs

Before running the scripting samples, it is assumed that you installed one of the scripting engines.

• Groovy (located at C:\scripting\engines\groovy\groovy-1.1-beta-2)

• JRuby (located at C:\scripting\engines\jruby\jruby-1.0.1)

• Jython (located at C:\scripting\engines\jython\jython2.2)

• JACL (located at C:\scripting\engines\jacl\jacl140)

It is also assumed that the Sun Java System Application Server is running with the following settings:

If your environment is different, change the following steps or the scripts according to your environment or installation.

Currently Sun supports these services:

• Administration Service

• Configuration Service

• Deployment Service

• Installation Service

• Runtime Management Service

Additional services will be supported in the future.

Exercising the Administration Service

Before you can exercise the Administration Service, you must have the following installed, and/or deployed, in your environment:

• A binding component named sun-http-binding

• A shared library named sun-wsdl-library

• A service assembly named SynchronousSampleApplication, which contains a service unit named SynchronousSampleApplication-SynchronousSample

  ---

  Tip –

  You must create the SynchronousSampleApplication from NetBeans, deploy it, and start it before you run the Administration Service scripts.

  ---

  ---

  Note –

  Change the script as you see fit to run in your environment.

  ---

Exercising the Administration Service in Groovy

The Groovy script for executing the Administration Service is attached in AdministrationServiceTest.groovy. Modify the script to suit your needs before executing it in your environment/installation.

cd C:\JavaCAPS6\managementapienv.batcd scripting\groovy\scripts\groovy ServiceTest\AdministrationServiceTest.groovy

If you are comfortable with the Swing-based groovyConsole, use it to load and execute the script file.

cd C:\scripting\groovy\scripts\env.batgroovyConsole

Exercising the Configuration Service

Before you can exercise the Configuration Service, you must have the following installed in your environment:

• A binding component named sun-http-binding

• A service engine named sun-bpel-engine

  ---

  Note –

  Change the script as you see fit to run in your environment.

  ---

Exercising the Configuration Service in Groovy

The Groovy script for executing the Configuration Service is attached in AdministrationServiceTest.groovy. Modify the script to suit your needs before executing it in your environment/installation.

cd C:\JavaCAPS6\managementapienv.batcd scripting\groovy\scripts\groovy ServiceTest\ConfigurationServiceTest.groovy

If you are comfortable with the Swing-based groovyConsole, use it to load and execute the script file.

cd C:\scripting\groovy\scripts\env.batgroovyConsole

Exercising the Deployment Service

The deployment service tries to deploy a Service Assembly named SynchronousSampleApplication. Before you run the Deployment Service scripts, from NetBeans you must first create a SynchronousSampleApplication, deploy it, and start it. Change the script as you see fit to run in your environment.

Exercising the Deployment Service in Groovy

The Groovy script for executing the Deployment Service is attached in DeploymentServiceTest.groovy. Modify the script to suit your needs before executing it in your environment/installation.

cd C:\JavaCAPS6\managementapienv.batcd scripting\groovy\scripts\groovy ServiceTest\DeploymentServiceTest.groovy

If you are comfortable with the Swing-based groovyConsole, use it to load and execute the script file.

cd C:\scripting\groovy\scripts\env.batgroovyConsole

Exercising the Installation Service

Before you can exercise the Installation Service, you must have aspectserviceengine.jar installed in your environment.

Read the following carefully.

1. A service engine named sun-aspect-engine attempts to stop, shutdown, and uninstall itself.

2. The service engine then attempts to install sun-aspect-engine from the attached aspectserviceengine.jar.

3. Before you run the Installation Service sample scripts, install aspectserviceengine.jar in your environment and start it.

4. Change the script as you see fit to run in your environment.

Exercising the Installation Service in Groovy

The Groovy script for executing the Installation Service is attached in InstallationServiceTest.groovy. Modify the script to suit your needs before executing it in your environment/installation.

cd C:\JavaCAPS6\managementapienv.batcd scripting\groovy\scripts\groovy ServiceTest\InstallationServiceTest.groovy

If you are comfortable with the Swing-based groovyConsole, use it to load and execute the script file.

cd C:\scripting\groovy\scripts\env.batgroovyConsole

Exercising the Runtime Management Service

Before you can exercise the Runtime Management Service, you must have the following installed and deployed in your environment:

• A service engine named sun-bpel-engine

• A service assembly named SynchronousSampleApplication, which you created from NetBeans.

  ---

  Note –

  Change the script as you see fit to run in your environment.

  ---

Exercising the Runtime Management Service in Groovy

The Groovy script for executing the Runtime Management Service is attached in RuntimeManagmentServiceTest.groovy. Modify the script to suit your needs before executing it in your environment/installation.

cd C:\JavaCAPS6\managementapienv.batcd scripting\groovy\scripts\groovy ServiceTest\RuntimeManagementServiceTest.groovy

If you are comfortable with the Swing-based groovyConsole, use it to load and execute the script file.

cd C:\scripting\groovy\scripts\env.batgroovyConsole

Exercising the JMS Management Service

Before you can exercise the JMS Management Service, you must have first installed the Sun JMS IQ Manager from the Java CAPS 6 Installer and deployed it in your environment:

The Java CAPS Installer, by default, allows you to install Sun JMS IQ Manager during the installation process. However, you can install Sun JMS IQ Manager at any time after you have installed Java CAPS 6.

Exercising the JMS Management Service in Groovy

The Groovy script for executing the JMS Management Service is attached in JMSManagmentServiceTest.groovy. Modify the script to suit your needs before executing it in your environment/installation.

cd C:\JavaCAPS6\managementapienv.batcd scripting\groovy\scripts\groovy ServiceTest\JMSManagementServiceTest.groovy

If you are comfortable with the Swing-based groovyConsole, use it to load and execute the script file.

cd C:\scripting\groovy\scripts\env.batgroovyConsole

Exercising the BPEL Management Service

Before you can exercise the BPEL Management Service, you must ensure:

• That monitoring is enabled for your BPEL Service Engine

• That a service engine named sun-bpel-engine has been installed and deployed in your environment

  ---

  Note –

  Change the script as you see fit to run in your environment.

  ---

Exercising the BPEL Management Service in Groovy

The Groovy script for executing the BPEL Management Service is attached in BPELManagmentServiceTest.groovy. Modify the script to suit your needs before executing it in your environment/installation.

cd C:\JavaCAPS6\managementapienv.batcd scripting\groovy\scripts\groovy ServiceTest\BPELManagementServiceTest.groovy

If you are comfortable with the Swing-based groovyConsole, use it to load and execute the script file.

cd C:\scripting\groovy\scripts\env.batgroovyConsole

Exercising the HTTP Administration Service

Before you can exercise the HTTP Administration Service, you must have the following installed and deployed in your environment:

• A binding component named sun-http-binding

• A Service Assembly with some HTTP consuming endpoint(s)

  ---

  Note –

  Change the script as you see fit to run in your environment.

  ---

Exercising the HTTP Administration Service in Groovy

The Groovy script for executing the HTTP Administration Service is attached in HTTPAdiministrationServiceTest.groovy. Modify the script to suit your needs before executing it in your environment/installation.

cd C:\JavaCAPS6\managementapienv.batcd scripting\groovy\scripts\groovy ServiceTest\HTTPAdministrationServiceTest.groovy

If you are comfortable with the Swing-based groovyConsole, use it to load and execute the script file.

cd C:\scripting\groovy\scripts\env.batgroovyConsole

Exercising the Notification Service

For Notification Service test, there are no prerequisites except that the AppServer is up and running. When any lifecycle changes happen in the JBI runtime, the Notification Service sends these notifications to all subscribed clients.

Change the script as you see fit to run in your environment.

Exercising the Notification Service in Groovy

The Groovy script for executing the Notification Service is attached in NotificationServiceTest.groovy. Modify the script to suit your needs before executing it in your environment/installation.

cd C:\JavaCAPS6\managementapienv.batcd scripting\groovy\scripts\groovy ServiceTest\NotificationServiceTest.groovy

If you are comfortable with the Swing-based groovyConsole, use it to load and execute the script file.

cd C:\scripting\groovy\scripts\env.batgroovyConsole

JRuby Integrated into NetBeans IDE

If you have the latest version of NetBeans IDE 6.0, you can create your own JRuby Project, and execute the JRuby samples (they have “rb” extensions) from within the NetBeans IDE.

Java CAPS 6 delivered with NetBeans IDE 6.1 ML.

To Create a JRuby Project

1. Create a new JRuby project.

2. Copy the JRuby scripting files into the project.

3. Right-click and open the Project Properties tab and provide the appropriate jar files for the project to use.

4. Start the Sun Java System Application Server.

5. Open a script file in NetBeans, right-click on the source, and then click Run File to run the script.