This chapter describes configuration and maintenance attributes and operations for the Tier Routing Manager. It also provides a workflow for the configuration:
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:
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:
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.
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.
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:
Managed object: Container ServicesTierRoutingManagerMBean
Below is a list of attributes and operations for configuration and maintenance:
Adds a new tier route. A route is identified by an index.
addTierRoute(endpointExpression : String, clusterName: String, index: int)
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 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.
Displays the list of tier routes. The list includes:
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.