This chapter describes the Oracle Communications Services Gatekeeper Extended Web Services (EWS) Subscriber Profile/Lightweight Directory Access Protocol (LDAPv3) communication service in detail.
The EWS Subscriber Profile/LDAPv3 communication service exposes Oracle's Extended Web Services Subscriber Profile application interface.
The communication service acts as an LDAP client to a directory service, connecting to the directory service using LDAPv3.
For the exact version of the standards that the communication service supports for the application-facing interfaces and the network protocols, see Services Gatekeeper Statement of Compliance.
Using the EWS Subscriber Profile/LDAPv3 communication service, an application can:
Retrieve the specific value for a particular property belonging to a subscriber profile stored in an LDAP data source.
Retrieve an entire subscriber profile from an LDAP data source, subject to SLA filtering.
For information about the application interface for the Extended Web Services Subscriber Profile communication service, see the discussion on extended web services subscriber profile in Services Gatekeeper Application Developer's Guide.
For information about the RESTful Call Notification interface, see the discussion on subscriber profile in Services Gatekeeper Application Developer's Guide.
The RESTful Service Call Notification interfaces provide RESTful access to the same functionality as the SOAP-based interfaces. The internal representations are identical, and for the purposes of creating SLAs and reading CDRs, and so on, they are the same.
The EWS Subscriber Profile/LDAPv3 communication service generates Event Data Records (EDRs), Charging Data Records (CDRs), alarms, and statistics to assist system administrators and developers in monitoring the service
See "Events, Alarms, and Charging" for more information.
Table 25-1 lists IDs of the EDRS created by the EWS Subscriber Profile/LDAPv3 communication service. This list does not include EDRs created when exceptions are thrown
EWS Subscriber Profile/LDAPv3-specific CDRs are generated under the following conditions:
After Services Gatekeeper has returned a full or partial subscriber profile to an application based on one or more attributes requested by that application.
After Services Gatekeeper has returned a subscriber profile to an application based on the ID of the profile.
Table 25-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counters.
This section describes the properties and workflow for the EWS Subscriber Profile/LDAPv3 plug-in instance.
It includes an LDAP server schema to use in constructing LDAP queries.
A connection pool is used for connections to the LDAP server. The connection pool is shared among all plug-in instances, and any configuration settings related to this pool or schema updates are broadcast to all plug-in instances in the cluster.
Use the updateLDAPSettings method to force configuration changes to take effect.
Table 25-3 lists the technical specifications for the communication service.
Table 25-3 Properties for EWS Subscriber Profile/LDAPv3
| Property | Description |
|---|---|
|
Managed object in Administration Console |
To access the object, select domain_name, then OCSG, then server_name, then Communication Services, then plugin_instance_id in that order. |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng_nt InstanceName=same as the network protocol instance_id assigned when the plug-in instance is created. Type=com.bea.wlcp.wlng.plugin.subscriberprofile.ldap.managedplugin.management.SubscriberProfileMBean Documentation: See the ”All Classes” section of Services Gatekeeper OAM Java API Reference |
|
Network protocol plug-in service ID |
Plugin_ews_subscriber_profile_ldap |
|
Network protocol plug-in instance ID |
The ID is assigned when the plug-in instance is created. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. |
|
Supported Address Scheme |
tel, id, imsi, ipv4/ipv6 |
|
Application-facing interface |
com.bea.wlcp.wlng.ews.plugin.SubscriberProfilePlugin |
|
Service type |
SubscriberProfile |
|
Exposes to the service communication layer a Java representation of: |
Extended Web Services Subscriber Profile |
|
Interfaces with the network nodes using: |
LDAP |
|
Deployment artifact NT EAR wlng_nt_subscriber_profile_ews.ear |
ews_subscriber_profile_service.jar and Plugin_ews_subscriber_profile_ldap.jar |
|
Deployment artifact AT EAR: Normal wlng_at_subscriber_profile_ews.ear |
ews_subscriber_profile.war and rest_subscriber_profile.war |
|
Deployment artifact AT EAR: SOAP Only wlng_at_subscriber_profile_ews_soap.ear |
ews_subscriber_profile.war |
All subscriber-profile-related operations are handed off to network nodes that accept LDAP queries according to LDAPv3. The decision concerning which node in the LDAP directory should be used to perform the query is decided at run time based on configuration settings. The data that is handed back to the application that initiated the Subscriber Profile query is filtered using the result filter mechanism in the service provider group and application group SLAs. For more information, see the discussion about <resultRestrictions> in the defining service provider group and application group SLAs desction of the Services Gatekeeper Accounts and SLAs Guide.
A schema is used for constructing queries. See Example 25-1.
Example 25-1 LDAP Query schema XSD
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="LdapConfig"> <xs:complexType> <xs:sequence> <xs:element name="Keys" type="KeySet" minOccurs="1" maxOccurs="unbounded"/> <xs:element name="LdapObject" type="LdapObject" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="KeyObject"> <xs:sequence> <xs:element name="uriScheme" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="addressKeyName" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="objectKeyName" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="objectKeyValue" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="optional"/> </xs:complexType> <xs:complexType name="KeySet"> <xs:sequence> <xs:element name="Key" type="KeyObject" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="LdapObject"> <xs:sequence> <xs:element name="ObjectKeySet" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="keyName" type="xs:string" use="required"/> <xs:attribute name="keyValue" type="xs:string" use="required"/> </xs:complexType> </xs:schema>
The LDAP server schema describes the following elements:
LdapObject: Holder of a KeySet
KeySet: Defines a collection of KeyObjects. Sets of keys are used because there may be several ways to reach a certain node in the tree. One LDAP plug-in instance can be configured with several KeySets and can provide the link between the search key in the Extended Web Services interface and the LDAP tree.
KeyObject: Defines an entry point to the LDAP tree and provides the link between the search key in the Extended Web Services interface and the LDAP tree.
Table 25-4 describes the schema objects in detail.
| Object | Element | Description |
|---|---|---|
|
LdapObject |
ObjectKeySet |
Defines the KeySet through which it can be reached. Refers to theID attribute of a defined KeySet. |
|
LdapObject |
id |
The identity of the LdapObject. Can be referenced from other LdapObjects through the ParentObjectId field. |
|
LdapObject |
keyName |
The name of the key through which the LdapObject can be reached. |
|
LdapObject |
keyValue |
The value of the key through which the LdapObject can be reached. |
|
KeyObject |
uriScheme |
Defines the URI scheme of the address for which this key applies. |
|
KeyObject |
addressKeyName |
Defines the key name with which the address value is associated. |
|
KeyObject |
objectKeyName |
Provides the possibility of defining the addressing key of a possible tree node above the node that is reached by the address key (that is, like the domain object in the 3DS directory information tree). |
|
KeyObject |
objectKeyValue |
See objectKeyName. Defines the value of the key. |
|
KeyObject |
id |
The identity of the key. Used only for descriptive purposes. |
|
KeySet |
Key |
All keys in the KeySet |
|
KeySet |
id |
The identity of the KeySet. Used when associating an LdapObject with a KeySet. |
Example 25-2 shows a directory information tree built using the schema described in Table 25-4.
Example 25-2 Example of LDAP server schema
<?xml version="1.0" encoding="UTF-8"?> <LdapConfig xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:noNamespaceSchemaLocation='sp_config.xsd'> <Keys id="myKeys"> <Key id="misidnKey"> <uriScheme>tel</uriScheme> <addressKeyName>msisdn</addressKeyName> <objectKeyName>domainName</objectKeyName> <objectKeyValue>msisdnD</objectKeyValue> </Key> <Key id="imsiKey"> <uriScheme>imsi</uriScheme> <addressKeyName>imsi</addressKeyName> <objectKeyName>domainName</objectKeyName> <objectKeyValue>imsiD</objectKeyValue> </Key> <Key id="subscriberIdKey"> <uriScheme>id</uriScheme> <addressKeyName>id</addressKeyName> <objectKeyName>domainName</objectKeyName> <objectKeyValue>subsD</objectKeyValue> </Key> <Key id="ipv4Key"> <uriScheme>ipv4</uriScheme> <addressKeyName>ipv4Addr</addressKeyName> <objectKeyName>domainName</objectKeyName> <objectKeyValue>ipv4D</objectKeyValue> </Key> </Keys> <LdapObject id="mySchema" keyName="serviceName" keyValue="mySchema"> <ObjectKeySet>myKeys</ObjectKeySet> </LdapObject> </LdapConfig>
Following is an outline for configuring the plug-in using the Administration Console or an MBean browser.
Create one or more instances of the plug-in service. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in service ID as listed in the "Properties for EWS Subscriber Profile/LDAPv3" section.
Select the MBean for the plug-in instance. The MBean display name is the same as the plug-in instance ID given when the plug-in instance was created.
Define the characteristics of the LDAP server to connect to using these fields:
Port
AuthDN
BaseDN
AuthPassword
Define the schema using either the Schema field or the updateSchemaURL operation.
See "LDAP Server Schema" for a description of the schema and "Configuration Workflow for EWS Subscriber Profile/LDAPv3" for a description of the mappings.
Define the connection pool characteristics for the connection using these fields:
MinConnections
MaxConnections
ConnTimeout
RecoverTimerInterval
Set up the routing rules to the plug-in instance. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in instance ID and address schemes listed in the "Properties for EWS Subscriber Profile/LDAPv3" section.
If required, create and load a node SLA. For details see the discussion about defining global node and service provider group node SLAs and managing SLAs in Services Gatekeeper Accounts and SLAs Guide.
Provision the service provider accounts and application accounts. For information, see Services Gatekeeper Portal Developer's Guide.
There are no specific management operations, except for the updateLDAPSettings method, used to update the LDAP connection pool after changing any of these fields:
MinConnections
MaxConnections
ConnTimeout
RecoverTimerInterval
If the results from the LDAP query should be filtered, use the service provider group and application group SLAs. See the discussion about <resultRestrictions> in the defining service provider group and application group SLAs desction of the Services Gatekeeper Accounts and SLAs Guide.
For a description of the attributes and operations of the SubscriberProfileMBean MBean, see the ”All Classes” section of Services Gatekeeper OAM Java API Reference.