WO2016127856A1 - 从中间件请求数据的方法、***及中间件客户端 - Google Patents
从中间件请求数据的方法、***及中间件客户端 Download PDFInfo
- Publication number
- WO2016127856A1 WO2016127856A1 PCT/CN2016/073146 CN2016073146W WO2016127856A1 WO 2016127856 A1 WO2016127856 A1 WO 2016127856A1 CN 2016073146 W CN2016073146 W CN 2016073146W WO 2016127856 A1 WO2016127856 A1 WO 2016127856A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- middleware
- data
- loaded
- requested
- webpage
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
Definitions
- the present application relates to the field of Internet technologies, and in particular, to a method, a system, and a middleware client for requesting data from a middleware.
- a batch interface is usually provided through the middleware, and the requesting party performs request combining through the batch interface.
- the bulk interface can solve the problem of multiple calls, when the request merge is coupled with the requester's business code, the following problems are caused: (1) when a new call needs to be added, or an unused call is deleted. When the requester must change the code that requests the merge; (2) the caller needs to write the logic of the merge call in all places where there is a merge requirement; (3) in the hierarchical architecture, the call merge of different layers will also give The transfer of the call result is difficult.
- the purpose of the present application is to solve at least one of the technical problems in the related art to some extent.
- the first object of the present application is to propose a method of requesting data from a middleware.
- the method completes the request merging through the self-learning of the middleware client, which not only solves the problem caused by the request merge in the related art, but also does not need to understand the whole process of request merging, and simplifies the operation of the requesting party.
- a second object of the present application is to propose a system for requesting data from a middleware.
- a third object of the present application is to propose a middleware client.
- the method for requesting data from a middleware includes: acquiring feature information related to a webpage to be loaded, and determining, according to the feature information, a to-be-request corresponding to the to-be-loaded webpage.
- the to-be-requested data name set includes at least one middleware corresponding to-be-requested data name; receiving a middleware data request, and determining a target middleware according to the middleware data request; according to the target middleware Determining, to the requested data name set, a to-be-requested data name that needs to be acquired from the target middleware; and obtaining a corresponding correspondence from the target middleware according to the to-be-requested data name acquired from the target middleware Middleware data collection and cache, wherein if a middleware data request sent to the target middleware is received again And extracting and feeding back corresponding middleware data from the cached middleware data set.
- the middleware client After a webpage loading request, the middleware client records the resources requested by the plurality of middleware data requests, and when the next webpage loading request arrives, the middleware client
- the terminal receives the middleware data request sent to the target middleware for the first time, according to the middleware data request of the resource recorded in the process of the last webpage loading request, the automatic merge is performed, that is, by providing a batch.
- the interface requests the merged resource to the target middleware through the batch interface, and caches the request result in the middleware client. If the middleware client receives the request to the target middleware again during the loading request of the webpage.
- the middleware data request When the middleware data request is received, the corresponding middleware data is extracted and fed back from the cached request result, which not only solves the problem caused by the request merge in the related art, but also does not need to understand the entire request merge. The process simplifies the operation of the requestor.
- a system for requesting data from a middleware includes a user client, a web server, a middleware client, and at least one middleware, wherein the user client is used to
- the web server sends a webpage loading request and receives webpage data fed back by the webpage server;
- the webpage server is configured to construct a webpage to be loaded according to the webpage loading request, and send a middleware data request to the middleware client Obtaining the middleware data from the at least one middleware, and feeding back the obtained middleware data to the user client;
- the middleware client is configured to acquire feature information related to the webpage to be loaded, and Determining, according to the feature information, a to-be-requested data name set corresponding to the to-be-loaded webpage, and determining a target middleware according to the middleware data request, and determining, according to the target middleware and the to-be-requested data name set, The name of the data to be requested obtained by the target middleware, and the The to
- the middleware client After a webpage loading request, the middleware client records the resources requested by the plurality of middleware data requests, and when the next webpage loading request arrives, the middleware client
- the terminal receives the middleware data request sent to the target middleware for the first time, according to the middleware data request of the resource recorded in the process of the last webpage loading request, the automatic merge is performed, that is, by providing a batch.
- the interface requests the merged resource to the target middleware through the batch interface, and caches the request result in the middleware client. If the middleware client receives the request to the target middleware again during the loading request of the webpage.
- the middleware data request When the middleware data request is received, the corresponding middleware data is extracted and fed back from the cached request result, which not only solves the problem caused by the request merge in the related art, but also does not need to understand the entire request merge. The process simplifies the operation of the requestor.
- the middleware client of the third aspect of the present application includes: a data name to be requested a set determining module, configured to acquire feature information related to a webpage to be loaded, and determine a to-be-requested data name set corresponding to the to-be-loaded webpage according to the feature information, where the to-be-requested data name set includes at least one middle Corresponding data name to be requested; target middleware determining module, configured to receive a middleware data request, and determine a target middleware according to the middleware data request; a data name determining module to be requested, according to the target middleware And the to-be-requested data name set determines a to-be-requested data name that needs to be acquired from the target middleware; and a middleware data providing module, configured to obtain a to-be-requested data name from the target middleware according to the requirement Obtaining a corresponding middleware data set from the target middleware and caching, wherein if the middleware data request sent to the
- the middleware client in the embodiment of the present application may record the resources requested by the plurality of middleware data requests after a webpage loading request, and receive the target middleware for the first time when the next webpage loading request arrives.
- the middleware data request for the resource recorded in the process of the last webpage loading request is automatically merged, that is, by providing a batch interface and through the batch interface to the target middleware. Requesting the merged resource and caching the result of the request in the middleware client.
- the slave cache extracts and feeds back the corresponding middleware data, which not only solves the problem caused by the request merge in the above related art, but also does not need to understand the entire request merge process, and simplifies the requester's operation.
- FIG. 1 is a flow chart of a method of requesting data from a middleware in accordance with one embodiment of the present application
- FIG. 2 is a diagram showing an example of a flow of operations when a first user accesses a page by a method of requesting data from a middleware according to an embodiment of the present application;
- FIG. 3 is a diagram showing an example of a flow of operations when a second user accesses a page by a method of requesting data from a middleware according to an embodiment of the present application;
- FIG. 4 is a schematic structural diagram of a system for requesting data from a middleware according to an embodiment of the present application
- FIG. 5 is a schematic structural diagram of a middleware client according to an embodiment of the present application.
- FIG. 6 is a schematic structural diagram of a middleware client according to another embodiment of the present application.
- FIG. 1 is a flow chart of a method of requesting data from a middleware in accordance with one embodiment of the present application. As shown in FIG. 1, the method for requesting data from the middleware may include:
- the feature information may be address information of a page to be loaded, member type information of a user requesting a page to be loaded, and a name of a page to be loaded (eg, a list page, a detail page) Etc., requesting client information of the page to be loaded (such as browser information, operating system information, etc.), requesting cookie information of the page to be loaded, or calling interface or parameter when the web server calls the middleware client.
- the to-be-requested data name set corresponding to the to-be-loaded webpage may be generated by: recording the middleware data request sent to the at least one middleware when the to-be-loaded webpage is loaded for the first time And the feature information related to the webpage to be loaded; and generating the to-be-requested data name set according to the recorded middleware data request, and establishing an association relationship between the feature information and the to-be-requested data name set.
- the webpage server may construct the webpage to be loaded according to the webpage loading request, and the middleware client may obtain the feature information related to the webpage to be loaded, such as the webpage to be loaded.
- the address information such as a URL (Uniform Resource Locator)
- the member type information of the user to which the user client belongs, and the like and then determining, according to the feature information, the to-be-requested data name set corresponding to the to-be-loaded webpage, It is understood that the to-be-requested data name set corresponding to the to-be-loaded webpage is generated during the first loading of the to-be-loaded webpage.
- S102 Receive a middleware data request, and determine a target middleware according to the middleware data request.
- the middleware client may receive the middleware data request sent by the webpage server, and find a corresponding data request corresponding to the middleware according to the middleware data request.
- the middleware serves as the target middleware.
- the middleware client may be based on the target middleware and the to-be-requested data name set. Determine the name of the data to be requested that needs to be obtained from the target middleware.
- the method for requesting data from the middleware in the embodiment of the present application is to complete the request merging through the self-learning of the middleware client, and the basic idea of automatically requesting the merge is: after a webpage loading request, the middleware client will The resource requested by the plurality of middleware data requests is recorded, and when the next webpage loading request arrives, when the middleware client receives the middleware data request sent to the target middleware for the first time, presses the last webpage loading request.
- the middleware data request for the resource recorded in the process is automatically merged, that is, by providing a batch interface, and requesting the merged resource to the target middleware through the batch interface, and simultaneously caching the request result in the middleware client.
- the middleware client receives the middleware data request sent to the target middleware again during the loading process of the webpage, the corresponding middleware data is extracted and fed back from the cached request result. .
- the method may further include: after the middleware data corresponding to all the data names to be requested in the to-be-requested data name set corresponding to the webpage to be loaded is fed back, the cache is cleared. .
- the lifetime of the cache is one page load request, and the cached result is only visible to the current page load request. Therefore, after the webpage loading request ends, the cache is emptied, on the one hand, the server resources can be released, and on the other hand, the middleware data in the cache does not be disordered between different webpage loading requests.
- the to-be-loaded page may need to invoke multiple middleware
- the to-be-requested data name set may include a plurality of middleware corresponding to-be-requested data names. That is, the method for requesting data from the middleware in the embodiment of the present application is also applicable to requesting data from multiple middlewares.
- the set of data names to be requested may include the plurality of The middleware corresponds to the name of the data to be requested.
- the middleware client When the middleware client receives the middleware data request corresponding to the middleware, the processing of the foregoing steps S102-S104 is performed according to the middleware data request corresponding to the middleware, to obtain all the calls that need to be called in the to-be-loaded page. Middleware data corresponding to the middleware.
- a middleware for rights management. All user permissions exist in this middleware.
- how much content will be displayed on the user's web page is controlled by the permissions of the content area.
- the permissions of the content area For example, taking a webpage with a URL of /admin/monitor.jsp as an example, suppose that there are four areas on the page of the webpage, and the permissions of each area are featureA, featureB, featureC, and featureD, then when the webpage is to be rendered, The permission middleware will need to be requested 4 times to complete the rendering of the 4 areas in the page.
- boolean isAllowed service.isAllowed(personID,featureA)
- This call will ask the remote permission middleware whether the current personID has the function of featureA. If there is this function, the content corresponding to featureA is displayed on the page.
- the middleware client can acquire and record the feature information URL related to the webpage to be loaded from the webpage server, and the middleware client can receive the middleware sent to the middleware.
- the middleware data request obtain corresponding middleware data from the target middleware and feed back to the web server, and the web server treats the webpage according to the middleware data.
- the middleware client generates and records the to-be-requested data name set according to the received middleware data request, and establishes a correspondence relationship between the feature information URL and the to-be-requested data name set, and at the same time
- the client requires the web server to pass the variable personID to the middleware client.
- the correspondence between the feature information URL and the set of data names to be requested is as follows:
- the middleware client may search for a corresponding data name set to be requested according to the URL sent by the web server.
- the data name to be requested The collection is [featureA, featureB, featureC, featureD], and the data is warmed up according to the variable (personID) passed in by the web server.
- the data warm-up will call the batch interface, request all the resources corresponding to the above-mentioned data name set to be requested from the middleware, and cache them.
- the web server's call to the middleware will get the data from the cache.
- the cache is cleared, wherein the cache life cycle is one user's webpage request, and the cached result is only visible to the current webpage request. .
- the request merge is completed through the self-learning of the middleware client, which not only solves the problem caused by the request merge in the related art, but also does not need to understand the entire request merge.
- the process simplifies the operation of the requestor.
- the present application also proposes a system for requesting data from a middleware.
- the system for requesting data from the middleware may include a user client 10, a web server 20, a middleware client 30, and at least one middleware 40.
- the user client 10 can be used to send a webpage loading request to the webpage server 20 and receive webpage data fed back by the webpage server 20.
- the web server 20 can be configured to construct a webpage to be loaded according to the webpage loading request, and send a middleware data request to the middleware client 30 to acquire the middleware data from the at least one middleware 40, and feed back the obtained middleware data to the user client.
- the middleware client 30 may be configured to acquire feature information related to the webpage to be loaded, determine a to-be-requested data name set corresponding to the webpage to be loaded according to the feature information, and determine a target middleware according to the middleware data request, and according to the target middleware And the to-be-requested data name set determines the to-be-requested data name that needs to be acquired from the target middleware, and obtains the corresponding middleware data set from the target middleware according to the required data name acquired from the target middleware and caches, and caches again Upon receiving the middleware data request sent to the target middleware, the corresponding middleware data is extracted and fed back from the cached middleware data set, wherein the to-be-requested data name set includes at least one middleware corresponding to-be-requested data name.
- the middleware client 30 is further configured to record the middleware data request sent to the at least one middleware 40 and the feature information related to the webpage to be loaded when the webpage to be loaded is loaded for the first time. And generating a to-be-requested data name set according to the recorded middleware data request, and establishing an association relationship between the feature information and the to-be-requested data name set.
- the feature information may be address information of the page to be loaded, member type information of the user requesting the page to be loaded, name of the page to be loaded (such as a list page, a detail page, etc.), and client information requesting the page to be loaded (if used) Browser information, operating system information, etc.), requesting cookie information of the page to be loaded or calling interface or parameter when the web server calls the middleware client.
- the webpage server 20 can construct a webpage to be loaded according to the webpage loading request, and the middleware client 30 can acquire the feature information related to the webpage to be loaded, such as The address information (such as a URL) of the webpage to be loaded or the member type information of the user to which the user client 10 belongs, and the like, may determine the set of data names to be requested corresponding to the webpage to be loaded according to the feature information, and it may be understood that the foregoing The set of to-be-requested data names corresponding to the loaded webpage is generated during the first loading of the webpage to be loaded.
- the address information such as a URL
- the set of to-be-requested data names corresponding to the loaded webpage is generated during the first loading of the webpage to be loaded.
- the web server 20 may send a middleware data request to the middleware client 30 to acquire middleware data from the at least one middleware 40, and the middleware client 30 may request the middleware data after receiving the middleware data request.
- the set of the data and the to-be-requested data name can determine the name of the data to be requested that needs to be obtained from the target middleware, and obtain the corresponding middleware data set from the target middleware according to the data name to be requested acquired from the target middleware as needed. And buffering, and receiving the middleware data request sent to the target middleware again, extracting and feeding back the corresponding middleware data from the cached middleware data set.
- the middleware client 30 may be further configured to: after the middleware data corresponding to all the data names to be requested in the to-be-requested data name set corresponding to the webpage to be loaded is fed back, Cache.
- the lifetime of the cache is one page load request, and the cached result is only visible to the current page load request. Therefore, after the webpage loading request ends, the cache is emptied, on the one hand, the server resources can be released, and on the other hand, the middleware data in the cache does not be disordered between different webpage loading requests.
- the to-be-loaded page may need to invoke multiple middleware
- the to-be-requested data name set may include a plurality of middleware corresponding to-be-requested data names. That is, the system for requesting data from the middleware in the embodiment of the present application is also applicable to requesting data from a plurality of middlewares.
- the set of data names to be requested may include the plurality of The middleware corresponds to the name of the data to be requested.
- the middleware client When the middleware client receives the middleware data request corresponding to the middleware, the corresponding processing is performed according to the middleware data request corresponding to the middleware, so as to obtain all the middlewares that need to be called in the to-be-loaded page. Middleware data.
- the middleware client After a webpage loading request, the middleware client records the resources requested by the plurality of middleware data requests, and when the next webpage loading request arrives, the middleware client
- the terminal receives the middleware data request sent to the target middleware for the first time, according to the middleware data request of the resource recorded in the process of the last webpage loading request, the automatic merge is performed, that is, by providing a batch.
- the interface requests the merged resource to the target middleware through the batch interface, and caches the request result in the middleware client. If the middleware client receives the request to the target middleware again during the loading request of the webpage.
- the middleware data request When the middleware data request is received, the corresponding middleware data is extracted and fed back from the cached request result, which not only solves the problem caused by the request merge in the related art, but also does not need to understand the entire request merge. The process simplifies the operation of the requestor.
- the present application also proposes a middleware client.
- FIG. 5 is a schematic structural diagram of a middleware client according to an embodiment of the present application.
- the middleware client may include a to-be-requested data name set determining module 31, a target middleware determining module 32, a to-be-requested data name determining module 33, and a middleware data providing module 34.
- the to-be-requested data name set determining module 31 can be configured to acquire feature information related to the webpage to be loaded, And determining, according to the feature information, the to-be-requested data name set corresponding to the to-be-loaded webpage, where the to-be-requested data name set includes at least one middleware corresponding to-be-requested data name.
- the feature information may be address information of a page to be loaded, member type information of a user requesting a page to be loaded, a name of a page to be loaded (such as a list page, a detail page, etc.), and a request to be loaded.
- the client information of the page (such as browser information, operating system information, etc.), the cookie information requesting the page to be loaded, or the calling interface or parameter when the web server calls the middleware client.
- the to-be-requested data name set determining module 31 is further configured to record the middleware data request and the to-be-loaded webpage sent to the at least one middleware when the to-be-loaded webpage is loaded for the first time. Correlating feature information, and generating a to-be-requested data name set according to the recorded middleware data request, and establishing an association relationship between the feature information and the to-be-requested data name set.
- the webpage server may construct the webpage to be loaded according to the webpage loading request, and the to-be-requested data name collection determining module 31 may acquire the feature information related to the webpage to be loaded, such as The address information of the to-be-loaded webpage or the member type information of the user to which the user client belongs, and the like, and then determining the to-be-requested data name set corresponding to the to-be-loaded webpage according to the feature information.
- the set of pending data names is generated during the first loading of the web page to be loaded.
- the target middleware determination module 32 can be configured to receive the middleware data request and determine the target middleware based on the middleware data request. More specifically, after the web server constructs the webpage to be loaded according to the webpage loading request sent by the user, the target middleware determining module 32 may receive the middleware data request sent by the webpage server, and find the data with the middleware according to the middleware data request. The corresponding middleware is requested as the target middleware.
- the to-be-requested data name determining module 33 is operable to determine, according to the target middleware and the set of data names to be requested, the to-be-requested data name that needs to be acquired from the target middleware. It should be understood that, since the to-be-requested data name set includes the to-be-requested data name corresponding to the middleware, after receiving the middleware data request, the to-be-requested data name determining module 33 may be configured according to the target middleware and the to-be-requested data name set. Determine the name of the data to be requested that needs to be obtained from the target middleware.
- the middleware data providing module 34 may be configured to acquire and cache a corresponding middleware data set from the target middleware according to the to-be-requested data name acquired from the target middleware, where the middleware data sent to the target middleware is received again.
- the request extracts and feeds back the corresponding middleware data from the cached middleware data set.
- the middleware client in the embodiment of the present application completes the request merging through self-learning, and the basic idea of automatically requesting merging is: after a webpage loading request, the middleware client will request multiple middleware data requests. The requested resource is recorded, and when the next time the webpage loading request arrives, when the middleware client receives the middleware data request sent to the target middleware for the first time, the multiple times recorded in the process of the last webpage loading request are recorded.
- the middleware data request is automatically merged, that is, by providing a batch interface and requesting the merged resource to the target middleware through the batch interface, and simultaneously caching the request result in the middleware client, if the request is loaded in the webpage
- the middleware client receives the middleware data request sent to the target middleware again, the corresponding middleware data is extracted and fed back from the cached request result.
- the middleware client may further include a cache management module 35, where the cache management module 35 may be used to name the data to be requested corresponding to the webpage to be loaded. After the middleware data corresponding to all the data names to be requested in the collection are all fed back, the cache is cleared.
- the lifetime of the cache is one page load request, and the cached result is only visible to the current page load request. Therefore, after the webpage loading request ends, the cache is emptied, on the one hand, the server resources can be released, and on the other hand, the middleware data in the cache does not be disordered between different webpage loading requests.
- the to-be-requested data name set may include a plurality of middleware corresponding to-be-requested data names. That is, the middleware client of the embodiment of the present application is also applicable to requesting data from multiple middlewares.
- the set of to-be-requested data names may include the plurality of middlewares. Corresponding data names to be requested.
- the middleware client When the middleware client receives the middleware data request corresponding to the middleware, the corresponding processing is performed according to the middleware data request corresponding to the middleware, so as to obtain all the middlewares that need to be called in the to-be-loaded page. Middleware data.
- the middleware client in the embodiment of the present application may record the resources requested by the plurality of middleware data requests after a webpage loading request, and receive the target middleware for the first time when the next webpage loading request arrives.
- the middleware data request for the resource recorded in the process of the last webpage loading request is automatically merged, that is, by providing a batch interface and through the batch interface to the target middleware. Requesting the merged resource and caching the result of the request in the middleware client.
- the slave cache extracts and feeds back the corresponding middleware data, which not only solves the problem caused by the request merge in the above related art, but also does not need to understand the entire request merge process, and simplifies the requester's operation.
- first and second are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated.
- features defining “first” or “second” may include at least one of the features, either explicitly or implicitly.
- the meaning of "a plurality” is at least two, such as two, three, etc., unless specifically defined otherwise.
- a "computer-readable medium” can be any apparatus that can contain, store, communicate, propagate, or transport a program for use in an instruction execution system, apparatus, or device, or in conjunction with the instruction execution system, apparatus, or device.
- computer readable media include the following: electrical connections (electronic devices) having one or more wires, portable computer disk cartridges (magnetic devices), random access memory (RAM), Read only memory (ROM), erasable editable read only memory (EPROM or flash memory), fiber optic devices, and portable compact disk read only memory (CDROM).
- the computer readable medium may even be a paper or other suitable medium on which the program can be printed, as it may be optically scanned, for example by paper or other medium, followed by editing, interpretation or, if appropriate, other suitable The method is processed to obtain the program electronically and then stored in computer memory.
- portions of the application can be implemented in hardware, software, firmware, or a combination thereof.
- multiple steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system.
- a suitable instruction execution system For example, if implemented in hardware, as in another embodiment, it can be implemented by any one or combination of the following techniques well known in the art: having logic gates for implementing logic functions on data signals. Discrete logic circuits, application specific integrated circuits with suitable combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.
- each functional unit in each embodiment of the present application may be integrated into one processing module, or may be each Units exist physically separately, or two or more units can be integrated into one module.
- the above integrated modules can be implemented in the form of hardware or in the form of software functional modules.
- the integrated modules, if implemented in the form of software functional modules and sold or used as stand-alone products, may also be stored in a computer readable storage medium.
- the above mentioned storage medium may be a read only memory, a magnetic disk or an optical disk or the like. While the embodiments of the present application have been shown and described above, it is understood that the above-described embodiments are illustrative and are not to be construed as limiting the scope of the present application. The embodiments are subject to variations, modifications, substitutions and variations.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
Abstract
一种从中间件请求数据的方法、***及中间件客户端,其中该方法包括:获取与待加载网页相关的特征信息,并根据特征信息确定待加载网页所对应的待请求数据名称集合,其中待请求数据名称集合包括至少一个中间件对应的待请求数据名称(S101);接收中间件数据请求,并根据中间件数据请求确定目标中间件(S102);根据目标中间件和待请求数据名称集合确定需要从目标中间件所获取的待请求数据名称(S103);以及根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存,其中如果再次接收到向目标中间件发送的中间件数据请求则从缓存的中间件数据集合中提取并反馈对应的中间件数据(S104)。该方法解决了请求合并所带来的问题。
Description
本申请涉及互联网技术领域,尤其涉及一种从中间件请求数据的方法、***及中间件客户端。
随着互联网技术的快速发展,互联网网站已经逐渐形成规模化,当网站***的规模大到一定程度后,***就会趋于服务化,所以在大规模的网站***中,一个网页往往需要多次请求多个中间件才能完成渲染。
相关技术中,当一个网页多次请求同一个中间件时,通常是通过中间件提供一个批量接口,请求方通过该批量接口进行请求合并。虽然批量接口能够解决多次调用的问题,但是,当将请求合并与请求方的业务代码耦合在一起时,会带来以下问题:(1)当需要增加一个新调用,或者删除一个不用的调用时,请求方必须改动请求合并的代码;(2)调用方需要在所有有合并需求的地方写上合并调用的逻辑;(3)在分层式的架构中,不同层的调用合并也会给调用结果的传递带来困难。
发明内容
本申请的目的旨在至少在一定程度上解决相关技术中的技术问题之一。
为此,本申请的第一个目的在于提出一种从中间件请求数据的方法。该方法通过中间件客户端的自学习来完成请求合并,不但解决了上述相关技术中请求合并所带来的问题,同时请求方不需要了解整个请求合并的过程,简化了请求方的操作。
本申请的第二个目的在于提出一种从中间件请求数据的***。
本申请的第三个目的在于提出一种中间件客户端。
为了达到上述目的,本申请第一方面实施例的从中间件请求数据的方法,包括:获取与待加载网页相关的特征信息,并根据所述特征信息确定所述待加载网页所对应的待请求数据名称集合,其中,所述待请求数据名称集合包括至少一个中间件对应的待请求数据名称;接收中间件数据请求,并根据所述中间件数据请求确定目标中间件;根据所述目标中间件和所述待请求数据名称集合确定需要从所述目标中间件所获取的待请求数据名称;以及根据所述需要从所述目标中间件所获取的待请求数据名称从所述目标中间件获取对应的中间件数据集合并缓存,其中,如果再次接收到向所述目标中间件发送的中间件数据请求
则从所述缓存的所述中间件数据集合中提取并反馈对应的中间件数据。
本申请实施例的从中间件请求数据的方法,在一次网页加载请求过后,中间件客户端将多个中间件数据请求所请求的资源记录下来,当下一次网页加载请求到来时,在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时,按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求,做自动的合并,即通过提供一个批量接口,并通过批量接口向目标中间件请求合并后的资源,同时将请求结果缓存在中间件客户端,如果在本次网页加载请求的过程中,中间件客户端再次接收到向目标中间件发送的中间件数据请求时,则从缓存的请求结果中提取并反馈对应的中间件数据即可,不但解决了上述相关技术中请求合并所带来的问题,同时请求方不需要了解整个请求合并的过程,简化了请求方的操作。
为了达到上述目的,本申请第二方面实施例的从中间件请求数据的***,包括用户客户端、网页服务器、中间件客户端和至少一个中间件,其中,所述用户客户端,用于向所述网页服务器发送网页加载请求并接收所述网页服务器反馈的网页数据;所述网页服务器,用于根据所述网页加载请求构建待加载网页,并向所述中间件客户端发送中间件数据请求以从所述至少一个中间件获取中间件数据,以及将获取的中间件数据反馈至所述用户客户端;所述中间件客户端,用于获取与所述待加载网页相关的特征信息,并根据所述特征信息确定所述待加载网页所对应的待请求数据名称集合,以及根据中间件数据请求确定目标中间件,并根据所述目标中间件和所述待请求数据名称集合确定需要从所述目标中间件所获取的待请求数据名称,以及根据所述需要从所述目标中间件所获取的待请求数据名称从所述目标中间件获取对应的中间件数据集合并缓存,并再次接收到向所述目标中间件发送的中间件数据请求时,从所述缓存的所述中间件数据集合中提取并反馈对应的中间件数据,其中,所述待请求数据名称集合包括至少一个中间件对应的待请求数据名称。
本申请实施例的从中间件请求数据的***,在一次网页加载请求过后,中间件客户端将多个中间件数据请求所请求的资源记录下来,当下一次网页加载请求到来时,在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时,按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求,做自动的合并,即通过提供一个批量接口,并通过批量接口向目标中间件请求合并后的资源,同时将请求结果缓存在中间件客户端,如果在本次网页加载请求的过程中,中间件客户端再次接收到向目标中间件发送的中间件数据请求时,则从缓存的请求结果中提取并反馈对应的中间件数据即可,不但解决了上述相关技术中请求合并所带来的问题,同时请求方不需要了解整个请求合并的过程,简化了请求方的操作。
为了达到上述目的,本申请第三方面实施例的中间件客户端,包括:待请求数据名称
集合确定模块,用于获取与待加载网页相关的特征信息,并根据所述特征信息确定所述待加载网页所对应的待请求数据名称集合,其中,所述待请求数据名称集合包括至少一个中间件对应的待请求数据名称;目标中间件确定模块,用于接收中间件数据请求,并根据所述中间件数据请求确定目标中间件;待请求数据名称确定模块,用于根据所述目标中间件和所述待请求数据名称集合确定需要从所述目标中间件所获取的待请求数据名称;以及中间件数据提供模块,用于根据所述需要从所述目标中间件所获取的待请求数据名称从所述目标中间件获取对应的中间件数据集合并缓存,其中,如果再次接收到向所述目标中间件发送的中间件数据请求则从所述缓存的所述中间件数据集合中提取并反馈对应的中间件数据。
本申请实施例的中间件客户端,在一次网页加载请求过后,可将多个中间件数据请求所请求的资源记录下来,当下一次网页加载请求到来时,在第一次接收到向目标中间件发送的中间件数据请求时,按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求,做自动的合并,即通过提供一个批量接口,并通过批量接口向目标中间件请求合并后的资源,同时将请求结果缓存在中间件客户端,如果在本次网页加载请求的过程中,中间件客户端再次接收到向目标中间件发送的中间件数据请求时,则从缓存的请求结果中提取并反馈对应的中间件数据即可,不但解决了上述相关技术中请求合并所带来的问题,同时请求方不需要了解整个请求合并的过程,简化了请求方的操作。
本申请附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本申请的实践了解到。
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中,
图1是根据本申请一个实施例的从中间件请求数据的方法的流程图;
图2是根据本申请一个实施例的从中间件请求数据的方法在第一次用户访问页面时所操作流程的示例图;
图3是根据本申请一个实施例的从中间件请求数据的方法在第二次用户访问页面时所操作流程的示例图;
图4是根据本申请一个实施例的从中间件请求数据的***的结构示意图;
图5是根据本申请一个实施例的中间件客户端的结构示意图;
图6是根据本申请另一个实施例的中间件客户端的结构示意图。
下面详细描述本申请的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本申请,而不能理解为对本申请的限制。
下面参考附图描述本申请实施例的从中间件请求数据的方法、***及中间件客户端。
图1是根据本申请一个实施例的从中间件请求数据的方法的流程图。如图1所示,该从中间件请求数据的方法可以包括:
S101,获取与待加载网页相关的特征信息,并根据特征信息确定待加载网页所对应的待请求数据名称集合,其中,待请求数据名称集合包括至少一个中间件对应的待请求数据名称。
此外,在本申请的实施例中,特征信息可为待加载页面的地址信息、请求待加载页面的用户的会员类型信息、待加载页面的名称(如list(目录)页面、detail(详情)页面等)、请求待加载页面的客户端信息(如所用浏览器信息、操作***信息等)、请求待加载页面的Cookie信息或者是网页服务器调用中间件客户端时的调用接口或参数等。
另外,在本申请的实施例中,待加载网页所对应的待请求数据名称集合可通过以下步骤生成:当待加载网页被第一次加载时,记录向至少一个中间件发送的中间件数据请求及与待加载网页相关的特征信息;以及根据记录的中间件数据请求生成待请求数据名称集合,并建立特征信息与待请求数据名称集合之间的关联关系。
具体地,当用户客户端向网页服务器发送网页加载请求时,网页服务器可根据网页加载请求构建待加载网页,中间件客户端可获取与该待加载网页相关的特征信息,如该待加载网页的地址信息(如URL(Uniform Resource Locator,统一资源定位符))或者上述用户客户端所属用户的会员类型信息等,之后可根据上述特征信息确定上述待加载网页所对应的待请求数据名称集合,可以理解,上述待加载网页所对应的待请求数据名称集合是在该待加载网页被第一次加载的过程中生成的。
S102,接收中间件数据请求,并根据中间件数据请求确定目标中间件。
具体地,在网页服务器根据用户发送的网页加载请求构建待加载网页之后,中间件客户端可接收网页服务器发送的中间件数据请求,并根据该中间件数据请求找到与该中间件数据请求对应的中间件作为目标中间件。
S103,根据目标中间件和待请求数据名称集合确定需要从目标中间件所获取的待请求数据名称。
应当理解,由于上述待请求数据名称集合包括中间件对应的待请求数据名称,所以,中间件客户端在接收到中间件数据请求之后,根据目标中间件和待请求数据名称集合即可
确定需要从目标中间件中所要获取的待请求数据名称。
S104,根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存,其中,如果再次接收到向目标中间件发送的中间件数据请求则从缓存的中间件数据集合中提取并反馈对应的中间件数据。
综上所述,本申请实施例的从中间件请求数据的方法是通过中间件客户端自学习来完成请求合并,自动请求合并的基本思路为:在一次网页加载请求过后,中间件客户端将多个中间件数据请求所请求的资源记录下来,当下一次网页加载请求到来时,在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时,按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求,做自动的合并,即通过提供一个批量接口,并通过批量接口向目标中间件请求合并后的资源,同时将请求结果缓存在中间件客户端中,如果在本次网页加载请求的过程中,中间件客户端再次接收到向目标中间件发送的中间件数据请求时,则从缓存的请求结果中提取并反馈对应的中间件数据即可。
进一步的,在本申请的一个实施例中,所述方法还可包括:在将待加载网页所对应的待请求数据名称集合中全部待请求数据名称对应的中间件数据均反馈完毕之后,清空缓存。可以理解,在本申请的实施例中,缓存的生命周期为一次网页加载请求,并且缓存的结果只对本次网页加载请求可见。由此,在本次网页加载请求结束后将缓存清空,一方面可以释放服务器资源,另一方面,不同网页加载请求之间不会造成缓存中中间件数据的紊乱。
可选的,在本申请的一个实施例中,待加载页面可以需要调用多个中间件,待请求数据名称集合可包括多个中间件分别对应的待请求数据名称。也就是说,本申请实施例的从中间件请求数据的方法也适用于从多个中间件请求数据,当待加载页面需要调用多个中间件时,上述待请求数据名称集合则可包括该多个中间件分别对应的待请求数据名称。当中间件客户端接收到哪个中间件对应的中间件数据请求时,则根据该中间件对应的中间件数据请求进行上述步骤S102-S104的处理,以获取该待加载页面中所需要调用的所有中间件对应的中间件数据。
为了使得本领域的技术人员更加清楚地了解本申请,下面将以单个中间件为例对本申请作进一步描述。
举例而言,假设现在有一个权限管理的中间件,所有用户的权限都存在于这个中间件中,当一个用户登录网站后,该用户的网页页面上将要展示多少内容由内容区域的权限所控制。例如,以URL地址为/admin/monitor.jsp的网页为例,假设该网页页面上有4个区域,每一个区域的权限分别为featureA,featureB,featureC,featureD,那么当要渲染这个网页时,将需要向权限中间件请求4次以完成页面中4个区域的渲染。其中,一次对权限中间件的调用示例为:boolean isAllowed=service.isAllowed(personID,featureA),
这个调用会向远程的权限中间件询问当前personID是否拥有featureA这个功能,如果有这个功能,就在页面上展示featureA对应的内容。
在上面的例子中,可假定一个网页上将要请求的权限是相同的,那么可以以待加载网页的URL为维度,来分类请求的资源。在第一次用户访问页面时,如图2所示,中间件客户端可从网页服务器获取并记录与待加载网页相关的特征信息URL,同时中间件客户端可接收向中间件发送的中间件数据请求(如boolean isAllowed=service.isAllowed(personID,featureA)),并根据该中间件数据请求从目标中间件获取对应的中间件数据并反馈至网页服务器,网页服务器根据这些中间件数据对待加载网页进行渲染并反馈给用户,其中,中间件客户端根据接收到的中间件数据请求生成待请求数据名称集合并记录下来,以及建立特征信息URL与待请求数据名称集合之间的对应关系,同时中间件客户端要求网页服务器将变量personID传入到中间件客户端中。在上面例子中,特征信息URL与待请求数据名称集合之间的对应关系,如下:
URL:/admin/monitor.jsp-[featureA,featureB,featureC,featureD]
变量:personID。
当第二次和以后所有的网页请求到来时,如图3所示,中间件客户端可根据网页服务器传入的URL来查找对应的待请求数据名称集合,在上面例子中,待请求数据名称集合为[featureA,featureB,featureC,featureD],同时再根据网页服务器传入的变量(personID)来做数据预热。数据预热将调用批量接口,向中间件请求上述待请求数据名称集合对应的所有资源,并缓存起来。接下去网页服务器对中间件的调用将会从缓存中获取数据。当完成业务(即缓存中待请求数据名称对应的中间件数据全部反馈给网页服务器)后,清空缓存,其中,缓存生命周期为一次用户的网页请求,并且缓存的结果只对本次网页请求可见。
应当理解,相关技术中,当一个网页多次请求同一个中间件时,通常是通过中间件提供一个批量接口,请求方通过该批量接口进行请求合并。虽然批量接口能够解决多次调用的问题,但是,当将请求合并与请求方的业务代码耦合在一起时,会带来以下问题:(1)当需要增加一个新调用,或者删除一个不用的调用时,请求方必须改动请求合并的代码;(2)调用方需要在所有有合并需求的地方写上合并调用的逻辑;(3)在分层式的架构中,不同层的调用合并也会给调用结果的传递带来困难。
通过本申请实施例的从中间件请求数据的方法,通过中间件客户端的自学习来完成请求合并,不但解决了上述相关技术中请求合并所带来的问题,同时请求方不需要了解整个请求合并的过程,简化了请求方的操作。
为了实现上述实施例,本申请还提出了一种从中间件请求数据的***。
图4是根据本申请一个实施例的从中间件请求数据的***的结构示意图。如图4所示,该从中间件请求数据的***可以包括:用户客户端10、网页服务器20、中间件客户端30和至少一个中间件40。
具体地,用户客户端10可用于向网页服务器20发送网页加载请求并接收网页服务器20反馈的网页数据。
网页服务器20可用于根据网页加载请求构建待加载网页,并向中间件客户端30发送中间件数据请求以从至少一个中间件40获取中间件数据,以及将获取的中间件数据反馈至用户客户端10。
中间件客户端30可用于获取与待加载网页相关的特征信息,并根据特征信息确定待加载网页所对应的待请求数据名称集合,以及根据中间件数据请求确定目标中间件,并根据目标中间件和待请求数据名称集合确定需要从目标中间件所获取的待请求数据名称,以及根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存,并再次接收到向目标中间件发送的中间件数据请求时,从缓存的中间件数据集合中提取并反馈对应的中间件数据,其中,待请求数据名称集合包括至少一个中间件对应的待请求数据名称。
其中,在本申请的实施例中,中间件客户端30还可用于在待加载网页被第一次加载时记录向至少一个中间件40发送的中间件数据请求及与待加载网页相关的特征信息,并根据记录的中间件数据请求生成待请求数据名称集合,并建立特征信息与待请求数据名称集合之间的关联关系。
此外,特征信息可为待加载页面的地址信息、请求待加载页面的用户的会员类型信息、待加载页面的名称(如list页面、detail页面等)、请求待加载页面的客户端信息(如所用浏览器信息、操作***信息等)、请求待加载页面的Cookie信息或者是网页服务器调用中间件客户端时的调用接口或参数等。
更具体地,当用户客户端10向网页服务器20发送网页加载请求时,网页服务器20可根据网页加载请求构建待加载网页,中间件客户端30可获取与该待加载网页相关的特征信息,如该待加载网页的地址信息(如URL)或者上述用户客户端10所属用户的会员类型信息等,之后可根据上述特征信息确定上述待加载网页所对应的待请求数据名称集合,可以理解,上述待加载网页所对应的待请求数据名称集合是在该待加载网页被第一次加载的过程中生成的。同时,网页服务器20可向中间件客户端30发送中间件数据请求以从至少一个中间件40获取中间件数据,中间件客户端30在接收到中间件数据请求之后,可根据该中间件数据请求找到与该中间件数据请求对应的中间件作为目标中间件,并可根据目标中
间件和待请求数据名称集合即可确定需要从目标中间件中所要获取的待请求数据名称,以及根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存,并再次接收到向目标中间件发送的中间件数据请求时,从缓存的中间件数据集合中提取并反馈对应的中间件数据。
进一步的,在本申请的一个实施例中,中间件客户端30还可用于在将待加载网页所对应的待请求数据名称集合中全部待请求数据名称对应的中间件数据均反馈完毕之后,清空缓存。可以理解,在本申请的实施例中,缓存的生命周期为一次网页加载请求,并且缓存的结果只对本次网页加载请求可见。由此,在本次网页加载请求结束后将缓存清空,一方面可以释放服务器资源,另一方面,不同网页加载请求之间不会造成缓存中中间件数据的紊乱。
可选的,在本申请的一个实施例中,待加载页面可以需要调用多个中间件,待请求数据名称集合可包括多个中间件分别对应的待请求数据名称。也就是说,本申请实施例的从中间件请求数据的***也适用于从多个中间件请求数据,当待加载页面需要调用多个中间件时,上述待请求数据名称集合则可包括该多个中间件分别对应的待请求数据名称。当中间件客户端接收到哪个中间件对应的中间件数据请求时,则根据该中间件对应的中间件数据请求进行上述的相应处理,以获取该待加载页面中所需要调用的所有中间件对应的中间件数据。
本申请实施例的从中间件请求数据的***,在一次网页加载请求过后,中间件客户端将多个中间件数据请求所请求的资源记录下来,当下一次网页加载请求到来时,在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时,按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求,做自动的合并,即通过提供一个批量接口,并通过批量接口向目标中间件请求合并后的资源,同时将请求结果缓存在中间件客户端,如果在本次网页加载请求的过程中,中间件客户端再次接收到向目标中间件发送的中间件数据请求时,则从缓存的请求结果中提取并反馈对应的中间件数据即可,不但解决了上述相关技术中请求合并所带来的问题,同时请求方不需要了解整个请求合并的过程,简化了请求方的操作。
为了实现上述实施例,本申请还提出了一种中间件客户端。
图5是根据本申请一个实施例的中间件客户端的结构示意图。如图5所示,该中间件客户端可以包括:待请求数据名称集合确定模块31、目标中间件确定模块32、待请求数据名称确定模块33和中间件数据提供模块34。
具体地,待请求数据名称集合确定模块31可用于获取与待加载网页相关的特征信息,
并根据特征信息确定待加载网页所对应的待请求数据名称集合,其中,待请求数据名称集合包括至少一个中间件对应的待请求数据名称。此外,在本申请的实施例中,特征信息可为待加载页面的地址信息、请求待加载页面的用户的会员类型信息、待加载页面的名称(如list页面、detail页面等)、请求待加载页面的客户端信息(如所用浏览器信息、操作***信息等)、请求待加载页面的Cookie信息或者是网页服务器调用中间件客户端时的调用接口或参数等。
进一步的,在本申请的实施例中,待请求数据名称集合确定模块31还可用于当待加载网页被第一次加载时,记录向至少一个中间件发送的中间件数据请求及与待加载网页相关的特征信息,并根据记录的中间件数据请求生成待请求数据名称集合,并建立特征信息与待请求数据名称集合之间的关联关系。
更具体地,在用户客户端向网页服务器发送网页加载请求时,网页服务器可根据网页加载请求构建待加载网页,待请求数据名称集合确定模块31可获取与该待加载网页相关的特征信息,如该待加载网页的地址信息或者上述用户客户端所属用户的会员类型信息等,之后可根据上述特征信息确定上述待加载网页所对应的待请求数据名称集合,可以理解,上述待加载网页所对应的待请求数据名称集合是在该待加载网页被第一次加载的过程中生成的。
目标中间件确定模块32可用于接收中间件数据请求,并根据中间件数据请求确定目标中间件。更具体地,在网页服务器根据用户发送的网页加载请求构建待加载网页之后,目标中间件确定模块32可接收网页服务器发送的中间件数据请求,并根据该中间件数据请求找到与该中间件数据请求对应的中间件作为目标中间件。
待请求数据名称确定模块33可用于根据目标中间件和待请求数据名称集合确定需要从目标中间件所获取的待请求数据名称。应当理解,由于上述待请求数据名称集合包括中间件对应的待请求数据名称,所以,在接收到中间件数据请求之后,待请求数据名称确定模块33根据目标中间件和待请求数据名称集合即可确定需要从目标中间件中所要获取的待请求数据名称。
中间件数据提供模块34可用于根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存,其中,如果再次接收到向目标中间件发送的中间件数据请求则从缓存的中间件数据集合中提取并反馈对应的中间件数据。
综上所述,本申请实施例的中间件客户端是通过自学习来完成请求合并,自动请求合并的基本思路为:在一次网页加载请求过后,中间件客户端将多个中间件数据请求所请求的资源记录下来,当下一次网页加载请求到来时,在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时,按上一次网页加载请求的过程中记录下来的多次对资源的
中间件数据请求,做自动的合并,即通过提供一个批量接口,并通过批量接口向目标中间件请求合并后的资源,同时将请求结果缓存在中间件客户端,如果在本次网页加载请求的过程中,中间件客户端再次接收到向目标中间件发送的中间件数据请求时,则从缓存的请求结果中提取并反馈对应的中间件数据即可。
进一步的,在本申请的一个实施例中,如图6所示,所述中间件客户端还可包括缓存管理模块35,缓存管理模块35可用于在将待加载网页所对应的待请求数据名称集合中全部待请求数据名称对应的中间件数据均反馈完毕之后,清空缓存。可以理解,在本申请的实施例中,缓存的生命周期为一次网页加载请求,并且缓存的结果只对本次网页加载请求可见。由此,在本次网页加载请求结束后将缓存清空,一方面可以释放服务器资源,另一方面,不同网页加载请求之间不会造成缓存中中间件数据的紊乱。
可选的,在本申请的一个实施例中,在待加载页面需要调用多个中间件时,待请求数据名称集合可包括多个中间件分别对应的待请求数据名称。也就是说,本申请实施例的中间件客户端也适用于从多个中间件请求数据,当待加载页面需要调用多个中间件时,上述待请求数据名称集合则可包括该多个中间件分别对应的待请求数据名称。当中间件客户端接收到哪个中间件对应的中间件数据请求时,则根据该中间件对应的中间件数据请求进行上述的相应处理,以获取该待加载页面中所需要调用的所有中间件对应的中间件数据。
本申请实施例的中间件客户端,在一次网页加载请求过后,可将多个中间件数据请求所请求的资源记录下来,当下一次网页加载请求到来时,在第一次接收到向目标中间件发送的中间件数据请求时,按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求,做自动的合并,即通过提供一个批量接口,并通过批量接口向目标中间件请求合并后的资源,同时将请求结果缓存在中间件客户端,如果在本次网页加载请求的过程中,中间件客户端再次接收到向目标中间件发送的中间件数据请求时,则从缓存的请求结果中提取并反馈对应的中间件数据即可,不但解决了上述相关技术中请求合并所带来的问题,同时请求方不需要了解整个请求合并的过程,简化了请求方的操作。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中,“多个”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分,并且本申请的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能,这应被本申请的实施例所属技术领域的技术人员所理解。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤,例如,可以被认为是用于实现逻辑功能的可执行指令的定序列表,可以具体实现在任何计算机可读介质中,以供指令执行***、装置或设备(如基于计算机的***、包括处理器的***或其他可以从指令执行***、装置或设备取指令并执行指令的***)使用,或结合这些指令执行***、装置或设备而使用。就本说明书而言,"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行***、装置或设备或结合这些指令执行***、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下:具有一个或多个布线的电连接部(电子装置),便携式计算机盘盒(磁装置),随机存取存储器(RAM),只读存储器(ROM),可擦除可编辑只读存储器(EPROM或闪速存储器),光纤装置,以及便携式光盘只读存储器(CDROM)。另外,计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质,因为可以例如通过对纸或其他介质进行光学扫描,接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序,然后将其存储在计算机存储器中。
应当理解,本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行***执行的软件或固件来实现。例如,如果用硬件来实现,和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列(PGA),现场可编程门阵列(FPGA)等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,该程序在执行时,包括方法实施例的步骤之一或其组合。
此外,在本申请各个实施例中的各功能单元可以集成在一个处理模块中,也可以是各
个单元单独物理存在,也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。
上述提到的存储介质可以是只读存储器,磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本申请的限制,本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。
Claims (15)
- 一种从中间件请求数据的方法,其特征在于,包括以下步骤:获取与待加载网页相关的特征信息,并根据所述特征信息确定所述待加载网页所对应的待请求数据名称集合,其中,所述待请求数据名称集合包括至少一个中间件对应的待请求数据名称;接收中间件数据请求,并根据所述中间件数据请求确定目标中间件;根据所述目标中间件和所述待请求数据名称集合确定需要从所述目标中间件所获取的待请求数据名称;以及根据所述需要从所述目标中间件所获取的待请求数据名称从所述目标中间件获取对应的中间件数据集合并缓存,其中,如果再次接收到向所述目标中间件发送的中间件数据请求则从所述缓存的所述中间件数据集合中提取并反馈对应的中间件数据。
- 如权利要求1所述的从中间件请求数据的方法,其特征在于,所述待加载网页所对应的待请求数据名称集合通过以下步骤生成:当所述待加载网页被第一次加载时,记录向至少一个中间件发送的中间件数据请求及与所述待加载网页相关的特征信息;以及根据所述记录的中间件数据请求生成所述待请求数据名称集合,并建立所述特征信息与所述待请求数据名称集合之间的关联关系。
- 如权利要求1或2所述的从中间件请求数据的方法,其特征在于,所述特征信息为所述待加载页面的地址信息、请求所述待加载页面的用户的会员类型信息、所述待加载页面的名称、请求所述待加载页面的客户端信息、请求所述待加载页面的Cookie信息或者是网页服务器调用中间件客户端时的调用接口或参数。
- 如权利要求1所述的从中间件请求数据的方法,其特征在于,还包括:在将所述待加载网页所对应的待请求数据名称集合中全部待请求数据名称对应的中间件数据均反馈完毕之后,清空缓存。
- 如权利要求1所述的从中间件请求数据的方法,其特征在于,所述待加载页面需要调用多个中间件,所述待请求数据名称集合包括所述多个中间件分别对应的待请求数据名称。
- 一种从中间件请求数据的***,其特征在于,包括用户客户端、网页服务器、中间件客户端和至少一个中间件,其中,所述用户客户端,用于向所述网页服务器发送网页加载请求并接收所述网页服务器反馈的网页数据;所述网页服务器,用于根据所述网页加载请求构建待加载网页,并向所述中间件客户端发送中间件数据请求以从所述至少一个中间件获取中间件数据,以及将获取的中间件数据反馈至所述用户客户端;所述中间件客户端,用于获取与所述待加载网页相关的特征信息,并根据所述特征信息确定所述待加载网页所对应的待请求数据名称集合,以及根据中间件数据请求确定目标中间件,并根据所述目标中间件和所述待请求数据名称集合确定需要从所述目标中间件所获取的待请求数据名称,以及根据所述需要从所述目标中间件所获取的待请求数据名称从所述目标中间件获取对应的中间件数据集合并缓存,并再次接收到向所述目标中间件发送的中间件数据请求时,从所述缓存的所述中间件数据集合中提取并反馈对应的中间件数据,其中,所述待请求数据名称集合包括至少一个中间件对应的待请求数据名称。
- 如权利要求6所述的从中间件请求数据的***,其特征在于,所述中间件客户端,还用于在所述待加载网页被第一次加载时记录向至少一个中间件发送的中间件数据请求及与所述待加载网页相关的特征信息,并根据所述记录的中间件数据请求生成所述待请求数据名称集合,并建立所述特征信息与所述待请求数据名称集合之间的关联关系。
- 如权利要求6或7所述的从中间件请求数据的***,其特征在于,所述特征信息为所述待加载页面的地址信息、请求所述待加载页面的用户的会员类型信息、所述待加载页面的名称、请求所述待加载页面的客户端信息、请求所述待加载页面的Cookie信息或者是所述网页服务器调用所述中间件客户端时的调用接口或参数。
- 如权利要求6所述的从中间件请求数据的***,其特征在于,所述中间件客户端,还用于在将所述待加载网页所对应的待请求数据名称集合中全部待请求数据名称对应的中间件数据均反馈完毕之后,清空缓存。
- 如权利要求6所述的从中间件请求数据的***,其特征在于,所述待加载页面需要调用多个中间件,所述待请求数据名称集合包括所述多个中间件分别对应的待请求数据名称。
- 一种中间件客户端,其特征在于,包括:待请求数据名称集合确定模块,用于获取与待加载网页相关的特征信息,并根据所述特征信息确定所述待加载网页所对应的待请求数据名称集合,其中,所述待请求数据名称集合包括至少一个中间件对应的待请求数据名称;目标中间件确定模块,用于接收中间件数据请求,并根据所述中间件数据请求确定目标中间件;待请求数据名称确定模块,用于根据所述目标中间件和所述待请求数据名称集合确定需要从所述目标中间件所获取的待请求数据名称;以及中间件数据提供模块,用于根据所述需要从所述目标中间件所获取的待请求数据名称从所述目标中间件获取对应的中间件数据集合并缓存,其中,如果再次接收到向所述目标中间件发送的中间件数据请求则从所述缓存的所述中间件数据集合中提取并反馈对应的中间件数据。
- 如权利要求11所述的中间件客户端,其特征在于,所述待请求数据名称集合确定模块,还用于当所述待加载网页被第一次加载时,记录向至少一个中间件发送的中间件数据请求及与所述待加载网页相关的特征信息,并根据所述记录的中间件数据请求生成所述待请求数据名称集合,并建立所述特征信息与所述待请求数据名称集合之间的关联关系。
- 如权利要求11或12所述的中间件客户端,其特征在于,所述特征信息为所述待加载页面的地址信息、请求所述待加载页面的用户的会员类型信息、所述待加载页面的名称、请求所述待加载页面的客户端信息、请求所述待加载页面的Cookie信息或者是网页服务器调用中间件客户端时的调用接口或参数。
- 如权利要求11所述的中间件客户端,其特征在于,还包括:缓存管理模块,用于在将所述待加载网页所对应的待请求数据名称集合中全部待请求数据名称对应的中间件数据均反馈完毕之后,清空缓存。
- 如权利要求11所述的中间件客户端,其特征在于,所述待加载页面需要调用多个中间件,所述待请求数据名称集合包括所述多个中间件分别对应的待请求数据名称。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510069814.5 | 2015-02-10 | ||
CN201510069814.5A CN105989070B (zh) | 2015-02-10 | 2015-02-10 | 从中间件请求数据的方法、***及中间件客户端 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2016127856A1 true WO2016127856A1 (zh) | 2016-08-18 |
Family
ID=56615012
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2016/073146 WO2016127856A1 (zh) | 2015-02-10 | 2016-02-02 | 从中间件请求数据的方法、***及中间件客户端 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN105989070B (zh) |
WO (1) | WO2016127856A1 (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112612983A (zh) * | 2021-01-07 | 2021-04-06 | 上海哔哩哔哩科技有限公司 | 一种页面访问方法及*** |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107196917B (zh) * | 2017-04-27 | 2020-02-14 | 威富通科技有限公司 | 一种服务响应方法及其中间件 |
CN110020349B (zh) * | 2017-09-26 | 2021-09-03 | 北京京东尚科信息技术有限公司 | 页面渲染的方法及装置 |
CN107818022B (zh) * | 2017-10-25 | 2021-08-24 | 努比亚技术有限公司 | 应用程序接口合并方法、移动终端及计算机可读存储介质 |
CN107729516A (zh) * | 2017-10-26 | 2018-02-23 | 北京百度网讯科技有限公司 | 单页应用展示方法和装置、服务器、设备及可读介质 |
CN108459914B (zh) * | 2017-12-26 | 2021-01-01 | 深圳神州数码云科数据技术有限公司 | 一种中间件命令执行方法及装置 |
CN113742010A (zh) * | 2020-05-29 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 页面多语言展示的方法和装置 |
CN113377784B (zh) * | 2021-08-13 | 2021-12-03 | 成都市维思凡科技有限公司 | 一种基于中间件的数据处理方法、***和存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101583072A (zh) * | 2008-05-15 | 2009-11-18 | 北京凯思昊鹏软件工程技术有限公司 | 一种用于实现Mobile Internet的中间件产品及其方法 |
CN101632071A (zh) * | 2007-02-20 | 2010-01-20 | 雅虎公司 | 基于用户情境预加载内容的***和方法 |
CN103685476A (zh) * | 2013-11-26 | 2014-03-26 | 优视科技有限公司 | 利用网页模板实现网页展现的方法和网页模板服务器 |
CN103888456A (zh) * | 2014-03-18 | 2014-06-25 | 国家电网公司 | 一种网页客户端、服务端以及数据处理装置和方法 |
CN103905498A (zh) * | 2012-12-27 | 2014-07-02 | 鼎捷软件股份有限公司 | 服务信息管理方法及服务信息管理*** |
US8886764B2 (en) * | 2009-09-30 | 2014-11-11 | Systemite Ab | Quick upload |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7752326B2 (en) * | 2001-08-20 | 2010-07-06 | Masterobjects, Inc. | System and method for utilizing asynchronous client server communication objects |
CN101661494B (zh) * | 2009-09-29 | 2012-06-20 | 莱芜钢铁集团有限公司 | 一种分布式中间件与数据库数据交互方法 |
US11222001B2 (en) * | 2013-03-15 | 2022-01-11 | Sap Se | Augmenting middleware communication services |
CN103729440B (zh) * | 2013-12-30 | 2017-09-15 | 优视科技有限公司 | 一种访问网站的方法及装置 |
-
2015
- 2015-02-10 CN CN201510069814.5A patent/CN105989070B/zh active Active
-
2016
- 2016-02-02 WO PCT/CN2016/073146 patent/WO2016127856A1/zh active Application Filing
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101632071A (zh) * | 2007-02-20 | 2010-01-20 | 雅虎公司 | 基于用户情境预加载内容的***和方法 |
CN101583072A (zh) * | 2008-05-15 | 2009-11-18 | 北京凯思昊鹏软件工程技术有限公司 | 一种用于实现Mobile Internet的中间件产品及其方法 |
US8886764B2 (en) * | 2009-09-30 | 2014-11-11 | Systemite Ab | Quick upload |
CN103905498A (zh) * | 2012-12-27 | 2014-07-02 | 鼎捷软件股份有限公司 | 服务信息管理方法及服务信息管理*** |
CN103685476A (zh) * | 2013-11-26 | 2014-03-26 | 优视科技有限公司 | 利用网页模板实现网页展现的方法和网页模板服务器 |
CN103888456A (zh) * | 2014-03-18 | 2014-06-25 | 国家电网公司 | 一种网页客户端、服务端以及数据处理装置和方法 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112612983A (zh) * | 2021-01-07 | 2021-04-06 | 上海哔哩哔哩科技有限公司 | 一种页面访问方法及*** |
Also Published As
Publication number | Publication date |
---|---|
CN105989070B (zh) | 2020-01-17 |
CN105989070A (zh) | 2016-10-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2016127856A1 (zh) | 从中间件请求数据的方法、***及中间件客户端 | |
US9323860B2 (en) | Enhancing client-side object caching for web based applications | |
WO2016146023A1 (zh) | 分布式计算***和方法 | |
JP5980430B2 (ja) | コンピュータ・システムのためのデータ・キャッシュを管理するための方法、装置、コンピュータ・プログラム製品、およびコンピュータ・プログラム(コンピュータ・システムのためのデータ・キャッシュの管理) | |
KR20080000656A (ko) | 다른 특징들을 가지는 클라이언트 단말들에 의해 접근될 수있는 서버 캐시의 관리를 최적화하기 위한 방법 | |
KR20130107280A (ko) | 디렉토리 리싱 | |
KR20090125108A (ko) | 사용자 정황 기반으로 콘텐츠를 프리로딩하기 위한 시스템 및 방법 | |
TW201711432A (zh) | 對伺服器進行健康檢查的方法及設備 | |
US20120259945A1 (en) | System and method for dynamically modifying content based on user expectations | |
JP2016520900A (ja) | オンライン共有のためのクラウドサービスの統合 | |
CN110851680A (zh) | 网络爬虫识别方法和装置 | |
US20160182673A1 (en) | Dynamic cache injector | |
WO2003046727A1 (fr) | Systeme de generation d'informations, procede de generation d'informations et programme de generation d'informations | |
US9401003B2 (en) | Just-in-time processing of images | |
CN112069386B (zh) | 一种请求处理方法、装置、***、终端及服务器 | |
CN113438302A (zh) | 动态资源多级缓存方法、***、计算机设备及存储介质 | |
US20180165018A1 (en) | Partial storage of large files in distinct storage systems | |
JP7217181B2 (ja) | ウェアラブルデバイス、情報処理方法、装置及びシステム | |
US10616291B2 (en) | Response caching | |
US10015012B2 (en) | Precalculating hashes to support data distribution | |
CN107103001B (zh) | 基于浏览器获取目标前端资源文件的方法、装置和*** | |
CN110807040B (zh) | 管理数据的方法、装置、设备及存储介质 | |
CN104978339A (zh) | 一种文件处理方法、设备和网络*** | |
JP2011087072A (ja) | 画像提供サーバ装置およびその制御方法およびプログラム | |
CN111698324B (zh) | 一种数据请求方法、装置及*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16748657 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 16748657 Country of ref document: EP Kind code of ref document: A1 |