论文部分内容阅读
摘要：SOA是一种服务导向的可重用组件模型。随着SOA应用服务数量、服务之间依赖关系复杂度的增加，服务发布与发现作为实现SOA架构的一项重要基础设施，如何管理现存服务变得越来越困难。针对集中式服务注册中心存在单点失效的不足，通过构建多节点的服务注册中心避免单点失效导致其对外提供的服務发布、发现、查询等接口不可用的缺陷。同时多个节点间基于消息与通知的方式，采用SSL建立安全的连接确保多个节点之间服务数据的一致性。针对Web服务之间内生点对点调用存在硬编码的不足，通过消息拦截分发机制有效缓解该问题。本文拟在上述服务注册中心的基础上，提出一种基于SOA的软件可重用开发模型，并在实际生产系统用户管理系统设计，实现并验证该模型的有效性。
关键词：UDDI；WSDL；SOA；SSL；服务
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2018）06-0212-03
1引言
自从1996年SOA（Service-Oriented Architecture，面向服务架构）的概念被Gartner提出以后，近二十年SOA的发展也经历了起起伏伏。近些年随着Web Service的兴起，使得SOA登上了第一次的巅峰。面向服务体系架构是继面向对象、基于构件开发之后的一种新型软件开发、部署和集成模式，为软件开发提供了灵活的设计和开发方案口。在SOA的应用中，几乎所有对Web Service的介绍都会引入三种角色：服务供应者，服务消费者以及服务注册中心。Web Service所具备的平台独立性，松耦合，自包含，服务可发现性等等可以很好地支持SOA架构思想。其提供了一系列接口通过标准的XML格式消息在In-ternet上进行发布，查找与访问。
服务提供者发布可通过网络访问的服务，服务消费者从本地或者服务注册中心查找服务描述信息完成服务绑定。UDDI定义了服务发布与发现的标准，对服务提供者与服务消费者提供了相应的发布与发现API（Application Programming Inter-face）。通过UDDI，SOA系统可以实现服务的可发现性，可重用，互操作，位置透明和服务之间的松耦合。对服务提供者，服务消费者而言，UDDI扮演着十分重要的“桥梁”角色。
2服务发布与发现模型研究现状
在传统的Web服务发布与发现体系结构中，根据实现方式的不同，服务发布与发现模型可以分为集中式、分布式与混合式。
2.1集中式服务发布与发现模型
集中式服务发布与发现模型以传统的UDDI为代表。该模型使用单一节点存储服务提供者发布的服务，服务信息将会持久化到单一节点上。该模型通过解析WSDL与UDDI的映射关系，生成核心数据模型数据，如Business Entity，Business Ser-vice等等。服务消费者根据查询结果中服务描述信息构建本地客户端服务代理，进行服务调用。文献5探讨了一种基于集中式UDDI的集成框架，并借助工程实践验证上述框架的实用性与有效性。
2.2分布式服务发布与发现模型
面对高并发服务发布与发现应用场景，集中式服务发布与发现模型存在性能瓶颈与单点失效的问题。部分学者基于P2P对等网络构建了以分布式结构为特点的服务发布与发现模型，适用于移动网络的服务发布与发现。该模型无中心节点，每个peer既可能是服务供应者也可能是服务消费者。服务请求以广播的形式发送到P2P网络中，服务提供者将满足需求的服务返回给服务请求者。由于采用广播的通信机制进行服务发现，所以通信开销较大。文献2引入对等架构，设计并实现基于结构化对等协议的Web服务注册系统。
2.3混合式服务发布与发现模型
混合式服务发布与发现模型是在集中式与分布式的基础上，将多个节点组合成一个组，尽管降低了全局服务查询的几率，减少了节点之间的通讯开销。但是随着服务数量的增加，其服务发现算法异常复杂，并需要考虑如何分组以及分组中的中心节点问题，不利于系统的扩展，降低了系统的灵活性。
本文结合上述三种服务发布与发现模型的优缺点，提出一种方案。针对集中式服务注册中心存在单点失效的不足，通过构建多节点服务注册中心避免单点失效，并且多个服务注册中心采用消息与通知的方式，基于双向SSL安全交换不同节点之间存在差异的数据，保证不同节点之间服务数据的一致性。
3分布式UDDI系统模型设计
3.1体系结构设计
分布式UDDI遵循UDDIv3版本规范，包含常用inquiry，publication等常用接口服务提供者通过服务注册中心客户端访问服务注册中心，通过SOAP消息客户端与服务注册中心交互，将服务描述信息传递给publication接口。服务请求者通过客户端提交服务查询相关参数，服务器端inquiry接口根据客户端传递过来的SOAP消息并解析该消息，按照关键词查询相关服务。
服务注册中心整体上划分为三个部分。第一部分提供对外暴露的接口信息，如服务发布接口，服务查询接口，服务复制接口等等。第二部分提供对象关系映射，将服务提供者发布的服务持久化到关系数据库或者服务消费者提供的关键检索数据库，查找符合要求的服务描述信息。第三部分为关系数据库。每个服务注册中心包含唯一的标识码，类似主键；将其与其他的服务注册中心区分开。多个服务注册中心需要保证多个服务注册中心关系数据库中所保存服务数据的一致性。
3.2数据一致性的考虑
每一个服务注册中心维护着本地数据库中存放的服务数据，在Business Entity，Business Service等数据模型产生改变的时候，源服务注册中心（服务数据发生改变的源头服务注册中心）将会通知与其有关联的所有其他节点。其他收到消息通知的节点从源服务注册中心节点拉取改变的数据，并将改变的数据持久化到本地数据库。此种模式下，所有节点之间均会相互关联，从逻辑上来看，节点之间构成了无向图这种数据结构。 服务提供者在获取authToken的基础上，将服务描述信息发布到服务注册中心。对服务注册中心而言，其保存数据的有效l生与正确性是十分重要的。Replication接口为服务注册中心之间交换数据提供了支持。服务注册中心之间采用双向SSL认证，保证双发交换数据之前知道对方的身份，确保对方在自己的信任库中。
4服务发布与发现模型在用户管理系统中的应用
本文所述的用户管理系统是企业在面对日常业务操作，实现信息化所构建的后台管理系统。该系统包含基础的账号管理，权限访问控制等常见功能。
本文拟在上述背景下，基于IBM SOMA（Service-oriented Modelingand Architecture）对用户管理系统中的菜单模块，角色模块，权限模块以及通用的支付模块进行服务建模；并以Web Service的形式对外暴露可访问的接口；利用Apache CXF框架组织上述服务（由上述服务构建的系统定义为基础服务系统SRS）。同时，将上述对外发布的服务发布到改进的分布式服务注册中心Apache JUDDI中。最后实现剥离上述模块的用户管理系统与上述服务进行交互，实现相关的业务逻辑，同时提高程序的可维护性，可扩展性，为未来开发不同产品时提供信息集成和共享能力。
4.1系统交互模型
整个交互模型由三种角色构成。基于JUDDI的分布式服务注册中心、用户管理系统与基础服务系统。JUDDI是基于UDDIv3規范的开源服务注册中心，用于服务发布与发现。用户管理系统是常见的企业后台管理系统。基础服务系统基于权限服务，菜单服务，用户管理服务，支付服务；为其他应用系统提供基础服务的系统。使用JUDDI将二者集成，基础服务系统将服务发布到JUDDI，用户管理系统搜索相应服务并构建客户端服务代理调用服务完成相应的后台业务逻辑。
4.2服务发布与查询
4.2.1服务发布
服务建模的目标是建立企业的服务模型，该服务模型作为业务与IT之间的桥梁是首先SOA对业务随需应变灵活性支持的关键因素。本文基于SOMA进行服务建模。首先抽取用户管理系统中的菜单模块，角色模块，权限模块以及支付模块。在此基础之上，确定各个组件对外暴露决策以及接口的参数规范。最后采用Web Service的形式，使用Apache CXF框架组织服务，并对外发布，供服务消费者请求与访问。
在服务注册中心持久化Business Entity之后，将会触发消息产生并通知其他服务注册中心节点，当前有数据更新。其他服务注册中心接收到该通知之后，会根据通知中的参数主动请求源服务注册中心节点，拉取更新的数据，并持久化到本地。
4.2.2服务查询
服务请求在服务注册中心客户端输入服务名称，分类等信息查询，服务注册中心根据关键词匹配服务描述信息并返回结果。
4.3服务调用
用户管理系统通过调用基础服务系统来实现相应的业务逻辑。具体的步骤如下。（1）用户登录系统时请求基础服务系统提供的用户管理服务，验证用户名密码是否正确，并返回验证结果。（2）在用户通过验证的基础上，用户管理系统请求基础服务系统角色服务获取用户所属的角色以及该角色所拥有的权限（菜单以及按钮）信息；（3）进人后台主界面，显示菜单、按钮等资源。二者之间的交互模型如图1所示。
图中展示了用户管理系统调用基础服务系统服务所做的特殊处理，主要是服务代理层与POJO模型对象转换层；服务代理层在SOAP请求消息中加入当前客户端的信息，为服务调用提供凭证。POJO模型转换层处理服务调用的结果，将服务调用的结果转化为适用于本系统简单对象或者将本系统的简单对象处理为服务代理层适用的请求参数。
5实验与分析
5.1实验环境
该实验在1MB/S以太网的网络环境中进行测试，包括三台阿里云服务器（Windows Server 2012、Intel双核2.60GHz处理器、4GB内存），软件环境有Jdk1.7的Java平台，Mysq15.5数据库，Apache Tomcat 7应用服务器，Apache Maven 3.5.0项目管理工具。JUDDI分布在两台独立的阿里云服务器上，二者建立双向的SSL连接，为服务数据的复制提供支持。使用SOAPUI对JUDDI中的服务是否可用进行测试。同时记录用户管理系统在调用服务时产生的数据包括当前调用的客户端，调用时间等等。下面对比分析修改前方法调用与修改后服务调用在性能方面的差异。下面以获取第三方支付凭证以及子菜单列表为例分析。
5.2实验结果
5.2.1获取支付凭证耗时对比分析
图2展示了在使用支付服务时，调用第三方支付获取支付凭证用户管理系统通过方法调用与服务调用所消耗的时间，耗时差距平均基本维持在50ms以内。
5.2.2获取菜单列表耗时对比分析
图3展示了在使用菜单服务时，根据权限获取当前用户所拥有的一级菜单时；获取用户一级菜单下的所有二级菜单所消耗的时间，耗时差距平均维持在1ms以内。
在调用基础服务系统提供的服务时，若客户端提供的参数含义不符合服务要求的参数定义，服务调用将会出现异常，并不会返回预期的结果；基础服务系统在对外暴露接口调用规范的同时会对服务的调用进行监控，将服务调用的客户端，服务调用所消耗的时间，当前调用的是哪个方式形成结构化数据持久化到数据库；供后期进行数据分析。
在企业开发不同产品的过程中，往往会出现不同产品包含相似功能模块的场景。从面向组件到面向服务，将各个产品功能类似的模块抽象成服务，单独维护与运营，提高相似模块的复用性。服务组件部署于局域网之中，网络开销比较小，以这种开发方式有利于规范软件开发过程，复用软件构件，降低软件开发风险以及软件维护成本。
6总结
本文在分析服务发布与发现模型的基础上，设计并实现了基于UDDIv3规范的多节点Web服务注册系统。通过Apache JUDDI构建多服务注册中心，用于服务发布与发现；采用消息与通知的方式维护多个服务注册中心服务数据的一致性。结合实际生产系统用户管理管理，抽取该系统中通用的菜单，角色，权限，支付模块；并采用SOMA方法建模为服务，并发布到服务注册中心。多节点的服务注册中心能够避免单节点服务注册中心失效而导致其对外提供API不可用的问题。基于消息分发模式能够改善传统Web Service点对点调用的缺点。文章对服务发布与发现的几种模型进行了深入研究，对基于SOA架构的信息系统中服务发布与发现的应用与实现技术进行了分析与研究，在改进的服务注册中心的基础上提出了一种软件可重用开发模型，并在相关项目中进行了验证与实现。
关键词：UDDI；WSDL；SOA；SSL；服务
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2018）06-0212-03
1引言
自从1996年SOA（Service-Oriented Architecture，面向服务架构）的概念被Gartner提出以后，近二十年SOA的发展也经历了起起伏伏。近些年随着Web Service的兴起，使得SOA登上了第一次的巅峰。面向服务体系架构是继面向对象、基于构件开发之后的一种新型软件开发、部署和集成模式，为软件开发提供了灵活的设计和开发方案口。在SOA的应用中，几乎所有对Web Service的介绍都会引入三种角色：服务供应者，服务消费者以及服务注册中心。Web Service所具备的平台独立性，松耦合，自包含，服务可发现性等等可以很好地支持SOA架构思想。其提供了一系列接口通过标准的XML格式消息在In-ternet上进行发布，查找与访问。
服务提供者发布可通过网络访问的服务，服务消费者从本地或者服务注册中心查找服务描述信息完成服务绑定。UDDI定义了服务发布与发现的标准，对服务提供者与服务消费者提供了相应的发布与发现API（Application Programming Inter-face）。通过UDDI，SOA系统可以实现服务的可发现性，可重用，互操作，位置透明和服务之间的松耦合。对服务提供者，服务消费者而言，UDDI扮演着十分重要的“桥梁”角色。
2服务发布与发现模型研究现状
在传统的Web服务发布与发现体系结构中，根据实现方式的不同，服务发布与发现模型可以分为集中式、分布式与混合式。
2.1集中式服务发布与发现模型
集中式服务发布与发现模型以传统的UDDI为代表。该模型使用单一节点存储服务提供者发布的服务，服务信息将会持久化到单一节点上。该模型通过解析WSDL与UDDI的映射关系，生成核心数据模型数据，如Business Entity，Business Ser-vice等等。服务消费者根据查询结果中服务描述信息构建本地客户端服务代理，进行服务调用。文献5探讨了一种基于集中式UDDI的集成框架，并借助工程实践验证上述框架的实用性与有效性。
2.2分布式服务发布与发现模型
面对高并发服务发布与发现应用场景，集中式服务发布与发现模型存在性能瓶颈与单点失效的问题。部分学者基于P2P对等网络构建了以分布式结构为特点的服务发布与发现模型，适用于移动网络的服务发布与发现。该模型无中心节点，每个peer既可能是服务供应者也可能是服务消费者。服务请求以广播的形式发送到P2P网络中，服务提供者将满足需求的服务返回给服务请求者。由于采用广播的通信机制进行服务发现，所以通信开销较大。文献2引入对等架构，设计并实现基于结构化对等协议的Web服务注册系统。
2.3混合式服务发布与发现模型
混合式服务发布与发现模型是在集中式与分布式的基础上，将多个节点组合成一个组，尽管降低了全局服务查询的几率，减少了节点之间的通讯开销。但是随着服务数量的增加，其服务发现算法异常复杂，并需要考虑如何分组以及分组中的中心节点问题，不利于系统的扩展，降低了系统的灵活性。
本文结合上述三种服务发布与发现模型的优缺点，提出一种方案。针对集中式服务注册中心存在单点失效的不足，通过构建多节点服务注册中心避免单点失效，并且多个服务注册中心采用消息与通知的方式，基于双向SSL安全交换不同节点之间存在差异的数据，保证不同节点之间服务数据的一致性。
3分布式UDDI系统模型设计
3.1体系结构设计
分布式UDDI遵循UDDIv3版本规范，包含常用inquiry，publication等常用接口服务提供者通过服务注册中心客户端访问服务注册中心，通过SOAP消息客户端与服务注册中心交互，将服务描述信息传递给publication接口。服务请求者通过客户端提交服务查询相关参数，服务器端inquiry接口根据客户端传递过来的SOAP消息并解析该消息，按照关键词查询相关服务。
服务注册中心整体上划分为三个部分。第一部分提供对外暴露的接口信息，如服务发布接口，服务查询接口，服务复制接口等等。第二部分提供对象关系映射，将服务提供者发布的服务持久化到关系数据库或者服务消费者提供的关键检索数据库，查找符合要求的服务描述信息。第三部分为关系数据库。每个服务注册中心包含唯一的标识码，类似主键；将其与其他的服务注册中心区分开。多个服务注册中心需要保证多个服务注册中心关系数据库中所保存服务数据的一致性。
3.2数据一致性的考虑
每一个服务注册中心维护着本地数据库中存放的服务数据，在Business Entity，Business Service等数据模型产生改变的时候，源服务注册中心（服务数据发生改变的源头服务注册中心）将会通知与其有关联的所有其他节点。其他收到消息通知的节点从源服务注册中心节点拉取改变的数据，并将改变的数据持久化到本地数据库。此种模式下，所有节点之间均会相互关联，从逻辑上来看，节点之间构成了无向图这种数据结构。 服务提供者在获取authToken的基础上，将服务描述信息发布到服务注册中心。对服务注册中心而言，其保存数据的有效l生与正确性是十分重要的。Replication接口为服务注册中心之间交换数据提供了支持。服务注册中心之间采用双向SSL认证，保证双发交换数据之前知道对方的身份，确保对方在自己的信任库中。
4服务发布与发现模型在用户管理系统中的应用
本文所述的用户管理系统是企业在面对日常业务操作，实现信息化所构建的后台管理系统。该系统包含基础的账号管理，权限访问控制等常见功能。
本文拟在上述背景下，基于IBM SOMA（Service-oriented Modelingand Architecture）对用户管理系统中的菜单模块，角色模块，权限模块以及通用的支付模块进行服务建模；并以Web Service的形式对外暴露可访问的接口；利用Apache CXF框架组织上述服务（由上述服务构建的系统定义为基础服务系统SRS）。同时，将上述对外发布的服务发布到改进的分布式服务注册中心Apache JUDDI中。最后实现剥离上述模块的用户管理系统与上述服务进行交互，实现相关的业务逻辑，同时提高程序的可维护性，可扩展性，为未来开发不同产品时提供信息集成和共享能力。
4.1系统交互模型
整个交互模型由三种角色构成。基于JUDDI的分布式服务注册中心、用户管理系统与基础服务系统。JUDDI是基于UDDIv3規范的开源服务注册中心，用于服务发布与发现。用户管理系统是常见的企业后台管理系统。基础服务系统基于权限服务，菜单服务，用户管理服务，支付服务；为其他应用系统提供基础服务的系统。使用JUDDI将二者集成，基础服务系统将服务发布到JUDDI，用户管理系统搜索相应服务并构建客户端服务代理调用服务完成相应的后台业务逻辑。
4.2服务发布与查询
4.2.1服务发布
服务建模的目标是建立企业的服务模型，该服务模型作为业务与IT之间的桥梁是首先SOA对业务随需应变灵活性支持的关键因素。本文基于SOMA进行服务建模。首先抽取用户管理系统中的菜单模块，角色模块，权限模块以及支付模块。在此基础之上，确定各个组件对外暴露决策以及接口的参数规范。最后采用Web Service的形式，使用Apache CXF框架组织服务，并对外发布，供服务消费者请求与访问。
在服务注册中心持久化Business Entity之后，将会触发消息产生并通知其他服务注册中心节点，当前有数据更新。其他服务注册中心接收到该通知之后，会根据通知中的参数主动请求源服务注册中心节点，拉取更新的数据，并持久化到本地。
4.2.2服务查询
服务请求在服务注册中心客户端输入服务名称，分类等信息查询，服务注册中心根据关键词匹配服务描述信息并返回结果。
4.3服务调用
用户管理系统通过调用基础服务系统来实现相应的业务逻辑。具体的步骤如下。（1）用户登录系统时请求基础服务系统提供的用户管理服务，验证用户名密码是否正确，并返回验证结果。（2）在用户通过验证的基础上，用户管理系统请求基础服务系统角色服务获取用户所属的角色以及该角色所拥有的权限（菜单以及按钮）信息；（3）进人后台主界面，显示菜单、按钮等资源。二者之间的交互模型如图1所示。
图中展示了用户管理系统调用基础服务系统服务所做的特殊处理，主要是服务代理层与POJO模型对象转换层；服务代理层在SOAP请求消息中加入当前客户端的信息，为服务调用提供凭证。POJO模型转换层处理服务调用的结果，将服务调用的结果转化为适用于本系统简单对象或者将本系统的简单对象处理为服务代理层适用的请求参数。
5实验与分析
5.1实验环境
该实验在1MB/S以太网的网络环境中进行测试，包括三台阿里云服务器（Windows Server 2012、Intel双核2.60GHz处理器、4GB内存），软件环境有Jdk1.7的Java平台，Mysq15.5数据库，Apache Tomcat 7应用服务器，Apache Maven 3.5.0项目管理工具。JUDDI分布在两台独立的阿里云服务器上，二者建立双向的SSL连接，为服务数据的复制提供支持。使用SOAPUI对JUDDI中的服务是否可用进行测试。同时记录用户管理系统在调用服务时产生的数据包括当前调用的客户端，调用时间等等。下面对比分析修改前方法调用与修改后服务调用在性能方面的差异。下面以获取第三方支付凭证以及子菜单列表为例分析。
5.2实验结果
5.2.1获取支付凭证耗时对比分析
图2展示了在使用支付服务时，调用第三方支付获取支付凭证用户管理系统通过方法调用与服务调用所消耗的时间，耗时差距平均基本维持在50ms以内。
5.2.2获取菜单列表耗时对比分析
图3展示了在使用菜单服务时，根据权限获取当前用户所拥有的一级菜单时；获取用户一级菜单下的所有二级菜单所消耗的时间，耗时差距平均维持在1ms以内。
在调用基础服务系统提供的服务时，若客户端提供的参数含义不符合服务要求的参数定义，服务调用将会出现异常，并不会返回预期的结果；基础服务系统在对外暴露接口调用规范的同时会对服务的调用进行监控，将服务调用的客户端，服务调用所消耗的时间，当前调用的是哪个方式形成结构化数据持久化到数据库；供后期进行数据分析。
在企业开发不同产品的过程中，往往会出现不同产品包含相似功能模块的场景。从面向组件到面向服务，将各个产品功能类似的模块抽象成服务，单独维护与运营，提高相似模块的复用性。服务组件部署于局域网之中，网络开销比较小，以这种开发方式有利于规范软件开发过程，复用软件构件，降低软件开发风险以及软件维护成本。
6总结
本文在分析服务发布与发现模型的基础上，设计并实现了基于UDDIv3规范的多节点Web服务注册系统。通过Apache JUDDI构建多服务注册中心，用于服务发布与发现；采用消息与通知的方式维护多个服务注册中心服务数据的一致性。结合实际生产系统用户管理管理，抽取该系统中通用的菜单，角色，权限，支付模块；并采用SOMA方法建模为服务，并发布到服务注册中心。多节点的服务注册中心能够避免单节点服务注册中心失效而导致其对外提供API不可用的问题。基于消息分发模式能够改善传统Web Service点对点调用的缺点。文章对服务发布与发现的几种模型进行了深入研究，对基于SOA架构的信息系统中服务发布与发现的应用与实现技术进行了分析与研究，在改进的服务注册中心的基础上提出了一种软件可重用开发模型，并在相关项目中进行了验证与实现。