Presence服务中资源列表业务模型的设计与实现

2010年第19卷第9期计算机系统应用SystemConstruction系统建设25Presence服务中资源列表业务模型的设计与实现①范绪波1,2雷为民2王宁2张伟2,3李俊超2,3(1.中国科学院研究生院北京100049；2.中国科学院沈阳计算技术研究所辽宁沈阳110171;3.中国科学技术大学计算机科学与技术系安徽合肥230027)摘要：随着终端个数的增多，呈现(Presence)服务中的点对点订阅会引起数据量偏大、终端频繁订阅等诸多问题。资源列表服务通过订阅列表的方式很好的解决了这个问题。在参考SIMPLE标准的基础上提出一种资源列表业务模型实现框架，详细讨论了列表订阅机制及其设计原理，设计并实现了一种资源列表服务器(RLS)。经过测试，该服务器能正确完成列表订阅，性能良好，很好地解决了终端频繁订阅的问题。关键词：资源列表;呈现服务;资源列表服务器;SIMPLEDesignandImplementationofResourceListServiceModelinPresenceServiceFANXu-Bo1,2,LEIWei-Min2,WANGNing2,ZHANGWei2,3,LIJun-Chao2,3(1.GraduateUniversityofChineseAcademyofSciences,Beijing100049,China;2.ShenyangInstituteofComputingTechnology,ChineseAcademyofSciences,Shenyang110171,China;3.DepartmentofComputerScienceandTechnology,UniversityofScienceandTechnologyofChina,Hefei230027,China)Abstract:Withanincreasingnumberoffriends,PeertoPeersubscriptioninPresencecausesagreatdataflowandmanyotherissues.TheResourceListServiceisaverygoodapproachtosolvethisproblembysubscribingtothelist.ThispaperproposesaframeworkfortheimplementationofResourceListServiceModelwhichreferstoSIMPLEstandards.Basedonthis,theRLSaswellasitsdescriptionsaredesigned.UpontestingtheRLSinWAN,theexperimentalresultsshowthatRLScancorrectlycompletethesubscriptionsofalistandprovideanexcellentsolutionforthefrequentsubscriptionissues.Keywords：resourcelist;presenceservice;resourcelistserver(RLS);SIMPLE1引言Presence即呈现业务，用以传达用户通过一组设备进行通信的能力和意愿，例如：在线、工作中、显示为脱机等。目前Presence作为一种引擎业务，可以很方便的为其它业务平台提供业务能力，如即时消息业务平台、一键通、富通信套件(RCS)[1]等。在Presence原有的点对点订阅方法中，用户上①收稿时间:2010-01-03;收到修改稿时间:2010-02-01线时会向Presence服务器订阅他全部好友的Presence状态，该用户有多少好友就需要单独发送多少个SUBSCRIBE[2]请求，当好友较多时会导致SUBSCRIBE信令数量迅速增加，NOTIFY[2]消息随之也会剧增，从而影响服务器性能，在带宽有限环境下，如无线网络中甚至会导致网络拥塞等问题。为了解决上述问题，优化Presence服务性能，IETFSIMPLE计算机系统应用2010年第19卷第9期26系统建设SystemConstruction工作组在RFC4662[3]中提出了资源列表订阅这一概念，这样订阅的时候只需要订阅好友列表对应的URI，Presence服务器会返回所有好友的状态信息，不必一个个好友单独订阅，节省了网络带宽资源（这对移动通信比较现实），也易于管理。本文给出了一种Presence服务中资源列表业务模型的实现方案。在Presence原有的软硬件平台基础上，添加了一个资源列表服务器(RLS)。文章对比介绍了两种Presence业务模型，详细描述了资源列表业务模型设计原理以及资源列表服务器的设计和实现，昀后给出了测试结果。2Presence业务模型2.1Presence点对点业务模型Presence点对点业务主要涉及三个逻辑实体：信息提供者(Presentity)、Presence服务器、信息请求者(Watcher)，业务模型如图1所示。图1Presence点对点业务模型SIMPLE标准遵从RFC2778[4]和RFC2779[5]定义的Presence服务模型[6]，同时扩展了PUBLISH[7]、SUBSCRIBE、NOTIFY三个SIP信令，用以支持这一服务模型。Presence业务被具体分解为几个步骤：订阅、发布和通知。一个昀简单的点对点业务过程如下：一个用户(Watcher)发送SUBSCRIBE请求订阅他感兴趣的其他用户(Presentity)的Presence信息，被订阅的用户接收订阅请求，之后每当被订阅用户的信息发生变化，他的终端将会通过PUBLISH消息发布自己的新状态到Presence服务器，这个新状态随后会通过NOTIFY消息通知给订阅者。WatcherPresenceServerAPresenceServerB200OKNOTIFYacceptSUBSCRIBE200OK200OKSUBSCRIBE200OKNOTIFYaccept图2Presence点对点订阅信令流程用户有多少好友就需要发送多少个SUBSCRIBE请求到好友所在的presence服务器，如图2所示，Watcher有两个好友，分别位于Presence服务器A和B，则Watcher必须向这两个服务器分别发出好友状态订阅。2.2Presence资源列表业务模型在实现了资源列表服务后，Presence系统结构如图3：图3Presence资源列表业务模型不管用户有多少好友，终端只需要发一个SUBSCRIBE请求到资源列表服务器，订阅自己的资源列表，由RLS服务器代替客户端进行全部好友的订阅，RLS服务器将收到的所有NOTIFY消息进行整合，发送一个复合格式的NOTIFY消息到终端，完成订阅。如图4所示，Watcher有两个好友，分别位于Presence服务器A和B，则Watcher只须向RLS服务器发出一个资源列表订阅，然后等待RLS服务器返回的复合NOTIFY消息即可。终端ResourceListServerPresenceServerASUBSCRIBE200OKNOTIFY200OKSUBSCRIBE200OKNOTIFY200OKSUBSCRIBE200OKNOTIFY200OKPresenceServerBNOTIFY200OK图4Presence资源列表订阅信令流程3Presence资源列表业务模型的设计原理为了实现资源列表订阅，首先要能够区分资源列表订阅和点对点订阅，其次要定义一种资源列表的描述方式，并能够对资源列表进行管理配置，昀后还要整合多个资源的状态到一个NOTIFY消息中。下面就这几个问题对资源列表业务进行详细介绍。3.1资源列表业务的协商为了实现资源列表订阅，RFC4662通过扩展RFC3625[2]中的SIPOptiontag机制来支持列表订阅2010年第19卷第9期计算机系统应用SystemConstruction系统建设27协商。支持资源列表订阅的客户端需要在SUBSCRIBE消息的Supported头域中包含“eventlist”，并在Accept头字段中指明multipart/related、applica-tion/rlmi+xml和pidf+xml三种格式，以示客户端可以解析这些格式的通知消息；RLS服务器则需要在NOTIFY消息的Require头域里包含“eventlist”。资源列表订阅和点对点订阅便区别开来。3.2资源列表配置管理资源列表服务中使用基于XCAP[8]的配置管理方式。XCAP是一种用以存取用户设置的通信协议，用户可以将特定的配置资料用XML的形式存储在服务器上，并允许客户端以GET、PUT、DELETE等方法读取、写入、修改、建立和删除数据。在资源列表业务中，用户首先会通过XCAP操作上传自己的XML配置文档到XCAP服务器，这些配置资料，包括资源列表、好友列表以及授权规则文档等。3.3资源列表描述文档RFC4826[9]定义了资源列表文档的格式，并且扩展了两个XCAP应用：“resource-lists”、“rls-services”来支持资源列表业务，以便终端可以使用XCAP服务器来管理相关配置文档。一是RLSServices文档，一是Resource-lists文档。前者定义了资源列表服务器上一系列可用服务以及订阅这些服务的URI；后者是资源列表的具体内容。前者将引用后者的内容。3.4资源列表状态消息格式为了构造包含多个资源状态的NOTIFY消息体，RFC4662扩展了RFC2387定义的“multipart/related”类型参数，定义了multipart/related;type=application/rlmi+xml类型，来描述包含多个资源状态的NOTIFY消息体格式。客户端订阅列表时，必须在SUBSCRIBE消息中声明对这两种类型的支持。RFC4662定义的NOTIFY消息体分为两部分：RLMI文档和多个PIDF格式的单资源状态文档。其中的RLMI文档描述了该消息体所包含资源的“meta-information”状态，包括授权状态；单资源状态文档描述了列表中具体资源的呈现状态。4Presence资源列表业务模型的设计与实现4.1资源列表业务模型实现框架从图5可知这一框架由RLS服务器，Presence服务器，XCAP服务器，信息提供者(Presentity)、信息请求者(Watcher)五部分组成；其中各个部分作用如下：图5资源列表业务模型实现框架(1)信息请求者(Watcher)：登录时保存自己的RLSServices文档和Resource-lists文档到XCAP服务器，当想要获取好友状态时，发送SUBSCRIBE请求到RLS服务器订阅自己的资源列表，并对RLS服务器返回的整合消息进行解析，获取好友的状态。(2)RLS服务器：接收来自终端的列表订阅，通过资源列表文档获取相关资源集合，代替终端发起对资源集合的虚拟订阅，整合所有资源的呈现状态后，返回给信息订阅者。(3)Presence服务器：主要处理两种请求，一是信息提供者发布的PUBLISH，一是RLS发送的SUBSCRIBE请求。(4)XCAP服务器：主要负责保存RLSServices文档、Resource-lists文档以及授权规则文档。(5)信息提供者(Presentity)：状态变化时将自己的状态PUBLISH到Presence服务器，并将授权规则文档上传到XCAP服务器，当信息请求者订阅自己时进行相关授权。4.2资源列表订阅流程资源列表订阅处理过程需要与XCAP服务器配合，由图6知，资源列表订阅由以下几个步骤构成：(1)终端登录时保存自己的Resource-lists文档和资源列表文档到XCAP服务器。(2)终端向RLS订阅他的一个资源列表服务，并且在SUBSCRIBE消息的Support头域中包含“eventlist”。(3)RLS接收到用户的列表订阅请求时