CN104378411A - 服务交换系统 - Google Patents

Abstract

服务交换系统即ServiceExchangeSystem，简称SES。SES是一个基于互联网的、统一的、与服务内容无关的服务发布和消费平台，主要特性如下：1. 基于互联网的开放平台；2. SES的三大功能是：统一的服务管理、统一的用户管理、统一的通信管理；3.SES本身不提供服务内容；4. 基于SES，服务者可将其服务发布到互联网，而无需自建运营系统；5. 基于SES的服务共享用户群，消费者可通过SES系统，精确获取所需要的服务。摘要附图说明（其中文字为必要的）：摘要附图左边展示了目前互联网服务的现状，右边展示了SES的主要目的，包括：1.共用同一运营系统；2.统一服务管理；3.统一的用户群；4.根据服务类型统一人机界面。

Description

服务交换系统

技术领域

本发明全称为服务交换系统，即Service Exchange System，缩写为SES，下文用SES表示。 

SES涉及一个基于互联网的服务发布和消费系统，服务提供者可通过各种软件或设备将服务内容发布到SES系统中；服务消费者亦可通过SES系统精确搜索并访问到所需要的服务。 

背景技术

首先阐述将SES作为一个整体来看的技术背景。 

各种软件或者智能设备若想将自己的服务发布到互联网上，以便消费者远程访问，必须有运营系统的支持，并提供相应的人机界面。目前，这些开发服务软件和设备的企业几乎都是自己搭建运营系统和开发人机界面。但实际上，这些运营系统和人机界面存在着大量的共同特性，尤其对于那些不同企业生产的同类产品。一般来说，运营系统都提供以下功能：服务管理，用户管理，通信管理，以及其他增值服务和客服支持；若是同类产品，由于产品的共性以及用户使用习惯的趋同性，其人机界面绝的功能和外观也是基本相似的。因此，提供一个统一的和服务无关的运营系统，并对同类型的服务提供统一的人机界面，既可减少企业对于产品的开发维护成本，也可提高消费者的消费体验；并可在此基础上，对服务质量和消费者身份进行统一有效的监管。图1（SES目的）的左边展示了目前互联网服务的现状以及不足，右边则展示了SES的目的和优点。 

下面分三个方面来阐释SES所包含的三大功能的技术背景，即：服务管理，用户管理，通信管理。 

服务管理

服务管理负责的主要功能是服务发布和服务搜索。

目前有关服务管理的主要技术是Web服务。Web服务是一种自包含、自解释、模块化的应用，能够被发布、定位，并且可以从Web上的任何位置进行调用。Web服务技术是完全基于标准协议的技术，其核心是服务发布、服务发现和服务绑定。W3C定义的Web服务协议主要包括SOAP、WSDL和UDDI。更多关于Web服务的内容请参考【1】【2】。 

在使用Web服务架构时，一般会遇到以下几个问题：首先，其协议标准比较复杂，掌握困难；其次，Web服务定义的是一组函数接口，虽然灵活性大，但开发人员基于它构建产品时仍需要做大量工作，甚至超出原有工作量；最重要的是，虽然定义了众多标准，但并不能解决或者是有利于解决服务被“智能”理解并被“智能”调用的问题，服务调用者仍然需要事先了解服务所能完成的功能（当然，从根本上来说，没有智能，只有约定）。虽然后来又提出了语义理解的改进方法（即WSDL-S，参考【3】），但WSDL+SOAP本质上是一个对接口精确描述的协议，语义的加入与WSDL的设计初衷并不一致。 

用户管理

用户管理是指对系统中所有的用户进行身份信息的管理，用户信息主要包括用户名，用户密码，以及其他与服务无关的用户信息。

目前，大多数网站都有自己的用户管理系统，使得消费者访问这些网站时，都不得不分别注册账户，导致账户数量繁多，使用极其不便。也有一些互联网企业提供公共的账户管理，但只限于人类用户管理，并且由于和企业所提供的服务紧密相关，无法适应其他类型的服务。 

另外，目前的用户管理系统在进行用户身份认证时，一般需要用户提供用户名和密码，而这些私有信息在网络上传输时，有可能被窃取，造成安全隐患。 

通信服务

SES的通信服务主要为了解决处于私有TCP/IP网络中的主机之间建立UDP和TCP连接的问题。

两种常用的NAT穿越技术是：STUN（参考【4】）和TURN（参考【5】和【6】）。STUN协议通过预测公网地址的方式进行点到点连接，但最大的问题是无法穿透对称型 NAT。另外有一个草案（参考【7】），但是其提出的方法中端口预测算法存在不足，会大大的降低穿透成功率。TURN协议则采用服务器中转的方式连接两个端点。但存在的主要问题是不够完善：对于UDP协议，TURN协议不支持端点一对一映射，因此需要进行消息解析，降低了消息中转的效率；对于TCP协议，则不支持端点多对多映射，因此服务器容量有限；同时，独立的中转服务器无法提供一个高效的通信服务，大大降低了端点之间的通信效率，例如即使是相隔很近的两个端点，也需要通过远处的TURN服务器进行消息中转。 

  

发明内容

SES是一个在现有各种技术的基础之上进行改进、完善和创新，设计的一个统一的、与服务无关的、互联网服务发布和消费平台。SES包括三大功能：服务管理、用户管理、通信管理。 

SES的引入有利于互联网产业的纵向分工，使得各种提供终端产品和服务的企业能够集中精力在其本职工作之上。基于SES平台，用户可以方便地开发出各种网络产品，而无需关心运营系统的开发和搭建，节约了研发、运营成本，降低了产品开发难度，加快了产品上市速度。 

从技术上来说，SES的解决的问题包括： 

1.         提供一个通用的，易于使用的服务管理系统，包括服务发布、服务定位、服务消费；并针对智能服务提供支持；

2.         提供统一的用户注册、注销、查询和身份认证机制；

3.         提供完整、安全、可扩展的通信服务，解决内网设备互联的问题。

下面就三个方面分别说明采用的技术方案以及解决的问题。 

服务管理

为了实现一套易于使用和灵活的服务管理系统，SES对服务的定义进行了层次上的提升。SES中使用一个服务接口ID（interface）代表一个完整的产品所拥有的全部功能，而无需定义一系列具体的函数。例如SES直接使用“冰箱”代表冰箱所能提供的全部功能，而不是像Web服务一样，定义一组函数去描述冰箱所能完成的具体功能。本质上，这仍然是一种约定，只不过这种约定包含了更多的内容，或者说包含了对人类语言的理解。服务接口ID的引入大大简化了协议栈（参见图2 SES协议栈），以及其他服务管理工作，包括服务发布消息的定义，数据库的设计等。另外，SES可通过扩充服务接口ID，并允许开发人员自定义新的服务接口ID，不断增强系统的基础服务能力，形成一个大数据服务平台。

除了引入服务接口ID外，SES的另一个特点是，设计了一种模糊消费的模式，对于服务所能提供的数据类型进行了统一的定义，可以让消费者无需了解服务者的调用方式的前提下也能获取自己所需要的服务。例如，消费者需要一张关于“衣服”的图片，那么系统将自动进行服务搜索，并自动的调用服务，找出一张最为匹配的图片返回给消费者；与此相对应的是，通过各种搜索网站得到的是一系列的图片网站，仍然需要用户做大量的选择工作，才能找到所需的图片。 

SES的服务管理和Web服务相比，SES协议栈相对简单，开发人员更容易理解和使用；而将服务定义为产品，实现和管理都更加简单；最后，通过标准化数据类型，SES引入了模糊消费模式，为“智能”调用提供了一种可行方案。 

用户管理

SES系统提出了一套独立的用户管理系统。和其他用户管理系统不同的是：SES的用户管理是和服务无关的；SES中的用户是逻辑节点，代表一个数据的终结点或者发起点，可能是一个人类用户，也可能是一个设备；一个用户在实际活动过程中，可能是消费者，也可能是服务者。由于和服务无关，SES的用户管理仅仅保存了用户的固有信息，其中最重要的是用户名、密码和地址；若表现为服务者，则还包括若干服务信息。

同时，SES设计了一套Key-Token身份认证机制，Key-Token的最大特点是所有通信过程中，用户最为敏感的password从不出现，这样就绝对避免了密码在通信过程中被窃取的可能性。另外，在接收到错误密码时，Key-Token机制非常容易识别是合法用户忘记密码，还是黑客在进行暴力破密，从而采取相应的措施。同时Key-Token认证支持公共认证、友好认证、私有认证三种模式，可以灵活适应于各种情况。 

SES的用户管理的特点是服务无关性，以及所提供的安全及灵活的Key-Token认证机制。 

通信服务

SES中的通信服务器综合了SUTN协议TURN协议的优点，并对其进行了改进，实现了一个新型的、完整的通信服务机制。对于P2P通信，SES的通信服务支持对称型NAT的穿透；对于中转服务，无论是UDP还是TCP协议，均支持一对一映射和多对多映射方式。在多对多的映射模式下，多个服务者可以共享一个IP地址和端口，大大的节约了公网IP资源（参考图3 通信中转服务的多对多映射模式）。

另外，在SES中，通信服务器可以看做一个提供了通信服务的服务者，其具体实现完全符合SES用户管理和服务发布的规范要求。因此，SES的通信服务器既可作为一个完全独立的设备提供服务，也可以地接入到SES系统中协同工作。接入到SES系统中时，系统可以根据服务者所处的地域分布和网络类型，灵活的分配通信服务器（一般采用地域上距离最近，网络类型相同的分配原则），大大降低了消息中转所带来的通信延迟和抖动等负面影响。 

SES的通信服务提供了一套完整的端点之间的通信机制，既支持P2P连接，也支持消息中转，并且考虑了网络的地理分布情况，大大提高了通信效率。 

附图说明 

以下为附图说明，其中的文字均为必要的： 

图1是SES目的；

图2是SES协议栈；

图3是通信中转服务的多对多映射模式；

图4展示了SES集群环境，图中的箭头显示的是服务信令和数据的方向； 

图5是SES工作流程图，为了描述方便，本图所描述的是主要的工作流程； 

图6 是MFMP消息示例；

图7 是服务发布时序图；

图8 是获取服务列表时序图；

图9是获取中转通信服务时序图；

图10 是获取点对点通信服务时序图；

图11 是Key-Token认证时序图； 

图12 是SES Framework架构。

 

具体实施方式

(一) SES系统架构 

SES系统的集群环境如图4 SES集群环境所示，图中的箭头显示的是服务信令和数据的方向。SES系统主要包括以下网元：

1.         服务注册者（Register）：运行于公网服务器上，负责服务注册（即服务发布），服务定位（即服务搜索），以及用户管理，包括用户注册，身份认证等；

2.         服务提供者（Servicer）：包括各种服务软件或者设备，负责提供具体的服务内容，例如监控服务、打印服务、存储服务等；

3.         服务消费者（Consumer）：消费者使用浏览器或者App，搜索并访问服务提供者；

4.         Web服务器（WebServer）：运行于公网服务器上，为使用浏览器的消费者提供服务搜索界面，协助消费者搜索并跳转到自己所需要的服务；

5.         通信交换机（Switcher）：运行于公网服务器上，协助提供服务者和消费者之间的通信连接；

6.         数据库（Database）：记录用户信息和服务状态的数据库。

SES系统的基本工作原理如图5 SES工作流程图所示。为了描述方便，本图所描述的是主要的工作流程。在实际工作过程中、以及不同配置下，工作流程会略有不同，例如Switcher可以向Register注册服务，同时，Servicer在获取通信服务之前必须先向Register注册，以获取最合适的Switcher服务器地址。SES工作流程的主要包括： 

1.      申请通信服务：若Servicer处于内网之中，并希望将服务发布到外网，则Servicer在注册服务之前，可以向Switcher申请通信中转服务，通信中转服务负责透明传输Consumer和Servicer的消息：

a)        向Switcher提交通信中转服务申请；申请时需提交服务者的信息（包括服务ID，密码等），申请的通信类型（例如TCP或UDP），以及其他信息（如申请的端口数量等）；

b)        若Servicer提交的申请合格，则返回一对服务端口给Servicer，这对服务端口中的一个对应于Servicer，另一个对应于Consumer；

2.      服务发布：Servicer将服务发布到Register，Register将发布的服务记录到数据库中：

a)        Servicer将服务信息发送给Register；

b)        Register检查服务信息，若通过检查，则将信息保存至数据库中；

c)        Register将结果返回给Servicer，结果有两种：成功或失败。若成功，可返回一个消费者认证秘钥，此秘钥在今后确认Consumer身份时将被使用；

3.      获取服务列表：若Consumer使用浏览器，则通过WebServer获取服务列表（如图中3.a所示）；若Consumer使用App访问服务，则通过Register获取服务列表（如图中3.b所示）：

a)        Consumer向WebServer或Register请求服务列表，请求中可以包括若干关键字，以便定位自己所需要的服务；

b)        WebServer或Register在数据库中搜索到匹配的服务；

c)        WebServer或Register将服务列表结果返回给Consumer；服务列表包括了每项服务必要的信息，包括服务ID，服务描述，服务地址等；

4.      服务消费：Consumer通过服务列表中提供的服务地址等信息，连接到Servicer，进行服务消费；根据不同的网络情况，Consumer可能是和Servicer进行P2P直接连接，也可能是通过Switcher进行消息中转：

a)        Consumer和Servicer进行服务消费；

5.      用户认证：服务消费过程中，Servicer可以要求Consumer提供身份证书。此时Consumer必须向认证机构（可能是Register，如图中5.a所示；也可能是Servicer，如图中5.b所示）请求用户认证：

a)        Consumer向认证机构提供用户ID，密码等信息；

b)        认证机构对用户信息进行认证，若通过认证，则返回身份证书（token）。

  

(二) 协议栈

如图2 SES协议栈所示，SES中各网元之间的通信均采用统一的协议：Message Function Mapping Protocol（MFMP）。

MFMP协议分为三层： 

1.         通信层：负责消息的可靠传输，保证消息从发送端可靠并有序的到达接收端，目前采用的是标准的TCPIP协议；当采用TCP协议时，能保证数据能有序并可靠到达接收端，但由于是流式传输，无法区分数据包的起始；当采用UDP协议时，可保证数据包的起始，但无法保证数据包的有序、可靠到达；

2.         系统层：即SES中所有网元通信需遵循的协议头，用来规范以及统一地址信息、消息参数，数据长度等；SES系统层兼容HTTP协议；

3.         应用层：与各个网元功能相关的内容，不同类型的服务者在此层中的定义各不相同，对于Servicer而言，其应用层的详细定义需参考其所提供的服务类型描述文档。

SES采用HTTP协议作为系统层协议，一个主要原因是考虑使用浏览器作为消费者客户端的情形。一般的HTTP协议主要以文本形式定义，人工可直接阅读，扩展性好；但由于数据较长，传输效率低；对于效率要求高的情形，则建议采用HTML5规范提出的WebSocket长连接特性。 

完整的HTTP命令包括：HTTP协议头 + 消息实体。 

例如，一条服务注册的形式如图6 MFMP消息示例。 

HTTP协议头由四部分组成，即命令 + URI + HTTP版本信息 + Tag。具体说明如下： 

1.        SES支持以下几种命令：

a)        GET（获取目标的属性）；

b)        POST（增加或修改目标的属性）；

c)        DELETE（删除目标）；

2.        完整的URI包括三部分：系统标识(ses) + 接口名(interface) +目标名(target) + 参数（params）：

a)        系统标识固定为ses；

b)        接口名(interface)定义了网元所提供的服务。对于switcher和register而言，其提供的服务是固定的，因此其接口名分别固定为switcher和register。不同servicer可以支持不同的接口，不同接口中可以定义相同的目标（target）而并不会引起冲突。接口名也可以看做是产品名称，一个产品所拥有的能力即可看做服务。因此，接口名一般来说是一个名词；

c)        目标 (target)表示此命令的操作对象。在SES中，一条消息均被视作一个服务请求，而一个服务均被视作包含若干可提供服务的对象的集合；每个服务请求均对应于某个服务对象；

d)        参数（params）是为了更加明确定义此操作的行为，参数有以下形式：……；

3.        版本信息目前定为HTTP/1.1；

4.        Tag指的是HTTP消息头中的各种标签，提供了一系列附加的信息，常用的如：Content-Length：表示消息实体的数据字节数；Content-Type：表示消息实体的数据类型。详细的Tag信息请参考HTTP协议标准。

消息实体一般XML格式或二进制格式或其他自定义格式，具体格式是由应用层自行定义的。若为xml格式，则由三部分组成： 

1.        根标签：SES定义三种根标签，分别对应三种uri的网元类别，即register，switcher，servicer；

2.        根属性：根属性定义了根标签的附加信息，目前没有用到；

3.        内容：内容即消息具体数据部分，不同命令所包含的内容各不相同。

消息实体的具体定义属于MFMP协议应用层范畴，不同服务对应的消息实体各不相同。 

对于如何选择参数还是消息实体，SES系统有如下约定： 

1.        若参数长度较小（<128字节），且属于标识性质，则优先使用参数形式；

2.        若参数较长（>=128字节），则使用消息实体；

3.        列表参数使用消息实体；

4.        参数不同对应不同的函数，消息实体和函数无关。

  

(三) 服务发布过程

服务发布是指Servicer将服务信息通过Register注册到SES系统中上，以便消费者能够通过SES运营系统搜索并消费此服务。所谓Servicer发布服务到Register，实际上就是将服务信息，包括服务ID、密码、服务描述、服务地址等信息提交给Register。服务发布之前，若服务者拥有公网IP地址，可选择其公网地址直接作为服务地址，而无需申请通信服务；若无公网IP地址，则可向Switcher申请通信服务，申请成功后，将获得一个公网的IP地址和端口，此地址即可作为服务地址；消费者连接服务时，也可先尝试P2P连接，当P2P连接失败时，才通过Switcher中转。

服务发布过程主要涉及Servicer和Register之间的消息交互。服务发布相关的主要过程如图7 服务发布时序图所示。具体说明如下： 

1.        身份认证：验证Servicer的身份合法性，采用SES Key-Token认证方式，关于Key-Token认证的详细信息请参考用户认证流程。进行身份认证后，Servicer将获得一个表示自己身份的通信令牌servicer_token，此后Servicer向Register以及Switcher发送的所有消息均需要携带此servicer_token，并且可对消息实体进行加密。采用身份认证的Servicer可以有效防止身份冒充，同时有利于保护Consumer的身份合法性检查；

2.        发送服务发布消息（publish）：Servicer将服务信息发送给Register；

3.        服务发布应答：Register检查发布消息的合法性，包括消息中的token以及密码是否匹配等，同一服务不允许重复发布等。最后将检查结果返回给Servicer，若成功，则将此服务信息记录到SES数据库中，并根据需要返回一个consumer_token_food，consumer_token_food的作用请参考用户认证流程；否则返回失败消息给Servicer；

4.        发送服务握手消息（fresh）：服务发布成功后，Servicer需要定时向Register发送握手消息，目前的握手间隔是30s；若一定时间内没有收到握手消息，Register将取消此服务；

5.        服务握手应答：Register检查握手消息的合法性，若正确，则更新计数；同时返回应答；

6.        发送服务更新消息（update）：若Servicer的服务信息变化，则可发送服务更新消息给Register；最常见的是服务地址发生变化；（注意：服务ID变化不适应于此消息；）

7.        服务更新应答：Register处理服务更新消息，此过程类似于服务发布消息的处理，唯一不同的是，服务更新消息允许多次发送，而服务发布消息只允许发送一次；

8.        发送服务取消消息（unpublish）：希望撤销服务时，Servicer可向Register发送此消息；

9.        服务取消应答：Register检查服务取消消息的合法性，若正确，则删除SES数据库中此服务的记录，并返回结果。

  

(四) 获取服务列表过程

获取服务列表过程即服务定位过程。根据Consumer使用的客户端是浏览器还是App，Consumer可通过WebServer或者Register获取服务列表；收到服务列表后，若是App则可以“智能”地选择服务列表中的某一项服务进行消费，若是浏览器则可以让人类消费者自主选择服务进行消费。

通过App方式向Register获取服务列表的过程如图8获取服务列表时序图。具体说明如下： 

1.        请求服务列表：请求服务列表由App发出，消息中可以携带skip参数表示忽略前面多少条记录，以及num参数表示获取的条数，Register检测到此参数后，将从第skip+1条服务记录开始统计。这适合处理服务列表数据量较大的情形；

2.        返回服务列表：Register在系统中搜索到匹配的服务后，生成一个服务列表返回给Consumer。Register需要优化搜索算法，尽快响应Consumer。因此，某些重要的数据需要保存在内存中，避免频繁访问数据库。

通过浏览器方式向WebServer获取服务列表过程类似，所不同的是，浏览器发出的不是请求服务列表消息，而是请求一个页面，WebServer搜索到服务列表后，生成页面并返回给浏览器。 

  

(五) 获取通信服务过程

通信交换机可以协助两个端点进行消息通信，目前通信交换机可以支持TCP、UDP的消息交互。

通信交换机提供两种通信方式，一是中转方式，另一种是点对点方式（P2P）。中转方式适合所有类型的NAT机制；而点对点方式适合所有锥型的NAT以及可预测端口对称型NAT（换句话说，点对点方式不适合于随机端口映射对称型NAT）。 

当Servicer处于内网，但仍然希望能够被外网的用户访问，那么则可以借助于通信交换机达到目的。Consumer可以选择哪种方式连接Servicer，若客户端为浏览器，由于浏览器无法控制端口，只能适应于中转方式，而对于客户端为App方式，则建议优先使用P2P连接，当P2P连接失败时才使用中转方式。无论是请求中转通信，还是请求P2P连接时，首先Servicer需要和Switcher建立一个持久连接s2s连接（Servicer to Switcher），s2s连接的作用可以看做Servicer和Switcher之间的服务请求通道（或称为信令通道）。在Servicer整个活动过程中，s2s通道必须保持连接。 

请求中转通信服务的工作流程如图9获取中转通信服务时序图。具体说明如下： 

1.        通信服务请求消息：Servicer向Switcher请求通信服务，提交必要的参数，包括服务名称，服务者令牌，申请的端口数量和通信类型等；

2.        服务地址：Switcher检查通信服务请求，检查通过后申请一对端口分别作为Servicer和Consumer的监听端口；此检查过程需要通过Register协助，包括servicer_token的合法性、申请的端口数量、带宽限制等等；

3.        消费者连接事件：当Consumer连接Switcher上的监听端口时，Switcher通知Servicer；此处对于TCP和UDP协议的处理有所不同，对于TCP，系统将自动创建一个新的TCP连接，并可收到明确的连接事件；对于UDP，连接事件实际上由Consumer发送消息而触发，这种情况下，Servicer发送的消息必须携带Consumer的IP地址和端口，而Consumer发送的消息必须携带Servicer的名称；

4.        绑定端口消息：同样，此处对于TCP和UDP协议的处理有所不同；对于TCP，Servicer将连接Switcher对应的监听端口，创建一个新的连接，并通过此连接发送绑定消息，表示此连接与某个Consumer绑定；对于UDP，则无需绑定端口，但是在发送消息的参数中必须携带Consumer的IP地址和端口；

5.        应答绑定端口消息：对于TCP才有此应答，对于UDP无此过程；

6.        此后，Switcher将Servicer和Consumer之间的消息互相透传。

  

请求P2P连接的主要流程如图10获取点对点通信服务时序图。具体说明如下：

1.        端口测试请求及应答1：在Servicer初始化阶段，向Switcher发起三次连续的TCP连接（或UDP消息），Switcher探测远端的地址（包括IP地址和端口）并将其返回给Servicer；Servicer利用三个地址值判断自己是否处于内网，以及NAT（网络地址转换）的端口映射步长（step）；最佳测试方法是Servicer使用同一端口，对三个不同的Switcher发起测试请求，若返回的端口相同，则可认为step为0（对应锥形路由器）；若返回的端口为等差序列，也可计算出相应的step（对应于步长固定的对称型路由器）；否则无法计算出step（对应于随机映射型路由器），这种类型的NAT无法穿透；

2.        端口测试请求及应答2：当Consumer请求P2P连接Servicer时，同样需要先测试自己所对应的NAT类型，测试方法和上述类似；由于需要进行一系列处理，此过程只适合于客户端为App的情形；

3.        请求连接通知(预测端口x)：Consumer向相应的Switcher（即与Servicer建立s2s连接的Swicher）发送P2P请求，Switcher通过s2s连接将此请求转发给Servicer；此步骤的一个关键是，Consumer需要预测一个端口x，这个端口将是此后P2P连接时Consumer端对应的NAT端口；预测方法是，将当前NAT端口（上一以步骤获取）加上n*step（n=1,2,3……）；另外，Consumer连接至Switcher后，需保持这个连接，以便随后Switcher发送邀请连接通知给Consumer；

4.        端口测试请求及应答3：当Servicer收到请求连接通知后，需尽快向Switcher发起一个端口测试请求，获得当前NAT映射端口t0；（假设本地端口为p0；）

5.        邀请连接(目标端口x)：获得t0端口后，需尽快向Consumer发起一个邀请连接，目标端口为x；本地端口使用p0端口；

6.        端口测试请求及应答4：随后尽快再次向Switcher测试NAT映射端口（最好使用不同的Switcher），本地端口继续使用p0端口；

7.        邀请连接通知(预测端口 y)：上述的三个步骤是不可分离的连续步骤， 目的是获得Servicer端的预测端口y，端口y将是此后P2P连接时Servicer端对应的NAT端口；端口y的测试方式是，将当前t0端口加上n*step（n=1,2,3……）；获得预测端口y后，Servicer向Switcher发起邀请连接通知，Switcher将此通知转发给Consumer；Consumer收到此消息后，可断开与Switcher的连接；

8.        抢占连接(目标端口y)：Consumer使用向Servicer对应的NAT端口y发起连续多次尝试连接，当本Consumer端的NAT端口刚好等于此前的预测端口x时，P2P连接将成功，（不难获知：此时Servicer端的消息是端口y ----> 端口x，而Consumer端的消息是端口x ----> 端口y）；

9.        正常通信：P2P连接后，Consumer和Servicer即可正常通信。

  

(六) 用户认证过程

用户认证是指用户向认证机构进行资格认证，并获得一个身份证明（token）。SES中的用户认证主要涉及以下几个场面：Consumer向Register或Servicer认证；Servicer向Register认证；Switcher向Register认证。

SES中，所有认证过程的原理是一样的，均采用一种称为Key-Token的认证方式。Key-Token的最大特点是所有通信过程中，用户最为敏感的password从不出现，这样就绝对避免了密码在通信过程中被窃取的可能性。另外，Key-Token机制非常容易识别和防止暴力破密。 

Key-Token认证过程有两个角色：认证机构和认证者。在SES系统中，认证机构可能是Register或者Servicer： 

1.        向Register请求认证包括Servicer,Switcher和Consumer；

2.        向Servicer认证的只有Consumer。

Key-Token认证流程如图11 Key-Token认证时序图。具体说明如下： 

1.        请求baby_key：认证者向认证机构请求一个随机的字符串；请求中需包含自己的名称，例如Servicer名称或者Consumer名称；

2.        返回baby_key：认证机构随机生成一个字符串，返回给认证者；

3.        发送adult_key并请求token：认证者使用自己的password作为key_food对baby_key进行有损加密，生成adult_key，即baby_key + password ~ adult_key。由于丢失部分信息，此adult_key是无法还原成baby_key的；然后将此adult_key以及请求token的其他信息，包括认证者的通信秘钥comkey，请求token的有效期expire，有效次数count等发送给认证机构，所有这些信息都使用password进行加密；

4.        返回token：认证机构验证adult_key是否正确，认证机构将adult_key与自己计算的结果进行比较，验证认证者的合法性，若合法，则将若干信息（包括comkey、expire、count、认证者的地址信息等）按一定格式编排，并使用一个秘钥token_food生成token，返回给认证者；此后认证者可使用此token与认证机构或者第三方进行秘密通信；若希望与第三方通信，则第三方需提前获取token_food。

Key-Token认证的基本思想是： 

1.        在算式（A + B）% C = D中，假设B、C、D已知，无法精确计算出A，只能得到一个A可能的取值序列；

2.        假设认证者使用A可能的取值序列中的值进行认证，试图猜测密码，基本可认为此认证者为蓄意入侵。

  

(七) 服务消费过程

SES需要解决的一个重要问题就是：如何让这些服务高效、精确的传递到所需要的消费者手中。由于关系紧密，这里不得不介绍获取单个服务者的过程；注意这里是指获取单个服务者，而不是获取一个服务者列表。

根据服务消费的一般情况，SES提供了三种服务消费模式： 

1.        完全指定消费：即向特定的服务者请求特定的服务，比如去某个熟悉的商店买衣服。这种情况下，消费者对服务者很了解，且自己的需要完全明确；即使不知道服务者的地址，也可通过服务注册者获得；

2.        部分指定消费：即在不指定服务者情况下请求特定服务，好比在众多商店中买衣服。这种情况下，消费者不在乎服务者是谁，但对自己的需要是明确的。服务注册者在这里的作用是，找出最为匹配的服务者，提供给消费者使用；

3.        模糊消费：即不指定服务者也没有明确自己所需要的服务，好比在无目的地逛商店。这种情况下，消费者不在乎服务者是谁，也不确定自己需要什么。但一般来说，消费者的个人喜好是相对固定的，因此，可以设想，服务注册者可以根据消费者的喜好，找出最匹配的服务者；然后此服务者也需要根据消费者喜好，找出最匹配的服务，提供给消费者。

三种服务消费模式的区别主要是在服务注册者和服务者的具体行为上，其服务消费的基本流程是相似的：都是从服务注册者或者WebServer获取到服务者地址，然后直接和服务者进行消费。服务消费过程的差异主要体现在不同服务具体实现上。 

在实际消费过程中，一次消费可能会涉及到三种消费模式。比如一开始是模糊消费，此时消费者尚不确定自己需要什么；当想到自己需要什么时，则进入部分指定消费模式；最后很可能选择某个服务者提供服务，即进入完全指定消费模式。 

虽然基本流程相似，但是在实现过程中，三种模式有着明显的区别。 

1.        完全指定消费：完全指定消费情况最简单，Consumer向Register或WebServer获取明确的服务者的服务地址后，直接访问此服务者的某个指定服务。这种模式下，请求和返回的数据类型都是明确的，无需任何“智能”计算； 

2.        部分指定消费：部分指定消费情况下，Consumer提供需要的服务数据类型，以及自己感兴趣的一系列关键字，通过Register（WebServer方式不支持此消费模式）自动计算最匹配的服务地址，然后向此服务者请求服务；由于指定了服务数据类型，服务者需要根据数据类型以及关键字计算最匹配的服务，并返回服务数据。此模式涉及到两种“智能”计算；

3.        模糊消费：模糊消费情况下，Consumer只提供自己感兴趣的一系列关键字，通过Register（WebServer方式不支持此消费模式）计算最匹配的服务者，然后向此服务者请求服务；由于没有指定服务数据类型，服务者需要根据关键字计算到最匹配的服务，并返回服务数据。同样，Consumer端由于实现不知道将返回何种数据类型，需要根据返回类型自动呈现服务数据。此模式涉及到三种“智能”计算。

  

(八) 服务监管过程

服务监管包括两个方面：

1.        功能完备：发布某一标准接口的服务者，必须通过接口的功能完备性测试；接口测试由测试模块自动完成；

2.        服务质量：由消费者评分；Register提供接口接受消费者的评分。

功能完备性测试由一个称为Robot Consumer的App自动完成。对于每一个标准接口，SES均提供一个Robot Consumer软件，由于标准接口是实现统一定义的，因此Robot Consumer软件完全可以对接口进行遍历访问。若某一操作的输出数据是另一操作的输入数据，并且输出数据类型为列表，则一般只获取列表中的一项作为输入数据进行测试。 

功能完备性测试的大致过程如下： 

1.        设置待测试的Servicer访问地址；（一个Servicer一般只支持一个interface；）

2.        选取一个可确定参数的target作为当前target；

3.        使用当前target以及必要的参数，发起一个服务请求；（注意：若服务应答是列表，则只需请求一项）；

4.        获得服务应答，判断应答正确性，给出提示；

5.        若服务应答是其他target所需参数，遍历测试这些target； 

6.        选取下一个可确定参数的target作为当前target，若存在则转至3；

7.        结束。

  

服务质量的监管是通过Register提供的评分接口进行的，只有通过用户认证的消费者才能对服务者进行评分。评分过程是一个完全独立的过程（因此没有出现在图5SES工作流程图中），即与服务管理、用户管理、通信管理均没有直接的交互关系，但是评分的结果将会影响到Register的“智能”计算结果。

  

(九) 数据库

数据库最重要的表是SESUser，记录了所有用户信息。这里的用户是对服务者和消费者的统称，一个用户在实际中既可以成为服务者，也可以成为消费者，还可以同时作为服务者和消费者出现。

SESUser表字段定义如下： 

1.        服务提供者(organizer)：类型nvarchar；最大128位；可作为服务提供者的描述信息；单值；

2.        服务名称(name)：类型nvarchar；最大128位；单值；

3.        服务密码(password)：类型varchar；最大128位；为”#”，或者为空。若为”#”，则表示需要用户提供密码才能连接服务；

4.        服务地址(address)：类型varchar；最大128位；目前有三种地址local:ip-port; switch:ip-port; global:ip-port；多值；

5.        服务接口(interface)：类型nvarchar；最大128位；对应的服务类型，可为任意字符串，例如：immecom（即时通信）；mediaserver（媒体中心）；remotemon（远程监控）；remotedesk（远程桌面）；location（位置服务）；服务类型分为系统服务和用户自定义服务，凡是用户自定义服务，其interface需要以c-开头；多值；

6.        服务描述(description)：类型nvarchar；最大1024位；可提供服务描述信息或者关键字信息；

7.        服务固有属性(properties)：类型varchar；最大1024位；由WEBServer负责写；目前包括regist，regdate，email；注册标记(regist)表示是否注册用户，注册用户可永久占用服务名称，下次登陆时服务名称和服务密码必须和用户名称和用户密码完全一致方可登陆成功；regdate指用户通过网站注册的时间日期；多值；

8.        服务状态(status)：类型varchar；最大1024位；由Register负责写；目前包括visuable，logintime，needlogin。可见标记(visuable)：标记为可见的服务才能被用户搜索并显示出来；例如visuable:yes；登陆时间(logintime)：年月日时分秒；为空表示没有登陆；例如logintime:2012/8/25 12:00:00。needlogin表示是否需要Register支持友好认证；多值；

9.        服务数据类型（datatype）：类型nvarchar；最大128位；对应的服务数据类型，目前包括string（字符串），image（图片）；video（视频）；text（文本）；audio（音乐）；medialist（媒体列表）等等；服务数据类型为SES系统统一定义，消费者客户端软件根据此类型展示服务返回的数据；多值。

  

(十) SESSDK

为了简化Servicer的开发工作，SES系统提供了服务软件开发包SES Software Development Kit（SESSDK）。SESSDK包含了两个主要模块：SES Framework，以及Servicer App。

SES Framework实现了服务中间层，完成大量和SES系统相关的工作，包括请求通信服务、服务发布、用户认证、协议层消息解析、消息分发等等；并提供一系列常用函数，例如字符串处理，xml数据处理等，供开发人员实用。基于SES Framework，Servicer的软件开发者只需要完成其核心业务功能，极大的简化了其开发任务。另一方面，SES Framework也可用来编写消费端App。 

SES Framework的架构如图12 SES Framework架构。 

Servicer App提供了一个基于SES Framework编写的服务软件。这个Servicer App既是一个编写服务软件的示例程序，也是一个工具。 

作为一个示例程序，Servicer App展示了编写一个服务软件的步骤： 

1.        初始化SES引擎；

2.        向SES引擎注册服务接口；

3.        启动本地服务；

4.        请求通信服务；

5.        发布服务至互联网。

另外，Servicer App也展示了如何监听SES Framework的事件，以及如何进行用户管理，参数设置等功能。 

作为工具，Servicer App可以提供以下功能： 

1.        自动生成服务接口的javascript代码或c代码；

2.        支持系统资源监控功能，协助开发者调试代码；

3.        提供log管理功能，协助开发者进行功能测试。

  

(十一)      结束

上述章节完整描述了SES系统的核心架构和主要流程实现。

总之，SES的宗旨是提供一个与服务无关的互联网服务发布和消费平台，一方面，SES不希望干预服务的具体内容和形式；另一方面，SES希望最大限度的简化互联网服务发布的难度，包括开发，维护，安全等方面。 

  

【1】       Web信息系统导论，李广建，高等教育出版社，2008年9月第一版

【2】       Web Services Architecture，W3C Working Group Note，11 February 2004

【3】       Web Service Semantics - WSDL-S，W3C Member Submission 7 November 2005

【4】       Session Traversal Utilities for NAT (STUN)，rfc5389

【5】       Traversal Using Relays around NAT (TURN，rfc5766

【6】       Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations，rfc6062

【7】       Symmetric NAT Traversal using STUN，draft-takeda-symmetric-nat-traversal-00.txt。

Claims (10)

1.SES是一个服务发布平台，其特征在于统一、与服务无关、基于互联网。

2.SES包含三大功能：服务管理、用户管理、通信管理。

3.SES的服务管理包括服务发布、服务定位、服务消费；并针对智能服务提供支持；SES的用户管理包括用户注册、注销、查询和身份认证机制；SES的通信管理包括完整、安全、可扩展的通信服务，解决内网设备互联的问题。

4.SES的服务管理中对服务重新进行了定义，其特征是使用一个服务接口ID（interface）代表一个完整的产品所拥有的全部功能，而不是定义一系列具体的函数。

5.SES设计了一个协议栈Message Function Mapping Protocol（MFMP），SES中各网元之间的通信均采用此协议；MFMP协议分为三层：通信层，系统层和应用层；SES采用HTTP协议作为系统层协议，兼容浏览器客户端和应用程序客户端。

6.SES实现了一种模糊消费模式，其特点是对服务所能提供的数据类型进行了统一的定义，系统可以根据数据类型自动调用服务，从而实现“智能”调用。

7.SES包括一个用户管理模块，其特征是完全和服务无关的，以及采用了Key-Token认证机制。

8.SES设计了Key-Token认证机制，其特征是所有通信过程中，用户最为敏感的password从不出现，绝对避免了密码在通信过程中被窃取的可能性，并可以有效辨别暴力破密；另一特征是Key-Token认证支持公共认证、友好认证、私有认证三种模式。

9.SES提供了通信管理模块，其特征包括其完整性，支持对称型NAT的穿透，中转服务的一对一、多对多模式。

10.SES系统可以根据服务者所处的地域分布和网络类型，灵活的分配通信服务器，其主要特征是大大降低了消息中转所带来的通信延迟和抖动等负面影响。