|
|
The licensing model for WebLogic Network Gatekeeper is based on the idea of the transaction unit. This book describes how transaction categories are monitored and how transaction units are calculated.
Licensing for WebLogic Network Gatekeeper is based on a maximum allowed rate (measured in transaction units per second or TUPS) during a specific time period per 24-hour interval. As Network Gatekeeper runs, it continuously counts the number of transactions it processes. Every 5 minutes that count is stored. After 24 hours of use, the busiest 60 minute window (the busy hour) is identified and the total number of transaction units processed in that period is divided by 3600.
Every day this computed busy hour TUPS value is compared to the rates specified by the license agreement as represented in the license key file. If the calculated TUPS rates are higher than the rates allowed by the license key, alarms are raised and logs are written.
| Note: | By contract, anyone operating Network Gatekeeper in a production environment must monitor the transaction rate and report any breaches in the licensing agreement to BEA. As well, anyone operating Network Gatekeeper in a production environment must agree to produce historical license logs upon request from BEA, backdating for a time period as defined in the license agreement. |
What specifically constitutes a transaction unit is based on the type of functionality being measured. Sending a Short Message is not the same as setting up a call between two parties. In general, Network Gatekeeper licensing is set up in a tiered manner, using two large transaction categories, Base Platform and BEA Module. License monitoring and enforcement is based on the TUPS rates associated with these two transaction categories. For more information, see Transactions - Categories and Units.
| Note: | TUPS rates measures only usage inside Network Gatekeeper. As a result transaction units can be logged even in the case when end-to-end requests fail, if that failure is due to errors in elements outside Network Gatekeeper. What this means is: |
WebLogic Network Gatekeeper keeps track of transaction units at two basic levels:
The larger and more general rate category is Base Platform TUPS. The Base Platform TUPS rate is the sum of the TUPS limits for Platform Services, Custom Modules, and BEA Module TUPS.
Platform Services covers general services that can be used by multiple capabilities.
These services support application-initiated requests only.
A Callable Policy transaction unit is recorded in the following situation:
A Subscriber Profile transaction unit is recorded in the following situation:
Network-triggered scenarios are not applicable for subscriber profile or callable policy transaction categories.
Custom Modules covers communication services or custom modules created using Network Gatekeeper’s Extension Toolkit.
In general there are two main types of custom module transactions:
A transaction unit for a custom module application-initiated scenario:
Network Gatekeeper processes a request that is submitted by the application and passes it to the underlying network node and Network Gatekeeper processes the response that is submitted by the underlying network node and passes it to the application.
| Note: | The exact sequence of request and response is defined during the extension module development project. |
Figure 1 illustrates when a generic extension module application-initiated transaction unit is logged. The illustrated operations are generic and abstract and would depend on which application-facing interface and/or network protocol the communication service is using.
A transaction unit for a custom module network-triggered scenario:
Network Gatekeeper processes a request that is submitted by the telecom network node and passes it on to the application, which processes it and returns a response to Network Gatekeeper, which passes it on to the telecom network node.
Figure 2 illustrates when a generic custom module network-triggered transaction unit is logged. The illustrated operations are generic and abstract and would depend on which application-facing interface and/or network protocol the communication service is using.
The second rate category is BEA Module TUPS. The BEA Module TUPS rate is the allowed total transaction rate for communication services delivered as a part of WebLogic Network Gatekeeper. The BEA Module TUPS rate is the absolute limit for non-custom communication service transactions; that is, Base Platform capacity beyond the defined BEA Module capacity cannot be used for any BEA delivered communication service.
For definitional purposes, BEA Module-based communication services are divided into the following transaction groups:
The Messaging transaction group covers transactions for the following Parlay X 2.1 communication services:
It also covers transactions for all Extended Web Services WAP Push communication services and the Binary SMS communication service.
There are two main types of transaction units in the Messaging group:
In an application-initiated scenario, a transaction unit consists of the following sequence:
Network Gatekeeper receives a request from an application and passes it on to the underlying network node. If notifications have been set up, Network Gatekeeper also receives the delivery notification from the network and passes it back to the application. Even if the message is distributed to a group of destination addresses, only one transaction unit is logged per message.
| Note: | If the application is not registered for delivery notifications, the transaction unit is not affected. |
In a network-triggered scenario, a transaction unit consists of one of the following two sequences:
The Mobility transaction group covers transactions for the following Parlay X 2.1 communication service:
There are two main types of transaction units in the Mobility group:
In an application-initiated scenario, a transaction unit consists of one of the two following sequences:
| Note: | An immediate check followed by a status notification is considered two transaction units. |
A transaction unit is not recorded in the following situation:
In a network-triggered scenario, a transaction unit consists of the following sequence:
Network Gatekeeper receives a notification request that is submitted by the network node and then passes it on to the application.
| Note: | For the purposes of logging transaction units, all notification triggers are equivalent: periodic, geographical, or state-change based are logged in the same manner. |
The Call Control transaction group includes transactions for the following Parlay X 2.1/3.0 communication services:
There are two main types of transaction units in the Call Control group:
In an application-initiated scenario, a transaction unit consists of one of the following:
In a network-triggered scenario, a transaction unit consists of one of the two following sequences:
The Presence transaction group covers transactions for the following Parlay X 2.1 communication service:
There are two main types of transaction units in the Presence group:
In an application-initiated scenario, a transaction unit consists of the following:
Network Gatekeeper receives a polling request for user presence information from an application and passes it to the underlying network node. Network Gatekeeper then receives the immediate response that the underlying network node returns and passes it back to the application.
In a network-triggered scenario, a transaction unit consists of the following:
Network Gatekeeper receives a status change notification request from the network node and passes it on to the application.
|