![]() ![]() ![]() ![]() ![]() ![]() |
The following chapter provides an overview of WebLogic Network Gatekeeper’s software architecture, including:
WebLogic Network Gatekeeper provides a robust, secure and highly performant container optimized for the task of running communication services. Communication services are specialized components that allow telephony network operators to provide Internet-based application developers with a powerful but simple way to access the operator’s network services. Out of the box Network Gatekeeper supplies communication services providing Web Services access to such network capabilities as Messaging, Call Control, Terminal Location, and Presence. Extending the provided communication services or creating entirely new ones, based on the specific needs of the operator’s circumstances, is made easy with the supplied Platform Development Studio. Built on WebLogic Server 10.0 MP01, Network Gatekeeper is closely aligned with JEE standards and tightly integrated with WebLogic SIP Server.
Communication services are components that run in the Network Gatekeeper container. They provide the main functionality of Network Gatekeeper, exposing network capabilities to Internet based applications in a form that is easy to use and manage. All traffic in Network Gatekeeper is processed through these services. A communication service consists of an application-facing interface, with WS-Security based authentication; a processing layer, where requests are validated, evaluated according to Service Level Agreements, and routed; and a protocol translation layer. A more detailed description of this flow can be found in Introducing Communication Services.
Network Gatekeeper provides a container that is highly optimized for running communication services, the components of Network Gatekeeper that provide the interface between Internet based applications and the functionality of the underlying telephony network. The container leverages the many standard container services that WebLogic Server 10.0 MP1 provides, but adds a number of services designed for the specialized needs of communication services and Network Gatekeeper generally. See Figure 3-2 and Figure 3-3 below for an example. These services include:
Broadcasts events among modules and servers in the cluster
Provides transparent access to data storage using distributed caching and the database
Stores largely read-only data, such as configuration information
Initializes the Orbacus ORB and makes it the default for the system. Can be disabled for systems that do not connect to Parlay Gateways
Broadcasts events and manages their translation into charging data and alarms, as necessary
Provides support for geo-redundant installations
Manages cross-cluster bandwidth allocation, and supports geo-redundant installations. In the context of quota and rate SLAs, it also maintains an historical perspective on usage patterns
Wraps the policy engine from older versions, which can still be used
Provides SNMP service for alarms
Figure 3-2 and Figure 3-3 below show an example of the typical interaction between a communication service (the example uses PX 2.1 Short Messaging to SMPP) and container services.
In production mode, communication services are typically deployed in two clustered tiers, an Access Tier and a Network Tier, separated, if desired, by a firewall. In a single physical site installation, this corresponds to a single WebLogic Server administration domain. Each communication service is deployed in its own EAR file, one per tier.
Note: | Some EARs may contain either multiple application-facing interfaces (Parlay X 2.1 Short Messaging and Binary SMS/SMPP) or multiple network plug-ins (Parlay X 2.1 Third Party Call/SIP and INAP) that support the same basic service capability. |
Single communication services can be installed or removed without having an impact on other communication services. If no interfaces are changed, existing communication services can be upgraded while traffic is running. This process is called a “hitless upgrade” and tracks traffic so that in-flight requests can be completed before the older version is undeployed. Communication services may be deployed selectively, as needed.
![]() ![]() ![]() |