Here is a summary of the TWSS components,
database tables, and other network elements that are required when
you deploy Parlay X Terminal Location over
Parlay.
This topic provides information about what is needed in the network
in order to deploy the Web service implementation. The order in which
the information is presented does not represent the order in which
the elements should be installed.
When you deploy this Web service implementation, your network should
include the following elements:
- The WebSphere® Application Server
platform
- A shared file system space to store the JMS queue file store
Access Gateway
The Access Gateway must
be installed in the network and is typically in a different cluster
than the Web service implementation. All incoming calls are routed
through message processing flows, which are deployed on the Access Gateway. A default Terminal
Location message processing flow is provided and should be deployed,
unless you are using a custom message processing flow.
Service Policy Manager
The Service Policy Manager must
be installed in the network, either in the Service Platform cluster
or in its own cluster. The Service Policy Manager manages
policies associated with the Web service implementation. When the
database tables are created, they are populated with default policies.
For information about default policies, see the Reference section
of this information center.
TWSS Administration Console and Parlay Administration Console
The
consoles must be installed on the deployment manager node for the
cluster where the Web service is deployed. The TWSS Administration Console must
be installed before the Parlay Administration Console.
The TWSS Administration Console is
used to configure the Web service implementations and the Service Platform components and
to specify how they should be invoked. It is also used to administer
MBeans that are included in the EAR file for the Web service implementations.
It is managed through JMX.
The Parlay Administration Console is
used to configure the Parlay Connector.
Both console plug-ins
act as extensions to the Integrated Solutions Console.
Service Platform components
The Service Platform components must
be installed on the same cluster node as the Web service implementation.
If the cluster is configured to synchronize, you can deploy the Service Platform components on
the network deployment manager node. Some Service Platform components may
be optional and, if so, are noted as optional in the following list.
Interactions with other Service Platform components are
also noted.Table 1. Service Platform components for Parlay X Terminal Location over
ParlayService Platform component |
Required? |
Remarks |
Admission Control |
No |
When the Admission Control component Web service is
available, the Web service implementation issues a VerifyAdmittableRequest to
the Admission Control component to determine if the service request
can be processed. |
Traffic Shaping |
No |
Not used. |
Network Resources |
No |
Recommended in an
integrated environment–that is, in a full setup where all of the TWSS
components (Access Gateway, Service Policy Manager,
and so forth) coexist. |
Notification Management |
Yes |
The startNotification operation issues a RegisterNotification
request. |
PX Notification |
Yes |
The Web service
implementation sends notification messages synchronously
to applications through this component. A retry mechanism has been
added to the notification delivery of Parlay X services. |
Address Masking |
No |
When deployed,
the Address Masking component Web service works
in conjunction with the Address Masking mediation primitive (part
of the processing flow for the Access Gateway). |
Fault and Alarm |
No |
Recommended. When the Fault and Alarm component Web service is
available, the Web service implementation issues a RecordFaultRequest request
to the Fault and Alarm component to generate a fault or an alarm when
the following conditions occur:- A Parlay X Terminal Location over
Parlay fault
condition is detected.
- An Admission Control component Web service fault
occurs.
- A Usage Record component Web service fault
occurs.
- A PX Notification component Web service fault
occurs
|
Usage Record |
No |
When the Usage Record component Web service is
available, the Web service implementation uses it to record information
about services rendered for status and billing purposes. |
Parlay Connector
The Parlay Connector
enables the Web services to communicate with a Parlay gateway. In
a production environment, an additional Parlay gateway may be configured
for failover. When you have multiple Parlay gateways in your network,
you must configure unique service IDs for each gateway. The Web service implementations use
the gateway session IDs and assignment IDs as references to track
requests sent to the gateway. The Parlay Connector is included in
the file Pxx_ParlayConnector.ear (where xx is
the Parlay version, such as 42 or 33).
To configure the Parlay
Connector, use the Parlay Administration Console. The Parlay Administration
Console must be installed on the network deployment manager for the
cluster where the Web service is deployed.
JMS queues
When you deploy Parlay X Terminal Location over
Parlay,
a JMS queue is required for the PX Notification component Web service.
When
setting up the service integration buses, the
First Steps script will
configure a permanent file store or datastore. If you choose to configure
the file store manually, the file store should be stored on a mounted
NFS drive. Each instance of the Web service in the cluster should
use the same permanent store directory path.
Note: When you use the First Steps script to
automate your configuration, the service integration buses are defined
for you. However, you will need to provide a file system directory
on the NFS shared drive.
Database
Database
tables must be created to store configuration and policy data. You
can use a single database to store this data, or you can create a
unique database for each type of data. When you use the First Steps script,
the required tables are created for a single database configuration.
If you choose to use multiple unique databases,
or if you prefer to configure the database tables manually, you can
find additional information in the topic Planning for the database.
DB2® and Oracle databases
are supported.
Other interactions
The
Parlay X Terminal Location over
Parlay Web
service implementation interacts with network elements and other entities.
The following interactions are important:
- HTTP proxy: An HTTP proxy needs to be configured. WebSphere Application Server includes
an HTTP proxy that can be used for this purpose.
- Parlay gateway: The Parlay gateway is a server that hosts the
service implementations for the Parlay API. Parlay X Terminal Location over
Parlay connects
to it by means of the Parlay Connector. The Parlay API consists of
various telecom service APIs, which provide an abstract interface
to network elements deployed in your network. The Parlay Connector
converts Java™ method calls to
CORBA calls, which adheres to the Parlay API of the Gateway.