Access development method, device, system and medium for multiple subsystem access

文档序号:1952356 发布日期:2021-12-10 浏览:20次 中文

阅读说明:本技术 多个子系统接入的接入开发方法、装置和系统、及介质 (Access development method, device, system and medium for multiple subsystem access ) 是由 李志� 于 2021-09-27 设计创作,主要内容包括:本发明实施例公开一种多个子系统接入的接入开发方法、装置和系统、及介质。在一具体实施方式中,该方法包括:根据外部服务端的请求参数和待接入子系统的接入协议自动生成外部服务端调用待接入子系统的请求转换类;将请求转换类发送至待接入子系统获取待接入子系统的响应参数,并根据待接入子系统的接入协议和响应参数生成待接入子系统响应于外部服务端调用的响应转换类;根据请求转换类和响应转换类生成接入文件。该实施方式通过基于请求参数和待接入子系统的接入协议自动生成请求转换类、并基于接入协议和响应参数生成响应转换类,使得能够通过开发端自动生成接入文件,降低了开发人员的工作量,提高了开发人员的工作效率,具有广泛的应用前景。(The embodiment of the invention discloses an access development method, an access development device, an access development system and an access development medium for accessing a plurality of subsystems. In one embodiment, the method comprises: automatically generating a request conversion class for calling the subsystem to be accessed by the external server according to the request parameter of the external server and the access protocol of the subsystem to be accessed; sending the request conversion class to the subsystem to be accessed to acquire the response parameter of the subsystem to be accessed, and generating a response conversion class which responds to the calling of an external server side by the subsystem to be accessed according to the access protocol and the response parameter of the subsystem to be accessed; and generating an access file according to the request conversion class and the response conversion class. According to the embodiment, the request conversion class is automatically generated based on the request parameter and the access protocol of the subsystem to be accessed, and the response conversion class is generated based on the access protocol and the response parameter, so that the access file can be automatically generated through the development terminal, the workload of developers is reduced, the working efficiency of the developers is improved, and the method has a wide application prospect.)

1. An access development method for accessing a plurality of subsystems is applied to an initiating terminal and is characterized by comprising the following steps:

automatically generating a request conversion class for calling the subsystem to be accessed by the external server according to the request parameters of the external server and the access protocol of the subsystem to be accessed;

sending the request conversion class to the subsystem to be accessed to acquire a response parameter of the subsystem to be accessed, and generating a response conversion class which is called by the subsystem to be accessed in response to an external server according to an access protocol of the subsystem to be accessed and the response parameter;

and generating an access file according to the request conversion class and the response conversion class.

2. The access development method of claim 1,

the automatically generating the request conversion class for the external server to call the subsystem to be accessed according to the request parameter of the external server and the access protocol of the subsystem to be accessed further comprises:

analyzing the access protocol to generate an intermediate conversion class;

mapping the intermediate conversion class line by line in a reflection mode, and determining the binding position of the request parameter in the intermediate conversion class; and

binding the request parameter in the position and compiling to generate the request conversion class, wherein the generating of the response conversion class of the subsystem to be accessed in response to the external server call according to the access protocol of the subsystem to be accessed and the response parameter further comprises:

and binding the response parameters in the positions and compiling to generate the response conversion class.

3. The access development method of claim 1,

the automatically generating the request conversion class for the external server to call the subsystem to be accessed according to the request parameter of the external server and the access protocol of the subsystem to be accessed further comprises:

analyzing the access protocol to generate the intermediate conversion class and an annotation file of the intermediate conversion class, wherein the intermediate conversion class further comprises a protocol character string which represents the hierarchy of the access protocol in the form of a parent tag;

determining, with the annotation file, a location to which the request parameter is to be bound based on the intermediate translation class; and

binding the request parameter in the position and compiling to generate the request conversion class, and automatically generating the request conversion class for the external server to call the subsystem to be accessed according to the request parameter of the external server and the access protocol of the subsystem to be accessed further comprises:

binding the response parameters in the location and compiling to generate the response translation class.

4. The access development method according to claim 2 or 3, wherein the intermediate transition classes comprise a nested hierarchy.

5. The access development method according to claim 2 or 3, characterized in that the access protocol is parsed based on one of DOM, SAX, and STAX methods.

6. The access method according to claim 1, wherein when the access protocol is JSON format, before the automatically generating the request conversion class for the external server to invoke the subsystem to be accessed according to the request parameter of the external server and the access protocol of the subsystem to be accessed, the method further comprises:

and converting the format of the access protocol into an XML format.

7. An application service method based on access of a plurality of subsystems is applied to a server side and is characterized by comprising the following steps:

generating a request protocol according to a service request and a pre-stored access file and sending the request protocol to the subsystem to be accessed, wherein the service request comprises a request parameter;

acquiring a response value of the subsystem to be accessed, and generating a response protocol according to the access file and the response value, wherein the response value comprises a response parameter;

wherein the access file is generated by the access development method of any one of claims 1-6.

8. An access development device implementing the access development method according to any one of claims 1 to 6, characterized by comprising:

the request conversion module automatically generates a request conversion class for calling the subsystem to be accessed by the external server according to the request parameters of the external server and the access protocol of the subsystem to be accessed;

the response conversion module is used for generating a response conversion class which is called by the subsystem to be accessed in response to an external server according to the access protocol of the subsystem to be accessed and the response parameters received from the subsystem to be accessed; and

and the file generation module generates an access file according to the request conversion class and the response conversion class.

9. An application service system for implementing the application service method of claim 7, comprising an application layer for receiving user operations and an access layer for accessing a subsystem to be accessed, wherein the access layer is configured to:

receiving an external request generated by user operation and a pre-stored access file generation request protocol according to the application layer;

generating a response protocol according to the access protocol of the subsystem to be accessed and the response value received from the subsystem to be accessed;

completing the access of the subsystem to be accessed according to the response protocol so that the application layer calls the application service of the subsystem to be accessed according to the received user operation,

wherein the access file is generated by the access development method of any one of claims 1-6.

10. A computer device, comprising:

one or more processors;

a storage device on which one or more programs are stored;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-6 or the method of claim 7.

11. A computer-readable storage medium, on which a computer program is stored, wherein the program, when executed by a processor, implements the method of any one of claims 1-6 or the method of claim 7.

Technical Field

The invention relates to the technical field of computers. And more particularly, to a method, apparatus, system, and medium for access development for multiple subsystem access.

Background

With the rapid development of the intelligent internet of things, the association between different software and hardware services is gradually increased, and when a third-party service is called, request parameters need to be packaged according to a specified protocol format when the service is called. However, each end service has its own protocol format, and the protocol formats are mostly different, so that an adaptation protocol is required in the mutual calling process, and often, a complex class needs to be manually encapsulated for a simple function, so that the development efficiency is low, which undoubtedly increases the development cost for the service calling process.

Disclosure of Invention

The invention aims to provide an access development method, an access development device, an access development system and an access development medium for accessing a plurality of subsystems, so as to solve at least one of the problems in the prior art.

In order to achieve the purpose, the invention adopts the following technical scheme:

the invention provides an access development method for accessing a plurality of subsystems, which is applied to an initiating terminal and comprises the following steps:

automatically generating a request conversion class for calling the subsystem to be accessed by the external server according to the request parameter of the external server and the access protocol of the subsystem to be accessed;

sending the request conversion class to the subsystem to be accessed to acquire the response parameter of the subsystem to be accessed, and generating a response conversion class which responds to the calling of an external server side by the subsystem to be accessed according to the access protocol and the response parameter of the subsystem to be accessed;

and generating an access file according to the request conversion class and the response conversion class.

In some of the alternative embodiments, the first and second,

the step of automatically generating a request conversion class for the external server to call the subsystem to be accessed according to the request parameters of the external server and the access protocol of the subsystem to be accessed further comprises the following steps:

analyzing the access protocol to generate an intermediate conversion class;

mapping the intermediate conversion class line by line in a reflection mode, and determining the binding position of the request parameter in the intermediate conversion class; and

binding the request parameters in a location and compiling to generate a request translation class,

generating a response conversion class of the subsystem to be accessed in response to the external server call according to the access protocol and the response parameter of the subsystem to be accessed further comprises:

the response parameters are bound in place and compiled to generate a response transformation class.

In some of the alternative embodiments, the first and second,

the step of automatically generating a request conversion class for the external server to call the subsystem to be accessed according to the request parameters of the external server and the access protocol of the subsystem to be accessed further comprises the following steps:

analyzing the access protocol to generate an intermediate conversion class and an annotation file of the intermediate conversion class, wherein the intermediate conversion class also comprises a protocol character string which represents the hierarchical structure of the access protocol in the form of a father tag;

determining the position to which the request parameter is bound based on the intermediate conversion class by using the annotation file; and

binding the request parameters in a location and compiling to generate a request translation class,

the step of automatically generating a request conversion class for the external server to call the subsystem to be accessed according to the request parameters of the external server and the access protocol of the subsystem to be accessed further comprises the following steps:

binding the response parameters in the location and compiling to generate the response translation class.

In some alternative embodiments, the intermediate transformation classes comprise a nested hierarchy.

In some optional embodiments, the access protocol is parsed based on one of a DOM method, a SAX method, and a STAX method.

In some optional embodiments, when the format of the access protocol is JSON format, before automatically generating a request conversion class for the external server to invoke the subsystem to be accessed according to the request parameter of the external server and the access protocol of the subsystem to be accessed, the method further includes:

the format of the access protocol is converted to XML format.

The second aspect of the present invention provides an application service method based on multiple subsystem access, applied to a server, including:

generating a request protocol according to a service request and a pre-stored access file and sending the request protocol to a subsystem to be accessed, wherein the service request comprises a request parameter;

acquiring a response value of a subsystem to be accessed, and generating a response protocol according to an access file and the response value, wherein the response value comprises a response parameter;

wherein, the access file is generated by the access development method.

A third aspect of the present invention provides an access development apparatus for implementing the access development method described above, including:

the request conversion module automatically generates a request conversion class for calling the subsystem to be accessed by the external server according to the request parameter of the external server and the access protocol of the subsystem to be accessed;

the response conversion module is used for generating a response conversion class which is called by the subsystem to be accessed in response to the external server according to the access protocol of the subsystem to be accessed and the response parameters received from the subsystem to be accessed; and

and the file generation module generates an access file according to the request conversion class and the response conversion class.

A fourth aspect of the present invention provides an application service system for implementing the application service method described above, including an application layer for receiving user operations and an access layer for accessing a subsystem to be accessed, where the access layer is configured to:

receiving a service request generated by user operation and a pre-stored access file generation request protocol according to an application layer;

generating a response protocol according to the access protocol of the subsystem to be accessed and the response value received from the subsystem to be accessed;

completing the access of the subsystem to be accessed according to the response protocol so that the application layer calls the application service of the subsystem to be accessed according to the received user operation,

wherein, the access file is generated by the access development method.

A fifth aspect of the present invention provides a computer apparatus comprising:

one or more processors;

a storage device on which one or more programs are stored;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement an access development method as described above or an application service method as described above.

A sixth aspect of the present invention provides a computer readable storage medium having stored thereon a computer program, wherein the program, when executed by a processor, implements an access development method as described above or an application service method as described above.

The invention has the following beneficial effects:

aiming at the existing problems, the invention sets an access development method, a device, a system and a medium for accessing a plurality of subsystems, automatically generates a request conversion class for calling the subsystem to be accessed by an external server according to a request parameter of the external server and an access protocol of the subsystem to be accessed, and generates a response conversion class according to the access protocol and the response parameter of the subsystem to be accessed, so that an initiating terminal can automatically generate an access file, developers do not need to manually package complex classes of various subsystems according to a protocol format, the workload of development interfaces of law belief staff is reduced, the development difficulty is reduced, the development efficiency is greatly improved, and the invention has wide application prospect.

Drawings

The following describes embodiments of the present invention in further detail with reference to the accompanying drawings.

Fig. 1 shows a flow diagram of an access development method for multiple subsystem access according to an embodiment of the invention;

fig. 2 is a schematic structural block diagram of an access development system implementing an access development method according to an embodiment of the present invention;

FIGS. 3a and 3b show schematic diagrams of a user interaction interface of an access development device according to an embodiment of the invention;

fig. 4 shows a schematic flow diagram of a resolution procedure in an access development method according to an embodiment of the invention;

FIG. 5 illustrates an exemplary file list of intermediate transformation classes in an access development method according to an embodiment of the invention;

FIG. 6 illustrates a schematic hierarchical relationship diagram of intermediate transformation classes in an access development method according to an embodiment of the present invention;

fig. 7 shows a schematic structural block diagram of an application service system according to an embodiment of the present invention; and

fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the present invention.

Detailed Description

In order to more clearly illustrate the present invention, the present invention will be further described with reference to the following examples and the accompanying drawings. Similar parts in the figures are denoted by the same reference numerals. It is to be understood by persons skilled in the art that the following detailed description is illustrative and not restrictive, and is not to be taken as limiting the scope of the invention.

In view of at least one of the above problems, as shown in fig. 1, an embodiment of the present invention provides an access development method for multiple subsystem access, which is applied to a development end and includes:

automatically generating a request conversion class for calling the subsystem to be accessed by the external server according to the request parameter of the external server and the access protocol of the subsystem to be accessed;

sending the request conversion class to the subsystem to be accessed to acquire the response parameter of the subsystem to be accessed, and generating a response conversion class which is called by the subsystem to be accessed in response to an external server according to the access protocol and the response parameter of the subsystem to be accessed;

and generating an access file according to the request conversion class and the response conversion class.

In the embodiment, the request conversion class of the subsystem to be accessed called by the external server is automatically generated according to the request parameter of the external server and the access protocol of the subsystem to be accessed, and the response conversion class is generated according to the access protocol and the response parameter of the subsystem to be accessed, so that the development end can automatically generate the access file, developers do not need to manually package complex classes of various subsystems according to protocol formats, the workload of the development interface of a judicial staff is reduced, the development difficulty is reduced, the development efficiency is greatly improved, and the method has a wide application prospect.

In order to better understand the implementation process of the access development method for multiple subsystem access of the present invention, first, the structure of the application service system that affects the overall implementation of the application service method is described with reference to fig. 2.

As shown in FIG. 2, the application service system includes a server 100, an development end 200, and a plurality of subsystems 300-1, 300-2, … …, and 300-n (where n is an integer, and n ≧ 2). In the description herein, when a distinction is not required, a subsystem is denoted with reference numeral 300. The application service system can be applied to various scenes of the internet of things such as intelligent household appliances, intelligent parks, smart cities and intelligent traffic.

The server 100 may be an application service system formed by one or more servers, where the servers may be cloud servers or local servers, the server includes an application layer and an access layer having a user interaction interface, and the server 100 may generate a service request for invoking a service to an external subsystem based on a user operation of a user on the user interaction interface. The Development end 200 may be a server loaded with an Integrated Development Environment (IDE), and may be a device used by a developer, such as a desktop computer or a notebook computer. The IDE can be an IDEA, VS Code and other integrated development platforms based on Java language. Particularly, in order to realize the access development method of the invention, an analysis plug-in for automatically generating the access file is integrated in the IDE of the development end, wherein the analysis plug-in is a plug-in library issued to the development platform, the issued format is a zip package or a jar package, and the plug-in library is downloaded and installed in the IDE of the development end when in use, so that the access file is automatically generated by calling the analysis plug-in the development process; the automatically generated access file refers to a Java bean file which is generated according to an access protocol file and has a hierarchical structure, the file format is Java, the credited file is called according to specific service requirements in the development process, errors caused by manual writing can be reduced, and therefore development efficiency is improved.

In addition, the multiple subsystems 300-1, 300-2, … …, and 300-n represent various internet of things management subsystems capable of being invoked and managed by the server 100, for example, the subsystem 300 may be a camera management subsystem, and may manage and control the behavior of a camera, such as code rate adjustment, direction adjustment, and the like. In this example, each subsystem may be a plurality of camera management subsystems 300-1, 300-2, … …, and 300-n manufactured by different vendors. Of course, the subsystem 300 may also represent other management subsystems, and each of the subsystems 300-1, 300-2, … …, and 300-N in the subsystem 300 may also represent different kinds of internet of things management subsystems produced by different manufacturers, for example, the subsystem 300-1 represents a camera management subsystem produced by manufacturer a, the subsystem 300-1 represents an indicator light management subsystem produced by manufacturer B, … …, and 300-N represents a display screen management subsystem produced by manufacturer N, and the like, which is not limited herein.

The access protocols used by the communication interfaces of the subsystems manufactured by different manufacturers may be different, for example, the subsystem 300-1 is a communication interface using the HTTP protocol, and the subsystem 300-2 is a communication interface using the TCP protocol, so that a developer needs to develop an interface at a development end. In the embodiment of the invention, the analysis plug-in which is designed and developed in advance by a developer is integrated in the IDE, so that the interface developer does not need to write code package interface files one by one manually, but can automatically generate access files aiming at access protocols of different subsystems, and upload the access files generated in the embodiment to the server, so that the application service calling between the server 100 and each subsystem can be realized in the actual application service calling process, the development workload and the complexity of the interface are reduced, and the development efficiency is improved.

A specific implementation of the access development method for accessing multiple subsystems is described in detail in a more specific embodiment with reference to fig. 3a to 6, and the access development method is described by taking an example of a developer developing an interface of a subsystem 300-1 to be accessed to the development client 100.

In this context, with respect to a general scenario with multiple subsystem accesses, the subsystem may also be referred to as a subsystem to be accessed to distinguish it from other subsystems, and is not explained herein too much.

In step S1, a request conversion class for the external server to invoke the subsystem to be accessed is automatically generated according to the request parameter of the external server and the access protocol of the subsystem to be accessed.

In actual development, this step includes parsing and parameter binding processes, and compiling processes. The analysis and parameter binding process is completed by an analysis plug-in developed by a developer, and the compiling process is completed by a compiler in the IDE.

Specifically, at the beginning of the interface development project, the developer first starts the IDE loaded on the development end 200, runs the analysis plug-in developed by the developer in the IDE, and when the analysis plug-in runs, the user interaction interface shown in fig. 3a will be displayed in the window of the IDE. It should be understood by those skilled in the art that fig. 3a only shows a schematic diagram of the user interaction interface, and the specific form is not limited thereto, that is, the interface titles "automatic parsing access protocol", "protocol file storing path", and "example object generating path" may be other expressions indicating the same meaning. In addition, it should be understood by those skilled in the art that, when the development project is executed for the first time, if the analysis plug-in is not installed in the IDE, the developer may download the installation package in the corresponding download path to install the analysis plug-in, and then start the IDE and run the analysis plug-in, which is not described herein again in detail.

Referring to FIG. 3b, the developer introduces the interface protocol of the subsystem 300-1 in the "protocol file deposit path" column in the user interface. For example, a developer may introduce the storage address of the interface protocol from the path list according to the storage location of the interface protocol by clicking a blank of the address introduction column, so as to resolve the plug-in call. The interface protocol is generally an interface protocol obtained and saved in advance from a developer of the subsystem after determining the kind of the subsystem to be accessed to the server 100, and represents protocol logic, codec format, and the like of the subsystem interface. In an embodiment of the present invention, the interface protocol is essentially a protocol template that is parsed as a parsing plug-in. The interface protocol of the subsystem is usually a file in an XML format, and in some cases, the interface protocol may also be a JSON file according to the difference of the subsystem developers.

With reference to fig. 3b, the developer introduces the storage location of the file generated after the analysis of the interface protocol of the subsystem 300-1 in the "example object generation and routing" column in the user interaction interface, and the developer can select the storage location by himself, and usually, for the IDE, the file generated after the analysis is completed should be stored in the project directory of the interface development project for the subsequent process to be performed smoothly. Those skilled in the art will appreciate that the path may be either a local path or a cloud path.

After introducing the "protocol file storage path" and the "instance object generation path", the developer clicks the "start parsing" button, and the development end 200 automatically generates the request conversion class for the server 100 to call the subsystem 300-1 by using the parsing plug-in.

Specifically, after the start "resolution button" is clicked, the development end 200 first analyzes the access protocol to generate an intermediate conversion class by using the resolution plug-in; the request parameters are bound to the intermediate conversion class. The request parameter is obtained from the server 100 in advance before the analysis is performed, and the request parameter represents the interface call information of the server in an array manner.

In the development stage, the request parameter does not indicate the actual meaning of requesting a specific service, and it is sufficient to obtain the form corresponding to the calling parameter structure of the terminal from the server 100, but for the server 100, the service request is sent to the development terminal 200. Therefore, in this document, the development phase only represents the service request acquired from the server 200 by using the request parameter to distinguish from the specific service request sent in the actual application service phase, but in the specific service invocation phase, the service request itself should include the request parameter representing the invocation parameter structure, and details are not described below.

Further specifically, as shown in fig. 4, in the parsing process performed by the parsing plugin, after the "start parsing" button is clicked, the parsing plugin acquires the access protocol of the subsystem 300-1, that is, the protocol template thereof, according to the storage location introduced in the "protocol file storage path"; whether the access protocol meets the format requirement is judged, and in the embodiment of the application, the access protocol is analyzed based on one of a DOM method, an SAX method and an STAX method. Therefore, the parsing plug-in determines whether the access protocol satisfies the XML format, and if so, parses the access protocol in one of the above methods to generate an intermediate conversion class, which is stored in a corresponding location according to the path set in fig. 3 b; if not, prompting error warning information, and the developer needs to check whether an access protocol provided by the developer has an error code, and then continues to repeat the analysis step after the access protocol is modified.

It should be noted that the above steps are performed on the premise that the access protocol is XML, and whether an error code exists in the XML-formatted file is identified. Considering that the interface protocol format provided by the developer of the subsystem is not always the XML format, some developers provide the interface protocol format as JSON format, for example. Optionally, when the format of the access protocol is JSON format, before the step S1, the access development method further includes: the format of the access protocol is converted into the XML format, so that the method can be suitable for the access development of various subsystems.

In the embodiment of the present application, the interface development is performed in an IDE based on Java language, and a "class" is represented as a special class Bean in Java. Those skilled in the art will understand that Bean means a reusable Java component, which is expressed as a class (Bean) to represent the structural meaning of an interface protocol by parsing the interface protocol in this application. The intermediate conversion class (Bean) is a class file directly representing the logical structure of the access protocol hierarchy in the JavaBean format, and the generated file list of the intermediate conversion class is shown in fig. 5.

Optionally, the intermediate transformation classes comprise a nested hierarchy. Illustratively, as shown in FIG. 6, the code files given by the categories in FIG. 5 have the hierarchical structure shown in FIG. 6. However, it will be understood by those skilled in the art that the hierarchical structure is used to specify a segmentation mode for expressing the interface protocol after parsing, that is, a nesting rule of the access protocol is set in a peer-to-peer manner, so that a hierarchical relationship is embodied in the intermediate conversion class, and subsequent execution of the program is prevented from being independent of the access protocol. The parsing plug-in will determine the location to which the request parameters are to be bound in this piece-wise manner. The specific segmentation manner of the hierarchical structure is not limited to this, that is, the present application does not intend to limit the hierarchical structure of the intermediate conversion class generated after the access protocol is analyzed in the analysis plug-in to the specific form as shown in fig. 6, and a developer of the analysis plug-in may also specify a two-level or three-level hierarchical structure when designing, as long as the analysis plug-in can determine the binding position in the binding process of the request parameter.

And after the intermediate conversion class is obtained through analysis, analyzing the plug-in binding request parameters. Those skilled in the art will appreciate that both the parsing and binding processes are automatically completed after the developer of the interface clicks the "begin parsing" button.

Specifically, a reflection mode is adopted to carry out line-by-line mapping on the intermediate conversion class, and the binding position of the request parameter in the intermediate conversion class is determined; the request parameters are bound in the location and compiled to generate the request translation class. Through the above arrangement, the access protocol of the subsystem 300-1 is taken as a template, the structural logic of the access protocol represented by the intermediate conversion class is analyzed and generated, and the request parameters are bound according to the hierarchical structure of the intermediate conversion class, that is, the request parameters are bound to the corresponding code files in the file list shown in fig. 5 by the nesting relation in fig. 6.

However, the reflective mode is a method of reflective reading each code line in the intermediate conversion class line by line in a line-by-line mapping mode and searching for the position where the requested parameter needs to be bound, and each line of code reading process takes time. Specifically, the reflection (reflection) mechanism of Java refers to a way for the backend to develop and acquire and use class information without front-end cooperation in the running state of the program. The reflection mechanism of Java can construct any object of any class and call the property and method of any object. Various methods are required to provide the reflection in the Java.

With this in mind, in an alternative embodiment, the binding locations of the request parameters are determined in a hard-coded manner instead of in a reflective manner. Specifically, in step S2, automatically generating a request conversion class for the external server to invoke the subsystem to be accessed according to the request parameter of the external server and the access protocol of the subsystem to be accessed further includes: analyzing the access protocol to generate an intermediate conversion class and an annotation file of the intermediate conversion class, wherein the intermediate conversion class also comprises a protocol character string which represents the hierarchical structure of the protocol template in the form of a parent tag; determining the position to which the request parameter is bound based on the intermediate conversion class by using the annotation file; and binding the request parameters in the location. The format of the annotation file is the same as that of the access file, and the annotation file is a java file.

Illustratively, if the access protocol in XML format is as follows:

the protocol string characterizing the hierarchy of the access protocol in the form of a parent tag is then as follows:

private String xmlStr=″<Message><Devices></Devices><UserID></UserID></Message>";

private String xmlStr=″<UserID token=\″\″></UserID>";

private StringxalStr=″<Devices><Device></Device><Animal></Animal><Car></Car><Test></Test></Devices>";

private String xmlStr=″<Device 1d=\"\"><Name></Name><NRxConf></NRxCont><NIC></NIC></Device>";

private String xmlStr=″<Animal><Cat></Cat></An1mal>";

private String xmlStr=″<Car 1d=\″\″></Car>";

private String xmlStr=″<Cat 1d=\″\″></Cat>";

private String xmlStr=″<NIC><Port></Port></NIC>″;

private String xmlstr=″<Port index=\″\″1p=\″\″></Port>″;

private String xmlStr=″<NRxConf><VD1splay></VDisplay><FiberOut></FiberOut><USB></USB></NRxConf>";

private string xmlstr=″<VDisplay d1s_tp1x=\″\″fps=\″\″></VD1splay>";。

as can be seen from the above example, by having the intermediate conversion class include the protocol string, the format and meaning of the various pieces of the access protocol in XML format can be reflected in the form of a parent tag, i.e., each piece of code in the access protocol is directly characterized in a hard-coded manner by the string of the parent tag. Meanwhile, the meanings of the file and the code segment of the intermediate conversion class are determined by the annotation file of the intermediate conversion class, so that the binding position of the request parameter in the intermediate conversion class can be quickly determined by the protocol character string and the annotation file of the intermediate conversion class, and the request parameter is bound in the position.

Compared with a line-by-line mapping reflection mode, the method greatly shortens the generation time of the request conversion class and further improves the interface development efficiency.

Next, the developer compiles the intermediate conversion class after binding the request parameters by using a compiler in the IDE to splice the protocol strings into a complete request conversion class. Those skilled in the art should understand that the request parameter in the development stage does not have the calling meaning of the actual application service, and at this time, the file generated by compiling after binding the request parameter cannot be directly equivalent to the request protocol having the calling meaning of the actual application service, which is only intended to represent the logical relationship of the request protocol when calling the service in the future. Therefore, in this document, to distinguish from the request protocol, it is referred to as a request translation class.

In step S2, the initiating terminal 200 sends the request conversion class to the subsystem to be accessed (in this example, the subsystem to be accessed is the subsystem 300-1), acquires the response parameter of the subsystem to be accessed, and generates a response conversion class, which is called by the subsystem to be accessed in response to the external server, according to the access protocol and the response parameter of the subsystem to be accessed.

After being sent to the subsystem 300-1, for the subsystem, because the request conversion class is actually a file binding the request parameters according to the structural relationship of the interface protocol of the subsystem 300-1, the interface protocol can parse the meaning of the file and can generate the response parameters. Of course, since the request parameters bound in the request conversion class do not have the actual meaning of application service invocation, the response parameters returned by the subsystem 300-1 are not the specific response protocol for a certain application service. The response parameter is interface response information which represents the server side in an array mode.

Optionally, after receiving the response parameter, the parsing plug-in binds the response parameter in the binding position of the parameter determined in step S1, and compiles to generate the response conversion class. Wherein the intermediate conversion class is still the intermediate conversion class of the unbound request parameter after the resolution of the plugin to the access protocol in step S1. After the binding is finished, the developer compiles the intermediate conversion classes bound with the corresponding parameters through the compiler to generate response conversion classes. The response translation class generated by this setting is a file representing the logical structure of the access protocol of the subsystem 300-1.

In step S3, an access file is generated based on the request conversion class and the response conversion class.

Specifically, the IDE may be used to package the request conversion class and the corresponding conversion class to generate an access file, and as will be understood by those skilled in the art, the access file includes the request conversion class bound with the request parameter and used by the server 100 to invoke the subsystem 300-1, and also includes the response conversion class bound with the response parameter and used by the subsystem 300-1 to respond to the server 100. Because the request conversion class is generated by binding the request parameters at the corresponding position of the intermediate conversion class, the intermediate conversion class is a JavaBean which expresses the hierarchical structure of the access protocol and is generated on the basis of analyzing the access protocol of the subsystem 300-1, the request conversion class is equivalent to a Java component which describes the access protocol by using an analyzing plug-in, and similarly, the response conversion class is equivalent to a Java component which describes the access protocol by using an analyzing plug-in, and the access file formed by the method enables the server 100 to read and bind the request parameters in the request protocol and read the response parameters in the response protocol, thereby realizing the call to the subsystem 300-1.

In the access development method in the embodiment of the invention, the client can utilize the analysis plug-in to automatically analyze and form the intermediate conversion class of the logic structure of the hierarchy structure representing the access protocol based on the access protocol of the subsystem, and the request parameter and the response parameter are respectively bound in the intermediate conversion class to form the access file, so that the automatic generation of the access file is realized, the workload of a developer for developing an interface is greatly reduced, the labor cost is saved, and the development efficiency is improved.

Corresponding to the access development method, an embodiment of the present invention further provides an access development apparatus for implementing the access development method described above, including:

the request conversion module automatically generates a request conversion class for calling the subsystem to be accessed by the external server according to the request parameter of the external server and the access protocol of the subsystem to be accessed;

the response conversion module is used for generating a response conversion class which is called by the subsystem to be accessed in response to the external server according to the access protocol of the subsystem to be accessed and the response parameters received from the subsystem to be accessed; and

and the file generation module generates an access file according to the request conversion class and the response conversion class.

In the embodiment, the request conversion class of the subsystem to be accessed called by the external server is automatically generated according to the request parameter of the external server and the access protocol of the subsystem to be accessed, and the response conversion class is generated according to the access protocol and the response parameter of the subsystem to be accessed, so that the development end can automatically generate the access file, developers do not need to manually package complex classes of various subsystems according to protocol formats, the workload of the development interface of a judicial staff is reduced, the development difficulty is reduced, the development efficiency is greatly improved, and the method has a wide application prospect.

On the other hand, the access file generated by the above access development method may be uploaded and stored in the client 200 through communication between the development terminal 200 and the service terminal 100, so as to implement an application service method based on access of multiple subsystems when a service is invoked.

Another embodiment of the present invention provides an application service method based on multiple subsystem accesses, applied to a server, including:

generating a request protocol according to an external request and a pre-stored access file and sending the request protocol to a subsystem to be accessed, wherein the external request comprises a request parameter;

acquiring a response value of a subsystem to be accessed, and generating a response protocol according to an access file and the response value, wherein the response value comprises a response parameter;

the access file is generated by the access development method of the above embodiment.

In this embodiment, the server can use the access file generated in the development method to complete service invocation of the server to various subsystems. The access file is automatically analyzed and formed in an intermediate conversion class of a logic structure of a hierarchical structure representing the access protocol based on the access protocol of the subsystem by utilizing the analysis plug-in through the client, and the request parameter and the response parameter are respectively bound in the intermediate conversion class to be automatically generated, so that the research and development cost of the service of each subsystem called by the server is reduced, the labor cost is saved, and the wide application prospect is realized.

A hardware system implementing the application service method is shown with reference to fig. 7. Fig. 7 illustrates a hardware architecture of an application service system implementing an application service method based on multiple subsystem accesses, in operative relationship with multiple subsystems 300-1, 300-2, … …, and 300-n.

The application service system provided by the embodiment of the invention comprises: an application layer 101 receiving user operations, and an access layer 102 accessing a subsystem to be accessed, wherein the access layer is configured to:

generating a request protocol according to an external request of user operation received by an application layer and a pre-stored access file;

generating a response protocol according to an access protocol of a subsystem to be accessed and a response value received from the subsystem to be accessed;

completing the access of the subsystem to be accessed according to a response protocol so that an application layer calls the application service of the subsystem to be accessed according to the received user operation,

wherein, the access file is generated by the access development method.

In this embodiment, the server can complete service invocation of various subsystems by the server based on user operation by using the access file generated in the development method. The access file is automatically analyzed and formed in an intermediate conversion class of a logic structure of a hierarchical structure representing the access protocol based on the access protocol of the subsystem by utilizing the analysis plug-in through the client, and the request parameter and the response parameter are respectively bound in the intermediate conversion class to be automatically generated, so that the research and development cost of the service of each subsystem called by the server is reduced, the labor cost is saved, and the wide application prospect is realized.

Another embodiment of the present invention provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements: automatically generating a request conversion class for calling the subsystem to be accessed by the external server according to the request parameter of the external server and the access protocol of the subsystem to be accessed; sending the request conversion class to the subsystem to be accessed to acquire the response parameter of the subsystem to be accessed, and generating a response conversion class which responds to the calling of an external server side by the subsystem to be accessed according to the access protocol and the response parameter of the subsystem to be accessed; and generating an access file according to the request conversion class and the response conversion class.

Another embodiment of the present invention provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements: generating a request protocol according to an external request and a pre-stored access file and sending the request protocol to a subsystem to be accessed, wherein the external request comprises a request parameter; acquiring a response value of a subsystem to be accessed, and generating a response protocol according to an access file and the response value, wherein the response value comprises a response parameter; wherein, the access file is generated by the access development method.

In practice, the computer-readable storage medium may take any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present embodiment, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

As shown in fig. 8, another embodiment of the present invention provides a schematic structural diagram of a computer device. The computer device 12 shown in fig. 8 is only an example and should not bring any limitations to the functionality or scope of use of the embodiments of the present invention.

As shown in FIG. 8, computer device 12 is in the form of a general purpose computing device. The components of computer device 12 may include, but are not limited to: one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including the system memory 28 and the processing unit 16.

Bus 18 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures include, but are not limited to, Industry Standard Architecture (ISA) bus, micro-channel architecture (MAC) bus, enhanced ISA bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

Computer device 12 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer device 12 and includes both volatile and nonvolatile media, removable and non-removable media.

The system memory 28 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM)30 and/or cache memory 32. Computer device 12 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 34 may be used to read from and write to non-removable, nonvolatile magnetic media (not shown in FIG. 8, and commonly referred to as a "hard drive"). Although not shown in FIG. 8, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 by one or more data media interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

A program/utility 40 having a set (at least one) of program modules 42 may be stored, for example, in memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which examples or some combination thereof may comprise an implementation of a network environment. Program modules 42 generally carry out the functions and/or methodologies of the described embodiments of the invention.

Computer device 12 may also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), with one or more devices that enable a user to interact with computer device 12, and/or with any devices (e.g., network card, modem, etc.) that enable computer device 12 to communicate with one or more other computing devices. Such communication may be through an input/output (I/O) interface 22. Also, computer device 12 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network such as the Internet) via network adapter 20. As shown in FIG. 8, the network adapter 20 communicates with the other modules of the computer device 12 via the bus 18. It should be appreciated that although not shown in FIG. 8, other hardware and/or software modules may be used in conjunction with computer device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

The processor unit 16 executes various functional applications and data processing by executing programs stored in the system memory 28, for example, an access development method for accessing a plurality of subsystems or an application service method based on accessing a plurality of subsystems provided by the embodiment of the present invention is implemented.

It should be noted that, the order of the steps of the gaze tracking method provided in the embodiment of the present invention may be properly expressed, and the steps may be increased or decreased according to the situation, and any method that can be easily changed within the technical scope disclosed by the present disclosure by a person skilled in the art should be covered in the protection scope of the present invention, and therefore, the detailed description is omitted.

Aiming at the existing problems, the invention sets an access development method, a device, a system and a medium for accessing a plurality of subsystems, automatically generates a request conversion class for calling the subsystem to be accessed by an external server according to a request parameter of the external server and an access protocol of the subsystem to be accessed, and generates a response conversion class according to the access protocol and the response parameter of the subsystem to be accessed, so that an initiating terminal can automatically generate an access file, developers do not need to manually package complex classes of various subsystems according to a protocol format, the workload of development interfaces of law belief staff is reduced, the development difficulty is reduced, the development efficiency is greatly improved, and the invention has wide application prospect.

It should be understood that the above-mentioned embodiments of the present invention are only examples for clearly illustrating the present invention, and are not intended to limit the embodiments of the present invention, and it will be obvious to those skilled in the art that other variations and modifications can be made on the basis of the above description, and all embodiments cannot be exhaustive, and all obvious variations and modifications belonging to the technical scheme of the present invention are within the protection scope of the present invention.

20页详细技术资料下载
上一篇:一种医用注射器针头装配设备
下一篇:窗口关闭方法、装置、电子设备及存储介质

网友询问留言

已有0条留言

还没有人留言评论。精彩留言会获得点赞!

精彩留言,会给你点赞!