运营管理电信运营支撑系统演变
过程及概述
电信运营支撑系统演变过程及概述
第一章：电信业务运营支撑系统概述
0、序言
1、电信业务运营支撑系统概述电信管理网（TMN）结构及演进
2、电信运营及模型（TINA）
3、电信管理论坛（TMF）与电信运行图（TOM/eTOM）
4、国内电信业务运营支撑系统现状
0、序言
什么是电信运营：电信运营商利用自身的通信资源，提供给消费者通信服务，而获取利益。
运营的含义：网络和业务的运行、维护及经营。
电信运营的目的：提供更加优质的服务，获取更高的收益。
什么是电信服务？：网络服务，网络承载的基本业务、业务平台提供的增值业务，打包的电信产品（套餐），外包服务，。。。
什么是电信运营支撑系统？采用计算机的技术，支持电信业务的运营过程的计算机系统。
所引出的问题：如何“更快、更高、更准”：通信技术的不断进步；如：3G/Wimax、宽带技术，如何更好地分析、认识、挖掘市场，如何更准确地计量，如何更快地将电
信服务交付给用户，同时、涉及到电信公司本身如何有效地管理。
电信运营支撑系统的特点：复杂、庞大，分布、协同、跨部门，异构
研究电信运营支撑系统的意义：任何行业和领域都面临信息化建设的问题—共性问题—业务支撑，计算机应用的根本问题，促进计算机技术的发展—计算、软件
1、 电信业务运营支撑系统概述电信管理网（TMN）结构及演进
电信业务运营支撑系统的概念目前在业界比较混乱，有多种定义如下：电信运营支撑系统 OSS (Operating Support System)，电信业务支撑系统 BSS (Business Support
System)，电信业务运营支撑系统（BOSS），出于中国移动的概念
其中：业务(business)源于 TMN的术语。目前国际上比较公认的叫法：OSS/BSS
电信业务运营支撑系统(OSS/BSS)定义:
是以市场为导向，面向电信业务和网络的运营支撑以及面向客户服务的企业经营支撑的计算机信息处理和管理系统。包括：
电信业务管理：业务及资源配置、业务故障及性能、业务准备及测试等管理支撑；
客户服务的管理：计费、帐务、业务开通和实现、收费等客户关系管理 CRM；
市场营销的管理：市场策略及营销计划、策略执行及评估、营销渠道管理等。
业务合作伙伴管理：
电信业务支撑系统的起源：在业界，OSS概念最初源于 ITU-T TMN系列建议中的运营系统（OS），OS是用来支撑网络运营的系统，
OSS由 ITU-T TMN OS演化而来，OSS定义的内涵指电信运营商的支撑系统，其概念范围包括 BSS，也包括网元管理系统/网络管理系统等。但从过去 ITU-T TMN方面的研究
内容来看，ITU-T TMN偏向于设备和网络的管理。（自底向上）
电信管理网 TMN结构及功能
国际电联的电信管理网络标准化建议 TMN将电信管理分为四个层次：
经营管理层：支撑整个电信企业的决策和管理
业务管理层：电信业务的提供、控制和监测，与业务相关的计费
网络管理层：网１络话务监视与控制、路由调度、质量监测
网元管理层：对网元的操作与管理，远程维护
电信管理网 TMN功能模型
TMN每个层面都有运营系统 OS
TMN的局限性：很好地解决了网络管理的统一；但是对于业务管理和经营管理却“力不从心”
原因分析：运营模式还是“面向网络”、“以业务为中心”用管理框架（FCAPS）和标准接口（参考点）很难将企业的经营进行统一。
2、电信运营及模型（TINA）
电信信息网络体系结构 TINA（Telecommunications Information Network Architecture)TINA-C论坛：其宗旨是将 TMN 与智能网 IN结合，用标准化的模式解决电信业务
管理和运营的问题，智能网 IN及下一代网络 NGN是提供电信业务和增值业务的平台。
TINA-C提出的一些标准化建议和草案可作为电信业务支撑系统设计和规划的理论基础。
TINA-C的电信经营模型
Access and Usage（接入和使用）
An ExampleMultiple Provider Scenario
电信运营及模型（中国联通）
电信运营企业的经营模式
经营参考模式的特点：
统一的客户服务（综合营业、综合收费）；客户服务与业务提供商分离：拓展营业网点、发展其它营销渠道（代理商、ISP），拓展业务范围、代理其它业务提供商的业务
（外包服务）；业务提供与网络提供商分离（接入与服务）：加快新业务的开发和部署，充分利用网络资源，跨网络提供商的资源共享和业务提供
经营模式的核心思想：以市场为导向、以客户为中心、以业务为依托、以网络为基础
电信市场环境的变化、新的业务模式的出现（移动数据业务模式）促使电信运营商的运
营模式发生变化：客户服务、市场开发，业务运营及管理，网络及资源的规划和运行，供应商及业务伙伴的开发和管理，企业管理
在不断加剧的市场竞争环境下，如何保企业的运营快速、健康和可持续发展？
市场环境变化引导企业转变管理观念。
3、 电信管理论坛（TMF）与电信运行图（TOM/eTOM）
TMF（TeleManagement Forum）：是一个由通信服务提供商及其供应商组成的国际性的协会，它的使命就是帮助业务提供商（Service Provider）和网络运营商（Network
Operator）以一种最节省费用和时间的方式来自动化他们的业务处理过程。
具体而言，电信管理论坛的工作包括：建立业务处理过程的运行指南；取得各处理活动
之间的信息流的一致；定义支持与 OSS互连的理想的系统环境；支撑集成的和自动化的电信运行过程的建立，以及真正产品的开发。
TMF 的目标：以经营业务（Business）和客户服务（Customer Service）驱动的途径，来获得端到端（End-to-End）的业务流程自动化；TMF强调为经营问题提供实用的
解决方案，并基于 ITU-T的 TMN模型的经营层（Business Layer）。在经营环境领域中，TMF定义经营处理过程，需求模型，和信息模型。
TMF基于 ITU-T TMN概念，重点研究并发展“业务管理”和部分“网络管理”方面的框架理论和概念，提出了 NGOSS和 eTOM等理论和概念。可以说，OSS概念在 TMForum
中得到了发展和广泛的应用；尤其是随着 NGOSS的提出，OSS/BSS的提法也得到业界的认可，通常前者指面向网络和设备维护的后台支撑系统，后者指面向业务和客户的前台
支撑系统，但 OSS和 BSS的概念在 TMForum中至今并没有一个非常明确清晰的定义或划分界限。
电信运营图 TOM（Telecom Operations Map）是 TMF最先提出的业务运营流程框架，它是基于 TMN结构和 TINA的经营模型，结合电信运营实际的 TOM是业务处理过程的蓝
图以及设计和开发集成业务运营支撑系统（OSS/BSS）的起点。
TMF的电信运行图 TOM TOM中的 FAB
端对端的管理－业务实现（1）
端对端的管理－业务保障（1）
端对端的管理－业务计费（1）
增强（扩展）的电信运营图 eTOM
业务运营的含义：面向客户的 1、市场的分析与预测，2、业务产品的开发，3、业务的
部署及管理，4、业务的运行及维护，5、业务的评价与审计。
以最低的成本、最快的速度开发出最满足客户和市场需求的业务产品。
低成本：指降低业务开发和运营支持的成本。快速：指快速的业务开发与部署、以及运营支持的开发与部署。合适的业务产品：业务的生命周期与业务的投入和回报（ROI）
电信运营支撑系统（OSS）作为快速开通业务及时保障业务、优化管理网络资源的重要手段，是电信网络运营管理不可分割的一部分。全球化竞争的电信市场和电信多元
长途网IP数据网增值业务
平台
收费点
化价值链的形成促进了 OSS技术的飞跃发展，电信运营支撑系统在电信集约化经营的实践中扮演着越来越重要的角色。合理使用 OSS技术，建设功能完善、互通灵活、充分共
享信息的运营支撑系统，是我国每个电信运营商目前极为关注并重点发展的运营管理战略之一。电信业务支撑系统的技术发展。
4、 国内电信业务运营支撑系统现状
中国电信：1997年，中国电信推出“97 工程”希望利用先进的技术手段和管理方法，
提高电信业务的服务质量和综合管理水平，适应电信体制的变革，实现本地网市内电话业务数据的集中管理、各生产部门的信息共享。初步实现了端到端的业务流程管理
“97工程”的历史作用：公认为是国内电信运营支撑系统建设和研究的开始。为后续的 0SS/BSS的建设和发展奠定了基础。
“97系统”的不足：面向市内电话业务，造成信息孤岛，未考虑完整的业务支撑
中国移动：2001年 6月，中国移动制定了《中国移动 BOSS系统技术规范》,旨在通过一个统一完整的规范来指导中国移动的整个运营支持系统 BOSS的建设，BOSS系统的
规划和建设遵循“一体化、二级中心和三层结构”的原则， 一体化是指将计费、 结算、帐务、客服及业务管理等功能进行统一规划和考虑，使 BOSS成为真正一体化的信息
资源充分共享的支持系统。
二级中心是指 BOSS系统分为集团公司级系统（全国中心）和省级系统（省中心）两级。
而三层结构是指 BOSS系统在逻辑上分为数据核心层、业务逻辑层和接入层。
客观上讲!中国移动的 BOSS一期工程是中国第一个完整意义上的 BSS/OSS系统（一体化），对促进中国 BSS/OSS市场的健康成长和发展起到了重要作用。
中国移动 系统框架：
\
中国联通：
关键词：集中、综合业务支撑，一个体系结构、多个子系统，以数据为核心，操作型与分析型的分离
从运营商的 IT架构谈起
第三章 下一代电信业务运营支撑系统中间件技术篇
1、 概述
2、 中间件的技术规范
3、 三种主流中间件技术平台的介绍
4、 中间件是实现电子商务的基础软件
5、 中间件符合软件发展的潮流
一、中间件技术概述
1、中间件的概念：随着计算机技术的飞速发展，各种各样的应用软件需要在各种平台之间进行移植，或者一个平台需要支持多种应用软件和管理多种应用系统，软、硬
件平台和应用系统之间需要可靠和高效的数据传递或转换，使系统的协同性得以保证。这些，都需要一种构筑于软、硬件平台之上，同时对更上层的应用软件提供支持的软件
系统，而中间件正是在这个环境下应孕而生。
比较流行的定义是：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/ 服务器的操作系统之上，
管理计算资源和网络通讯。
2、中间件特点及优势：通常意义下，中间件应具有以下的一些特点 ：满足大量应用的需要 ；运行于多种硬件和 OS平台 ；支持分布式计算，提供跨网络、硬件和 OS平
台的透明性的应用或服务的交互功能 ；支持标准的协议 ；支持标准的接口。
程序员通过调用中间件提供的大量 API，实现异构环境的通讯，从而屏蔽异构系统中复杂的操作系统和网络协议。 中间件提供客户机与服务器之间的连接服务，这些服
务具有标准的程序接口和协议。
中间件在分布式的客户和服务之间扮演着承上启下的角色，如事务管理、负载均衡以及基于 Web的计算等。
具体地说，中间件屏蔽了低层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少程序设计的复杂性，将注意力集中在自己的业务上，不必再为程
序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担。
3、中间件的应用领域与分类 ：数据访问中间件：对异构环境下的数据库实现联接或文件系统实现联接的中间件；远程过程调用中间件：程序员编写客户端的应用，可以
调用位于远端服务器上的过程；消息中间件：用来屏蔽各种平台及协议之间的特性，进行相互通信，实现应用程序之间的协同；交易中间件：在分布、异构环境下提供保证交
易完整性和数据完整性的一种环境平台；对象中间件等。
对象中间件：在分布、异构的网络计算环境中，可以将各种分布对象有机地结合在一起，完成系统的快速集成，实现对象重用。
面向对象标准原本只有一个，即 CORBA(公共对象请求代理体系结构)，后来，Sun推出了企业级 JavaBeans(EJB)，用自己易使用的程序模型来对 CORBA做出了改进。微软
COM(Component Object Model，组件对象模型)的出现，使面向对象中间件市场里又多了一个标准，
二、 中间件的技术规范
中间件的技术规范（DCE）
1、DCE体系 分布式计算环境 DCE（Distrbuted Computing Environment ），它由 Open Software Fondation 制定，现在这个组织被称为 Open Group。DCE由多个共同在
一起工作的组件组成，它们是：远程过程调用（RPC）、本地和全局目录服务（CDS和 GDS）、安全服务、DCE线程、分布式时钟服务（DTS）、分布式文件服务（DFC）。
线程、RPC、CDS、安全服务和 DTS组件通常被成为安全核心，并且是组成任何 DCE环境所必须的组件，DTS是可选件。在 DCE环境中，还包括用于管理这些组件的管理工
具。
DCE被称做中间件或使其具有能力的技术，它不是独立存在的，而是被捆绑在供应商操作系统中，或者由第三方供应商进行集成。
中间件的技术标准（DTP）
2、 DTP模型与 XA规范
DTP（Distributed Transaction Processing）模型是 X/OPEN组织提出的一种软件结构，这种结构允许多个应用程序去共享多个资源管理器提供的资源，并且具有协调全
局事务的能力。
X/Open DTP模型（1994）包括：应用程序（AP）、事务管理器（TM）、资源管理器（RM）、
通信资源管理器（CRM）。一般，常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM）是数据库，常见的通信资源管理器（CRM）是消息中间件。
事务（Transaction）又称为交易，指一个程序或程序段，在一个或多个资源如数据库或文件上为完成某些功能的执行过程的集合。
事务具有 ACID 特性。分布式事务处理是指一个事务可能涉及多个数据库操作，分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交
或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。
所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。对数
据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操
作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。
一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将
其自己所做的操作（可恢复）映射到全局事务中。
XA就是 X/Open DTP定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。
XA接口函数由数据库厂商提供。
中间件的技术标准（CORBA）
3、 CORBA 公共对象请求代理结构 CORBA（Common Object Request Broker Architecture ），由国际对象管理组织 OMG制定，这个组织是一个国际性组织，始建于 1989
年，现已拥有包括生产厂商与软件开发商 800多个会员，其目的是在分布和异构计算机环境下为应用软件的开发提供一个公共框架，使开发出来的软件即面向对象又具有可重
用性、可移植性以及可操作性等特点。
该规范描述和定义了 OMA 的 ORB 接口和特征。OMG 于 1998 年分布了最新的 规范[4]，其主要内容有：1. ORB 内核（Core）；2. OMG 接口定义语言 IDL；3.接口池
（Interface Repository）；4.语言映射（Language Mapping）；5.接口存根与骨架（Stub and Skeleton）；6.动态调用与分布（Dynamic Invocation and Dispatch）；7.对象
适配器（Object Adapter）；8. ORB互操作协议（Inter-ORB Protocol）。
Client Object Implementation
ORB Core
Dynamic
Invocation
IDL
Stub
ORB
Intf.
DSI IDLSkel Object
Adaptor
Same for all ORBs
Interface-specific
stubs and skeletons
There may be mutiple
object adapters
ORB-private interfaces
COBRA标准主要分为 3个层次：
对象请求代理 ORB （底层）：规定了分布对象的定义（接口）和语言映射，实现对象间的通讯和互操作，是分布对象系统中的"软总线"；公共对象服务：在 ORB 之上定
义了很多公共服务，可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务；公共设施（上层）：定义了组件框架，提供可直接为业务对象使用的
服务，规定业务对象有效协作所需的协定规则。
1. 对象请求代理（ORB）的作用：在传统的基于客户机/服务器模式的应用程序开
发过程中，项目开发人员遵循公开的标准或自由设计模块间的协议，这样的协议依赖于网络类型、实现语言、应用方式等。引入 ORB后，客户只要遵循服务对象的对外接口标
准向服务对象提出业务请求，由 ORB 在分布式对象间建立客户-服务对象关系。总结起来，ORB 的作用包括：接受客户发出的服务请求，完成请求在服务对象端的映射；自动
设定路由寻找服务对象；提交客户参数；携带服务对象计算结果返回客户端。
CORBA构件模型 CCM，是 OMG组织制定的一个用于开发和配置分布式应用的服务
器端中间件模型规范，它主要包括如下三项内容：抽象构件模型，用以描述服务器端构件结构及构件间互操作的结构；构件容器结构，用以提供通用的构件运行和管理环境，
并支持对安全、事务、持久状态等系统服务的集成；构件的配置和打包规范，CCM使用打包技术来管理构件的二进制、多语言版本的可执行代码和配置信息，并制定了构件包
的具体内容和基于 XML的文档内容标准。
中间件的技术标准（J2EE）
4、 J2EE
J2EE是一种多层应用模式的结构体系。整个规范由 SUN公司提出，它将业务逻辑从系
统服务功能和用户界面中分离出去，放置在客户层和应用基础设施这两层之间的中间层，是目前应用的最为广泛的面向 Web的应用系统结构规范。 J2EE的目标是：提供平台
无关的、可移植的、支持并发访问和安全的，完全基于 Java的开发服务器端中间件的标准。
在 J2EE中，Sun给出了完整的基于 Java语言开发面向企业分布应用规范，其中：
在分布式互操作协议上，J2EE 同时支持 RMI 和 IIOP，在服务器端分布式应用的构造形式，则包括了 Java Servlet、JSP(Java Server Page)、EJB 等多种形式，以支持不同
的业务需求，
EJB自从 J2EE推出之后，得到了广泛的发展，已经成为应用服务器端的标准技术。SunEJB技术是在 Java Bean本地构件基础上，发展的面向服务器端分布应用构件技术。
EJB给出了系统的服务器端分布构件规范，这包括：构件、构件容器的接口规范以及构件打包、构件配置等的标准规范内容。
EJB 是业务逻辑层的中间件技术，它提供了事务处理 TP 的能力，自三层结构提出以后，业务逻辑层（中间层：处理事务的核心），从数据存储层分离，取代了存储层的大
部分地位。从分布式计算的角度，EJB像 CORBA一样，提供了分布式技术的基础。提供了对象之间的通讯手段。
EJB中的 Bean可以分为会话 Bean和实体 Bean，前者维护会话，后者处理事务。
目前 Servlet负责与客户端通信，访问 EJB，并把结果通过 JSP产生页面传回客户端。
中间件的比较分析
业界常用的做法从以下三个方面进行分析：
1、集成性：集成性主要反映在基础平台对应用程序互操作能力的支持上。它要求分布
在不同机器平台和操作系统上、采用不同的语言或者开发工具生成的各类商业应用必须能集成在一起，构成一个统一的企业计算框架。这一集成框架必须建立在网络的基础之
上，并且具备对于遗留应用的集成能力； 2、可用性：要求所采用的软件构件技术必须是成熟的技术，相应的产品也必须是成熟的产品，在至关重要的企业应用中能够稳定、
安全、可靠地运行。另外，由于数据库在企业计算中扮演着重要角色，软件构件技术应能与数据库技术紧密集成； 3、可扩展性：集成框架必须是可扩展的，能够协调不同的
设计模式和实现策略，可以根据企业计算的需求进行裁剪，并能迅速反应市场的变化和技术的发展趋势。通过保证当前应用的可重用性，最大程度地保护企业的投资。
四、 BSS/OSS的中间件架构
1、BSS/OSS的本质就是对处于网络分布环境中的各计算机系统进行交互协作，从而支持新的商业运作模式。
2、管理和传输各业务系统之间的数据信息、协调各系统的处理模块的中间管理服务系统，是保证 BSS/OSS应用成功的关键。
3、应用服务器、通用业务网关（接口平台）、支付网关、通信平台和安全平台，统一纳入 BSS/OSS中间件构架的范畴。
4、从技术角度看， BSS/OSS将由互联网技术、传统 IT技术以及具体的业务处理所构成。但是，系统的建立将会面临许多新的问题，包括：应用系统：能不能快速地建
立，能不能适应大用户数、高处理量要求，能不能提供高效率、高可靠性、高可用性等等关键任务的要求，能不能满足安全需要等等。
规划出一个整体的应用框架，并提供一个支持平台，用于 BSS/OSS应用的开发、部署和管理，并能籍此解决上述各种问题。这已经发展成为一个能广泛适应的标准的支撑
层，成为 Internet应用的基础设施（Infrastructure），这一支撑层实际上是基于 Internet的中间件，也就是应用服务器。
BSS/OSS应用包含以下层次： 浏览器：这是进入 BSS/OSS的通道。应用平台：提供不同应用类型的生成工具软件，如网上商店、网络支付、虚拟社区等等。交换平台：对
内集成企业内部的各种与 BSS/OSS相关的业务系统，对外连接商业合作伙伴，如银行、供应商、客户、配送结构，完成各种不同业务系统之间数据转换和整合。基础平台：用
来支持大量 Internet客户的并发访问，使应用开发商快速开发出灵活多变的应用，尽快把信息系统和业务活动放到 Internet中。
中间件构架是一种应用集成的关键件，不管 BSS/OSS应用分布在什么硬件平台上，使用了什么数据库系统，透过了什么复杂的网络，各种应用的互连和互操作是中间件构
架首先要解决的问题。
针对不同的应用环境，对 BSS/OSS中间件构架有各种不同的要求。在通信方面，中间件构架要支持各种通信协议和通信服务模式，传输各种数据内容，数据格式翻译、流
量控制、数据加密、数据压缩等等； 对工作流应用，需要根据条件以及条件满足状态，将信息、响应状态从一个应用传递到另一个应用；对联机事务处理，需要保证分布式
的数据一致性、不停机作业、大量并发的高效率；对于一个数据采集系统需要保证可靠传输等等。
在 BSS/OSS中间件构架核心，要解决名字服务、安全控制、并发控制、可靠性和效率保证等；
在 BSS/OSS应用开发方面，要能提供基于不同平台的丰富的开发接口，支持流行的开发工具和异构互连接口标准等；
在管理方面，解决 BSS/OSS中间件构架本身的配置、监控等，为 BSS/OSS应用的易用易管理提供保证。
BSS/OSS中间件趋势
五、中间件符合软件发展的潮流：软件构件化（Software Component）技术是在大工业生产启发下应运而生的，是软件技术跨世纪的一个发展趋势，其目的是彻底改变软
件生产方式，从根本上提高软件生产的效率和质量，提高开发大型软件系统尤其是商用系统的成功率。
复用软件一直是整个世界软件业所追求的梦想，软件构件化为实现这一梦想指出了一条切实可行的道路，而中间件正是构件化软件的一种形式。中间件抽象了典型的应用
模式，应用软件制造者可以基于标准的形式进行开发，使软件构件化成为可能，加速了软件复用的进程。因此，中间件是符合软件发展的内在规律的。
六、OSS/J介绍：
NGOSS提供了一个技术无关的框架，而 OSS/J则提供一个符合框架原则的技术相关（Java）的实现方案。
NGOSS关注架构原则，提出了公共通信机制，流程控制外部化，合约定义接口等架构原则，同时定义了共享信息和数据模型，便于应用集成。
OSS/J为构件创建一个标准运行环境，消除了学院框架和实践设计模式间的障碍。事实上，OSS/J在很大程度实现了 TMF的愿景。
OSS/J 的由来：
就在 TMF 于 2000 年提出 NGOSS 的概念时，以 SUN 为首的一些厂商，如 BEA，IBM， NEC， Motorola，Nokia 等，酝酿成立了 OSS/J 工作组(OSS/J，OSS through Java™
Initiative )。他们一直在为加速 OSS/BSS解决方案的开发、简化其中系统组件的部署和集成而努力。
OSS/J 规范的推出是在 JCP（ Java Community Process, ）支持下完成的，以 Java 规约请求（JSR，Java Specification Request）的形式提交。JCP
是 SUN和许多其它主流厂商所主导的一个社团，现有 500多个公司和组织参与。
Roadmap to NGOSS
OSS/J 原则和架构：OSS/J的制定立足于 J2EE平台，它的制定基于以下原则：OSS的功能以 EJB构件定义实现；粗粒度，面向业务的接口；利用应用服务器支持集群，可
扩展性和错误恢复；利用消息机制最小化构件间的耦合；支持工作流；依靠 JCA集成遗留系统
Alignment with TMF NGOSS
工作组利用 JAVA技术，为 OSS/BSS定义实现了一系列的开放的标准 API，提供给 OSS/BSS的开发者使用。OSS/J的优点在于它定义了标准的接口，应用间可以通过此接口
进行交互。API的定义中考虑了其适应性和可扩展性。在设计中应用了许多设计模式，保证了新实体加入时，不会影响到 API的架构。
OSS/J 关注域 (late 02)
各关注域之间的关系
Step 1:
Pick the most
comprehensive
telco business
framework
Step 2:
Pick the only
open standard
software
foundation truly
adopted
Step 3:
Mandate
Standard API's
Step 4:
Integrate best of
breed
interoperable
components
Step 5:
Harmonize
presentation and
processes on low
cost mainstream
middleware
● TMF
NGOSS
● Java
and
Web
Service
● TMF
NGOSS
● OSS/J
Function
al API's
● Java
and
Web
Service
● TMF
NGOSS
● Certified
Product
s
● OSS/J
Function
al API's
● Java
and
Web
Service
● TMF
NGOSS
● JBI, JES,
OpenOffic
e, Identity
Mgt
● Certified
Products
● OSS/J
Functional
API's
● Java and
Web
Services
● TMF
NGOSS
From the theory to practice with
OSS/J
QoS and Performance API
– Performance data
– Alarm data
– Usage data
APIs supporting the following areas first (all Final Draft except Inventory In
Public Draft– final in May’03):
Service Activation API
– Order Management
– Network Activation
Trouble Ticketing API
– Customer Mngt
– Network Level
Scalability, Security, Integr. CORBA, EAI, B2B (ebXML, SOAP,…), etc….
Common API
IP Billing API
– Usage Data Collection
– Billing + RatingInventory API
OSS服务开通 API（OSS Service Activation API或 SA API）： 主要提供了对订单的管
理功能（例如生成、修改、删除、查询订单等）和服务的管理功能。API 中并没有给出指定的“服务信息模型（Service Information Model）”，而是将这部分工作留给开发
者去实现，这样开发者可以根据自己的业务逻辑的需要定义服务信息模型。SA API 中关于订单管理的定义是根据 TMF 603 中的“世界订单信息协定”（World Ordering
Information Agreement）以及 OMG WMF/WfMC的“订单状态模型（Order State Model）”的定义完成的。
OSS故障单 API（OSS Trouble Ticket API或 TT API）：定义了生成、更新、查询、关
闭故障单的一系列操作。网管系统可以通过调用 TT API自动生成故障单，服务提供商也可以利用它产生和处理故障单，客户关怀系统能够调用这些 API将故障单发送给服务
提供商；如果故障单的管理是在一个工作流程中完成的话，那么开发人员可以使用这些 API与工作流引擎进行信息传递。
OSS/J设计的实现依赖如下几个机制：依赖 XML消息实现异步和松耦合交互模型；强类型，基于对象的事件；XML消息机制；基于 JMS的事件和消息订阅机制；利用 JNDI
规范，定位 OSS/J架构元素（会话对象，主题，队列等）的服务；依靠外观模式实现 OSS/J的会话组件接口，以 JVT对象作为参数
技术选择：
OSS/J定义了如下两种交互模式，用以支持 A2A的集成和 B2B的集成：
J2EE™, XML and Web Services
紧耦合紧耦合
集成集成
JavaJava EJBEJB
RMIRMI IIOPIIOP
JavaJava
EJBEJB
RMIRMI IIOPIIOP
松耦合松耦合
集成集成
JavaJava EJBEJB
RMIRMI IIOPIIOP
XMLXML
JMSJMS
B2BB2B
集成集成
XMLXML
WebWeb ServicesServices
XMLXML
WebWeb
ServicesServices
JAVA值类型会话对象（JVT，Java Value Type Session Beans）： JVT是一种 JAVA模
式，通过值对象作为参数来访问后端实体。应用外观模式（facade）,通过单一接口访问系统定义的实体。以 Java值类型对象作为参数，也可进行批量操作。JVT类型接口使
得 JAVA应用间可以进行紧耦合的集成。
XML/JMS消息: OSS/J中定义了 JAVA对象到 XML的映射，在 XML表示和 JAVA对象
间建立了一个等价的对应关系。XML表示的消息请求中定义了操作，它传递使用 XML模式定义的标识和管理实体的状态。XML表示的请求对象被传递到特定应用的消息驱动对
象（MDB，Message Drive Bean），MDB通过 JVT接口操作实体。
第四章 下一代电信运营支撑系统
共享信息和数据模型（SID）设计原理
u 为什么要研究共享信息和数据模型？
u 什么是 SID？
u SID信息模型的设计原理
u SID描述
u SID的应用
一、 为什么要研究 SID？：信息孤岛、信息冗余、缺乏统一的信息术语---交互、信息共
享
新的管理需求
BOSS应用环境愈加复杂：用户和设备的数量增加、提供的服务数量增加、业务链的延伸；BOSS应用和使用的系统复杂：必须满足不同的用户和应用需求，需要灵活的架构
和管理；随需应变的管理
业务提供的障碍
固定的提供和策略 (the EML, NML, and SML are provisioned separately)：Manual
fine-tuning and validation is inconsistent and doesn’t scale 人工的接口造成不一致，Hard to build a flow-through system 很难支持流程
网络部件不能联动：Currently measure traffic load and content，Need to measure
customer, resource or service analysis，A router or switch doesn’t know customer needs, product offerings or personalized SLAs
OSSs 孤立于客户服务和服务提供：Difficult to manage and integrate in real time
解决之道
To define and use a new information modelBuilt towards promoting data sharing and reuse（共享和复用）Built to support multiple mappings（映射） to different
implementations using different data stores
To define and use new extensions of this information modelIntegrated support for SLAs, Contracts, and other Business Entities Integrated support for
translating between different representations of policy Especially between business and device configuration
二、什么是 SID？
The SID is the NGOSS “Glue”
Provides business, system, and implementation views to drive design and implementation
An organized collection of business and system entity definitions and UML models that
Provide a common information/data language
Depict the relationships among the entities
SID and the NGOSS
SID is the NGOSS “glue”
Provides a ：business view，system view，implementation view
Three views necessary to ensure that business requirements can drive system design and implementation
SID and the Industry
SID is a federation of models, not “home-grown”：Material mined from company contributions (BT, Telstra, MetaSolv) as well as ITU, IETF, and DEN-ng
SID is already being used!： TM Forum Catalyst Projects， OSS/J， T1M1 Global Telecom Data Dictionary (GTDD)， By vendors, such as MetaSolv and
Intelliden，By Service Providers, such as BT and Telstra
Entity Template/Entity Pattern
三、SID信息模型的设计原理
信息建模的基本方法：从企业过程模型到企业信息模型、现实世界的概念抽象
四、SID描述
Archetype Used for All SID Models
C u s to m e r In v o ic in g /
P a y m e n t
P o r t fo l io P r o d u c t
S e r v ic e E q u ip m e n t
T e c h n o lo g y
E q u ip m e n tW
o
rk
S a le s /M a r k e t
B u s in e s s
S u p p l ie r / P a r tn e r
C o m m o n
B u s in e s s E n t i t ie s
Who (Party)
<<concept>>
Why (Reason)
<<concept>>
What (Thing)
<<concept>>
When (TimePeriod)
<<concept>>
Where (Location)
<<concept>>
共性业务实体
Party (Simplified)
Interaction Example
Request Response Notification Agreement Command
Interaction Location PartyPolicy
ManagedEntit
y
Phase 2Phase 2Phase 2
Interaction Party (playing arole)
participants are one or more
Product
Offering
invovled in
Product
involved in
Locationoccuring at
Customer-Customer
Customer-Order
Product
设备– 资源 and 资源描述
Equipment – Hardware Classes
CustomerAccountRelationship
relationshipType : String
validFor : TimePeriod
<<businessentity>>
IdentityContactMedium
(from Identity)
<<businessentity>>
CustomerAccountContact
contactType : String
validFor : TimePeriod
<<businessentity>>
0..n
0..n
0..n
0..n
accessedVia
CustAcctCreditProfileReference
financialInstitutionName : String
financialInstitutionAccoutNumber : String
financialInstitutionAccountType : String
financialInstitutionContactName : String
financialinstitutionContactMedium : String
<<businessentity>>
CustomerQuote/Offer
(from Inqui ry Response)
<<businessentity>>
PartyRole
(from Party Role)
<<businessentity>>
CustomerAccountCreditProfile
creditProfileID : String
creditProfileDate : Date
validFor : TimePeriod
<<businessentity>>
0..n1 0..n1
includes
CustomerAgreement
delieveryDate : Date
(from Customer Agreement)
<<businessentity>>
Customer
customerID : String
customerStatus : String
customerRank : String
<<businessentity>>
0..n
1..n
0..n
1..n
entersInto
0..n
1
0..n
1 requests
CustomerAccountTaxExemption
issuingJurisdiction : String
certificateNumber : String
validFor : TimePeriod
<<businessentity>>
CustomerAccountBillCycle
billCycle : String
validFor : TimePeriod
<<businessentity>>
CustomerAccount
accountID : String
accountName : String
accountType : String
accountStatus : String
<<businessentity>>
0..n
0..n
0..n
0..n
usedAs
0..n0..n 0..n
references
0..n
0..n
1..n
0..n
1..n
stabilityMeasuredBy
0..n
0..n
0..n
0..n
impactedBy
0..n
1..n
0..n
1..n
posseses
0..n
1
0..n
1 exemptedFromTaxesVia
0..n
1
0..n
1 receivesABillDuring
Distribution
Channel ProductCatalog
MarketSegment
InterationItem
CustomerAgreement
Item
Product
ProductSpecification
ProductOffering
Location
PhysicalResource
Resource
ProductFeature LogicalResource
Equipment - PhysicalResourceRole
五、 SID的应用
共享信息数据服务---SID应用
数据的处理和存储需考虑的问题：共享信息的实现结构应与分布式的构件接口一致。即：服务（信息服务）；应将处理逻辑和共享数据的耦合降低；对数据封装；对数据
的操作应保证数据的一致性、完整性。尽量提高数据处理的效率
在 NGOSS中将数据分为：局部数据和共享数据。如：订单处理过程中的客户数据是共享数据、内部状态数据为局部。
信息服务层：是对原始数据进行的加工和处理，转换（信息结构、编码）、适配
引入共享信息数据模型的根本目的在于信息的充分共享。单独的 NGOSS共享信息模型将为大量的共享信息服务定义信息模型并提供公共框架。
通过信息共享，实现信息在一定业务流程驱动下的动态交互，即通过业务流程来驱动各部门、各应用系统之间的协调运作，从而实现企业自动化。
第五章 软件体系结构及 NGOSS-TNA
1. 软件体系结构的兴起
2. 软件体系结构的定义
3. 软件体系结构的风格
4. NGOSS采用的软件体系结构 TNA
1、软件体系结构的兴起
六十年代的软件危机使得人们开始重视软件工程的研究。最初软件设计的重点放在数据结构和算法的设计，随着软件系统规模和复杂性增加，整个软件系统的结构和规格
说明显得愈加重要。
在此种背景下，人们认识到软件体系结构的重要性，并认为对软件体系结构的系统、深入的研究将会成为提高软件生产率和解决软件维护问题的新的最有希望的途径。
软件体系结构的设计已经成为软件开发过程中的一个阶段。
自从软件系统首次被分成许多模块，模块之间有相互作用，组合起来有整体的属性，就具有了体系结构。
好的开发者常常会使用一些体系结构模式作为软件系统结构设计策略，但他们并没有规范地、明确地表达出来，这样就无法将他们的知识与别人交流。
软件体系结构是设计抽象的进一步发展，满足了更好地理解软件系统，更方便地开发更大、更复杂的软件系统的需要。
软件总是有体系结构（Architecture）的，不存在没有体系结构的软件。
从细节上来看每一个程序也是有结构的。早期的结构化程序就是以语句组成模块，模块的聚集和嵌套形成层层调用的程序结构，也就是体系结构。
结构化程序的程序（表达）结构和（计算的）逻辑结构的一致性及自顶向下开发方法自然而然地形成了体系结构。
ManagedResource
LogicalResourcePhysicalResource
ManufactureDate : String
SerialNumber : String
PhysicalConnector
CableType : Integer
Gender : Integer
InUse : Boolean
PinDescription : String
Type : Integer
0..n
0..n
0..n
ConnectedTo
0..n
Card
AtomicHolder
PhysicalDevice
IsComposite : Boolean
DeviceGroupID : String
Equipment
ExpectedEquipmentType : String
InstalledEquipmentType : String
InstalledVersion : String
Redundancy : Integer
Hardware
Depth : String
Height : String
MeasurementUnits : Integer
Weight : String
WeightUnits : Integer
Width : String
0..1 0..n0..1 0..n
ConsistsOf
CompositeHolder
EquipmentHolder
AcceptableEquipmentList : SequenceOf String
Address : SequenceOf String
Type : Integer
Status : Integer
0..1 0..n0..1 0..n
EquipmentInHolder
1
0..1
1
HolderInHolder
0..1
0..1
0..n
0..1
0..nHoldsHardware
0..1
0..n
0..1
0..n
HoldsHolders
LineCard
Chassis
PhysicalPort
DuplexMode : Integer
IFType : Integer
Number : Integer
Type : Integer
VendorPortName : String
0..1
0..n
0..1
0..n
PortsOnCard
0..1
0..n
0..1
0..n
PortsOnChassis
Slot
由于结构化程序设计时代程序规模不大，通过强调结构化程序设计方法学，自顶向下、逐步求精，并注意模块的耦合性就可以得到相对良好的结构，所以，并未特别研究
软件体系结构。
随着面向对象软件时代的到来，软件也从传统的软件工程进入到现代面向对象的软件工程，研究整个软件系统的体系结构，寻求建构最快、成本最低、质量最好的构造过
程。
为什么要研究软件体系结构？
----软件工程技术发展的要求
程序设计阶段
早期软件工程
阶段
• 手 工
作坊
• 软 件
危机
1.软件开发无计划性；
2.软件需求不充分；
3.软件开发过程无规范；
4.软件开发产品无评测手
段。
如何更多、更好、
更方便、更快地
开发软件？
• 工程化管理
软件开发
• 以满足功能
需求为主
问题定义；需求分析；概要设计；
详细设计；编码；测试；维护
瀑布模型；演化模型；螺旋模型；喷
泉模型；增量模型；原型模型；组装
可重用构件模型。
？
2. 为什么应用软件开发模型和软件工程方法解决大规模、复杂问题时，
软件系统的质量和效率无法得到保证？
非功能性需求
1. 系统性能要求，可用性要求；
2. 系统可适应性和可移植性要求；
3. 系统可靠性和安全保密性要求；
4. 系统可重用性要求等。解决方法：在系统的局部算法结构设计之前，
着重进行系统的整体结构设计。软件体系结构设计
二、软件体系结构的定义
定义 1：软件体系结构是具有一定形式的结构化元素，即：构件的集合，包括：处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信
息，连接构件把体系结构的不同部分组组合连接起来。
定义 2：一个软件体系结构包括一个软件和系统构件，互联及约束的集合；一个系统需求说明的集合；一个基本原理用以说明这一构件，互联和约束能够满足系统需求。
定义 3：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中，"软件外部的可见特性"是指软件构件提供的
服务、性能、特性、错误处理、共享资源使用等。
总之：软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素（构件）的描述、这些元素（构件）的相互作用、指导元素（构件）集成的
模式以及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原
理。
三软件体系结构的风格
定义：软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效
地组织成一个完整的系统。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。
软件体系结构风格的四种基本要素：
1. 提供一个词汇表：定义与设计元素有关的部件、连接件类型等 2.定义一套配置规则或系统的拓扑限制：明确设计元素
的合法组成方式。3.定义一套语义解释原则：使得设计元素的组成可以适当地约束于配置规则之中，并具有清晰的含义。4.定义可以对基于这种风格建立的系统进行的分析。
如：Client/Server结构风格的实时处理过程的可调度性。
下面是 Garlan和 Shaw对通用软件体系结构风格的分类：（1）数据流风格：批处理序列；管道/过滤器（2）调用/返回风格：
主程序/子程序；面向对象风格；层次结构（3）独立构件风格：进程通讯；事件系统（4）虚拟机风格：解释器；基于规则的系统（5）仓库风格：数据库系统；超文本系统；
黑板系统
下面我们将介绍几种主要的和经典的体系结构风格并比较它们的优缺点。
1、C2 风格 C2 体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2 风格中的系统组织规则如下：（1）系统中的构件和连接件都
有一个顶部和一个底部；（2）构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；（3）一个连接件可
以和任意数目的其它构件和连接件连接；（4）当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
例如：基于消息队列的软件，ACD排队机软件
C2 风格具有以下特点：（1）系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；（2）所有构件之间的通讯是通过以连接件为中介的异步消息交换机
制来实现的；（3）构件相对独立，构件之间依赖性较少。
2、管道/过滤器风格
在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换
及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另
一过滤器的输入。
例如：电信业务支撑系统中的计费批价系统。
管道/过滤器风格的软件体系结构具有的特点：1。构件具有良好的隐蔽性和高内聚、低耦合的特点；2。允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为
的简单合成；3。支持软件重用。重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；4。系统维护和增强系统性能简单。新的过滤器可以添加到现
有系统中来；旧的可以被改进的过滤器替换掉；5。允许对一些如吞吐量、死锁等属性的分析；6。支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务
并行执行。
3、主程序/子程序 Main program & subroutine：一个问题的处理分解成若干个步骤（subroutine），并由控制器（main program）将这些步骤协调在一个单线程中。主
程序充当子过程的调用者，子过程之间又存在复杂的过程调用关系。过程之间通过参数传入和传出数据。
系统结构基本上都是：主程序和子过程 ，调用和返回关系
这是软件设计最直接、最基本的结构关系（部件、连接机制和协议？）
多个子过程通常合并成为模块
模块：Compilation unit, including related declarations and interface （编译单元，包含相关的声明和接口）
为什么需要模块？Management: Partition the overall development effort；divide and conquer (分而治之)；Evolution: Decouple parts of a system so that changes
to one part are isolated from changes to other parts；进化：降低模块间的耦合度，使改变一个模块不会影响其他；Understanding: Permit system to be understood
as composition of mind-sized chunks；理解：系统可以被理解成若干个易于理解的模块的组合
特点：是一切软件结构的最本质、最基础的形式；代码的效率可以通过良好设计部件之间的关系得到。
缺点：代码的可维护性差（功能易变、数据结构易变）；代码的复用性差（单纯的过程概念无法反映软件结构的本质关系，无法成为软件复用的基本单元）
4、数据抽象和面向对象风格
抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操
作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。
面向对象的系统有许多的优点：
（1）因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象。
（2）设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
但是，面向对象的系统也存在着某些问题：（1）为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的
标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。（2）必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果 A使用了
对象 B，C也使用了对象 B，那么，C对 B的使用所造成的对 A的影响可能是料想不到的。
5、基于事件的隐式调用风格：基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个
事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，事件的触发就可以隐式调用模块中的过程。
例如：工作流软件、过程控制引擎（BPM）
5、层次系统风格：层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层
可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约
束。
这种风格支持基于可增加抽象层的设计。这样，允许将一个复杂问题分解成一个增量步骤序列的实现。
层次系统有许多可取的特性：（1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；（2）支持功能增强，因为每一层至多和相
邻的上下层交互，因此功能的改变最多影响相邻的上下层；（3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的
接口，而允许各种不同的实现方法。
但是，层次系统也有其不足之处：（1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设
计师不得不把一些低级或高级的功能综合起来；（2）很难找到一个合适的、正确的层次抽象方法。
7：正交软件体系结构：正交软件体系结构由组织层和线索的构件构成。层是由一组具有相同抽象级别的构件构成。线索是子系统的特例，它是由完成不同层次功能的构
件组成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能。每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在
相互调用的。
正交软件体系结构是一种以垂直线索构件族为基础的层次化结构，其基本思想是把应用系统的结构按功能的正交相关性，垂直分割为若干个线索（子系统），线索又分为
几个层次，每个线索由多个具有不同层次功能和不同抽象级别的构件构成。
正交软件体系结构具有以下优点：（1）结构清晰，易于理解。正交软件体系结构的形式有利于理解。由于线索功能相互独
立，不进行互相调用，结构简单、清晰，构件在结构图中的位置已经说明它所实现的是哪一级抽象，担负的是什么功能。（2）易修改，可维护性强。由于线索之间是相互独立
的，所以对一个线索的修改不会影响到其他线索。因此，当软件需求发生变化时，可以将新需求分解为独立的子需求，然后以线索和其中的构件为主要对象分别对各个子需求
进行处理，这样软件修改就很容易实现。系统功能的增加或减少，只需相应的增删线索构件族，而不影响整个正交体系结构，因此能方便地实现结构调整。 （3）可移植性强，
重用粒度大。因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现体系结构级的重用。
8、三层 C/S软件体系结构：C/S软件体系结构，即 Client/Server (客户机/服务器)结构，是基于资源不对等，且为实现共享而提出来的，是 20世纪 90年代成熟起来的
技术，C/S结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。
表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输的
数据。为使用户能直观地进行操作，一般要使用图形用户接口，操作简单、易学易用。
功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。
数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因
此，一般从功能层传送到数据层的要求大都使用 SQL语言。
9、C/S与 B/S混合软件体系结构：B/S与 C/S混合软件体系结构是一种典型的异构体系结构。B/S软件体系结构，即
Browser/Server （浏览器/服务器）结构，是随着 Internet技术的兴起，对 C/S体系结构的一种变化或者改进的结构。在 B/S体系结构下，用户界面完全通过 WWW浏览器实
现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现。
B/S体系结构主要是利用不断成熟的 WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发
成本，是一种全新的软件体系结构。
我们只讲述了“纯”的软件体系结构。但是，从前面的论述中看出，不同的结构有不同的处理能力的强项和弱点，一个系统的体系结构应该根据实际需要进行选择，以解
决实际问题。事实上，也存在一些系统，它们是由这些纯体系结构组合而成，即采用了异构软件体系结构。
四、NGOSS采用的软件体系结构 TNA
为了保证 NGOSS的目标能够顺利实现，为了解决不同技术的兼容问题，TMF提出了 NGOSS的技术中立体系结构（TNA）。
TNA定义了 NGOSS在系统体系结构方面的功能，是一个抽象的、通用的体系结构。
NGOSS的 TNA：TNA定义了体系结构的概念及概念之间的关系，继承了分布式系统的相关概念。构件、合同、服务、接口、共享数据信息
TNA的核心是：构件和构件间的关系。
构件（component）是 TNA部署的、可管理的基本单元，它是合同的承载者，同时也是服务的提交实体。
构件的定义：功能的二进制实现；有合同定义的接口；可独立部署的单元；可由第三方构造；和构件模型一致
NGOSS 中对构件实现的要求：明确定义其外部关联；用与技术相关的构件模型实现；无论构件是否有持续的状态，其操作所需的信息应永久存储。
构件的交互（基于分布式处理环境）
三层体系结构的构件模式
第六章 电信业务支撑系统设计 环境设计（实现视点）
基于 NGOSS 的基本思想：流程驱动、构件和总线的技术中立。结合目前的软件体系结构和中间件技术。应用已有的中间件技术，提出了一个新一代运营管理支撑平
台的软件体系结构。所谓支撑平台：可以部署和运行系统的平台。
工作流：一般而言，电信运营管理支撑系统应该不仅仅能够支持电信企业内部的业务处理流程，还应该能够提供对运营商与客户、运营商之间的业务处理流程的
支持，各种业务处理流程都应能够无缝地穿越相关软件系统的边界。
工作流系统通过对电信运营管理软件实体以及相关电信业务流程的抽象，建立了能够对业务流程进行快速、灵活重组的处理机制，提供了一套完善的关于业务流
程建模、执行监控及其管理工具。
业务流程执行引擎：平台的业务流程执行引擎为业务流程实例的执行提供运行环境。作为解析和执行驱动工具，业务流程执行引擎可对业务流程描述进行解析，
可通过对相关业务组件的调用实现对其执行的控制。
消息总线：平台消息总线根据业务流程执行引擎的调度，在业务组件之间进行相关的数据和控制命令的传递，并根据时效等策略要求，将各业务组件处理后的信
息反馈给业务流程引擎。消息总线采用管理者/代理者工作模式。在实际应用中，总线上一般可同时存在多个消息服务器（manager)、消息客户端代理(agent)，以及
共享信息模型库。
适配器：适配器主要负责将用不同技术实现的业务功能组件的交换信息转换成统一的消息格式，并通过消息总线进行传输，从而完成异构系统之间的信息交互。
适配器完成的工作主要包括以下两个方面：在业务流程执行之前，适配器按 Web Service 的接口方式，将接入的业务功能组件的功能描述和适配器自身的描述通过服务
注册模块在消息服务器 Manager上注册，以供其它的业务组件查询调用；
2、在业务流程执行过程中，发送方通过服务调用模块发出调用请求，通过其消息处理模块按照预先定义好的格式，将发送方发出的信息进行格式转换，然后将转换后的
信息发送到消息总线，消息总线负责将消息发送到接收方，接收方通过消息处理模块解析消息并将消息发送到服务调用模块，调用接收方的业务功能组件，调用完成返回后将
消息反馈给消息总线，消息总线负责将返回的消息发送到发送方，发送方的消息处理模块对消息总线返回的具有统一格式的信息进行解析，将解析后的结果返回给发送方的业
务功能组件。
共享信息模型（SID）实现
采用 UML类图对各个管理域中的共享数据进行数据建模，定义相关的共享对象及其属性，以及对象与对象之间的关联关系；同时采用公共信息模型（CIM）的元语言描述
机制，描述数据的属性、相关操作及其相互之间的交互关系。
第七章 NGOSS体系及方法
引言：
问题的提出：基于 eTOM 提出的电信业务运营流程框架，如何设计和规划支撑系统？传统的以单一的电信业务运营流程为驱动的设计的弊端（例如 97 系统），如何解决
综合业务的问题？如果按照横向的业务功能组进行系统架构的规划和部署，那么数据如何的共享。
1. NGOSS系统体系结构的理论基础--分布式系统的参考模型 RM-ODP概述
2. NGOSS概述
3. NGOSS方法论
一、RM-ODP概述：
开放分布式处理 ODP是分布式处理（计算）技术发展的高级阶段，试图解决网络环境下，异构系统的交互及接口问题。提供应用程序一致的接口模型。实现分布操作的
互操作、访问透明、可移植。开放分布式计算参考模型（RM-ODP）提供了分布式系统的框架，使异构的、自治的分布式系统部件之间可以集成与互操作。RM-ODP 框架是抽象
的模型—分布计算模型，核心概念：服务、服务的导航（选择）。RM- ODP 从 5 个视角（视点）描述分布式系统。分别是：企业视点、信息视点、工程视点、计算视点、技术
视点。每一种视点是从不同的角度对一个复杂的分布式系统进行的抽象和描述。RM-ODP是指导电信业务运营支撑系统进行业务/技术规范编制的指南。
TINA System Specification Method
ODP-RM的视点：
1、 企业视点：目标：系统实现的目标；范围：系统的边界；策略：规范描述系统的业务需求。
包括：角色（roles）和活动（activities）；ODP系统与外部环境的交互作用；企业的组织结构；处理流程；相关的安全和管理策略
TMF-eTOM就是电信业务运营支撑系统的企业视点。
2、信息视点：描述企业对 ODP系统的信息需求。包括：信息模型（实体及实体间的关系）、信息流。信息结构（信息元素、
对象）、信息之间的关系、信息的变化和导出及相应的规则、信息的属性、信息流、信息处理的形式、逻辑划分
基本概念：模式：静态模式：定义某时刻信息对象的状态和结构；不变模式；动态模式；完整性规则；关系：对象间的联系
3、计算视点（Computation Viewpoint）：描述 ODP系统的功能性分解、互操作性、可移植性：功能分解为对象和接口；互操作为对象在接口上的交互；
技术中立（独立）：应有独立于所运行的计算机和网络，体现为分布透明性。
从计算视点看：ODP系统由许多计算对象组成，对象包括数据和处理、并提供与其他对象的接口界面。
计算规范定义：系统中的对象、对象的活动以及对象之间的交互。对象间的交互可以是面向操作的（RPC机制），或面向流的（生产者/消费者）：面向操作的接口—客
户/服务器模型；面向流的接口—数据流；
Computational Modeling Concepts
Type1 Type2
Type3 Type4 Type5
generic relationship
1+
role1 role2
composition (aggregation)
containment (inheritance)
InformationInformation
viewpointviewpoint
EngineeringEngineering viewpointviewpoint
Meaning
Animation Distribution
NCCENCCE
DPEDPE
KernelKernel
Network
Nodes
DPEDPE
KernelKernel
NCCENCCE NCCENCCE
Stream InterfaceObject
ComputationalComputational
viewpointviewpointOperational
Interface
DPE
server
C
O
C
O
C
OC
O
BusinessBusiness
viewpointviewpointstakeholde
r
administrative
domain
RP
stakeholde
r
.
adm. dom.
business
role
business
role
business
role
business
role
business
role
business
role
RP
.
RP
RP
RP
KTNKTN
DPEDPE
KernelKernel
TINATINA
systemsystem
Framework &
Requirements
Multiple Interface Objects in the TINA-DPE
4、工程视点（Engineering Viewpoint）：支持分布式计算所要求的透明控制机制和功能实现。即：系统的部署和实现环境:
描述运行 ODP系统功能的抽象体系结构;确定用于管理局部和物理分布的系统资源所需的抽象;定义支持 ODP功能的各种对象的任务；确定不同对象之间的参考点；
工程视点描述的是对象和通道。
对象包括：基本工程对象：对应计算视点的对象;结构对象：其它对象
通道：通信机制
五、技术视点: 规范测试信息
ODP-RM是对 ODP系统的不同角度的抽象，由 5种视点规范构成了系统规范说明的完整框架。
专题二：
NGOSS(下一代电信运营软件系统）
1. NGOSS概述
2. NGOSS组成
3. 技术特性
4. 技术思想
5. 开发方法及生命周期模型
一、NGOSS概述
下一代运营支撑系统（NGOSS）是由电信管理论坛（TMF）提出的新一代 OSS/BSS体系。NGOSS从：系统（即插即用规
则）、过程（企业事务过程模型）、信息（关联处理公用数据）、产品（COTS）四个方面保证 OSS体系具备了标准化、可逐步演进、保证互连和互操作（开放）、实现端到端管理
和高度自动化的特点。
NGOSS提出一系列的文档、信息模型和代码，分析研究企业核心业务流和信息技术，提出一套指导 OSS/BSS建设的系统框架，帮助开发商迅速开发支撑系统，满足电信运
营商对 OSS/BSS 建设的需要，使 OSS/BSS 的设计和开发从满足个别运营商的个体需求扩展到分析电信运营商的整体需求，使 OSS/BSS 的设计和开发进入到一个崭新的时代。
NGOSS的目标是贴近运营商需求，使系统开发变得更迅速、更灵活、成本更低。
二、NGOSS的组成：
当前的 NGOSS由四个主要部分组成：增强的电信运营流程框架 eTOM，用于描述电信企业运营过程，是 NGOSS 赖以建立的企业运营和管理模型；（企业视点）；共享信息和
数据模型 SID，规范系统使用的信息结构和内容；（信息视点）；技术中立系统结构 TNA，描述完成 NGOSS目标的系统抽象体系结构；（计算视点）；部署和兼容性测试（技术
视点）
三、NGOSS的技术特性：
eTOM提供了一个抽象的、通用的电信运营商企业运营过程模型，该模型是建立稳定的 OSS/BSS系统奠定了基础。
在建立实际的 OSS/BSS系统，必须解决系统设计和实现的问题，其中包括：确定系统体系结构和应用各种技术，从技术的角度考虑，如果将上述的业务需求映射到对系
Multiple interfaces are a consequence of:
Object composition
Different users accessing the same object with different rights
Different views on the same object
O
O2O1
O3
O4
composition
decomposition
统要求，我们会要求系统具有以下技术特性：
1、互操作性：为了提供端到端的支持，系统互联以及保证系统的演化，BSS/OSS必须与其他系统互联；
2、可伸缩性：对于电信运营商来说，企业经营规模的变化，用户数量的变化和网络规模的变化，都需要系统具有良好的可伸缩性；
3、可演化和可移植性：对于电信运营商来说，系统要面对不断变化发展的经营局面，就必须不断升级和演化，以支持最新的网络技术和业务，支持最新的营销概念和方
式；
4、向后兼容性：为了在系统连续运行的同时，完成新增功能的演化，这一要求是不言而喻的。良好的向后兼容性可以降低新增构件和系统时的风险。降低系统开发和部
署的成本。
四、NGOSS 技术思想
受到软件产业的组件技术和组件开发方法的启示，NGOSS 提出了基于组件（构件）的面向对象的分布式 BSS/OSS 解决方案。随着功能封装、接口协议定义等组件开发
方法被业界普遍认可，业务过程流、公共总线结构、公共业务数据、NGOSS组件等的研究迅速开展起来。
（1） 业务过程流： NGOSS将业务过程流从组件中剥离出来，使每个组件成为一个功能实体，从而使得对单独组件
的开发要求转变为对过程控制的业务逻辑要求。即：业务过程和业务功能（逻辑）分离。在改变业务过程流时，组件只需完成公共协议中定义的接口功能，可以通过简单的流
程定义来改变业务过程流，而无需修改应用组件。这样也使得应用组件可以重用，组件的开发更加方便，灵活性更高。同时，NGOSS框架允许业务流程的定制、改造和优化，
从而实现企业业务流程再造。
（2）公共总线结构 ：点对点的系统集成方法要求每个业务都要有面向其他系统的接口，这使 OSS/BSS变得越来越复杂，
并且难以维护和扩展。为了解决这个难题，NGOSS引入了公共总线的概念，通过公共总线使原有的各个应用系统（如网管系统、客户服务系统、业务支撑系统等）间实现信息
交换。通过引入公共总线结构，NGOSS达到了各个组件相对独立、整个平台稳定可靠、系统具有可扩展性和灵活性的目的，从而使 NGOSS能够高效整合数据和业务流程并适用
于各种应用和异构硬件环境。
（3）共享信息数据模型（SID）：共享信息数据模型指在各种业务过程之间需要使用的业务信息和需要存储的业务数据。
在一个特定的业务过程中，多个组件会由于不同的目的，在同一时间使用共同的信息。这样的信息需要从整个企业的层次定义（比如：企业的客户数据），而不能从组件的层
次定义。应用组件访问数据时，通过这些共享信息数据模型的服务接口来实现。
引入共享信息数据模型的根本目的在于信息的充分共享。单独的 NGOSS共享信息模型将为大量的共享信息服务定义信息模型并提供公共框架。
通过信息共享，实现信息在一定业务流程驱动下的动态交互，即通过业务流程来驱动各部门、各应用系统之间的协调运作，从而实现企业自动化。
共享信息服务
数据的处理和存储需考虑的问题：共享信息的实现结构应与分布式的构件接口一致。即：服务（信息服务）；应将处理逻
辑和共享数据的耦合降低；对数据封装；对数据的操作应保证数据的一致性、完整性；尽量提高数据处理的效率
在 NGOSS中将数据分为：局部数据和共享数据。如：订单处理过程中的客户数据是共享数据、内部状态数据为局部。
信息服务层：是对原始数据进行的加工和处理，转换（信息结构、编码）、适配
（4）NGOSS 组件电信管理论坛用组件的方法来构建 NGOSS 系统。组件是对象，是可用代码的封装，这些代码可以用来执行应用程序的一些功能。一个软件组件是一段
代码，它用来实现一系列已定义的接口。组件不是完整的应用程序，不能独立运行。
NGOSS 的组件可以是较大的模块（如计费模块、客户服务模块等），也可以是较小的模块（如用户地址显示模块、用户总费用计算模块等），但必须声明组件功能与使用
者的关系、组件功能与业务数据之间的依赖关系、组件处理过程的层次关系以及与其他组件的相互关系等。
五、NGOSS开发方法及生命周期模型
借鉴了 RM-ODP的视角概念；采用了 MDA方法；软件开发生命周期+迭代
1、软件开发方法论 GB927文档前一部分主要介绍了软件开发结构和方法论，包括：Zachman Framework、Reference Model for Open Distributed Programming、Model
Driven Architecture(MDA)、Unified Software Development Process(USDP)。
其中的 MDA 就是大家熟悉的 OMG 近几年力推的从系统模型到技术模型平滑演化的方法论。其又包括 Computation Independent Business Model(CIM)、Platform
Independent Model(PIM)、Platform Specific Model(PSM)。三者正好是层层递进的将业务演化到技术实现。
NGOSS与 RM-ODP的对比
TMF 结合以上几种适合电信运营要求的优点，提出了名为 SANNR的方法论。这个方法论的名称来自 Scope、Analyze、Normalize、Rationalize、Rectify五个单词的首
字母。Scope(范围)：定义解决方案的边界、任务目标和业务方面的高层用例；Analyze(分析)：在范围限定下描述环境、详细用例、处理图、策略列表；Normalize(标准化)：
获得处理图的公共词汇表，以及单独的统一模型；Rationalize(合理化)：验证标准化模型是否要修正(间隙分析、重复性分析、冲突分析)，决定何时不再修改；
Rectify(校正)：修改、删除、增加功能，满足第 4步中的要求，完成后转到步骤 3；
2、 合约：合约概念是 NGOSS系统中著名的 Business View、System View、Implementation View、Deployment View所对
应的 COTS 组件进行交互的基础和规范，地位非常重要。就像我们大家所知道的那样：做一个系统最重要的事情之一就是定义好与外界系统的接口问题。这个概念也是 eTOM
从 到 演化中在其架构中进行的主要增强之一
专题一：下一代电信运营支撑系统的关键技术 EAI专题
1. 引言
2. EAI的概念
3. 数据集成
4. 应用集成
5. 流程集成
6. 用户界面集成
一、 引言
问题的提出：下一代电信运营支撑系统是由分布网络环境多个系统的协同，共同完成端到端运营流程的体系架构;各个系
统之间如何协同？如何集成遗留系统？
二、EAI概念综述
企业应用集成(EAI)的概念在 IT界提出和讨论已经有几年的历史了，最初大家谈到的 EAI的概念，相对后来 EAI的发展来看，可以说是一个狭义上的 EAI，正如其字面上
的含义“Enterprise pAplication Integration”，即企业应用集成，仅指企业内部不同应用系统之间的互连，以期通过应用整合实现数据在多个系统之间的同步和共享。
现在大家谈到的 EAI的概念，具有更为广义的内涵，它已经被扩展到业务整合(Business Integration)的范畴，业务整合相对 EAI来说是一个更宽泛的概念，它将应用
整合进一步拓展到业务流程整合的级别。业务整合不仅要提供底层应用支撑系统之间的互连，同时要实现存在于企业内部应用与应用之间，本企业和其他合作伙伴之间的端到
端的业务流程的管理，它包括应用整合，B2B整合，自动化业务流程管理，人工流程管理，企业门户以及对所有应用系统和流程的管理和监控等方方面面。
EAI概念的理解是：数据集成、应用集成和业务流程集成等多个方面。
具体到技术层面上的划分，我们认为一套完整的 EAI技术层次体系应该包括:应用接口层；应用整合层；流程整合层；用户交互层。
应用接口层（适配器）：解决的是应用服务器与被集成系统之间的连接和数据接口的问题。
应用集成层：解决的是被集成系统的数据转换问题，通过建立统一的数据模型来实现不同系统间的信息转换。
流程整合层：将不同的应用服务系统连接在一起，进行协同工作，并提供商业流程管理的相关功能，包括流程设计、监控和规划，实现业务流程的管理。
用户交互层：是为用户在界面上提供一个统一的信息服务功能入口，通过将内部和外部各种相对分散独立的信息组成一个统一的整体，保证了用户既能够从统一的渠道
访问其所需的信息，也可以依据每一个用户的要求来设置和提供个性化的服务。
1、 应用接口层
EAI 要解决的问题是独立应用系统之间的连接，传统的应用系统之间的连接方式包括了：CORBA, SOCKET 通讯, RMI, RPC, EJB, COM/COM+, HTTP 和 FTP 等，数据库系
统之间常见的连接规范包括：ODBC, JDBC。上述这些规范在企业应用系统或数据库系统之间传统的点对点的连接中得以广泛应用。
而在 EAI的应用接口层，主要是通过适配器技术将原有数据库系统、应用系统和原有网络服务组件封装起来，实现系统之间的互通互联。
适配器是 EAI厂商或产品厂商为了解决系统之间的连接而开发的可重用的、统一的接口，通过该接口每一个应用系统仅需要与业务整合平台相连，而不需要与每个与之
交互的应用系统相连。
2、 应用集成层
应用集成层是 EAI技术层次体系中的核心层次，该层次是连接业务流程管理层和应用接口层的桥梁。数据信息在业务流程中的流转以及在各个应用系统之间的交互必须
建立在数据源和数据目的地都能理解该数据信息的基础之上。在应用整合层我们定义了能为数据产生源、数据处理地、数据投送地都能理解的信息处理规范方式、方法和规则，
包括：数据格式定义、数据转换和消息路由。
数据格式定义：数据格式定义是 EAI执行信息处理的基础。一般认为数据是信息的载体，数据只有通过一定的方式对信息内容进行标识，转换为统一格式之后，才
能实现在不同的异构系统间的发布和共享。
作为数据格式，通常有三种方式：使用特定行业已经存在的标准；使用 XML 作为数据格式的统一描述语言；用户自定义格式
数据转换：数据转换是应用整合层的重要组成部分，它是指将不同的信息格式和语法重新转换成能被目标应用系统所理解的数据格式和语义的整合技术。数据转换
包括两个层面的内容，即数据格式转换和数据语义转换。
格式转换：能够实现任意形式的数据格式都转换成为所指定的一种统一、规范的标准数据格式（如 XML）上去，在此基础上再来执行后续相关的信息处理工作。
语义转换 ：在现实的数据环境中，不仅数据源是异构的，数据表示十分复杂，数据之间的语义联系也相当丰富。数据要在不同的应用系统之间或者业务流程之间交流，
必须确保交互的双方对数据表达的语义有统一的认识。EAI平台上应该建设一个全局的语义完整性控制，在应用整合层面上解决由于各局部数据库的异构性而引起的在数据对
象的命名、数据的格式以及数据结构等方面存在不一致的问题，为全局用户提供全局数据信息的集成和统一的表示。
消息路由：消息路由通常是指为了使消息在不同的消息域中共享，而将消息从一个域路由到另外一个域的信息处理手段。消息路由建立在已有数据格式定义和数据
转换基础之上，通过消息中间件技术能够动态的识别和理解从源应用发出的消息并且把它发向特定的应用系统。
3 流程集成层
流程集成概述：业务整合着眼于提高每个业务流程的效率和效能，利用业务整合，业务流程被推向解决方案的最前沿，通过采用成熟的技术可以成功地创建模型，
自动化流程处理过程，监控和管理这些业务流程，从而满足业务变化的需求。它通过同时协同人工参与流程和自动化运行的流程来整合一个跨越企业内部同部门和不同系统之
间的业务流。
业务流程管理(BPM)：BPM 是在企业范围内实现业务流程自动化，使得企业应用之间不再孤立，企业的软件更加模块化、标准化，从而使企业变得更加敏捷更加灵
活。BPM能够用来实现企业内的流程自动化，常用的就是实现跨系统流程的自动化。BPM最突出的，是能够实现自动和手工混合流程的自动化，把流程中涉及的系统连接起来，
实现业务步骤（包括手工的和系统实现的）的自动化。多个流程可以作为独立的单元进行存取，也可以联合起来形成一个更高层次的流程。
BPM是一个完整的企业应用集成实现策略，它使企业内的一个个分离系统变成了一个支持业务过程的连续系统，满足企业的整个业务过程需求。在一个基于流程的企业
中，企业为其所有的业务事务处理都清楚地定义了过程，企业的每一个活动都是为了完成特定的业务过程任务。
业务流程通常都是由事件驱动的，事件就是由用户行为、软件或时间等引起的一些活动或状态。BPM实现了跨越多个异构的应用系统的业务过程自动化。
3 流程集成层
业务流程分企业内部业务流程和企业外部业务流程。因此，企业需要实现的业务流程集成分为三部分：内部业务流程集成，是通过 BPM实现的，外部业务流程集成，是
通过 B2Bi实现的，内外部业务流程集成。是通过 BPM和 B2Bi共同实现的。
BPM实现了一个平台两种业务流程模式（业务流程自动化和人员介入工作流）的融合能力，包括： 流程建模、流程监控、
工作流引擎。
流程建模：流程建模是对业务模型进行集中设计并对模型进行管理。流程建模使用活动图形和常用结构图等模型结构来设计业务模型，用图形交互界面方式建造内部和
外部不同组织的控制流模型。
流程监控 ：流程监控是对系统中的核心业务流程进行分级和分类（分级可以按照业务的优先级来划分，分类可以按照业务类型进行规类）的管理。使用预定义的图形
格式，监查特定流程实例，对业务流程的动态执行过程实时跟踪，并对业务流程执行情况（如业务流程执行成功、失败、回滚）进行统计。
工作流：业务流程自动化只是解决了业务流程管理中的部分问题。譬如说，随着程序的自动化，人的工作就集中在异常事件的处理。然而，当需要员工作出频繁判断、
决策标准确定、需要层层审批，或需要用户确定丢失命令位置等分析工作时，流程自动化就不适合了。 工作流是指那些需要人工进行干预的业务流程。
工作流无需编程即可支持快速的、组织管理严密的流程开发和部署。用户可以在工作流设计中完成流程中数据结构的定义，进行数据映射，无需编写代码。工作流在设
计上支持路由选择、连接、控制、比较、计时和通知等功能。同时 EAI平台提供的协同工作，版本管理功能，能在不影响运行工作流程的情况下，升级和部署业务流程。 同
时通过流程监控，可以监控工作流上的所有工作流的状态，包括：工作流是否被激活，工作流被执行到哪一个任务环节，工作流中的某一任务是否已经被处理或正被处理等。
电信运营管理系统的 EAI体系结构
企业间整合(B2Bi)：B2Bi 即 B2B Integration，指企业间的信息整合，即企业合作伙伴间，集合彼此的业务流程、应用软件、资料及 Web 功能。B2Bi 基于外部网
络（如 Internet）,安全而有效地实现信息交换与交易发生。不同贸易伙伴间存在不同的贸易协议与数据格式，同样通过协议转换与数据传输服务，实现这些信息的发送、接
收与验证。B2Bi关注于企业对外的业务流程集成，
4 用户交互层
用户交互层是 EAI 与用户实现人机交互在表示层面上的扩展。涉及的内容包括:展示内容的集成（门户应用）、单点登陆（Single Sign On）、用户统一管理、用户认证
授权的管理等。现今很多 EAI产品都提供了对用户集成这几方面内容的支持。
EAI-industry-consortium 的 ESB 实际侧重了对一个 EAI 架构的消息处理、数据转换和应用连接三个层面的讨论，强调了以 MOM 技术为核心架构信息处理引擎，通过
JMS、JCA、Web Services等异步方式达到与周边目标系统的松偶合集成。
而 TMF今年推出的 NGOSS 中 TNA架构的定义中详尽地描述了分层服务架构的 TNA框架，将 ESB的框架定义为 SIM的一个重要组成部分，
TNA 架构，包含：基础服务机制：主要是现在应用服务器、网关、集群等技术；基础框架服务：包含服务命名、查找、定位、调用等技术；OSS 框架服务：包含了那些
组成业务服务的基础 OSS服务，如日志服务、鉴权服务等；OSS应用：具体的 BSS/OSS服务组件；流程服务：包含 BPM/BAM等技术，将流程控制与组件实现剥离；策略和安全
管理：全前言的 AAA控制；
SIM：信息共享模型和架构。
NGOSS应用平台
主要包含以下几个组成部分：交易处理应用服务器：承载电信企业海量和高性能的交易处理引擎；应用集成的集成代理器：包含了消息处理、数据映射、流程管理、适
配器技术等完整的集成代理技术；用户交互的门户集成平台：承载多渠道、多协议、多人群的访问平台；共享的中间件基础设施，提供 SOA、EDA的支持；共享元数据管理、
数据共享模型和实现平台；集成的企业管理平台，支撑运营和管理；集成的开发部署平台，提供从门户、消息、数据转换、适配器、工作流、交易处理的集成开发、部署环境。
第九章中国联通电信业务支撑系统 CDMA 1X数据业务支撑（案例分析）
1. 背景及说明
2. 系统建设目标及原则
3. 网络的组织结构
4. 应用软件总体结构
5. 支撑系统功能
6. 系统接口描述
7. 系统其它技术要求
一、背景
中国联通正大力推出基于 CDMA 1X技术的无线数据业务及其增值业务。
CDMA 1X数据业务及其增值业务对整个支撑系统提出了新的要求，需要对原有 CDMA专业计费、综合结算、统一客户
资料、综合帐务、综合营业、综合客户服务等支撑功能上做相应的改造与扩充。
规范编制说明
本规范修订完善了综合电信业务支撑系统的信息模型；提出了支撑建设方案；在原有营业、帐务、客服、计费（含采集）、结算、统一客户资料、信用控制/防欺诈子系
统中增加了对 CDMA 1X数据业务的支撑功能，并对处理流程进行了描述；规范了支撑系统各子系统之间关于 CDMA 1X业务的内部接口，规范了支撑系统和 CDMA 1X网络平台、
增值业务综合管理平台、165互联网平台等外部系统的接口。
二、建设目标及原则
1、总体建设目标 2、建设原则 3、技术原则
总体建设目标：CDMA 1X支撑建设的总体目标是：在现有统一的运营支撑体系中增加对 CDMA 1X业务的支撑。该体系具有以下特征：快速的业务部署能力，可配置
地实现对基于 CDMA 1X的数据业务、增值业务的支撑；帮助联通实现灵活的市场策略，以获取、维持高价值的客户群；具有完善的收入保障能力，保证收入在支撑的每个环节
不会流失，支撑处理的每个环节具有可管理性；平滑地适应用户量的增加；能够提高运营效率，降低投资以及运营成本。
、建设原则：1、协作性；2、功能分配合理的清晰性；3、适应性；4、资源合理利用性 5、系统延续性
、技术原则：一体化原则；适应性；先进性；安全和可靠；灵活性；实时性；准确性；开放性；技术独立性
三、网络组织结构
1、CDMA 1X数据业务网络结构
2、CDMA 1X支撑网络结构
CDMA 1X数据业务网络结构
由 CDMA 1X分组数据接入网、增值业务综合管理平台、165互联网等组成；系统由总部、省分公司两级平台组成。
总部包含有 CDMA 1X 的 Broker AAA、增值业务平台、165 总部认证平台。其中 Broker AAA 负责国际用户的认证转发、省际 VPN 用户的认证或转发；增值业务平台负责 SP 的
管理与结算、增值应用的接入管理。165负责上网卡用户的认证。
省分包含无线数据接入平台和 165认证平台，目前无增值业务管理平台。其中无线接入平台包含无线数据接入点 RN、分组数据业务节点 PDSN，认证服务器 AAA。
CDMA1X支撑网络结构
总部部分包括增值业务部增值业务综合管理平台，信息系统部总部结算中心、互联网部的总部 165计费系统。
增值业务综合管理平台由增值业务 SP结算平台、增值业务接入管理平台两部分组成。
总 部
B r o k e r
A A A
总 部 1 X
b r o k e r A A A
R a d i u s
1 6 5 / A T M 传 输 网
省 分 1 省 分 2
L a p t o p c o m p u t e r
S D
R N
S D
D A T A X
e Z 1 2 8 K T A E R D R R S / C C S S O / T R D / R C D / 1
3 2 1 6 8 4 2 1 S Y N CO V FE R R -
A L M T E S T P W R
E R R I N S E R R R S T
M O D E
0 1
R A T E S T S P N C R
M O D E R A T E
+ +
P D S N / F A V A A A
省 分 1 6 5 网 / A T M
M o d e m
N A S
接 入 地 R a d i u s
1 6 5 接 入 网C D M A 1 X 接 入 网
省 分 公 司
外 部 S P / C P联 通
内 部 增 值 业 务 提 供 平 台
总 部 增 值 业 务 综
合 管 理 平 台
总 部 1 6 5
H A
H A A
A
增值业务 SP结算平台负责 SP的结算、二次批价内容详单的收集与标准化、提供与支撑系统间的文件形式接口。
增值业务接入管理平台负责 SP 信息的存储与管理、用户增值业务接入鉴权信息的存储与管理、对联通内部增值业务的公共管理、为无计费能力的 SP 提供内容代计费功能、
提供与支撑系统间的消息形式接口。
省分部分包含 C网话音/流量专业计费、165专业计费、综合结算、统一客户资料、综合帐务、综合客服、综合营业等。
C网专业计费子系统负责对 AAA、HLR的设备开通，话音、流量计费。 165专业计费子系统负责 PCMCIA上网卡部分的内容计费功能。
综合结算子系统负责 C网流量、话音的结算功能。 综合营业子系统负责对数据、增值业务的受理、开通查询等。统一客户资料子系统负责 NAI等相关信息的存储。综合帐
务子系统进行包括数据、内容服务在内的帐务处理。
四、应用软件总体结构
1、应用软件设计要求；2、CDMA1X支撑体系结构；3、支撑软件的分层原则
应用软件设计要求
1、软件工程方法 ；2、模块化、组件化技术；3、大型关系数据库；4、系统易操作性
CDMA1X支撑体系结构
支撑软件的分层原则
五、 支撑系统功能 1、总体描述 2、计费功能 3、统一客户资料管理和服务 4、营业功能 5、帐务功能 6、缴费功能 7、
信用控制/防欺诈 8、结算功能 9、客服功能
、总体描述
基本处
理单元
基本处
理单元
基本处
理单元
文件 文件 文件
业务处理
逻辑
业务处理
逻辑
业务处理
逻辑
GUI 浏览器
系统
接口表示层
业
务
逻
辑
层
数据层
软件的体系结构
参
数
管
理
系
统
监
控
安
全
管
理
数
据
管
理
系统管理
…
…
基本处
理单元
综
合
业
务
支
撑
系
统
增值业务
综合管理平台
客服
标准联
机
工
单
统一客
户资料
二次批
价 综合结算
数据采
集
综合营业 综合帐务
综合接
入管理平
台
SP结算
管
理平台
资
料查
询
AAA MSCHLR
HLR
联机命
令
处
理
数据采
集
C 网专业计费
AA
A
联
机
命令处
理
流
量计
费
话
单
AA
A联机指
令
HL
R联机指
令
HLR
联机工
单
AA
A联机工
单
一次批
价计费详
单
165 专业计费
数据采
集
联机命
令
处
理
Radius
内容计费详单
联机工
单
联机指
令
漫游流量详单
Radiu
s
SP
投诉信
息
SP
代收费实收信
息
统一经营信息服务子系统
SP结算结果信息 经营统计信息
联机指
令
语
音
话
单
计
费
内
容
详
单
计
费
内
容
详
单
计
费
二
次批
价
1、SP资料
1、SP资料
2、编码信息
2、编码信息
3、终端资料
计费功能
为了满足 CDMA数据业务发展的需要，现增加 CDMA 1X数据业务流量计费功能:功能结构,数据采集,预处理,一次批价,
联机指令,统计,系统管理
计费功能（功能结构）
、统一客户资料管理与服务
为了支撑 CDMA 1X业务，统一客户资料信息模型中的实体及属性需要进行新增与修改，统一客户资料子系统提供的接口服务单元也需要进行相应的新增与修改:信息模
型,接口服务单元,客户资料沉淀,系统管理
、统一客户资料信息模型
、统一客户资料信息模型
数据采集 联机指令一次批价预处理
AAA上的原始流
量话单
一次批价后的
详单
业务处理
管理 接口管理 系统管理
数据
营业子系统工单请求/
处理结果
AAA系统指令请求/反
馈结果
用户I D
用户
客户I D客户I D
客户
套装I D
套装
NAI I D
NAI
套餐I D
套餐用户I D
套餐用户NAI
对应关系
用户I D
套装用户NAI
对应关系
套装客户NAI
对应关系
NAI I D
套餐I D
NAI I D
套装I D
NAI I D
套装I D
营业功能
为了满足 CDMA数据业务发展的需要，需对综合营业系统进行相应改造和增加:功能结构,业务受理,综合查询,参数管理
营业功能（功能结构）
营业功能（业务受理）
以业务新装为例说明：CDMA 业务新装，选择开通公用 NAI 上网功能（CDMA 1X 用户）和 PDSN 自动构建 NAI 上网功能（CDMA 95 用户）;CDMA 业务新装，用户要求使用
现有的私有 NAI上网;CDMA业务新装，用户要求新建私有 NAI
营业功能（综合查询）:用户资料信息查询（改造功能）.CDMA1X数据详单查询（新增功能）。帐务查询（改造功能）。
套装/套餐查询（改造功能）.SP基本信息/业务信息查询。（新增功能）.终端信息查询（新增功能）.NAI权限级别信息查询（新增功能）.特殊 NAI资源信息查询（新增功能）
营业功能（参数管理）: NAI域信息管理。SP基本信息和业务信息管理。NAI权限级别管理.特殊 NAI资源管理.费
率描述代码管理.优惠描述代码管理
综 合 营 业 子 系
统
统 一 客 户 资 料
子系 统
增 加 对 智 能 网 类 型 标 识 、 数 据 业
务 级 别 变 更 、 用 户 I P服 务 类 别 等
字 段 的 修 改 功 能 。
根 据 用 户 要 求 ， 用 新 数 据 替 换 相应 字 段 的 老 数
据
综 合 营 业 子 系
统
统 一 客 户 资 料
子系 统
2. 处 理 用 户 信 息 数 据
1. 查 询 数 据 用
户
3. 发 送 用 户 资 料 数
据
注 ：
改 造 处 理 ： 1、 2、 3、 4、 6
4. 发 送 AAA联 机 工 单 数 据 与 HLR数 据
CDMA专 业 计 费子 系
统
互 联 网
5. 发 送 I MSI 、 MDN等 数 据
6. 发 送 I MSI 、 MDN等 数 据
增 值 业 务 接 入
管 理 平 台
新 增 处 理 ： 5
帐务功能: 为了满足 CDMA 1X业务发展的需要，综合帐务子系统只需做相应的改造， 功能结构，数据采集，二次
批价，帐务处理（累帐、出帐、调帐、销帐、反销帐），欠费数据生成，无主话单处理，稽核、统计、报表，帐单管理
功能结构
帐务功能（数据采集）
缴费功能（SP费用代收）
信用控制/防欺诈 参照综合营帐技术规范
省分结算功能：CDMA 1X结算包含语音结算和数据结算两部分。其中 CDMA 1X语音结算部分由现有综合结算子系
统的语音结算功能实现，不需新增或改造任何功能；对于数据结算部分，综合结算子系统目前暂不考虑内容话单结算，仅处理流量话单结算部分。
省分结算（功能结构）
总部结算功能
总部结算包含语音结算和数据结算两部分。其中 CDMA 1X语音结算部分由总部计费结算中心现有 CDMA结算系统的语音
结算功能实现，不需新增或改造任何功能；为了支持开展 CDMA 1X数据业务，需要新增 CDMA 1X数据业务结算功能。
CDMA 1X数据结算包含流量费结算与内容费结算两部分。由于支撑系统暂不进行内容费结算，所以对于总部 CDMA 1X
数据业务的结算功能，目前暂进行流量费的国际漫游结算与省际漫游结算。
总部结算（功能结构）
客服功能（功能结构）
数据采集
… …对帐处理
结算批价预处理
审核校验
CDMA专业计费子
系统生成文件
上传总部结算中心的省
际漫入文件、下发的省际
国际漫出文件、统计文件
业务处理
管理 接口管理 系统管理
数据
结算处理
查询统计
传至综合帐务子
系统的省际国际
漫出文件
客服功能（业务受理）
客服功能（投诉建议）
6、接口
接口定义方式：发起方系统，接收方系统，接口协议，接口方式，接口形式
支撑系统内部接口：综合帐务子系统与 CDMA专业计费子系统的流量详单接口；综合帐务子系统与省结算子系统的流量详单接口；综合营业子系统与 CDMA专业计费子系
统的联机工单接口；综合营业子系统与 165专业计费子系统的联机工单接口（待补充） ；客服子系统与综合营业子系统的业务受理与查询接口 ；综合结算子系统与 CDMA专
业计费子系统的流量详单接口 ；综合结算子系统与总部结算系统的接口 ；统一客户资料子系统与其余支撑子系统的接口 ；支撑系统的生产型子系统与统一经营信息服务子
系统的接口
支撑系统外部接口：CDMA专业计费子系统与 AAA系统的流量话单接口 ；CDMA专业计费子系统与 AAA系统的联机指令接口；CDMA专业计费子系统与 HLR的联机指令接口；
综合帐务子系统与增值业务 SP结算平台的内容详单接口 ；综合帐务子系统与增值业务 SP结算平台的日接收详单文件核对统计接口 ；综合帐务子系统与增值业务 SP结算平
台的内容帐单接口（可选）；综合帐务子系统与增值业务 SP结算平台的实收统计接口；综合营业子系统与增值业务接入管理平台的联机工单接口；综合营业子系统与增值业务
1001接入平台 业务受理模块 综合营帐系统
1、传送主叫信息
2、明确需要办理的业务
3、取用户密码请求
4、取到的用户密码
5、用户密码鉴权
6、提交受理信息
7、返回受理结果
用户拨打1001进入
到客服系统
SP结算平台的 SP基本信息获取接口
支撑系统外部接口（续）：综合营业子系统与增值业务 SP 结算平台的 SP 业务信息获取接口 ;综合营业子系统与增值业务 SP 结算平台的终端信息获取接口 ;综合营业
子系统与增值业务 SP 结算平台的编码信息获取接口 ;总部统一经营信息服务子系统与增值业务 SP 结算平台的 SP 结算统计接口（待补充） ;客服子系统与增值业务 SP 结算
平台的 SP投诉信息传送接口 ;总部结算与全国 AAA系统的流量话单接口
