何龙龙1,2，李 炜1,2
（1.北京邮电大学网络与交换技术国家重点实验室，北京 100876;
2.东信北邮信息技术有限公司，北京 100191）
摘要：EBAS（EBupt Application Server）是东信北邮下一代核心业务平台的重要组成部分，用于快速构建与部署电信增值业务的平台。OAM（Operation，Administration and Maintenance）对EBAS运行时的管理和维护提供支持。针对OAM目前基于协议适配架构存在难以扩展及维护等问题，提出了相应的解决方案，并给出了基于REST的资源架构模型和统一接口的通用OAM的具体设计与实现。
关键字：应用服务器；操作管理平台；REST；资源模型；统一接口
Design and Implementation of OAM Based on REST
He Longlong1,2, Li Wei1,2
(1.State Key Lab of Networking and Switching Technology, Beijing University of Posts and Telecommunications, 100876;2.EBUPT Information Technology Co.,Ltd., 100191)
【Abstract】 EBAS(EBupt Application Server), one of the most important component of next generation of core business platform in EBUPT Information Technology Co.,Ltd., is the platform used for rapid development and deployment of telecom value-added service. OAM(Operation, Administration and Maintenance) supports the management and maintenance of the EBAS-Runtime. At present it is complex to extend and maintain the OAM which based on protocol adapter architecture. In order to address the issue, a general OAM based on REST, which include resource architecture and unified interface, is put forwad, also the specific design and implementation is given.
【Key words:】application server; OAM; REST; resource architecture; unified interface
中图分类号：T 文献标识码：A 文章编号：1006-0707 (2011) xx-xxxx-x
EBAS（EBupt Application Server，东信北邮应用服务器）[1]是用于快速构建与部署电信增值业务的平台[2]。EBAS这种电信级产品需要提供7*24小时实时系统监控、维护的功能，在系统不宕机的前提下，能够进行系统、业务级别的管理和维护，即OAM(Operation，Administration and Maintenance)。现状况是对于不同的监控对象，如（主机信息、日志、告警、用户管理等），基于不同的协议适配模块有不同的管理接口，例如通过HTTP适配器监控主机信息，而通过RMI适配器监控日志等，不同协议的适配器降低了OAM自身的可维护性及可扩展性等，同时降低了OAM的易用性，加大了OAM监控人员学习成本，因此需要设计面向监控人员的统一管理接口。
1 当前OAM的部署结构
OAM是支持包括Web，Console，GUI等多种接入方式的操作管理平台，每一种方式都对应一个协议适配器，部署方式如图1所示。
图1 OAM当前的部署方式
ASI（AS Instance）是EBAS的一个实例，需要支持不同的管理接入方式（Web、Console等），对应不同的接入方式与监控对象，需要不同的协议适配模块。
由于ASI数量的不同，每个协议适配模块需要维护自身的ASI连接，因此存在大量的可复用代码，增加了OAM自身的复杂度的同时，降低了OAM的可扩展性与可维护性。
由于多种协议适配模块没有统一的接入接口，OAM需要对各个协议的消息分别解析，每增加一种协议，就需要增加一个对应的协议适配模块，降低了系统的灵活性和可维护性。同时也无法应用统一的负载均衡和流量控制等算法，必须对每个协议模块单独实现。
2 改进的方案设计
为构建更合理的OAM，将从以下方面进行改进：
2.1 提供统一的接入接口
为支持不同的管理接入方式(Web、Console等)，降低OAM接入系统的复杂度，同时最大程度上的复用代码。每种接入方式互不相干，任意增添或删减接入方式，对其它接入方式没有影响。
2.2 资源建模监控对象
从资源的角度，对监控对象进行建模，增强OAM的可扩展性与可维护性。
2.3 使用标准方法操作资源
在资源建模之后，使用标准方法操作资源，增强OAM系统的易用性，降低OAM使用人员的学习成本。图2是改进后的方案总体结构图：
图2 改进后的OAM部署方式
3 改进的OAM的设计
3.1 REST
REST(Representational State Transfer)软件架构是由Roy Thomas Fielding博士[3]在2000年首次提出的。REST软件架构是一个抽象的概念，是一种为了实现这一互联网的超媒体分布式系统的行动指南[4]。以下是构建REST架构的五条关键原则[5]：
1) 为所有“资源”定义ID
2) 将所有事物链接在一起
3) 使用标准方法
4) 资源多重表述
5) 无状态通信
由于REST架构风格提供了统一的管理接口，并且天生拥有易用性及良好的可扩展性，因此本文将基于REST改进OAM系统。
3.2 资源模型的设计
从REST的介绍可以看出，REST是基于资源架构的一种软件架构风格，操作的所有事物都抽象成资源，并且为每个资源定义一个URI。按照以下步骤设计资源模型[6]，为简化讨论且能说明问题，在此将OAM的监控对象设定为主机信息(Host)、日志(Log)、告警(Alarm)、用户管理(User)，主机信息包括主机名与磁盘利用率，其它监控对象具体信息不赘述。
1) 规划数据集
OAM的监控对象包括ASI的主机信息(Host)、日志(Log)、告警(Alarm)、用户管理(User)等，
2) 将数据集划分为资源
根据OAM的管理特点，将OAM的资源分别表示如下
a) OAM自身
b) OAM的监管对象列表
c) OAM监管对象的新建
d) OAM的具体监管对象
e) 主机信息的监管对象列表
f) 主机信息监管对象的新建
g) 主机信息的具体监管对象
日志、告警、用户管理等资源建模方式同主机信息。
3) 用URI为资源命名
a) OAM自身
/oam
b) OAM的监管列表
/oam/all
c) OAM监管对象的新建
/oam/new
d) OAM的具体监管对象
/oam/{XManager}
{XManager}中表示OAM具体的监控对象，如主机信息为/oam/hostManager。
e) 主机信息的监管对象列表
/oam/hostManager/all
f) 主机信息监管对象的新建
/oam/hostManager/new
g) 主机信息的具体监管对象
/oam/hostNamager/{info}
{info}表示主机的具体参数，如：
主机名为/oam/hostManager/hostname，
主机磁盘利用率为/oam/hostManager/diskusage。
4) 设计资源表述格式
使用XML格式表示资源内容。
5) 用超链接将资源连接起来
以树型结构组织资源，如图3所示：
图3 OAM的树型资源结构图
根节点只有子节点的链接，叶子结点只有父节点的链接，其它结点都有子结点与父节点的链接，树型链接方式可以保证所有资源的连通性。
3.3 统一接口的设计
RESTful架构风格基于HTTP协议，基本统一接口包括POST、PUT、GET、DELETE，因此为每个资源暴露一个统一接口的子集
1) /oam
GET
获取OAM的具体信息
2) /oam/all
GET
获取OAM监控对象列表
3) /oam/new
POST
创建新的OAM监控对象
4) /oam/{XManager}
GET
查看OAM的具体监控对象
DELETE
删除OAM的具体监控对象
5) /oam/hostManager/all
GET
获取主机的监控列表
6) /oam/hostManager/new
POST
创建新的主机监控对象
7) /oam/hostManager/hostname
GET
获取主机名
DELETE
删除主机对主机名的监控
8) /oam/hostManager/diskusage
GET
获取主机的磁盘使用信息
DELETE
删除主机对磁盘使用率的监控
使用资源建模与统一接口重构OAM之后，OAM提供了统一的接入口(/oam)，不同的接入方式(Web、Console等)之间互不干扰，可以根据需要任意扩展接入方式，与此同时，树型的资源组织结构与超链接模式，保证了所有资源的连通性。OAM监管的不同对象，可以很好的以资源的视点被添加到资源模型中，不会对现有模型产生影响。使得OAM的可扩展性、可维护性、健壮性等方面都有所加强。
由于对资源统一接口的设计，可以保证OAM良好的易用性，大幅度的降低OAM监控人员的学习成本。
4 改进的OAM实现
实现OAM的核心类包括：
4.1 ResourceFactory类图
OAM的资源管理工厂，方法及其返回值如图4所示，含义如下：
1) entry()
可以获取OAM的唯一入口的资源。
2) register(Resource resource)
在资源管理工厂注册资源。
3) unregister(Resource resource)
在资源管理工厂注销资源。
4) getResource（URL url）
获取对应url的资源。
图4 ResourceFactory类图
4.2 Resource类图，抽象类
OAM资源模型的核心概念：资源。方法及其返回值如图5所示，含义如下：
1) Resource（URL url）
以url为参数，构造一个资源，资源与url对应。
2) doHandle(Method method, Representation representation)
处理标准接口的特定方法与表述。
图5 Resource类图
4.3 Representation类图
表述可以有许多种方式，toXML()是用XML表述，之后可以添加其它形式的表述，如toString()、toHTML()等。方法及其返回值如图6所示，含义如下：
toXML()
以XML表述资源。
图6 Representation类图
5 结束语
为解决OAM的部署结构存在的一系列问题，以改进和完善OAM的功能和架构，提供更具灵活性和扩展性的支持，针对目前存在的问题进行分析研究，并提出了一个基于REST的解决方案，并以OAM对主机名与磁盘信息的管理为例，根据REST的最佳实践，逐步完成了OAM的实现，不仅解决了系统原有问题，还提供了更为清晰灵活的系统接口，方便今后不同接入方式的扩展和整个OAM各个资源的整合，同时也有利于后期的维护和升级。资源模型与统一接口的引入，还大大降低了OAM使用人员的学习成本。
搜索
关注微信
