This chapter describes how to deploy and administer communication services in Oracle Communications Services Gatekeeper.
All telecommunication traffic processed by Services Gatekeeper passes through a communication service. Each communication service includes an application-facing (north) interface connecting it to an application, a service plug-in that provides functionality, and a network-facing (south) interface connecting it to your network nodes.
For:
An overview of communication services, see Services Gatekeeper Concepts.
Details on the communication services that Services Gatekeeper includes, see Services Gatekeeper Communication Service Reference Guide.
Information on creating your own custom communication services see Services Gatekeeper Extension Developer's Guide.
Communication services are packaged and deployed in EAR files. Container services are packaged and deployed separately from the communication services and should not be modified.
All network protocol plug-ins that share the same group of application-facing interfaces are packaged into the same EAR file.
All communication services that share a common set of application-facing interfaces are grouped together. For example, Services Gatekeeper is delivered with two communication services for Parlay X 2. 1 Third Party Call:
Parlay X 2.1 Third Party Call/INAP, where INAP is exposed through Parlay X 2.1 Third Party Call interfaces.
Parlay X 2.1 Third Party Call/SIP, where SIP is exposed through Parlay X 2.1 Third Party Call interfaces.
Each group of communication services is packaged in two separate EAR files:
wlng_at_communication service.ear: This file serves as the service facade for the named communication service. It consists of modules shared among the communication service only. The wlng_at_communication service.ear file is deployed in the access tier.
wlng_nt_communication service.ear. This file serves as the service enabler for the named communication service. It contains the network protocol plug-ins for the communication service and common modules for the communication service. The wlng_nt_communication service.ear file is deployed in the network tier.
The communication services EAR files are located in the Middleware_home/ocsg_/applications directory.
The files holding the communication services that share the Parlay X 2.1 Third Party Call communication service layer consist of the following artifacts:
wlng_at_third_party_call_px21.ear
wlng_nt_third_party_call_px21.ear
The wlng_nt_third_party_call_px21.ear file contains, among other modules:
Plugin_px21_third_party_call_inap.jar, which contains the Parlay X 2.1 Third Party Call/INAP plug-in.
Plugin_px21_third_party_call_sip.jar, which contains the Parlay X 2.1 Third Party Call/SIP plug-in.
The Plugin_px21_third_party_call_sip.jar file is one of the artifacts needed to achieve end-to-end service communication for communications services connecting to the SIP network. There is also a part that is deployed as a SIP servlet in the SIP Server container. The SIP servlet parts are packaged in a set of files, wlng-integration-management.jar, wlng-integration-console-ext.war, wlss-int.ear, and wlng-security.jar.
An HTTP servlet is available for plug-ins that use HTPP as the transport protocol and handle network-triggered messages from the network node. HTTP servlets are packaged as Web Archives (WARs) and are packaged in the network tier EAR for the communication service.
Other modules in wlng_nt_third_party_call_px21.ear are shared between the two network protocol plug-ins, including the common parts that are tied to the implementation of the communication layer, and any libraries and utilities shared among the plug-ins.
When adding or removing a plug-in to or from wlng_nt_communication service.ear, expand the EAR and the plug-in specific parts that are being added or removed.
Example 19-1 describes the elements in a wlng_nt_communication service.ear file.
Example 19-1 Contents of wlng_nt_<communication service>.ear
+---APP-INF/lib
...
communication service_callback_client.jar
/<utilities 1>.jar
...
/<utilities n>.jar
+---META-INF/MANIFEST.MF
/application.xml
/weblogic-application.xml
/weblogic-extension.xml
+---<plug-in 1>.jar
...
+---<plug-in n>.jar
+---<plug-in 1>.war
...
+---<plug-in n>.war
+---<communication service>_service.jar
In Example 19-1:
APP-INF/lib contains any JARs that are shared among the plug-ins in the EAR. This includes the client library for the service callback EJB communication service_callback_client.jar.
One or more utility jar files can be present, depending on the type of communication service.
META-INF/MANIFEST.MF is a standard manifest file.
META-INF/application.xml is the standard deployment descriptor for EARs.
META-INF/weblogic-application.xml is the WebLogic Server-specific deployment descriptor.
META-INF/weblogic-extension.xml is a WebLogic Server-specific deployment descriptor.
All plug-ins in the service enabler are packaged as individual jar files in the root of the EAR with the service EJB, communication service_service.jar.
If a plug-in connects to the telecom network using HTTP and supports network-triggered requests, there is also a corresponding WAR file that contains the servlet.
For more information about enterprise application deployment descriptor elements, see ”Referencing JMS Resources in a WebLogic Application” in Oracle WebLogic Server Developing Applications for Oracle WebLogic Server.
Example 19-2 describes the elements in a plug-in jar file.
Example 19-2 Contents of <plug-in X>.jar
+---com/ +---org/ +---META-INF/MANIFEST.MF + instancemap + srv_depl.xml
The plug-in jar file contains the regular elements in a jar and an instancemap. The instancemap element uses the InstanceFactory class to instantiate the plug-in specific implementation of the required interface. See the discussion about "Retrieving Implementation Instances Using InstanceFactory" in Services Gatekeeper Extension Developer's Guide for more information.
For those communication services that have RESTful facades, both SOAP and RESTful facades are included in the standard EAR files.
If your installation needs to use multiple clusters of AT servers, you must make some adjustments. You cannot deploy the RESTful facade on multiple clusters within the same domain. You can deploy both the RESTful facade and the SOAP facade on a single cluster within the domain and deploy only the SOAP facade on multiple other clusters within that same domain.
To accomplish this, do the following:
Undeploy the standard EAR files for the communication services (including the session manager) you are using on any additional clusters your installation requires.
Replace the files with special equivalent EAR versions that contain only SOAP interfaces
The file names for .ear files for SOAP interfaces are identical to those of the standard files except that a _soap is appended to the end of the name. The following SOAP-only EAR files should be deployed (as needed) in this situation:
wlng_at_call_notification_px21_soap.ear
wlng_at_multimedia_messaging_px21_soap.ear
wlng_at_payment_px30_soap.ear
wlng_at_presence_px21_soap.ear
wlng_at_push_message_ews_soap.ear
wlng_at_session_soap.ear
wlng_at_sms_px21_soap.ear
wlng_at_subscriber_profile_ews_soap.ear
wlng_at_terminal_location_px21_soap.ear
wlng_at_third_party_call_px21_soap.ear
These files are found in the Middleware_home/ocsg/applications directory of your installation. Information on the content of these files is available in the ”Properties” section of each respective communication services reference in Services Gatekeeper Communication Service Reference Guide.
Complete the deployment procedure before production.
Important:
From the Administration console:
Create Managed Servers for the non-REST AT clusters (for example, WLNG_AT1 and WLNG_AT2).
Create Managed Servers for the REST_AT cluster (for example, REST_AT1 and REST_AT2)
Create the clusters for these servers (for example WLNG_AT_Cluster and REST_AT_Cluster).
Assign the Managed Servers to their appropriate clusters:
WLNG_AT_Cluster WLNG_AT1 WLNG_AT2
REST_AT_Cluster REST_AT1 REST_AT2
Change all deployed applications with REST interfaces (that is, the standard EARs), including session manager, to target REST_AT_Cluster.
Change the targets of the AT JMS Servers from WLNG_AT* to the REST_AT*.
Change the target of WLNG_ATJMSResource from WLNG_AT_Cluster to REST_AT_Cluster.
Shut down all servers.
Edit the following snippet of the config.xml file manually. In default installations this file can be found at domain-home/config/config.xml.
<custom-resource>
<name>accesstier</name>
<target>WLNG_AT_Cluster</target>
<descriptor-file-name>custom/at.xml</descriptor-file-name>
<resource-class>com.bea.wlcp.wlng.management.descriptor.resource.WlngTierResource</resource-class>
<resource-class>com.bea.wlcp.wlng.management.descriptor.resource.WlngTierResource</resource-class>
</custom-resource>
Change the target in the access tier custom resource from WLNG_AT_Cluster to WLNG_AT_Cluster, REST_AT_Cluster.
Locate and open the config.xml file.
In default installations, this file can be found at domain-home/config/config.xml.
Carefully edit the following snippet of the config.xml file manually.
<custom-resource>
<name>accesstier</name>
<target>WLNG_AT_Cluster</target>
<descriptor-file-name>custom/at.xml</descriptor-file-name>
<resource-class>com.bea.wlcp.wlng.management.descriptor.resource.WlngTierResource</resource-class>
<resource-class>com.bea.wlcp.wlng.management.descriptor.resource.WlngTierResource</resource-class>
</custom-resource>
Change the target in the access tier custom resource from WLNG_AT_Cluster to WLNG_AT_Cluster, REST_AT_Cluster.
Start up the administration server and install and deploy the SOAP-only EAR files to the non-REST cluster (WLNG_AT_Cluster).
Start the newly installed EAR files using the Administration console. If you forget to do this, their status will be prepared.
Start the Managed Servers.
For more information on using the Administration Console to accomplish these tasks, click Help on the console screen.
Communication services are associated with release versions and can be upgraded using in-production deployment.
The version numbering is on the EAR level, which means that all network protocol plug-ins for a given collection of application-facing interface are redeployed.
The version number for a specific communication service is specified in the Weblogic-Application-Version attribute in META-INF/manifest.mf in wlng_at_communication service.ear and wlng_nt_communication service.ear, respectively.
For more information about how to develop applications for production redeployment, see ”Developing Applications for Production Redeployment" in Oracle Fusion Middelware Developing Applications for Oracle WebLogic Server.
Communication services are deployed and undeployed as EAR files.
For a description of the different deployment options, see "Overview of the Deployment Process" in Oracle Fusion Middleware Understanding Oracle WebLogic Server.
The EAR file names for each communication service and the JAR names for the network protocol plug-ins are listed a table in the discussion on properties for each communication service chapter in Services Gatekeeper Communication Service Reference Guide.
The properties section also describes the JAR file for the plug-in and other artifacts, such as third-party libraries, used by the plug-in.
Following is an example on how to undeploy the Parlay X 2.1 Third Party Call communication service:
java weblogic.Deployer -adminurl http://<admin host>:<admin port> -user <admin user> -password <admin password -name wlng_nt_third_party_call_px21 -undeploy -graceful
If a plug-in has been removed from the EAR, use the mechanism described in "Performing a Hitless Upgrade".
See "Patch Management of Services Gatekeeper Systems" in Multi-tier Installation Guide for instructions on patching Services Gatekeeper, including communication services.
Table 19-1 gives an overview of the Services Gatekeeper configuration files.
Table 19-1 Services Gatekeeper Configuration Files
| File | Contains configuration for... |
|---|---|
|
Domain_home/config/config.xml |
WebLogic Server. See "Domain Configuration files" in Oracle WebLogic Server Understanding Domain Configuration for Oracle WebLogic Server. Note: Do not edit this file manually. The following additional elements are specific to Services Gatekeeper:
To manage the lifecycle of communication services, use the WebLogic Server tools, such as the Administration Console's Deployment page or the command-line tools. For more information see "Overview of Common Deployment Scenarios" in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server. |
|
Domain_home/config/custom/at.xml |
Services Gatekeeper access tier container and container services. This is a custom resource. Note: Do not edit this file. |
|
Domain_home/config/custom/nt.xml |
Services Gatekeeper network tier container and container services. This is a custom resource. Note: Do not edit this file. |
|
Domain_home/config/custom/wlng-edr.xml |
EDRs, CDRs, and alarms. This is a custom resource Note: Do not edit this file manually. |
Table 19-2 describes the Services Gatekeeper Java EE container services. The interfaces to these, with common classes, are packaged in
Middleware_home/ocsg/server/lib/wlng/wlng.jar
The container services are packaged in separate JARs, located in
Middleware_home/ocsg/server/lib/wlng/wlng.jar
Table 19-2 Services Gatekeeper Container Services
| Container service | Summary |
|---|---|
|
com.bea.wlcp.wlng.core.CoreServerService |
Performs initial setup during the start-up sequence. |
|
com.bea.wlcp.wlng.snmp.SNMPServerService |
SNMP service. |
|
com.bea.wlcp.wlng.event_channel.EventChannelServerService |
Broadcasts arbitrary events between modules and servers in a cluster. |
|
com.bea.wlcp.wlng.storage.StorageServerService |
Storage service. |
|
com.bea.wlcp.wlng.storage.db.DbServerService |
Storage provider for persistence using direct database access. |
|
com.bea.wlcp.wlng.storage.inval.InvalidatingServerService |
Storage provider for persistence using an invalidating cache. |
|
com.bea.wlcp.wlng.storage.configuration.ConfigurationStoreServerService |
Storage provider for configuration settings. |
|
com.bea.wlcp.wlng.edr.EdrServerService |
EDR service. |
|
com.bea.wlcp.wlng.core.budget.BudgetServerService |
Budget service. |
|
com.bea.wlcp.wlng.georedundant.GeoRedundantServerService |
Geographical redundancy service. |
|
Account service. |
|
|
com.bea.wlcp.wlng.statistics.StatisticsServerService |
Statistics service. |
|
com.bea.wlcp.wlng.plugin.PluginManagerServerService |
Plug-in manager. |
|
com.bea.wlcp.wlng.storage.georedundant.GeoRedundantStoreServerService |
Storage provider for intercepting store operations for geographically redundant stores, forwarding changes to the geo storage server service functions and reads to the local storage provider. |
|
com.bea.wlcp.wlng.geostorage.GeoStorageServerService |
Geo storage server service that has the geo storage singleton services, manages the geo-master lifecycle, performs calls remote calls to the other site, and consistency checks between sites. Also has the geo storage Mbean. |
|
com.bea.wlcp.wlng.tier_routing.TierRoutingManagerServerService |
Tier routing manager. |
You patch container services using the SmartUpgrade utility. See ”SmartUpgrade Support for JDBC” in Oracle Fusion Middleware Administering JDBC Data Sources for Oracle WebLogic Server.
You patch container services and WebLogic Server using the upgrade process. See "Understanding the 12c Upgrade Process" in Oracle Fusion Middleware Upgrade Planning Guide.