(1)服务支撑层。能够接入不同的设备或者是服务，用于提供对不同粒度构件的 "即插即用"支持，即：接入各种数据流，包括：信息流，事件流，感知流，从而利用不同的信息 输入或输出实现智慧服务的接入支撑；
[0036] (2)服务感知中间件。获取服务支撑平台的各种异构服务数据，是智慧服务平台获 取服务资源信息及其自身状态变化不可或缺的过程和手段，从而可以提供多样化，个性化， 可扩展化的数据服务，实现在服务支撑平台和业务融合层之间传递信息；
[0037] (3)业务融合层。业务融合层获取感知中间件提供的各种开放信息，对各种信息进 行整合处理，为应用层提供各种应用服务；
[0038] (4)应用层。这是智慧服务商店平台的最上层，一方面，平台用户可以利用服务构 件模型进行服务消费、资源共享以及具体的业务需求定制；另一方面，随着软件应用的部署 运行，为了满足后续的业务变更，还为第三方开发人员提供了针对系统平台的接入服务，可 以接入相关的服务数据，即：智慧医疗数据和智慧交通数据。
[0039] 二、3S智慧服务商店服务感知中间件设计
[0040] 服务感知中间件模块是整个平台的核心功能构件，负责支撑整个平台的数据解 析以及服务的发布订阅，是沟通底层数据流接入与上层业务融合的中间桥梁与纽带。
[0041] 如图2所示为服务感知中间件模块体系结构，服务感知中间件是智慧服务平台获 取服务资源信息以及其自身状态变化预测的不可缺少的过程，也是系统可扩展，面向服务 化的直接驱动力，本发明首先基于已有的知识表达法，采用自顶向下的方式对服务资源进 行抽象建模，提出一种通用的、易扩展的服务感知中间件框架，具体包括服务访问控制层、 服务数据交换处理层和服务数据获取层，在此基础上，描述了感知中间件的构造方法和简 单的服务数据交互原型。
[0042] 本发明的服务感知中间件模块包括：
[0043] (1)服务数据获取层。该层主要负责对平台所处的服务资源和事件信息流进行采 集预处理并传输。其中，感知流可以是传统的物联网传感器节点采集到的数据，用于实时采 集感知信息，事件流可以有用户的交易请求信息，服务告警信息等，而其他的接入流可以是 第三方的服务提供者提供的数据流信息。在这一层本发明通过统一的编程接口对各种异构 的服务信息进行捕捉，以降低服务之间的耦合度。服务信息预处理模块主要负责将各种接 入到平台的数据流的原始粗糙服务数据转换成统一的格式（即：XML和JSON格式），为后续 的服务信息存储到数据库，以及解析和处理提供通用的标准化数据源。
[0044] (2)服务数据交换处理层。服务数据交互处理层主要负责对下层解析过来的标 准数据源进行交换处理，实现服务信息的融合和事件的管理功能，包括服务信息库模块、 服务信息管理模块、服务聚合和事件处理模块，其中服务信息库可以是关系型数据库，即： Oracle和MySQL数据库，负责处理数据源的增删改查工作。
[0045] (3)服务访问控制层。该层采用同步服务请求和异步通知相结合的技术，通过统一 的服务开放接口，可以实现高效稳定的服务访问查询服务，也可以异步通知服务的事件状 态变化。主要包括服务查询、服务订阅、面向业务融合层的接口模块。
[0046] 三、智慧服务数据模型及其设计
[0047] 智慧服务数据的交换与处理是整个3S智慧服务商店平台中必不可少的一部分， 它位于服务感知中间件层（如图2所示），在已有智慧服务数据模型设计的基础上，本设计 提出了服务数据交换处理的方法，包括服务数据交换处理架构，服务数据交换处理过程式 等关键技术及实现工作，为整个平台提供稳定以及快速的服务数据交换与处理。
[0048] 本发明设计的服务数据交换处理方法使用持久化的发布/订阅模式，使平台能够 可靠的交换数据，各服务节点易于部署维护，服务数据交换技术的应用为用户提供了详细 的数据流转时间及交换日志，具体设计如下：
[0049] 3. 1智慧服务数据UML类图
[0050] 智慧服务数据是服务支撑层接入的各类数据流，是平台运营最为重要的构件，包 括两方面的含义：（1)自身承载的基本信息，例如温度传感器数据，心跳数据，智能交通数 据；（2)与其他信息元素之间的关联关系，这是一个层次型的关系，例如温度传感和湿度传 感器可以归为环境监控参数服务，心跳血压等数据可以划分为智能健康服务，这些关系信 息承载着服务数据的上下文组织方式。针对这种关联关系，本发明构建了一个通用的、易扩 展的、具有层级递归关系的服务数据模型（ServiceDataModel),如图3所示。
[0051] 根据图3的UML类图，本发明定义了一个具有层次结构的数据模型，其中，业务 的数据结构定义为三个，分为服务数据的属性，服务数据的资源分类以及服务数据发布接 口，其中Property接口负责描述数据类型及具体值，比如获取温度参数，获取健康参数， Resource接口负责描述服务数据的所属分类，如划分成智能健康，智能交通类别，最上层的 ServiceData接口负责接收并发送数据，一个ServiceData接口可以由若干服务数据分类 和若干子服务数据组成，是一对多的关系。
[0052] 3. 2服务数据模型的形式化描述
[0053] 服务数据模型=〈ServiceData, Resource, Property〉，这是一个三元组的模 式，而服务数据提供接口是一组服务资源分类R(Resource)组成的集合，即Service= {R" R2,…，Rj，（n彡1)〇
[0054] 服务资源分类可以由若干个子服务资源和属性组成，令Property=P，即 ELPi(i>〇)。P是由属性名和属性值组成的一个二元组，即是〈key，value〉集合，其中key 表示属性名，value表示属性值。
[0055] 有了如上的定义，本发明采用树型拓扑结构，将各个服务数据按照其所属类别及 其层次关系组织起来，这样可以得到一种通用的、易扩展的服务数据模型（如图4所示），为 整个平台提供通用的标准化数据源。
[0056] 3. 3服务数据模型详细解释如下
[0057] 如图4所示，本发明的服务数据模型由服务资源分类和服务属性两个节点组成， 服务数据模型是一种多叉树的形式，圆形节点表示服务资源分类节点，每个服务资源分类 里面又可能包含子服务分类资源和多个服务属性节点，为了便于系统标识，每个节点的名 称是唯一的；方形节点表示服务属性节点，隶属于服务资源分类节点，每个节点都承载了具 体的服务数据，用〈key,value〉的键值映射集合形式存储信息，例如{ "wendu"： "32°C"}〇
[0058] 整个平台的服务数据均采用〈key，value〉键值进行存储，方便数据进行解析交换 传输，也有利于第三方服务提供商将自己的服务数据接入到3S智慧服务商店平台，比如： 智能健康服务资源分类可以表示为：http: /Vurl/servicedata/health,用户心跳服务数 据可以表示为：http: //url/servicedata/health/heart。其中，URL为平台的访问地址，对 外开放授权访问。
[0059] 3. 4服务数据交换与处理的总体结构
[0060] 图4所示为服务数据图5所示为服务数据交换平台结构，服务数据交换处理采用 星型拓扑结构，服务节点的数据通过服务数据交换接口将服务数据发送至交换中心，交换 中心将数据传输到上一级的目标服务节点。目标节点的数据交换接口将接收到的数据存入 该服务节点对应的业务系统数据库中。采用星型拓扑结构，可以保证各服务节点只需和中 心交