Skip navigation.

eDocs Home > BEA Extension SDK for WebLogic Network Gatekeeper 2.1 Documentation > Extension SDK for BEA WebLogic Network Gatekeeper > Creating an example ESPA Service Capability module

Extension SDK for BEA WebLogic Network Gatekeeper

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Creating an example ESPA Service Capability module

The following section provides a description on how to create an example ESPA service capability module:

The example ESPA service capability will use the interfaces defined for the example network plug-in prepared in Creating an example network plug-in. The ESPA service capability has the following properties:

 

General preparations

This is general preparations.

  1. Make sure the files for the service capability and the service capability interfaces are copied to the directory exampleproj. That is, all files and directories in module_templates\espa_sc_impl and module_templates\espa_sc_if.
  2. Change directory to bea\wlng21\esdk\build and issue the command ant

 

Preparing the ESPA service capability interface

Set up the build environment

  1. Edit the file exampleproj\espa_sc_if\build.xml.

Edit the properties described in Adapting the build files for the modules on page 15-40 to reflect the desired names.

Define the ESPA service capability module interface structure

  1. In the file exampleproj\espa_sc_if\idl\MyServiceCapability_if.idl, change the interface structure to reflect the desired package structure. For example, the structure:
    2. module com {
       module acompany {
          module espa {
             module mysctype {

    This will create the ESPA service capability interface structure com.acompany.espa.mysctype

Interfaces to the ESPA service capability module

  1. Add or change additional methods to be used in the interface between the SESPA service capability and the ESPA Service Capability. Use the definitions in exampleproj\espa_sc_if\idl\MyServiceCapability_if.idl as templates.

In the template file, the method myMethod is an example of how to define an asynchronous method invoked by an application on the ESPA service capability.

  1. Edit the service name (used as ESPA service capability type) to the desired type, change the definition of SERVICE_NAME

    2. The service name is used as ESPA service capability type when registering the ESPA service capability in the SC manager. It is also used as in the SLAs in the <scs> tag.

 

Compilation of the ESPA service capability module interface

  1. Compile the ESPA service capability interface by changing directory to exampleproj\espa_sc_module_if\build\ and execute the command ant

    2. This compiles the ESPA service capability interface and generates Java stubs from the IDL interface.

 

Preparing the ESPA service capability module implementation

Set up the build environment

  1. Edit the file exampleproj\espa_sc_impl\build.xml.

    2. Edit the properties described in Adapting the build files for the modules on page 15-40 reflect the desired names.

    Note: Always use a prefix in the jar name. The autostarted SLEE services are started in alphabetic order based on the jar name. All Service Capabilities should have a prefix so they are started after the network protocol plug-ins but before the SESPA modules.

Defining the OAM methods

  1. Edit the files exampleproj\espa_sc_impl\MyServiceCapabilityOAM.idl. Define any additional OAM methods.

ESPA service capability module plug-in listener interface implementation

The plug-in interface implementation has to be updated with any changes to the plug-in interface defined in Interfaces in the plug-in.

  1. Open the file implementing the call-back interface from the plug-in, MyPluginListener_impl.java in exampleproj\spa_sc_impl\src\com\acompany\espa\mysctype\
  2. Adapt the import statement for the plug-in interfaces if there has been any changes.
  3. Adapt the name of the class that the extends the listener, the name of the class is the same as as the classname for the callback interface, with the addition POA, for example:

    4. public class MyPluginListener_impl extends com.my_company.my_plugin.MyPluginListenerPOA

  4. Adapt the method names if there have been any changes or additions.

ESPA service capability module service manager implementation

The interface has to be updated so it implements the MyServiceCapabilityManager interface as defined in Interfaces to the ESPA service capability module.

  1. Open the file MyServiceCapabilityManager_impl.java in exampleproj\espa_sc_impl\src\com\acompany\espa\mysctype
  2. Adapt the import statement for the plug-in interfaces if there have been any changes to them.
  3. In the doTask method, change the line:
    4. MyPlugin myPlugin = MyPluginHelper.narrow(resource)

    to reflect any changes in names.

  4. Adapt the method names to reflect the names in the interface definitions.

ESPA service capability module persistent storage

  1. Open the file MyServiceCapabilityPersistentStorage.java in exampleproj\espa_sc_impl\src\com\acompany\espa\mysctype.
  2. Edit the database table names, by changing GLOBAL_CONFIG_TABLE, LOCAL_CONFIG_TABLE, and ESPA_MYSERVICECAPABILITY_REQUEST_TIMEOUT_EVENT to a name for the tables holding persistent data.

ESPA service capability module context

  1. Open the file MyServiceCapabilityContext.java in exampleproj\espa_sc_impl\src\com\acompany\espa\mysctype.
  2. Change POLICY_SERVICE_NAME to a value that will be used to identify which Service Capability the Policy request originates from.
  3. Change PLUGIN_TYPE to a value that will be used to identify which plug-in the Service Capability will connect to. This is the same type as the plug-in registered itself as, see Plug-in type definition on page 16-6.

 

Implement the Policy Enforcement Point

The Policy Enforcement Point (PEP) in the example ESPA module resides in MyServiceCapabilityManager_impl.java, in the method myMethodInternal().

The service name is fetched from MyServiceCapabilityContext.POLICY_SERVICE_NAME.

The data that is to be accessible from rules executing at this PEP must be passed in the policy request. These reside in the additionalParameters of the PolicyRequest class.

Each data parameter is contained in an AdditionalData class, containing one AdditionalDataValue class and a data name which is an arbitrary string. The example code in the template shows how strings are used as additional data, but the AdditionalData class also supports the following data types:

It is up to the rule implementation to extract additional values according to their defined data types. The PEP implementation must also extract any modified data returned in the modified policy request (modifiedRequest in the example code).

 

Compilation of the ESPA service capability module implementation

Prior to this, the plug-in interface and the ESPA service capability module interface must have been built.

  1. Compile the ESPA service capability module implementation by changing directory to exampleproj\espa_sc_module_impl and execute the command ant

 

Adapting the policy rules

  1. Open the files:
    2. exampleproj\policy\rules\app\ESPA_myservicecapability.ilr
    exampleproj\policy\rules\sp\ESPA_myservicecapability.ilr
  2. Depending on the policy implementation (the PEP) the two rules listed under the heading START_APP_My_Service_Capability_Specific_Rules and START_SP_My_Service_Capability_Specific_Rules might have to be changed.

    3. If the data format has been changed, the parameter

    ?dataString: getAdditionalDataStringValue has to be updated accordingly.

    If the method name has been changed in the policy implementation, see Implement the Policy Enforcement Point, the parameter ?methodName.equals has to be updated.

 

Installing the ESPA service capability module

This section describes how to install and deploy the ESPA service capability module that was created using the instructions in this section. For instructions on how to use the Management Tool and how to register an ESPA service capability module in more detail, see WebLogic Network Gatekeeper User's Guide.

  1. Make sure you have access (by ftp directly to the file system) to the SLEE in that the ESPA service capability module shall be installed in.
  2. Open the Management Tool and select the SLEE in which to install the ESPA service capability module.
  3. In the Management tool, select the SCS_Manager service, and invoke the method addType. Use the type defined for the ESPA service capability.

    4. In the example, the SCS type is MY_SCS_TYPE. This is defined in the plug-in interface definition file, my_plug_in_if.idl in the constant MY_SCS_TYPE.

  4. In the SLEE_deployment service, select install. Enter the URL to the jar-file in the field ServiceJarURL and click Invoke.

    5. In the example, the path and file name is file:///<drive>/exampleproj/espa_sc_module_impl/lib and the name was defined in the build file property local.jarName.

    Note: On Windows systems, use three (3) slashes prior to the disk name.

  5. In the SLEE_deployment service, select start. Enter the SLEE name for the ESPA service capability module. Click Invoke.

    6. The name was defined in the build file property local.deployName.

  6. In the SLEE_deployment service, select activate. Enter the SLEE name for the ESPA service capability module. Click Invoke.

 

Update Service Level Agreements (SLAs)

Any application and service provider using the newly created ESPA service capability need to have valid SLAs for the new ESPA service capability. The SLA-files need to be updated with service contracts for the ESPA service capability. For information on how to write the SLA-files, see WebLogic Network Gatekeeper User's Guide.

The SC name (entered in the <scs></scs> tag) is the name defined as service name in Step 6. on page 3.

 

Install policy rules

In order to enforce the SLA, load the policy rules defined in Adapting the policy rules into Network Gatekeeper.

  1. In the Policy service, select loadApplicationRules. Enter the URL to the application rule irl-file in the field irlUrl and the service name in the serviceName field. Click Invoke.

    2. In the example, the path and file name is file:///<drive>/exampleproj/policy/rules/app/ESPA_myservicecapability.ilr

    The service name is the name defined in Step 6. on page 3.

    Note: On Windows systems, use three (3) slashes prior to the disk name.

  2. In the Policy service, select loadServiceProviderRules. Enter the URL to the service provider rule irl-file in the field irlUrl and the service name in the serviceName field. Click Invoke.

    3. In the example, the path and file name is file:///<drive>/exampleproj/policy/rules/sp/ESPA_myservicecapability.ilr

 

Skip navigation bar  Back to Top Previous Next