Oracle® Communications Services Gatekeeper System Administrator's Guide Release 5.0 Part Number E16623-02 |
|
|
View PDF |
This chapter describes how to configure and maintain attributes and operations for the Tier Routing Manager. It also provides a workflow for the configuration.
Applications can interact with these Service Facades when using Services Gatekeeper communication services:
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 are routed to the correct Service Facade by an identifier which specifies the Service Facade used when setting up the subscription. The Tier Routing Manager uses this identifier to route network-triggered requests to the appropriate Service Facade, or more specifically to the correct Access Tier cluster. 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. |
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
Managed object: Container Services−>TierRoutingManagerMBean
MBean: com.bea.wlcp.wlng.tier_routing.TierRoutingManagerMBean
Following is a list of attributes and operations for configuration and maintenance:
Scope: Cluster
Adds a new tier route. A route is identified by an index.
Signature:
addTierRoute(endpointExpression : String, clusterName: String, index: int)
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). |
Scope: Cluster
Displays the list of tier routes. The list includes:
index
endpoint expression
cluster name
Signature:
listTierRoutes()
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-3 describes this parameter.