What's New in UDDI Version 2.0?
A lot has happened in the UDDI community since Version 1.0 of the UDDI specification was released on September 6, 2000. The UDDI community has broadened from the three charter members (Ariba, IBM, and Microsoft) to include over 280 advisory group members! As a result of this influx of additional contributors (and hence their requirements), UDDI has increased in scope and functionality. Let's briefly highlight the new functionality covered in UDDI v2.0 and then detail how these features can be used by SkatesTown or WeMakeIt Inc.
These changes are documented in the Version 2.0 UDDI specification documentation set available at www.uddi.org (copyright © 2001 by Accenture, Ariba, Inc., Commerce One, Inc., Compaq Computer Corporation, Equifax, Inc., Fujitsu Limited, Hewlett-Packard Company, 12 Technologies, Inc., Intel Corporation, International Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and Verisign, Inc. All Rights Reserved). This specification was released on June 8, 2001.
Overview of Changes in UDDI V2.0
We can categorize the changes from Version 1.0 to Version 2.0 of the UDDI specification into these broad areas:
Overall, none of these changes have a dramatic impact on SkatesTown or WeMakeIt Inc., but some of the changes are useful for WeMakeIt Inc. The changes are incremental in nature, and outside of the assertions and perhaps the third-party taxonomy feature described next, the changes are not likely to be dramatically exploited by SkatesTown, WeMakeIt Inc., or organizations like them.
Taxonomies are the primary means in UDDI of organizing and, therefore, searching for entries. UDDI Version 2.0 added a feature by which third parties could specify new taxonomies and provide a service by which UDDI registries, in particular operator nodes within the UDDI Business Registry, could validate categorizations asserted against a taxonomy developed by a third party. Most of the new findQualifiers (see the section "New Find Qualifiers") added in UDDI Version 2.0 are suited for referencing these third-party taxonomies in find messages.
Why would anyone want to define a new taxonomy? UDDI provides, by default, three canonical taxonomies: NAICS, for industry classifications; UN/SPSC, for product/service classifications; and ISO 3166, for geographic classifications. These general-purpose taxonomies are quite useful for broadly classifying businesses or services. However, a particular industry might want to define a new taxonomy to detail product classifications according to a scheme commonly used in their industry. A third-party QoS guarantor might wish to define an identifier scheme, classifying businesses and their services according to some new QoS metric for Web services. Organizations can choose to convert their product codes into a taxonomy and categorize which businessService entries are associated with requesting, purchasing, and getting post-sales support on each of their products.
WeMakeIt Inc. decides to create a canonical parts code scheme for all the parts WeMakeIt Inc. uses in its manufacturing lines. Because WeMakeIt Inc. is a manufacturer of a wide and frequently changing variety of goods, this list of product codes is constantly updated. By creating this taxonomy, WeMakeIt Inc. can make its private UDDI partner catalog registry extremely useful. WeMakeIt Inc. requires all its suppliers to use Web services to interact with WeMakeIt Inc.'s automated supply reordering system. All the partners are required to categorize their UDDI businessService entries using WeMakeIt Inc.'s custom parts code taxonomy. In this way, the businessService entries in WeMakeIt Inc.'s partner catalog UDDI are all classified according to its parts code. When WeMakeIt Inc. needs to reorder a part, it can issue a taxonomy-based find operation and retrieve all the business partners that deal in that part. WeMakeIt Inc. can then issue RFQs, purchase orders, and so on, to resupply a manufacturing line, or to just-in-time prepare for an upcoming manufacturing run.
Let's examine the steps WeMakeIt Inc. used to set up its third-party taxonomy.
First, WeMakeIt Inc. used their existing product code scheme as the basis of the taxonomy. It created a relational database containing product codes for the 10,000 or so supplies that it has ever ordered in the past. WeMakeIt Inc. built a small Web-based application to browse the database, displaying code to product name mappings.
Next, WeMakeIt Inc. created a tModel to describe its product code taxonomy and register it in the UDDI Business Registry. Alternatively, WeMakeIt Inc. could have created the tModel in its own portal private UDDI registry and promoted it to the UDDI Business Registry. Regardless, the save_tModel message looks like this:
<save_tModel generic="2.0" xmlns="urn:uddi-org:api_v2" > <authInfo>...</authInfo> <tModel tModelKey=""> <name>WeMakeIt Product Code Taxonomy</name> <description xml:lang="en">WeMakeIt Inc. classfies all its supplies... </description> <overviewDoc> <overviewURL> http://www.wemakeit.com/supplies/browseReorderCatalog </overviewURL> </overviewDoc> <categoryBag> <keyedReference keyName="TModel categorization type" keyValue="categorization" tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4"/> <!-- UDDI Types tModelKey --> </categoryBag> </tModel> </save_tModel>
The tModelKey assigned by the UDDI registry (say, UUID:E0AC1230-4CC1-11D5-B353-B4D70FD31643) is remembered and documented in the Web pages associated with the reorder catalog browser WeMakeIt Inc. hosts at http://www.wemakeit.com/supplies/browseReorderCatalog. This entry categorizes WeMakeIt Inc.'s product code scheme as a categorization tModel. WeMakeIt Inc. tells all its suppliers to get this tModel and use it to classify their businessEntity and businessServices according to which of these product codes the supplier provides.
Because WeMakeIt Inc. wants their suppliers properly categorized, it provides a validation mechanism for its taxonomy. WeMakeIt Inc. sets up a Web service to validate any UDDI entry that is categorized using its custom taxonomy. This Web service is conformant to the validate_values requirements specified in the UDDI Version 2.0 programmer's API. WeMakeIt Inc. registers this service with the UDDI Business Registry using the mechanism specified by the operator node that controls WeMakeIt Inc.'s entries. It tells all its suppliers to reference this validate_values Web service with their private portal UDDI registries.
Without this effort, WeMakeIt Inc.'s custom taxonomy will remained unchecked. The difference between a checked and an unchecked taxonomy is fairly important. With a checked taxonomy, any save_business, save_service, or save_tModel (although save_tModel is unlikely to use WeMakeIt Inc.'s taxonomy) that references this taxonomy will use the validate_values service published by WeMakeIt Inc. If an entry specifies an invalid category, or WeMakeIt Inc.'s validate_values service returns an error for some reason, the save operation for the entry fails.
If WeMakeIt Inc. developed an unchecked taxonomy, there would be no way that its suppliers could ensure that their classifications accurately reflected WeMakeIt Inc.'s supplies coding scheme.
Let's examine WeMakeIt Inc.'s validate_values Web service in a little more detail.
The UDDI registry that is attempting to validate the use of WeMakeIt Inc.'s taxonomy would send a validate_values message to the service registered by WeMakeIt Inc. with that registry. Details of the taxonomy validation service are specific to each UDDI registry implementation.
<validate_values generic="2.0" xmlns="urn:uddi-org:api_v2"> <businessEntity/>... | <businessService/>... | <tModel/>... <validate_values>
In the case of WeMakeIt Inc., its validate_values service would receive this message, extract the key values used in any keyedReference element referencing its taxonomy tModelKey, and do a simple lookup of this keyValue against its product code database to make sure the keyValue used by the entry's categorization is a valid value. Its validate_values service ignores all other details of the entry being categorized.
The validate_values service must return a dispositionReport as specified in the UDDI Version 2.0 API specification with errorCode set to E_success and errno set to the value 0. If an error occurs (for example, if one of the keyValues is not within the product code set), the service must return a SOAP fault containing a dispositionReport containing the error details. In this case, the only error that would be returned from WeMakeIt Inc.'s validate_values service is E_invalidValue. The error text, of course, indicates which keyedReference element caused the error. Only the first error is reported.
Modeling Relationships between businessEntity Entries
In UDDI Version 1.0, each company is represented by a single businessEntity. So, small organizations like SkatesTown were modeled with the same technique as larger, more complicated organizations like WeMakeIt Inc. Prior to UDDI Version 2.0, UDDI provided no formal mechanism to model the relationship between individual business units within a large organization.
The feature of publication assertions was introduced in UDDI Version 2.0 to address the publication needs of large, complex organizations. Any pair of businessEntity entries can be associated in some fashion, reflecting their business relationship. Using this feature, the relationship between WeMakeIt Inc. and its subsidiaries in Asia and Europe can be formally modeled.
A new find message, find_relatedBusinesses, was added to allow requestors to view these relationships. This new find message is described in more detail in the section "Added find_relatedBusiness Message". The only relationships visible through the find_relatedBusinesses message are those that have been validated by the owners of both businessEntity entries. The businessEntity relationship feature was built this way to avoid false and misleading claims about the relationships between one business and another. Unless both parties assert the relationship exists, it is not visible from UDDI.
Let's review how WeMakeIt Inc. would create the relationships between the businessEntity representing the corporate holding company WeMakeIt Inc. and its two subsidiaries, WeMakeIt Asia Inc. and WeMakeIt Europe PLC.
First, WeMakeIt Inc. would create businessEntity entries for all three business units, using the save_business message. Let's assume these entries are created in WeMakeIt Inc.'s private portal UDDI node and later promoted to the UDDI Business Registry. The example would be the same if WeMakeIt Inc. did all this registration in the UDDI Business Registry. In the case of WeMakeIt Inc., Joanna Pravard manages the UDDI entries in WeMakeIt Inc.'s private UDDI registries, as well as the UDDI Business Registry. For other, more complicated organizations, different people might manage each businessEntity separately.
Joanna must now make several publisher assertions to describe the relationships between WeMakeIt Inc. and its two subsidiaries:
After the first two assertions are made, using the add_publisherAssertions message (described later), the relationship between WeMakeIt Inc. and WeMakeIt Asia Inc. would be visible through the find_relatedBusinesses message. After the last two assertions are made, the relationship between WeMakeIt Inc. and WeMakeIt Europe PLC would be visible. Note that Joanna could make all four assertions at once using a single invocation of add_publisherAssertions like this:
<add_publisherAssertions generic="2.0" xmlns="urn:uddi-org:api_v2" > <authInfo>...</authInfo> <publisherAssertion> <!-- BusinessKey for WeMakeIt Inc.--> <fromKey>DCD2B450-A4C0-11D5-AF98-BD95162D3AC9</fromKey> <!-- BusinessKey for WeMakeIt Inc. Asia --> <toKey>DCD5C190-A4C0-11D5-AF98-BD95162D3AC9</fromKey> <keyedReference tModelKey="uuid:807A2C6A-EE22-470d-ADC7-E0424A337C03" keyValue="parent-child"/> </publisherAssertion> <publisherAssertion> <!-- BusinessKey for WeMakeIt Inc.--> <fromKey>DCD2B450-A4C0-11D5-AF98-BD95162D3AC9</fromKey> <!-- BusinessKey for WeMakeIt Inc. Europe --> <toKey>DCD5C191-A4C0-11D5-AF98-BD95162D3AC9</fromKey> <keyedReference tModelKey="uuid:807A2C6A-EE22-470d-ADC7-E0424A337C03" keyValue="parent-child"/> </publisherAssertion> <!-- etc. for the other two assertions --> </add_publisherAssertions>
Note the use of keyedReference in the add_publisherAssertions message. The business relationships feature of UDDI makes use of a special, canonical tModel to specify the different kinds of relationships. There are three possible key values for the relationships tModel in UDDI Version 2.0:
As a result of issuing this add_publisherAssertions message, the assertions that appear in the find_relatedBusinesses example would be visible.
After Joanna registers this information with the UDDI Business Registry, she should occasionally issue a get_assertionStatusReport, which will tell her if any other individual has attempted to assert a relationship with any of Joanna's businessEntity entries. Joanna will, of course, reject each of these assertions, simply by not acting. If the relationship is not mutually asserted, it is not visible.
To summarize the components described in this section, UDDI has defined a business relationship facility based on pair-wise assertions of the relationship between two businessEntity elements. To support this, UDDI Version 2.0 added the following:
Changes to the Inquiry API
Added find_relatedBusinesses Message
This new message was added to the UDDI Version 2.0 Inquiry API as part of the new facility to model relationships between businessEntities (see "Modeling Relationships between businessEntity Entries"). The find_relatedBusinesses message is used to return a list of businessEntities related in some specified way with a target businessEntity.
The structure of the find_relatedBusinesses message looks like this:
<find_relatedBusinesses generic="2.0" xmlns="urn:uddi-org:api_v2" > [<findQualifiers/>] <businessKey/> [<keyedReference/>] </find_relatedBusinesses>
Like all the other find messages in the Inquiry API, the results found in the response message are subject to the values of the findQualifiers arguments. A discussion on the use of findQualifiers argument in find messages can be found in the section "Finding Information in a UDDI Registry."
The keyedReference argument can be used to restrict which related businessEntities are returned in the response message. This argument is optional and can appear at most once in the message. The value of the keyedReference should reference the uddi-org:relationships tModel, and keyValues should be taken from the small set of values associated with this tModel.
For example, if a potential client wished to determine what subsidiaries WeMakeIt Inc. had registered with its entry in the UDDI Business Registry, it would use the following find message:
<find_relatedBusinesses generic="2.0" xmlns="urn:uddi-org:api_v2" > <businessKey>DCD2B450-A4C0-11D5-AF98-BD95162D3AC9</businessKey> <keyedReference tModelKey= "uuid:807A2C6A-EE22-470d-ADC7-E0424A337C03" keyValue="parent-child"/> </find_relatedBusinesses>
Of course, the client would use a find_business message to locate the UUID businessKey for WeMakeIt Inc. The keyValue attribute in the keyedReference element was set to "parent-child", reflecting that the client is looking for "child" businessEntities (subsidiaries) of WeMakeIt Inc.
The result of this message is a list of businessEntities that WeMakeIt Inc. asserted were its child or subsidiary businessEntities. The following would be the response to the find_relatedBusinesses example message:
<relatedBusinessList generic="2.0" operator="uddi.anOperator" xmlns="urn:uddi-org:api_v2.0"> <businessKey>DCD2B450-A4C0-11D5-AF98-BD95162D3AC9</businessKey> <relatedBusinessInfos> <relatedBusinessInfo> <businessKey>DCD5C190-A4C0-11D5-AF98-BD95162D3AC9</businessKey> <name>WeMakeIt Asia Inc.</name> <description>WeMakeIt Asia provides outsourced man...</description> <sharedRelationships> <keyedReference tModelKey=""uuid:807A2C6A..." keyValue="parent-child"/> </sharedRelationships> </relatedBusinessInfo> <relatedBusinessInfo> <businessKey>DCD5C191-A4C0-11D5-AF98-BD95162D3AC9</businessKey> <name>WeMakeIt Europe Plc.</name> <description>WeMakeIt Europe provides outsourced m...</description> <sharedRelationships> <keyedReference tModelKey=""uuid:807A2C6A..." keyValue="parent-child"/> </sharedRelationships> </relatedBusinessInfo> ... </relatedBusinessInfos> </relatedBusinessList>
Of course, if there are no related businesses to the target businessEntity, then the response message would contain an empty relatedBusinessInfos element. An error message will be returned if the businessKey argument does not correspond to a target businessEntity in the registry or (like any other find message) if one of the findQualifiers arguments is invalid.
Multiple Language Support for Business and Service Names
One extremely useful enhancement in Version 2.0 of UDDI is its support for multiple names for businessEntity and multiple names for businessService. The primary purpose of this change is to support multiple language translations of the business or service name.
WeMakeIt Inc. intends to exploit this feature in its businessEntity entry in the UDDI Business Registry. Whereas previously the company included only the English version of its name, WeMakeIt Inc. intends to include a Spanish and French translation of the name to serve the entire North American Free Trade Zone market and to assist in winning contracts with clients in the European Union.
Here is the new businessEntity entry for WeMakeIt Inc.:
<businessEntity businessKey="DCD2B450-A4C0-11D5-AF98-BD95162D3AC9" authorizedName="JPavard" operator=...> <name>WeMakeIt Inc.</name> <name xml:lang="fr">Nous Faisons Tout Inc.</name> <name xml:lang="sp">Carbarundo Inc.</name> ... </businessEntity>
Although WeMakeIt Inc. can save its businessEntity elements with any number of child name elements, at most one of the names (which must be the first name element) can appear without an xml:lang attribute qualifier. (This is also true for description elements.) Any additional name element must have a unique xml:lang attribute qualifier. Note that the first name element (the one without xml:lang attribute) is assigned the code for US English, because that is the default language Joanna specified when she registered WeMakeIt Inc. with the UDDI Business Registry.
The impact of the businessEntity name change was great for WeMakeIt Inc., because it allowed the company to advertise in international markets. However, this name change facility is also supported the businessService element. This application of the multiple names facility is perhaps more useful. WeMakeIt Inc. has one businessService advertised in the UDDI Business Registry, that being its private portal UDDI (see the earlier discussion of portal UDDI nodes as part of the private UDDI discussion). The additional language translations available on the name element of businessService make it easier to find WeMakeIt Inc. The additional service name translations make a great accompaniment to the language translations of its service descriptions.
<businessService businessKey="DCD2B450-A4C0-11D5-AF98-BD95162D3AC9" serviceKey="... /> <name>Private Portal UDDI Inquiry API.</name> <name xml:lang="fr">Prive Portal UDDI Inquirer</name> ... </businessService>
UDDI Version 2.0 also makes it easier to find businesses using multiple names (again, each name element in the query must be in a separate language). Although this feature is nice in theory, the majority of businesses will use a single name in their UDDI businessEntity entries. For the record, the new find_business API in Version 2.0 allows up to five names to appear in the query. If any of the name elements in the query match on both the value of the name element and the language attribute, then the businessEntity is returned in the result set of the find operation. This feature has also been defined for the find_service API. WeMakeIt Inc. expects that many international clients browsing its private portal UDDI node will use this facility.
Less Restrictive find_business
UDDI Version 2.0 reduced some restrictions on the parameters in the find_business query. In Version 1.0 of UDDI, the find_business service was defined by the UDDI Programmer's API specification with the following syntax:
<find_business generic="1.0" [ maxRows="nn" ] xmlns="urn:uddi-org:api" > [<findQualifiers/>] <name/> | <identifierBag/> | <categoryBag/> | <tModelBag/> | <discoveryURLs> </find_business>
The major consequence of this is that the name, identifierBag, categoryBag, tModelBag, and discoveryURLs find arguments were all mutually exclusive. If a find_business had more than one of these arguments specified, the result of the inquiry would be an error message, of type E_tooManyOptions.
The Version 2.0 find_business removes this restriction. With UDDI Version 2.0, a programmer at WeMakeIt Inc. can search a UDDI registry for businesses offering Wheel Bearings (according to the UNSPSC code) that have services based on the e-Torus standard order suite POPlacement service interface and whose name starts with the letter A. A rough sketch of the find_business with these parameters is as follows:
<find_business generic="1.0" xmlns="urn:uddi-org:api_v2" > <name>A%</name> <categoryBag> <keyedReference <!-- UNSPSC 3.1 --> tModelKey="uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384" keyName="Wheel bearings" keyValue="31171503"/> </categoryBag> <tModelBag> <tModelKey>UUID:D16D8A40-4F07-11D5-B842-87383803123D</tModelKey> </tModelBag> </find_business>
In Version 2.0, the E_tooManyOptions error occurs only when more than five name arguments are included in the find_business invocation.
New Find Qualifiers
UDDI Version 2.0 added six new values to the permitted set of valid findQualifiers in find messages. The use of findQualifier arguments in find messages is described previously in the section "Finding Information in a UDDI Registry."
The new findQualifiers add more flexibility to the find messages. Most of the new findQualifiers extend the sophistication of categoryBag (for example, taxonomy-based) or identifierBag find operations. Let's take a brief look at each of the new findQualifiers.
This findQualifier is used on find messages involving categoryBag or identifierBag arguments. The find behavior specified by the use of this findQualifier is to OR together any keyedReference elements associated with the same tModelKey (such as references to the same taxonomy, identifier system, or other namespacing mechanism). Of course, keyedReference elements from separate tModelKeys are still ANDed together.
For example, if SkatesTown wanted to find all businesses that are:
then the following find_business message would be used:
<find_business generic="2.0" xmlns="urn:uddi-org:api_v2" > <findQualifiers> <findQualifier>orLikeKeys</findQualifier> </findQualifiers> <categoryBag> <!-- UNSPSC 3.1 patterns --> <keyedReference tModelKey="uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384" keyValue="311715" keyName="Bearings"/> <keyedReference tModelKey="uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384" keyValue="31171503" keyName="Wheel Bearings"/> <keyedReference tModelKey="uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384" keyValue="31171505" keyName="Roller Bearings"/> <keyedReference tModelKey="uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384" keyValue="31171515" keyName="Plain Bearings"/> <!-- GEO Taxonomy patterns ISO 3166-1 --> <keyedReference tModelKey="uuid:61668105-B6B6-425c-914B-409FB252C36D" keyValue="UA" keyName="United States"/> <keyedReference tModelKey="uuid:61668105-B6B6-425c-914B-409FB252C36D" keyValue="CA" keyName="Canada"/> </categoryBag> </find_business>
This facility is very important to support sophisticated searches of hierarchical taxonomies (such as UNSPSC) by specifying a categoryBag of all the keyValues associated with a particular branch of the taxonomy.
By default, any categoryBag or identifierBag based search uses a logical AND of all keyedReference elements when matching. The affect of this findQualifier is that all of this default logical AND behavior is reversed to be logical OR. So if any entry matches any of the keyedReference elements in any of the categoryBag or identifierBag arguments, then it is included in the result set of the message.
This findQualifier would be used if SkatesTown wanted to find any business that was categorized according to UNSPSC code 31171503 (wheel bearings) or 31171515 (plain bearings) or categorized in NAICS code 33992 (sporting and athletic goods). The following find_ business message illustrates the use of this findQualifier:
<find_business generic="2.0" xmlns="urn:uddi-org:api_v2" > <findQualifiers> <findQualifier>orAllKeys</findQualifier> </findQualifiers> <categoryBag> <!-- UN/SPSC patterns --> <keyedReference tModelKey="uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384" keyValue="31171503" keyName="Wheel Bearings"/> <keyedReference tModelKey="uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384" keyValue="31171515" keyName="Plain Bearings"/> <!-- NAICS patterns --> <keyedReference tModelKey="uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2" keyValue="33992" keyName="Sporting and Athletic Goods"/> </categoryBag> </find_business>
This is an interesting new wrinkle on the find_business message only. The use of this findQualifier modifies the behavior of categoryBag-based searches. The idea is that with this qualifier, the categoryBag of the businessEntity and all contained or referenced businessService elements are treated as a single, logical, aggregated categoryBag for purposes of matching. The response message will contain a businessList containing businessInfo elements for each businessEntity entry whose logical, aggregated categoryBag matched with any of the keyedReference elements contained in the categoryBag argument of the find_business message.
SkatesTown would use this feature in the case where some business partners categorized their businessEntity entries according to NAICS and their businessServices according to UN/SPSC, whereas other business partners might use both taxonomies for businessEntity only.
This is a handy new feature for the find_business message only. This findQualifier combines with other find arguments to restrict the response set to include only those businessEntity entries that include businessService elements that are categorized according to the categoryBag element (the find_business message must include a categoryBag argument). The categoryBag argument is applied to businessService elements, not businessEntity elements. The response of this message is a businessList containing businessEntity entries that contain or reference those businessServices whose categoryBag element matches the technical fingerprint specified in the categoryBag argument of the find operation. The serviceInfo elements contained within the businessService elements in the response will contain only those businessService entries matched by the categoryBag comparison (and not all the other businessServices that businessEntity has registered with the UDDI registry).
So if you are looking for all businesses that implement a service categorized in a particular way, this is the findQualifier to use. Consider an example find_business message using the serviceSubset findQualifier. If you wanted to find all businesses that advertise a businessService for a product within a given UNSPSC code, say 31171503 (wheel bearings), use serviceSubset and the categoryBag identifying the UNSPSC taxonomy with the key value for the given category. The following is an example of this kind of find:
<find_business generic="2.0" xmlns="urn:uddi-org:api_v2" > <findQualifiers> <findQualifier>serviceSubset</findQualifier> </findQualifiers> <categoryBag> <keyedReference tModelKey="uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384" keyValue="31171503" keyName="Wheel Bearings"/> </categoryBag> </find_business>
The result of this message is a list of businessEntities that have services categorized under the given UNSPSC category, and serviceInfo elements for each of the services so categorized.
This findQualifier specifies the default behavior of doing logical AND of any keyedReference as part of indentifierBag or categoryBag arguments in the find message. This is the default behavior inherited from UDDI Version 1.0 find messages. Because the findQualifier orLikeKeys (discussed earlier) was introduced, andAllKeys was added to the list of valid findQualifier arguments for completeness sake.
Soundex is a term used to describe name-based searches for entity names that sound alike.
This findQualifier can be used on the find_business and find_service messages to locate businesses or services with similar sounding names. This is the only new findQualifier not associated with categoryBag-or identifierBag-based find messages.
A find message that looks like
<find_business generic="2.0" xmlns="urn:uddi-org:api_v2" > <findQualifiers> <findQualifier>soundex</findQualifier> </findQualifiers> <name>Wee May Kit</name> </find_business>
will return a response message with a businessList containing a businessInfo element for WeMakeIt Inc. and any other businessEntity that sounds like "Wee May Kit." If multiple name parameters were in the find message (recall in UDDI find_xxx you can now specify up to five name arguments), the businessList would return entries that matched any of the names.
Changes to the Publication API
The changes made to the Publication API in UDDI Version 2.0 are all related to the publication assertions feature supporting the modeling of business relationships in UDDI. First, a set of five additional messages—add_publisherAssertions, set_publisherAssertions, delete_publisherAssertions, get_assertionStatusReport, and get_publisherAssertions—directly manage the business relationship assertions. Second, a related modification of the save_business behavior allows a businessService to be shared between businessEntities. The mechanism of modeling business relationships using the publication assertion feature is described in the section "Modeling Relationships between businessEntity Entries."
The add_publisherAssertions and delete_publisherAssertions messages are used to insert, update, and delete individual or small sets of publisher assertions. The set_publisherAssertions message manages an entire set of assertions as a single set. The get_publisherAssertions message is used to retrieve the entire set of assertions; it often will be used in conjunction with the set_publisherAssertions message. Finally, the set of new messages includes the administrative get_assertionStatusReport message, which is used to determine which assertions have been made referencing owned businessEntity entries that have yet to be acknowledged by reciprocal assertion of the business relationship.
Let's take a closer look at the five new publication messages and discuss how WeMakeIt Inc. would use these facilities.
This message is used to add one or more additional publisher assertions associated with businessEntities owned by the publisher. Like all the publication messages, entries acted upon must be owned by the user sending the message (the publisher, or technically the user associated with the authInfo element of the message). We saw in a previous example that Joanna Pravard would use this message to model the relationship between WeMakeIt Inc. and its subsidiaries. The benefit of this approach over the set_publisherAssertions is that assertions can be added incrementally, without having to refer to the entire set of assertions currently associated with the businessEntity.
This message is used to delete one or more publisher assertions associated with businessEntity entries owned by the publisher. Joanna Pravard would use this message to remove assertions in case one of the subsidiaries is sold to another company, or one of the subsidiaries goes out of business.
Of course, another way to delete assertions is to delete one of the businessEntity entries referred to in the relationship. When the delete_business message executes, any assertion associated with that businessEntity is also deleted.
This message is similar to the add_publisherAssertions message, except that it acts on the entire set of publisher assertions associated with any businessEntity owned by the user who sends the message (the publisher, or technically the user associated with the authInfo element of the message). Note that unlike most of the other publication messages, this affects entries associated with the publisher, not an individual element or set of elements identified by UUID keys. The result of the message is to replace whatever set of assertions existed before the message was sent with the assertions contained within the message. Essentially any existing assertion that is not in the message is deleted, and any new assertion that is in the message is added.
This message can act as an analog to a delete_publisherAssertions message by passing an empty set of publisher assertions, deleting the entire set of existing assertions associated with any businessEntity owned by the publisher.
This message is used to retrieve the entire set of publisher assertions associated with a publisher. Joanna Pravard would use this message in preparation to use the set_publisherAssertions message. Joanna would issue the get_publisherAssertions message, examine the set of publisher assertions, add a few, remove a few, and then use this modified set of publisher assertions as the argument in a set_publisherAssertions message.
This message is used to help publishers examine the set of assertions that reference any of their owned businessEntity entries. Joanna Pravard would use this message to see if any other publisher attempted to assert a relationship between one of his/her businessEntity entry and WeMakeIt Inc. Joanna, of course, would ignore these assertions. Until Joanna acknowledges these assertions by reciprocating with an assertion of her own, the relationship between WeMakeIt Inc. and the other businessEntity is not visible.
Sharing Services between businessEntity Entries
Different business units in a company might share Web services. For WeMakeIt Inc., in the case of their POPlacement Web service, a single instance of this Web service supports all three operating units. Although it is possible to duplicate businessService entries for this single Web service and place them separately into each separate businessEntity, this can become a maintenance headache for Joanna.
As a result of UDDI Version 2.0 modeling relationships between businessEntity entries, the facility has been added to share businessService entries between businessEntity entries. The behavior of the save_business message has been modified to allow a businessService contained by one businessEntity to be shared or referenced by a different businessEntity.
The save_business message takes one or more entire businessEntity elements as arguments. A businessEntity element can contain child businessService elements. If the businessKey child element of businessService has a value that is different from the businessKey of the businessEntity being saved, the save_business operation will add a reference from the businessEntity being saved to the businessService. The referenced businessService itself will not be changed as a result of the save_business operation.
A reference to a businessService can be removed from a businessEntity by sending a save_business message for that businessEntity without including a reference to the businessService in the businessEntity argument passed in the message.
Several other smaller changes were made in UDDI Version 2.0, but none of them impact SkatesTown or WeMakeIt Inc. For the sake of completeness, here is a list of several other miscellaneous changes that appeared in UDDI Version 2.0.
Generic and Default XML Namespace Updated
Recall that messages in UDDI require the use of the oddly named generic attribute, as well as the conventional definition of the default XML namespace. Messages intended for UDDI Version 2.0 compatible registries should include these attributes in the message element as shown here:
<API_MESSAGE_NAME generic="2.0" xmlns="urn:uddi-org:api_v2" >
These attributes appear to be redundant. The value of having the generic attribute to distinguish specification version intention seems to be already covered by specifying the default namespace of the message. The danger of this redundancy is now illustrated as the first version change in UDDI has been made. This problem is described by the following passage from the UDDI Version 2.0 API specification:
The specification does not explicitly dictate the legal combinations of values of these attributes. The client of the UDDI registry cannot determine what the outcome will be if the message mixes values for generic and the default namespace. It would have been better if the specification clearly required this to be an error condition or, better yet, removed the generic attribute altogether and relied solely on the value of the default namespace to indicate the version expectation of the message.
Miscellaneous Error Codes Changes
Table 7.2 summarizes the changes made to the expected error codes from Version 1.0 to Version 2.0.
SOAPAction Header Use Updated
The role of the SOAPAction HTTP header was described in Chapter 3. Version 1.0 of the UDDI specification required that this header be left as an empty string. This recommendation is contrary to how many SOAP engines use SOAPAction as a processing hint. UDDI Version 2.0 now allows this header to have as a value the name of the API message contained within the SOAP body element. To support backward compatibility with UDDI Version 1.0, the SOAPAction header is still permitted to be an empty string.
New Canonical tModels Added
UDDI Version 1.0 established a convention to describe certain UDDI-specific, core tModels as canonical tModels. This set of canonical tModels described various technical specifications used in UDDI itself, including:
Version 2.0 augmented the core UDDI API tModels by adding version-specific tModels for the updated Inquiry, Publication, and taxonomy maintenance APIs:
The uddi-org:types tModel was extended to include two new types. First, a relationship type was added to support the publication assertions model of representing relationships between businessEntity entries. Second, an unvalidatable type was added to model Version 2.0 to categorize tModels representing third party taxonomies that are not externally validated.
The uddi-org:relationships canonical tModel was also added to support the publication assertions feature which is new in UDDI Version 2.0. This tModel is, of course, categorized in the uddi-org:types categorization under the relationship type category. The use of this tModel to support publication assertions is described in the section "Modeling Relationships between businessEntity Entries."
Replication Specification Published
Public description of the replication mechanism between operator nodes in the UDDI Business Registry appeared for the first time with the documentation set for UDDI Version 2.0. This specification is available at www.uddi.org.
Details of the mechanism used to share changes in UDDI entries between the operator nodes are interesting, but not of immediate concern to most UDDI users. This level of detail is, of course, very important to any organization building an implementation of UDDI that would be used as an operator node within the UDDI Business Registry.
This information might also be important for an organization considering using existing UDDI implementations to set up a private federation of UDDI registries within an organization. Large organizations, such as WeMakeIt Inc., might consider creating a private UDDI Business Registry. WeMakeIt Inc. could deploy a UDDI registry for each major division, or separate business unit. The replication mechanism could be used to keep Web service descriptions properly up-to-date between all registries within WeMakeIt Inc. As it turns out, WeMakeIt Inc. chose to implement a federation of private UDDI registries without the replication mechanism. The operating units felt that the volume of changes did not warrant the extra complication of setting up the replication mechanism. Besides, more targeted facilities, such as copy/paste and publish/subscribe, allowed each operating unit more fine grained control on which updates were communicated to other UDDI registries within WeMakeIt Inc.
Clearly, SkatesTown is too small an organization to consider hosting more than one private UDDI implementation, let alone building a private replication-based federation of UDDI registries.
Operators Manual Published
Also new in the UDDI Version 2.0 documentation set is a set of details outlining required behavior of operator nodes within the UDDI Business Registry. This specification is also available at www.uddi.org. The operators manual is important to WeMakeIt Inc. Although WeMakeIt Inc. has no intention of becoming an operator within the UDDI Business Registry, it does need to make sure its validate_values service is properly registered with the UDDI Business Registry, and, therefore, available to UDDI Business Registry nodes (and private UDDI registries) to validate the use of WeMakeIt Inc.'s product code taxonomy.