CN110618810A - 一种基于元数据驱动的多样化服务的混合编排方法 - Google Patents

Abstract

服务协议的多样性带来了消息结构的多样性，而BPEL不支持多样化的服务消息结构，因此在多样化的服务组合存在服务交互不匹配的问题。对此本发明提出一种元数据驱动的多样化服务的混合编排方法，对多样化服务进行元数据建模，描述服务消息结构，服务适配器利用元数据转换多样化的服务消息，在统一的消息结构上定义流程中服务间的数据交互，总体结合了基于元数据的数据依赖定义和BPMN定义完整地描述一个流程。通过案例测试以及可用性评估，结果验证了方法的可行性。该方法在一定程度上解决了多样化服务编排的问题，对多样化的服务协议类型可扩展。

Description

一种基于元数据驱动的多样化服务的混合编排方法

技术领域

本发明属于服务计算领域，尤其涉及服务组合中的服务编排方法。

背景技术

服务组合的概念是使用系统中已有的Web服务，通过对他们进行一定顺序的组合以及进行组合顺序的改变来创造出新的服务来满足用户的需求。其中过程驱动的WSC的基本思想是利用WSC与过程模型的相似性，使用较成熟的过程建模工具和语言对WSC业务过程进行建模。而过程驱动的WSC又可以分为基于工作流模型，基于状态演算和基于进程代数三类。其中基于工作流模型的方式提供图形化的操作界面，服务设计人员通过人机交互的方式定义抽象服务流，之后自动转换为流程引擎中的工作流。这种半自动的服务编排方式充分利用了设计者的领域知识并减少了设计者的工作量，具有很好的动态性和灵活性。

BPMN业务流程的一种定义语言，是一套业务分析者，软件开发者以及业务管理者都可以理解的语言，它的目标是为服务组合语言如BPEL提供图形化的建模符号，使得服务组合的设计和实现可以无缝衔接。它包含一些基本元素流对象，连接对象，泳道和工件。流对象由活动对象，事件和网关三类组成，用于定义流程的各个子任务。而活动对象是对业务行为的抽象。连接对象表示流对象之间的关联。文献[10]讨论了根据BPMN 2.0去描述服务交互模式存在的问题以及其克服办法。

服务整合的典型处理方法是适配器和消息解析器，服务适配器将WEB应用包裹起来，转换消息结构使得服务之间看起来使用相同结构的数据进行交互，令服务组合更加容易。服务的适配器类型可被归为兼容性适配器和替换性适配器，兼容性适配器的作用在于适配服务的消息格式，使服务可以相互交流，替换性适配器弥补服务的功能不足，以补全服务组合的功能。服务适配在交互失配检测的基础上,通过构造适配器来实现服务之间的正确交互，比如一种称为WSDL2CODE的半自动化服务适配器的生成方法。

发明内容

本文提出元数据驱动的多样化服务的混合编排方法，整体方法示意图如图2所示，通过BPMN和服务元数据定义流程执行中服务的调度的执行顺序和数据依赖关系，并自动解析多样化格式的服务消息。具体采用如下技术方案：

一种基于元数据驱动的多样化服务的混合编排方法，其特征在于，包括：

元数据管理模块：提供了对服务元数据进行增删该查的功能，提供了元数据展示界面，以及元数据的注册修改界面；流程管理模块提供了流程编排界面，以及流程的状态的管理界面；用户可以在元数据管理界面中，查看，添加或修改服务元数据信息；在编排界面中可以通过图形化的操作进行服务编排，在流程管理界面中可以执行，挂起或终止已经部署的流程；

服务编排模块：基于BPMN可视化的流程编排界面进行服务编排，指定服务的调度顺序；同时，指定服务调用之间的数据传递关系；两方面操作生成BPMN的流程定义和数据依赖关系定义，二者共同描述了一个流程中服务的执行顺序以及服务之间的数据交互；

流程执行模块：服务适配器根据服务元数据将多样化的服务消息格式适配为统一消息格式，并在此消息格式上定义统一的数据交互模式；同时依靠BPMN定义流程中服务的执行顺序，最终实现多样化服务的服务编排,在流程执行模块中，根据BPMN流程定义依次调度各个服务，服务之间的数据交互依据已定义的数据依赖关系进行；在服务调度中，统一结构的消息与对应服务协议的消息自动适配，也就是给定统一结构的请求数据，自动地生成服务请求；给定服务的返回，自动解析为统一结构的返回数据；

服务消息适配模块：实现了标准化消息和实际服务的消息之间的转换；服务的元数据中定义了转换所需要的信息，包括服务地址、协议、消息格式等信息，同时消息格式中定义了消息中各个数据元素的语法细节，因此，利用服务的元信息，可以实现标准化消息和实际服务的消息之间的双向转换。

在上述的一种基于元数据驱动的多样化服务的混合编排方法，元数据管理模块进行服务的元数据建模，具体是：

构建服务的描述数据，服务元数据支持两个阶段工作，服务编排和流程执行；具体为在服务编排阶段生成数据依赖定义，以及在服务执行阶段自动适配服务消息；基于服务元数据所支持的工作阶段不同，服务元数据所包含的信息被分为编排信息和适配信息；

服务的编排信息描述服务的基本输入项和输出项，输入输出项为应用层上的输入输出，元数据中的适配信息则描述生成和解析服务消息时所需要的信息。

在上述的一种基于元数据驱动的多样化服务的混合编排方法，服务消息适配模块定义统一的服务消息交互格式，具体是：在流程编排阶段，服务数据传递规则无法基于BPMN语言指定；基于服务元数据定义统一的Json消息格式用于服务之间的数据交互；该数据结构可以表示一个服务请求或一个服务返回，流程中服务的请求和返回都采用该格式，作为服务的请求消息时，Json的Key值为元数据中的输入项名称，作为输出消息时，对应元数据中输出项名称。

在上述的一种基于元数据驱动的多样化服务的混合编排方法,流程执行模块基于BPMN和服务元数据定义流程执行过程和数据依赖，具体是：

BPMN中包含流对象和活动对象两个基本元素，分别表示流程中需要执行的任务和任务的顺序，通过BPMN中的活动对象描述一次服务调用，通过流对象描述服务的执行顺序，在BPMN2.0中，ServiceTask元素表示一个流程中的自动任务，sequenceFlow元素表示一个活动到下一个活动的执行顺序，结合服务的元数据信息，在任务节点中指定服务调度的顺序；

借助于服务元数据和统一的Json消息格式定义一个流程中服务之间的数据交互,最后生成的数据依赖定义本文又称为数据映射表；具体的方法是为每个服务的输入数据指定来源，在Json结构的数据依赖表中，在变量名的对应值中预先填充一个JsonPath，JsonPath定位于另一个服务消息中的某一个具体的数据项。

在上述的一种基于元数据驱动的多样化服务的混合编排方法，服务编排模块用于：一方面基于BPMN可视化的流程编排界面进行服务编排，指定服务的调度顺序；另一方面指定服务调用之间的数据传递关系；两方面操作生成BPMN的流程定义和数据依赖关系定义，两者共同描述了一个流程中服务的执行顺序以及服务之间的数据交互,具体包括:

步骤4.1、基于BPMN指定服务的调度顺序；

BPMN中包含流对象和活动对象两个基本元素，分别表示流程中需要执行的任务和任务的顺序，本文通过BPMN中的活动对象描述一次服务调用，通过流对象描述服务的执行顺序，在BPMN2.0中，ServiceTask元素表示一个流程中的自动任务，sequenceFlow元素表示一个活动到下一个活动的执行顺序，如下图为上文所定义流程的BPMN文本描述，其中具体包含三个ServiceTask元素表示三次服务调用，其中的sequenceFlow表示了几次服务调用的执行顺序；同时本文结合服务元数据中的ServiceContext服务上下文和MethodContext方法上下文两个字段，在流程中指定一个活动调用的具体服务下的具体方法；

步骤4.2、定义统一的服务消息交互格式；

一个完整的流程定义包括两个部分，服务执行顺序的定义以及服务之间数据交互的定义，BPMN语言本身的特性能够很好的描述一系列活动的执行顺序，但是并不能全面的描述服务流程的信息，具体地说是无法描述服务之间的数据交互，对于此本文基于服务元数据定义了服务交互中的统一消息格式以及服务之间数据依赖的描述方法；

在流程编排阶段，服务数据传递规则无法基于BPMN语言指定；基于服务元数据，本文定义了统一的消息格式用于服务之间的数据交互；该数据结构为Json，具体结构如图7所示，该数据结构可以表示一个服务请求或一个服务返回，数据结构中的字段ServiceContext，MethodContext和DataName，分别对应服务元数据中的具体值；流程中服务的请求和返回都采用该格式，作为服务的请求消息时，DataName为元数据中的InputSchema输入项，作为输出消息时，对应元数据中输出项OutputSchema输出项的名称；

步骤4.3、基于元数据定义流程中的数据依赖；

借助于服务元数据和统一的消息格式定义一个流程中服务之间的数据交互,最后生成的数据依赖定义本文又称为数据映射表；具体的方法是为每个服务的输入数据指定来源，在图7的消息格式中，在DataName的对应value值中预先填充一个JsonPath，JsonPath定位于另一个服务消息中的某一个具体的数据项；

在流程执行中，在调用服务之前，根据流程中的数据依赖定义，从其他的服务消息中抽取所需数据，具体方法是根据数据项后面的JsonPath锁定导入具体的数据；比如对于流程中矢量数据获取以及矢量数据拼接两个服务，根据二者的数据依赖关系定义了JsonPath表示矢量数据拼接的数据来源于矢量数据获取服务的返回，量数据拼接的输入“vectorAddr1”来源于矢量数据获取的输出“DataFetch”；

步骤4.4、基于服务元数据自动解析服务消息；

适配器实现了标准化消息和实际服务的消息之间的转换；服务的元数据中定义了转换所需要的信息，包括服务地址、协议、消息格式等信息，同时消息格式中定义了消息中各个数据元素的语法细节，因此，利用服务的元信息，可以实现标准化消息和实际服务的消息之间的双向转换。

因此，本发明具有如下优点：1、本发明定义了服务交互的统一消息格式以及基于此格式的数据传递规则，在一定程度上解决了多样化服务编排的问题。2、本发明对多样化的服务协议类型具有可扩展的优点。3、本发明相比手工编码编排服务具有更短的服务编排耗时及更高的执行效率。

附图说明

图1是消息格式多样性。

图2是方法整体框架图。

图3是元数据概念模型图。

图4是元数据示例图。

图5是流程示例图。

图6基于BPMN的流程定义。

图7消息格式定义。

图8数据依赖定义。

图9服务调用流程图。

图10消息适配示例图。

图11元数据管理工具截图。

图12流程编排工具截图。

图13流程管理工具截图

具体实施方式

本文提出元数据驱动的多样化服务的的编排方法，服务元数据是对服务进行抽象的元数据建模。并构建服务适配器，服务适配器根据服务元数据将多样化的服务消息格式适配为统一消息格式，并在此消息格式上定义统一的数据交互模式。同时依靠BPMN定义流程中服务的执行顺序，最终实现多样化服务的服务编排。

一、本文方法的发明内容包括以下五点：

(一)服务的元数据建模

通过元数据对服务本身的属性进行描述。服务元数据支持两个阶段工作，服务编排和流程执行。具体为在服务编排阶段生成数据依赖定义，以及在服务执行阶段自动适配服务消息。基于服务元数据所支持的工作阶段不同，服务元数据所包含的信息被分为编排信息和适配信息。

服务的编排信息从输入输出的统一概念上描述服务，具体的输入项和输出项对应于应用层协议中的字段。服务的适配信息包含服务发布的所采用的底层协议信息，以及应用层的消息结构信息。内容上，服务的编排信息描述服务的基本输入项和输出项。

元数据中的适配信息则描述生成和解析服务消息时所需要的信息，比如对于一个RESTful服务，适配信息包括服务下每个方法的请求类型，每个参数的传递方式。比如对于SOAP服务，则包括SOAP消息体的命名空间。

本文提出元数据模型如图3所示，其中服务的编排信息抽象描述了服务的接口，以及接口的输入输出数据项。输入输出数据的自我关联表示一种层次结构，视输入项为一个对象，则它包含的属性可以细分为更多的输入项，即一个数据项可以细分为多个数据项。该抽象结构是为了在服务编排的设计阶段中为服务的一个输入数据项指定多个来源。图3中各个属性字段的具体含义如表1所示。

表1元数据属性信息

本文展示了两个具体服务的元数据实例，如图4所示，并围绕这两个服务讲解服务的编排过程。两个服务的名称分别为矢量数据查询服务以及图形拼接服务，前者是一个Restful服务，后者是OGC标准下的一个WPS服务。

矢量数据查询服务接受省市的地区编号，返回相应地区的矢量图形数据的地址。图形处理服务接受两个矢量数据的地址和一个坐标参考系进行图形拼接并且返回拼接后的矢量数据，其中ServiceMethods下的信息为元数据的编排信息。ServiceContext，ServiceAddress，ServiceProtocal等信息为元数据的适配信息。

本文将上文两个服务编排为一个流程，编排后的流程可以视为一个具有新功能的服务。该服务接收两个地区编号和一个坐标参考系，返回这两个地区的矢量数据进行拼接后的结果，流程示意图如图5所示。接下来本文结合该流程，具体描述BPMN的流程定义和数据依赖的定义。

(二)基于BPMN指定服务的调度顺序

BPMN中包含流对象和活动对象两个基本元素，分别表示流程中需要执行的任务和任务的顺序，本文通过BPMN中的活动对象描述一次服务调用，通过流对象描述服务的执行顺序，在BPMN2.0中，ServiceTask元素表示一个流程中的自动任务，sequenceFlow元素表示一个活动到下一个活动的执行顺序，如下图为上文所定义流程的BPMN文本描述，其中具体包含三个ServiceTask元素表示三次服务调用，其中的sequenceFlow表示了几次服务调用的执行顺序。同时本文结合服务元数据中的ServiceContext(服务上下文)和MethodContext(方法上下文)两个字段，在流程中指定一个活动调用的具体服务下的具体方法。

如图6所示，为上文流程的BPMN流程定义，该定义具体指定了流程中服务的执行顺序，具体调用了两次VectorDataFetch服务下的DataFecth方法两次，调用了VectorDataCombine服务下的DataCombine方法一次。

(三)定义统一的服务消息交互格式

一个完整的流程定义包括两个部分，服务执行顺序的定义以及服务之间数据交互的定义，BPMN语言本身的特性能够很好的描述一系列活动的执行顺序，但是并不能全面的描述服务流程的信息，具体地说是无法描述服务之间的数据交互，对于此本文基于服务元数据定义了服务交互中的统一消息格式以及服务之间数据依赖的描述方法。

在流程编排阶段，服务数据传递规则无法基于BPMN语言指定。基于服务元数据，本文定义了统一的消息格式用于服务之间的数据交互。该数据结构为Json，具体结构如图7所示，该数据结构可以表示一个服务请求或一个服务返回，数据结构中的字段ServiceContext，MethodContext和DataName，分别对应服务元数据中的具体值。流程中服务的请求和返回都采用该格式，作为服务的请求消息时，DataName为元数据中的InputSchema(输入项)，作为输出消息时，对应元数据中输出项OutputSchema(输出项)的名称。

(四)基于元数据定义流程中的数据依赖

借助于服务元数据和统一的消息格式定义一个流程中服务之间的数据交互,最后生成的数据依赖定义本文又称为数据映射表。具体的方法是为每个服务的输入数据指定来源，在图7的消息格式中，在DataName的对应value值中预先填充一个JsonPath，JsonPath定位于另一个服务消息中的某一个具体的数据项。

在流程执行中，在调用服务之前，根据流程中的数据依赖定义，从其他的服务消息中抽取所需数据，具体方法是根据数据项后面的JsonPath锁定导入具体的数据。比如对于流程中矢量数据获取以及矢量数据拼接两个服务，根据二者的数据依赖关系定义了JsonPath表示矢量数据拼接的数据来源于矢量数据获取服务的返回，如图8所示，矢量数据拼接的输入“vectorAddr1”来源于矢量数据获取的输出“DataFetch”。

(五)基于服务元数据自动解析服务消息

适配器实现了标准化消息和实际服务的消息之间的转换。服务的元数据中定义了转换所需要的信息，包括服务地址、协议、消息格式等信息，同时消息格式中定义了消息中各个数据元素的语法细节，因此，利用服务的元信息，可以实现标准化消息和实际服务的消息之间的双向转换。

举一个具体的消息适配实例，内容如图10所示，矢量数据拼接请求消息是流程中统一格式的请求消息，从矢量数据拼接服务的服务元数据了解到，底层的服务发布协议使用的是RESTful服务协议，请求类型为POST，需要传递的两个矢量数据和一个参考坐标系全部通过“BodyParam”即消息体的方式传输，同时还有服务的发布地址，上下文路径等基本信息，根据以上信息，服务适配器生成了最终的HTTP请求，具体将三个数据整理在一个Json结构的数据中，作为RESTful服务的HTTP请求的消息体，请求类型被设置为POST。

步骤五：编写元数据管理工具，流程执行引擎和服务消息适配器

二、下面是本发明的具体实施例。

本文提出了元数据驱动的服务编排框架，编排框架由三个模块，分别是元数据管理，服务编排模块以及流程执行模块。

根据所述方法实现了工具实例。工具由Java实现，采用Eclipse进行开发，部署在Tomcat下，通过Web应用的方式访问。整体分为两个模块，元数据管理模块和流程管理模块。元数据管理模块中采用MongoDB作为元数据的存储数据库，流程管理模块利用Acitivi开源流程引擎实现流程编排和流程执行。

元数据管理模块提供了对服务元数据进行增删该查的功能，提供了元数据展示界面，以及元数据的注册修改界面。流程管理模块提供了流程编排界面，以及流程的状态的管理界面。两个模块截图的如图10、11所示。

如图12所示，用户可以元数据管理界面中，查看，添加或修改服务元数据信息。在编排界面中可以通过图形化的操作进行服务编排，在流程管理界面中可以执行，挂起或终止已经部署的流程。

步骤一：编写元数据管理模块对服务元数据进行统一的增删改查管理操作，一个服务元数据的实例对应一个具体服务。服务编排模块和流程执行模块都依赖于元数据管理模块的服务元数据。

步骤二：编写服务编排模块，一方面基于BPMN可视化的流程编排界面进行服务编排，指定服务的调度顺序。另一方面指定服务调用之间的数据传递关系。两方面操作生成BPMN的流程定义和数据依赖关系定义，二者共同描述了一个流程中服务的执行顺序以及服务之间的数据交互。

步骤三：编写服务消息适配模块，根据BPMN流程定义依次调度各个服务，服务之间的数据交互依据已定义的数据依赖关系进行。在服务调度中，统一结构的消息与对应服务协议的消息自动适配，也就是说，给定统一结构的请求数据，自动地生成服务请求。给定服务的返回，自动解析为统一结构的返回数据。

本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。

Claims (5)

1.一种基于元数据驱动的多样化服务的混合编排方法，其特征在于，包括：

元数据管理模块：提供了对服务元数据进行增删该查的功能，提供了元数据展示界面，以及元数据的注册修改界面；流程管理模块提供了流程编排界面，以及流程的状态的管理界面；用户可以在元数据管理界面中，查看，添加或修改服务元数据信息；在编排界面中可以通过图形化的操作进行服务编排，在流程管理界面中可以执行，挂起或终止已经部署的流程；

服务编排模块：基于BPMN可视化的流程编排界面进行服务编排，指定服务的调度顺序；同时，指定服务调用之间的数据传递关系；两方面操作生成BPMN的流程定义和数据依赖关系定义，二者共同描述了一个流程中服务的执行顺序以及服务之间的数据交互；

流程执行模块：服务适配器根据服务元数据将多样化的服务消息格式适配为统一消息格式，并在此消息格式上定义统一的数据交互模式；同时依靠BPMN定义流程中服务的执行顺序，最终实现多样化服务的服务编排,在流程执行模块中，根据BPMN流程定义依次调度各个服务，服务之间的数据交互依据已定义的数据依赖关系进行；在服务调度中，统一结构的消息与对应服务协议的消息自动适配，也就是给定统一结构的请求数据，自动地生成服务请求；给定服务的返回，自动解析为统一结构的返回数据；

服务消息适配模块：实现了标准化消息和实际服务的消息之间的转换；服务的元数据中定义了转换所需要的信息，包括服务地址、协议、消息格式等信息，同时消息格式中定义了消息中各个数据元素的语法细节，因此，利用服务的元信息，可以实现标准化消息和实际服务的消息之间的双向转换。

2.根据权利要求1所述的一种基于元数据驱动的多样化服务的混合编排方法，其特征在于，元数据管理模块进行服务的元数据建模，具体是：

构建服务的描述数据，服务元数据支持两个阶段工作，服务编排和流程执行；具体为在服务编排阶段生成数据依赖定义，以及在服务执行阶段自动适配服务消息；基于服务元数据所支持的工作阶段不同，服务元数据所包含的信息被分为编排信息和适配信息；

服务的编排信息描述服务的基本输入项和输出项，输入输出项为应用层上的输入输出，元数据中的适配信息则描述生成和解析服务消息时所需要的信息。

3.根据权利要求1所述的一种基于元数据驱动的多样化服务的混合编排方法，其特征在于，服务消息适配模块定义统一的服务消息交互格式，具体是：在流程编排阶段，服务数据传递规则无法基于BPMN语言指定；基于服务元数据定义统一的Json消息格式用于服务之间的数据交互；该数据结构可以表示一个服务请求或一个服务返回，流程中服务的请求和返回都采用该格式，作为服务的请求消息时，Json的Key值为元数据中的输入项名称，作为输出消息时，对应元数据中输出项名称。

4.根据权利要求1所述的一种基于元数据驱动的多样化服务的混合编排方法，其特征在于，流程执行模块基于BPMN和服务元数据定义流程执行过程和数据依赖，具体是：

BPMN中包含流对象和活动对象两个基本元素，分别表示流程中需要执行的任务和任务的顺序，通过BPMN中的活动对象描述一次服务调用，通过流对象描述服务的执行顺序，在BPMN2.0中，ServiceTask元素表示一个流程中的自动任务，sequenceFlow元素表示一个活动到下一个活动的执行顺序，结合服务的元数据信息，在任务节点中指定服务调度的顺序；

借助于服务元数据和统一的Json消息格式定义一个流程中服务之间的数据交互,最后生成的数据依赖定义本文又称为数据映射表；具体的方法是为每个服务的输入数据指定来源，在Json结构的数据依赖表中，在变量名的对应值中预先填充一个JsonPath，JsonPath定位于另一个服务消息中的某一个具体的数据项。

5.根据权利要求1所述的一种基于元数据驱动的多样化服务的混合编排方法，其特征在于，服务编排模块用于：一方面基于BPMN可视化的流程编排界面进行服务编排，指定服务的调度顺序；另一方面指定服务调用之间的数据传递关系；两方面操作生成BPMN的流程定义和数据依赖关系定义，两者共同描述了一个流程中服务的执行顺序以及服务之间的数据交互,具体包括:

步骤4.1、基于BPMN指定服务的调度顺序；

BPMN中包含流对象和活动对象两个基本元素，分别表示流程中需要执行的任务和任务的顺序，本文通过BPMN中的活动对象描述一次服务调用，通过流对象描述服务的执行顺序，在BPMN2.0中，ServiceTask元素表示一个流程中的自动任务，sequenceFlow元素表示一个活动到下一个活动的执行顺序，如下图为上文所定义流程的BPMN文本描述，其中具体包含三个ServiceTask元素表示三次服务调用，其中的sequenceFlow表示了几次服务调用的执行顺序；同时本文结合服务元数据中的ServiceContext服务上下文和MethodContext方法上下文两个字段，在流程中指定一个活动调用的具体服务下的具体方法；

步骤4.2、定义统一的服务消息交互格式；

一个完整的流程定义包括两个部分，服务执行顺序的定义以及服务之间数据交互的定义，BPMN语言本身的特性能够很好的描述一系列活动的执行顺序，但是并不能全面的描述服务流程的信息，具体地说是无法描述服务之间的数据交互，对于此本文基于服务元数据定义了服务交互中的统一消息格式以及服务之间数据依赖的描述方法；

在流程编排阶段，服务数据传递规则无法基于BPMN语言指定；基于服务元数据，本文定义了统一的消息格式用于服务之间的数据交互；该数据结构为Json，具体结构如图7所示，该数据结构可以表示一个服务请求或一个服务返回，数据结构中的字段ServiceContext，MethodContext和DataName，分别对应服务元数据中的具体值；流程中服务的请求和返回都采用该格式，作为服务的请求消息时，DataName为元数据中的InputSchema输入项，作为输出消息时，对应元数据中输出项OutputSchema输出项的名称；

步骤4.3、基于元数据定义流程中的数据依赖；

借助于服务元数据和统一的消息格式定义一个流程中服务之间的数据交互,最后生成的数据依赖定义本文又称为数据映射表；具体的方法是为每个服务的输入数据指定来源，在图7的消息格式中，在DataName的对应value值中预先填充一个JsonPath，JsonPath定位于另一个服务消息中的某一个具体的数据项；

在流程执行中，在调用服务之前，根据流程中的数据依赖定义，从其他的服务消息中抽取所需数据，具体方法是根据数据项后面的JsonPath锁定导入具体的数据；比如对于流程中矢量数据获取以及矢量数据拼接两个服务，根据二者的数据依赖关系定义了JsonPath表示矢量数据拼接的数据来源于矢量数据获取服务的返回，量数据拼接的输入“vectorAddr1”来源于矢量数据获取的输出“DataFetch”；

步骤4.4、基于服务元数据自动解析服务消息；

适配器实现了标准化消息和实际服务的消息之间的转换；服务的元数据中定义了转换所需要的信息，包括服务地址、协议、消息格式等信息，同时消息格式中定义了消息中各个数据元素的语法细节，因此，利用服务的元信息，可以实现标准化消息和实际服务的消息之间的双向转换。