This section covers backwards compatibility between Weblogic Network Gatekeeper 3.0 and Oracle Communication Services Gateway 4.0. The following areas are discussed:
Upgrade from Network Gatekeeper 3.0 to Gatekeeper 4.0 are supported. The upgrade process requires a full cluster restart and will need to be scheduled during a maintenance window. WebLogic Server does not support hitless upgrades across major releases, so this is a result of the fact that the base platform used by Gatekeeper has been upgraded from WebLogic Server 9.2 to WebLogic Server10 MP1.
Scripts and tools to facilitate upgrade and migration of data are provided.
Upgrades from Network Gatekeeper 2.2 are not supported. They are considered new installations.
There are some changes in out-of the box communication services.
OSA/Parlay connectivity has been removed from the standard platform, except for the Parlay X 3.0 call control related services, which based directly on customer-driven requirements. As a result, the following communication services have been removed from the standard platform:
Backwards compatible communication services based on the deprecated Network Gatekeeper 2.2 and earlier CORBA based architecture are no longer supported. That is, the architecture that relied on the SESPA and ESPA modules is no longer supported. All OOTB communication services in this release, including the ones in 3.0 that were built on the older architecture, use the new architecture.
In addition. exceptions thrown by Extended Web Services interfaces are now aligned with Parlay X exceptions. That is, ESVCxxx
is now SVCxxx
and EPOLxxx
is now POLxxx
.
Traffic paths and plug-ins built using Network Gatekeeper 3.0 Extension Toolkit must be adapted to the features of this release. Because there is a new deployment model for communication service and because the Extension Toolkit has been restructured and folded into the Platform Development Studio, extensions built in the 3.0 architecture are source compatible only and cannot be directly deployed. See section Converting Traffic Paths and Plug-ins to Communication Services in Platform Development Studio - Developer’s Guide for more information.
Extension plug-ins that use the storage service need to be repackaged to deploy their schema configuration using the new storage service configuration deployment model.
Backwards compatible communication services based on the deprecated Network Gatekeeper 2.2 and earlier CORBA based architecture are no longer supported. They must be re-implemented using the new architecture.
Extension APIs that are deprecated:
Support for provisioning of data specific to individual communication services has been removed from the PRM interfaces. The PRM interfaces are re-positioned to provide on-boarding, workflow management, monitoring and SLA provisioning for applications and service providers. Provisioning of individual communication services should be performed using JMX.
All OAM MBean interfaces have been updated as a result of unified exception handling and support for MBean hierarchies.
All return types and exceptions for the MBean have been packaged in a JAR file, $PDS_HOME/wlng_pds400/lib/wlng/oam.jar
, for easy of JMX integration.
All OAM interfaces based on IDL/CORBA have been removed and aligned with standard JMX.
The following OAM interfaces have been removed:
Of particular interest are the ESPA_Access and SESPA_Access MBeans which have been replaced with a set of MBeans under com.bea.wlcp.wlng.account.*
The interfaces have been removed either because of the overall MBean updates or because their functionality has been removed from the platform.
The text-based Management Tool has been discontinued and is replaced by WLST.
Unused Alarm IDs have been removed.
Database schemas have been changed and migration scripts are provided for upgrades.
The contents of cdr.xml, edr.xml, and alarm.xml have been consolidated into $DOMAIN_HOME/config/custom/wlng-edr.xml
. This file should only be edited using the EDR configuration pane in the Administrative Console.
SLA schemas are now controlled and managed in conjunction with the release cycle of the product. This means that extending SLA schemas is no longer supported.
The attribute serviceProviderGroupID in the Global Node SLA is deprecated and made optional in the XSD.
The following SLA elements are removed from the Global Node SLA XSD:
The following SLA elements are removed from the Service Provider Node SLA XSD:
The following SLA elements are removed from the Service Prover Group and Application Group SLA XSDs: