The Parlay API consists of two sets of interfaces, the Framework Interfaces and the Service Interfaces. The Framework Interfaces provide the supporting capabilities necessary for the Service Interfaces to be secure, resilient, located and easily managed. The Service Interfaces enables applications access to a range of network capabilities and information.

Implementation of the API specification will enable more, and cheaper services as well as create a more competitive market for telecom applications and services.

Application developers

• The Parlay API will make application communication service opportunities available to most software developers.  
• Application developers will be able to focus on creating value-added functionality without being hindered by the intricacies of network technologies.

Network operators:

• Considerable market growth as new service provider applications will increase network traffic demand and revenue.  
• The ability to address niche market requirements as a result of service providers using custom-built applications.  
• Quicker marketing of new applications due to access to a large application development community enabled by publicly available interfaces.

Service providers:

• Significant market opportunities for new services, or improvements to existing services, that depend on the Parlay/OSA API.  
• The ability to address niche market requirements by using custom built applications that exploit the API.  
• Quicker marketing of new applications.  
• The ability to cope with additional network capabilities as they become available through new communication technologies.

End-users

• Numerous application solutions, including niche applications, available from a wide range of application developers at a price that reflects a highly competitive open market for communication applications.  
• Retaining control of highly important databases and functions.  
• Availability of a wide range of applications

Operators have adopted the Parlay API all over the world. It is technology independent. Ericsson Network Resource Gateway will enable the applications to use the capabilities of circuit switched mobile and fixed networks as well as of packet based networks without adapting the application itself. Ericsson is committed to be compliant with the Parlay Group API specification. For this reason any Parlay compliant application will inter-operate with Ericsson Network Resource Gateway.

In a nutt-shell, the Ericsson Network Resource Gateway SDK is set of Java libraries, example code, tools and documentation, aimed at reducing the development costs of applications that use features offered by Ericsson Network Resource Gateway.

The SDK has been designed to hide as much CORBA details as possible, while compromising the capabilities and performance as little as possible. This reduces the learning curve for programmers with no or little experience with CORBA. In addition, there are several other features such as Ericsson Network Resource Gateway cluster transparency and method interception that can reduce the development time for all but the most experienced programmers.

Scalability of applications using the SDK API is limited. The main reason is that SDK API objects are bound to one JVM, and hence cannot be exchanged between processors. Note that the Test API provides some support for serializing and de-serializing SDK objects, thus allowing for the exchange of SDK objects between JVMs. This feature is used by the Ericsson Network Resource Gateway Automated Test Tool of the Ericsson Network Resource Gateway SDK Example Applications, to emulate a redundant node configuration. A similar solution is under consideration for future versions of the Core API.

No specific attempts are made to keep the SDK API future compatible, in the sense that applications written using a particular version of the SDK API may not compile or run properly when a downgrade to an earlier version of the SDK is performed.

All attempts (within reason) are made to keep the SDK API backward compatible, in the sense that applications written for an earlier version of the SDK API still compile and run properly when an upgrade to a later version of the SDK is performed. A (rare) reason for breaking backward compatibility would be if the HOSA API offered by Ericsson Network Resource Gateway itself changes in a backward incompatible way.

This does not mean that the SDK API is frozen. As the SDK evolves, interfaces are reorganized and renamed for consistency, methods are replaced by new and better methods, etc. Instead of disposing of the old API (which would result in backward incompatibility), it is marked deprecated. If an application uses a deprecated API, it continues to work, but the compiler will issue a warning. Developers are strongly recommended to fix the warning because deprecated elements of the API may cease to exist in later versions of the SDK. For details, including information on how to fix a deprecation warning, refer to the overview of deprecated items for the Utility API, Core API and Test API.

When you download a file using Internet Explorer, you get a pop-up window where you can specify the path, file name and file type. When saving the second download (Ericsson_Parlay_Developers_CD_r1a_split.z01), Explorer recognizes the extension .z01 and will set the default file type to WinZip file. As a result, the file is saved with extension z01.zip instead of simply .z01. Consequently, the WinZip tool cannot find the file.

To avoid the problem, click on "Save" in the "File Download" pop-up window, then select file type "All Files" in the "Save as" pop-up window when downloading the file. Alternatively, to fix the problem after the download, simply rename the z01.zip extension .z01.

The Ericsson Network Resource Gateway (NRG) has the capability to handle multiple instances of the same Parlay application. This is also called Service Level Agreement (SLA) resigning. When a second application with the same application name creates the same notifications they will not be overwritten but the second callback will be added to the list of available callback interfaces for a certain notification. The only thing that you need to keep in mind is that both instances of the application need to sign the SLA sequentially before they start creating/enabling the notifications.
 
Depending on the SLA configuration the NRG will use the callbacks sequential or randomly (for load balancing purposes).
 
The Simulator in the latest version of the Ericsson Network Resource Gateway SDK includes a menu option Menu Client. Using the Management Client you can review and change the SLAs, providing no application has signed the SLA. When you have connected the Framework Management and have done a get action for both the service types as the client applications. You can navigate to the following place in the tree:

Through the property SP_NRG_LOAD_BALANCING the operator can specify how the callbacks should be treated for each of the service profiles. When this property is set to true it will use load balancing.
 
When there are multiple callback interfaces registered for a notification and one of them fails, the NRG will try another one. When all fail, the NRG will give up.

Question continues: We have network elements such as SMS-C that use protocol CIMD2, which is not supported by the NRG. How can we integrate these kinds of elements into NRG? Does Ericsson or one of its partners provide the necessary protocol support or do we have to develop it ourselves?

Answer: If it is a widely used protocol and the customer is willing to pay for the customization, Ericsson will of course do the adaptation.

We are always in the process of implementing support for new or updated protocols. In some cases, however, the specific customer need does not fit into our project planning, perhaps because we don't see a business case or because we do not have the resources and in area of the requested customization.

In this specific case, there is no plan for supporting the CIMD2 protocol.