| Oracle® Communications ASAP Concepts Release 7.2 E18880-01 |
|
 Previous |
 Next |
Figure 2-1 illustrates the functional architecture of Oracle Communications ASAP.
The ASAP multitier architecture operates on an Oracle database engine.
To run ASAP, install the ASAP software and then implement the service order and network element interfaces to support specific services and network elements by using the following customizable modules:
Service Request Processor (SRP) or Java SRP modules interface with the host system
Network Element Processor (NEP) and Java NEP modules interface with network elements
|
Note: These interfaces can be purchased from Oracle in the form of cartridges or they can be developed. |
ASAP consists of a set of multithreaded UNIX client/server processes and Java 2 Platform, Enterprise Edition (J2EE) applications that communicate with one another and with the appropriate database server. This arrangement has several advantages:
Flexibility – Client/server applications are easily distributed across several, possibly heterogeneous platforms. The result is a scalable architecture that can expand to meet evolving requirements.
Manageability – Because common services are handled on a server, application size and complexity are reduced. Client applications are simplified, duplicate code is minimized, and application maintenance is easier.
Customization – Client/server architecture enables applications to be developed with distinct components. You can modify or replace these components without affecting other parts of the application.
Improved performance – Multithreaded application architecture improves performance by enabling you to add additional processing functionality as threads within the process, as opposed to additional processes within the network. This capability enables greater throughput for the following reasons:
A threaded application makes better use of operating system resources than the conventional, multiprocess application.
Interthread communication is much faster than interprocess communication.
Improved communication between applications – Client applications that use different communication protocols cannot communicate directly. A client/server architecture, however, allows communication using a “gateway” server that understands both protocols.
The ASAP provisioning process begins when customer service requests are sent from an order management or service order entry system. These requests use either batch or transaction-based interfaces.
The most common format for customer service requests is the conventional work order generated by service representatives or automated systems, such as a web interface or voice response program. Work orders generally require other activities, such as updates to customer, billing, and assignment records, in addition to the provisioning operation.
Figure 2-2 illustrates the work order translations performed as part of the provisioning process.
The Service Request Translator (SRT) is an optional component that accommodates upstream requests (requests from business and operations support systems) defined within XML documents. Based on the incoming request (XML document), the SRT enables a variety of tasks within a transformation computation, including mapping, data lookup, and message transformation. Mapping tasks allow upstream requests to be broken into one or more downstream requests (request sent to the network element). The SRT output is also an XML document. See SRT User Guide for more information.
The following client application enables you to define services, create work orders, and configure ASAP.
The Order Control Application (OCA) Client enables users to query and create work orders, monitor work order-related events, define notifications based on generated events, and manage fallout work orders.
The OCA Client is a Java-based GUI that communicates with the OCA SRP. The OCA Client allows you to interact with ASAP in a flexible manner, providing a single entry point where you can create and manage work orders.
The OCA Client is also available as a Java applet that can be embedded in an HTML Web page and run in a browser.
Access to the Java source code for the OCA Client is provided by the OCA Toolkit option.
Oracle Communications Design Studio is a GUI-based application that enables users to quickly develop, package, and deploy services in ASAP. Using Design Studio, you can:
Define new services
Extend the services that have been defined in an ASAP cartridge
Reuse existing service definitions
Deploy services to development or production environments
The following server applications contribute to the working of an ASAP system.
The customer's service request systems communicate with one or more SRPs. If the same provisioning request is received from more than one source, it is translated by an SRP into identical sets of Common Service Description Layer (CSDL) also called service action commands and parameters.
Service action commands are independent of the originating system. The communications capability, the standard representation of services, and the multiprocess deployment of the SRP allow the same ASAP system to adapt to new customer service request sources without the need to change the existing service delivery flow.
After the SRP has translated the service and action combinations into service action commands, the SRP extracts service, action, and associated parameters from the native order format. It determines parameters for the work order that constitute the header portion of the ASAP work order (such as due date, order number, and priority). In addition, the SRP finds the global parameters for the work order that are required for provisioning.
When the translation is complete, the SRP sends the ASAP version of the work order to the Service Activation Request Manager.
The Service Activation Request Manager (SARM) acts as a request controller that determines and coordinates requests between the various SRPs and NEPs in the ASAP system. The SARM enables you to efficiently manage connections to network elements, including work order priority and load balancing (managing multiple connections to network elements according to configurable thresholds).
The SRP transmits the service actions and parameters to the SARM. The SARM provides centralized coordination and transaction management of provisioning activities across diverse networks in a high-performance environment. Using a data-driven service model, the SARM translates service actions into one or more Atomic Service Description Layer commands (ASDLs) also called atomic actions. Each atomic action represents a single task to be performed on a network element. The SARM then determines the routing for each atomic action and transmits it and its provisioning parameters to the appropriate NEP for provisioning.
The atomic action command parameters are derived from both the service action and global work order parameters.
The SARM routes each atomic action to a NEP. The NEP provides transparent connections to network elements or element management systems. The dialog with the network element is completed by using State Table scripts or Java scripts. State Tables are programs used internally by ASAP to control the dialog with external systems, such as NEs, and perform service order translations.The NEP maps the atomic action to the user-defined script and conducts the activation dialog with the external network devices. To manage a large number of network elements, multiple NEPs can be deployed.
During the NEP translation process, atomic actions become network-element-specific commands. After the NEP has received atomic action commands and their associated parameters from the SARM, the NEP selects either a user-defined State Table (for C-based processes) or the JInterpreter (for Java-based processes) to provision each atomic action command for a network element.
The Admin server maintains performance data generated by other ASAP components, principally by the SARM. It polls the application servers periodically for their real-time performance data and stores the results in its database. You can reference this performance data, accessible through an API, by using monitoring and reporting tools.
The Control server manages the overall run-time distribution of ASAP components. The Control server has the following management functions:
System startup and shutdown
System alarm generation
System distribution
Secure data storage
Encryption key distribution
One Control server must reside on each machine on which ASAP processes run.
Configuration management involves two sets of activities:
Operational configuration – The configuration of ASAP components
Service configuration – The definition, configuration, and deployment of services
New configuration entries can be added dynamically. Once you add new configuration entries to the database, you can send a request to each relevant ASAP server to load the configuration changes from the database into memory. This enables you to add service actions, atomic actions, service action-to-atomic action mappings, new NEPs, hosts, routings, and network element resources dynamically.
Using the command-line interface, you can manage the following operational configurations:
Operational configuration – You can configure the operational components of ASAP, including the distribution of ASAP over one or more machines and the definition of ASAP servers.
Event/alarm configuration – You can define system events and specify the circumstances under which system event alarms are issued.
Network element configuration – You can manage mapping relationships, create and maintain NEPs, create network element blackout periods, define a new Host network element, and create new atomic action command routings.
Other SARM configurations – You can configure miscellaneous SARM operations, including atomic action responses for system testing, file system thresholds, modifiable text, ASAP international message conversion setup, SRP-to-SARM security setup, SRP definition to SARM, and management of database monitoring thresholds.
Using the command-line interface, you can manage the following service configurations:
Provisioning translation – You can create and maintain service actions and atomic actions, along with service action-to-atomic action mapping relationships and atomic action-to-State Table or Java script mapping relationships.
Services can be developed according to the Service Model XML Schema. Alternatively, a set of specific services in the form of a cartridge can be purchased or developed. Cartridges provide plug-and-play domain behavior into a core product and include the configuration of the core product. An ASAP cartridge follows the guidelines specified in the ASAP Cartridge Development Guide.
Whether services are developed or purchased, the Service Activation Deployment Tool (SADT), Service Activation Configuration Tool (SACT), and the PostDeploySarFile script enables you to assemble and deploy generic or cartridge-specific service models. The functionality provided by these scripts can be implemented using the installCartridge script.
The installCartridge script does the following:
Facilitates the development of generic service packages, cartridges, and solutions
Defines a structure for packaging an activation model
Defines a process for deploying an activation model
You can use this script to bundle and deploy cartridges into an ASAP instance. Packetizing a service bundle also lends itself to version control. The benefits are:
Reduced deployment time
Reduced deployment costs
Ability to layer and version control service models
Facilitation of cross-product service model deployments
The ASAP Development Toolkit provides a set of APIs that you can use to customize ASAP client and server applications.
ASAP provides C/C++, Java, and CML/JMS to create custom SRPs JSRPs, NEPs, and JNEPs or provide programmatic integration with ASAP. These APIs include:
APIs common to both client and server applications
Client APIs
Server APIs
Java
The ASAP Interpreter and JInterpreter libraries are script engines that allow State Table scripts or Java scripts to be developed, configured dynamically, and run without the need to recompile C/C++ or Java code. This library can be incorporated into application servers to provide internal ASAP State Table scripting or Java scripting capabilities. The interpreter and JInterpreter libraries are provided to build State Table and Java capability in customer NEPS, and JNEPs.
This section describes the features and functions of ASAP security components.
You can manage ASAP users with Oracle WebLogic Server. Oracle WebLogic Server uses an enterprise-level framework that allows multiple servers to share a common security architecture.
For information on the default permissions that are available to users and user groups, refer to ASAP System Administrator's Guide.
ASAP provides enhanced security functionality that is designed to respond to the increased security requirement when provisioning over distributed networks.
ASAP security is designed to provide maximum confidentiality and data integrity while ensuring on-demand access to services for authorized users. ASAP security is designed for two essential functions: managing secure data and protecting diagnostics files.
ASAP security incorporates the following features:
Secure data storage – Your ASAP security administrator predefines the nature of the secure data and the accessibility by each ASAP server. There are two classes in the secure data: ASAP secure data, such as ASAP database passwords, and custom secure data, such as network element passwords.The ASAP secure data is stored in a Credential Store Factory (CSF) wallet, accessible to each ASAP server. The custom secure data is stored in a central repository called the Master Control server.
Secure data encryption – The CSF wallet that contains ASAP secure data provides transparent encryption functionality. ASAP supports a symmetric secret key encryption method to achieve data confidentiality for custom secure data.
Key distribution – Each ASAP server can locally access the ASAP secure data contained in the CSF wallet. The Master Control server acts as a key distribution server and distributes custom secure data to every ASAP server during provisioning. To acquire the custom secure data, the ASAP server has to follow the predefined key distribution protocol.
Secure NE dialog – The ASAP NEP diagnostic file contains switch-sensitive information sent to and received from network elements. The NE dialog can be configured to secure the provisioning information.
Secure work order information – Work order information that originates from the upstream system and is sent to network elements contains business-sensitive information. As the work order progresses through several components (SRP, SARM, NEP, and so on), the information is exposed to different diagnostic files. For example, some database queries in the SARM can reveal work order information. By setting a configuration variable or a work order property, you can ensure that work order information is not exposed in any diagnostic files.
Every ASAP component application can have its own database. This close coupling of processes to databases distributes ASAP efficiently in a networked environment.
Figure 2-3 illustrates the process and database components of ASAP.
ASAP uses Oracle's relational database management system (RDBMS) as the database engine. A single database can contain one or more ASAP databases. Or every ASAP database in a fully-distributed environment can reside on a separate RDBMS, on separate machines. This ability to distribute transparently and to scale ASAP accordingly is a feature of ASAP.
The RDBMS employed by ASAP uses an Oracle server. The Oracle RDBMS is a specialized server process that manages ASAP databases. It offers the following features:
Client/server architecture
Stored procedures
Server-enforced integrity and security
High application availability
Open, distributed RDBMS
Scalable high-performance programmable server
Online backups and maintenance
Rapid recovery
Distributed access, data, retrievals, and updates
ASAP uses Sybase Open Client and Open Server run-time libraries. The Sybase Open Client provides a library of functions for use when creating Open Client applications that communicate with Sybase Open Server applications. The Open Server offers a set of functions you can use when writing a multithreaded Open Server application to receive requests from Open Client applications. It is a platform independent, multithreading, and remote procedure call (RPC) library.
You can deploy ASAP across a broad range of services and network element technologies. Tier 1 operators globally are using ASAP for multiple domains including Mobile, Voice (Circuit switched and packet voice), Data (xDSL and HFC) and Video (CATV and Satellite).
ASAP has a robust cartridge development program. Oracle offers over 80 certified cartridge adapters for various network elements from different vendors. ASAP customers can license these productized cartridges and receive fully tested and supported solutions for activating services on the various network elements.
Oracle Design Studio allows you to extend or build new cartridge adapters for new network elements or versions that are being introduced into the network.
ASAP supports the following interface protocols and standards:
SOAP/XML
HTTP/S
SNMP Manager
TL1
TCP/IP
Socket interface
Telnet interface
SSH
File Transfer Protocol (FTP) interface
Secure FTP (SFTP) interface
Serial asynchronous
External device driver API for proprietary or custom interfaces as required
|
Note: Protocols that are not included in the above list can be supported through extensibility. |
ASAP cartridges are discrete software components that are developed for the ASAP product. An ASAP cartridge offers specific domain behavior on top of the core ASAP software, and provides the configuration that supports a set of services on a NE.
An ASAP cartridge is not a standalone component, but operates with the ASAP core product. ASAP cartridges offer the following benefits:
Reduced Time to Market: Time to market of new services is reduced through simplified development, implementation, and extension of cartridges on customer sites.
Extendable: Cartridges can be extended to include additional services and components that deliver business value, without requiring changes to the original cartridge.
Simplified Effort: The effort and technical knowledge that is required to perform customizations is reduced.
Ease of Installation: Cartridges can be installed into an ASAP environment without interfering with the existing install base.
An ASAP cartridge allows you to configure ASAP to provision the following:
NEs from a specific vendor, such as Ericsson or Huawei.
Technologies, such as GSM or xDSL.
Services that are supported on the NE, Mobile, Data, or Video.
|
Note: Cartridges are designed for a specific technology, software load, and service. |
An ASAP cartridge supports a particular set of services on an NE. These services are independent of customer-specific service definitions. Professional Services or systems integrators can perform extensions to the cartridge to support customer-specific requirements.
|
 Copyright © 2005, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
