Release Notes

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Backwards Compatibility

This section covers backwards compatibility between Weblogic Network Gatekeeper 3.0 and Oracle Communication Services Gateway 4.0. The following areas are discussed:

 


Platform Upgrades

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.

 


Communication Services

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.

 


Extensions

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:

 


Partner Relationship Management

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.

 


Operations and Management

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

Database schemas have been changed and migration scripts are provided for upgrades.

 


EDR Generation

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.

 


Service Level Agreements

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.

SLA XSDs are split into:

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:


  Back to Top       Previous  Next