|
|
The following chapter presents a high level introduction to Network Gatekeeper’s communication services, including:
A separate document, the Communication Service Reference, offers a more detailed look at specific services.
All application service request data flows through Network Gatekeeper using communication services. A communication service consists of a service type (Multimedia Messaging, Terminal Location, etc.), an application-facing interface (also called a “north” interface), and a network-facing interface (also called “south” interface).
Network Gatekeeper is deployed into two tiers: the Access Tier, which manages interactions with applications, and the Network Tier, which contains the mechanisms necessary for dealing with the underlying network nodes. For increased security, these tiers can be separated by a firewall.
Application-initiated requests (also called mobile terminated, or MT) enter through the Access Tier, where they are processed by the WLS Web Services Container. They are then sent on to the Network Tier using RMI. The Network Tier manages service authorization and policy enforcement, charging, and traffic throttling and shaping. Then the Network Tier translates the request into a form appropriate for the underlying network node.
| Note: | Although the operator may choose instead to run in a “sessionless” mode, by default, Network Gatekeeper requires that applications acquire a Network Gatekeeper session before beginning to send request traffic. Applications do this using the Session Manager interface, which returns a Session ID. The application then adds this Session ID to the header of all its subsequent SOAP requests. Network Gatekeeper can use this value to keep track of all the traffic that an application sends for the duration of the session. |
Network-triggered (also called mobile originated, or MO) traffic is also supported by Network Gatekeeper, so that applications can choose to receive data from the telecom network. To do so, the application must first send a request to Network Gatekeeper (or have the operator perform the equivalent task using OAM methods) to register a description of the types of data it is interested in - delivery notifications, incoming messages, etc. - and any criteria that the data must be meet to be acceptable. For example, an application might specify that it is only interested in receiving incoming SMSes that are addressed to the short code “12345” and that begin with the string “blue”.
| Note: | For more on short codes, see the “Parlay X 2.1 Short Messaging Communication Service” chapter in the Communication Services Reference, another document in this set. |
Figure 4-1 below illustrates typical application-initiated traffic flow.
| Note: | Sessions allow correlation among sequences of operations. They are not used for purposes of authentication. |
| Note: | All requests are authenticated in this manner, whether the application uses the session mode or not. |
In addition, the request may be further secured through encryption using the W3C’s standard XML encryption and through digital signatures using the W3C XML digital signature standard. The particular security requirements of the installation are specified in the WS-Policy section of the published WSDL file.
| Note: | It is possible to simply use the appropriate standard Parlay X 2.1 or 3.0 WSDL to create requests, but the developer would then be required to ascertain the appropriate security type from the operator, and insert the information manually. |
| Note: | Should a request fail because of an unavailable module, an interceptor retries the request using one of the remaining eligible modules. |
The key difference between application-initiated traffic flow and network-triggered traffic flow (other than the direction) is that the application must first indicate to Network Gatekeeper that it is interested in receiving traffic from the network. It does this by registering for (or subscribing to) notifications, either by sending a request to Network Gatekeeper or by having the operator set up the notification using OAM methods. For example, the application could send Network Gatekeeper a request to begin receiving SMSes from the network, indicating that it is only interested in SMSes that are sent to the address 12345 and that begin with the string blue.It also indicates the URL of the Web Service that the application has implemented to receive these notifications back.
This registration for notifications is stored in the appropriate network plug-in, which in most cases passes it on to the underlying network node itself (in certain cases the Network Gatekeeper operator must do this manually.) When a matching SMS reaches the plug-in from the network, the plug-in sends it to the Plug-in Manager, which invokes the Interceptor stack for evaluation. Then, using RMI, the final Interceptor passes the notification, along with the appropriate URL from the registration, to the Access Tier, which sends it on to the application. See Figure 3-2 and Figure 3-3 for more information on the general flow, although those figures document delivery notifications.
Some functionality is common to all communication services. This functionality includes:
All application access to WebLogic Network Gatekeeper’s communication services is governed by a set of Service Level Agreements (SLAs) between the application service provider and the Network Gatekeeper operator. Network Gatekeeper uses a two tiered account system to group application services and their providers and to simplify the creation and maintenance of SLAs:
For more information on the account system, see The Administration Model.
These SLAs define whether a member of a service provider group or application group:
For a more detailed look at Service Provider and Application SLA structure, see the “Defining Service Provider Level and Application Level Service Agreements” chapter in Managing Accounts and SLAs. For a communication service-focussed description, see the respective communication service chapters in the Communication Service Reference. These books are separate documents in the Network Gatekeeper documentation set.
SLA enforcement for communication services is provided by the Interceptor stack. As in previous versions, it is also possible to create extended rules that are evaluated using the external policy engine, which is called from an interceptor.
| Note: | These rules represent operator specific policies defined by the operator and implemented by BEA Systems or a selected partner. |
A simplified version of the flow is illustrated in Figure 4-2 below.
Network-triggered requests are also evaluated using the Interceptor stack.
There are also SLAs that help protect the underlying network node by setting priorities for sending requests, on the level of a particular service provider group or of Network Gatekeeper as a whole. Depending on the status of the underlying network, traffic can be throttled and shaped. If a particular node is overloaded, lower priority traffic can be rejected all together. For general information on these Traffic (sometimes called Node) SLAs, see The Administration Model. For more detailed information, see the “Defining Global Node and Service Provider Group Node SLAs” chapter in Managing Accounts and SLAs.
Network Gatekeeper uses special SOAP headers to authenticate service provider applications. These headers are documented in each interface’s WSDL file, in the WS-Policy section. Processing is managed by WebLogic Server’s WS-Security, which supports plaintext or digest passwords, X.509 certificates, or SAML tokens for authentication. To guarantee the confidentiality of communication between WebLogic Network Gatekeeper and the application, all traffic can be encrypted - fully or partially - using W3C’s standard XML encryption. Message integrity can be assured using the W3C XML digital signature standard. Again, the WS-Policy section of the published WSDL for each interface describes if and how either of these standards is being used. For more information on WebLogic Server’s capabilities, see the “Configuring Message Level Security” chapter in WebLogic Web Services: Security, a separate document in the WLS set. Access to a particular communication service is based on the two types of SLAs discussed in Service Level Agreements and Policy Enforcement.
In addition, if the underlying network node provides an authentication interface, WebLogic Network Gatekeeper protocol plug-ins can register and be authenticated with it, making the request’s transfer to the network secure.
| Note: | This is highly dependent on the protocol and the specific implementation in the node and the plug-in. |
All WebLogic Network Gatekeeper modules can produce general events, alarms and charging events. General events are expected system occurrences that are of importance to the operator, but do not need corrective action. Alarms are system occurrences that are unexpected and may require corrective action. Charging events are the basis for CDRs, the records that provide the information needed to charge for services. CDRs are written only when the transaction that brackets the request’s flow through the Network Tier commits. For more information on events and charging, see “Events, Alarms, and Charging” in the Communication Service Reference. For more information on alarms, see Handling Alarms.
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. Two TUPS rates are measured: Base Platform - the more general rate - and BEA Module - which covers only Network Gatekeeper-supplied communication services. For more information on how these rates are calculated, see Licensing, a separate document in this set.
|