WebSphere brand IBM WebSphere Telecom Web Services Server, Version 7.1

Standard configurations for Telecom Web Services Server

WebSphere® Telecom Web Services Server (TWSS) is deployed in a clustered environment. It consists of three logical components: Access Gateway, Service Platform, and Service Policy Manager. You can configure these components in several different ways.

How the components interact

The Access Gateway builds on the WebSphere ESB (Enterprise Service Bus) platform and provides policy-driven traffic monitoring, capture, authorization, and management capabilities. These services are provided at the application layer and are enforced for each Web service request using the knowledge of the requester, target service, and invoked operation.

The Service Platform consists of an application server with enhanced support for telecom protocols and callable components for common service function. The service implementations can include custom Web service interface definitions and backend implementations. For the most part TWSS uses the Parlay X Web service APIs as a standard interface abstraction for telecom network functions. But the architecture is general enough to provide infrastructure services for any kind of Web service implementation.

The Service Policy Manager provides access function and management for policy configuration data, and the runtime data used to customize service delivery for a given requester.

A loose model based on SOAP messaging is used between the Access Gateway and the Service Policy Manager, enabling flexible deployment. However, service deployments typically require a front-end traffic management component to meet non-function service requirements, and the preferred deployment model is of the Access Gateway fronting service implementations. In addition, the WebSphere ESB platform provides rich integration capabilities for the TWSS components, providing a point of flexibility for how different components are connected.

Initiating the TWSS request flow

For TWSS, the requester principal value is checked by the Trust Association Interceptor (TAI), if the TAI is deployed. The value, set by TWSS for the Service Platform, validates the originated request in the trusted network.

The following steps describe how the request flow is initiated for TWSS.
  1. The Access Gateway authenticates the requester using WebSphere, and authorizes the requester through the use of policies. The authenticated requester then receives an asserted identity that is passed to all subsequent services.
  2. The Access Gateway adds an asserted identity header to the request.
    Note: The Trust Association Interceptor (TAI) security component is the recommended security mechanism for handling traffic from the IMS network. A single sign-on scheme is recommended for handling transactions between the Access Gateway and the Service Platform components, and optionally between the Access Gateway and the Service Policy Manager.
  3. The Access Gateway then sends the request to one of the TWSS Web service implementations to perform the work and complete the operation and the response.

Topology

In a typical topology, there is a cluster for the Access Gateway (running with WebSphere ESB) and another cluster for the Service Platform components (running with WebSphere Application Server). The Service Policy Manager can be deployed in a unique cluster or in the same cluster as the Service Platform components.

Note: If you are running WebSphere Application Server version 6.1.0.29, the TWSS Access Gateway can coexist in the same cluster with the Service Platform components. However, when the Service Platform components are deployed in a cluster running WebSphere Application Server version 7.0.0.7, the Access Gateway must be deployed in a separate cluster.

The following diagram illustrates a network topology in which each TWSS component is deployed in a unique cluster.

Example hardware topology for TWSS

While you can define deployment managers for both the Access Gateway and the Service Platform components together on a single server, they are actually distinct deployment managers.

It is important to note that the First Steps script deploys and configures all of the base components and services that are installed on the server where it runs. Configurations in which a single server is shared between multiple clusters, and a different set of services is deployed on each cluster, are not supported.

If you are deploying Web services that are implemented over Parlay 3.x and 4.x APIs, you can also deploy the Parlay Administration Console on the same server. The Parlay Administration Console should use the same deployment manager as the Service Platform components.




Terms of use
(C) Copyright IBM Corporation 2009. All Rights Reserved.