CN110618810A - Metadata-driven diversified service mixed arrangement method - Google Patents
Metadata-driven diversified service mixed arrangement method Download PDFInfo
- Publication number
- CN110618810A CN110618810A CN201910565669.8A CN201910565669A CN110618810A CN 110618810 A CN110618810 A CN 110618810A CN 201910565669 A CN201910565669 A CN 201910565669A CN 110618810 A CN110618810 A CN 110618810A
- Authority
- CN
- China
- Prior art keywords
- service
- metadata
- data
- message
- flow
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The diversity of service protocols brings the diversity of message structures, and the BPEL does not support the diversified service message structures, so that there is a problem that service interaction is not matched in the diversified service combinations. The invention provides a metadata-driven diversified service mixed arrangement method, which carries out metadata modeling on diversified services, describes a service message structure, utilizes metadata to convert diversified service messages by a service adapter, defines data interaction among services in a flow on a unified message structure, and totally combines a metadata-based data dependence definition and a BPMN definition to completely describe a flow. The feasibility of the method is verified through case testing and usability evaluation. The method solves the problem of diversified service arrangement to a certain extent, and can expand diversified service protocol types.
Description
Technical Field
The invention belongs to the field of service calculation, and particularly relates to a service arrangement method in a service combination.
Background
The concept of service composition is to use the existing Web services in the system to create new services to meet the needs of users by combining them in a certain order and changing the combination order. The basic idea of the process-driven WSC is to use the similarity of the WSC and a process model and use a mature process modeling tool and a language to model the WSC business process. The process-driven WSCs can be classified into three categories, namely workflow-based models, state-based algorithms and process-based algebra. A graphical operation interface is provided based on a workflow model, and a service designer defines an abstract service flow in a man-machine interaction mode and then automatically converts the abstract service flow into a workflow in a process engine. The semi-automatic service arrangement mode makes full use of the field knowledge of designers, reduces the workload of the designers and has good dynamic property and flexibility.
A definition language of BPMN business process is a language which can be understood by a set of business analysts, software developers and business managers, and aims to provide graphical modeling symbols for a service combination language such as BPEL, so that the design and implementation of the service combination can be seamlessly connected. It contains some basic element stream objects, join objects, lanes and workpieces. The stream object is composed of three types of active objects, events and gateways and is used for defining each subtask of the process. Whereas active objects are abstractions of business behavior. The connection objects represent associations between stream objects. Document [10] discusses the problem of describing the service interaction pattern according to BPMN2.0 and its overcoming method.
The typical processing method of service integration is an adapter and a message parser, the service adapter wraps the WEB application, and the message structure is converted, so that the services are interacted by using data with the same structure, and service combination is easier. The adapter types of the services can be classified into a compatible adapter and a replaceable adapter, the compatible adapter is used for adapting the message formats of the services so that the services can be mutually communicated, and the replaceable adapter makes up the function deficiency of the services to complement the function of the service combination. Service adaptation on the basis of interaction mismatch detection, correct interaction between services is realized by constructing adapters, such as a generation method of a semi-automatic service adapter called WSDL2 CODE.
Disclosure of Invention
The overall method schematic diagram is shown in fig. 2, and defines the execution sequence and data dependency relationship of scheduling of services in flow execution through BPMN and service metadata, and automatically parses service messages in diversified formats. The following technical scheme is adopted specifically:
a hybrid arrangement method based on metadata-driven diversified services is characterized by comprising the following steps:
a metadata management module: the function of adding and deleting the service metadata is provided, a metadata display interface and a metadata registration modification interface are provided; the process management module provides a process arrangement interface and a management interface of the state of the process; the user can view, add or modify the service metadata information in the metadata management interface; service arrangement can be carried out through graphical operation in the arrangement interface, and the processes which are already deployed can be executed, suspended or terminated in the process management interface;
a service orchestration module: performing service arrangement based on a BPMN visual flow arrangement interface, and appointing a service scheduling sequence; meanwhile, a data transfer relation between service calls is specified; the two-aspect operation generates a flow definition and a data dependency relationship definition of the BPMN, and the flow definition and the data dependency relationship definition describe the execution sequence of the services in one flow and the data interaction between the services together;
a flow execution module: the service adapter adapts diversified service message formats into a uniform message format according to the service metadata, and defines a uniform data interaction mode on the message format; meanwhile, the execution sequence of the services in the flow is defined by the BPMN, the service arrangement of diversified services is finally realized, in the flow execution module, each service is sequentially scheduled according to the BPMN flow definition, and the data interaction among the services is carried out according to the defined data dependency relationship; in service scheduling, the message of the unified structure is automatically adapted to the message of the corresponding service protocol, that is, the request data of the unified structure is given, and a service request is automatically generated; given the return of the service, automatically analyzing the return data into a unified structure;
a service message adaptation module: the conversion between the standardized message and the actual service message is realized; the metadata of the service defines the information required for conversion, including information of service address, protocol, message format, etc., and the message format defines the syntax details of each data element in the message, so that the service metadata can be used to realize the bidirectional conversion between the standardized message and the actual service message.
In the above hybrid arrangement method for diversified services based on metadata driving, the metadata management module performs metadata modeling of the services, specifically:
constructing description data of the service, wherein the service metadata supports two-stage work, service arrangement and flow execution; specifically, a data dependence definition is generated in a service arrangement stage, and a service message is automatically adapted in a service execution stage; based on different working stages supported by the service metadata, the information contained in the service metadata is divided into arrangement information and adaptation information;
the arrangement information of the service describes basic input items and output items of the service, the input and output items are input and output on an application layer, and the adaptation information in the metadata describes information required when the service message is generated and analyzed.
In the above mixed arrangement method for diversified services based on metadata driving, the service message adaptation module defines a uniform service message interaction format, which specifically includes: in the process arrangement stage, the service data transmission rule cannot be specified based on BPMN language; defining a unified Json message format for data interaction between services based on the service metadata; the data structure can represent a service request or a service return, the request and the return of the service in the process both adopt the format, when the request message is used as the request message of the service, the Key value of Json is the name of an input item in the metadata, and when the request message is used as the output message, the name of an output item in the corresponding metadata is corresponded.
In the above method for hybrid arrangement of metadata-driven diversified services, the flow execution module defines a flow execution process and data dependency based on BPMN and service metadata, and specifically includes:
the BPMN comprises two basic elements of a flow object and an activity object, which respectively represent tasks to be executed in the flow and the sequence of the tasks, the activity object in the BPMN describes service calling once, the execution sequence of the service is described by the flow object, in the BPMN2.0, a ServiceTask element represents an automatic task in one flow, a sequence flow element represents the execution sequence from one activity to the next activity, and the sequence of service scheduling is specified in a task node by combining metadata information of the service;
defining data interaction between services in a process by means of service metadata and a uniform Json message format, wherein the finally generated data dependence definition is also called a data mapping table; the specific method is that a source is designated for input data of each service, in a data dependency table of a Json structure, a JsonPath is pre-filled in a corresponding value of a variable name, and the JsonPath is positioned in a specific data item in another service message.
In the hybrid arranging method for diversified services based on metadata driving, the service arranging module is configured to: on one hand, service arrangement is carried out based on a BPMN visual flow arrangement interface, and the scheduling sequence of the service is specified; on the other hand, specifying data transfer relationships between service calls; the two-aspect operation generates a flow definition and a data dependency relationship definition of the BPMN, and the two definitions describe an execution sequence of services in a flow and data interaction between the services, and specifically includes:
step 4.1, appointing a service scheduling sequence based on the BPMN;
the BPMN includes two basic elements, namely a flow object and an activity object, which respectively represent tasks to be executed in the flow and the sequence of the tasks, the document describes a service call through the activity object in the BPMN, and describes the execution sequence of the services through the flow object, in the BPMN2.0, a ServiceTask element represents an automatic task in one flow, and a sequence flow element represents the execution sequence from one activity to the next activity, as shown in the following figure, the BPMN text description of the flow defined above specifically includes three ServiceTask elements representing three service calls, and the sequence flow represents the execution sequence of several service calls; meanwhile, the text is combined with two fields of a ServiceContext service context and a MethodContext method context in the service metadata, and a specific method under a specific service called by an activity is specified in a flow;
step 4.2, defining a uniform service message interaction format;
a complete flow definition comprises two parts, namely definition of service execution sequence and definition of data interaction between services, wherein the characteristic of BPMN language can well describe the execution sequence of a series of activities, but cannot comprehensively describe information of service flow, in particular cannot describe data interaction between services, and for the definition, a description method of uniform message format and data dependency between services in service interaction is defined based on service metadata;
in the process arrangement stage, the service data transmission rule cannot be specified based on BPMN language; based on the service metadata, a unified message format is defined herein for data interaction between services; the data structure is Json, the specific structure is shown in fig. 7, the data structure can represent a service request or a service return, and the fields ServiceContext, MethodContext and DataName in the data structure respectively correspond to specific values in the service metadata; the request and the return of the service in the process both adopt the format, when the request and the return are used as a request message of the service, the DataName is an input item of an input schema in the metadata, and when the request and the return are used as an output message, the DataName corresponds to the name of an output item of the output schema in the metadata;
4.3, defining data dependence in the flow based on the metadata;
defining data interaction between services in a process by means of service metadata and a uniform message format, wherein the finally generated data dependence definition is also called a data mapping table; the specific method is that a source is designated for input data of each service, in the message format of fig. 7, a JsonPath is pre-filled in a corresponding value of the DataName, and the JsonPath is positioned in a specific data item in another service message;
in the process of executing the flow, before calling the service, extracting required data from other service messages according to the data dependency definition in the flow, wherein the specific method is to lock and import specific data according to JsonPath behind a data item; for example, for two services of vector data acquisition and vector data splicing in the flow, JsonPath is defined according to the data dependency relationship between the two services to indicate that the data for vector data splicing comes from the return of the vector data acquisition service, and the input "vectorAddr 1" for volume data splicing comes from the output "DataFetch" for vector data acquisition;
step 4.4, automatically analyzing the service message based on the service metadata;
the adapter realizes the conversion between the standardized message and the actual service message; the metadata of the service defines the information required for conversion, including information of service address, protocol, message format, etc., and the message format defines the syntax details of each data element in the message, so that the service metadata can be used to realize the bidirectional conversion between the standardized message and the actual service message.
Therefore, the invention has the following advantages: 1. the invention defines the uniform message format of service interaction and the data transmission rule based on the format, and solves the problem of diversified service arrangement to a certain extent. 2. The invention has the advantage of being extensible to diversified service protocol types. 3. Compared with manual coding arrangement service, the invention has shorter service arrangement time consumption and higher execution efficiency.
Drawings
Fig. 1 is a message format diversity.
FIG. 2 is a method overall framework diagram.
FIG. 3 is a conceptual model diagram of metadata.
Fig. 4 is an exemplary diagram of metadata.
Fig. 5 is a flowchart.
Fig. 6 is based on the flow definition of BPMN.
Fig. 7 message format definition.
FIG. 8 data dependency definition.
FIG. 9 service invocation flow diagram.
Fig. 10 message adaptation example diagram.
FIG. 11 is a metadata management tool screenshot.
FIG. 12 is a flowchart of an orchestration tool screenshot.
FIG. 13 flow management tool screenshot
Detailed Description
A method for orchestration of metadata driven diverse services is presented herein, service metadata being metadata modeling that abstracts the services. And constructing a service adapter, wherein the service adapter adapts diversified service message formats into a uniform message format according to the service metadata, and defines a uniform data interaction mode on the message format. Meanwhile, the execution sequence of the services in the flow is defined by the BPMN, and finally the service arrangement of diversified services is realized.
The invention content of the method comprises the following five points:
metadata modeling of (A) services
The attributes of the service itself are described by the metadata. The service metadata supports two phases of work, service orchestration and flow execution. In particular, data dependency definitions are generated during a service orchestration phase, and service messages are automatically adapted during a service execution phase. Based on different working phases supported by the service metadata, the information contained in the service metadata is divided into arrangement information and adaptation information.
The orchestration information of services describes services conceptually from a unity of input and output, with specific input and output items corresponding to fields in the application layer protocol. The adaptation information of the service includes the information of the underlying protocol used for service publishing and the information of the message structure of the application layer. In content, the orchestration information of a service describes the basic input items and output items of the service.
The adaptation information in the metadata describes information required for generating and parsing the service message, for example, for a RESTful service, the adaptation information includes a request type of each method under the service, and a transfer manner of each parameter. Such as for a SOAP service, a namespace for the body of the SOAP message is included.
The metadata model proposed herein is illustrated in fig. 3, where the orchestration information abstraction of a service describes the interface of the service, and the input and output data items of the interface. The self-association of input and output data represents a hierarchical structure, and the attribute contained in an input item can be subdivided into more input items according to the condition that the input item is an object, namely, one data item can be subdivided into a plurality of data items. The abstract structure is to specify multiple sources for an input data item of a service during the design phase of the service layout. The specific meanings of the respective attribute fields in fig. 3 are shown in table 1.
TABLE 1 metadata attribute information
This document shows metadata examples of two specific services, as shown in FIG. 4, and explains the orchestration process of the services around the two services. The two services are named as a vector data query service and a graph splicing service respectively, wherein the former is a Restful service, and the latter is a WPS service under the OGC standard.
The vector data query service receives the region number of province and city and returns the address of the vector graphics data of the corresponding region. And the graphics processing service receives the addresses of the two pieces of vector data and a coordinate reference system to perform graphics splicing and returns the spliced vector data, wherein the information under the ServiceMethods is the arrangement information of the metadata. Information such as ServiceContext, ServiceAddress, serviceprotocol, etc. is adaptation information of the metadata.
The two services are organized into a flow, and the organized flow can be regarded as a service with a new function. The service receives two area numbers and a coordinate reference system, returns the result of splicing the vector data of the two areas, and the flow diagram is shown in fig. 5. The flow definition and data dependency definition of BPMN are described in detail herein below in conjunction with the flow.
(II) specifying scheduling order of services based on BPMN
The BPMN includes two basic elements, namely a flow object and an activity object, which respectively represent tasks to be executed in the flow and the sequence of the tasks, the single service call is described by the activity object in the BPMN, the execution sequence of the services is described by the flow object, in the BPMN2.0, the ServiceTask element represents an automatic task in one flow, and the sequence flow element represents the execution sequence from one activity to the next activity, as shown in the following figure, the BPMN text description of the flow defined above specifically includes three ServiceTask elements representing three service calls, and the sequence flow represents the execution sequence of several service calls. Meanwhile, the text combines two fields of ServiceContext and method context in the service metadata to specify a specific method under a specific service called by an activity in the flow.
As shown in fig. 6, for the BPMN flow definition of the above flow, the definition specifically specifies the execution order of the services in the flow, specifically calls the DataFecth method twice under the vectordafetch service, and calls the DataCombine method once under the vectordacombo service.
(III) defining a unified service message interaction format
A complete flow definition comprises two parts, namely definition of service execution sequence and definition of data interaction between services, and the BPMN language has characteristics of well describing the execution sequence of a series of activities, but can not describe information of service flow comprehensively, particularly data interaction between services, and for the definition, a description method of uniform message format in service interaction and data dependence between services is defined based on service metadata.
In the process arrangement stage, the service data delivery rule cannot be specified based on the BPMN language. Based on the service metadata, a unified message format is defined herein for data interaction between services. The data structure is Json, the specific structure is shown in fig. 7, the data structure may represent a service request or a service return, and the fields ServiceContext, MethodContext, and DataName in the data structure respectively correspond to specific values in the service metadata. The request and return of the service in the flow both adopt the format, when the request message is used as a request message of the service, the DataName is an input item in the metadata, and when the request message is used as an output message, the DataName corresponds to the name of an output item OutputSchema in the metadata.
(IV) defining data dependencies in a flow based on metadata
The data interaction between services in a flow is defined by means of service metadata and a unified message format, and the finally generated data dependency definition is also referred to herein as a data mapping table. A specific method is to specify a source for input data of each service, and in the message format of fig. 7, a JsonPath is pre-filled in a corresponding value of the DataName, and the JsonPath is located in a specific data item in another service message.
In the process execution, before calling the service, required data is extracted from other service messages according to the data dependency definition in the process, and the specific method is to import specific data according to the JsonPath lock behind the data item. For example, for two services of vector data acquisition and vector data splicing in the flow, JsonPath is defined according to the data dependency relationship between the two services to indicate that the data for vector data splicing is derived from the return of the vector data acquisition service, as shown in fig. 8, the input "vectorAddr 1" of vector data splicing is derived from the output "DataFetch" of vector data acquisition.
(V) automatically parsing service messages based on service metadata
The adapter enables conversion between standardized messages and messages of the actual service. The metadata of the service defines the information required for conversion, including information of service address, protocol, message format, etc., and the message format defines the syntax details of each data element in the message, so that the service metadata can be used to realize the bidirectional conversion between the standardized message and the actual service message.
As a specific message adaptation example, the content is shown in fig. 10, the vector data splicing request message is a request message in a unified format in the process, it is known from the service metadata of the vector data splicing service that a RESTful service protocol is used by a service publishing protocol at the bottom layer, the request type is POST, two vector data and a reference coordinate system which need to be transferred are all transmitted in a "body param" manner, and basic information such as a publishing address of the service, a context path, and the like is also included.
Step five: authoring metadata management tools, process execution engines and service message adapters
Second, the following is a specific embodiment of the present invention.
The metadata-driven service arrangement framework is provided, and comprises three modules, namely a metadata management module, a service arrangement module and a process execution module.
An example of a tool is implemented according to the method. The tool is realized by Java, is developed by Eclipse, is deployed under Tomcat and is accessed in a Web application mode. The whole system is divided into two modules, namely a metadata management module and a process management module. The metadata management module adopts MongoDB as a storage database of metadata, and the process management module realizes process arrangement and process execution by utilizing an Acitivi open source process engine.
The metadata management module provides functions of adding and deleting the service metadata, provides a metadata display interface and a metadata registration modification interface. The process management module provides a process arrangement interface and a management interface of the state of the process. The screenshots of the two modules are shown in FIGS. 10 and 11.
As shown in fig. 12, a user may view, add, or modify service metadata information in a metadata management interface. The service arrangement can be carried out through graphical operation in the arrangement interface, and the processes which are already deployed can be executed, suspended or terminated in the process management interface.
The method comprises the following steps: the metadata writing management module performs unified operations of adding, deleting, modifying and checking the service metadata, and one instance of the service metadata corresponds to one specific service. The service arranging module and the flow executing module are both dependent on the service metadata of the metadata management module.
Step two: and writing a service arranging module, on one hand, carrying out service arranging based on a BPMN visual flow arranging interface, and appointing a service scheduling sequence. Another aspect specifies data transfer relationships between service calls. The two-way operation generates a flow definition and a data dependency definition of the BPMN, which together describe the execution order of services in a flow and the data interaction between services.
Step three: and writing a service message adaptation module, and scheduling each service in turn according to the BPMN process definition, wherein data interaction among the services is carried out according to the defined data dependency relationship. In service scheduling, the messages of the unified structure are automatically adapted to the messages of the corresponding service agreement, that is to say the service request is automatically generated given the request data of the unified structure. Given the return of the service, the return data is automatically parsed into a unified structure.
The specific embodiments described herein are merely illustrative of the spirit of the invention. Various modifications or additions may be made to the described embodiments or alternatives may be employed by those skilled in the art without departing from the spirit or ambit of the invention as defined in the appended claims.
Claims (5)
1. A hybrid arrangement method based on metadata-driven diversified services is characterized by comprising the following steps:
a metadata management module: the function of adding and deleting the service metadata is provided, a metadata display interface and a metadata registration modification interface are provided; the process management module provides a process arrangement interface and a management interface of the state of the process; the user can view, add or modify the service metadata information in the metadata management interface; service arrangement can be carried out through graphical operation in the arrangement interface, and the processes which are already deployed can be executed, suspended or terminated in the process management interface;
a service orchestration module: performing service arrangement based on a BPMN visual flow arrangement interface, and appointing a service scheduling sequence; meanwhile, a data transfer relation between service calls is specified; the two-aspect operation generates a flow definition and a data dependency relationship definition of the BPMN, and the flow definition and the data dependency relationship definition describe the execution sequence of the services in one flow and the data interaction between the services together;
a flow execution module: the service adapter adapts diversified service message formats into a uniform message format according to the service metadata, and defines a uniform data interaction mode on the message format; meanwhile, the execution sequence of the services in the flow is defined by the BPMN, the service arrangement of diversified services is finally realized, in the flow execution module, each service is sequentially scheduled according to the BPMN flow definition, and the data interaction among the services is carried out according to the defined data dependency relationship; in service scheduling, the message of the unified structure is automatically adapted to the message of the corresponding service protocol, that is, the request data of the unified structure is given, and a service request is automatically generated; given the return of the service, automatically analyzing the return data into a unified structure;
a service message adaptation module: the conversion between the standardized message and the actual service message is realized; the metadata of the service defines the information required for conversion, including information of service address, protocol, message format, etc., and the message format defines the syntax details of each data element in the message, so that the service metadata can be used to realize the bidirectional conversion between the standardized message and the actual service message.
2. The hybrid orchestration method based on metadata-driven diverse services according to claim 1, wherein the metadata management module performs metadata modeling of the services, specifically:
constructing description data of the service, wherein the service metadata supports two-stage work, service arrangement and flow execution; specifically, a data dependence definition is generated in a service arrangement stage, and a service message is automatically adapted in a service execution stage; based on different working stages supported by the service metadata, the information contained in the service metadata is divided into arrangement information and adaptation information;
the arrangement information of the service describes basic input items and output items of the service, the input and output items are input and output on an application layer, and the adaptation information in the metadata describes information required when the service message is generated and analyzed.
3. The method according to claim 1, wherein the service message adaptation module defines a uniform service message interaction format, specifically: in the process arrangement stage, the service data transmission rule cannot be specified based on BPMN language; defining a unified Json message format for data interaction between services based on the service metadata; the data structure can represent a service request or a service return, the request and the return of the service in the process both adopt the format, when the request message is used as the request message of the service, the Key value of Json is the name of an input item in the metadata, and when the request message is used as the output message, the name of an output item in the corresponding metadata is corresponded.
4. The method according to claim 1, wherein the flow execution module defines flow execution procedures and data dependencies based on the BPMN and the service metadata, and specifically comprises:
the BPMN comprises two basic elements of a flow object and an activity object, which respectively represent tasks to be executed in the flow and the sequence of the tasks, the activity object in the BPMN describes service calling once, the execution sequence of the service is described by the flow object, in the BPMN2.0, a ServiceTask element represents an automatic task in one flow, a sequence flow element represents the execution sequence from one activity to the next activity, and the sequence of service scheduling is specified in a task node by combining metadata information of the service;
defining data interaction between services in a process by means of service metadata and a uniform Json message format, wherein the finally generated data dependence definition is also called a data mapping table; the specific method is that a source is designated for input data of each service, in a data dependency table of a Json structure, a JsonPath is pre-filled in a corresponding value of a variable name, and the JsonPath is positioned in a specific data item in another service message.
5. The hybrid orchestration method based on diverse services driven by metadata according to claim 1, wherein the service orchestration module is configured to: on one hand, service arrangement is carried out based on a BPMN visual flow arrangement interface, and the scheduling sequence of the service is specified; on the other hand, specifying data transfer relationships between service calls; the two-aspect operation generates a flow definition and a data dependency relationship definition of the BPMN, and the two definitions describe an execution sequence of services in a flow and data interaction between the services, and specifically includes:
step 4.1, appointing a service scheduling sequence based on the BPMN;
the BPMN includes two basic elements, namely a flow object and an activity object, which respectively represent tasks to be executed in the flow and the sequence of the tasks, the document describes a service call through the activity object in the BPMN, and describes the execution sequence of the services through the flow object, in the BPMN2.0, a ServiceTask element represents an automatic task in one flow, and a sequence flow element represents the execution sequence from one activity to the next activity, as shown in the following figure, the BPMN text description of the flow defined above specifically includes three ServiceTask elements representing three service calls, and the sequence flow represents the execution sequence of several service calls; meanwhile, the text is combined with two fields of a ServiceContext service context and a MethodContext method context in the service metadata, and a specific method under a specific service called by an activity is specified in a flow;
step 4.2, defining a uniform service message interaction format;
a complete flow definition comprises two parts, namely definition of service execution sequence and definition of data interaction between services, wherein the characteristic of BPMN language can well describe the execution sequence of a series of activities, but cannot comprehensively describe information of service flow, in particular cannot describe data interaction between services, and for the definition, a description method of uniform message format and data dependency between services in service interaction is defined based on service metadata;
in the process arrangement stage, the service data transmission rule cannot be specified based on BPMN language; based on the service metadata, a unified message format is defined herein for data interaction between services; the data structure is Json, the specific structure is shown in fig. 7, the data structure can represent a service request or a service return, and the fields ServiceContext, MethodContext and DataName in the data structure respectively correspond to specific values in the service metadata; the request and the return of the service in the process both adopt the format, when the request and the return are used as a request message of the service, the DataName is an input item of an input schema in the metadata, and when the request and the return are used as an output message, the DataName corresponds to the name of an output item of the output schema in the metadata;
4.3, defining data dependence in the flow based on the metadata;
defining data interaction between services in a process by means of service metadata and a uniform message format, wherein the finally generated data dependence definition is also called a data mapping table; the specific method is that a source is designated for input data of each service, in the message format of fig. 7, a JsonPath is pre-filled in a corresponding value of the DataName, and the JsonPath is positioned in a specific data item in another service message;
in the process of executing the flow, before calling the service, extracting required data from other service messages according to the data dependency definition in the flow, wherein the specific method is to lock and import specific data according to JsonPath behind a data item; for example, for two services of vector data acquisition and vector data splicing in the flow, JsonPath is defined according to the data dependency relationship between the two services to indicate that the data for vector data splicing comes from the return of the vector data acquisition service, and the input "vectorAddr 1" for volume data splicing comes from the output "DataFetch" for vector data acquisition;
step 4.4, automatically analyzing the service message based on the service metadata;
the adapter realizes the conversion between the standardized message and the actual service message; the metadata of the service defines the information required for conversion, including information of service address, protocol, message format, etc., and the message format defines the syntax details of each data element in the message, so that the service metadata can be used to realize the bidirectional conversion between the standardized message and the actual service message.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910565669.8A CN110618810A (en) | 2019-06-27 | 2019-06-27 | Metadata-driven diversified service mixed arrangement method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910565669.8A CN110618810A (en) | 2019-06-27 | 2019-06-27 | Metadata-driven diversified service mixed arrangement method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110618810A true CN110618810A (en) | 2019-12-27 |
Family
ID=68921751
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910565669.8A Withdrawn CN110618810A (en) | 2019-06-27 | 2019-06-27 | Metadata-driven diversified service mixed arrangement method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110618810A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112243032A (en) * | 2020-10-15 | 2021-01-19 | 江苏云坤信息科技有限公司 | Service calling method and system based on access gateway |
| CN113791775A (en) * | 2020-08-21 | 2021-12-14 | 北京京东振世信息技术有限公司 | Metadata flow arrangement method and device, storage medium and electronic equipment |
| CN113923250A (en) * | 2020-07-07 | 2022-01-11 | 华为技术有限公司 | Method, device and system for assisting network service arrangement |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080071908A1 (en) * | 2006-09-18 | 2008-03-20 | Emc Corporation | Information management |
| CN107343018A (en) * | 2017-01-04 | 2017-11-10 | 成都华栖云科技有限公司 | The application service method of combination and system of a kind of PaaS cloud platforms |
| CN108845798A (en) * | 2018-05-30 | 2018-11-20 | 安徽四创电子股份有限公司 | A kind of visualization big data task cradle and processing method |
-
2019
- 2019-06-27 CN CN201910565669.8A patent/CN110618810A/en not_active Withdrawn
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080071908A1 (en) * | 2006-09-18 | 2008-03-20 | Emc Corporation | Information management |
| CN107343018A (en) * | 2017-01-04 | 2017-11-10 | 成都华栖云科技有限公司 | The application service method of combination and system of a kind of PaaS cloud platforms |
| CN108845798A (en) * | 2018-05-30 | 2018-11-20 | 安徽四创电子股份有限公司 | A kind of visualization big data task cradle and processing method |
Non-Patent Citations (1)
| Title |
|---|
| 张光宇等: "元数据驱动的多样化服务的混合编排方法", 《计算机应用研究》 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113923250A (en) * | 2020-07-07 | 2022-01-11 | 华为技术有限公司 | Method, device and system for assisting network service arrangement |
| CN113791775A (en) * | 2020-08-21 | 2021-12-14 | 北京京东振世信息技术有限公司 | Metadata flow arrangement method and device, storage medium and electronic equipment |
| CN113791775B (en) * | 2020-08-21 | 2024-03-01 | 北京京东振世信息技术有限公司 | Metadata flow arranging method and device, storage medium and electronic equipment |
| CN112243032A (en) * | 2020-10-15 | 2021-01-19 | 江苏云坤信息科技有限公司 | Service calling method and system based on access gateway |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8209710B2 (en) | Implementation system for business applications | |
| US8234308B2 (en) | Deliver application services through business object views | |
| US7219328B2 (en) | Model-based composable code generation | |
| US7437277B2 (en) | Model independent simulation | |
| CN110618810A (en) | Metadata-driven diversified service mixed arrangement method | |
| JP2006107479A (en) | Framework for modeling cross-cutting behavioral concerns inside work flow region | |
| US20050108684A1 (en) | Method and system for generating an application object repository from application framework metadata | |
| Channa et al. | Constraint satisfaction in dynamic web service composition | |
| US20120060141A1 (en) | Integrated environment for software design and implementation | |
| Harmsen et al. | Comparison of four method engineering languages | |
| de Boer et al. | Enterprise architecture analysis with xml | |
| CN102375743B (en) | SOA(Service-Oriented Architecture) system development method based on model and template | |
| Ma et al. | Bpel fragments for modularized reuse in modeling bpel processes | |
| Costa et al. | The application of UML and an open distributed process framework to information system design | |
| Lahoud et al. | OCEAN: A semantic web service to extract knowledge in E-Groupwares | |
| Sobolewski | Unifying front-end and back-end federated services for integrated product development | |
| Maarouf et al. | XML integrated environment for service-oriented data management | |
| Gonen et al. | Ontological support for the evolution of future services oriented architectures | |
| Tann et al. | The collaboration modelling framework for ship structural design | |
| Angelaccio et al. | A model transformation framework to boost productivity and creativity in collaborative working environments | |
| Menkhaus et al. | Legacy system integration using a grammar-based transformation system | |
| Fernando et al. | Towards build-time interoperability of workflow definition languages | |
| zur Muehlen et al. | Workflow Process Definition Language–Development and Directions of a Meta-Language for Workflow Processes | |
| Cabral et al. | Translating Semantic Web Service based business process models | |
| Wang et al. | Service change analyzer: An enabling tool for change management in service-based business processes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WW01 | Invention patent application withdrawn after publication | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20191227 |