![]() ![]() ![]() ![]() ![]() ![]() |
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, Network 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 is 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 is the 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/wlng400/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 14-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 Enterprise Application Archives.
META-INF/weblogic-application.xml
is the BEA WebLogic Server-specific deployment descriptor, see
http://download.oracle.com/docs/cd/E13222_01/wls/docs100/programming/app_xml.html.
META-INF/weblogic-extension.xml
is a BEA WebLogic Server-specific deployment dscriptor.
Listing 14-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.
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, see http://download.oracle.com/docs/cd/E13222_01/wls/docs100/programming/versioning.html.
Individual communication service are deployed and undeployed as EARs.
See http://download.oracle.com/docs/cd/E13222_01/wls/docs100/deployment/understanding.html 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 Network 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 is 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/wlng400/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/wlng400/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 14-2 gives an overview of the Network Gatekeeper configuration files.
WebLogic Server, see
http://download.oracle.com/docs/cd/E13222_01/wls/docs100/domain_config/config_files.html, with the following additions specific to Network Gatekeeper:
...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.
|
|||
|
|||
|
|||
|
Table 14-3 describes the Network Gatekeeper container services. The interfaces to these, together with common classes, are packaged in
$BEA_HOME/wlng400/server/lib/wlng/wlng.jar
The container services are packaged in separate JARs, located in $BEA_HOME/wlng400/modules
Table 14-4 describes the retired Network Gatekeeper container services. These services are deprecated and are not deployed as a part of standard Network Gatekeeper installation. The services are packaged in:
wlng_at_bc.ear
, see Table 14-4.wlng_nt_bc.ear
, see Table 14-5.
Used by applications to establish sessions. Uses the Access service, see Table 14-5s.
|
By default, the Orbacus ORB is started when Network 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 are done using SmartUpdate, see http://download.oracle.com/docs/cd/E13179_01/common/smartupdate/guide.
Patches to container services and Weblogic Server is done using rolling upgrades, see http://download.oracle.com/docs/cd/E13179_01/common/docs100/upgrade/rolling_upgrade.html.
The following patches should not be removed using SmartUpdate Tool. The Patch IDs are:
![]() ![]() ![]() |