电信能力开放平台中鉴权框架的设计与实现_侯祎寒.docx

《电信能力开放平台中鉴权框架的设计与实现_侯祎寒.docx》由会员分享，可在线阅读，更多相关《电信能力开放平台中鉴权框架的设计与实现_侯祎寒.docx（77页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 独创性（或创新性）声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不 包含其他人 已经发表或撰写过的研宄成果，也不包含为获得北京邮电大学或其他 教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研宄所做的任 何贡献均已在论文中作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定，艮 P: 研宄生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保 留并向国家有关部门或机构送交论文的复印件和

2、磁盘，允许学位论文被查阅和借 阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、 缩印或其它 复制手段保存、汇编学位论文。（保密的学位论文在解密后遵守此规定 ） 保密论文注释：本学位论文属于保密在 _年解密后适用本授权书 9非保密论 文注释：本学位论文不属于保密范围，适用本授权书。 本人签名 : 日期： n/ )- 关于论文使用授权的说明 日期 : 列又 i卜 日期： ). 11 电信能力开放平台中鉴权框架的设计与实现 摘要 随着移动互联网的发展，网络真正成为了以人为中心的平台。互 联网公司打破了传统被动获取信息的方式，以开放的思想将核心能力 提供给外部开发者，构建丰富的应用提供给用

3、户。为了应对互联网公 司的竞争以及更好地利用传统通信域的优势，顺应用户日益个性化 的需求，传统电信运营商也将自己的电信能力开放以获取更多的合作 伙伴，创造丰富应用，从而打造平台生态圈。 电信能力开放平台作为一个关系型的平台，需要统一的鉴权认证 确保关系一致性管理以及开放接口的安全性。然而，鉴权认证的业务 流程复杂、涉及角色众多，导致实际开发过程中灵活 性受限，开发和 维护成本增高。由此，本文设计实现了电信能力开放平台中的通用的 鉴权框架，对外部应用发起的请求进行操作权限、角色认定、资源使 用等鉴权认证和合理计费，并与外部系统配合完成数据的同步管理。 该框架采用面向服务的分层设计理念，参考 Du

4、bbo分布式服务框 架，提高业务的复用度和可扩展度。在实现方面遵循面向对象的设计 原则，采用灵活的应用设计模式，实现 Java代码的编写工程化，改 善了代码的重用性和扩展性。本文设计开发的鉴权框架己应用于中国 移动 OMP (Open Mobile Platform， 开放 移动平台 ） 项目和 HDC ( Home DataCenter， 家庭数据中心 ） 项目中，功能测试表明框架具有可用性， 利用性能测试工具 Apache Benchmark在不同并发量和请求量下进行 测试，验证了框架的稳定性。 关键字 ：分布式服务框架鉴权认证能力开放平台 Dubbo DESIGN AND IMPLEME

5、NTION OF AUTHENTICATION FRAMEWORK ON OPEN PLATFORM OF TELECOMMUNICATION CAPABILITIES ABSTRACT With the development of mobile Internet, the network truly becomes a platform for humman-centered. Internet companies have broken the passive way to get information in traditional Internet era, instead, the

6、y open up their core ability for external developers to build rich applications to meet users5 demand. In order to cope with the competition and take better advantages of traditional telecommunications to adapt to users, requirement, traditional telecom operators also open their telecommunications c

7、apabilities to get more partners to create rich applications. By this way a platform ecosystem is created. The open platform of telecommunications capabilities is a relational platform, and it requires a unified authentication to ensure consistency of relationships and security. However, the authent

8、ication process is complex and involves numerous roles, leading to limited flexibility and increased costs of development and maintenance in the actual development process. Therefore, this thesis designs and implements a general authentication framework for the open platform of telecommunication cap

9、abilities, which accomplishes authentication and certificatidistributed service framework, to improve reusability and scalability of the business. Besides, the completion follows the Object Oriented design principles, and applys flexible design mode to ensure engineering Java coding as well as impro

10、ve the code reusability and scalability. At last, the authentication framework is applied to projects of OMP (Open Mobile Platform) and the HDC (Home Data Center), the availability is proved through functional testing. Performance testing results are made by testing tool Apache Benchmark in differen

11、t amount of concurrent which proves that the framework is a stable framework. KEY WORDS: distributed service framework, aut ntication, open platform of telecommunication capabilities, Dubbo 目录 第一章 . 1 l.i“ 研究背景及意义 . 1 1.2. . 主要创新工作 2 1.3“ 攸结构 . 3 第二章相关技术研究 . 5 2.1. 分布式服务框架 Dubbo . 5 2.1.1. 应用程序架构的发展

12、 . 5 2.1.2. 分布式服务架构 Dubbo . 6 2.2. 面向服务体系结构 SOA . 7 2.3. Spring 框架 . 8 2.4. 开放平台安全机制 . 9 第三章需求分析与总体设计 . 10 3.1. . 需求分析 10 3.1.1系统的组成元素 . 10 3.1.2系统的功能分析 . 11 3.2“ 设计思想 . 13 3.3 “ 部署结构 . 13 3.4. 框架设计 . 14 3.5“ 工作流程 . 17 3.6.数据结构设计 . 17 3.6.1数据库实例 -关系图 . 17 3.6.2关键数据表说明 . 19 第四章详细设计与实现 . 26 4.1 模块的划分

13、. 26 4.2业务管理模块 . 27 4.2.1使用鉴权模块 . 27 (1) .信 息 同 步 模 块. 31 4.2.2订购管理模块 . 33 4.3 集成服务模块 . 37 4.4基础服务模块 . 39 第五章系统的部署与测试 . 40 5.1 系统的部署 . 40 5.1.1 硬件环境 . 40 5.1.2软件环境 . 40 5.1.3 软件配置说明 . .41 5.2系统功能测试 . 43 5.2.1管理子系统 -鉴权子系统接口 . 43 5.2.2接入子系统 -鉴权子系统接口 . 45 5.3 . 系统性能测试 48 5.3.1测试案例 . 48 5.3.2测试结果对比分析 .

14、56 5.4测试总结 . 57 第六章总结与展望 . 58 6.1 总结 . 58 6.2 未来工作 . 58 参考文献 . 60 m . 62 附录 1 UsingAuth源码示例 . 63 附录 2 application.xml部分配置示例 . 67 攻读学位期间发表的学术论文 . 69 第 一 章 绪 论 1.1. 研究背景及意义 Web 2.0时代提出以人为互联网中心，网络成了新的平台，传统互联网用户 被动获取信息的模式被打破 1。电信运营商也逐步开放自己的电信能力供外部开 发者使用，但是能力网关的开放形式不利于中小企业的应用集成，准入门槛高且 集成周期长，为了更好地适用于互联网时代

15、的快速迭代开发，电信运营商推出了 能力开放平台。 移动互联网的飞速发展加速推动了互联网与传统通信领域的融合，无论是互 联网企业还是通信运营商，都选择通过能力开放平台汇聚合作伙伴，以平台生态 圈的形式共赢发展 2，中国移动就尝试推出自己的能力开放平台来迎合移动互联 网时代的需求。 OMP (Open mobile platform， 能力开放平台 ） 是一个开放电信能力供外部开 发者构建应用，同时管理运营应用和能力的访问过程的平台系统。此系统通过屏 蔽低层网络的复杂性、统一电信能力网关的调用接口，来提供第三方应用的开发、 管理和计费服务 1。随着电信能力的开放，以及电信网、广播电视网和互联网的

16、三网融合的发展，开放平台也不仅仅只为单个用户服务，走向了家庭信息化的方 向，为家庭用户提供融合、无缝的通信服务及综合的信息化服务。 HDC(Home Data Cente， 家庭信息开放平台）是传统的电信能力幵放平台的扩展，深入到家庭 领域 提供集多媒体娱乐、水电计费、设备管理等多方位的服务。随着信息的进一步开 放，平台的鉴权及安全问题就显得尤为重要，亟需一个统一认证中心来确保平台 的安全性，从而促使平台良性发展。 能力开放平台定位为移动通信网络侧的中间件产品，其核心构件就是能力开 放引擎，包括接入子系统、鉴权子系统、管理子系统三个部分。其中鉴权子系统 的功能是对外部应用发起的调用请求完成对操

17、作权限、操作中涉及的各方角色、 资源进行基于安全基础的鉴权认证过程、以及基于鉴权合法基础上的计费过程； 同时还需要与另外两个子系统配合完成数据的一致 性管理，从而保证能力开放的 安全性。 鉴权认证中心作为能力幵放平台的统一认证中心，由鉴权模块和安全模块组 成，其中鉴权模块的功能是完成对操作权限、操作中设计的各方角色、资源进行 基于安全基础的鉴权认证来却实现数据的一致性管理以及保证能力开放的安全 性 _。 鉴权认证过程涉及的角色众多，包括用户、开发者、应用、能力等 5，同时 流程复杂，其中有较多可以复用和整合的部分，例如注册认证、订购授权和使用 鉴权等不同的鉴权认证流程都有可复用的鉴权步骤。然而

18、随着电信能力开放平台 的不断发展和完善，原有单一垂直型的鉴权体系存在程序复用性差、可扩展性差、 程序高耦合等问题，导致幵发和维护成本增加，系统性能下降，无法满足业务扩 展的需求。例如，家庭信息开放平台无法在原有的能力开放平台的基础上复用和 扩展，一定程度上阻碍了开放平台鉴权业务的发展。上述问题具体分析如下： (1) 程序复用性差问题。鉴权的业务按功能模块划分，可以分为鉴权批价、 订购关系鉴权和安全认证，其中鉴权批价和订购关系鉴权有很多相同的步骤，这 就导致模块、代码 、函数等之间的依赖关系大，耦合度高，从而导致程序的复用 性差。解决此类问题一方面需要对系统进行全面的需求分析，规划好功能模块的

19、划分，降低功能模块的耦合度，另一方面还要在代码的级别解耦，减少依赖。 (2) 程序可扩展性查问题。可扩展性差主要体现在程序级别，原有的鉴权 框架多采用的是面向类的编程而非面向接口的编程，当需求发生变化时，原有程 序变动很大，不利于后期的维护，再加上耦合度高，依赖关系大，灵活性得不到 满足，可扩展性差。解决此类问题一方面需要增加高度可配置型，即通过参数化 配置程序或者 XML (Extensible Markup Language， 可扩展标记语言）配置文件 等来提高程序灵活性，另一方面需要在设计模式上，采用模块化、服务化的设计 理念，使用面向对象编程中的抽象化、封装、多态和 开 -闭 “ 原则

20、等来保证程序 的可扩展性。 (3) 系统性能差的问题。随着业务量的不断上升，系统性能不断下降，经 调研主要原因是数据访问频率高而访问效率低下，而随着程序的灵活性和可扩展 性的提高，系统的稳定性也受到影响。解决这个问题一方面需要考虑改善原有数 据库的设计，根据业务的需要进行分库分表，另一方面考虑数据缓存的技术，来 提高数 据存储效率。 因此，需要从角色角度和业务流程等角度综合考虑，调研应用程序的架构， 设计一套通用的鉴权体系结构，便于流程的统一管理，提高代码的复用性和可扩 展性，提升系统性能，更好地支撑未来更复杂的业务扩展需求。 1.2. 主要创新工作 本文致力于在电信能力开放平台下构建一套安全

21、可靠、可扩展性强、性能优 化的鉴权框架，并在此基础上编写代码来实现，搭建测试环境进行功能测试和性 能测试并总结测试结果，应用于现有的 OMP项目和 HDC项目。为了实现以上目 标，主要创新工作如下： (1) 立足于 OMP和 HDC两个项目，对能力开放平台鉴权系统的功能进行 全面的调研分析，包括涉及的角色、各角色的职责及它们之间的关系、操作流程 等，总结两个项目的功能异同点，提炼出重复性高的功能点以及需要高扩展性的 业务，同时归纳以往项目开发过程中的问题，提出一套电信能力开放平台下通用 的鉴权功能架构。 (2) 结合互联网框架设计技术与电信能力开放平台的业务需求，充分考虑 能力开放平台上所涉及

22、的互联网技术、应用程序架构、安全机制等，采用分布式 服务框架 Dubbo实现鉴权系统的框架结构，具备高度的可操性。以高可复用、 高扩展、松耦合的设计思想，严格遵循 REST风格的 Web体系设计原则，包括 接口原则、分层系统原则和按需代码原则等 6m，确保系统实现与设计模型的一 致性，同时采用 Spring框架与Hibernate技术来实现高度可配置性，降低代码的 维护成本。 (3) 编写完善的测试用例，覆盖正常流程和异常流程确保了程序的健壮 性，性能测试进一步验证鉴权框架的稳定性和较高的处理能力。 综上所述，本文的创新性体现在对电信能力开放平台的鉴权框架的业务总 结、通用的系统设计和完善的测

23、试这几个方面，致力于实现一个可扩展性强、可 复用性强、性能稳定的鉴权框架。 1.3. 论文结构 本文包含六个章节，下面对每一个章节的具体工作做描述。 第一章介绍了论文的研宄背景和意义，明确了将要实现的内容和目标。 第二章对论文中可能涉及的相关技术进行了阐述，明确了其基本工作原理和 实现机制，包括 Dubbo开发框架、 SOA模型设计原则、 Spring开发框架、 Hibernate 数据持久化技术等。同时，分析了上述关键技术在实际项目开发过程中的具体应 用。 第三章是系统总体设计，介绍系统的需求分析，设计思想，以及在此基础上 的系统框架设计、部署结构、工作流程以及关键的数据结构。 第四章是系统

24、的具体实现，详细介绍了功能模块的划分，模块之间的通信和 联系，以及每一个模块的具体交互流程和 UML类图，尤其是关键模块的实现细 节。 第五章介绍系统的部署及测试，首先明确系统的运行环境和部署条件，然后 给出功能测试的测试用例，从正常流程和异常流程进行全面测试，证明系统的可 用性和健壮性。同时介绍性能测试情况，最后对整体测试情况进行 了总结。 第六章是总结与展望，对论文的全部工作进行了总结，同时介绍了下一步可 以完善的地方。 第二章相关技术研究 2.1. 分布式服务框架 Dubbo 2.1.1. 应用程序架构的发展 当前，垂直应用框架己经无法适用于大规模的应用程序，且随着应用程序规 模的继续扩

25、大，亟需一个统一管理的框架来确保应用程序架构适应性地发展 8。 分布式服务框架就顺应了当前的发展趋势，如图 2-1是应用程序框架发展的趋势。 图 2-1应用程序框架发展示意图 8 (1) 单一应用框架。在网站流量足够小的情况下，所有功能可以在一个应 用中实现，以减少部署成本。此时，数据访问框架能够简化增删改查工作量。 (2) 垂直应用框架。在访问量逐渐增大的情况下，对于单一应用程序可以 通过配备更多机器带来性能提升，但是其影响越来越小，需将应用拆分以便提升 访问效率。此时， Web框架能够分离前端与后端的开发，解决此问题。 (3) 分布式服务框架。在垂直应用越来越多的情况下，应用与应用之间不

26、可避免地有所交互，需对应用进行整合和抽象，将核心应用提炼出来作为独立服 务，形成服务中心，同时前端应用与核心应用分离开 来，以便更快响应需求的改 变。此时，分布式服务框架能够提高业务整合和程序的复用性。 (4) 流动计算框架。在应用更多的时候，系统会显现出小服务的资源浪费 等问题，需对服务进行有效的资源评估，同时増加一个调度中心根据实时访问的 数据情况管理内存和 CPU容量，从而提高资源的使用率。此时，资源调度和治 理中心能够有效提高机器利用率。 原有鉴权体系结构经历了单一应用和垂直应用架构的发展过程，首先是一个 应用内集合了大部分的功能且嵌入了大量与数据库交互的操作，而随着业务需求 的增加

27、，一 个应用己无法承担，于是拆分成了多个节点，例如呼叫节点和管理节 点等，以提升数据访问的效率。随后随着访问量的增加，这种架构也己经无法负 图 2-2服务分层糢型 8 前端 服务：直接面向最终用户，用户能够调用前端服务来完成某项功能。 它需要调用集成服务和核心服务来实现。 集成服务：执行原子的业务逻辑，以供前端服务所调用。它的实现需要 调用核心服务来组装完成。 核心服务：业务执行的最小单位，通过与数据库交互来完成数据读写和 存储等基本操作，屏蔽前端服务与数据库交互的复杂性，一定程度上减 “ 少数据存取的频繁操作。被集成服务和前端服务调用。 注册中心：完成对服务提供者发布的基本信息进行记录的工作

28、，包括服 务地址、版本、名称等。当服务请求者需要调用服务时，则可以通过基 本信息来查找和调用所需的服务。 调度和监控中心：记录服务的使用者、服务调度的次数和服务供应者等 信息。以便更加优化服务的拆分和组合 1使用鉴权管理：用户使用应用产品的鉴权认证过程。 订购管理：用户 开发者订购、退订、暂停、恢复订购关系的鉴权管理。 安全认证功能：包括伪码管理、 Token认证等。 信息同步功能：与管理、接入和 BOSS系统进行信息同步，保持信息一 致性。 (2) 集成服务层：完成原子级的业务逻辑。通过对系统功能的需求分析， 细粒度地进行功能划分，拆分成原子级的业务逻辑提高代码的复用性和可扩展 性，便于被业

29、务系统层的服务调用，主要通过调用基础服务层的操作来实现以下 业务逻辑： 黑白名单检查：检查用户、应用、能力等是否在黑白名单中，如果在黑 名单中则根据受限级别进行鉴权，如果在白名单中则不需要鉴权直接通 过。 用户侧订购关系检查：包括用户与应用产品的订购关系的状态、有效性 检查以及应用产品的状态和有效性检查。 能力侧订 购关系检查：包含开发者与能力产品订购关系、能力产品、能 力产品 -能力对应关系的状态和有效性检查。 应用侧有效性检查：包含应用、开发者、能力以及应用 -能力签约关系的 状态和有效性检查，完成应用侧使用鉴权流程。 话单生成：统计应用使用的用户信息、应用产品信息、使用时间、时长、 费用

30、等信息，作为使用的话单记录。 计费：根据计费策略对应用使用情况进行计费。 (3) 基础服务层：实现基础的数据信息处理。通过调用底层的数据持久化 服务，主要完成程序中重复性高的数据处理操作，为上层业务所调用。 应用侧信息管理：包含应用 -开发者 -能力以及应用 -能力签约关系的信息 管理，完成对应用、开发者、能力、应用 -能力的签约关系的存储查询等 操作。 用户侧订购关系管理 ： 包含应用产品、用户 -应用产品的订购关系的信息 管理。 能力侧订购关系管理：包含能力产品、开发者 -能力产品的订购关系的信 息管理。 黑白名单信息管理：包含对用户、应用设置的黑白名单信息管理。 (4) 数据持久化 ：

31、持久化 是指对象模型与存储模型的相互转换 ： 包含和 数据库的各种操作。持久化技术封装了数据访问的细节，主要具有以 +的优势： 减少访问数据库数据的次数，增加应用程序执行速度，改善性能； 代码重用性高，能够完成大部分数据库操作； 松散耦合，使持久化不依赖于底层数据库和上层业务逻辑实现，更换数 据库时只需要修改配置文件而不用修改代码。 3.5. 工作流程 根据系统的框架设计，将系统按层次进行代码框架的搭建以及工作流程的梳 理，如图 3-6所示： 图 3-6鉴权框架工作流程 webapp模块对应于业务系统层。鉴权框架实现了对接入子系统和管理子系 统的基于 REST接口的 web服务，发布 web服

32、务的 URL供外部系统调用。 message 是消息适配模块。编写请求 /响应消息的 XSD文件，并使用命令自动生成消息代 码，作为入参和返回参数被 webapp调用。 service是具体的业务逻辑实现，对应 分层服务化结构的业务系统层。 saac_basic_service对应集成服务层。原子业务逻 辑，被 service调用。 saac_data_service对应于基础服务层，实现数据存储等操作。 上述模块的工作流程如下： (1) 外部系统通过 REST接口调用鉴权系统的服务，鉴权系统对请求消息 进行参数校验等操作； (2) 参数校验成功，则根据业务系统层的业务逻辑顺序调用集成服务层的

33、 原子逻辑，返回处理结果；参数校验失败，则返回失败的响应消息； (3) 集成服务层调用基础数据层的数据操作来实现原子逻辑，返回数据处 理结果； - (4) 业务系统层接收到最终处理结果 ,并通过 REST接口返回给外部接口。 3.6. 数据结构设计 3.6.1数据库实例 -关系图 鉴于开放平台是一个关系型平台，将平台中的角色和资源的关系用数据库实 例 -关系图表本，如图 3-7所不： 图 3-7数据库实例 -关系图 该实例 -关系图中的数据表以及它们之间的关系如下： (1 App： 应用信息表。记录平台中应用的详细信息，其中外键 devld与 Dev表的 Id关联，表示应用的开发者 ID， 与

34、开发者 Dev是一对一的关系。 (2) Dev:开发者信息表。 (3) AppProduct:应用产品信息表。应用产品是组合一个或多个应用并引 入计费方式而产生的可被用户订购和使用的产品。 (4) APPApppRelation:应用 -应用产品关系表。其中 id是数据库自动记录 生成的 id,应用和应用产品是多对多的关系，即一个应用可以有零个或多个应用 产品，一个应用产品由至少一个应用组成。 (5) User:用户信息表。存储用户的基本信息。 (6) UserApppOrder:用户 -应用产品订购关系表。记录用户订购关系的详 细信息，其中外键 userid关联 User用户表的主键 Id，

35、 外键 apppid关联 APPProduct 表的主键 Id。 (7) AppEaRelation:应用 -能 力签约关系表。记录应用和能力的签约关系， 应用只有在与至少一个电信能力签约之后才能使用能力，应用与能力的对应关系 是多对多，即一个能力可以与零个或多个应用签约。 (8) Ea:能力信息表。记录电信能力的详细信息。 (9) Eap“ 能力产品信息表。能力产品是指组合一个或多个能力并引入计 费方式而产生的可以被开发者订购和使用的产品。 (10) Ea-EapRelation:能力 -能力产品关系表。能力与能力产品是多对多的 关系，即一个能力可以被零个或多个能力产品使用，一个能力产品可以

36、包含一个 或多个能力。 (11) DevEapOrder:开发者 -能力产品订购关系表。开发者只有在订购了 至少一个能力产品后，才能够使用电信能力来开发应用。 3.6.2关键数据表说明 根据以上的数据库实例 -关系图，平台中最集中的资源是应用和能力，最核 心的角色是用户、开发者，最重要的关系是用户订购关系，在本小节中，将对这 五张表的表结构进行详细地说明。 (1) 应 用 信 息 表 如表 3-1所示，该表存储的是应用信息，应用自身的基本信息如 id、 description 等字段， status字段表示应用当前的状态，用于对应用的访问权限进行鉴权 ，devld 字段表示应用的开发者信息，将

37、应用和开发者的关系关联了起来， createtime、 cityld等记录应用的详细信息，与外部管理子系统、接入子系统进行信息的同步， 保持数据一致性。 表 3-1应用信息表 (续上表） 處喔麵議 墓 lype Length;NULL llkunimition 7 devid number : p)： yes: 应用开发者 id 8 ?tbappcatcgo _露纖擊 _麗嗎觀纖 _靡猶 ry丨 d number 10 应用类型 id / _ . . . . 9descriptionyarchar2 :腦 4 应用说明 : - 10 createtime timcstam P . 6 . .

38、乂 - . V.:. nu 应用创建时间 _ ； V . . . 11 onlinetime timestam P 6 ： , . yes 应兩上 线时间 . . . . . . . : . 12 stbapplevelnumber 1 no 应用级别： 0:全国 1:省级 2:地市 13 provinceidnumber 10 yes 省唯 一 标识 14 cityid number 10 yes 地市唯一标识 15 isUninstalla ble number 2 yes 应用是否可卸载，对预装应用 有效 0:不可卸载 1:可卸载 16 issopenablervarchar2 1 ye

39、s 是 否 为 自 有 能 力 1:自 有 能 力 0 :非自由能力 ， (2) 能 力 信 息 表 如表 3-2所示，存储的是能力信息，能力根据创建者的不同分为自有能力和 非自有能力，由 issopenabler字段标识，不同能力的访问控制权限不同，鉴权认 证的流程也不同。 epld字段表示能力提供者 ID， 须关联开发者信息表对其状态 进行合法性校验。 能力类型 appType字段须与管理子系统、接入子系统保持一致。 表 3-2能力信息表 Object enablers Purpose 能力信息 Primary； Key ID ，基 . :v Foreign key Index No At

40、tribute Illumination Name Type LengthNULL 1. id number10 no 能力数据库标识 2. eacode varchar2 12 no 能力标识 3. descinfo varchar2 1024 yes 描述信息 4. eaname varchar2 120 no 能力名称 5. eastatus number 1 no 能力状态 0:正常 1:待审核 2:预注销 3:待审核 4:注销 5:拒绝添加 6:未提交 6. eatype number 1 no 能力类型： 1、电信能力 2、 支付能力： 3、定位能力 7. applytype nu

41、mber 2 no 申请类型 ： 0:默认是没有申 请、1:创建、 2:暂停、 3:注 销、 4:修改 8. createtime timesta mp 6 no 能力创建时间 10 epid number 10 no 能力提供者标识 11 epcode varchar2 16 yes 开发者标识 12 epname varchar2 120 开发者名称 13 issopenabler varchar2 1 yes 是否为自有能力 1:自有能 力 0 :非 自 由 能 力 (3) 用 户 信 息 表 如表 3-3所示，该表存储的是用户的信息，基本信息包括用户名、密码等内容。 表 3-3用户信息表 Object T n userlnioPurpose 用户信息 Primary Key . . . .； . . . . . . .：二 .： .