A Service Level Agreement (SLA) is defined by the Parlay gateway and is used to verify that an application is authorized to use a service. The Parlay Connector signs service agreements on behalf of a telecommunications application.
The Parlay Connector must first select a service manager object and then obtain the object from the Parlay gateway before an application can use a service installed on the Parlay gateway. After the connector authenticates with the gateway, it determines what services are installed and active on the gateway and begins the process of selecting and obtaining service manager objects from the gateway. The connector must sign a service agreement with the gateway for each service manager it requests. The result of successfully signing a service agreement is a reference to the requested service instance.
The Parlay Connector uses configuration data to control dynamic loading of the service agreement signing classes. This enables you to accept the default service agreement signing classes or to configure customized service agreement signing classes.
If the Parlay Connector computes or verifies a digital signature during the process of signing a service agreement, you must configure encryption. In most cases, this is the only configuration needed for the Parlay Connector to sign or terminate service agreements with the Parlay gateway.
Typically, the client must use the same agreement text as the gateway. You do not need to configure agreement text unless the target gateway requires some other flow or does not use the same agreement text.
Typically, the client also uses the agreement text provided by the gateway as termination text. Therefore, you do not need to configure the Parlay Connector to terminate service agreements with the Parlay gateway. You might need to configure termination text if the target gateway requires termination text other than the agreement text provided by the gateway.
The default implementation of the ServiceAgreementManager interface begins the service agreement signing process and then waits for the Parlay gateway to call the ServiceAgreementCallback object. When the ServiceAgreementCallback object returns a digital signature to the gateway, the ServiceAgreementManager object requests a service manager object from the gateway. In this request, the ServiceAgreementManager object specifies the same agreement text and signing algorithm that the gateway specified when it called the ServiceAgreementCallback object.
The default implementation of the ServiceAgreementCallback interface computes a digital signature when called by the gateway to sign a service agreement. If the digital signature computed by the ServiceAgreementCallback object is accepted by the gateway, the gateway returns its own digital signature and the requested service manager object to the Parlay Connector.
When customized processing is needed to obtain service manager objects from the Parlay gateway, the Service Agreement Manager class name and the Service Agreement Callback class name classes implement the required customized logic.
The class configured for Service Agreement Manager class name must implement the ServiceAgreementManager interface. This class provides the necessary NEP vendor-specific processing to sign service agreements with the Parlay gateway and returns the service manager object to the Parlay Connector.
The class configured for the Service Agreement Callback class name must implement both the ServiceAgreementCallback interface and the IpAppServiceAgreementManagement interface. This class responds to the Parlay gateway when called to sign service agreements.
Service agreement processing is usually symmetrical. This means you must customize the Parlay Connector to Parlay gateway processing and the Parlay gateway to Parlay Connector processing. Depending on the type of customization you might not need both customized classes.
The Parlay Connector creates a hash table containing its configuration and state information. This hash table is passed to the custom classes. This allows you to provide all configuration data needed by the custom classes during Parlay Connector configuration.
The Parlay gateway Service Agreement Management (signing algorithm preferences), initiates service agreements, passes agreement texts, required signing algorithms, and the return of digital signatures.
The default implementation of the Service Agreement Manager interface begins the service agreement signing process and then waits for the Parlay gateway to call the Service Agreement Callback object.
The Service Agreement Callback object will return a digital signature to the Parlay gateway, while the Service Agreement Manager object requests a service manager object from the Parlay gateway. In this request, the Service Agreement Manager specifies the same agreement text and signing algorithm that the Parlay gateway specified when it called the Service Agreement Callback object.
If the Parlay gateway accepts the digital signature computed by the Service Agreement Callback object, then the Parlay gateway returns its own digital signature and the requested service manager object to the Service Agreement Manager. The default implementation of the Service Agreement Callback interface computes a digital signature when called by the Parlay gateway to sign a service agreement.
If custom support is needed for to manage the service agreement with a Parlay gateway, either the Service Agreement Manager class name configuration field or the Service Agreement Callback class name configuration field, or both, can be used to specify custom classes.
When there is more than one service manager instance for a service type and each instance has different properties, the Parlay Connector might not be able to determine which service manager instance to use for signing service agreements with the Parlay gateway. If all of the service manager instances for a service type meet the needs of your application, you do not need to specify service properties for a service type. Otherwise, you might need to define service properties to ensure that the Parlay Connector selects the correct service manager instance from the Parlay gateway.
Although Parlay service managers are normally on remote computers, you can configure to obtain service managers implemented locally if the service managers meet certain requirements.
You can configure the Parlay Connector with a local service manager implementation using a service type name defined on the Parlay gateway. In this case, when your application specifies that service type name in a Parlay Connector API, the Parlay Connector considers the specified service type to be the local implementation and not the service type that the Parlay gateway provides.