Patent Application
20200204461
The present application relates to a management system of web service, and especially to the automated management system for testing and publishing of web service.
In general, a firewall is configured to avoid the local network exposing under the internet, and the web-service cloud is set in a demilitarized zone (DMZ), which is a controlled and protected network area between internet and local network area. An application program interface (API) gateway is configured to control the access to web services, and then to reduce the coupling between the client end and the server end. The provider of the web services builds, publishes, maintains and monitors the web services through the API gateway. Thus the network security is enhanced by the API gateway.
However, it is a big burden to publish or update a web service. A web service needs to pass the unit test, integrated test, and system test before publishing. If an error occurs after publishing, the web-service system has to restore the system environment of a previous version, and that must be a disaster to the web-service provider.
The present application proposes a solution to automate the management system of testing and publishing web services, to reduce the burden of the provider and to enhance the management efficiency.
The present application proposes an automation system to avoid interrupting the web services in the updating process due to testing and publishing of the web services.
The present application proposes an automation system to automatize the procedures of testing and publishing web services in the environment of the online system, so that the provider does not need to prepare an additional testing environment, thereby minimizing the fail risk caused by environment compatibility.
The present application proposes an automation system to manage the version of web service, which is convenient for the provider to expand or to extend the web services.
An automation system for testing and publishing web services comprises a management dashboard, a message queue, a multiprocessing module, an API description document interpreter, an API gateway and a service registry module. The management dashboard receives an API description document, parses the API description document, puts a testing message in the message queue, and tests the list of web services from the API gateway. The API description document comprises the registry information of the web service. The message queue receives the message, transforms the message to a testing instruction and queues the testing request. The multiprocessing module takes the testing request and transmits the API description document to the API description document interpreter. Then the API description document interpreter sends a request to one web service of the web-service cloud system according to the API description document, and the web service receives the request in response to the API description document interpreter and transfers the result to the multiprocessing module. The multiprocessing module integrates the testing result to generate a report and transmits the report to the API gateway. The API gateway publishes a successful web service testing result and registers the web service on the web-service system. If the test does not pass, the API gateway reports a failed web service to the management dashboard.
An automation method for testing and publishing the web services comprises the following steps. The first step is to deploy a web service on the web-service system. The second step is to upload an API description document via a management dashboard, where the API description document comprises a registration information. The third step is to transform a testing message into a testing instruction format and to write the instruction onto a message queue by using the management dashboard. The fourth step is to read the testing instruction out of the message queue and to transmit the API description document to an API description document interpreter through the multiprocessing module. The fifth step is to execute the testing program of the web service according to the API description document by using the API description document interpreter. The interpreter sends a request to the web-service system, receives and collects the responses from the web-service system, and then passes the results to the multiprocessing module. The sixth step is to generate a testing report and sends the report to the API gateway. The API gateway registers the service on the web-service system for the web service that passed the test and to publish the web service automatically, or reports the testing result to management dashboard for the failed web service.
The drawings employed here are used to explain and not to limit the present application. The drawings do not mean the whole features of the present application, but some element(s) or some strep(s) is essential for the features of the present application. In some configuration, some element(s) or step(s) can be modified to reach some function according to the spirit of the present application, and that should be in the scope of the present application, i.e. more precisely, the scope of the present application is defined in the claims.
Referring to the
The automation system 300 uploads the API description document 100 by using the management dashboard 310, interacts with the web-service system 400 to test a web service, and the API gateway 350 registers the web service. Then the web service starts to provide the service to a client end 200. The automation system automates the procedure of testing and publishing one web service according to the API description document 100.
Moreover, the automation system 300, according to the embodiment of the present application shown in
First, the API description document includes the information including the web-service name, version, the IP address of the host, the path of the web service, the content of the web service, and the parameters of the web service and its type, the testing instructions of the web service, the testing item of the web service, the location of the testing report and so on. The API description document is configured to be extendable and expandable. In practice, the API description document 100 could be edited in the JSON or YAML format, which is a kind of serialized data type to have higher flexibility and readability than the traditional instruction file.
Second, the management dashboard comprises the functions at least below:
Third, the multiprocessing module 330 controls the testing procedure by reading the testing message and loading the API description document. Then the multiprocessing module 330 drives the API description document interpreter 340 to start to test the web service according to the API description document and receives the testing results to determine whether the web service passed the test or not according to the API description document 100. For the web services that failed the testing, the multiprocessing module 330 transmits the testing report to the management dashboard 310, and the web service provider can revise the API description document 100 based on the testing result. For the web services that passed the testing, the multiprocessing module 330 drives the API gateway 350 to register the web service and to publish the web service according to the API description document 100.
Forth, the API gateway 350 interacts with the multiprocessing module 330 to be the gateway of the web services. The API description document 100 comprises the information of web-service name, host, path and content and so on. The API gateway 350 registers the web service on service registry module 360 and then publishes the web service.
Fifth, the message queue 320 receives the testing message from the management dashboard 310 and buffers the testing message. Later, the multiprocessing module 330 reads the testing message to proceed with the testing.
Sixth, the API description document interpreter 340 is used to receive the instruction from the multiprocessing 330 to test the web service according to the API description document 100. The API description document interpreter 340 sends a request to the web service 410 deployed on the web-service system 400 and to receive the response from the web service 410. The instructions of the testing include “build”, “delete”, “update” and “get”, and the type of instruction is extendable and expandable. The instructions are transformed into the HTTP or RESTful format, so the testing instructions can be transmitted via HTTP protocol. The API description document interpreter 340 interacts with the web service 410 in the web-service system 400. The API description document interpreter 340 sends a request to the web service 410 according to the API description document 100, the web service 410 computes to get a result and responds to the API description document interpreter 340. Then the API description document interpreter 340 returns the response to the multiprocessing module 330.
The automation system for testing and publishing the web service can be equipped with a service discovery module to have the function of Service Discovery, and the automation system is able to discover automatically the web service, to test the web service and to publish the web service. The service discovery module comprises a server-side component and a client-side component, and the service-side component interacts with the service registry module to automatize the service discovery. The service registry module comprises a database to maintain the web services and the path to the service location, i.e. host of the service. The server-side component of the service discovery module is located at the automation system for testing and publishing the web service. The client-side component of the service registry module is located at the web-service system. The service discovery module could look up the database of the service registry module. The client-side component could send a request of registering the web service to the server-side component. Once a web service starts, the client-side component sends the registering request with the information to the server-side component, where the request information comprises the service name, host name, IP address, status page, health check and so on. The server-side component looks up the registration status of the web service, and pushes a testing message into the message queue to trigger a testing if the web service is not found, i.e. not registered. The multiprocessing module reads out the testing message to complete the testing and registration, as mentioned above in this document. Once a web service stops, the service registry is also triggered the server-side component to look up the registration status and to remove the registry information. If the automation system is not equipped with the service discovery module, the user or the manager is able to test, to register or to remove web service via the management dashboard.
The process of service discovery is explained below:
The user or manager can also use the management dashboard 310 to look up the registration status of a service through the API gateway to complete the testing and registering manually. The process is as below:
It is noted that the automation system for testing and publishing the web service with different versions, so the testing and publishing does not affect the published web service. The user uses the version of the API description document 100 to handle the updating to the web service. The web services with different versions do not affect each other and the published service.
