This chapter describes Open Services Architecture (OSA)/Parlay Gateways and explains how to connect them to Oracle Communications Services Gatekeeper.
This section describes the general model Services Gatekeeper uses to deal with OSA/Parlay gateways.
Services Gatekeeper communication services use an internal service, Parlay Access, to manage all connections with OSA/Parlay Gateways. A plug-in that connects to an OSA/Parlay Service Capability Server (SCS) asks the OSA Access service for a connection, and the service handles all of the details of authentication, service discovery, and load management toward the OSA/Parlay framework before returning the handle for the SCS to the plug-in.
The following concepts relate to a plug-in connected to an OSA/Parlay Gateway:
An OSA/Parlay Gateway is identified by a gatewayId, which represents the actual OSA/Parlay Gateway. Each OSA Gateway used is registered in Services Gatekeeper. Any certificate to be used when authenticating with the OSA/Parlay framework is associated with the gatewayId.
Each OSA/Parlay Gateway has one or more OSA/Parlay Gateway Connections, identified by a connectionID. Multiple connections are used if the actual OSA/Parlay Gateway contains more than one Framework. The link between the OSA Gateway and the OSA Gateway connection is the gatewayID/gwID.
An OSA/Parlay client represents the account in the OSA/Parlay Gateway. An OSA client has the following attributes:
OSA client application ID, made up of the Enterprise Operator ID and the Application ID as provisioned in the OSA/Parlay Gateway,
Depending on the authentication method used, a private key (with associated password and keystore password) and public certificate to be used when authenticating.
An OSA/Parlay client mapping maps an OSA/Parlay client with OSA/Parlay SCSes. There must be at least one OSA/Parlay client mapping per OSA SCS being used. If the communication service uses n OSA/Parlay SCSes, n client mappings must be defined. Three different models are possible for the OSA/Parlay client mapping:
The client mapping can use wild cards for both the service provider and the application level, so all applications from all service providers are mapped to a single Client. In this case, transactions in the OSA/Gateway are traceable only to Services Gatekeeper because Services Gatekeeper, from the OSA/Parlay Gateway's viewpoint, acts as one single application.
The client mapping can use a wildcard for the application level and specify the service provider, so multiple Services Gatekeeper applications that originate from a common service provider are mapped to a single OSA client. In this case, the transactions in the OSA/Gateway are traceable only to the service provider because Services Gatekeeper, from the OSA/Parlay Gateway's viewpoint, acts as one application per service provider.
The mapping may be set up per application level, so there is a one-to-one mapping between an Services Gatekeeper service provider and application account combination and the equivalent client. This means that every transaction originating from a specific application results in a transaction in the OSA/Parlay Gateway that is traceable to that specific application because Services Gatekeeper, from the OSA/Parlay Gateway's viewpoint, acts as one application per service provider and application combination.
Note:
Combinations of the above are not allowed. The Services Gatekeeper administrator must choose one of these connection modes and use the same mode for all Services Gatekeeper applications. In the first case, the connection is a systemwide configuration. In the other two cases, the connection is set up as a part of the provisioning chain for Services Gatekeeper service providers and their applications.Defining the OSA/Parlay client mapping is a part of the provisioning chain in when setting up service provider and application accounts if the client mapping is of type b. or type c.
Each OSA/Parlay Client mapping has a state:
Active, when the connection between Services Gatekeeper and a specific SCS in the OSA/Parlay Gateway is active and functional.
Inactive, when there is no active connection. This may be because the client mapping is not configured to be initialized at startup and no requests have yet been passed to it. It may also indicate that there is a problem with the connection.
The OSA/Parlay Gateway administrator must provide the following information with regard to the OSA/Parlay Gateway account and OSA/Parlay Framework:
The entOpId (Enterprise Operator ID): Depending on how the OSA/Parlay operator administers applications (OSA/Parlay clients), the entOpId can be valid for:
All applications registered in Services Gatekeeper
All applications connected to a service provider account
A single application account
The appId (Application ID) to be used for the application account; used with the entOpId in clientAppId parameters to various operations
The OSA/Parlay service types for the OSA/Parlay SCSes to which the application is to be mapped
The encryption method used
The signing algorithm used
Connection information for the OSA/Parlay Framework, either:
name service reference file to the OSA/Parlay Gateway Framework's Parlay IpInitial object.
name of the initial object in the name service and the file containing the Interoperable Object Reference (IOR) to the IpInitial object.
If the authentication method toward the OSA/Parlay Framework requires a certificate, the Services Gatekeeper administrator must generate one and distribute it to the OSA/Parlay Gateway administrator. The associated key must be stored in the Services Gatekeeper keystore. This is done when the OSA client is created: see "Creating an OSA client" for details.
For non-production environments, the WebLogic Server CertGen utility can be used to create certificates and keys.
To connect an application account to an OSA/Parlay Gateway:
Create a logical representation of the OSA/Parlay Gateways to connect to. See "Adding an OSA/Parlay Gateway" for details.
For each Framework in the OSA/Parlay Gateway, create a logical representation of the Framework. See "Adding an OSA Gateway Connection".
Define how Services Gatekeeper connects to the OSA/Parlay Gateway.
If Services Gatekeeper connects to the OSA/Parlay Gateway as one single user, register this user. See "Creating an OSA client".
If Services Gatekeeper connects to the OSA/Parlay Gateway as several users, the registration of users is a part of the provisioning flow for service providers and applications.
The registration of which SCSes to use in the OSA/Parlay Gateway is done either as a part of the configuration flow for the communication services or as a part of the provisioning flow for service providers and application. The procedure is described in "Mapping the OSA client to an OSA Gateway and an OSA/Parlay SCS", and the data to be used is described in the configuration section for each communication service.
An OSA/Parlay Gateway connection is the entity representing an OSA/Parlay Gateway. One or more OSA Gateway Connections can be associated with the OSA Gateway.
If authenticating using certificates, get the certificate for the OSA/Parlay Gateway from the administrator of the OSA/Parlay Gateway and store it on the local file system of the Services Gatekeeper administration server.
Starting in the configuration and operations page for Plugin_Parlay_Access_communication service, select addGw from the Select An Operation list.
The parameters for the operation are displayed.
Enter the gateway information using the ParlayAccessMBean addGw method.
Click Invoke.
The OSA Gateway is created. An ID for the OSA Gateway is returned.
An OSA Gateway connection is the entity representing an individual Framework in an OSA/Parlay Gateway.
Get information about how to obtain a reference to the OSA/Parlay Framework from the administrator of the OSA/Parlay Gateway. These options are possible:
The name service reference file. Store the file on the local file system of the Services Gatekeeper administration server.
The name of the initial object in the name service and the file containing the IOR to the Parlay initial object. Store the file on the local file system of the Services Gatekeeper administration server.
The IOR is provided as a String.
Starting in the configuration and operations page for Plugin_Parlay_Access_communication service:
If the IOR is provided as a file use the addConnection method
If the IOR is provided as a String use the AddConnectionIOR method
Click Invoke.
The OSA Gateway Connection is created. An ID for the OSA Gateway Connection is returned.
The OSA client is the entity being used when creating the OSA client mapping.
If you are authenticating using certificates, create, or get from a Certificate Authority, the private key and certificate for the client and store them on the local file system of the Services Gatekeeper administration server.
Starting in the configuration and operations page for Plugin_Parlay_Access_communication service, select addClient from the Select An Operation list.
The parameters for the operation are displayed.
Enter client information using the ParlayAccessMBean addClient method.
Click Invoke.
The OSA client is created.
The mapping may be applied on service provider account, application account, or Services Gatekeeper level.
Note:
One mapping must be created for each OSA/Parlay SCS (network service) the Services Gatekeeper application is using in the OSA/Parlay Gateway.Starting in the configuration and operations page for Plugin_Parlay_Access_communication service, select addMapping from the Select An Operation list.
The parameters for the operation are displayed.
Enter mapping information using the ParlayAccessMBean addMapping method.
Click Invoke.
The OSA client mapping is created.
For a description of the attributes and operations of the ParlayAccessMBean MBean, see Oracle Communication Services gatekeeper OAM Java API Reference.