The present invention relates to client applications of web services, especially to the method and device for tracing and locating web services changes during updating client web application process.
Booming of web services makes more people depend on web-service based software to do their business. For instance, there are a lot of service suppliers providing web services (also called as online API) for users, such as Map service from Google*, picture service from Flickr*, video service from YouTube*. ProgrammableWeb* (at programmableweb.com) has listed current popular Web services. Users can build their own applications by using or integrating these Web services expediently. For example, users are able to use eCommerce Web service provided by eBay and Map service from Google to build a convenience application to search for product's price and suppliers' location. *May be a trademark of the respective company
But these online APIs (application interface) change frequently, periodically or non-periodically. These frequently-changed web services raise a big challenge for users, namely, how to easily notify the users of these changes and adapt to these changes in a highly efficient way.
For example, considering the Web service provided by eBay*, in April 2004 there are:
These numbers have increased rapidly in recent years. According to further observation and analysis of the Web service provided by eBay, it has been found that:
So a big problem coming along in such context is how to help developers track the changes of the target Web services easily and modify their code efficiently.
Currently when the service providers publish the new version of Web services, the new services are versioned by the version numbers or the timestamps. At the same time, release notes or online API update guides are also delivered to help the developers to change their client codes. Most release notes are html pages and published to the service consumers in RSS/Atom feeds or emails. For instance, eBay Web service version (refer to developer.ebay.com) are organized by their own version numbers and are sent to the developers once the new version is published. Amazon Web service are managed by mangling the timestamps to the namespace to mark the service version, the developers can be notified by email or by subscribing the release note page's RSS feeds.
However, the drawbacks of the currently known methods are listed as follows:
Further descriptions are made as follows. Firstly, as shown in
To solve the above-mentioned problem, the present invention provides a novel method and device for tracing and locating web service changes involving the client's application so that it is more convenient to change the client's application.
To achieve this, the present invention has designed a method and device not only help users record related changes of web services dynamically and efficiently without too much human efforts, but also automatically locate which part of the application shall be changed and the corresponding change history.
The present invention uniquely provides a method and device for tracing and locating web service changes to keep a change history of a target web service at the side of Web service clients. The method and device of the present invention could be implemented as a plug-in or library that may be added into the development platform of Web service client application. Alternately, the method and device of the present invention can be added into the server of web service provider, or be provided to a third party independent of said web service user or provider.
The advantage of the present invention include at least one of the followings: The release notes or the online API update guides can be customized for each consumer locally; the change history of the target web service concerned by the user can be tracked and stored locally; the present invention also can transform all changes into standard primitive descriptions, thereby unifying various service change descriptions from all kinds of web service providers and eliminating the differences between different web providers. Users can easily use the above-mentioned change history to locally update client codes, which is the basis of auto-update of client codes.
In one aspect, the present invention provides a change history recording method for recording web service change history, including a receiving step of receiving release notes of web service change description; a transforming step of finding out change descriptions corresponding to Customer Used Elements from the release notes; a history generating and storing step of generating a change history for said Customer Used Elements on the basis of said change descriptions corresponding to said Customer Used Elements and locally storing it at the client side.
In the other aspect, the present invention provides a change history recording device for recording web service change history, including: a transformation engine used for receiving release notes of web service change description, and finding out change descriptions corresponding to Customer Used Element from the release notes; history generating means, used for receiving change description of said Customer Used Elements from the transformation engine, and generating a change history of said Customer Used Elements.
In a further aspect, the present invention provides an embodiment for a change-update supporter, which updates client application according to release notes, the above mentioned change-update supporter includes: the change history recording device as described above; a release note receiving means used for receiving new release notes and inputting them into the change history recording device, said release note including change descriptions of web services; a code searching means used for searching Customer Used Elements from the client application and input them into the change history recording device, and wherein the change history recording device outputs a change history of said Customer Used Elements.
Hereinafter an exemplary method and device will be described with references to the following descriptions and figures. Considering the following detailed description and figures, other advantages and novel characteristic are obvious. The inventive concept itself as well as a preferred embodiment will be best understood by referring to the following detailed description of embodiments and drawings, wherein:
a and 1b show samples of release notes published in the prior art.
With reference to
According to one preferred embodiment of the present invention, the above-mentioned transformation rules involves how to transform various kinds of release notes into standard change description primitives. For example, one preferred group of standard change description primitives of the present invention is: “ADD”, “REMOVE” and “UPDATE”, it will be more detailed in the following text.
With reference to
As those skilled in the art can understand, given the change history recording device 304 proposed by the present invention, change update supporter 305 can provide great assistance to clients, such as prompting users the updating of client applications according to the change history recorded by the change history recording device 304, even updating codes automatically according to the change history. The following text will make further introduction about these expanded functions provided by the change history recording device of the invention.
With reference to
The change history recording device 304 includes two parts, transformation engine 402 and history generator 403.
In one aspect, transformation engine 402 receives a new release note from the web service provider, and transforms it into a predetermined format. As those skilled in the art can understand, it is possible to use the prior art to receive release notes, such as email, RSS feeder, Atom receiver, FTP and etc.
On the other aspect, transformation engine 402 receives “Consumer Used Elements” 401, wherein “Consumer Used Elements” 401 usually include the used services, operations, messages, elements, types, attributes, etc. when user develops applications. customer Used Element 401 can be manually input by developers. Alternatively, it can be obtained through prior art means, such as code searching and text matching. For instance, at present, each web service provider provides WSDL files (e.g., WSDL files of Amazon Web can be downloaded from the website webservices.amazon.com at AWSECommerceService.wsdl?), which gives the detailed descriptions of the original web service. Since WSDL is an Extensible Markup Language, all the element names of this web service can be obtained by using various existing XML parsers or WSDL parsers to parse the WSDL files of the original web service. There are a lot of available WSDL parsers, such as WSDL4J[3], C++WSDL Parser[4] and etc. Then, after developers develop the client applications, a simple code reader could be used to compare the used elements in the client application with all web service element names obtained from WSDL files and to find out the names of customer used elements.
After receiving customer used element 401 and the new release note 404, transformation engine 402 will search the new release note 404 to find out change descriptions in relation to customer used elements 401, e.g., “Element A changes to element A1” as shown in
The history generator receives the change description in relation to the customer used elements from transformation engine 402, and records this change description as change history 305 according to a predetermined history format, and stores the change history 305 locally or remotely.
As those skilled in the art can understand, the change history can be used to help developers modify their application codes. This can be achieved through the static or dynamic auto-update of programs, or through notifying users to modify the code manually.
With reference to
Transformation engine 402 in the change history recording device 304 includes 3 components to support the transformation: release note parser 503, release note translator 504, and customized release generator 505.
The operation of release note parser 503 is to parse the release note 501 and obtain the descriptions of web service changes. At present, different web service providers provide different formats of release notes, for example, Google, eBay, Amazon and other web service providers provide release notes in their own formats. XML parsing technique (such as DOM, SAX that can be used to read RSS files or Atom files), for example, could be used to parse it, and transform it into desired formats.
In addition, since different web service providers usually provide release notes in different change description primitives, it is necessary to map them into one unified change description primitive.
One preferred embodiment of the present invention adopts 3 change description primitives 506: ADD, REMOVE and UPDATE, to uniformly translate the received release notes. ADD primitive indicates a new service element (including service, operation, message and etc.) is added into the target service. REMOVE primitive indicates a service element is removed from the target service. UPDATE primitive indicates a service element in the target service is renamed or its value is changed. All changes can be described by one of the above 3 standard primitives.
Accordingly, predefined transformation rules could be as follows:
After release note translator 504 receives the parsed release note, the parsed release note is translated and transformed according to the above transformation rules, the resulting contents are defined by uniform change description primitives.
As those skilled in the art can understand, the above transformation rules are just an illustration. Transformation rules can be provided by the web service providers or developers of the client application, mapping between change description primitives of release notes and the change description primitive predefined by users.
Change description primitives of various kinds of release notes are translated and transformed uniformly, such as “CHANGE TO” and “CHANGED TO” are both translated into “UPDATE” primitive. After such processing, all changes described in release notes are described using the three standard primitives. One advantage is to unify service change descriptions of various web service providers at the client side, and to eliminate the differences among different web service providers; another advantage is to provide support for subsequent updating of client application, and subsequent applications can recognize changes in terms of description primitives so as to help user update the application.
Then, Customized Release Note Generator 505 will choose those change descriptions concerned by the client application developer according to a list of customer used elements.
As mentioned above, the list of customer used elements 502 describes which service elements are already used by the client application, it can be manually input by developers or automatically obtained through prior art means, such as code searching and text marching. On the basis of the list of customer used elements 502, Customized Release Note Generator 505 finds out the changes in relation to customer used elements, generates a customized change description, and sends it to history generator 403.
As shown in
History Repository 509 stores change history files for every service used by the client application. For example, the client application uses two services, one is Amazon E-commerce web service, and the other is Google Map web service. Then, the client can use two change history files to maintain change histories for the two services. History Repository 509 can store these two files. Said change history could be a database, a file system or even a document file. For instance, if the change repository is implemented as a database, the change history file will be parsed, and contents of the file will be stored as items in the database. If History Repository 509 is implemented as a file system, the change history will be written into a file and be directly stored in the file system.
Web service client developer can access the History Repository 509 to obtain the change history.
History Creator 507 is used to create a new change history record. For example, History Repository 509 obtains the created change history record, inserts the new change descriptions into the change history record according to a predefined history description format 50, and generates a new change history record. As those skilled in the art can understand, History Description Format 508 can be defined on demand by the client application developer or the client side of the service.
With reference to
It is assumed that the client application only uses service elements A, B and C. The currently used elements are updated to A1, B1 and C1.
After some time, the release note 2 arrives. As shown in
Then, the change history in relation to used elements A, B and C is for example a tree data structure as shown in
Here, if the developer wants to update his client codes, it is quite easy to find out which part of the source code needs to be changed and which part of the release note needs to be referred, with reference to
With the reference to
The function performed by the client application 8030 is: based on the user input, call itemSearch( ) of Amazon e-commerce web service 8040 to search products and print out all product attributes.
Amazon publishes its own release note though RSS. As those skilled in the art can understand, RSS Receiver and Reader 8021 can receive these release notes. In this embodiment, code searching method is used to find out all Amazon e-commerce Web service elements used by the client. In this embodiment, the used web service 8040 is “itemSearch( )” method. According to the wsdl file released by Amazon, the input and output messages of “itemSearch( )” are defined as “ItemSearchRequest”, “ItemSearchResponse”; data elements of the messages are “ItemAttributes”, etc. The details of said method “Itemsearch”, message “Itemsearchrequest”, “Itemsearchresponse” and data element “ItemAttributes” are defined in a wsdl file (with reference to webservices.amazon.com at AWSECommerceService.wsdl?)
As those skilled in the art can understand, the logical level of the above “method”, “message” and “data element” are simplified from high to low as follows:
In this embodiment, by means of code searcher 8022, service elements being used by current user application can be detected, such as “Itemsearch” method; “Itemsearchrequest” and “Itemsearchresponse” messages; “ItemAttributes” data element and etc. However, in this field, method (such as “Itemsearch”) and message (such as “Itemsearchrequest” and “Itemsearchresponse”) are usually not selected as customer used elements. This is because release notes rarely include changes of “method” and “message”. The most frequent changes of release notes occur under the message level, such as changes in data element level of “ItemAttributes” or even lower level “attribute”. Therefore, “ItemAttributes” is selected as a customer used element in this example.
It shall be noted that, since “ItemAttributes” is chosen as a customer used element, certain changes (such as changes of adding a new “method” or new “message”) cannot be detected in the present embodiment. However, since the existed client application cannot use a new method, the change of adding a new method is not concerned by users of the client application. In addition, regarding a “method” provided by web service, input and/or output messages are usually fixed, the actual release note will not add any new message. In addition, there will substantially be no changes of updating “method” or “message” in release notes, because specific changes actually occur at and belong to a level lower than “message”.
In this example, after related change history is generated base on the client used element “ItemAttributes”, code updating is mainly manually performed. The function of Code Updater 8024 is to reflect related changes in the editing window of eclipse.
The release note of Amazon E-Commerce Service 8040 refers to the page connect/kbcategory.jspa at amazonwebservices.com.
As shown in
As shown in
Regarding the Amazon E-commerce Web service release notes, the predefined transformation rules are defined as follows:
At the meantime, code searching is performed on the client application. As mentioned above, in this embodiment, which service element is used in the client application is found out through said service element searching part (i.e., Code Searcher). The results could include: “Itemsearch” method; “Itemsearchrequest” and “Itemsearchresponse” messages; “ItemAttributes” data element and etc. In this embodiment, “ItemAttributes” is selected as a customer used element. Please note this is only for illustration, rather than restriction.
After confirming the customer used elements is “ItemAttributes”, “ItemAttributes” is used as a keyword to search the release notes. For each release note and each customer used element, it performs a thoroughly searching using the keyword to find corresponding descriptions, and then records any code portion containing this keyword or even a table line containing this keyword, and stores it in a change history of this keyword.
For example, the customer used element is “ItemAttributes”, when a release note arrives (such as the release notes of 2006-9-11, 2006-11-8 and 2006-11-14), a thorough search is done using “ItemAttributes” as keyword, and records any description portion or table lines containing said keyword “ItemAttributes”, and stores them in the change history of this keyword, so as to obtain the customized change history record of the customer used element “ItemAttributes”.
The final resulted change history record can be stored in the change history recording device 8023 as a HTML file, for example. According to a preferred embodiment, the contents of said file are as follow:
Change History of Amazon E-commerce Web Service
Element ItemAttributes
Note: the two attributes “symbol” and “ListPrice” don't change their names, so the description is Update attribute symbol to symbol and Update attribute ListPrice to ListPrice
As shown in
For example, if the user didn't update his own client application between 2006-9-10 and 2006-11-15, when he opens his Eclipse editing window after November 15th, the part which need to be adjusted in the application will be shown highlighted. As shown in
In the above sample, change history is listed according to time sequence. The release note on 2006-11-08 didn't involve any change of “ItemAttributes”, so there is no change about the release note on 2006-11-08. In addition, change history can be classified based on change description primitives, such as “ADD”, “UPDATE”, wherein there is no change of “REMOVE” in the above 3 release notes.
It shall be noted that the above-mentioned change history format is just illustrative. As those skilled in the art can understand, the change history recording device in a preferred embodiment can generate a change history record in a tree structure, namely a change history record tree. In this tree, each root node is a web service element, such as method, message and message parameter. Nodes of each level under this root node record changes in relation to this root node element in release notes. The root node is added into the change history record tree when the service element changes the first time, namely when it firstly appears on the current release note. As shown in
In the above example, the method and device of the present invention is implemented as a plug-in, which is added into the development platform of the web service client application.
Alternatively, the method and device of the present invention can be implemented in server 2000 at the web service provider side, as shown in
The additional advantages of the embodiment of
The calling frequency could be for instance, the number of times that a client calls this service element between two release notes being released from web service provider. At the server side, the server can monitor the calling frequency of clients. On the other hand, this could be implemented at the client side, as provided by the client application running environment, such as IBM WebSphere Application Server (WAS) could be adapted to monitor the number of times that a client calls web service for certain period.
As those skilled in the art can understand, alternately, the method and device of the present invention can be implemented in a third party independent of said web service user and provider.
Unless indicated otherwise, the function of the present invention can be run by hardware or software or the combination thereof. However, in a preferred embodiment, unless indicated otherwise, these functions are executed by integrate circuits of one or more processors (such as computer or electronic data processor), based on codes (such as computer program codes). Generally, a method for implementing the embodiment of the present invention could be a part of operating system, a specific application, a program, a module, an object or command sequences. Software of the present invention usually includes computer readable commands, i.e. machine executable commands. In addition, computer programs include parameters and data structures locally or remotely resided in memory. In addition, various kinds of programs can be recognized according to the method that implements the specific embodiment of the present invention. When carrying computer readable commands directed to the present invention, such signal-carrying medium represents an embodiment of the present invention.
Although the description of the present invention refers to the specific embodiments, it should be understood that the present invention is not limited to any embodiment. The appended claims, when interpreted to the widest extent, include all the necessary modifications, equivalents and functions.
Number | Date | Country | Kind |
---|---|---|---|
200710168209.9 | Oct 2007 | CN | national |