The following section describes configuration and maintenance attributes and operations for the Plug-in manager. It also provides a workflow for the configuration:
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.
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.
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.
Routing logic is expressed in XML, and is evaluated by means of 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 use data configured using the plug-in manager:
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.
The plug-in routing logic matches data in a request, and data associated with a request, with routing logic and results in the selection of a plug-in instance. The request is handed off to the selected plug-in instance for further processing.
The routing logic offers a fine grained way to select a network protocol plug-in instance and makes it possible to select a plug-in instance, and thereby a network node, to be targeted for individual requests, based on all data available in the request.
In combination with the plug-in instance feature make it possible to single out a certain network node based on the above operands and thereby:
In combination with the plug-in instance feature make it possible to single out a network protocol plug-in instance even if the different plug-in instances connect to the same network node and thereby use different configurations for the request towards the network node.
Example: A network protocol plug-in offers the possibility to configure a priority parameter when sending request to the network node, by setting the parameter differently in different plug-in instances, different priorities can be used for different service providers. In the same way credentials can be mapped so the originator of the request is mapped to the request that is made to the network node.
The routing logic is expressed in XML and provides:
The XML based routing logic is specified per plug-in instance and routes requests to a plug-in based on logical expressions and tests that gets evaluated.
The logical operators are XML elements, as described in Table 19-1.
The operands are XML elements, as described in Table 19-2.
The destination address provided in the request is compared with the value given in this element. Which parameter that is considered the destination address is plug-in specific.
The format of the value is a regular expression specified as a string. The result is true only if the regular expression matches. See How address ranges are specified when setting up routes for examples of regular expressions.
The element has the optional attribute
defaultResult . It is a Boolean attribute that affects the end result if the request does not contain any destination address. If the attribute is set to false the evaluation results in false. If set to true, the evaluation results in true. Default value is false.
|
|
A named parameter in the request is compared with the value given in this element. There are three attributes to this element:
|
|
A parameter supplied in the request as a tunnelled parameter (xparam) in the request is compared with the value given in this element. There are three attributes to this element:
|
The plug-in routing configuration XML document is validated when it is provisioned. The XML is validated according to the XSD, see Plug-in Routing XSD.
For a set of examples, see Plug-in Routing Configuration Examples.
The example in Listing 19-1 matches requests sent to an address starting with tel:123
. If the request does not contain an address this route does not match.
<?xml version="1.0" encoding="UTF-8"?>
<route xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="route.xsd">
<destAddress>tel:123.*</destAddress>
</route>
The example in Listing 19-2 matches any address and also matches any request that does not contain an address.
<?xml version="1.0" encoding="UTF-8"?>
<route xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="route.xsd">
<destAddress defaultResult="true">.*</destAddress>
</route>
The example in Listing 19-3 matches requests sent from the service provider with the ID sp1
, and the application with the ID app1
.
<?xml version="1.0" encoding="UTF-8"?>
<route xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="route.xsd">
<and>
<spId>sp1</appId>
<appId>app1</appId>
</and>
</route>
The example in Listing 19-4 matches all requests except the ones where the operation is sendSmsRingtone
and either sent from and application using application instance ID appInst1
or the operation is sendSms
withe the value of the parameter senderName
is tel:123456
.
<?xml version="1.0" encoding="UTF-8"?>
<route xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="route.xsd">
<and>
<not><method>sendSmsRingtone</method></not>
<or>
<appInstanceId>appInst1</appInstanceId>
<and>
<method>sendSms</method>
<param name="arg0.senderName" value="tel:123456"/>
</and>
</or>
</and>
</route>
Below is the XSD to use when creating a plug-in routing configuration XML file.
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="route">
<xs:complexType>
<xs:group ref="ConditionGroup" minOccurs="1" maxOccurs="1"/>
</xs:complexType>
</xs:element>
<xs:group name="ConditionGroup">
<xs:choice>
<xs:element name="and" type="AndType"/>
<xs:element name="or" type="OrType"/>
<xs:element name="not" type="NotType"/>
<xs:element name="spId" type="xs:string"/>
<xs:element name="appId" type="xs:string"/>
<xs:element name="appInstanceId" type="xs:string"/>
<xs:element name="destAddress" type="AddressType"/>
<xs:element name="method" type="xs:string"/>
<xs:element name="param" type="ParamType"/>
<xs:element name="xparam" type="ParamType"/>
</xs:choice>
</xs:group>
<xs:complexType name="AndType">
<xs:group ref="ConditionGroup" minOccurs="1" maxOccurs="unbounded"/>
</xs:complexType>
<xs:complexType name="OrType">
<xs:group ref="ConditionGroup" minOccurs="1" maxOccurs="unbounded"/>
</xs:complexType>
<xs:complexType name="NotType">
<xs:group ref="ConditionGroup" minOccurs="1" maxOccurs="1"/>
</xs:complexType>
<xs:complexType name="AddressType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="defaultResult" type="xs:boolean" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ParamType">
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="value" type="xs:string" use="required"/>
<xs:attribute name="defaultResult" type="xs:boolean" default="false"/>
</xs:complexType>
</xs:schema>
Address ranges are specified using UNIX regular expressions. A few examples are given below:
The address scheme can be included in the expression. If not specified, any scheme will match. Examples
Plug-in routing logic is an extension the plug-in routes and Operation: setRouteConfig and Operation: getRouteConfig replaces Operation: addRoute and Operation: removeRoute.
Plug-in routes added using Operation: addRoute, are converted into plug-in routing logic where route is added as a logical OR given that the route that is being modified only contain <or>
and <destAddress defaultResult="true">
elements.
Configuring the plug-in manager can be divided into:
Below is an outline for configuring the plug-in manager:
Below is an outline for creating an instance of a plug-in service:
The administration of routes uses the following operations:
A node ID is assigned to one or more plug-in instance IDs to enforce node SLAs,. The node ID is then referred to in the node SLAs.
Managed object: Container ServicesPluginManager
MBean: com.bea.wlcp.wlng.plugin.PluginManagerMBean
Below is a list of attributes and operations for configuration and maintenance:
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.
Specifies whether policy based routing should be used.
Note: | Policy based routing must be enabled in order to enforce node SLAs. |
Deprecated. Use Operation: setRouteConfig.
Adds a new plug-in route. A route is identified by the plug-in instance ID and a match pattern.
addRoute(PluginInstanceId: String, AddressExpression: String)
ID of the plug-in instance that is the target of the route. A list of plug-in instance IDs is displayed using the Operation: listPluginInstances.
|
|
The pattern to be used as a matching criteria. See How address ranges are specified when setting up routes.
|
Creates a new instance of a specific plug-in service.
createPluginInstance(PluginServiceId: String, PluginInstanceId: String)
ID of the plug-in service to instantiate. See Operation: listPluginServices for a list of plug-in service IDs.
|
|
All existing instances can be displayed using Operation: listPluginInstances.
|
Destroys an instance of a specific plug-in instance. All routes associated with the instance are kept.
destroyPluginInstance(PluginServiceId: String, PluginInstanceId: String)
Gets information about a specific plug-in instance. The information includes:
getPluginInstanceInfo(PluginInstanceId: String)
Displays which plug-in node ID a plug-in instance is associated with, if any.
getPluginNodeId(PluginInstanceId: String)
Displays information about a plug-in service. The information includes:
getPluginServiceInfo(PluginServiceId: String)
Gets the plug-in routing logic XML for a given plug-in instance.
getRouteConfig(PluginInstanceId :String)
Displays information about a service type. The information includes:
This list is useful when setting up SLAs.
getServiceInfo(Type: String)
ID of the service type. See Operation: listServiceTypes.
|
Displays a list of plug-in instances IDs.
<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 #.
listPluginInstances()
Displays a list of plug-in service IDs. A plug-in service ID uniquely identifies a plug-in service.
listPluginServices()
Displays a list of all registered routes, including the routing logic expressed an XML.
listRoutes()
Displays a list of service types. The service types defines a collection of plug-in services exposing a specific functionality in the network.
listServiceTypes()
Deprecated. Use Operation: setRouteConfig.
Removes a route. The route is identified by the ID of the plug-in instance and the matching pattern.
removeRoute(PluginInstanceId: String, AddressExpression: String)
The pattern used as a matching criteria. See How address ranges are specified when setting up routes.
|
Loads plug-in routing logic XML for a plug-in instance. Existing routing logic is overwritten, use Operation: getRouteConfig to get the existing routing logic.
Replaces Operation: addRoute.
setRouteConfig(PluginInstanceId :String, xmlConfig: String)
The plug-in routing logic. Expressed as XML, see Plug-in Routing Logic.
|
Assigns a node ID to a plug-in instance.
setPluginNodeId(PluginInstanceId :String, nodeId: String)
Loads plug-in routing logic XML for a plug-in instance.
Replaces Operation: addRoute.
setRouteConfig(PluginInstanceId :String, xmlConfig: String)
The plug-in routing logic. Expressed as XML, see Plug-in Routing Logic.
|