The invention relates generally to computer systems and networks, and more particularly to distributed services.
There are many types of computing services, resources and data that computer users and applications need to manage and otherwise access, such as services and data maintained on corporate networks and other remotely accessible sites including intranets and the internet. As there are many different computing platforms, various platform-independent mechanisms and protocols that facilitate the exchange of network information are becoming commonplace, including HTTP (HyperText Transfer Protocol), XML (extensible Markup Language), XML Schema, and SOAP (Simple Object Access Protocol). The concept of web services, in which businesses, organizations, and other providers offer services to users and applications, is based on these standards. Web services are services that connect applications across an intranet, extranet, or across the Internet, so that these applications can share resources and information. Web services can be offered by any individual or organization that has the tools to create them and make them available to other individuals or organizations online.
To be of value, web services need to enable users and applications to locate them, and exchange the information needed to execute them. To this end, UDDI (Universal Description Discovery & Integration) provides a set of defined services (e.g., in a universal business registry) that help users and applications discover such businesses, organizations, and other web services providers, along with a description of their available web services and the technical interfaces needed to access those services. UDDI thus facilitates the connection between the providers and the consumers of Web services. Although such services may be provided over the internet, services also may be provided in an enterprise environment or other intranet, where the services and their usage may be more controlled. Thus, not just UDDI, but other service registries (such as one based on Microsoft Corporation's Active Directory®) may provide a way of locating a distributed service.
Regardless of the service registry, taxonomies such as those within UDDI may be used to categorize sets of related values in the service registry, in which these values are typically used to categorize entities such as web services or web service providers. These values make up the “nodes” within a taxonomy. The nodes typically offer a hierarchical breakdown of a domain (such as the series of hierarchically arranged nodes in a geographic taxonomy path “World/Europe/UK/Scotland”). Taxonomies may also cover domains where there is no established hierarchy, such as by placing all nodes as peers at the top, or root level.
However, while UDDI provides a valuable technology for locating web services that works in part by providing the ability to categorize UDDI entries, the UDDI specifications provide no standard mechanism for programmatically discovering nodes within a taxonomy, and specifically no support for discovering related nodes. Further, there is no way to discover what is at the root of a given taxonomy. Although it is possible for a client to cache the taxonomy data (via some receiving mechanism outside of UDDI), such data tends to be large, and may be customized and/or change often, making client caching impractical in many, if not most, situations.
As a result, this lack of support significantly hinders navigation around the taxonomy and the presentation of taxonomy-related data. What is needed is a better way for clients to interact with taxonomies, such as UDDI taxonomies, to obtain such information about the taxonomy and the contained nodes and node relationships.
Briefly, the present invention provides a system and method for enabling UDDI client applications to interactively obtain taxonomy information from a UDDI server and thereby present that information to a user, such as to enable the user to navigate the taxonomy. A mechanism such as an application programming interface (API) is provided by which a client application sends a unique taxonomy identifier and a relationship qualifier to a server. The client may also provide a node identifier within the taxonomy to indicate a reference node for which a related node (or set of related nodes) is being sought. The API may use XML as the message format for the request and the response.
The API provides the requested information to an implementing service in a server (e.g., in a UDDI-based service registry). A request handling mechanism in the server extracts the data provided by the client in order to query a database (which may be any data store) for the relationship information. The request handling mechanism then formats and returns a response based on the results of the database query. The client (e.g., an application program running thereon) then interprets the response and thereby has the capability to enumerate, identify and describe the taxonomy.
If the client provides a root node qualifier, the server returns a root node identifier at the top or “root” level of the specified taxonomy. A taxonomy may have multiple root nodes, in which event the response may include the data for each root node. If the client provides a parent node qualifier and specifies a particular node within the taxonomy, the server returns information about the parent node. If the client provides a child node qualifier and specifies a particular node within the taxonomy, the server returns information about the child node or nodes of the specified node. More than one qualifier can be provided per request, and other relationship qualifiers are possible. The relationship may be with a node in another taxonomy, e.g., to specify one node in a taxonomy and find an equivalent node in another taxonomy.
The response may provide additional details. For example, in a UDDI-based environment, the response will include the unique identifier of the taxonomy, a unique (within the scope of that taxonomy) keyValue that uniquely identifies the node within that taxonomy, a keyName comprising human-readable symbols such as a text string, and an indication (in an isValid attribute) of whether this node is appropriate for classifying entities, or is provided only to provide structure within the hierarchy.
To provide the relationship information, the server maintains a database in the form of one or more tables accessed with keys. One such table includes a taxonomy UUID field, a taxonomy node value field, a parent node value field, and an isValid field. The keyName data may be in another field, or may be kept as an offset pointer or the like into a structure containing the keyName strings. With this arrangement, given the appropriate keys to identify a taxonomy, and a node therein if a relationship beyond the root node is being sought, a straightforward query can determine root, parent and child relationships, and relationships with the node of another taxonomy. Multiple queries can be used to obtain other relationships. In general, if XML is used, any relationship tag that the client and request handling mechanism both understand and from which the server can detect a relationship may be used to request and obtain data.
With the response data, the client can present a hierarchical view that matches the taxonomy or taxonomies on the server. The client application may allow navigation through the taxonomies, along with displaying information about each node as the user selects a node during navigation.
Other advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which:
Exemplary Operating Environment
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to: personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media including memory storage devices.
With reference to
The computer 110 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 110 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computer 110. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media, discussed above and illustrated in
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160 or other appropriate mechanism in a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
Interactively Obtaining and Presenting Taxonomy Information
The present invention is in part, generally directed towards distributed network services, in which a client running on essentially any platform may use a defined protocol such as SOAP (Simple Object Access Protocol) to access network services over UDDI. However, the present invention is not limited to UDDI, but applies to any technology that handles requests related to information that may be arranged as nodes in a taxonomy. Thus, while the present invention will primarily be described with reference to UDDI and UDDI services, it is understood that the present invention may apply to locating related information in general. Further, while the present invention will be primarily described with respect to SOAP, XML, UDDI, and/or Windows®/.NET, it is understood that the present invention is not limited to any particular implementation, protocols, components, APIs, and so forth, but also encompasses similar mechanisms for interacting over a network. Thus, although the examples herein are related to the UDDI standards, it is understood that the actual invention may be abstracted to provide generic capabilities for navigating hierarchical categorizations on alternate systems.
As generally represented in
In
As represented in
In general, two fields are used to identify a node within a particular taxonomy within the UDDI specificationsm (tModelKey and keyValue) and three fields are used to describe the node (tModelKey, keyValue and keyName). Further, beyond the UDDI specifications, and isValid attribute is also used to describe an aspect of each node, as described below.
The tModelKey field contains a unique identifier in the form of a Globally Unique Identifier (GUID) to identify the intended taxonomy of values, while the keyValue field contains a node identifier which is unique within the scope of the taxonomy. The keyName field contains a non-unique, textual description of the node. The keyName value is typically a human-readable identifier for the node that is not used for programmatic identification, in part because it is non-unique. An example of these fields such as used to describe the node 223 in the taxonomy 200 of
This (hypothetical) example uniquely identifies and describes Joe's Cookbooks node value (128649) within a UDDI-based publisher taxonomy uniquely identified as “297axa47-2de3-4454-a04a-cf38e889d0c4”. There may be another publisher named Joe's Cookbooks in this same taxonomy 200, but the keyValue (128649) uniquely identifies the publisher in question.
As mentioned above, the UDDI specifications provide no standard mechanism for programmatically discovering nodes within a taxonomy, and thus in the above example, would provide no support for discovering that Joe's Cookbooks is a child of the node Book Publisher with value 101407 (and with KeyName “XYZ Co.” within this taxonomy, or that at the root of this taxonomy, there is a “Suppliers” node 100016.
In accordance with an aspect of the present invention, there is provided a mechanism by which a client application may obtain details about the nodes within a taxonomy and the relationships among these nodes, (and possibly relationships with nodes of another taxonomy). Note that as used herein, a “client application” may itself be a server application or another UDDI server variant, that is, the client is any consuming application, and is not necessarily an end-user GUI client application. In one implementation, this mechanism is provided as an application programming interface (API) referred to as the “Related Categories” API. When implemented within Microsoft® UDDI Services, for example, the Related. Categories API uses XML as the message format for the request and the response. More particularly, (using the actual names) in one implementation, the Related Categories API provides a mechanism to interactively obtain details about the nodes within a taxonomy via a single, flexible XML “get_relatedCategories” request message, which returns an XML “categoryList” response message.
As generally represented in
More particularly, in one implementation, to request the details for the root of a taxonomy, the identifying key for the taxonomy, along with an element specifying the relationship that is being requested, is specified:
The response message, named categoryList in this example implementation, provides the details for the root node of the specified categorization:
To summarize using the data structures in this implementation, the general request-response operation is represented in
Note that the response details 318 include the unique (within the scope of this taxonomy) keyValue, the keyName and an indication (the is Valid attribute) of whether this node is appropriate for classifying entities or is provided only to provide structure within the hierarchy. Other attributes, such as a flag that if set on a node would hide that node's data and/or its existence from clients, are also feasible. Although not shown, if no data is found for the tModelKey value, an appropriate error message or the like may be returned.
As a second example, represented in
The following table sets forth the get_relatedCategories API in the form of an XML request seeking information of related nodes, providing the identifying key for the taxonomy, along with elements specifying the relationships of interest:
The response message includes the details for the root node of that categorization along with the parent node and any child nodes (in this example none):
As can be seen from this return message and referring to the hypothetical taxonomy of
In general, a single request (and corresponding response) may be highly flexible in what information is being sought per request. Thus, it is feasible to have a request that spans different taxonomies, has relationship requests for more than one node within a taxonomy, and/or can request different relationship data for the same node. Thus, the details for the related categories for more than one relationship may be specified within the same request as represented in the following example, which shows the XML message for requesting the return of details on the root node for a particular taxonomy identified by the tModelKey “uuid:c0b9fe13-179f-413d-8a5b-5004 db8e5bb2”; the child and parent categories relative to the particular node “51121” within that taxonomy (identified by the tModelKey “uuid:c0b9fe13-179f-413d-8a5b-5004 db8e5bb2”); the root and child categories relative to the particular node “51121” within that taxonomy; and the details for the particular node “51121” within that taxonomy:
The resulting categoryList is an in order collection (sequenced according to the order of requests) of categoryInfo structures:
Note that in this implementation the response is not required to include the optional parentKeyValue attribute, as the API already provides a mechanism for obtaining the parentKeyValue of any given node. Further, the categoryValue defined as being of type categoryValueType response is not required to include the optional parentKeyValue or the tModelKey attribute, as the API already provides a mechanism for obtaining the parentKeyValue of any given node and the tModelKey can be extracted from the surrounding categoryInfo node. As described above, the isValid boolean attribute signals whether this node is valid for categorization, e.g., in this example the root node of NAICS is not valid for classification. The optional “truncated” attribute is included on the categoryList element to indicate cases in which the server truncated the result set, such as in the case of a large result set. Also, if a taxonomy identifier is provided along with a keyValue having zero relationship qualifiers, the other details for the identified node (e.g., the keyName and is Valid attribute) are returned.
The following provides an example XSD (Extensible Schema Definition) language-formatted data structure setting forth the details of the schema:
Turning to an explanation of the operation of the server response handling mechanism 310, in general, the categorization relationships are maintained in a database 312 in the form of one or more tables accessed with keys. For example, as represented in
As is readily apparent from
While the above examples are directed to root, parent and child relationships, virtually any relationship that may be defined such that the server can determine the appropriate data for the node or nodes is feasible. For example, a grandparent node can seek the parent, and use the resulting parent node data to seek its parent, and so on. Sibling nodes could be found by locating the parent, and then locating that parent's children.
Moreover, the relationship need not be in the same taxonomy. For example, there may be an equivalence relationship between nodes of two taxonomies. For example, a node such as shown as “United States” (actually its value) in the database table 500 appears in the Geography-related taxonomy and the Postal Code-related taxonomy. A query may be arranged to return information (e.g., the different UUID's) based on such an equivalent relationship. For example, a query may be used to obtain the UUID of any taxonomy in which an equivalent node appears, and/or may return the taxonomy and a node value for that equivalent node (along with any other information). In general, if XML is used, any relationship (or other) tag that the client and request handling mechanism both understand (e.g., an <equivalenceRelationship> tag) and from which the server can detect a relationship may be used to request and obtain data.
Although not necessary to the present invention, a primary purpose for obtaining relationship data at the client is to present it in a meaningful way, such as to allow a user of the client to navigate the taxonomy.
The results, corresponding to the data about the selected node, are displayed in a right results frame 604. Essentially anything returned by the server 308 in accordance with the present invention may be included in the results frame 604, e.g., the friendly name, status of the “is valid” attribute, the parent name, any child names and/or other relationships. In this manner, a user can navigate a taxonomy and view relevant information as needed.
As can be seen from the foregoing detailed description, there is provided a method and system by which clients can obtain taxonomy information including relationships, such as for presenting that information to a user. The method and system are straightforward for clients to use, are flexible and operate on demand, thereby rapidly providing access to relevant information, and particularly relationship information, among significant amounts of taxonomy data. The method and system thus provide significant advantages and benefits needed in contemporary computing.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
Number | Name | Date | Kind |
---|---|---|---|
6711585 | Copperman et al. | Mar 2004 | B1 |
6888554 | Decombe | May 2005 | B1 |
7181438 | Szabo | Feb 2007 | B1 |
20030191769 | Crisan et al. | Oct 2003 | A1 |
20040093326 | Carson et al. | May 2004 | A1 |
Number | Date | Country | |
---|---|---|---|
20040267718 A1 | Dec 2004 | US |