CN118259880A - Rule chain-based service combination interface design method - Google Patents
Rule chain-based service combination interface design method Download PDFInfo
- Publication number
- CN118259880A CN118259880A CN202410423751.8A CN202410423751A CN118259880A CN 118259880 A CN118259880 A CN 118259880A CN 202410423751 A CN202410423751 A CN 202410423751A CN 118259880 A CN118259880 A CN 118259880A
- Authority
- CN
- China
- Prior art keywords
- service
- data
- component
- rule
- interface
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 238000013461 design Methods 0.000 title claims abstract description 15
- 230000003993 interaction Effects 0.000 claims abstract description 40
- 238000011161 development Methods 0.000 claims abstract description 23
- 238000004458 analytical method Methods 0.000 claims abstract description 13
- 230000005540 biological transmission Effects 0.000 claims abstract description 9
- 230000008569 process Effects 0.000 claims description 15
- 238000012545 processing Methods 0.000 claims description 12
- 230000001419 dependent effect Effects 0.000 claims description 7
- 238000004573 interface analysis Methods 0.000 claims description 4
- 210000001503 joint Anatomy 0.000 claims description 3
- 238000007405 data analysis Methods 0.000 claims description 2
- 238000010276 construction Methods 0.000 abstract description 2
- 238000010606 normalization Methods 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 8
- 238000012546 transfer Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 4
- 239000000203 mixture Substances 0.000 description 4
- 230000006978 adaptation Effects 0.000 description 2
- 230000000712 assembly Effects 0.000 description 2
- 238000000429 assembly Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013075 data extraction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000009472 formulation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/42—Syntactic analysis
- G06F8/427—Parsing
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The application provides a service combination interface design method based on a rule chain, which comprises the following steps: according to the service combination entry parsing rule and in combination with the service component interface description, an entry data format is formulated; carrying out standardized development on a service component interface by utilizing a service component interface rule to complete interface design; according to the service protocol, the design of each part of the component is completed, and the development flow of the component is standardized; summarizing the output data requirements of the service components according to the self requirements, and formulating an export data format according to the service combination export analysis rule; and combining interaction requirements with other service components, and normalizing the component interaction mode according to the component interaction protocol and the characteristics of a rule chain. The application realizes the effects of simplifying the service combination difficulty, accelerating the code normalization and improving the development efficiency, and can lead the user to rapidly complete the construction, interaction and data transmission of the service assembly according to the own requirements and application fields under the condition of insufficient professional knowledge.
Description
Technical Field
The invention belongs to the field of cloud native micro-service combination, which is used for service combination based on a rule chain, combines nodejs with the existing micro-service technology and standard, and is applied to the field of service combination and service arrangement combination of a medium and small-sized enterprise industrial internet platform.
Background
With the continuous trend of the times, the continuous breakthrough of science and technology is carried out, so that various software platforms are continuously developed in the market and enterprises at present, and meanwhile, the industry is gradually becoming a daily and varied environment, and the competition in the industry is becoming more and more severe. Under the environment, the requirements for enterprises are gradually increased, the enterprises are required to respond to the severely-changed market environment rapidly and timely, the self business is continuously adjusted, and the development speed is increased. In order to meet the development of the environment, the system applied in the enterprise is gradually changed from a single system to a distributed system, and meanwhile, how to realize rapid adjustment of the development process according to the requirement to replace the traditional development process becomes the focus in recent years.
Papazoglou teaches that: "service-oriented computing" is a new computing paradigm that uses services as the basic computing units to support the development of fast, low-cost, easily interactable, easily evolving, large-scale distributed applications. Service computing integrates service concepts, enabling the development of more complex services by assembling reusable services, i.e., service portfolios. The service combination is to quickly synthesize simple and basic reusable services into more complex services through a good interface, so that more powerful functions can be provided, the requirements of quick adjustment and development according to the requirements are met, and the complex and changeable task requirements in the actual production environment are completed.
With the development of service computing and cloud native, service composition applications are more and more developed, but at the same time, because of the flexibility of service composition, and a higher development requirement and application requirement for developers and application personnel, common workers cannot freely use the cloud platforms without a threshold, and meanwhile, the development difficulty of the developers on the whole system is increased.
In general, a common worker needs to correctly subscribe to a complex service, needs to fully understand the parameters of the input and output and the interface of the service, otherwise cannot be correctly executed, and meanwhile, if a developer wants to develop a new service, the input and output target types of the target service are sometimes ambiguous, so that interaction failure or increased interaction difficulty is caused when the service is interacted with other service components, meanwhile, the data of an instrument are also disordered, and a certain workload is required for extracting effective information from unprocessed data by the service. The rule chain can effectively restrict the development process of developers, and a unified interface interaction standard is constructed, so that the requirement of unified interaction management is further met, the standardization of the whole system can be greatly improved, the development efficiency is further improved, and the enterprise requirement is met.
Disclosure of Invention
In order to solve the problems, the invention provides a service combination interface design method based on a rule chain, according to the characteristics of service combination flexibility, the contents of an application layer entry analysis specification, an exit analysis specification, an interface description specification, a service specification, a component interaction specification and the like are researched, an industrial interconnection technology service platform application service unified interface for middle and small enterprises is provided, the unified specification and convention of a technology service platform application layer user interface, an external interface and an internal interface are realized, a service combination scheme adapting to the rule chain is constructed, the service combination difficulty is simplified, the code normalization is accelerated, the development efficiency is improved, and a user can quickly complete the construction and interaction of a service component and data transmission according to own requirements and application fields under the condition of insufficient professional knowledge.
The technical scheme of the invention is as follows:
A service combination interface design method based on a rule chain comprises the following steps:
Step S1, summarizing commonalities of project input data according to self requirements, and formulating an entry data format according to service combination entry analysis rules and service component interface description;
S2, utilizing service component interface rules to develop the service component interface in a standardized way, and completing interface design;
step S3, when the service component is developed, the design of each part of the component is completed according to the service protocol, and the component development flow is standardized;
Step S4, summarizing the output data requirements of the service assembly according to the self requirements, and formulating an export data format according to the service combination export analysis rule;
And S5, combining interaction requirements with other service components, and normalizing the component interaction mode according to the component interaction protocol and the characteristics of a rule chain.
Further, the step S1 includes:
Step S1-1: searching for commonality among input data based on the existing service combination input data, and performing data processing;
Step S1-2: according to the entry analysis rule, carrying out standardization processing on the data, and adding various fields for data analysis;
step S1-3: normalized data, extracting and abstracting service combination input data into the following types of input, command class, string class, image class, voice class, video class, file class, zip class, number class and the like;
Step S1-4: the user standardizes own transmission data according to the entry rule, processes the input data through a data conversion program, converts the input data into standard data, and then inputs the standard data into the service component;
step S1-5: the service component performs customization processing on the standard data.
Further, the step S2 includes:
step S2-1: according to the requirements, opening a service component interface according to interface analysis rules, wherein the interface analysis rules define how the user will transmit data into the service component, and what specification is provided for the externally opened interface so as to realize normal transmission butt joint with input data;
Step S2-2: completing the specification definition of each interface according to the service component interface description rule;
Step S2-3: and opening an interface meeting the interface rule of the service component, and combining the interface with the entry data to provide services.
Further, the step S3 includes:
Step S3-1: the user summarizes the requirements of the service components and the characteristics of the service components, and reconstructs the service components;
step S3-2: the user modifies and adjusts the own service components according to the service protocol, and adds necessary service component contents;
Step S3-3: after the service rule is formulated, a developer develops according to the service rule when developing, standardizes the development process and pays attention to service dependent code logic.
Further, the step S4 includes:
step S4-1: based on the existing service combination output data, searching for commonality among the output data, and performing data processing;
Step S4-2: the service component is required to standardize outgoing data according to the export parsing rule;
step S4-3: adding an export field for the output data according to the export parsing rule;
Step S4-4: extracting and abstracting service combination output data into the following classes of input, command class, string class, image class, voice class, video class, file class, zip class, number class and the like;
step S4-5: the output data becomes standardized data, and is normally output from the service component, and if a reverse proxy exists, the reverse proxy is started after the output data is output.
Further, the step S5 includes:
step S5-1: the user observes the service interaction process and summarizes the interaction characteristics;
step S5-2: modifying interactions between service components according to service component interaction specifications;
Step S5-3: when the service component needs to call other service components, the content of the component rule of the target service component is known, and the service component is called according to the rule.
The invention provides a service combination interface design method based on a constructed rule chain, which specifically comprises the following steps: based on the existing service combination input data, the expert processes the data through the commonality of the data, and the service combination entry analysis rule according to the invention normalizes the data and then transmits the normalized data to the service component through the entry rule; the invention provides a service component interface rule, the interface rule analyzes and prescribes the content and description specification of an externally opened interface of a service component, and a user opens the service component interface according to the interface rule; after the user transmits the data meeting the entry rule into the interface according to the interface rule, the user processes the data according to the service component meeting the service rule; then the service component analyzes and processes the target data through the export rule and outputs the target data to the target notification; meanwhile, if the service component needs to interact the data with other service components, the interaction with other service components is realized through the component interaction protocol.
In addition, the invention also provides a service rule how to develop the service component, when a programmer develops the service component, the service component of the programmer needs to be modified and adjusted according to the service rule of the invention, and meanwhile, the newly developed service component can be better developed through adapting to a rule chain by combining an interface rule and a component interaction rule, an entry rule and an exit rule.
The system designed by the method has the advantages that the use threshold of non-professional persons on the cloud primary service combination platform and the system can be greatly reduced, so that common workers without much professional knowledge can easily use the service assembly system, correct data formats are provided, specifications are provided for various service assemblies, the development and application of the service assemblies are more convenient, and the intelligent and humanized degree of the industrial Internet platform is improved.
Drawings
Fig. 1 is a flowchart of an overall rule chain based service composition system.
Fig. 2 is an entry resolution rule diagram.
Fig. 3 is a service component rule diagram.
Fig. 4 is an exit resolution rule diagram.
FIG. 5 is a component interaction rule diagram.
Fig. 6 is an interface json format diagram.
Fig. 7 is a service specification json format diagram.
Fig. 8 is an exit json format diagram.
Fig. 9 is an interactive json format diagram.
FIG. 10 is a canonical definition of service components.
Detailed Description
Nowadays, rule chains are mostly applied to the field of big data, and by applying the rule chains to service combinations, the multisource and complexity of the rule chains can be fully utilized, so that the requirements of the service combinations are met. Meanwhile, the service is screened by utilizing the rule chain, so that the efficiency of service combination can be improved, and a service combination scheme can be generated as soon as possible. For this reason, a rule chain-based adaptation needs to be performed on the system, and a service component satisfying the relevant rules such as interfaces and service components is formulated.
The technical scheme provided by the application is further described below with reference to specific embodiments and attached drawings. The advantages and features of the present application will become more apparent in conjunction with the following description.
As shown in fig. 1, an overall flow of a service combination system based on a rule chain is divided into five steps in system implementation:
Step S1, summarizing commonalities of project input data according to self requirements, and formulating an entry data format according to service combination entry analysis rules and service component interface description;
S2, utilizing service component interface rules to develop the service component interface in a standardized way, and completing interface design;
step S3, when the service component is developed, the design of each part of the component is completed according to the service protocol, and the component development flow is standardized;
Step S4, summarizing the output data requirements of the service assembly according to the self requirements, and formulating an export data format according to the service combination export analysis rule;
And S5, combining interaction requirements with other service components, and normalizing the component interaction mode according to the component interaction protocol and the characteristics of a rule chain.
As shown in fig. 2, the step S1 specifically includes:
Step S1-1: based on the existing service combination input data, the expert searches to determine the commonality among all the input data, and the commonality is processed in a certain mode.
Step S1-2: because of the large and complex data in the rule chain, if the data format is not normalized, the data processing on the service component will be interfered, and the processing time will be greatly increased. Therefore, before the data is transferred to the rule chain, the entry data must be normalized, including the types of exchange protocols, including mqtt, http, tcp, udp, websocket, and the like. And the address of the input data is analyzed to indicate the source address of the data and the resource path of the resource acquisition. So that the service component accurately locates the desired data.
Step S1-3: normalized data, extracting and abstracting service combination input data into the following types of input, command class, number class, string class, image class, voice class, video class, file class and zip class.
For command class, extract its relationship, data specifying its json format must contain the following fields: data numbering, command content, action object, input parameter 1, input parameter 2.
For a string class, its relationship is extracted, and the data specifying its json format must contain the following fields: data number, device name, device number, sending address, time stamp, attribute description, operation type, data content;
For an image class, whose relationship is extracted, encoded using BASE64, the data specifying its json format must contain the following fields: data number, device name, device number, sending address, timestamp, file description, operation type, file name, picture height, picture width, coding format, data content;
For the voice class, using AAC LC coding, its relationship is extracted, and the data specifying its json format must contain the following fields: data number, device name, device number, send address, timestamp, file description, operation type, file name, audio length, sampling rate, channel, audio code rate, audio content;
For video class, H264 coding is used to extract the relationship, and each video corresponds to a combination of a plurality of frame images and audio streams, so that it needs to be considered simultaneously, and the data defining the json format must include the following fields: data number, device name, device number, send address, timestamp, file description, operation type, file name, encoding format, pixel format, resolution, code rate, frame rate, file size, file duration, video content;
For the file class, the relationship is extracted, and the data specifying its json format must contain the following fields: data number, device name, device number, send address, timestamp, file description, operation type, file name, file size, file content;
For the zip class, to extract its relationship, the data specifying its json format must contain the following fields: data number, device name, device number, send address, timestamp, file description, operation type, file name, file content.
Step S1-4: and the user standardizes own transmission data according to the rule, and if the transmission data is not in a standard format, the input data is processed through a data conversion program, converted into standard data and then input into the service component interface.
Step S1-5: and combining with the service component interface description, judging whether the input data needs to be customized to meet the service component requirements.
As shown in fig. 3, the step S2 specifically includes:
Step S2-1: according to the requirements of a rule chain on the dynamic scheduling service component, the service component needs to have flexible interface entry to provide calling, a specific interface definition is opened to the outside, and the standard interface definition is convenient to develop. According to the service component interface rules, the user sums up the content of the data transmitted into the service component, and the data is in the form of an externally opened interface so as to realize normal transmission butt joint with the input data.
Step S2-2: as shown in fig. 6, the service component interface description rules include the following for each interface's specification definition: protocol specification: an https or http protocol is adopted; domain name specification: the interface has and only has a unique domain name and port; API path specification: to distinguish from other paths, an api directory must be added to the path; version control specification: the service component of the formal version needs to determine the interface version, backup the interface code and add version information into the interface path; API naming convention: url is domain name specification + API path specification + version control specification; the method is as follows: adopts http verb correspondence, such as GET, POST, PUT, DELETE and the like; request parameter specification: public data is requested by using a GET mode, private data is requested by using a POST mode, POST is used as much as possible, and configuration parameters are added according to project requirements; returning to parameter specification: list data return, under the condition that no special condition exists, the latest data must be ordered in sequence, and examples are { "list" [ ], object { }/"object": "" status ":" SUCCESS ":" message ":" i me is a prompt message ",..; object must choose, entity data, json key value pairs; status must choose, operating status code = SUCCESS, ERROR and other static variables; message must select, prompt message; pages and subnumber are optional for paging queries.
The interface description of a service component must contain several things: the entry description field is used for describing the function and the function of the interface in more detail, so that a user can clearly know how to interface with the interface; a request address field from where the request originates; a request mode field in which protocol the request is issued; a resource description field, in which the interface, i.e. what resource is needed by the service component, is written, which is actually embodied as what request parameter is needed by the service component, and meanwhile, a specific return parameter is also needed to be described in this field, and a normal return example is given; a resource address field, where the resource is stored in a public address, and the service component accesses the address to acquire the resource; the model call field writes a field that makes it clear what model this service component will call.
Step S2-3: after the user establishes the service component interface based on the service component interface rules, the service component interface is combined with the entry data conforming to the entry analysis rules and is transmitted to the service component to normally provide service.
The step S3 specifically includes:
Step S3-1: in order to better develop and combine service components, the invention provides a service rule chain for developing service combination adaptation rules by making service rule for developing service components. When the programmer develops the service components, the programmer needs to modify and adjust the service components according to the service specifications.
Step S3-2: as shown in fig. 7, in the service component service specification, the following must be included for specification definition of each service:
The built platform model protocol, the description of the internal behavior change of the program, comprises:
Business logic performs: business logic describing how a component performs its encapsulation, including processing requests, performing operations, generating responses, and the like; transaction management: service components may need to process transactions, and component dynamic models should describe the start, execution, commit, or rollback of transactions; abnormality management: describing how the component handles the exception conditions include error detection, exception capture, error recovery, error reporting, and the like.
Information model specifications, specific description of services. The information model specifications include: service component metadata: basic information describing service components, such as names, versions, descriptions, responsible parties, etc.; description of the functions: defining functions provided by the service component, including operations that it can perform, input and output parameters of the service, pre-and post-conditions of the operations, and the like; quality of service (QoS) attributes: defining properties and requirements of service components in terms of performance, reliability, transaction processing, security, etc.; management and monitoring: how service components are managed and monitored, including logging, performance monitoring, exception handling, etc.
Service flow conventions, for each service component, specify which services the service component depends on, which services the service will invoke. The dependent services are sequentially written in the service definition document according to the dependent sequence, and the called services are the same. When the service component is started, the dependent service is pulled into a rule chain first and is used as a service combination node to be placed in front of the service. Second, it is checked whether there are service component dependencies that have not been pulled until all of the dependent service components are added to the rule chain. And then, adding the called services to the service node according to the calling sequence until all the called services are added to the rule chain. Before all the dependent services are started, the services are not started, and after the service component is started, the called services are started according to the calling sequence.
Message event protocol, the service component can trigger what kind of event when encountering messages with different types or different values, and what kind of event triggered result occurs.
Step S3-3: when developing, the developer develops according to the service protocol, standardizes the development process and notices the service dependence calling code logic.
As shown in fig. 4, in the present invention, the step S4 specifically includes:
Step S4-1: based on the existing service combination output data, the expert searches to determine the commonality among all output data, and the commonality is processed in a certain mode.
Step S4-2: the service component normalizes outgoing data according to the egress parsing rules. Therefore, if the output data is not in the standard format after being generated in the service component, the output data is further processed by the data conversion program, converted into the standard data, and then output to the outside.
Step S4-3: as shown in fig. 8, for the service component exit resolution rule, the following is to be included at the exit: exchange protocols, including mqtt, http, tcp, udp, websocket and other protocols; a destination address to which the data of the exit is to be directed, the address not being fixed, each time written; interface data, data to be output; and the reverse proxy is used for triggering what event or code is triggered by the service component after the service component finishes outputting the output data once, and the content and the address of the trigger event are written.
Step S4-4: the service combination output data extraction is abstracted into the following classes of input, command class, string class, image class, voice class, video class, file class, zip class and number class. The specific output type requirements are the same as in step 1.
Step S4-5: the user normalizes the data format generated by the service component according to the export parsing rule, and normally outputs the data from the service component, and if a reverse proxy exists, the reverse proxy is started after outputting the output data.
As shown in fig. 5, the step S5 specifically includes:
step S5-1: interaction between service components occurs frequently, for which component interaction protocols need to be formulated, and component interaction procedures are standardized. And summarizing the interaction modes and characteristics according to the interaction requirements of the self service components by the user.
Step S5-2: as shown in fig. 9, the service group interaction resolution rules specify that the rules need to be satisfied between service components when interacting, the rules include the following: a calling convention that each service component specifies what conditions the calling service component needs to satisfy; the value transfer, what parameter needs to be transferred when the service component is called, and the value of the transfer parameter is transferred in what mode, namely, two types of value transfer and address transfer; the public interface calls the service component to call through a fixed public interface address; data transfer, data transferred by service components and further interactive service components.
Step S5-3: and the user completes the service component interaction calling process according to the component interaction protocol, and calls other services through the public interface.
Through the five steps, the integration with the existing rule chain is realized when specific service combination is performed. After the above five steps are completed, a service component specification definition is formed, as shown in fig. 10:
Wherein,
The base information and protocol information correspond to step 3 service resolution rules,
The input parameters correspond to the step 1 entry resolution rules,
The output parameters correspond to the step4 exit parsing rules,
Build dependency corresponds to step 5 component interaction rules.
The interface rules are incorporated into the specific formulation of various parameters.
The above description is only illustrative of the preferred embodiments of the application and is not intended to limit the scope of the application in any way. Any alterations or modifications of the application, which are obvious to those skilled in the art based on the teachings disclosed above, are intended to be equally effective embodiments, and are intended to be within the scope of the appended claims.
Claims (6)
1. The service combination interface design method based on the rule chain is characterized by comprising the following steps:
Step S1, summarizing commonalities of project input data according to self requirements, and formulating an entry data format according to service combination entry analysis rules and service component interface description;
S2, utilizing service component interface rules to develop the service component interface in a standardized way, and completing interface design;
step S3, when the service component is developed, the design of each part of the component is completed according to the service protocol, and the component development flow is standardized;
Step S4, summarizing the output data requirements of the service assembly according to the self requirements, and formulating an export data format according to the service combination export analysis rule;
And S5, combining interaction requirements with other service components, and normalizing the component interaction mode according to the component interaction protocol and the characteristics of a rule chain.
2. The method according to claim 1, wherein the step S1 includes:
Step S1-1: searching for commonality among input data based on the existing service combination input data, and performing data processing;
Step S1-2: according to the entry analysis rule, carrying out standardization processing on the data, and adding various fields for data analysis;
Step S1-3: normalized data, extracting and abstracting service combination input data into the following types of input, command class, string class, image class, voice class, video class, file class, zip class and number class;
Step S1-4: the user standardizes own transmission data according to the entry rule, processes the input data through a data conversion program, converts the input data into standard data, and then inputs the standard data into the service component;
step S1-5: the service component performs customization processing on the standard data.
3. The method according to claim 1, wherein the step S2 includes:
step S2-1: according to the requirements, opening a service component interface according to interface analysis rules, wherein the interface analysis rules define how the user will transmit data into the service component, and what specification is provided for the externally opened interface so as to realize normal transmission butt joint with input data;
Step S2-2: completing the specification definition of each interface according to the service component interface description rule;
Step S2-3: and opening an interface meeting the interface rule of the service component, and combining the interface with the entry data to provide services.
4. The method according to claim 1, wherein the step S3 includes:
Step S3-1: the user summarizes the requirements of the service components and the characteristics of the service components, and reconstructs the service components;
step S3-2: the user modifies and adjusts the own service components according to the service protocol, and adds necessary service component contents;
Step S3-3: after the service rule is formulated, a developer develops according to the service rule when developing, standardizes the development process and pays attention to service dependent code logic.
5. The method according to claim 1, wherein the step S4 includes:
step S4-1: based on the existing service combination output data, searching for commonality among the output data, and performing data processing;
Step S4-2: the service component is required to standardize outgoing data according to the export parsing rule;
step S4-3: adding an export field for the output data according to the export parsing rule;
step S4-4: extracting and abstracting service combination output data into the following classes of input, command class, string class, image class, voice class, video class, file class, zip class and number class;
step S4-5: the output data becomes standardized data, and is normally output from the service component, and if a reverse proxy exists, the reverse proxy is started after the output data is output.
6. The method according to claim 1, wherein the step S5 includes:
step S5-1: the user observes the service interaction process and summarizes the interaction characteristics;
step S5-2: modifying interactions between service components according to service component interaction specifications;
Step S5-3: when the service component needs to call other service components, the content of the component rule of the target service component is known, and the service component is called according to the rule.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410423751.8A CN118259880A (en) | 2024-04-09 | 2024-04-09 | Rule chain-based service combination interface design method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410423751.8A CN118259880A (en) | 2024-04-09 | 2024-04-09 | Rule chain-based service combination interface design method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118259880A true CN118259880A (en) | 2024-06-28 |
Family
ID=91612927
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410423751.8A Pending CN118259880A (en) | 2024-04-09 | 2024-04-09 | Rule chain-based service combination interface design method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118259880A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN118585173A (en) * | 2024-08-02 | 2024-09-03 | 天翼视联科技有限公司 | Component construction method, device and authority authentication method for component set |
-
2024
- 2024-04-09 CN CN202410423751.8A patent/CN118259880A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN118585173A (en) * | 2024-08-02 | 2024-09-03 | 天翼视联科技有限公司 | Component construction method, device and authority authentication method for component set |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11561774B2 (en) | Composition of pattern-driven reactions in real-time dataflow programming | |
| US8626803B2 (en) | Method and apparatus for automatically providing network services | |
| US7284048B2 (en) | Method and computer system for correlating network event messages | |
| US6766368B1 (en) | System and method for providing an internet-based correlation service | |
| Schmidt et al. | C++ Network Programming, Volume 2: Systematic Reuse with ACE and Frameworks | |
| US7752598B2 (en) | Generating executable objects implementing methods for an information model | |
| EP1727045A2 (en) | Application framework for use with net-centric application program architectures | |
| CN118259880A (en) | Rule chain-based service combination interface design method | |
| US20020046301A1 (en) | System and method for integrating disparate networks for use in electronic communication and commerce | |
| KR20050119645A (en) | Program creation by combining web services using graphic user interface controls | |
| KR20030045027A (en) | Accessing legacy applications from the internet | |
| CN112363699B (en) | Interaction method and device applied to multi-language development platform | |
| US20230281040A1 (en) | Pipeline-based machine learning method and apparatus, electronic device, and computer readable storage medium | |
| US20060085423A1 (en) | Rules of engagement for deterministic Web services | |
| Tai et al. | Model-driven development of large-scale Web applications | |
| Laitkorpi et al. | A uml-based approach for abstracting application interfaces to rest-like services | |
| CN115357241A (en) | Service-oriented manufacturing resource componentization encapsulation and semantic description method | |
| Takeda et al. | MERA: Meta language for software engineering | |
| Pahl | Components, contracts, and connectors for the unified modelling language UML | |
| Chang et al. | A service acquisition mechanism for server-based heterogeneous distributed systems | |
| Zheng et al. | MobiGATE: a mobile computing middleware for the active deployment of transport services | |
| US11966719B2 (en) | Event consumption for high-level programing language platform | |
| Selić | Modeling of Real-Time Software Systems | |
| CN107332891A (en) | Method, server and the client of HTTP request processing | |
| Zhou et al. | Towards semantic modeling for qos specification |
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 |