System Administrator’s Guide

Managing and Configuring the Plug-in Manager

The following section describes configuration and maintenance attributes and operations for the Plug-in manager. It also provides a workflow for the configuration:

Introduction

Network protocol plug-ins consist of two parts: the plug-in service and the plug-in instance.The plug-in service is the deployable and updatable unit. It does not itself process any traffic. Plug-in instances are instantiated from a plug-in service. One plug-in service can be the base for many plug-in instances.

A plug-in service:

A plug-in instance:

Plug-in instances are created using the Plug-in Manager MBean.

The plug-in manager introspects the plug-in north interfaces, methods, and names of any arguments. This is useful when creating up service provider group and application group SLAs.

Execution and evaluation flow

Application-initiated requests

When an application’s request is processed, it is routed to the network protocol plug-in instance via the plug-in manager. The plug-in manager triggers a chain of service interceptors, where the request is evaluated and a given plug-in instance is selected based on:

Once the decision has been made, the request is forwarded to the selected plug-in.

Routes are configured in the Plug-in manager via OAM operations, and are used by the service interceptors.

Refer to the section in this guide for each communication service for the plug-in service ID and plug-in type under which individual plug-ins are registered.

The following interceptors are use data configured using the plug-in manager:

Network triggered Requests

When a request is triggered from the network, the plug-in manager is also part of the request flow, and is responsible for invoking the chain of service interceptors.

How address ranges are specified when setting up routes

Address ranges are specified using UNIX regular expressions. A few examples are given below:

In the examples:

The address scheme can be included in the expression. If not specified, any scheme will match. Examples

Configuration Workflow

Configuring the plug-in manager can be divided into:

Configuring the Plug-in Manager

Below is an outline for configuring the plug-in manager:

Creating a Plug-in instance

Below is an outline for creating an instance of a plug-in service:

Administration of Plug-in Routes and Node IDs

The administration of routes uses the following operations:

Reference: Attributes and Operations for PluginManager

Managed object: Container ServicesPluginManager

MBean: com.bea.wlcp.wlng.plugin.PluginManagerMBean

Below is a list of attributes and operations for configuration and maintenance:

Attribute: ForceConnectInResuming

Scope: Cluster

Unit: n/a

Format: Boolean

Specifies if a network protocol plug-in service is allowed to transition to state ACTIVE if it fails to establish a connection with the underlying network node during deployment or re-deployment. This assures that a new version of the network protocol plug-in service is activated only when it is certain that it can accept traffic.

If enabled, all plug-ins services packaged in the EAR that is being updated must become active before any traffic is routed to the plug-in instances derived from the new version. If any plug-in instance fails to connect to the underlying network, the new version does not become active.

Use:

Attribute: PolicyBasedRouting

Scope: Cluster

Unit: n/a

Format: Boolean

Specifies whether policy based routing should be used.

Use:

Operation: addRoute

Scope: Cluster

Adds a new plug-in route. A route is identified by the plug-in instance ID and a match pattern.

Signature:

addRoute(PluginInstanceId: String, AddressExpression: String)

Operation: createPluginInstance

Scope: Cluster

Creates a new instance of a specific plug-in service.

Signature:

createPluginInstance(PluginServiceId: String, PluginInstanceId: String)

Operation: destroyPluginInstance

Scope: Cluster

Destroys an instance of a specific plug-in instance. All routes associated with the instance are kept.

Signature:

destroyPluginInstance(PluginServiceId: String, PluginInstanceId: String)

Operation: getPluginInstanceInfo

Scope: Cluster

Gets information about a specific plug-in instance. The information includes:

Signature:

getPluginInstanceInfo(PluginInstanceId: String)

Operation: getPluginNodeId

Scope: Cluster

Displays which plug-in node ID a plug-in instance is associated with, if any.

Signature:

getPluginNodeId(PluginInstanceId: String)

Operation: getPluginServiceInfo

Scope: Cluster

Displays information about a plug-in service. The information includes:

Signature:

getPluginServiceInfo(PluginServiceId: String)

Operation: getServiceInfo

Scope: Cluster

Displays information about a service type. The information includes:

This list is useful when setting up SLAs.

Signature:

getServiceInfo(Type: String)

Operation: listPluginInstances

Scope: Cluster

Displays a list of plug-in instances IDs.

The list is rendered as:

<Plug-in instance ID>#<JEE application name>#<version of JEE application>

The plug-in instance ID is the part of each entry up to the first #.

Signature:

listPluginInstances()

Operation: listPluginServices

Scope: Cluster

Displays a list of plug-in service IDs. A plug-in service ID uniquely identifies a plug-in service.

Signature:

listPluginServices()

Operation: listRoutes

Scope: Cluster

Displays a list of all registered routes.

Signature:

listRoutes()

Operation: listServiceTypes

Scope: Cluster

Displays a list of service types. The service types defines a collection of plug-in services exposing a specific functionality in the network.

For example: SMS or MMS.

Signature:

listServiceTypes()

Operation: removeRoute

Scope: Cluster

Removes a route. The route is identified by the ID of the plug-in instance and the matching pattern.

Signature:

removeRoute(PluginInstanceId: String, AddressExpression: String)

Operation: setPluginNodeId

Scope: Cluster

Assigns a node ID to a plug-in instance.

Signature:

setPluginNodeId(PluginInstanceId :String, nodeId: String)