System Administrator’s Guide

Managing and Configuring the Tier Routing Manager

This chapter describes configuration and maintenance attributes and operations for the Tier Routing Manager. It also provides a workflow for the configuration:

Introduction

Applications can interact with several different types of Service Facades when using Oracle Communications Services Gatekeeper Communication Services. The different types of Service Facades are:

SOAP
SOA
RESTful
Native

All Service Facades use Service Enablers to connect to the telecom network.

Application-initiated requests are automatically routed from any given Service Facade to the proper Service Enabler, since there is a many-to-one (n:1) relationship between Service Facades and Service Enablers.

Network-triggered requests needs a mechanism to resolve to which Service Facade they shall be routed. The network-triggered case is solved by attaching an identifier to that identifies which Service Facade was used when setting up the subscription to notifications on network triggered requests.

This identifier is used by the Tier Routing Manager to route network-triggered requests to the appropriate Service Facade, or rather to which Access Tier cluster the request shall be passed on to. There is one Access Tier cluster with SOA Service Facades, one cluster with RESTful Service Facades, and one cluster with SOAP Service Facades.

The routing uses tier routes to identify to which cluster to route the request. A tier route is identified by an index and has the following properties:

An endpoint expression
The name of the cluster for which the route is valid

When an application wishes to receive traffic from the network, it subscribes to notifications for network triggered events. As a part of the subscription, the application provides a URL for the endpoint to which notifications should be sent.

The SOA Service Facades uses the application-provided endpoint URL and rewrites it, embedding information that it was the SOA Service Facade that was used to set up the notification along with the original URL. This new URL is passed used the request to the Service Enabler. The SOA Service Facade replaces the original callback URL with a new URL that points to the Oracle Service Bus Proxy Service and adds the parameter realUrl that has the value of the original callback URL.

For example, if the original callback URL is:

http://somehost/services/SmsNotification

the rewritten callback URL is

http://soahost/proxySms/SmsNotification?realUrl=http://somehost/services/SmsNotification

The RESTful Service Facades always gets a callback URL starting with /bayeux/ from the application, so the URL itself provides information that the subscription originated from the RESTful Service Facade.

When a network-triggered request arrives at the Tier Routing Manager, it inspects the endpoint (rewritten) URL to extract from it the Service Facade to which it should be routed. It looks at the pattern of the URL and matches it to the configured endpoint expression type. When a match is found, it resolves the cluster name and passes the request on to the appropriate cluster.

Note:

Some network protocol plug-ins support off-line provisioning for subscriptions for notifications. The callback URL used for these subscriptions must be formatted according to the URL rewrite pattern of the appropriate Service Facade.

See Table 20-1 for examples of endpoint expressions.

Table 20-1 Examples of tier routes
Endpoint expressions	Description
.realUrl=.	Routes to a SOA Service Facade cluster, since the parameter realURL is present in the callback endpoint.
/bayeux.*	Routes to a RESTful Service Facade cluster, since the parameter bayeux is present in the callback endpoint.
http://.mydomain.com/	Routes to a specific cluster when the callback endpoint is within the domain mydomain.com. This makes it possible to inspect in which domain the callback endpoint is, and use one access cluster for a given set of service providers and another for another set of service providers. It makes it possible to use one Access tier cluster for applications residing in the network operator’s intranet and another for applications hosted by service providers outside the network operator’s domain.

Configuration Workflow

The administration of routes uses the following operations:

To add a new tier route: Operation: addTierRoute
To remove a tier route: Operation: removeTierRoute
To list all existing tier routes: Operation: listTierRoutes

Reference: Attributes and Operations for TierRoutingManager

Managed object: Container ServicesTierRoutingManagerMBean

MBean: com.bea.wlcp.wlng.tier_routing.TierRoutingManagerMBean

Below is a list of attributes and operations for configuration and maintenance:

Operation: addTierRoute

Scope: Cluster

Adds a new tier route. A route is identified by an index.

Signature:

addTierRoute(endpointExpression : String, clusterName: String, index: int)

Table 20-2 addTierRoute
addTierRoute
Parameter	Description
endpointExpression	The pattern to be used as a matching criteria for the callback URL for network-triggered operations. Each Service Facade adds its own signature to the pattern. See Table 20-1 for examples of routes. The pattern is a regular expression.
clusterName	The name of the cluster to pass the request to if the endpointExpression matches.
index	The index of the tier route. The first matching route will be used so the order of the routes are important if a URL can match multiple routes. The new entry will shift any existing entries one index higher. To insert entry first in the list, use index 0 (zero). To insert entry last in the list, use the number of list entries (the size of the list).

Operation: listTierRoutes

Scope: Cluster

Displays the list of tier routes. The list includes:

index
endpoint expression
cluster name

Signature:

listTierRoutes()

Table 20-3 listTierRoutes
listTierRoutes
Parameter	Description
-	-

Operation: removeTierRoute

Scope: Cluster

Removes a tier route. The route is identified by the index. After the update, the index of all tier routes with a higher index than the removed are decreased by one.

Signature:

removeTierRoute(index: int)

Table 20-4 removeRoute
removeRoute
Parameter	Description
index	Index if the tier route to remove.