Use Java technology to achieve a new generation of OSS / BSS
Sun China Engineering Research Institute Software Technology Center Wang Gang
Abstract: This paper focuses on the status quo of OSS / BSS development, and provides a brief introduction to OSS / J technical architecture, API specifications, and how to develop OSS / J-based system development.
OSS / BSS Overview
OSS (Operations Support Systems) refers to "Business Support System", BSS (Business Support Systems) as "Business Support System", OSS / BSS is a combined telecom service operation and management platform combined with these two types of systems. In China OSS / BSS is sometimes referred to as BOSS.
The Standardization Tissue Telecommunications Management Forum (TMF) proposed a widely accepted function model that is widely accepted by the industry. In this model, OSS / BSS includes three major functions: business open, business security and billing (or business metering). Business Opening refers to the order of telecom operators to accept customers to order telecom services, and provide customers with the services required by the distribution, configuration, installation, and deployment of telecom resources, and can charge the service. Business protection must provide the amount of 饬 饬 辏 辏 辏 7 衲艽 锏 突 у у у 滴 窦 窦 吭蚴 吭蚴 吭蚴 吭蚴 滴 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌 阌κ κ 延 ⒍ 允 允 压 峁 ┲ ┲ frame? lt; / p>
As an efficient information management system, OSS / BSS has been widely used in foreign telecom operators and has accumulated a lot of successful cases in practice. The OSS / BSS solution is also perfect in this process, and it has also exposed more and more difficult problems:
Figure 1, "Integrated Nightmare" of OSS / BSS
l OSS / BSS software system is relatively complicated, allowing the network management system, billing system, accounting system, customer service system, etc., all into a system, to put them organically integrated together, almost impossible, for this "Messy No Character" system structure (see Figure 1), which is simply called the Integration Nightmare.
l Many OSS / BSS developers have the same feeling - lack of training-oriented engineers, which is determined by the previous one, need engineers to master the professional knowledge of telecommunications, but also familiar with all kinds of software, indeed the requirements are more demanding.
l industry standard problem. Although some standard specifications have been launched in China in recent years, most of them have stayed on paper, and they lack more intuitive technical guidance and successful cases.
l A OSS / BSS often involves several separate systems, except for integration, testing the system, and maintenance is very time consuming.
The above issues, OSS / J can be solved, because:
l The software interface developed in accordance with the OSS / J specification is relatively simple, and the individual subsystems inside the OSS / BSS are interchangable.
L OSS / J is based on J2EE technology, developers are enough to familiarize with J2EE development (even familiar with Java development), they can work with designers to complete system development.
l OSS / J includes not only technical specifications, but also real code implementations and test tools. This helps developers get started quickly.
l Because each subsystem meets the standard interface, the post-test and maintenance work of the system will be relatively simple.
What is OSS / J
OSS / J (OSS THROUGH JAVA) is a new generation of OSS / BSS solutions based on Java technology.
Speaking of OSS / J, we need to mention a working group called OSS Through Java Initiative, which consists of a large number of new technologies (such as Motorola, Nokia, Sun, BEA, IBM). Since its establishment in 2000, they have been working hard to speed up the development of OSS / BSS solutions, simplify the deployment and integration of system components. The Working Group uses Java technology to define a series of open standard APIs for OSS / BSS definitions, providing developers for OSS / BSS. In the near future, both equipment manufacturers, software developers, and system integrators in the telecommunications industry follow these standard API definitions. Then, the final OSS / BSS will be a component-based, organic combined integrated management platform ( See Figure 2) The system structure of "messy" will become in the past. Figure 2, system structure constructed using OSS / J
It should be pointed out that OSS / J is not to define another universal OSS / BSS integration framework. Before defining the standard API, members have drawn the essence of many standard specifications and protocols, for example, OSS / J inherits from 3rd Generation Partnership Project (3GPP), 3GPP2, Mobile Wireless Internet Forum (MWIF) ) And the specifications and framework systems of organizational or forums such as TELEMANAGEMENT Forum (TMF). Therefore, the Working Group puts all the experiences into the definition and encoding implementation of the Java API, and users who use OSS / J specification can be obtained free of charge.
TMF introduces detailed OSS / BSS definitions in the documentation of NGOSS 3.0 (Next Generation Operations Support Systems). (See http: // www.tmforum.org). OSS / J's API definition complies with NGOSS ETOM (Enhanced Telecom Operations Map), please see "OSS / J API" section for details. In summary, NGOSS provides us with universal applicable frameworks independently of technology, and OSS / J is based on this framework, which proposes an implementation of Java technology.
The launch of OSS / J specification is completed in Java Community Process, http://jcp.org. By accessing the JCP website, or in http://java.sun.com/products/oss, you can download to OSS / J specification, reference implementation and compatibility test tools, hereby introduction:
OSS / J specification: including OSS / J API specification and OSS / J J2EE system design guidance. These content will be described in detail in "OSS / J API".
OSS / J Reference Implementation (Reference Implementation or Ri): The main content is the code implemented according to the OSS / J API specification. Introducing the RI on the one hand, in order to verify the demolition of the specification, the code of RI has not been optimized. Another important role of ri is that it enables developers to start design and development work quickly, and all code in RI can be used directly from the development of commercial systems directly. So, carefully reading the analysis of Ri's code can greatly shorten your time you are familiar with OSS / J.
Compatibility Test Tool (Test Compatibility Kits or TCK): How can we know if it meets the OSS / J specification after the development of an OSS / BSS (or one of the subsystems) is completed? TCK can complete such tests and generate a test report. If the developed product meets the requirements of the OSS / J specification, it will be easily integrated with other products that are also compatible with OSS / J specification. After the launch of OSS / J, it has been widely recognized by the industry, many telecom operators, service providers, and system integrators to follow. The 2002 report from IDC said, "... With the release of SA, TT, QoS API, many service providers and suppliers believe that Java technology implements OSS has reached the actual phase."
OSS / J and J2EE
The above mentioned above, OSS / J can help us end the "system integration nightmare", because it defines a series of standard APIs for us, as long as each manufacturer can comply with the regulations in the API, then the integration of OSS / BSS is difficult The problem will be solved. So what is the specific underlying implementation mechanism? - OS / J uses J2EE as a technical platform.
J2EE (Java 2 Enterprise Edition) Java 2 Enterprise Edition is a programming framework for building a distributed system for developers, requiring a more deep understanding of J2EE, please visit http://java.sun.com/j2ee/ . Overall, J2EE makes developers do not need to consider the underlying technology to achieve detail, such as thread management, network communication, etc., but concentrate on the development of business logic, which undoubtedly accelerate the development process of the application. And simplify system deployment and post-maintenance work. At present, the total number of J2EE developers in the world has reached several million, and this group is still expanding quickly.
Figure 3, using J2EE to implement OSS / BSS
As a server-side development technology, enterprise JavaBean (EJB), Extended Marker Language (XML), and Java Management Extensions (JMX) are adopted in OSS / J. Because J2EE, XML, JMX have been successful in many large enterprise applications (especially server-side applications), so OSS / J uses them to define the API required to assemble, develop, and deploy OSS / BSS solutions.
Figure 3 is a schematic of OSS / BSS using J2EE. Based on OSS / J API, we developed EJBs that support SA, TT and other functions, which can access databases via JDB as needed, or access directory servers via JNDI. For existing legacy systems and EMS (Element Management Systems), the J5EE Connector can be used to integrate through SNMP, CMIP, or other proprietary protocols. OSS clients can be browser or custom applications, associated with HTTP / XML / Java / IIOP and systems. At the same time, Java's message mechanism provides us with more flexible integration of "loosely-couppeld", using it to simply implement connections to other systems in the intranet / Internet.
OSS / J API Introduction
Figure 4 Maps each process of the core API and TMF of the OSS / J made a mapping. As can be seen from the figure, the OSS / J core API includes 20 customer management, order management, service opening, etc. About the detailed description of each API, see http://java.sun.com/products/oss/ OSS / J API Roadmap on Apis.html. Currently, the completed API has: OSS service Open API, OSS Troubleshooting API, OSS General API, OSS IP Billing API and OSS Service Quality Control API, and OSS Inventory API will be released soon. In addition to the API, the OSS / J Working Group also provides developers with "OSS / J J2EE System Design Guidance". Figure 4, mapping of OSS / J API to ETOM
OSS Universal API: Unlike other OSS / J APIs, it does not provide support for OSS / BSS in business logic, but provides a base framework for developers using OSS / J API. This part of the API can be considered a specific implementation of "OSS / J J2EE System Design Guidance". It is emphasized that since all OSS / J API mentioned below is dependent on the general API.
OSS / J J2EE System Design Guidance (OSS / J J2EE DESIGN GUIDELINE or OSS / J J2EE DG): Defines a series of Design Patterns, which is ideal for use J2EE / EJB to build a network service management system. Overall, the design patterns mentioned in DG are from J2EE design patterns. For more information on J2EE design patterns, see http://java.sun.com/boeprints/corej2eepatterns. The following points are mainly involved in the DG:
l OSS functionality is implemented in the form of EJB components
l These EJB provide a rough interface for business logic
l Application Server provides cluster, extension, and fault processing for the OSS / BSS system.
l Use the message (Messaging) switching mechanism to reduce the degree of coupling between components.
l Combined with message mechanism and JCA architecture implementation system integration and workflow management
An important concept through DG is the concept of "Software Building". A software building block is a collection of software components, these software components collaborate to meet the needs of system business logic. It is emphasized that all definitions and implementations of the OSS / J API are compliant with OSS / J J2EE DG.
OSS service open API (OSS Service Activation API or SA API): It is mainly provided to manage management functions of orders (such as generation, modification, deletion, query orders, etc.) and services. There is no specified "Service Information Model" in the API, but this part of the work is left to developers, so that developers can define service information models based on their business logic. The definition of order management in the SA API is done based on the "World Order Information Agree" and the ORDER State Model "of the" World Order Information Agree "in TMF 603.
OSS Troubleshooting API (OSS TROUBLE TICKET API or TT API): A series of operations that define generated, update, query, and turn off the ticket. The network management system can automatically generate a ticket by calling the TT API, and the service provider can also use it to generate and process the ticket, the customer care system can call these APIs to send the ticket to the service provider (see Figure 5); if the ticket Management is done in a workflow, then developers can communicate with the workflow engine using these APIs. OSS IP Biometric API (OSS IP Billing API): Defines the interface between the data source and the billing system of the IP bill. This part of the API is applicable to OSS / BSS development for 2.5G and 3G networks. Moreover, the definition of the API focuses on (but not limited to) the field of wireless communication. The definition of this specification is to achieve a billing system, billing data acquisition system, and a variety of record types (such as CDR, SDR, IPDR, etc.) between these different subsystems. Exchange and transmission.
OSS Service API (OSS QUALITY OF Service API or OSS QoS API): QoS API enables QoS systems to get data that affect service quality from other systems, such as network performance, limit value, and fault data, etc. The QoS API mainly involves data monitoring, system limit value monitoring, system monitoring of system limit, and the monitoring of malfunction data.
OSS Inventory API: OSS / BSS Most of the products, services, and resources can be used, which are available for use in the operation, which is available from the inventory API. This part of the API includes directory management of products and services, and tracks the functions of tracking users and services or services; the functions of network resource management (such as devices on the network) in the API) For OSS / BSS is also indispensable.
The following figure shows the relationship between the OSS / J APIs, where the elliptical boundary can be seen as the definition of the API, the content of the rectangle is implemented by the developer, and the arrow represents the method or function call, these function calls In particular, between the individual subsystems (e.g., from the QoS call fault slip) should be done using the OSS / J API.
Figure 5, the relationship between the OSS / J API
OSS / J development guidance
After understanding the OSS / J API overview, you may have decided to start the OSS / J system development. Whether you are a system designer or a programmer, you should have J2EE's development experience, and it is best to understand the telecom industry knowledge (especially about OSS / BSS knowledge). Moreover, it is recommended that you work according to the following steps.
Study on OSS / J Related Information
Browse OSS / J website http://java.sun.com/products/oss, you can download to OSS / J specification and related technical articles (as shown in Figure 6). As mentioned earlier, try deploying Ri and studying its code can help you quickly understand OSS / J. If you have any questions and comments when you study and use, you can publish in the appropriate newsgroup (the address of the newsgroup see the website of OSS / J).
Figure 6, download OSS / J specification, RI development
Start OSS / BSS design and implementation
This process and standard software development have no big difference. It mainly experiences several links such as formulation, demand analysis, system design, detailed design, coding implementation, and testing. Since the development of OSS / J is based on J2EE technology, it is important to select a stable and efficient application server (Application Server) and integrated development environment (IDE). We have many choices because of J2EE's openness. For example, Sun ONE Application Server, BEA WebLogic, Borland Jbuilder, etc. When designing and detailed design, designers need to be familiar with the contents of OSS / J J2EE design guidance, and design them according to the design patterns described. As for coding, there is no difference between the development of J2EE development, mainly involving EJB programming, while providing programmers are familiar with XML. Enter the test phase, in addition to completing a series of tests that need to be completed by ordinary software development, the compatibility of the OSS / J specification is also required. As mentioned above, TCK can help you complete this step (see Figure 7). Figure 7, test using TCK
Release your product information
When your product successfully passed the TCK test, you can get the certification of OSS / J. OSS / J stipulates a flexible "self-certification process" for OSS / BSS products, see Figure 8. As mentioned above, use TCK to test your product, will have a test report. If the test is successful, the report can be published on your public website while notifying the OSS / J Working Group program management team. After verification, the OSS / J program management team will update the OSS / J website, add the link (URL) of the product test report you publish to the list of certified product lists. By now, the entire "self-certification process" is completed. Get the certification of OSS / J, meaning that you developed can be easily integrated with other vendors, can be integrated as an organic part to the OSS / J API-based OSS / BSS. See http://java.sun.com/products/oss_products_table.html, where you can see the products of IBM, ILOG, NOKIA, etc. have gained OSS / J certification.
Figure 8, "self-certification" of OSS / J
Join OSS / J Working Group
If you want to know the development trend of OSS / J in time, get the latest information, and even want to participate in the formulation and modification of the specification, then the most effective way is to join the OSS / J workgroup. Members in the OSS / J Working Group have different levels, which have different rights. Check out http://java.sun.com/products/oss/members.html to learn about the details of the Join the OSS / J Working Group.
to sum up
OSS / J provides us with a technical framework that implements OSS / BSS using Java technology. It draws on numerous established industry norms, based on J2EE / XML technology, provides a standard environment for OSS / BSS developers. To address the integration issues present in the current OSS / BSS. I believe that with the advancement of related technologies, OSS / J will have more and more supporters, thereby developing technical standards for implementing OSS / BSS with Java.
Reference
l Operations Support Systems, http://www.iec.org
L OSS Through Java Initiative, by Philippe Lalande
L OSS Through Java Initiative, Simplifying Integration with Common Apis, http://java.sun.com/products/ossl OSS / J API RoadMap
L Case Study: from ngoss map to oss / j aroundwork, http://www.tmforum.org/browse.asp?catid=1483&snode=1483&exp=y&linkid=28103, by Peter Lambert
L OSS THROUGH JAVA Design Guidelines, http://java.sun.com/products/oss/apis.html
l OSS TROUBLE TICKET API
l OSS Service Activation API
l OSS Common API
l OSS IP Billing API
l OSS Quality Of Service API
l OSS Inventory API
