This section describes the deployment model used in Oracle Communications Services Gatekeeper. Communication services are packaged and deployed in EAR files. The EAR files are grouped, 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.
The communication services are grouped so that all communication services that share a common set of application-facing interfaces are grouped together. For example, off-the-shelf, Oracle Communications Services Gatekeeper is delivered with two communication services for Parlay X 2. 1 Third Party Call:
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 $BEA_HOME/ocsg_4.1/applications
directory.
When adding or removing a plug-in to or from wlng_nt_<communication service>.ear
, the EAR must be exploded and the plug-in specific parts being either added or removed.
Listing 17-1describes the elements in 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>_callb
ack_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 Oracle WebLogic Server Developing Applications with WebLogic Server at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/programming.
Listing 17-2 describes the elements in a plug-in jar file.
+---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
InstanceFactory in 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 AT 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. To support this, a special second set of EAR files should be deployed instead of the standard EAR files. These special equivalent EAR versions 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:
These files are found in the $BEAHOME/ocsg_4.1.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 done before going into production. It is recommended that you make the console-based changes (all but step 6) with only the Admin Server running. For step 6, you will need to shut down all servers and re-start.
In general these are the steps required. Using the Admin console:
WLNG_AT_Cluster WLNG_AT1 WLNG_AT2
REST_AT_Cluster REST_AT1 REST_AT2
<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>
<descriptor-bean-class>com.bea.wlcp.wlng.management.descriptor.bean.WlngTierBean</descriptor-bean-class>
</custom-resource>
Change the target in the accesstier custom resource from WLNG_AT_Cluster to WLNG_AT_Cluster, REST_AT_Cluster.
For more information on using the Admin Console to accomplish these tasks, click Help on the console screeen. WebLogic Server Administration Console Help comes up.
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 attribute Weblogic-Application-Version
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 Oracle WebLogic Developing Applications with WebLogic Server at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/programming/index.html.
Individual communication service are deployed and undeployed as EARs.
See Oracle WebLogic Server Deploying Applications to WebLogic Server at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/deployment/ for a description of the different deployment options.
The EAR names for each communication service and the JAR names for the network protocol plug-in are found under the heading “Properties for <Communication service>” in the section of Oracle Communications Services Gatekeeper Administration Guide (this guide) which describes the management of the network protocol plug-in for the communication service in question.
For example, the EAR names for the Third Party Call communication service are found in Properties for Parlay X 3.0 Third Party Call/Parlay MultiParty Call Control, Properties for Parlay X 2.1 Third Party Call/SIP, and Properties for Parlay X 2.1 Third Party Call/INAP.
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.
Below 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.
Below is the typical process for applying patches to communication services.
Alternatively, both patches can be applied at the same time. This will result in the same version as when applying them separately (version 4.0_2).
Patches are applied using an Ant build file: $BEA_HOME/ocsg_4.1/server/bin/build.xml
The correct CLASSPATH
must be setup in order for the patch build file. Run setWLSEnv.sh
or setWLSEnv.cmd
located in $BEA_HOME/
wlsserver_10.3/server/bin to setup the environment.
There are two targets available in the build file:
ant [patch | printpatches] -Dsrc= -Ddest= -Dversion= -Dpatchdir= -Dpatchfiles=
The patch tool detects conflicts if multiple patches try to patch the same file. In this situation an error message is displayed and combination (combo) patch must be used.
Table 17-2 gives an overview of the Oracle Communications Services Gatekeeper configuration files.
WebLogic Server. See the section describing the domain configuration files in Oracle WebLogic Server Understanding Domain Configuration at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/domain_config/
...A set of <app-deployment> specific for the deployed communication services. See the Deployment Artifacts section for the relevant communication service in
Communication Service Reference.
Do not edit this file manually. To manage the life-cycle of communication services, use the WebLogic Server tools, such as the Administration Console’s Deployment page or the command line tools described in Oracle WebLogic Server Deploying Applications to WebLogic Server at
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/deployment/
|
|||
|
|||
|
|||
|
Table 17-3 describes the Oracle Communications Services Gatekeeper container services. The interfaces to these, together with common classes, are packaged in
$BEA_HOME/ocsg_4.1/server/lib/wlng/wlng.jar
The container services are packaged in separate JARs, located in $BEA_HOME/ocsg_4.1/modules
Table 17-4 describes the retired Oracle Communications Services Gatekeeper container services. These services are deprecated and are not deployed as a part of standard Oracle Communications Services Gatekeeper installation. The services are packaged in:
wlng_at_bc.ear
, see Table 17-4.wlng_nt_bc.ear
, see Table 17-5.
Used by applications to establish sessions. Uses the Access service, see Table 17-5s.
|
By default, the Orbacus ORB is started when Oracle Communications Services Gatekeeper starts.
The ORB binds to the same IP as WebLogic Server binds to. This can have impact on, among other things, the IOR callbacks having localhost
in them if WebLogic Server is configured to listen to localhost
.
If a deployment does not use any of the CORBA features, the ORB can be disabled.
When the ORB is disabled none of the EARs that contain modules that require CORBA can be deployed. This includes the EARs that contains any of the Retired container services and also any communication service EAR that includes an OSA/Parlay-type network protocol plug-in. See the administration section for each communication service for information about which parts of the communication service EAR are related to the OSA/Parlay-type network protocol plug-ins.
To disable the ORB, do the following steps on all servers:
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 Oracle WebLogic Server Upgrading WebLogic Application Environments at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/upgrade/index.html