CN102202102A - 基于云计算架构的网络服务聚合系统及其聚合方法 - Google Patents

Abstract

本发明揭示了一种基于云计算架构的网络服务聚合系统及其聚合方法，所述系统包括客户端、Web接口服务器、任务调度服务器、消息处理服务器、数据库服务器。Web接口服务器用以给客户端提供信息，并且处理和消息无关的数据。任务调度服务器负责监视消息处理服务器的资源消耗状态，并在Web接口服务器为登入用户索取相对空闲的消息处理服务器地址时返回，让Web接口服务器自行调用。消息处理服务器通过Web接口服务器与客户端连接，用户的网络服务在消息处理服务器进行登入、登出、状态管理、消息收发处理。本发明可支持各类网络服务，让处于不同平台的各个用户进行无障碍交流的环境。

Description

基于云计算架构的网络服务聚合系统及其聚合方法

技术领域

本发明属于网络通讯技术领域，涉及一种网络通讯系统，尤其涉及一种基于云计算架构的网络服务聚合系统；同时，本发明还涉及上述基于云计算架构的网络服务聚合系统的聚合方法。

背景技术

自上个世纪逐渐流行起电子邮箱和即时聊天工具后，当今已经涌现出多种新兴的网络服务，如：IM、微博、SNS和论坛等等。人们为了交流与联系，有时需要同时安装这些软件并涉足多个类型网络服务，而一个联系人又可能有多种联系方式，人们总希望使用最为便捷的方法联系对方。

比如：甲通常用QQ与好友交流，乙是他刚结识朋友，而乙习惯用MSN与人网上通讯，为和乙保持联系，甲得注册一个MSN，但是额外的注册就意味着需要下载额外的软件并且消耗额外的资源来维护MSN的运行。用户也时常会为了登入和切换服务而耗费大量时间，而管理自己的网络账户和联系人也成了麻烦的事情。

当我们各自使用着不同的通信软件，却因为需要互相交流，而不得不再去下载各种其他软件，让一台电脑运行着好几种通信软件，这时我们迫切需要一个平台：它能将所有通信软件整合——只是将它们彼此良性地聚合，而不会阻碍各自的发展。现代人十分需要一个能支持所有网络服务的无缝交流平台。

对此，目前互联网有了一些服务，但仅仅是聚合了特定类型的网络服务。比如eBuddy，这个服务整合了全球互联网大部分主流的即时聊天工具；Gwibber(硅博)，整合了主流的微博；Outlook聚合了电子邮箱，等等。尽管这些服务做到了把同类而不同的服务商提供的服务放在一起，省去了用户在自己的电脑上安装多款通信软件，但是不能达成各类服务之间的整合。用户需要分别管理不同的账户。

人们使用着不同种类的服务进行联系与交流，然而用户并不清楚究竟采用什么方式才能顺畅地联系到对方。对于用户来说，发送自己的消息到联系人并且让对方收到就成，而目前的这些软件不能让用户在无需顾虑采用什么服务的情况下发送自己的消息。eBuddy、Gwibber和Outlook等不同的软件相互独立而无法彼此照应，它们使用独立的联系人列表，独立的消息处理方式，独立的软件使用方法，因而无法满足互联互通的需求，用户依然需要选择通过何种方式来取得联系。

由此可见，现有的种类繁多的网络通信服务(如微博、SNS、论坛、电子邮箱和即时聊天工具等)相互间难以融合交流。

发明内容

本发明所要解决的技术问题是：提供一种基于云计算架构的网络服务聚合系统，可支持各类网络服务，让处于不同平台的各个用户进行无障碍交流的环境。

此外，本发明还提供一种上述基于云计算架构的网络服务聚合系统的聚合方法，可支持各类网络服务，让处于不同平台的各个用户进行无障碍交流的环境。

为解决上述技术问题，本发明采用如下技术方案：

一种基于云计算架构的网络服务聚合系统，所述系统包括：

客户端，按照运行的设备和Web接口进行通讯；

Web接口服务器，用以给客户端提供信息，并且处理和消息无关的数据；在用户登入时，向任务调度服务器索取相对空闲的消息处理服务器地址，操控和监视消息处理服务器，并即时将状况反馈给客户端；

任务调度服务器，负责监视消息处理服务器的资源消耗状态，并在Web接口服务器为登入用户索取相对空闲的消息处理服务器地址时返回，让Web接口服务器自行调用；在运行后，任务调度服务器定时对消息处理服务器更新资源使用情况；

消息处理服务器，通过Web接口服务器与客户端连接，用户的网络服务在消息处理服务器进行登入、登出、状态管理、消息收发处理；消息处理服务器启动后自动向任务调度服务器注册，让任务调度服务器能监视其状态，同时等待Web接口服务器的调用；发生需要提醒用户的情况时，消息处理服务器会推送到Web接口服务器处理；

数据库服务器，同时被Web接口服务器和消息处理服务器调用来记录各类信息。

一种上述基于云计算架构的网络服务聚合系统的聚合方法，所述聚合方法包括如下步骤：

客户端按照运行的设备和Web接口进行通讯；

Web接口服务器给客户端提供信息，并且处理和消息无关的数据；在用户登入时，向任务调度服务器索取相对空闲的消息处理服务器地址，操控和监视消息处理服务器，并即时将状况反馈给客户端；

任务调度服务器负责监视消息处理服务器的资源消耗状态，并在Web接口服务器为登入用户索取相对空闲的消息处理服务器地址时返回，让Web接口服务器自行调用；在运行后，任务调度服务器定时对消息处理服务器更新资源使用情况；

消息处理服务器通过Web接口服务器与客户端连接，用户的网络服务在消息处理服务器进行登入、登出、状态管理、消息收发处理；消息处理服务器启动后自动向任务调度服务器注册，让任务调度服务器能监视其状态，同时等待Web接口服务器的调用；发生需要提醒用户的情况时，消息处理服务器会推送到Web接口服务器处理；

数据库服务器同时被Web接口服务器和消息处理服务器调用来记录各类信息。

本发明的有益效果在于：本发明提出的基于云计算架构的网络服务聚合系统及其聚合方法，将所有通信软件和网络服务整合在一起，开发一种无缝交流的平台，发明基于云计算架构的网络服务聚合系统，建立了能够支持各类网络服务，让处于不同平台的各个用户进行无障碍交流的环境。本发明面向“人”，以人作为通讯的基础单位，采用用户联系人列表，能让处在不同通讯场合(使用不同的网络服务、不同的通讯设备)的多个联系人互通、交流与办公，能及时反馈众联系人的状态和特性，具有可靠的消息收发机制和高效的消息管理方式。

对所有用户而言，无论用户身在何处，无论用户或者用户的联系对象喜欢或擅长使用何种网络服务，也无论用户对如何使用自己的网络服务是否熟悉，只要用户双方的网络服务有交集，用户都能利用本发明便捷地与对方进行顺畅的交流；即使对方不在线，也能将此消息保存到数据库，被联系人在下次上线的时候会收到消息。

本用户通过新鲜事功能保留了各类服务原有的基本特性，因此用户无需再登入自己的网络服务，用户通过一个平台就能实现操控自己所拥有的社交网络服务的愿望。而且本系统的设计为今后功能的拓展夯实了良好的基础，对目前流行甚至是未来可能出现的网络服务类型都能兼收并蓄和融通，能方便地为其他通信设备开发客户端。本软件可应用到广泛的社会活动中去，可产生良好的社会效益，具有无限的市场开发前景。

附图说明

图1为本发明网络服务聚合系统的组成示意图。

具体实施方式

下面结合附图详细说明本发明的优选实施例。

实施例一

请参阅图1，本发明揭示了一种基于云计算架构的网络服务聚合系统，所述系统包括：客户端、Web接口服务器、任务调度服务器、消息处理服务器、数据库服务器。

客户端按照运行的设备和Web接口进行通讯。

Web接口服务器用以给客户端提供信息，并且处理和消息无关的数据；在用户登入时，向任务调度服务器索取相对空闲的消息处理服务器地址，操控和监视消息处理服务器，并即时将状况反馈给客户端。

任务调度服务器负责监视消息处理服务器的资源消耗状态，并在Web接口服务器为登入用户索取相对空闲的消息处理服务器地址时返回，让Web接口服务器自行调用；在运行后，任务调度服务器定时对消息处理服务器更新资源使用情况。

消息处理服务器通过Web接口服务器与客户端连接，用户的网络服务在消息处理服务器进行登入、登出、状态管理、消息收发处理；消息处理服务器启动后自动向任务调度服务器注册，让任务调度服务器能监视其状态，同时等待Web接口服务器的调用；发生需要提醒用户的情况时，消息处理服务器会推送到Web接口服务器处理。

数据库服务器同时被Web接口服务器和消息处理服务器调用来记录各类信息。

所述聚合系统包括保留服务基本特性的模块，包括：获得用户状态单元、广播用户状态单元、搜索单元、新鲜事获取定时器、执行服务命令单元。

【获得用户状态单元】由Web接口服务器调用，通常用户状态不保存在数据库中，而是直接从用户服务读取；消息处理服务器只读取第一个有状态的服务的状态发送返回给Web接口服务器；

【广播用户状态单元】一些服务具有显示用户状态的特性；所述广播用户状态单元由Web接口服务器调用，消息处理服务器将为用户所有服务都设定状态；如果用户的某些服务不支持，状态设定的行为将不被处理；

【搜索单元】对于具有或者需要搜索特性才能完全操控的网络服务，使用所述搜索单元对服务进行搜索；搜索过程和结果由服务插件实例完成和生成，对于用户对结果的响应由服务插件实例识别并执行相关操作；

【新鲜事获取定时器】服务新鲜事由Web接口服务器获取；Web接口服务器获取服务新鲜事时，用户新鲜事已经收集好并放在一个变量中；收集工作由新鲜事获取定时器完成，新鲜事获取定时器获取设定的频率将用户服务的新鲜事放入变量中，等待Web接口服务器获取；

【执行服务命令单元】执行服务命令由服务插件实例在服务新鲜事的时候生成，由服务插件实例识别并执行相关操作。

以上揭示了本发明基于云计算架构的网络服务聚合系统，本发明在揭示上述系统的同时，还揭示上述基于云计算架构的网络服务聚合系统的聚合方法；所述聚合方法包括如下步骤：

【步骤S1】客户端按照运行的设备和Web接口进行通讯；

【步骤S2】Web接口服务器给客户端提供信息，并且处理和消息无关的数据；在用户登入时，向任务调度服务器索取相对空闲的消息处理服务器地址，操控和监视消息处理服务器，并即时将状况反馈给客户端；

【步骤S3】任务调度服务器负责监视消息处理服务器的资源消耗状态，并在Web接口服务器为登入用户索取相对空闲的消息处理服务器地址时返回，让Web接口服务器自行调用；在运行后，任务调度服务器定时对消息处理服务器更新资源使用情况；

【步骤S4】消息处理服务器通过Web接口服务器与客户端连接，用户的网络服务在消息处理服务器进行登入、登出、状态管理、消息收发处理；消息处理服务器启动后自动向任务调度服务器注册，让任务调度服务器能监视其状态，同时等待Web接口服务器的调用；发生需要提醒用户的情况时，消息处理服务器会推送到Web接口服务器处理；

【步骤S5】数据库服务器同时被Web接口服务器和消息处理服务器调用来记录各类信息。

实施例二

系统的组成

本发明的整个网络信息聚合系统被划分为5个部分：

1、客户端

按照运行的设备和Web接口进行通讯，和最终用户交互。客户端可以被设计成运行在多个平台下，目前已实现了HTML、Windows Phone 7手机和Android客户端的设计，还将继续开发其他平台的客户端，以满足不同用户的使用需求。

2、Web接口服务器

提供给客户端信息并且处理和消息无关的数据(比如维护联系人列表)。在用户登入时，向“任务调度服务器”索取相对空闲的“消息处理服务器”地址，操控和监视“消息处理服务器”并即时将状况反馈给客户端。Web接口服务器可以有多个，以应对不同地域网络访问的需要。

3、任务调度服务器

或称“任务分配服务器”。此服务器仅仅负责监视“消息处理服务器”的资源消耗状态，并在“Web接口服务器”为登入用户索取相对空闲的“消息处理服务器”地址时候返回，让“Web接口服务器”自行调用。在运行后，“任务调度服务器”会定时对“消息处理服务器”更新资源使用情况。“任务调度服务器”理论上有一台(在资源共享的情况下可以作为集群)，负责整个云计算的负载均衡工作。

4、消息处理服务器

用户的网络服务就在“消息处理服务器”进行登入、登出、状态管理、消息收发等等处理。此服务器启动后自动向“任务调度服务器”注册，让“任务调度服务器”能监视其状态，同时等待“Web接口服务器”的调用。在有新消息或者其他需要提醒用户的情况，“消息处理服务器”会推送到“Web接口服务器”处理。此服务器需要多台才能保证在大用户的状况下还能及时响应。

5、数据库服务器

数据库服务器可以同时被“Web接口服务器”和“消息处理服务器”调用来记录联系人、服务帐号、话题等等信息。本系统使用postgresql作为数据库，在负荷量庞大的时候可以利用数据库软件自身功能进行集群处理。

数据库设计

数据库用来保存用户的登入信息、用户服务、用户联系人列表、话题、回复等等信息。数据库服务器可以被Web接口服务器和信息处理服务器调用。

(一)存储用户联系人

有两个表存储与用户联系人有关的信息。其中一个表储存联系人名称和一个自动增加的编号，另一个表储存联系方式和这个联系方式所对应的联系人的编号。这样设计可以形成一个联系人有多个联系方式的结构。

(二)存储用户服务

本表用于存储用户服务的相关信息，其中包含了服务名称，服务访问的方式(含用户名和密码)以及服务所属于的用户。

(三)存储话题和帖子

由于话题和帖子具备相同特性，它们共用一个数据表。表包含了标题、内容、作者、发布时间、父级帖子编号、根帖子编号、帖子内容代号、回复数量、查看数量、最后回复时间、最后回复联系人、隐私设置信息和帖子编号。帖子为树形结构，一个话题中，话题帖子为根帖子，话题下面的回复的父级帖子和根帖子的编号都是话题帖子的编号。而表中帖子的编号都是自动增长的。

帖子理论上可以无限嵌套。

帖子内容代号和帖子编号性质一样，它是帖子的唯一代号，其作用是用帖子的来源作为帖子标记。例如：用户收到的每封电子邮件都有一个唯一编号(UID)，系统在第一次接收这封邮件的时候会将这个编号重新组合成帖子内容代号并和邮件内容一起保存到数据库中。下次再次接受到这封邮件时，系统能识别出这个在数据库中已经有记录，就不会重复操作。隐私设置仅仅在此帖子为话题的时候才有值，用来指定帖子是否允许其他用户查看并发表话题

(四)存储话题联系人

存储话题联系人的表主要字段有：联系地址、联系方式、来源用户和话题编号。这个表的作用是存储用户对话题发帖或者这个表里的联系人对这个话题发消息时转发的地址列表。帖子联系人中有记录的地址，能及时收到和话题相关的消息。

(五)存储话题标签

该表的作用是让用户能及时搜索到相关的关键字，起到关键字索引的作用，在搜索时分词后就能直接SELECT出结果。这个表的字段只有关键字和帖子编号。

(六)存储延迟消息

由于并不能保证用户的消息一定能及时发送到联系人那边。因为，如果联系人的联系方式都无法用于传递，就必须将消息延迟到下次联系人的联系方式在线的时候。这个表缓存了用户即将通过消息处理服务器使用服务发送的所有信息，其中还记录重试次数，如果一直都无法成功，这个消息将不得不放弃发送。

服务器端设计

考虑到服务器软件的跨平台和技术支持上的问题，系统最终使用Java做为整个服务器端所使用的技术。因为服务总是需要拓展的，可能会需要安装多台服务器来维持。所以使用开源软件能节约软件授权的成本，使运营过程中只需要集中投入人力和硬件设施即可维持系统的运行。在实验阶段，在3台装有Ubuntu Server 10.4、JDK 1.6，并安装设置了Postgresql数据库和GlassFishv3的服务器上测试，获得成功。

(一)连接系统的各个部分

本系统为分布式。在架构设计的时候，系统被划分成了5个部分，其中4个部分和服务器端有关。决定使用hibernate的JDBC连接数据库后，还有Web接口服务器、任务调度服务器和消息处理服务器这3个部分之间的连接。使用效率相对较高的Java远程接口，调用JavaRemote Method Invocation连接这3个后端部分，让后端能有效的协调运作。

1、连接Web接口服务器和客户端

在架构设计的时候，为了兼容不同平台，决定使用基于HTTP协议和客户端进行交互。

(1)序列化

在传输过程中，服务器在内存中的对象要序列化才能发送到客户端。目的是将服务器的二进制数据转换为能给客户端解析的明文，使客户端能顺利地将服务器的内容呈现给用户。目前在HTTP协议传输中流行的序列化方法主要是XML和JSON。在比较了这两种序列化的方法后，本实施例决定采用JSON作为序列化的方式，原因有：

①JSON更加简单。JSON不需要像XML一样，规定数据的格式就能直接传输，使用JSON交互可以直接传输数据而不需要参考服务器的数据结构。

②JSON灵活。JSON可以随意规定参数并且任意传输，同时JSON也具有和XML一样元素嵌套的结构，支持数组和数组对象等等。

③JSON节约带宽。XML为了保持严谨的格式而带入一些不必要的标签。这些标签通常是留给开发人员使用。而一般我们只需要传递数据，并不希望验证合法性，XML的验证作用标签对我们没有用处。在带宽上，XML还存在一点天生的缺陷：每个值都需要被类似于<Tag>Hello</Tag>的包围，而相同的效果JSON只需要{Tag：‘Hello’}即可。

JSON在HTTP协议网络传输中的应用越来越多，也印证了上述判断。

(2)设计调用的接口

因为系统使用接口调用的方式和客户端互动，所以Web接口调用服务器里没有一个JSP动态页面。所有行为全部单独使用Servlet设计，接收和输出JSON。本实施例单独设计了一个抽象类让每个Servlet继承，完成判断请求合法性、解析和序列化JSON等任务，而每个Servlet类只负责直接读取并使用父类的函数进行响应，将处理结果返回给客户端即可。

(3)设计在HTTP协议中最为经济、和客户端保持状态同步的方法

客户端需要监听服务器端的状态更新。如果是传统的TCP/IP协议，我们可以让服务器端直接发送状态到客户端。而系统使用的是HTTP协议，HTTP不能直接对客户端发送消息，每个连接都是独立的。初始的想法是客户端定时向服务器索取更新信息，测试后发现这种方法无法达到实时更新的效果，而且非常浪费资源。经过分析一些其他公司的网页版即时通讯的消息接收原理，发现目前大部分网站使用长连接来解决这类问题。具体方案是，客户端在连接服务器时服务器会延时(这个时间通常为几十秒)给客户端回应，这样客户端会和服务端保持一段时间的连接。一旦有可以反馈的信息，服务器就中断延时，将信息返回给客户端。如果长时间没有可以发送的消息，服务器也会中断延时，但是不返回任何信息。客户端一旦接受到可以处理的信息，就可以及时反馈给用户。在一次长连接结束后将再次和服务器建立长连接，继续监听状态。

2、连接数据库

Web接口服务器和消息处理服务器都需要连接数据库。在研究Web接口服务器和消息处理服务器与数据库传输问题时，本实施例使用Hibernate作为连接数据库的中间件。使用Hibernate读取出的实体类能方便地序列化并进行数据传输，Hibernate帮助完成了为即将传输数据的打包工作，极大地提高了开发效率。

3、Web接口服务器、任务调度服务器、消息处理服务器之间的连接

任务调度服务器、消息处理服务器都不运行在容器中，所以不能使用hessian。因此，RMI是首选。在一切就绪后使用RMI就像直接调用本地的类一样，而且可以直接传输Hibernate的实体类，在使用的时候非常方便。

(二)WEB接口服务器

作为夹在客户端和消息处理服务器之间的Web接口服务器，主要负责用户登入，分配服务器资源，将客户端的命令传给消息处理服务器，再将消息处理服务器的命令反馈给客户端，同时处理一些不需要消息处理服务器介入的事务，比如管理联系人列表，查看话题等等。

1、加载

处于容器中的Web接口服务器通过ServletContextListener的contextInitialized监听整个站点的启动。这个不像非容器的可以直接在Main函数里编码。加载过程中除了加载容器所必要的组件外，Web接口服务器还要加载配置文件，读取任务调度服务器的相关信息，与任务调度服务器建立连接，获取消息处理服务器集群的信息，再加载可被消息处理服务器集群支持的网络服务列表，以便在用户需要的时候及时反馈给用户。

2、销毁

此过程通知读取任务调度服务器和消息处理服务器集群，该Web接口服务器已经销毁，这些服务器将不会再与销毁的Web接口服务器进行连接。

3、用户注册

和任何网络服务一样，用户需要注册一个具有个人特征的帐号，让系统可以对特定的用户进行回应。用户选择一个唯一的用户名和一个具有一定复杂度的密码。同时用户还需要输入自己的名字，这个名字被用来给自己的联系人表明身份，系统没有强行要求用户输入自己的真实姓名。注册用户的密码将进行2次SHA1加密，再放入数据库。

4、用户登入

用户需要登入后才能管理个人信息，收发消息，管理联系人等，使用和他人隔离的甚至和隐私相关的事务。用户登入后，服务器将相互处理一系列用户信息，读取用户服务列表，从任务调度服务器获得合适的消息处理服务器地址，使用获取到的服务器登入用户的服务，加载联系人列表，并监听从消息处理服务器反馈的信息。

(1)用户登入过程

这个过程有2种情况发生。用户自行输入用户名和密码以登入，用户名和密码在用户上次登入后就已经保存在客户端里。对此，在登入前，每次接收连接时，都要检查是否包含了有效的用户登入信息，如果有效就自动登入。

(2)用户登入后服务器的处理

用户登入后，服务器将新建线程，进行登入后的操作。也就是说，用户在登入和进入自己的个人主页之时，服务器只检查用户名和密码的合法性。新建的线程完成以下几个步骤：

1)从数据库服务器读取用户的联系人列表；

2)从数据库服务器读取用户的服务列表；

3)向任务调度服务器索取当前用户将要使用的消息处理服务器地址；

4)连接获取的消息处理服务器地址；

5)将获取的服务列表发送给消息处理服务器，让消息处理服务器登入这些服务；

6)监听来自消息处理服务器的回推。

完成这些步骤后，服务列表、联系人列表连接后的消息处理服务器接口都将保存在Web接口服务器的一个处理用户系统信息的内存单元内。因为用户在登入后会产生非常多的信息，为每个用户专门分配内存单元有助于管理。

5、监听用户状态

用户在登入后，Web接口服务器将监听来自消息处理服务器的回推。回推的主要内容是消息处理服务器收到新的用户消息、用户的服务状态变更(比如是否已经登入、是否有新的新闻、联系人的联系方式是否有变化等等)。Web消息处理服务器在接收到消息处理服务器的回推后，将进行处理，如果需要，打断和客户端更新状态的长连接，把更新的消息在一个请求中返回给客户端。

6、用户登出

两种情况会使用户登出。一种是用户主动登出，客户端会按照用户的意愿联系Web接口服务器登出用户。另一种是用户长时间没有进行长连接，对此，本实施例设定SessionTimeout并监听SessionListener的sessionDestroyed事件来实现用户登出。在用户登出后，Web接口服务器将通知消息处理服务器和任务调度服务器销毁与用户有关的资源，同时销毁Web接口服务器和用户有关的资源。其中和此用户有关的回推将不被监听。

7、管理用户信息

Web接口服务器负责管理被用户所要求管理的用户信息，这些信息就是用户联系人列表、联系人联系方式优先级、用户服务等等信息。为了给客户端的人机交互带来方便，管理用户信息的接口需要进行合适的设计。

(1)管理联系人列表

用户可以管理自己的联系人列表，除了添加和删除联系人以外，还可以对联系人的联系方式进行排序。用户在管理联系人列表的时候，Web接口服务器还会和信息处理服务器进行交互。例如，用户给自己的联系人添加了MSN地址作为一种联系方式，Web接口服务器就会联系消息处理服务器，在用户的MSN账户上进行添加联系人的操作。这样可以保证联系人列表和用户服务的联系人列表同步。

(2)管理服务列表

用户需要添加自己所使用的网络服务才能让系统发挥效用。用户可以添加和删除网络服务，添加网络服务时，Web接口服务器会通知消息处理服务器尝试以用户提供的信息登入。如果登入成功，就将用户提供的信息保存到数据库，以便下次用户使用。通常用户需要提供自己的帐号和密码，对于某些不特定的帐号(比如邮箱)还需要提供服务器地址和端口等信息。

(3)管理帐号

用户在此管理自己在注册的时候提供的信息，除了用户名以外，其他任何信息都可以修改，包括密码和名字。

(4)查询话题

用户需要分类检索自己的话题，就像电子邮箱里被分成了收件箱、发件箱、垃圾邮件和回收站等等。在系统中，话题被分为我的话题、加入的话题和我回复的话题。用户在知道自己检索的目的时，可以方便地从中寻找并查看话题。由于查询到的话题可能数量非常多，Web接口服务器支持分页查询，旧的话题置于末端。

(5)查询帖子内容

Web接口服务器可以直接查询数据库中的帖子，列出话题并列出话题的回复与回复的回复。帖子的内容就是用户和其联系人交流的内容。在提供父级帖子编号和根帖子编号的情况下，客户端可以非常容易地组合成树形结构并呈现给用户。

(6)发布话题与回复

Web接口服务器接收在客户端用户的要求下发布话题或者回复。用户需要提供帖子的相关信息，Web接口服务器不直接处理这些信息，而是转发到用户的消息处理服务器，让消息处理服务器进行写数据库和消息发送的工作。

(7)将状态推送到客户端

系统会在一次长连接中推送多条信息给客户端，一次推送可能同时包含用户在线状态和服务状态、是否有新的消息等信息。Web接口服务器在收到消息处理服务器的推送后，会将其缓存在用户内存单元的一个变量中，在Web接口服务器的长连接的循环中，一旦监测到变量变化，就会打断并返回给客户端。因为用户可能在不同地方登入，在Java Servlet里会拥有多个Session ID，所以，在推送前需要给每个不同Sesssion ID保留一个副本，将推送消息发送到用户所有的客户端上。

(8)服务新鲜事

此特性将用户服务中带有社交网站元素的信息搬到客户端通常是主页的位置，让用户知道自己的联系人或者此服务的其他人在做什么而主动进行交流。这些信息由消息处理服务器定时从用户登入的服务中获取，Web接口服务器再定时从消息处理服务器获取并放入用户内存单元中。这个特性没有使用推送机制，因为联系人状态的信息可能变化非常快。客户端需要主动向Web接口服务器索取这些信息。这些信息是由消息处理服务器的服务插件生成，包含状态标题、内容、联系人和反馈方式。反馈方式的作用是告诉客户端用户在点击这条状态后该如反馈。反馈方式有：

①直接给状态的联系人产生新话题；

②复制状态内容作为新话题，再对其进行回帖；

③将联系人和状态标题及内容返回给Web接口服务器，再转发消息处理服务器，由消息处理服务器的服务插件处理行为。

(三)消息处理服务器

1、消息处理工作过程

消息处理服务器是处理系统用户消息的主要部分，是真正实现消息收发的部分。消息处理服务器可以集群部署，只要能和任务调度服务器注册，就能被分配到任务。Web接口调用指定的消息处理服务器，消息处理服务器会将任务进行处理，调用服务插件，让服务插件实现消息最后的接收、发送和其他服务相关的功能。

2、加载

服务插件启动后，从配置文件读取任务调度服务器地址，建立Hibernate和数据库的连接，并加载加RMI服务到注册表。一开始启动的时候，只加载通用RMI服务。然后将此服务器在任务调度服务器上进行注册。结束后根据配置文件中插件的信息加载服务插件。

(1)加载服务插件

本实施例在Java中动态加载Jar文件的插件来实现插件的特性。插件都按照一定的接口和模式进行设计。插件加载模块在加载之前读取配置文件，配置文件包含了插件的系统名称、类名称、是否依赖联系人列表发送消息、默认优先级、插件的Jar所依赖的包和登入服务时所需要提供的信息模版。插件系统名称可以在系统内部识别此服务，是否依赖联系人决定了能否在联系人不在联系列表的情况下也能通过地址发送消息，默认优先级决定了用户在添加此服务作为联系人的联系方式的时候所赋予的优先级(用户可以自行进行调整)，插件依赖的Jar包就是插件运行所需要的其他Jar文件。在加载插件Jar的时候，依赖项将和插件一起加载到消息处理服务器中。

(2)在任务调度服务器上进行注册

因为Web接口服务器需要通过任务调度服务器来为用户分配消息处理服务器的分布式服务器资源，而且为了使整个分布式网络更加灵活，每台消息处理服务器上线后都要自动向任务调度服务器注册，使任务调度服务器知道自身(消息处理服务器)的存在，以便在Web接口服务器索取用户资源时将自己的资源给Web接口服务器使用。

3、通用RMI服务

通用RMI服务针对的是整个消息处理服务器。Web消息服务器可以从通用RMI服务获取可用服务列表、生成用户RMI服务。任务调度服务器可以从通用RMI获取此消息处理服务器的硬件资源消耗情况。因为不同的用户可能分散在不同服务器里，消息处理服务器之间也能在需要的时候互相通讯。

(1)可用服务列表

可用服务列表由加载的配置文件而来，消息处理服务器直接将列表返回至询问的Web接口服务器，让Web接口服务器自行处理。

(2)生成用户RMI服务

Web接口服务器被指令用户登入后，消息处理服务器会被要求为用户生成一个用户专有的RMI远程对象。消息处理服务器将此对象的RMI地址返回Web接口服务器，让Web接口服务器自行连接刚才生成的RMI远程对象。连接该用户的远程对象后Web接口服务器就可以控制用户的服务资源(比如发送帖子，添加联系人等等)。

(3)获取硬件资源消耗情况

任务调度服务器分配用户资源的方式就是根据信息处理服务器的资源消耗情况。任务调度服务器会每隔一段时间更新消息处理服务器的硬件资源使用状况。提供给任务调度服务器的是一个性能指数，此信息通过Java虚拟机从系统获取，本实施例使用了com.sun.management的OperatingSystemMXBean来获取操作系统的信息，计算公式为.getRuntime().freeMemory()/.getSystemLoadAverage()。这样数值越大就代表系统资源越丰富。

(4)相互通讯

考虑到系统用户之间相互交流信息时，如果两个用户不在同一台消息处理服务器，就无法回推消息，因为Web接口服务器也是不确定的，回推时一定要把消息回推到正确的Web接口服务器。这样用户只能自己手动检查是否有新消息。相互通讯的功能是当系统在发帖的时候发现联系人有其他用户，就在用户内存单元寻找本机是否存在此用户，存在就说明用户和联系人中的用户在同一台服务器，可以直接以相应回推，不存在就要询问任务调度服务器此用户的消息处理服务器，将回推的消息转发到联系人用户的消息处理服务器，被转发的消息的服务器将按照不同流程将消息回推到Web接口服务器。如果在任务调度服务器找不到，将把这个帖子放入延迟发送的数据表中，在下次合适的时候发送。

4、用户RMI

用户在登入以后，Web接口服务器就会从被指定的消息处理服务器中获得用户RMI。所有和该用户有关的远程调用都通过这个接口实现。

(1)制定函数

1)指定此用户RMI的所有人；

2)测试服务是否可通过用户提供的信息登入(在用户添加新服务帐号的时候使用)；

3)加载并登入用户服务。此操作由Web接口服务器在用户登入后调用；

4)销毁。此操作在用户登出帐号时由Web接口服务器调用；

5)获取联系人优先联系服务；

6)获取所有服务在线情况；

7)设定用户状态；

8)获取用户状态；

9)获取用户服务新鲜事；

10)发帖；

11)转发消息；

12)执行服务命令；

为了加快每次RMI调用的响应速度，所有不返回值的函数的过程全部使用单独的线程处理(异步)。比如加载并登入用户服务这个步骤，如果等待所有服务上线，将让用户等待很长的时间，而给不返回值的情况下使用单独的线程可以让过程变得更加高效。对于需要返回值的调用，要求这个过程能够尽快完成。

(2)上述函数实现的方法

1)指定此用户RMI的所有人

这个过程由Web接口服务器调用，检查消息处理服务器是否已经存在关于此用户的用户内存单元。如果有，就使用已经存在的资源，如果没有，就为该用户创建资源。同时开启定时器定时从用户服务更新新鲜事，并且记录此Web接口服务器。

2)测试服务

该函数只有在用户尝试添加新服务或者修改服务时由Web接口服务器调用，确认用户提供的信息是否能登入。这个函数将返回一个值，所以不是异步的，用户则需要等待此服务登入成功或者失败。

3)测试服务是否可通过用户提供的信息登入

Web接口服务器会把用户的服务和服务登入信息发送给用户的消息处理服务器。消息处理服务器将在加载好的服务插件上创建服务实例，每个用户的每个服务都有这样一个实例，只不过因为不同的服务和帐号而不相同。加载完毕后，消息处理服务器会让每个加载好的服务插件实例登入服务。登入过程由服务插件对象控制，返回是否登入结果到Web接口服务器。

4)加载并登入用户服务

Web接口服务器将发送用户服务列表和相关登入信息给指定的消息处理服务器列表，由消息处理服务器登入服务。Web消息处理服务器将异步为每个服务调用“测试服务是否可通过用户提供的信息登入”函数，而登入服务的函数到此结束，登入是否成功的消息由服务插件实例回推到Web接口服务器中。所以这个过程对于用户来说是一瞬间的事情，而无需等待服务加载并登入完毕。

5)销毁

这个过程是在Web接口服务器的用户注销后所发生。因为考虑到用户在多个地方登入的可能，所以必须要在确认用户完全登出后才能销毁用户相关的资源。销毁资源的过程中，所有服务将离线，所有定时器关闭，最后从内存销毁所有此用户所使用的资源。

6)获取联系人优先联系服务

该函数可以直接被Web消息处理服务器调用、在回推联系人可使用服务和发帖的时候调用。这个过程中，消息处理服务器将从联系人列表中读取联系人的联系方式；按照联系方式的优先级在每个已经登入的用户服务中判断联系方式是否可用；将找到的第一个联系方式返回。

7)获取所有服务在线情况

Web接口服务器调用此函数来获取目前服务的在线情况。消息处理服务器将直接查询用户服务的在线状态并返回。

8)广播用户状态

一些服务具有广播用户状态的特性。如一些即时通讯工具，可以显示联系人目前在做什么，这些内容可以被用户的任何联系人看到，发送一条微博也属于广播范畴。用户也可以广播自己的状态。此函数由Web接口服务器调用，消息处理服务器将为用户所有服务都设定状态。如果用户的某些服务不支持，状态广播的行为将不被处理。还可以通过用户状态实现分享之类广播的特性。

9)获取用户状态

此函数是由Web接口服务器调用。通常用户状态不保存在数据库中，而是直接从用户服务读取。消息处理服务器只读取第一个有状态的服务的状态发送返回给Web接口服务器。

10)获取用户服务新鲜事

服务新鲜事由Web接口服务器获取。Web接口服务器获取的时候，用户新鲜事已经收集好并放在一个变量中。收集工作由新鲜事获取定时器完成。因为每个服务获取新鲜事的时间和方式不同，所以使用定时器是安全稳定的。新鲜事获取定时器以固定的频率将用户服务的新鲜事放入变量中，等待Web接口服务器获取。

11)发帖

作为整个系统的核心之一，发帖可以被消息处理服务器内部调用，也可以被Web接口服务器调用。发帖可以是用户，也可以是用户的服务中收到的消息。发帖需要提供数据库表的所有信息，作为话题帖子，还需要提供话题的联系人列表。

以下是发帖时系统处理步骤：

A.检查唯一编号是否已经在数据库存在。如果不存在进行下一步，如果存在直接退出函数；

B.将信息格式化；

C.如果为话题帖子，检查是否缺少用户为其中之一的联系人，如果是，将其补上；

D.检查联系人列表的联系人和作者。有些时候用户或者联系人会直接使用服务的地址作为联系人字符串，而这个地址刚好是某个联系人的联系方式。这个过程将把使用服务地址联系人字符串改变为用户的联系人的联系人字符串。一般当用户的联系人发帖时可以将地址转换成联系人，让用户能直接识别；

E.将帖子插入数据库；

F.如果这个帖子为回复，更新父帖和根帖的数据库纪录中“回复人”和“最后回复时间”字段；

G.读取已经插入数据库的帖子的编号；

H.如果为话题帖子，将帖子联系人列表插入帖子联系人表；

I.如果是回复，获取根帖的编号。如果是话题帖子，根帖编号为已经插入数据库的帖子的编号；

J.通过获取的根帖子的编号从数据库获取根帖子的联系人列表；

K.根据读取的帖子联系人列表，将消息转发给联系人。

12)转发消息

此函数不被Web接口服务器调用，是发帖时用来为指定联系人或用户转发消息时使用。因为一个话题可能有不同的用户参与其中，而不同的用户可能在不同的消息处理服务器，所以转发消息需要作为远程方法调用来执行。转发过程中，系统将：

A.检查转发的联系人和作者是否为同一人，如果是，此消息将不被转发到这个联系人；

B.检查转发的联系人是否为系统的另一个用户，并且此用户不在本地的消息处理服务器中。如果是，将从任务调度服务器读取此用户位置，并把此消息转发到用户位置进行处理。整个本服务器的转发过程结束；

C.检查转发消息的联系人字符串的格式；

D.如果为用户联系人字符串，将通过获取联系人优先联系服务方法获取最合适用户联系人联系方式，通过这个联系方式所对应的服务插件实例发送消息；

E.如果为用户的某个服务插件的实例地址，直接通过这个实例发送；

F.如果为系统用户，将消息回推到用户的Web接口服务器。

整个过程是否成功将被监视，如果不成功，这个消息将保存到数据库，在下次合适的时候发送。

13)执行服务命令

命令由服务插件实例在服务新鲜事的时候生成，由服务插件实例识别并执行相关操作。

(四)任务调度服务器

任务调度服务器是为用户分配消息处理服务器资源的服务器，也是索引用户消息处理服务器的服务器。任务处理服务器启动的时候注册自己的RMI，就等待其他服务器的连接。

1、消息处理服务器的注册

注册过程将把此消息处理服务器的IP地址纪录在案，并且打开一个定时器定期从消息处理服务器获取性能指数，找出资源剩余最大的服务器并记录。期间将为每个服务器打开定时器检测消息处理服务器是否离线来更新消息处理服务器列表。

2、获取用户消息处理服务器

每次Web接口服务器获取用户消息处理服务器的时候，任务调度服务器将记录的服务器返回即可。

服务插件设计

(一)服务插件定义及其函数

服务插件是用户服务收发的最终端，运行于消息处理服务器中。我需要为每个用户可能会用到的服务编写服务插件。服务插件所提供的服务可以是任何具有消息交流特性的互联网服务，但是每个服务插件都要按照特定的接口编写，以便消息处理服务器支持。目前服务插件接口的函数有：

1.加载；

2.登入；

3.登出(断开连接)；

4.发送消息；

5.获取服务在线情况；

6.获得用户状态；

7.广播用户状态；

8.搜索

9.重新加载。此函数为消息处理服务器为每个插件实例的一个定时器调用，提醒其更新自己的状态；

10.添加联系人(和用户联系人列表中的联系方式绑定)；

11.删除联系人(和用户联系人列表中的联系方式绑定)；

12.判断地址是否可以发送，消息处理服务器据此判断是否通过此联系方式转发用户消息；

13.获取新鲜事；

14.执行服务命令。

(二)服务处理方式

虽然每个服务并不相同，但是我可以针对同一类型的服务使用同一套处理方式。例如即时通讯，我为这种类型的服务开发了自动判断话题和让联系人选择话题的部分。由于即时通讯工具的消息不携带其他信息，因而需要人工确定第一条消息的话题。如微博，本实施例将用户状态设定为发送一条微博，获取用户最后发送的微博作为用户状态，而用户向指定微博为联系方式的联系人发送消息时，将其视为私信处理，微博的用户评论了用户状态，系统就复制用户的这条状态作为话题，将评论作为回复。服务插件可以自主搭配使用任何消息处理服务的函数来实现具有服务特色的插件。服务插件可以自主处理服务命令，这样可以让新鲜事的功能变得更加灵活，服务插件自己订制新鲜事的指令，让用户选择后还将自行处理这些指令。

(三)服务消息的处理

服务插件在接收到服务消息后，将其托管到消息处理服务器中处理消息。使用的方法和用户发帖时Web接口服务器所调用的是同一个函数。当服务插件以话题形式发布话题时，联系人则是接收此消息的系统用户。

(四)开发与维护

本实施例使用开源的由社区或者志愿者维护的服务类库，以此为基础进行开发。这些类库在许可证范围内可以随意使用，节约了开发时间与成本。但并不是所有的服务都有开源社区或者志愿者的维护，有些服务需要自己开发。而有些服务是无法开发插件的，例如，无法为腾讯QQ开发服务插件，因为QQ使用了封闭的信息传输方法，并且协议每隔一段时间就会发生改变。以前有不少QQ协议的类库，但是最终都因为QQ协议频繁变动而放弃维护了。

实施例三

MSN插件的开发

为了制作MSN插件，本实施例在网上找到了Java MSN Messenger library(http://sourceforge.net/projects/java-jml/)。该类库由jadestorm开发并维护，使用Apache License V2.0协议，可以在保留协议的情况下使用这个类库于商业和非商业的用途。这个类库提供了MSN基本的协议架构，如果要应用在消息处理服务器中，还需要按照服务插件接口进行封装。

以下假设您已经理解JML的开发文档。

1、加载

这个过程为插件指定了服务的系统用户，在以后和消息处理服务器交互的时候会用到。

2、登入

本过程将解析提供给插件的登入信息，使用这些登入信息调用JML的messenger＝MsnMessengerFactory.createMsnMessenger，创建一个MSN协议的实例，为监控状态添加Listener，然后调用messenger.login()进行登入。由于JML使用异步的登入方式，因此必须在主线程等待JML的登入异步线程完成登入后，再结束主线程的登入过程，返回是否登入的结果。如果MSN成功登入，将回推用户的Web接口服务器，说明用户的这个MSN已经登入。

3、加载MSN服务联系人

在登入过程中设定的Listener，其中一个用途就是监听MSN的服务器是否发送了MSN服务联系人到我的消息处理服务器，或者联系人列表是否出现改变。在接收到MSN服务的联系人列表后，将把联系人列表的联系人地址，和系统用户的联系人联系方式的地址进行比较，如果不存在这个地址，就把这个地址导入联系人列表。服务在第一次登入的时候，会将所有服务联系人地址导入系统用户的联系人列表。同时这个过程将回推用户的Web接口服务器联系人列表，告知其已经改变。

4、登出

在这里，直接调用messenger.logout()登出用户MSN。

5、接收消息

在登入时添加的其中一个Listener作用就是监听服务的联系人发送的消息。由于即时通讯工具的消息无法保存额外信息，也就是说光从单个消息，我们并不知道其内容说的是什么话题。这个问题存在于所有即时通讯工具中，所以为即时通讯工具开发了一个公共类库，让公共类库来托管即时通讯消息的收发工作。而即时通讯的服务插件只需要按照要求提供参数，就可以实现兼容系统的话题消息机制。

6、发送消息

发送消息对系统来说实际上是一个给用户的联系人指定话题的过程。因为发送消息时，服务插件能得知发送消息所指向的话题。这个过程也交给即时通讯工具的公共类库处理，最终发送的消息不光包含内容本身，还有消息的发送者和标题。

7、获取服务在线情况

直接返回最后登入的状态

8、获得用户状态

直接返回messenger.getOwner().getPersonalMessage()。

9、广播用户状态

使用messenger.getOwner().setPersonalMessage(Status)设置用户MSN的个人消息。

10、搜索

MSN的类库没有搜索特性，所以搜索在此返回空。

11、重新加载

MSN的类库具有自动维持登入状态的特性，所以什么都不需要做。

12、添加联系人

使用messenger.addFriend(Email.parseStr(Address)，Address)。

13、删除联系人

使用messenger.removeFriend(Email.parseStr(Address)，false)。

14、判断地址是否可以发送

这里，先判断MSN服务是否在线；接着判断用户MSN是否包含这个联系人。如果条件都满足，返回

messenger.getContactList().getContactByEmail(Email.parseStr(Address)).getStatus()！＝MsnUserStatus.OFFLINE。

15、获取新鲜事

MSN的新鲜事在加载服务联系人列表的时候，就从服务联系人列表中的联系人个人信息上提取，并保存在一个数组变量中，等待消息处理服务器获取。这里的所有新鲜事的服务命令全部都是为此联系人创建新话题，此命令可以直接由客户端处理，不需要在执行服务命令的时候处理。

16、执行服务命令

因为新鲜事里没有需要让服务插件执行的命令，所以这里什么都不需要做。

实施例四

新浪微博插件的开发

尽管国内有不少封闭的网络服务提供商，不过也不缺少一些开放的网络服务。新浪微博有自己维护的，从原本用来支持Twitter的twitter4j(作者为Yusuke Yamamoto)改编而来的weibo4j类库，可以直接用于开发支持新浪微博的软件。这个类库同样需要封装后才能被消息处理服务器接受。

1、加载

该过程和MSN一样，指定了服务的系统用户。

2、登入

新浪微博使用了OAuth认证方式，和本系统的Web接口服务器一样，基于HTTP协议。登入的过程实际就是初始化微博接口实例的过程，以解析后的用户名和密码初始化微博接口(weibo＝new Weibo(user，pass))，使用此接口就可以访问用户微博的任何授权资源。登入后，系统会尝试性地加载联系人(从weibo.getFriendsStatuses()获取)，成功就说明此用户的用户名和密码是正确的。全部过程完成后返回用户验证结果，同时回推给用户的Web验证结果。

3、加载服务联系人

此过程已经在登入的时候完成。

4、登出

weibo4j没有登出的接口，实际上也不需要，因为weibo4j最终使用HTTP协议，所以不用再访问即可达到相同效果。因消息处理服务器在服务登出后将直接对其进行销毁，故这里不需要做任何事情。

5、接收消息

由于使用HTTP协议，新浪微博的服务器并不会主动在有评论或者私信时，发送消息给消息处理服务器。因此，需要定时从新浪微博的服务器读取来接收消息，这个过程在“重新加载”里处理。

6、发送消息

在微博，发送消息有两种模式，即私信和微博回复。服务插件为确定这两种模式，必须对消息对应的话题进行判断。服务插件会依据从数据库读取发送的消息的话题的“帖子内容代号”来判断消息是否为微博。在重新加载的过程中，作为新话题的，微博都将使用唯一的开头，如果在发送消息的时候判断到这个唯一的开头，就将其以此微博的评论发送。如果没有判断到这个开头，就以私信的形式发送。

7、获取服务在线情况

一旦成功登入，在线情况就一直为在线。如果在登入的时候就没有成功，就一直显示不在线，直到登入成功。

8、获得用户状态

本函数返回最后一条微博作为用户状态。

9、广播用户状态

发布一条以用户状态为内容的微博，来实现微博的广播用户状态功能。

10、搜索

新浪微博的API提供了搜索微博的方法。在此，系统将使用和新鲜事类似的方法处理搜索到的微博。

11、重新加载

这个过程将主要处理新的微博评论、新的私信和新鲜事这些内容。前面解释了微博服务器不会即时回应消息，因而需要定时从服务器获取。由于新浪的API规定不能以非常高的频率访问他们的服务器，所以本实施例以2分钟为周期，同步微博的信息。

(1)处理微博评论

首先，使用weibo.getCommentsToMe()获得他人对用户的评论。系统会获得这个评论的内容和评论对应的微博状态。先把这个微博状态的编号组合成唯一的帖子内容代号，在数据库进行查找，如果找不到就将这个微博状态以话题的方式插入。接着处理评论内容，将其以微博状态对应的话题的回复进行发帖。

(2)处理私信

然后，使用weibo.getDirectMessages()。这个处理过程，和即时通讯工具的处理方式一样。

(3)处理新鲜事

最后，调用weibo.getHomeTimeline()，获得用户微博中原本显示在首页的微博状态，作为微博服务的新鲜事显示在用户客户端的主页上。使用特殊的服务命令作为新鲜事的服务命令，这是因为，用户在点击他人的微博状态后，系统需要将这条微博状态复制为话题后才能回复，这个任务客户端无法完成，所以返回服务插件完成后，再移交Web接口服务器处理。微博还具有转发微博的主要功能，我们针对微博增加了额外特殊服务命令，交由服务器处理并在用户的微博服务中进行转发。

12、添加联系人

直接使用weibo.createFriendship(Address)添加服务联系人。

13、删除联系人

直接使用weibo.destroyFriendship(Address)删除服务联系人。

14、判断地址是否可以发送

这里状况过于复杂，直接返回“是”。

15、获取新鲜事

直接返回“重新加载”步骤里生成的新鲜事。

16、执行服务命令

新鲜事使用了需要服务插件处理后才能继续的服务命令。在这里，服务插件需要把用户点击的微博内容作为话题复制后，再让用户对其进行回复。执行服务命令将处理这个过程。完成后，将返回话题的帖子编号，以便客户端让用户对其进行回复。

综上所述，本发明提出的基于云计算架构的网络服务聚合系统及其聚合方法，将所有通信软件和网络服务整合在一起，开发一种无缝交流的平台，发明基于云计算架构的网络服务聚合系统，建立了能够支持各类网络服务，让处于不同平台的各个用户进行无障碍交流的环境。本发明面向“人”，以人作为通讯的基础单位，采用用户联系人列表，能让处在不同通讯场合(使用不同的网络服务、不同的通讯设备)的多个联系人互通、交流与办公，能及时反馈众联系人的状态和特性，具有可靠的消息收发机制和高效的消息管理方式。

对所有用户而言，无论用户身在何处，无论用户或者用户的联系对象喜欢或擅长使用何种网络服务，也无论用户对如何使用自己的网络服务是否熟悉，只要用户双方的网络服务有交集，用户都能利用本发明便捷地与对方进行顺畅的交流；即使对方不在线，也能将此消息保存到数据库，被联系人在下次上线的时候会收到消息。

本用户通过新鲜事功能保留了各类服务原有的基本特性，因此用户无需再登入自己的网络服务，用户通过一个平台就能实现操控自己所拥有的社交网络服务的愿望。而且本系统的设计为今后功能的拓展夯实了良好的基础，对目前流行甚至是未来可能出现的网络服务类型都能兼收并蓄和融通，能方便地为其他通信设备开发客户端。本软件可应用到广泛的社会活动中去，可产生良好的社会效益，具有无限的市场开发前景。

这里本发明的描述和应用是说明性的，并非想将本发明的范围限制在上述实施例中。这里所披露的实施例的变形和改变是可能的，对于那些本领域的普通技术人员来说实施例的替换和等效的各种部件是公知的。本领域技术人员应该清楚的是，在不脱离本发明的精神或本质特征的情况下，本发明可以以其它形式、结构、布置、比例，以及用其它组件、材料和部件来实现。在不脱离本发明范围和精神的情况下，可以对这里所披露的实施例进行其它变形和改变。

Claims (10)

1.一种基于云计算架构的网络服务聚合系统，其特征在于，所述系统包括：

客户端；

Web接口服务器，用以给客户端提供信息，并且处理和消息无关的数据；在用户登入时，向任务调度服务器索取相对空闲的消息处理服务器地址，操控和监视消息处理服务器，并即时将状况反馈给客户端；

任务调度服务器，负责监视消息处理服务器的资源消耗状态，并在Web接口服务器为登入用户索取相对空闲的消息处理服务器地址时返回，让Web接口服务器自行调用；在运行后，任务调度服务器定时对消息处理服务器更新资源使用情况；

消息处理服务器，通过Web接口服务器与客户端连接，用户的网络服务在消息处理服务器进行登入、登出、状态管理、消息收发处理；消息处理服务器启动后自动向任务调度服务器注册，让任务调度服务器能监视其状态，同时等待Web接口服务器的调用；发生需要提醒用户的情况时，消息处理服务器会推送到Web接口服务器处理；

数据库服务器，同时被Web接口服务器和消息处理服务器调用来记录各类信息。

2.根据权利要求1所述的基于云计算架构的网络服务聚合系统，其特征在于：

设置于客户端和消息处理服务器之间的Web接口服务器主要负责用户登入、分配服务器资源，将客户端的命令传给消息处理服务器，再将消息处理服务器的命令反馈给客户端，同时处理一些不需要消息处理服务器介入的事务；

加载过程中除了加载容器所必要的组件外，Web接口服务器还要加载配置文件，读取任务调度服务器的相关信息，与任务调度服务器建立连接，获取消息处理服务器集群的信息，再加载可被消息处理服务器集群支持的网络服务列表，以便在用户需要的时候及时反馈给用户；

用户需要登入后才能管理设定信息；用户登入后，服务器将相互处理一系列用户信息，读取用户服务列表，从任务调度服务器获得合适的消息处理服务器地址，使用获取到的服务器登入用户的服务，加载联系人列表，并监听从消息处理服务器反馈的信息；

用户自行输入用户名和密码以登入，用户名和密码在用户上次登入后就已经保存在客户端里；对此，在登入前，每次接收连接时，都要检查是否包含了有效的用户登入信息，如果有效就自动登入；

用户登入后，服务器将新建线程，进行登入后的操作；即用户在登入和进入自己的个人主页之时，服务器只检查用户名和密码的合法性；新建的线程完成以下六个步骤：

(1)从数据库服务器读取用户的联系人列表；

(2)从数据库服务器读取用户的服务列表；

(3)向任务调度服务器索取当前用户将要使用的消息处理服务器地址；

(4)连接获取的消息处理服务器地址；

(5)将获取的服务列表发送给消息处理服务器，让消息处理服务器登入这些服务；

(6)监听来自消息处理服务器的回推；

完成上述六个步骤后，服务列表、联系人列表连接后的消息处理服务器接口都将保存在Web接口服务器的一个处理用户系统信息的内存单元内；用户在登入后会产生大量信息，为每个用户专门分配内存单元，以便于管理；

用户在登入后，Web接口服务器将监听来自消息处理服务器的回推；回推的主要内容是消息处理服务器收到新的用户消息、用户的服务状态变更；Web消息处理服务器在接收到消息处理服务器的回推后，将进行处理，如果需要，打断和客户端更新状态的长连接，把更新的消息在一个请求中返回给客户端；

两种情况会使用户登出；一种是用户主动登出，客户端会按照用户的意愿联系Web接口服务器登出用户；另一种是用户长时间没有进行长连接；在用户登出后，Web接口服务器将通知消息处理服务器和任务调度服务器销毁与用户有关的资源，同时销毁Web接口服务器和用户有关的资源；其中和此用户有关的回推将不被监听。

3.根据权利要求2所述的基于云计算架构的网络服务聚合系统，其特征在于：

所述Web接口服务器负责管理被用户所要求管理的用户信息；

(1)管理联系人列表

用户管理自己的联系人列表，除了添加和删除联系人以外，还可对联系人的联系方式进行排序；用户在管理联系人列表的时候，Web接口服务器还会和信息处理服务器进行交互；保证联系人列表和用户服务的联系人列表同步；

(2)管理服务列表

用户需要添加自己所使用的网络服务才能让系统发挥效用；用户添加和删除网络服务、添加网络服务时，Web接口服务器会通知消息处理服务器尝试以用户提供的信息登入；如果登入成功，就将用户提供的信息保存到数据库，以便下次用户使用，用户需要提供自己的帐号和密码信息；

(3)管理帐号

用户在此管理自己在注册的时候提供的信息，除了用户名以外，其他任何信息都可修改，包括密码和名字；

(4)查询话题

用户需要分类检索自己的话题；在系统中，话题被分为我的话题、加入的话题和我回复的话题；用户在知道自己检索的目的时，可方便地从中寻找并查看话题；由于查询到的话题可能数量非常多，Web接口服务器支持分页查询，按照时间的先后顺序排列，新的信息排列在前面；

(5)查询帖子内容

通过Web接口服务器可直接查询数据库中的帖子，列出话题并列出话题的回复与回复的回复；帖子的内容即为用户和其联系人交流的内容；在提供父级帖子编号和根帖子编号的情况下，客户端非常容易地组合成树形结构并呈现给用户；

(6)发布话题与回复

Web接口服务器接收在客户端用户的要求下发布话题或者回复；用户需要提供帖子的相关信息，Web接口服务器不直接处理这些信息，而是转发到用户的消息处理服务器，让消息处理服务器进行写数据库和消息发送的工作；

(7)将状态推送到客户端

系统在一次长连接中推送多条信息给客户端，一次推送同时包含用户在线状态和服务状态、是否有新的消息；Web接口服务器在收到消息处理服务器的推送后，会将其缓存在用户内存单元的一个变量中，在Web接口服务器的长连接的循环中，一旦监测到变量变化，就会打断并返回给客户端；因为用户可能在不同地方登入，会拥有多个Session ID，所以，在推送前需要给每个不同Sesssion ID保留一个副本，将推送消息发送到用户所有的客户端上；

(8)服务新鲜事

将用户服务中带有社交网站元素的信息搬到客户端通常是主页的位置，让用户知道自己的联系人或者此服务的其他人在做什么而主动进行交流；这些信息由消息处理服务器定时从用户登入的服务中获取，Web接口服务器再定时从消息处理服务器获取并放入用户内存单元中；这些信息是由消息处理服务器的服务插件生成，包含状态标题、内容、联系人和反馈方式；反馈方式的作用是告诉客户端用户在点击这条状态后该如反馈；反馈方式包括：

①直接给状态的联系人产生新话题；

②复制状态内容作为新话题，再对其进行回帖；

③将联系人和状态标题及内容返回给Web接口服务器，再转发消息处理服务器，由消息处理服务器的服务插件处理行为。

4.根据权利要求1所述的基于云计算架构的网络服务聚合系统，其特征在于：

消息处理服务器是处理系统用户消息的主要部分，是真正实现消息收发的部分；Web接口服务器调用指定的消息处理服务器，消息处理服务器会将任务进行处理，调用服务插件，让服务插件实现消息最后的接收、发送功能；

服务插件启动后，从配置文件读取任务调度服务器地址，建立和数据库的连接，并加载加RMI服务到注册表；一开始启动时，只加载通用RMI服务；然后将此服务器在任务调度服务器上进行注册；结束后根据配置文件中插件的信息加载服务插件；

动态加载插件文件来实现插件的特性；插件都按照设定的接口和模式进行设计；插件加载模块在加载之前读取配置文件，配置文件包含了插件的系统名称、类名称、是否依赖联系人列表发送消息、默认优先级、插件所依赖的文件和登入服务时所需要提供的信息模版；插件系统名称可在系统内部识别此服务，是否依赖联系人决定了能否在联系人不在联系列表的情况下也能通过地址发送消息，默认优先级决定了用户在添加此服务作为联系人的联系方式的时候所赋予的优先级，插件依赖的文件就是插件运行所需要的其他文件；在加载插件的时候，依赖文件将和插件文件一起加载到消息处理服务器中；

由于Web接口服务器需要通过任务调度服务器来为用户分配消息处理服务器的分布式服务器资源，而且为了使整个分布式网络更加灵活，每台消息处理服务器上线后都要自动向任务调度服务器注册，使任务调度服务器知道消息处理服务器的存在，以便在Web接口服务器索取用户资源时将自己的资源给Web接口服务器使用。

5.根据权利要求4所述的基于云计算架构的网络服务聚合系统，其特征在于：

整个消息处理服务器提供通用RMI服务；Web消息服务器可从通用RMI服务获取可用服务列表、生成用户RMI服务；任务调度服务器从通用RMI获取此消息处理服务器的硬件资源消耗情况；因为不同的用户可能分散在不同服务器里，消息处理服务器之间在需要通讯时互相通讯；

可用服务列表由加载的配置文件而来，消息处理服务器直接将可用服务列表返回至询问的Web接口服务器，让Web接口服务器自行处理；

Web接口服务器被指令用户登入后，消息处理服务器会被要求为用户生成一个用户专有的RMI远程对象；消息处理服务器将此对象的RMI地址返回Web接口服务器，让Web接口服务器自行连接刚才生成的RMI远程对象；连接该用户的远程对象后Web接口服务器即可控制用户的服务资源；

任务调度服务器根据信息处理服务器的资源消耗情况分配用户资源的方式；任务调度服务器每隔一段时间更新消息处理服务器的硬件资源使用状况；提供给任务调度服务器的是一个性能指数，此信息从系统获取；

当系统在发帖的时候发现联系人有其他用户，就在用户内存单元寻找本机是否存在此用户，存在就说明用户和联系人中的用户在同一台服务器，可以直接以相应回推，不存在就要询问任务调度服务器此用户的消息处理服务器，将回推的消息转发到联系人用户的消息处理服务器，被转发的消息的服务器将按照不同流程将消息回推到Web接口服务器；如果在任务调度服务器找不到，将把这个帖子放入延迟发送的数据表中，在下次合适的时候发送；

用户在登入以后，Web接口服务器就会从被指定的消息处理服务器中获得用户RMI；

所有和该用户有关的远程调用都通过这个接口实现；包括如下步骤：

1)指定此用户RMI的所有人；

该过程由Web接口服务器调用，检查消息处理服务器是否已经存在关于此用户的用户内存单元；如果有，就使用已经存在的资源，如果没有，就为该用户创建资源；同时开启定时器定时从用户服务更新新鲜事，并且记录此Web接口服务器；

2)测试服务；

该函数只有在用户尝试添加新服务或者修改服务时由Web接口服务器调用，确认用户提供的信息是否能登入；这个函数将返回一个值，所以不是异步的，用户则需要等待此服务登入成功或者失败；

3)测试服务是否可通过用户提供的信息登入

Web接口服务器会把用户的服务和服务登入信息发送给用户的消息处理服务器；消息处理服务器将在加载好的服务插件上创建服务实例，每个用户的每个服务都有这样一个实例，根据不同的服务和帐号而实例不相同；加载完毕后，消息处理服务器会让每个加载好的服务插件实例登入服务；登入过程由服务插件对象控制，返回是否登入结果到Web接口服务器；

4)加载并登入用户服务；

Web接口服务器将发送用户服务列表和相关登入信息给指定的消息处理服务器列表，由消息处理服务器登入服务；Web消息处理服务器将异步为每个服务调用“测试服务是否可通过用户提供的信息登入”函数，而登入服务的函数到此结束，登入是否成功的消息由服务插件实例回推到Web接口服务器中；

5)销毁；

这个过程是在Web接口服务器的用户注销后所发生；考虑到用户在多个地方登入的可能，必须要在确认用户完全登出后才能销毁用户相关的资源；销毁资源的过程中，所有服务将离线，所有定时器关闭，最后从内存销毁所有此用户所使用的资源；

6)获取联系人优先联系服务；

获取联系人优先联系服务函数可直接被Web消息处理服务器调用、在回推联系人可使用服务和发帖的时候调用；这个过程中，消息处理服务器将从联系人列表中读取联系人的联系方式；按照联系方式的优先级在每个已经登入的用户服务中判断联系方式是否可用；将找到的第一个联系方式返回；

7)获取所有服务在线情况；

Web接口服务器调用此函数来获取目前服务的在线情况；消息处理服务器将直接查询用户服务的在线状态并返回；

8)广播用户状态；

一些服务具有广播用户状态的特性；广播用户状态函数由Web接口服务器调用，消息处理服务器将为用户所有服务都设定状态；如果用户的某些服务不支持，状态广播的行为将不被处理；或者通过用户状态实现分享之类广播的特性；

9)获取用户状态；

获取用户状态函数是由Web接口服务器调用；通常用户状态不保存在数据库中，而是直接从用户服务读取；消息处理服务器只读取第一个有状态的服务的状态发送返回给Web接口服务器；

10)获取用户服务新鲜事；

服务新鲜事由Web接口服务器获取；Web接口服务器获取的时候，用户新鲜事已经收集好并放在一个变量中；收集工作由新鲜事获取定时器完成；新鲜事获取定时器以固定的频率将用户服务的新鲜事放入变量中，等待Web接口服务器获取；

11)发帖；

作为整个系统的核心之一，发帖被消息处理服务器内部调用，或者被Web接口服务器调用；发帖的执行方是用户，或者是用户的服务中收到的消息；发帖需要提供数据库表的所有信息，作为话题帖子，还需要提供话题的联系人列表；发帖步骤进一步包括如下步骤：

11A)检查唯一编号是否已经在数据库存在；如果不存在进行下一步，如果存在直接退出发帖步骤；

11B)将信息格式化；

11C)如果为话题帖子，检查是否缺少用户为其中之一的联系人，如果是，将其补上；

11D)检查联系人列表的联系人和作者；一些情况下，用户或者联系人会直接使用服务的地址作为联系人字符串，而这个地址刚好是某个联系人的联系方式；这个过程将把使用服务地址联系人字符串改变为用户的联系人的联系人字符串；当用户的联系人发帖时将地址转换成联系人，让用户能直接识别；

11E)将帖子插入数据库；

11F)如果这个帖子为回复，更新父帖和根帖的数据库纪录中“回复人”和“最后回复时间”字段；

11G)读取已经插入数据库的帖子的编号；

11H)如果为话题帖子，将帖子联系人列表插入帖子联系人表；

11I)如果是回复，获取根帖的编号；如果是话题帖子，根帖编号为已经插入数据库的帖子的编号；

11J)通过获取的根帖子的编号从数据库获取根帖子的联系人列表；

11K)根据读取的帖子联系人列表，将消息转发给联系人；

12)转发消息；

转发消息函数不被Web接口服务器调用，是发帖时用来为指定联系人或用户转发消息时使用；转发消息需要作为远程方法调用来执行；转发消息过程具体进一步包括如下步骤：

12A)检查转发的联系人和作者是否为同一人，如果是，此消息将不被转发到这个联系人；

12B)检查转发的联系人是否为系统的另一个用户，并且此用户不在本地的消息处理服务器中；如果是，将从任务调度服务器读取此用户位置，并把此消息转发到用户位置进行处理；整个本服务器的转发过程结束；

12C)检查转发消息的联系人字符串的格式；

12D)如果为用户联系人字符串，将通过获取联系人优先联系服务方法获取最合适用户联系人联系方式，通过这个联系方式所对应的服务插件实例发送消息；

12E)如果为用户的某个服务插件的实例地址，直接通过这个实例发送；

12F)如果为系统用户，将消息回推到用户的Web接口服务器；

上述整个过程是否成功将被监视，如果不成功，这个消息将保存到数据库，在下次合适的时候发送；

13)执行服务命令；

命令由服务插件实例在服务新鲜事的时候生成，由服务插件实例识别并执行相关操作。

6.根据权利要求1所述的基于云计算架构的网络服务聚合系统，其特征在于：

任务调度服务器用以为用户分配消息处理服务器资源，同时索引用户消息处理服务器；任务处理服务器启动时注册自己的RMI，就等待其他服务器的连接；

消息处理服务器的注册过程将把此消息处理服务器的IP地址纪录在案，并且打开一个定时器定期从消息处理服务器获取性能指数，找出资源剩余最大的服务器并记录；期间将为每个服务器打开定时器检测消息处理服务器是否离线来更新消息处理服务器列表；

每次Web接口服务器获取用户消息处理服务器的时候，任务调度服务器将记录的消息处理服务器返回；

服务插件是用户服务收发的最终端，运行于消息处理服务器中；服务插件所提供的服务是任何具有消息交流特性的互联网服务，但是每个服务插件都要按照特定的接口编写，以便消息处理服务器支持；服务插件接口的函数包括：加载函数；登入函数；登出函数；发送消息函数；获取服务在线情况函数；获得用户状态函数；广播用户状态函数；搜索函数；重新加载函数；此函数为消息处理服务器为每个插件实例的一个定时器调用，提醒其更新自己的状态；添加联系人函数，与用户联系人列表中的联系方式绑定；删除联系人函数，与用户联系人列表中的联系方式绑定；判断地址是否可以发送函数，消息处理服务器据此判断是否通过此联系方式转发用户消息；获取新鲜事函数；执行服务命令函数；

虽然每个服务并不相同，但是针对同一类型的服务使用同一套处理方式；服务插件可自主搭配使用任何消息处理服务的函数来实现具有服务特色的插件；服务插件可自主处理服务命令，使得让新鲜事的功能变得更加灵活，服务插件自己订制新鲜事的指令，让用户选择后还将自行处理这些指令；

服务插件在接收到服务消息后，将其托管到消息处理服务器中处理消息；使用的方法和用户发帖时Web接口服务器所调用的是同一个函数；当服务插件以话题形式发布话题时，联系人则是接收此消息的系统用户；

7.根据权利要求1所述的基于云计算架构的网络服务聚合系统，其特征在于：

所述聚合系统包括保留服务基本特性的模块，包括：

获得用户状态单元，由Web接口服务器调用，通常用户状态不保存在数据库中，而是直接从用户服务读取；消息处理服务器只读取第一个有状态的服务的状态发送返回给Web接口服务器；

广播用户状态单元，一些服务具有显示用户状态的特性；所述广播用户状态单元由Web接口服务器调用，消息处理服务器将为用户所有服务都设定状态；如果用户的某些服务不支持，状态设定的行为将不被处理；

搜索单元，对于具有或者需要搜索特性才能完全操控的网络服务，使用所述搜索单元对服务进行搜索；搜索过程和结果由服务插件实例完成和生成，对于用户对结果的响应由服务插件实例识别并执行相关操作；

新鲜事获取定时器，服务新鲜事由Web接口服务器获取；Web接口服务器获取服务新鲜事时，用户新鲜事已经收集好并放在一个变量中；收集工作由新鲜事获取定时器完成，新鲜事获取定时器获取设定的频率将用户服务的新鲜事放入变量中，等待Web接口服务器获取；

执行服务命令单元，执行服务命令由服务插件实例在服务新鲜事的时候生成，由服务插件实例识别并执行相关操作。

8.一种权利要求1所述基于云计算架构的网络服务聚合系统的聚合方法，其特征在于，所述聚合方法包括如下步骤：

客户端按照运行的设备和Web接口进行通讯；

Web接口服务器给客户端提供信息，并且处理和消息无关的数据；在用户登入时，向任务调度服务器索取相对空闲的消息处理服务器地址，操控和监视消息处理服务器，并即时将状况反馈给客户端；

任务调度服务器负责监视消息处理服务器的资源消耗状态，并在Web接口服务器为登入用户索取相对空闲的消息处理服务器地址时返回，让Web接口服务器自行调用；在运行后，任务调度服务器定时对消息处理服务器更新资源使用情况；

消息处理服务器通过Web接口服务器与客户端连接，用户的网络服务在消息处理服务器进行登入、登出、状态管理、消息收发处理；消息处理服务器启动后自动向任务调度服务器注册，让任务调度服务器能监视其状态，同时等待Web接口服务器的调用；发生需要提醒用户的情况时，消息处理服务器会推送到Web接口服务器处理；

数据库服务器同时被Web接口服务器和消息处理服务器调用来记录各类信息。

9.根据权利要求8所述的聚合方法，其特征在于：

设置于客户端和消息处理服务器之间的Web接口服务器主要负责用户登入、分配服务器资源，将客户端的命令传给消息处理服务器，再将消息处理服务器的命令反馈给客户端，同时处理一些不需要消息处理服务器介入的事务；

加载过程中除了加载容器所必要的组件外，Web接口服务器还要加载配置文件，读取任务调度服务器的相关信息，与任务调度服务器建立连接，获取消息处理服务器集群的信息，再加载可被消息处理服务器集群支持的网络服务列表，以便在用户需要的时候及时反馈给用户；

用户需要登入后才能管理设定信息；用户登入后，服务器将相互处理一系列用户信息，读取用户服务列表，从任务调度服务器获得合适的消息处理服务器地址，使用获取到的服务器登入用户的服务，加载联系人列表，并监听从消息处理服务器反馈的信息；

用户自行输入用户名和密码以登入，用户名和密码在用户上次登入后就已经保存在客户端里；对此，在登入前，每次接收连接时，都要检查是否包含了有效的用户登入信息，如果有效就自动登入；

用户登入后，服务器将新建线程，进行登入后的操作；即用户在登入和进入自己的个人主页之时，服务器只检查用户名和密码的合法性；新建的线程完成以下六个步骤：

(1)从数据库服务器读取用户的联系人列表；

(2)从数据库服务器读取用户的服务列表；

(3)向任务调度服务器索取当前用户将要使用的消息处理服务器地址；

(4)连接获取的消息处理服务器地址；

(5)将获取的服务列表发送给消息处理服务器，让消息处理服务器登入这些服务；

(6)监听来自消息处理服务器的回推；

完成上述六个步骤后，服务列表、联系人列表连接后的消息处理服务器接口都将保存在Web接口服务器的一个处理用户系统信息的内存单元内；用户在登入后会产生大量信息，为每个用户专门分配内存单元，以便于管理；

用户在登入后，Web接口服务器将监听来自消息处理服务器的回推；回推的主要内容是消息处理服务器收到新的用户消息、用户的服务状态变更；Web消息处理服务器在接收到消息处理服务器的回推后，将进行处理，如果需要，打断和客户端更新状态的长连接，把更新的消息在一个请求中返回给客户端；

两种情况会使用户登出；一种是用户主动登出，客户端会按照用户的意愿联系Web接口服务器登出用户；另一种是用户长时间没有进行长连接；在用户登出后，Web接口服务器将通知消息处理服务器和任务调度服务器销毁与用户有关的资源，同时销毁Web接口服务器和用户有关的资源；其中和此用户有关的回推将不被监听；

所述Web接口服务器负责管理被用户所要求管理的用户信息；

(1)管理联系人列表

用户管理自己的联系人列表，除了添加和删除联系人以外，还可对联系人的联系方式进行排序；用户在管理联系人列表的时候，Web接口服务器还会和信息处理服务器进行交互；保证联系人列表和用户服务的联系人列表同步；

(2)管理服务列表

用户需要添加自己所使用的网络服务才能让系统发挥效用；用户添加和删除网络服务、添加网络服务时，Web接口服务器会通知消息处理服务器尝试以用户提供的信息登入；如果登入成功，就将用户提供的信息保存到数据库，以便下次用户使用，用户需要提供自己的帐号和密码信息；

(3)管理帐号

用户在此管理自己在注册的时候提供的信息，除了用户名以外，其他任何信息都可修改，包括密码和名字；

(4)查询话题

用户需要分类检索自己的话题；在系统中，话题被分为我的话题、加入的话题和我回复的话题；用户在知道自己检索的目的时，可方便地从中寻找并查看话题；由于查询到的话题可能数量非常多，Web接口服务器支持分页查询，按照时间的先后顺序排列，新的信息排列在前面；

(5)查询帖子内容

通过Web接口服务器可直接查询数据库中的帖子，列出话题并列出话题的回复与回复的回复；帖子的内容即为用户和其联系人交流的内容；在提供父级帖子编号和根帖子编号的情况下，客户端非常容易地组合成树形结构并呈现给用户；

(6)发布话题与回复

Web接口服务器接收在客户端用户的要求下发布话题或者回复；用户需要提供帖子的相关信息，Web接口服务器不直接处理这些信息，而是转发到用户的消息处理服务器，让消息处理服务器进行写数据库和消息发送的工作；

(7)将状态推送到客户端

系统在一次长连接中推送多条信息给客户端，一次推送同时包含用户在线状态和服务状态、是否有新的消息；Web接口服务器在收到消息处理服务器的推送后，会将其缓存在用户内存单元的一个变量中，在Web接口服务器的长连接的循环中，一旦监测到变量变化，就会打断并返回给客户端；因为用户可能在不同地方登入，会拥有多个Session ID，所以，在推送前需要给每个不同Sesssion ID保留一个副本，将推送消息发送到用户所有的客户端上；

(8)服务新鲜事

将用户服务中带有社交网站元素的信息搬到客户端通常是主页的位置，让用户知道自己的联系人或者此服务的其他人在做什么而主动进行交流；这些信息由消息处理服务器定时从用户登入的服务中获取，Web接口服务器再定时从消息处理服务器获取并放入用户内存单元中；这个特性没有使用推送机制，因为联系人状态的信息可能变化非常快；客户端需要主动向Web接口服务器索取这些信息；这些信息是由消息处理服务器的服务插件生成，包含状态标题、内容、联系人和反馈方式；反馈方式的作用是告诉客户端用户在点击这条状态后该如反馈；反馈方式包括：

①直接给状态的联系人产生新话题；

②复制状态内容作为新话题，再对其进行回帖；

③将联系人和状态标题及内容返回给Web接口服务器，再转发消息处理服务器，由消息处理服务器的服务插件处理行为。

10.根据权利要求8所述的聚合方法，其特征在于：

消息处理服务器是处理系统用户消息的主要部分，是真正实现消息收发的部分；Web接口服务器调用指定的消息处理服务器，消息处理服务器会将任务进行处理，调用服务插件，让服务插件实现消息最后的接收、发送功能；

服务插件启动后，从配置文件读取任务调度服务器地址，建立Hibernate和数据库的连接，并加载加RMI服务到注册表；一开始启动时，只加载通用RMI服务；然后将此服务器在任务调度服务器上进行注册；结束后根据配置文件中插件的信息加载服务插件；

动态加载插件文件来实现插件的特性；插件都按照设定的接口和模式进行设计；插件加载模块在加载之前读取配置文件，配置文件包含了插件的系统名称、类名称、是否依赖联系人列表发送消息、默认优先级、插件的文件所依赖的文件和登入服务时所需要提供的信息模版；插件系统名称可在系统内部识别此服务，是否依赖联系人决定了能否在联系人不在联系列表的情况下也能通过地址发送消息，默认优先级决定了用户在添加此服务作为联系人的联系方式的时候所赋予的优先级，插件依赖文件就是插件运行所需要的其他文件；在加载插件文件的时候，依赖项将和插件一起加载到消息处理服务器中；

由于Web接口服务器需要通过任务调度服务器来为用户分配消息处理服务器的分布式服务器资源，而且为了使整个分布式网络更加灵活，每台消息处理服务器上线后都要自动向任务调度服务器注册，使任务调度服务器知道消息处理服务器的存在，以便在Web接口服务器索取用户资源时将自己的资源给Web接口服务器使用；

整个消息处理服务器提供通用RMI服务；Web消息服务器可从通用RMI服务获取可用服务列表、生成用户RMI服务；任务调度服务器从通用RMI获取此消息处理服务器的硬件资源消耗情况；因为不同的用户可能分散在不同服务器里，消息处理服务器之间在需要通讯时互相通讯；

可用服务列表由加载的配置文件而来，消息处理服务器直接将可用服务列表返回至询问的Web接口服务器，让Web接口服务器自行处理；

Web接口服务器被指令用户登入后，消息处理服务器会被要求为用户生成一个用户专有的RMI远程对象；消息处理服务器将此对象的RMI地址返回Web接口服务器，让Web接口服务器自行连接刚才生成的RMI远程对象；连接该用户的远程对象后Web接口服务器即可控制用户的服务资源；

任务调度服务器根据信息处理服务器的资源消耗情况分配用户资源的方式；任务调度服务器每隔一段时间更新消息处理服务器的硬件资源使用状况；提供给任务调度服务器的是一个性能指数，此信息从系统获取；

当系统在发帖的时候发现联系人有其他用户，就在用户内存单元寻找本机是否存在此用户，存在就说明用户和联系人中的用户在同一台服务器，可以直接以相应回推，不存在就要询问任务调度服务器此用户的消息处理服务器，将回推的消息转发到联系人用户的消息处理服务器，被转发的消息的服务器将按照不同流程将消息回推到Web接口服务器；如果在任务调度服务器找不到，将把这个帖子放入延迟发送的数据表中，在下次合适的时候发送；

用户在登入以后，Web接口服务器就会从被指定的消息处理服务器中获得用户RMI；所有和该用户有关的远程调用都通过这个接口实现；包括如下步骤：

1)指定此用户RMI的所有人；

该过程由Web接口服务器调用，检查消息处理服务器是否已经存在关于此用户的用户内存单元；如果有，就使用已经存在的资源，如果没有，就为该用户创建资源；同时开启定时器定时从用户服务更新新鲜事，并且记录此Web接口服务器；

2)测试服务；

该函数只有在用户尝试添加新服务或者修改服务时由Web接口服务器调用，确认用户提供的信息是否能登入；这个函数将返回一个值，所以不是异步的，用户则需要等待此服务登入成功或者失败；

3)测试服务是否可通过用户提供的信息登入

Web接口服务器会把用户的服务和服务登入信息发送给用户的消息处理服务器；消息处理服务器将在加载好的服务插件上创建服务实例，每个用户的每个服务都有这样一个实例，根据不同的服务和帐号而实例不相同；加载完毕后，消息处理服务器会让每个加载好的服务插件实例登入服务；登入过程由服务插件对象控制，返回是否登入结果到Web接口服务器；

4)加载并登入用户服务；

Web接口服务器将发送用户服务列表和相关登入信息给指定的消息处理服务器列表，由消息处理服务器登入服务；Web消息处理服务器将异步为每个服务调用“测试服务是否可通过用户提供的信息登入”函数，而登入服务的函数到此结束，登入是否成功的消息由服务插件实例回推到Web接口服务器中；

5)销毁；

这个过程是在Web接口服务器的用户注销后所发生；考虑到用户在多个地方登入的可能，必须要在确认用户完全登出后才能销毁用户相关的资源；销毁资源的过程中，所有服务将离线，所有定时器关闭，最后从内存销毁所有此用户所使用的资源；

6)获取联系人优先联系服务；

获取联系人优先联系服务函数可直接被Web消息处理服务器调用、在回推联系人可使用服务和发帖的时候调用；这个过程中，消息处理服务器将从联系人列表中读取联系人的联系方式；按照联系方式的优先级在每个已经登入的用户服务中判断联系方式是否可用；将找到的第一个联系方式返回；

7)获取所有服务在线情况；

Web接口服务器调用此函数来获取目前服务的在线情况；消息处理服务器将直接查询用户服务的在线状态并返回；

8)广播用户状态；

一些服务具有广播用户状态的特性；广播用户状态函数由Web接口服务器调用，消息处理服务器将为用户所有服务都设定状态；如果用户的某些服务不支持，状态广播的行为将不被处理；或者通过用户状态实现分享之类广播的特性；

9)获取用户状态；

获取用户状态函数是由Web接口服务器调用；通常用户状态不保存在数据库中，而是直接从用户服务读取；消息处理服务器只读取第一个有状态的服务的状态发送返回给Web接口服务器；

10)获取用户服务新鲜事；

服务新鲜事由Web接口服务器获取；Web接口服务器获取的时候，用户新鲜事已经收集好并放在一个变量中；收集工作由新鲜事获取定时器完成；新鲜事获取定时器以固定的频率将用户服务的新鲜事放入变量中，等待Web接口服务器获取；

11)发帖；

作为整个系统的核心之一，发帖被消息处理服务器内部调用，或者被Web接口服务器调用；发帖的执行方是用户，或者是用户的服务中收到的消息；发帖需要提供数据库表的所有信息，作为话题帖子，还需要提供话题的联系人列表；发帖步骤进一步包括如下步骤：

11A)检查唯一编号是否已经在数据库存在；如果不存在进行下一步，如果存在直接退出发帖步骤；

11B)将信息格式化；

11C)如果为话题帖子，检查是否缺少用户为其中之一的联系人，如果是，将其补上；

11D)检查联系人列表的联系人和作者；一些情况下，用户或者联系人会直接使用服务的地址作为联系人字符串，而这个地址刚好是某个联系人的联系方式；这个过程将把使用服务地址联系人字符串改变为用户的联系人的联系人字符串；当用户的联系人发帖时将地址转换成联系人，让用户能直接识别；

11E)将帖子插入数据库；

11F)如果这个帖子为回复，更新父帖和根帖的数据库纪录中“回复人”和“最后回复时间”字段；

11G)读取已经插入数据库的帖子的编号；

11H)如果为话题帖子，将帖子联系人列表插入帖子联系人表；

11I)如果是回复，获取根帖的编号；如果是话题帖子，根帖编号为已经插入数据库的帖子的编号；

11J)通过获取的根帖子的编号从数据库获取根帖子的联系人列表；

11K)根据读取的帖子联系人列表，将消息转发给联系人；

12)转发消息；

转发消息函数不被Web接口服务器调用，是发帖时用来为指定联系人或用户转发消息时使用；转发消息需要作为远程方法调用来执行；转发消息过程具体进一步包括如下步骤：

12A)检查转发的联系人和作者是否为同一人，如果是，此消息将不被转发到这个联系人；

12B)检查转发的联系人是否为系统的另一个用户，并且此用户不在本地的消息处理服务器中；如果是，将从任务调度服务器读取此用户位置，并把此消息转发到用户位置进行处理；整个本服务器的转发过程结束；

12C)检查转发消息的联系人字符串的格式；

12D)如果为用户联系人字符串，将通过获取联系人优先联系服务方法获取最合适用户联系人联系方式，通过这个联系方式所对应的服务插件实例发送消息；

12E)如果为用户的某个服务插件的实例地址，直接通过这个实例发送；

12F)如果为系统用户，将消息回推到用户的Web接口服务器；

上述整个过程是否成功将被监视，如果不成功，这个消息将保存到数据库，在下次合适的时候发送；

13)执行服务命令；

命令由服务插件实例在服务新鲜事的时候生成，由服务插件实例识别并执行相关操作。