| Oracle® Communications Services Gatekeeper System Administrator's Guide Release 5.1 E37531-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Services Gatekeeper System Administrator's Guide Release 5.1 E37531-01 |
|
|
PDF · Mobi · ePub |
This chapter describes the deployment model used in Oracle Communications Services Gatekeeper. Communication services are packaged and deployed in EAR files. All network protocol plug-ins that share the same group of application-facing interfaces are packaged into the same EAR file.
Container services are packaged and deployed separately from the communication services and should not be modified.
All communication services that share a common set of application-facing interfaces are grouped together. For example, Oracle Communications 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, which serves as the service facade. This part consists only of modules shared among the communication service. The wlng_at_communication service.ear is deployed in the Access Tier.
wlng_nt_communication service.ear, which serves as the service enabler. This part contains the network protocol plug-ins for the communication service and common modules for the communication service. The wlng_nt_communication service.ear is deployed in the Network Tier.
The communication services EAR files are located in the Middleware_Home/ocsg_5.1/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
wlng_nt_third_party_call_px21.ear 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. See note below.
Other modules in this 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.
Note:
Plugin_px21_third_party_call_sip.jar is not the only artifact 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. In addition, for plug-ins that use HTPP as the transport protocol and handle network-triggered messages from the network node, there is an HTTP servlet. HTTP servlets are packaged as Web Archives (WARs) and are packaged in the network tier EAR for the communication service. 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.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 17-1describes the elements in wlng_nt_communication service.ear
Example 17-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
All plug-ins in the service enabler are packaged as individual jar files in the root of the EAR together 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.
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 and 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.
For more information about enterprise application deployment descriptor elements, see "Enterprise Application Deployment Descriptor Elements" in Oracle® Fusion Middleware Developing Applications for Oracle WebLogic Server at
http://download.oracle.com/docs/cd/E15523_01/web.1111/e13706/app_xml.htm
Example 17-2 describes the elements in a plug-in jar file.
Example 17-2 Contents of <plug-in X>.jar
+---com/ +---org/ +---META-INF/MANIFEST.MF + instancemap + srv_depl.xml
The jar contains the regular elements in a jar and also an instancemap, used among other thing to instantiate the plug-in specific implementation of the plug-in interface using the InstanceFactory. See "Class: InstanceFactory" in the Oracle Communications Services Gatekeeper Platform Development Studio 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 uses a single cluster of AT servers, this raises no issues. But if your installation needs to use multiple clusters of AT servers, you need to make some adjustments. As a result of certain internal characteristics, it is not possible to deploy the RESTful facade on multiple clusters within the same domain. It is possible to deploy both the RESTful facade and the SOAP facade on a single cluster within the domain and to deploy only the SOAP facade on multiple other clusters within that same domain. In order to accomplish this, you need to use the normal mechanisms to undeploy the standard EAR files for the communication services (including the session manager) you are using on any additional clusters your installation requires and to deploy instead special equivalent EAR versions that contain only SOAP interfaces. The file names are identical to those of the standard files except that a _soap is appended to the end of the name. The following is a list of the SOAP-only EAR files that 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 $BEAHOME/ocsg_5.1/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 this guide.
This procedure should be performed prior to production. It is recommended that you make the console-based changes (all except step 6) with only the Administration Server running. For step 6, you need to shut down all servers and re-start.
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:
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. Carefully 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.
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 versioned and can be upgraded using in-production deployment.
The versioning is on EAR level, which means that all network protocol plug-ins for a given collection of application-facing interface are redeployed.
The version is specified in the Weblogic-Application-Versionattribute 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 Middleware Developing Applications for Oracle WebLogic Server at
http://download.oracle.com/docs/cd/E15523_01/web.1111/e13706/versioning.htm
Individual communication service are deployed and undeployed as EARs.
For a description of the different deployment options, see "Deploying Applications" in Oracle Fusion Middleware Administrator's Guide at
http://download.oracle.com/docs/cd/E15523_01/core.1111/e10105/deploy.htm
The EAR file names for each communication service and the JAR names for the network protocol plug-ins are listed a table in the "Properties for communication service" sections of the chapters in Oracle Communications Services Gatekeeper Communication Service 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".
To upgrade communication services, patches are applied using a patch tool. The patch tool operates on the EAR files for the communication services. The version of the plug-in is the same as the version of the service enabler it is packaged in, the versioning is on EAR file level.
Following is the typical process for applying patches to communication services.
The patch, in the form of a JAR file is provided.
The patch is applied to the original EAR file witch results in a new, patched, EAR. For example, if the original EAR version is 5.1, the version of the new EAR is 5.1_1. A sequence number should be suffixed to make each version unique.
The new EAR file is deployed and the old version is undeployed, using in-production redeployment, see "Hitless Upgrade Using Production Redeployment".
If another issue is detected for the same EAR a second patch JAR is provided.
The patch is applied to the already patched EAR and creates version 5.1_2.
The new patched EAR is deployed.
Alternatively, both patches can be applied at the same time. This will result in the same version as when applying them separately (version 5.1_2).
Patches are applied using an Ant build file: Middleware_Home/ocsg_5.1/server/bin/build.xml
The correct CLASSPATH must be set up for the patch build file. Run setWLSEnv.sh or setWLSEnv.cmd located in Middleware_Home/wlsserver_10.3/server/bin to set up the environment.
There are two targets available in the build file:
patch – Applies patches to an EAR file.
printpatches – Displays the currently applied patches.
The syntax is:
ant [patch | printpatches] -Dsrc= -Ddest= -Dversion= -Dpatchdir= -Dpatchfiles=
Table 17-1 describes these arguments.
Table 17-1 Arguments to Patch Build File
| Target/Argument | Description |
|---|---|
|
patch |
This target applies a patch. |
|
printpatches |
This target displays the currently applied patches. The information includes:
|
|
src |
The EAR file to which the patch is to be applied |
|
dest |
The EAR file that will contain the patch |
|
version |
The new version for the EAR. Must be different from the original version. |
|
patchdir |
Directory that holds the patches. Paths are relative or absolute. |
|
patchfiles |
The JAR files that contain the patches. Wild cards are supported. |
The patch tool detects conflicts if multiple patches try to patch the same file. In this situation, an error message is displayed and a combination (combo) patch must be used.
Table 17-2 contains some usage examples.
| Example | Command |
|---|---|
|
View patch information for a single EAR file. |
|
|
View patch information for all EARs in a specified directory. |
|
|
Apply a single patch to an EAR. |
|
|
Apply all patches located in the directory /patches. |
|
Table 17-3 gives an overview of the Oracle Communications Services Gatekeeper configuration files.
Table 17-3 Oracle Communications Services Gatekeeper Configuration Files
| File | Contains configuration for... |
|---|---|
|
Domain_Home/config/config.xml |
WebLogic Server. See "Domain Configuration Files" in Oracle® Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server at
The following additions are specific to Oracle Communications Services Gatekeeper: ...a <custom-resource>, with ...a <custom-resource>, with ...A set of <app-deployment> specific for the deployed communication services. See the relevant communication service in Oracle Communications Services Gatekeeper Communication Service Guide. Do not edit this file manually. 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 described in "Deployment Tools" in Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server at
|
|
Domain_Home/config/custom/at.xml |
Oracle Communications 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 |
Oracle Communications 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 17-4 describes the Oracle Communications Services Gatekeeper container services. The interfaces to these, together with common classes, are packaged in
Middleware_Home/ocsg_5.1/server/lib/wlng/wlng.jar
The container services are packaged in separate JARs, located in
Middleware_Home/ocsg_5.1/server/lib/wlng/wlng.jar
| 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. |
Patching of container services is done using SmartUpdate; see WebLogic Server Installing Patches and Maintenance Packs at
http://download.oracle.com/docs/cd/E12840_01/common/smartupdate/guide/
Patches to container services and WebLogic Server is done using rolling upgrades; see "Roadmap for Upgrading Your Application Environment" in Oracle® Fusion Middleware Upgrade Guide for Oracle WebLogic Server at
http://download.oracle.com/docs/cd/E15523_01/web.1111/e13754/roadmap.htm
|
 Copyright © 2007, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|