Patent Application
20070300240
In the following detailed description presently preferred embodiments of the invention are further described with reference to the following figures:
The following is a glossary of terms used in the present application:
Memory Medium—Any of various types of memory devices or storage devices. The term “memory medium” is intended to include an installation medium, e.g., a CD-ROM, floppy disks 104, or tape device; a computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; or a non-volatile memory such as a magnetic media, e.g., a hard drive, or optical storage. The memory medium may comprise other types of memory as well, or combinations thereof. In addition, the memory medium may be located in a first computer in which the programs are executed, and/or may be located in a second different computer which connects to the first computer over a network, such as the Internet. In the latter instance, the second computer may provide program instructions to the first computer for execution. The term “memory medium” may include two or more memory mediums which may reside in different locations, e.g., in different computers that are connected over a network.
In the following, embodiments of the system and the method of the present invention are described with respect to managing a simplified arrangement of only a single client 10 accessing a single web service 20. However, it is to be understood that embodiments of the present invention may be used to facilitate the managing of large arrangements having tens or hundreds of web services servicing requests of a plurality of clients.
As can be seen, the system comprises a registry 30. The registry comprises one or more APIs (Application Programming Interfaces) 31 for storing and retrieving WSDL files as well as the runtime information stored in the registry as described below. Further, there is preferably an administration API 32, for administrating the registry 30. The registry 30 may be implemented as program instructions and/or data stored on a memory medium of a computer system and executable by a processor. Thus, for example, the registry 30 may comprise a database of WSDL files with one or more APIs 31 for storing and retrieving the WSDL files. The APIs 31 may be implemented as program instructions, e.g., stored on the memory medium where the registry 30 is stored.
As illustrated by the double headed horizontal arrow in
Runtime information provided by the service filter 40 might in a very simple case be only information about which entity of the SOA calls which web service at what time. In more advanced embodiments the service filter 40 will obtain more information such as user accounts involved, size of a request and its response, processing time, breakdowns, etc. From a more structured point of view the following four different technical areas can be identified, to which the runtime information gathered by the service filter 40 may relate:
First, the runtime information can reveal the statistics for the web services involved in the SOA. Statistical information such as usage count, the provision of interconnection graphs with bandwidth usage and identities, the distribution over time (time of day or longer period) and the response times and data amounts being sent provide an administrator of the SOA with a central view on the usage of the involved web services.
Another aspect is the technical monitoring of the SOA, which involves alerts being sent to the right contacts in case of certain events such as the non-availability of a web service. Monitoring provided by the service filter 40 may further involve virus and security checks, debugging support for the development of new applications and generally an assessment of the quality of service provided by the web services of the SOA. Since all the gathered information is fed back to the registry 30, the registry 30 allows to keep the monitored SOA running from a central point and to assess its success based on historical data.
In addition to gathering information about the SOA, the service filter 40 may in a more advanced embodiment also actively change the processing of a request. Dynamic concepts such as loose coupling can be realized, if the service filter 40 redirects a request initially directed to a certain web service 20 to another web service (not shown in
Finally, the gathering of runtime information can be used to enforce policies or service level agreements, for example concerning a predetermined response time of a web service to a certain request.
In the embodiment of
In the following, an exemplary processing of an incoming request by the service filter 40 of the embodiments of
The processing of an incoming request starts at step 100 with the determination, whether the incoming request is a SOAP request. In the non-limiting embodiment of
Step 102 comprises an optional lookup in the registry 30 to obtain the current description of the web service addressed by the request, in particular to determine at runtime, which information is to be gathered from the request and/or its response and whether the request is (additionally) to be modified. Information, which can be obtained during the lookup step 102 and which is evaluated during the subsequent step 103, may concern, whether the addressed web service is flagged for reporting, i.e. whether it is marked in the description in the registry that runtime data are to be gathered for this specific web service. In an SOA having hundreds of web services only a selection of web services might be relevant for obtaining runtime information or for modifying a request from a client.
If the respective web service is not marked for reporting, i.e. gathering of runtime information, or even unknown to the filter, it is forwarded in step 104 and processed by the addressed web service without any further involvement of the service filter. In this case, an alert could be sent to make the fact known that there is an unknown service
Otherwise, the runtime information is gathered in step 105 from the request, for example information concerning the requesting client, the host, the time stamp and the size, etc. All of the above mentioned alternatives for the runtime information (and for possible modifications of the incoming request) can be obtained by the filter in this step. The obtained runtime information can be stored locally as shown in
After gathering the runtime information from the request in step 105, the request is forwarded to the web service in step 106. The response from the web service is processed by the service filter in step 107 and again either stored locally or immediately forwarded to the registry. If the results of the steps 105 and 107 are stored locally, there is a further step 108, wherein all results are sent to the registry. Subsequently, the response from the web service is returned to the client in step 109. However, the response may also be forwarded to the client before or while the runtime information is sent to the registry. Further, the obtained data may not immediately after each request be sent to the registry but, for example, only periodically after a certain amount of time has passed or after a predetermined number of requests have been processed.
As a result, the registry 30 comprises all information of the registered web services, namely their description and the runtime information. This runtime information is exemplary shown in the screen shot of
If one web service is excessively requested, this situation will be reflected in the pie chart of
| Number | Date | Country | Kind |
|---|---|---|---|
| EP 06011491.5 | Jun 2006 | EP | regional |
