UDDI registry extension for rating UDDI artifacts

A method and system to provide subjective evaluations for artifacts in a Universal Description Discovery and Integration (UDDI) registry (version 3 or later). An extension to a UDDI registry receives a request from a client to add a subjective evaluation to an artifact in the UDDI registry, the request including a key identifying the artifact and an evaluation value to be associated with the artifact. The extension stores an evaluation, including the artifact identifying key and the associated evaluation value. The extension receives a request from a client to find a specific type of artifact in the UDDI registry, the request including an evaluation qualifier. The extension receives from the registry a list of keys identifying artifacts responsive to the request. The extension then provides the client with a list of stored evaluation values associated with the artifact keys in the artifact list.

FIELD OF THE INVENTION

An embodiment relates generally to the field of web services. More particularly, an embodiment relates to a method and a system for providing subjective ratings for artifacts found in UDDI v3 Registries.

BACKGROUND OF THE INVENTION

The Universal Description Discovery and Integration (UDDI) standards project aims at speeding up interoperability and adoption of Web services by enabling enterprises to quickly and dynamically publish, discover and invoke such services. UDDI advances this goal through the creation of standards-based specifications for service description and discovery. The UDDI standard provides for registries to be set up on the internet that allow providers of web services to publish information about these services on a certain registry and allow users of web services to search that registry for web services they want to use. The current version of UDDI is UDDI v3.

UDDI v3 registries store several persistent data structures called entities or artifacts. Artifacts are stored in eXtensible Markup Language (XML) format. UDDI v3 artifacts include the following types: Business Entity, Business Service, Binding Template, tModel, Publisher assertion, and Subscription. A Business Entity describes a business or other organization that provides web services. A Business Service artifact is linked subordinately to a Business Entity and describes a collection of related web services offered by the business described in the Business Entity. A Binding Template is linked subordinately to a Business Service and describes the technical information necessary to use a particular web service. A tModel is a reusable model of a concept that may be referenced by other artifacts, usually Binding Templates. Concepts that a tModel can model include a type of web service or a taxonomy system or a protocol used by web services. A Publisher Assertion is linked subordinately to a Business Entity and describes the relationship that Business Entity has with another Business Entity. A Subscription describes a standing request to keep track of changes to the artifacts described by the Subscription.

There are several types of entities that interact with a UDDI v3 registry. An Operator is a person or organization that maintains an instance of UDDI v3 registry software and typically hosts the server that the UDDI v3 registry software instance runs on. A software instance that interacts with a UDDI v3 registry and is a Client. A person or organization that the client acts on behalf of is a User. A Publisher is a user that establishes or changes artifacts on a UDDI v3 registry. Other users may access the registry to find a web service to use.

The UDDI v3 standard provides a variety of mechanisms to classify a web-service artifact in terms of standard and custom classification criteria that are objective. These classifications can only be established or altered by the owning publisher of the UDDI v3 artifact. However, the UDDI v3 standard does not provide a means for the users of a UDDI v3 registry to publish their own, subjective evaluations about the perceived “quality” of a web-service or other artifact found in the UDDI v3 registry, and to search for a web-service based on such subjective criteria. Nor do the currently known providers of UDDI v3 registers (e.g. registries from Systinet, Microsoft, SAP, Apache, Oracle) provide a means for a user of the UDDI v3 registry to publish a subjective evaluation of an artifact from this registry and later to search for artifacts on the basis of such subjective evaluations.

DETAILED DESCRIPTION

A method and system for rating UDDI v3 Registry artifacts is described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of an embodiment of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention. The embodiments described are compatible with UDDI version 3, but may be compatible with other versions as well.

In some embodiments, hard-wired circuitry may be used in place of or in combination with one or more processors executing machine-accessible instructions to implement the present invention. Thus, the present invention is not limited to any specific combination of hardware circuitry and processors executing machine-accessible instructions.

Some embodiments of the invention are described by referring to flowcharts. Describing methods by reference to a flowchart enables one of ordinary skill in the art to develop such programs including such instructions to carry out the methods on suitably configured computing devices (e.g., one or more processors of a node) executing the instructions from computer-accessible media. The computer-executable instructions may be written in a computer programming language or may be embodied in firmware logic. If written in a programming language conforming to a recognized standard, such instructions can be executed on a variety of hardware platforms and interface to a variety of operating systems. In addition, embodiments of the invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, etc.), as taking an action or causing a result. Such expressions are merely a shorthand way of saying that execution of the software by a computing device causes the device to perform an action or produce a result.

FIG. 1shows an Evaluation Extension apparatus and its Evaluation Addition function. One embodiment of the invention is an Evaluation Extension103. The Evaluation Extension103extends the functionality of a UDDI v3 Registry106in response to requests from a Client Application102regarding the evaluation of artifacts in the UDDI v3 Registry106. In one embodiment, the Evaluation Extension103is operated on the same server as the UDDI v3 registry106. In another embodiment, the Evaluation Extension103is on a separate server. A Client Application102sends a Request140to add an evaluation to an artifact in the UDDI v3 Registry106. The Client102sends with the Request140an Evaluation Value144to be associated with the artifact and a Key142that uniquely identifies the artifact. If the Evaluation Extension103determines the Evaluation Addition Request140is authorized and valid, the Evaluation Extension103stores the Artifact Identifying Key142and the associated Evaluation Value144.

FIG. 2shows the Evaluation Extension apparatus and its Evaluation Providing function. The Client Application102sends a Request160to find a specific type of artifact in the UDDI v3 Registry106, the Request including an Evaluation Qualifier. The Client102includes the Qualifier to limit the finding of artifacts to only those artifacts that have a certain evaluation associated with them. The Evaluation Extension103receives the Find Artifact with Evaluation Qualifier Request160and creates a Redacted Find Artifact Request162by removing the Evaluation Qualifier. The Evaluation Extension103sends the Redacted Find Artifact Request162to the UDDI v3 Registry106. the UDDI v3 Registry returns a List164of identification keys of artifacts that match the remaining criteria and qualifiers of the Redacted Find Artifact Request162. The Evaluation Extension103compiles a List166of stored evaluations associated with the artifact identification keys in the Artifact List164. The Evaluation Extension103sends the Artifact List and the Associated Evaluations166to the Client102.

FIG. 3shows an Evaluation Extension apparatus with components. In one embodiment, an Evaluation Extension104is comprised of several components, including a Message Receiving Module110, an Evaluation Authorization Issue Module112, an Evaluation Addition Module114, an Evaluation Authorization Check Module116, an Evaluation Validity Check Module118, and an Evaluation Storage Module120. The function of each component is described in the following figures and discussions.

FIG. 4shows a Message Receiving Module, a component of the Evaluation Extension. The Message Receiving Module110is a component of the Evaluation Extension104that monitors messages passed between the client application102and the UDDI v3 Registry106. The evaluation extension104receives a message130from the client102to the UDDI v3 Registry106. If the evaluation extension104determines that the message is regarding an evaluation of an artifact in the registry106, then the message130is classified as an evaluation message131and retained in the extension104for further processing. Evaluation messages131are not passed on the registry106unless the extension104later decides to do so. A Message130that the extension104determines is not regarding artifact evaluation is classified as a non-evaluation message132and passed on the registry106without further processing by the extension104.

FIG. 5shows the function of an Evaluation Authorization Issue Module, a component of the Evaluation Extension. In one embodiment, the evaluation extension104has an Evaluation Authorization Issue Module112. The evaluation authorization issue modules112facilitates limiting the addition of evaluations to clients with authorization to do so from the registry106. A client may send a message with a request for authorization134. In some embodiments, the request134includes a user identification key and a user credential, both associated with a user of the client102. In some embodiments, the authorization request is specifically for authorization to add an evaluation. In those embodiments, the message receiving module110intercepts the request134and sends it to the Evaluation Authorization Issue Module112, which redacts details relating to evaluations and sends a general request for authorization134to the registry. In other embodiments, the authorization request134is not specifically to add an evaluation. In those embodiments, the Message Receiving Module110passes the authorization request134directly to the Registry106. If the Registry106approves, it sends an Authorization Token136back to the Client102. The Evaluation Authorization Issue Module112intercepts the Authorization Token136, stores one copy136-1in an Evaluation Authorization Check Module116and forwards another copy136-2to the Client102.

FIG. 6Ashows the function of an Evaluation Addition Module and an Evaluation Authorization Check Module, components of the Evaluation Extension. In one embodiment, the Evaluation Extension104has an Evaluation Addition Module114. A Client102may send a Request140to add an evaluation to an artifact in the Registry106. In some embodiments, this Evaluation Addition Request140includes additional information items, including an Authorization Token136-2, a Key142identifying the artifact, an Evaluation Value144to be assigned to the artifact and a Key148identifying an Evaluation System stored in the Registry106. In other embodiments, the additional information items may be sent in separate messages. The Message Receiving Module110intercepts the Evaluation Addition Request140and sends it to the Evaluation Addition Module114. The Evaluation Addition Module114sends the Authorization Token136-2received from the Client102to the Evaluation Authorization Check Module116. If the Authorization Token136-2from the Client102matches a stored copy of the Token136-1, then the Evaluation Authorization Check Module116determines the Evaluation Addition Request140is authorized.

FIG. 6Bshows an example of an Evaluation Addition Request. A sample of Evaluation Addition Request600is shown in XML format. In this sample, there are two artifacts to be evaluated: a business service and a business entity. A business service element602gives as an attribute the artifact identifying key for the business service. A first evaluation element604gives as attributes the identifying key for the evaluation system, the evaluation value to be assigned and a string corresponding to the evaluation value. A second evaluation element606is included for a second evaluation of the same business service. Similarly, a group of business entity evaluation elements608identify a business entity and specify evaluation systems and evaluation values to be assigned to the business entity. An XML schema for Evaluation Addition Requests is shown in the appendix.

FIG. 7shows the function of an Evaluation Validity Check Module, a component of the Evaluation Extension. In one embodiment, the Evaluation Extension104has an Evaluation Validity Check Module118. The Evaluation Addition Module114sends the Artifact Identifying Key142that it received from the Client102to the Evaluation Validity Check Module118, which forwards the Key142to the Registry106in a request for details on the artifact. If the Registry responds back with a message containing Artifact Details146, then the Evaluation Validity Check Module118determines that the existence in the Registry106of an artifact matching the Key142has been confirmed.

The Evaluation Addition Module114sends the Evaluation Value144and the Evaluation System Identifying Key148that it received from the Client102to the Evaluation Validity Check Module118. In some embodiments, the Registry106has one or more evaluation systems stored as t-models. In these embodiments, the Evaluation Validity Check Module118forwards the Evaluation System Identifying Key148to the Registry106in a request for all valid values in the corresponding evaluation system. If the Registry responds back with a message containing a Valid Values List150, and if the Evaluation Value144sent by the Client102matches one of the values in the Valid Values List150, then the Evaluation Validity Check Module118determines that the Evaluation Value144is valid. In other embodiments, the evaluation systems are not stored in the Registry106but rather in the Evaluation Extension104. In these embodiments, the Evaluation Validity Check Module118checks with the Evaluation Extension for an evaluation system corresponding to the Evaluation System Identifying Key148. If a corresponding evaluation system is found, and if the Evaluation Value144sent by the Client102matches one of the valid values in the corresponding evaluation system, then the Evaluation Validity Check Module118determines that the Evaluation Value144is valid. If the existence in the Registry106of an artifact matching the Artifact Identifying Key142has been confirmed and if the Evaluation Value144has been determined to be valid, then the Evaluation Validity Check Module118determines that the Evaluation Addition Request140is valid.

FIG. 8shows the function of an Evaluation Storage Module, a component of the Evaluation Extension. In one embodiment, the Evaluation Extension104has an Evaluation Storage Module120. If the Evaluation Addition Request140has been determined to be authorized and valid, then the Evaluation Addition Module114sends the Artifact Identifying Key142and the Evaluation Value144to the Evaluation Storage Module120, which associates the Artifact Identifying Key142and the Evaluation Value144and stores the associated pair. In some embodiments the Evaluation Addition Module114sends the Evaluation System Model Identifying Key148to the Evaluation Storage Module120to be associated and stored with the Artifact Identifying Key142and the Evaluation Value144. In some embodiments the Evaluation Addition Module114sends a user identifying key extracted from the Authorization Token136-1the to the Evaluation Storage Module120to be associated and stored with the Artifact Identifying Key142and the Evaluation Value144.

FIG. 9shows the function of an Evaluation Providing Module, a component of the Evaluation Extension. In one embodiment, the Evaluation Extension104has an Evaluation Providing Module122. The Client102may request the stored evaluations of UDDI v3 registry artifacts by sending to the Registry106a standard UDDI v3 find request that is modified to include an evaluation qualifier. The Message Receiving Module110determines the Find Artifact with Evaluation Qualifier Request160is a message regarding evaluations and sends it to the Evaluation Providing Module122. The Evaluation Providing Module122redacts the evaluation qualifier from the Request160to form a Redacted Find Artifact Request162, which is sent to the Registry106. The Registry106returns an Artifact List164with identifying keys of any artifacts matching the requirements specified in the Redacted Request162. The Evaluation Providing Module122sends the Artifact List164to the Evaluation Storage Module120which retrieves any stored evaluations associated with any of the artifact identifying keys in the Artifact List164. These Associated Evaluations166are sent to the Evaluation Providing Module122which forwards them to the Client102along with the Artifact List164. In some embodiments, the Artifact List164is reordered by the Evaluation Providing Module122according to the Associated Evaluations166before the Artifact List164is sent to the Client102. In some embodiments, only a reordered Artifact List164is sent to the Client102and the Associated Evaluations are not sent. In some embodiments, artifacts in the Artifact List164that the Evaluation Storage Module120finds no evaluations for is removed from the Artifact List164before the Artifact List164is sent to the Client102.

FIG. 10shows an example of a Request to find artifacts with evaluations. A portion of a standard UDDI v3 request190to find a specified type of UDDI v3 article—web services—is shown with a findQualifier192that has a value194of “uddi:evaluation:quality”. All UDDI v3 compliant client applications should be able to make this request. A UDDI v3 server would recognize this request, but would not know how to handle this particular findQualifer value194. A Redacted Find Request196comprises the Find Request190with the evaluation qualifier192removed.

FIG. 11shows a flowchart for an embodiment of a method for an extension to a Universal Description Discovery and Integration (UDDI) v3 registry to maintain evaluations of artifacts in the registry. One stage210of the method comprises receiving from a client an evaluation addition request to add an evaluation of an artifact in the UDDI v3 registry. A second stage212includes receiving from the client an artifact identifying key and an evaluation value associated with the artifact identifying key. In one embodiment, the artifact identifying key and an evaluation value associated with the artifact identifying key are sent in the same message as the evaluation addition request. In another embodiment, the artifact identifying key and an evaluation value associated with the artifact identifying key are sent in one or more different messages. A third stage214includes storing an evaluation, including storing the artifact identifying key and the associated evaluation value, if the evaluation addition request is authorized and valid. In one embodiment, a key identifying the user who requested the evaluation addition is associated with the artifact identifying key and associated evaluation value and stored with them.

FIG. 12shows a flowchart for a second embodiment of a method for a UDDI v3 registry to maintain evaluations of artifacts in the registry. One stage230of the method comprises authorizing a client to make an evaluation. A second stage232includes receiving from a client an evaluation addition request to add an evaluation of an artifact in the UDDI v3 registry. In some embodiments, more than one evaluation addition request can be made per message sent by the client. A third stage234includes receiving with the evaluation addition request additional information items including an artifact identifying key, an evaluation value to be associated with the artifact identifying key, an authorization token, and a key identifying an evaluation system. In one embodiment, the additional information items are sent in the same message as the evaluation addition request. In another embodiment, the additional information are sent in one or more different messages. A fourth stage236includes determining if the evaluation addition request is authorized. A five stage238includes determining if the evaluation addition request is valid. A sixth stage240includes storing an evaluation, including storing the artifact identifying key and the associated evaluation value, if the evaluation addition request is authorized and valid.

FIG. 13shows a flowchart for a method for an extension to a UDDI v3 registry to monitor messages to the registry. A first stage250of the method includes receiving from the client a UDDI v3 message. A second stage252includes determining if any of the message contents is regarding artifact evaluations. A third stage254includes processing the message in the extension. The third stage254is only performed if the message has contents that regard artifact evaluations. A fourth stage256includes forwarding the message to the registry without further processing by the extension. The fourth stage256is only performed if the message does not have contents that regard artifact evaluations.

FIG. 14shows a flowchart for a method for an extension to a UDDI v3 registry to authorize a client application to make an evaluation. This method is one embodiment for a detailed method of carrying out the first stage230of the method shown inFIG. 12. A first stage310includes receiving from the client application an authorization request, a user identifying key and a credential associated with a user of the client application. In some embodiments this request may be in the form of a standard UDDI v3 get_auth_Token request. A second stage312includes forwarding to the registry the authorization request, the user identifying key and the user credential. A third stage314includes receiving from the registry an authorization token, if the registry sent an authorization token. In some cases, the registry will deny the request for authorization and send an error message indicating that the provided pair user identifying key and credentials is invalid for the request. If such an error message is received, the extension stops processing the request and the remainder of this method is not performed. A fourth stage316includes associating the first authorization token with the user identifying key. A fifth stage318includes storing the first authorization token and associated user identifying key. A sixth stage320includes forwarding to the client the first authorization token.

FIG. 15shows a flowchart for a method for an for an extension to a UDDI v3 registry to determine if an evaluation addition request from a client is authorized. This method is one embodiment for a detailed method of carrying out the fourth stage236of the method shown inFIG. 12. A first stage358includes deciding if an authorization token received from a client matches a stored authorization token previously received from the UDDI v3 registry. If the received token matches a stored token, then the request is authorized. If the received token does not match a stored token, then the request is not authorized.

FIGS. 16 and 17show a flowchart for a method for an for an extension to a UDDI v3 registry to determine if an evaluation addition request from a client is valid. This method is one embodiment for a detailed method of carrying out the fifth stage237of the method shown inFIG. 12. A first stage370includes forwarding to the registry a request for details about a registry artifact, the request including an artifact identifying key received from the client. A second stage372includes deciding if any of the details of a return message from the registry match the sent artifact identifying key. If any of the details of the return match the artifact identifying key, then the existence of the artifact corresponding to the key is confirmed. If none of the details of the return match the artifact identifying key or if the registry does not supply a return message, then a the existence of the artifact corresponding to the key is not confirmed. A third stage376includes forwarding to the registry a request for a list of valid values from an evaluation system saved as a t-model in the registry, the evaluation system identified with an evaluation system model key received from the client and sent with the request. A fourth stage378includes receiving from the registry a list of valid values associated with the evaluation system model. A fifth stage380includes deciding whether an evaluation value sent by the client to be associated with the registry artifact match one of the values in the list of valid values. If the evaluation value matches one of the values in the list, then the evaluation value is valid. If the evaluation value does not match one of the values in the list, then the evaluation value is not valid. A sixth stage386includes deciding if the evaluation request is authorized by deciding if the artifact exists and if the evaluation value is valid. If the artifact has been determined to exist and the evaluation value has been determined to be valid, then the evaluation request is valid. If the artifact has not been determined to exist or the evaluation value has not been determined to be valid, then the evaluation request is not valid.

FIG. 18shows a flowchart for a method for an for an extension to a UDDI v3 registry to provided a stored evaluation of a UDDI v3 artifact in the registry in response to a request from a client. A first stage410includes receiving from the client a request to find a specified type of UDDI v3 artifact, the request including a find qualifier regarding evaluations. A second stage412includes creating a redacted find artifact request by extracting the evaluation find qualifier from the find artifact request. A third stage414includes forwarding the redacted find artifact request to the registry. A fourth stage416includes receiving from the registry a response list of zero or more artifact identifying keys, responsive to the redacted find artifact request. A fifth stage418includes retrieving evaluation values associated with any artifact identifying keys in the response list. A sixth stage420includes forwarding to the client, the response list of artifact identifying keys and the associated evaluation values.

FIG. 19shows an embodiment including instructions on a tangible machine accessible medium. One embodiment of the invention includes instructions890placed on a tangible machine-accessible medium, which when accessed by a machine cause the machine to execute the instructions to carry out the methods described herein. A tangible machine-accessible medium includes any mechanism that stores information in a form accessible by a machine (e.g., a computer800, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.). For example, a tangible machine-accessible medium includes reusable and non-reusable media (e.g., read only memory (ROM)860; random access memory (RAM)870; mass storage media memory880such as magnetic disk storage media; optical storage media; flash memory devices; etc.).