· 2003-10-14 · 1/405 uddi spec tc 1 2 uddi version 3.0.1 3 uddi spec technical committee...

1/405

UDDI Spec TC 1

UDDI Version 3.0.1 2

UDDI Spec Technical Committee Specification, 3

Dated 20031014 4

5

Document identifier: 6 uddi_v3 7

Current version: 8 http://uddi.org/pubs/uddi-v3.0.1-20031014.htm 9

Latest version: 10 http://uddi.org/pubs/uddi_v3.htm 11

Previous version: 12 http://uddi.org/pubs/uddi-v3.00-published-20020719.htm 13

Editors: 14 Tom Bellwood, IBM 15 Luc Clément, Microsoft 16 Claus von Riegen, SAP 17

Contributors: 18 Bob Atkinson, Microsoft 19 Tom Bellwood, IBM 20 Maud Cahuzac, France Telecom 21 Luc Clément, Microsoft 22 John Colgrave, IBM 23 Ugo Corda, SeeBeyond Technology 24 Alexandru Czimbor, OSS Nokalva 25 Matthew J. Dovey, Individual Member 26 Daniel Feygin, UnitSpace 27 Shishir Garg, France Telecom 28 Rajul Gupta, OSS Nokalva 29 Andrew Hately, IBM 30 Brad Henry, Individual Member 31 Aikichi Kawai, NTT USA 32 Paul Macias, LMI 33 Anne Thomas Manes, Individual Member 34 Claus von Riegen, SAP 35 Tony Rogers, Computer Associates 36 Alok Srivastava, Oracle 37 Paul Thorpe, OSS Nokalva 38 Alessandro Triglia, OSS Nokalva 39

�� UDDI Version 3.0¶

UDDI Spec Technical Committee Specification, 19 July 2002¶

�� 0-published-20020719

�� Authors:

�� David Ehnebuske, IBM¶

Andrew Hately, IBM¶Maryann Hondo, IBM¶Yin Leng Husband, HP¶Karsten Januszewski, Microsoft¶Sam Lee, Oracle¶Barbara McKee, IBM¶Joel Munter, Intel¶��

Selim Aissi, Intel¶��

Tom Gaskins, HP¶Tom Glover, IBM¶Dan Guinan, VeriSign¶Christian Hansen, SAP¶Thomas Hardjono, VeriSign¶Richard Harrah, HP¶Keisuke Kibakura, Fujitsu¶Seán MacRoibeáird, Sun¶Ed Mooney, Sun¶Andrew Nielsen, HP¶Shigeru Shimada, IBM¶Christian R. Thomas, Intel¶Johannes Viegener, SAP¶Acknowledgements:¶Sharon Boeyen, Entrust¶Fennivel Chai, DealEasy¶Paul Denning, MITRE¶Matthew J. Dovey, Oxford University¶��

Jeffrey Kenyon, Qwest¶Anne Thomas Manes, Systinet¶Takayuki Nakao, NTT Communications¶Scott Wood, Cambian¶Brian Young, Boeing¶

UDDI Version 3.0 UDDI Spec Committee Specification, Dated 19 July 2002UDDI Version 3.0.1 UDDI Spec Technical Committee Specification, Dated 20031014

2/405

Max Voskob, Individual Member 40 George Zagelow, IBM 41

42

Abstract: 43 The UDDI Version 3.0.1 Specification describes the Web services, data structures and 44 behaviors of all instances of a UDDI registry. 45

Status: 46 This specification has attained the status of Committee Specification. This document is 47 updated periodically on no particular schedule. 48 49 Committee members should send comments on this Committee Specification to the uddi-50 [email protected] list. Others should subscribe to and send comments to the 51 [email protected] list. To subscribe, send an email message to 52 [email protected] with the word "subscribe" as the body 53 of the message. 54 55 For information on whether any intellectual property claims have been disclosed that may 56 be essential to implementing this Committee Specification, and any offers of licensing 57 terms, please refer to the Intellectual Property Rights section of the UDDI Spec TC web 58 page (http://www.oasis-open.org/committees/uddi-spec/ipr.php). 59

60

Copyrights: 61 Copyright © 2001-2002 by Accenture, Ariba, Inc., Commerce One, Inc., Fujitsu Limited, 62 Hewlett-Packard Company, i2 Technologies, Inc., Intel Corporation, International 63 Business Machines Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, 64 Sun Microsystems, Inc., and VeriSign, Inc. All Rights Reserved. 65 66 Copyright © OASIS Open 2002-2003. All Rights Reserved. 67

68

�� http://www.oasis-

open.org/committees/uddi-spec/


3/405

69

Content 70

71


4/405

72

1 Introduction 73

Web services are meaningful only if potential users may find information sufficient to permit 74 their execution. The focus of Universal Description Discovery & Integration (UDDI) is the 75 definition of a set of services supporting the description and discovery of (1) businesses, 76 organizations, and other Web services providers, (2) the Web services they make available, 77 and (3) the technical interfaces which may be used to access those services. Based on a 78 common set of industry standards, including HTTP, XML, XML Schema, and SOAP, UDDI 79 provides an interoperable, foundational infrastructure for a Web services-based software 80 environment for both publicly available services and services only exposed internally within an 81 organization. 82

1.1 About this specification 83

This document describes the Web services and behaviors of all instances of a UDDI registry. 84 Normative material is provided in the numbered chapters of the document and in the XML 85 schemas which accompany this document. Supplementary non-normative commentary, 86 explanations, and guidance may be found in the lettered appendices. In particular, first-time 87 readers of this specification may find Appendix L Glossary of Terms useful. 88

This specification contains examples of XML data and URIs used in interacting with UDDI. To 89 illustrate them as completely as possible, the examples include the names of individuals, 90 companies, brands, and products. All of these names are fictitious and any similarity to the 91 names and addresses used by an actual business enterprise is entirely coincidental. 92

The primary audiences for this document are: 93

• Programmers who want to write software that will directly interact with a UDDI registry. 94

• Programmers who want to implement a UDDI node 95

• Programmers who want to implement any of the Web services UDDI Nodes invoke 96

All implementations of the UDDI specification must provide support for the required Web 97 services described here as well as the behaviors defined. 98

1.2 Language & Terms 99

RFC 2119: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 100 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 101 document, are to be interpreted as described in RFC 2119 found at 102 http://www.faqs.org/rfcs/rfc2119.html. 103

MANDATORY, RECOMMENDED, and OPTIONAL: Beginning with this third version, the 104 UDDI specification renders explicit which components of the UDDI specification are 105 MANDATORY and MUST be implemented, which are RECOMMENDED and SHOULD be 106 implemented, and which are OPTIONAL and MAY be implemented. It is important to note that 107 OPTIONAL and RECOMMENDED elements of the specification, if they are implemented, 108 MUST be implemented in the manner documented in this specification. 109

Separation of operational issues: In this third version of the UDDI Specification the trend 110 begun in Version 2 to separate normative behavior from UDDI registry and node policy is 111 completed. For instance, authorization has been called out as a policy decision. A similar 112 separation of normative behavior and registry content has also been carried out. For example, 113 the requirement to support specific category systems has been removed from this version of 114 the specification. 115


5/405

1.3 Diagrams Used in this document 116

1.3.1 Attributes and elements 117

UDDI uses the XML Schema Language (See http://www.w3.org/TR/xmlschema-0/, 118 http://www.w3.org/TR/xmlschema-1/ and http://www.w3.org/TR/xmlschema-2/) and its 119 terminology, such as “sequence” and “choice” to formally describe its data structures. The 120 diagrams1 used in this specification show the structure and cardinality of the elements used in 121 these structures. Attributes are not shown in the diagrams, but explained in the corresponding 122 documentation. 123

1.3.2 Element structure 124

1.3.2.1 Sequence 125

126

The hexagonal symbol with the horizontal “dotted” line indicates “sequence of.” This diagram 127 says the element registeredInfo consists of elements businessInfos and tModelInfos. All three 128 elements are defined in the namespace whose prefix is “uddi”. Note that although the word 129 “sequence” is used, there is no requirement for a specific order to these elements. 130

The fact that businessInfos and tModelInfos have a box with a “+” in it at their right-hand end 131 indicates that there is more structure to them than is shown in the diagram. 132

1.3.2.2 Choice 133

134

The switch-like symbol indicates a choice. In this case, a choice between the elements 135 businessKey, fromKey, and toKey. 136

None of these has more structure than is given in the diagram (there are no boxes with a “+” in 137 them at their right-hand ends). That they are adorned with a small series of horizontal lines in 138 their upper left corners indicates that each is a non-empty element. 139

1.3.3 Cardinality 140

1.3.3.1 Optional, one 141

142 1 Diagrams provided in this specification were produced by the ©XML Spy editor, Altova GmbH and Altova, Inc.

�� the sequence of

�� followed by


6/405

The dashed line indicates that the element listDescription is optional. The fact that it is not 143 adorned with some other cardinality indicator (see below) says there can be at most one of 144 them. 145

1.3.3.2 Mandatory, one 146

147

There must be exactly one of the element businessKey. 148

1.3.3.3 Optional, repeating 149

150

The element assertionStatusItem is optional and may appear an indeterminate number of 151 times. The number of times it may appear is given by the adornment “0..∞”, a cardinality 152 indicator meaning “zero to infinity”. Other numbers may appear to indicate different 153 cardinalities. 154

1.3.3.4 Mandatory, repeating 155

156

The element addressLine must appear at least once and may appear an indeterminate 157 number of times. 158

1.4 Related Documents 159

1.4.1 Translations of the UDDI Specification 160

Translations of the UDDI Specifications may be produced, by the UDDI specification technical 161 committee of OASIS, or by others. In all instances the English version of the document is the 162 official version; in case of discrepancy the English version shall be the definitive source. 163

1.4.2 Best Practices and Technical Notes 164

To provide guidance on the use of UDDI registries, the UDDI specification technical committee 165 of OASIS from time to time publishes “Best Practices” and “Technical Notes”. The contents of 166 these documents are not a part of this specification. See http://uddi.org/bestpractices.html for 167 further information on Best Practices and http://uddi.org/technotes.html for information on 168 Technical Notes. 169

1.5 Base UDDI Architecture 170

1.5.1 UDDI Data 171

This specification presents an information model composed of instances of persistent data 172 structures called entities. Entities are expressed in XML and are persistently stored by UDDI 173

�� .org

�� .org


7/405

nodes. Each entity has the type of its outer-most XML element. A UDDI information model is 174 composed of instances of the following entity types: 175

• businessEntity: Describes a business or other organization that typically provides Web 176 services. 177

• businessService: Describes a collection of related Web services offered by an 178 organization described by a businessEntity. 179

• bindingTemplate: Describes the technical information necessary to use a particular 180 Web service. 181

• tModel: Describes a “technical model” representing a reusable concept, such as a 182 Web service type, a protocol used by Web services, or a category system. 183

• publisherAssertion: Describes, in the view of one businessEntity, the relationship that 184 the businessEntity has with another businessEntity.2 185

• subscription: Describes a standing request to keep track of changes to the entities 186 described by the subscription. 187

1.5.2 UDDI Services and API Sets 188

This specification presents APIs that standardize behavior and communication with and 189 between implementations of UDDI for the purposes of manipulating UDDI data stored within 190 those implementations. The API’s are grouped into the following API sets. 191

1.5.2.1 Node API Sets 192

• UDDI Inquiry 193

• UDDI Publication 194

• UDDI Security 195

• UDDI Custody Transfer 196

• UDDI Subscription 197

• UDDI Replication 198

1.5.2.2 Client API Sets 199

• UDDI Subscription Listener 200

• UDDI Value Set 201

1.5.3 UDDI Nodes 202

A set of Web services supporting at least one of the Node API sets is referred to as a UDDI 203 node. A UDDI node has these defining characteristics: 204

1. A UDDI node supports interaction with UDDI data through one or more UDDI API sets 205

2. A UDDI node is a member of exactly one UDDI registry. 206

3. A UDDI node conceptually has access to and manipulates a complete logical copy of 207 the UDDI data managed by the registry of which it is a part. Moreover, it is this data 208

2 If identical publisherAssertions are made from the views of both businessEntities, a “relationship” is formed between them. See

Section 3.7 publisherAssertion.


8/405

which is manipulated by any query and publish APIs supported by the node. Typically, 209 UDDI replication occurs between UDDI nodes which reside on different systems in 210 order to manifest this logical copy in the node. 211

The physical realization of a UDDI node is not mandated by this specification. 212

1.5.4 UDDI Registries 213

One or more UDDI nodes may be combined to form a UDDI Registry. The nodes in a UDDI 214 registry collectively manage a particular set of UDDI data. This data is distinguished by the 215 visible behavior associated with the entities contained in it. 216

A UDDI Registry has these defining characteristics. 217

1. A registry is comprised of one or more UDDI nodes. 218

2. The nodes of a registry collectively manage a well-defined set of UDDI data. Typically, 219 this is supported by the use of UDDI replication between the nodes in the registry 220 which reside on different systems. 221

3. A registry MUST make a policy decision for each policy decision point. It MAY choose 222 to delegate policy decisions to nodes. See Chapter 9 Policy for details. 223

The physical realization of a UDDI Registry is not mandated by this specification. 224

1.5.5 Affiliations of Registries 225

The entities businessEntity, businessService, bindingTemplate, tModel form the core data 226 structures of UDDI. Within a registry, each instance of the core data structures is uniquely 227 identified by a UDDI key. By choosing appropriate policies, multiple registries may form a 228 group, known as an “affiliation”, whose purpose is to permit controlled copying of core data 229 structures among them. A UDDI registry affiliation has these defining characteristics. 230

1. The registries share a common namespace for entity keys. 231

2. The registries have compatible policies for assigning keys to entities. 232

3. The policies of the registries permit publishers to assign keys 233

1.5.6 Person, Publisher and Owner 234

When publishing information in a UDDI registry the information becomes part of the published 235 content of the registry. During publication of an item of UDDI information, a relationship is 236 established between the publisher, the item published and the node at which the publish 237 operation takes place. The glossary contains definitions of the terms person, publisher and 238 owner. 239

This specification defines a relationship between these three terms and leaves the binding of 240 these abstract relationships to be determined by the policies of the registry and its nodes at 241 implementation. It is important to review Chapter 9 on policy to understand how different 242 implementations can define different policies but remain consistent with the UDDI specification. 243

1.5.7 Transfer of ownership 244

As the owner of datum, a person can initiate the transfer of ownership of the datum to another 245 publisher within the registry. Section 5.4 Custody and Ownership Transfer API describes the 246 transfer of ownership within UDDI. 247

1.5.8 Data Custody 248

Generally speaking, data is replicated between nodes of a UDDI registry using a replication 249 protocol. Registries that choose to use the replication protocol defined in Section 7.4 250


9/405

Replication API Set MUST enforce the following data custody policy. (Registries which choose 251 otherwise incur no such requirement.) 252

Each node has custody of a portion of the aggregate data managed by the registry of which it 253 is a part. Each datum is by definition in the custody of exactly one such node. A datum in this 254 context can be a businessEntity, a businessService, a bindingTemplate, a tModel, or a 255 publisherAssertion. Changes to a datum in the registry MUST originate at the node which is 256 the custodian of the datum. The registry defines the policy for data custody and, if allowed, the 257 custodian node for a given datum can be changed; such custody transfer processes are 258 discussed in Section 5.4 Custody and Ownership Transfer API. 259

1.6 Representing Information within UDDI 260

For Web services to be meaningful there is a need to provide information about them beyond 261 the technical specifications of the service itself. Central to UDDI’s purpose is the 262 representation of data and metadata about Web services. A UDDI registry, either for use in 263 the public domain or behind the firewall, offers a standard mechanism to classify, catalog and 264 manage Web services, so that they can be discovered and consumed. Whether for the 265 purpose of electronic commerce or alternate purposes, businesses and providers can use 266 UDDI to represent information about Web services in a standard way such that queries can 267 then be issued to a UDDI Registry – at design-time or run-time – that address the following 268 scenarios: 269

• Find Web services implementations that are based on a common abstract interface 270 definition. 271

• Find Web services providers that are classified according to a known classification 272 scheme or identifier system. 273

• Determine the security and transport protocols supported by a given Web service. 274

• Issue a search for services based on a general keyword. 275

• Cache the technical information about a Web service and then update that information 276 at run-time. 277

These scenarios and many more are enabled by the combination of the UDDI information 278 model and the UDDI API set. Because the information model is extremely normalized, it can 279 accommodate many different types of models, scenarios and technologies. The specification 280 has been written to be flexible so that it can absorb a diverse set of services and not be tied to 281 any one particular technology. While a UDDI Node exposes its information as an XML Web 282 service, it does not restrict the technologies of the services about which it stores information or 283 the ways in which that information is decorated with metadata. 284

1.6.1 Representing Businesses and Providers with “ businessEntity” 285

One top-level data structure within UDDI is the businessEntity structure, used to represent 286 businesses and providers within UDDI. It contains descriptive information about the business 287 or provider and about the services it offers. This would include information such as names and 288 descriptions in multiple languages, contact information and classification information. Service 289 descriptions and technical information are expressed within a businessEntity by contained 290 businessService and bindingTemplate structures. 291

While the name of XML entity itself has the word business embedded in it, the structure can be 292 used to model more than simply a “business” in its common usage. As the top-level entity, 293 businessEntity can be used to model any “parent” service provider, such as a department, an 294 application or even a server. Depending on the context of the data in the entire registry, the 295 appropriate modeling decisions to represent different service providers can vary. 296


10/405

1.6.2 Representing Services with “ businessService” 297

Each businessService structure represents a logical grouping of Web services. At the service 298 level, there is still no technical information provided about those services; rather, this structure 299 allows the ability to assemble a set of services under a common rubric. Each businessService 300 is the logical child of a single businessEntity. Each businessService contains descriptive 301 information – again, names, descriptions and classification information -- outlining the purpose 302 of the individual Web services found within it. For example, a businessService structure could 303 contain a set of Purchase Order Web services (submission, confirmation and notification) that 304 are provided by a business. 305

Similar to the businessEntity structure, the term business is embedded within the name 306 businessService. However, a suite of services need not be tied to a business per se, but can 307 rather be associated with a provider of services, given a modeling scenario that is not based 308 on a business use case. 309

1.6.3 Representing Web services with “ bindingTemplate” 310

Each bindingTemplate structure represents an individual Web service. In contrast with the 311 businessService and businessEntity structures, which are oriented toward auxiliary information 312 about providers and services, a bindingTemplate provides the technical information needed by 313 applications to bind and interact with the Web service being described. It must contain either 314 the access point for a given service or an indirection mechanism that will lead one to the 315 access point. 316

Each binding Template is the child of a single businessService. The containing parents, a 317 bindingTemplate can be decorated with metadata that enable the discovery of that 318 bindingTemplate, given a set of parameters and criteria. 319

1.6.4 Technical Models (tModels) 320

Technical Models, or tModels for short, are used in UDDI to represent unique concepts or 321 constructs. They provide a structure that allows re-use and, thus, standardization within a 322 software framework. The UDDI information model is based on this notion of shared 323 specifications and uses tModels to engender this behavior. For this reason, tModels exist 324 outside the parent-child containment relationships between the businessEntity, 325 businessService and bindingTemplate structures. 326

Each distinct specification, transport, protocol or namespace is represented by a tModel. 327 Examples of tModels that enable the interoperability of Web services include those based on 328 Web Service Description Language (WSDL), XML Schema Definition (XSD), and other 329 documents that outline and specify the contract and behavior – i.e., the interface – that a Web 330 Service may choose to comply with. To describe a Web service that conforms to a particular 331 set of specifications, transports, and protocols, references to the tModels that represent these 332 concepts are placed in the bindingTemplate. In such a way, tModels can be re-used by 333 multiple bindingTemplates. The bindingTemplates that refer to precisely the same set of 334 tModels are said to have the same “technical fingerprint” and are of the same type. In this 335 way, tModels can be used to promote the interoperability between software systems. 336

It is important to note that such technical documents and the supporting documentation 337 necessary to a developer using Web services are not stored within the UDDI registry itself. A 338 UDDI tModel simply contains the addresses where those documents can be found. A tModel, 339 however, contains more than just URLs; it also stores metadata about the technical 340 documents and an entity key that identifies that tModel. 341

Because tModels can represent any unique concept or construct, they have usage beyond the 342 software interoperability scenario described above. They can also be used to represent other 343 concepts within the UDDI information model, such that metadata concepts are reused 344


11/405

throughout the model. For example, tModels are used for the following other purposes within 345 UDDI: 346

• Transport and protocol definitions such as HTTP and SMTP. (See below and also 347 Section 11.1.1 uddi-org:types for a description.) 348

• Value sets including identifier systems, categorization systems and namespaces. 349 (See Section 3.3 businessEntity Structure and Appendix F Using Categorization for a 350 description of how value sets are used in UDDI.) 351

• Structured categorizations using multiple value sets called “categorization groups.” 352

• Postal address formats. (See Section 3.3.2.7 address and Appendix B 353 Internationalization for a description.) 354

• Find qualifiers used to modify the behavior of the UDDI find_xx APIs. (See Section 355 5.1.4 findQualifiers for a description.) 356

• Use type attributes that specify the kind of resource being referred to by a URI 357 reference. (See, for example, Section 3.5.2.1 accessPoint.) 358

The use of tModels is essential to how UDDI represents data and metadata. The UDDI 359 specification defines a set of common tModels that can be used canonically to model 360 information within UDDI. If a concept that is required to model a particular scenario does not 361 exist in a registry, a user should introduce that concept by saving a tModel containing the URL 362 of the relevant overview documents. 363

1.6.5 Taxonomic Classification of the UDDI entities 364

Data is worthless if it is lost within a mass of other data and cannot be distinguished or 365 discovered. If a client of UDDI cannot effectively find information within a registry, the purpose 366 of UDDI is considerably compromised. Providing the structure and modeling tools to address 367 this problem is at the heart of UDDI’s design. The reification of data within UDDI is core to its 368 mission of description, discovery and integration. It achieves this by several means. 369

First, it allows users to define multiple taxonomies that can be used in UDDI. In such a way, 370 multiple classification schemes can be overlaid on a single UDDI entity. This capability allows 371 organizations to extend the set of such systems UDDI registries support. One is not tied to a 372 single system, but can rather employ several different classification systems simultaneously. 373

Second, UDDI allows such classification systems to be used on every entity within the 374 information model. It defines a consistent way for a publisher to add any number of 375 classifications to their registrations. It is important that taxonomies are used when publishing 376 data into a UDDI registry. Whether standard codes are used (such as the United Nations 377 Standard Products and Services Code System (UNSPSC)) or a new taxonomy is created and 378 distributed, it is imperative that UDDI data -- businessEntity, businessService, bindingTemplate 379 and tModel elements alike – are attributed with metadata. 380

Third, the UDDI Inquiry API set provides the ability to issue precise searches based on the 381 different classification schemes. A range of queries that perform different joins across the 382 UDDI entities can be generated, such that data can be discovered and accessed. Also, 383 registering information such as industry codes, product codes, geography codes and business 384 identification codes allows other search services to use this classification information as a 385 starting point to provide added-value indexing and classification. 386

Classification and identification systems, taken together, are called “value sets” in UDDI. Value 387 sets may be “checked” or “unchecked”. Both checked and unchecked value sets are used for 388 categorization and identification. The difference between them is that whenever a checked 389 value set is used, the use is inspected to see that it conforms to the requirements of the value 390 set. Unchecked value sets do not have their uses checked. 391


12/405

1.7 Introduction to Security 392

The security model for a UDDI registry can be characterized by the collection of registry and 393 node policies and the implementation of these policies by a UDDI node. This specification 394 details a list of policies that MUST be defined by registries and nodes in Chapter 9 Policy. This 395 specification also describes how policies SHOULD be modeled. 396

Several optional and extensible mechanisms for implementing nodes, registries and clients 397 with a particular security model are described in this specification. The principal areas of 398 security policies and mechanisms in the UDDI specification are related to data management, 399 user identification, user authentication, user authorization, confidentiality of messages and 400 integrity of data. 401

In order to authorize or restrict access to data in a UDDI registry, an implementation of a UDDI 402 node MAY be integrated with one or more identification systems. An implementation specific 403 policy MUST identify the identification system(s) used. Integration of UDDI APIs and data with 404 an identification system MAY be implemented through the authentication and authorization 405 APIs to provide access control as described in Section 5.3 Security Policy API Set. Other 406 authentication and authorization mechanisms and policies are represented in UDDI through 407 use of tModels to describe the Web services of a UDDI node. 408

UDDI also supports XML Digital Signatures on UDDI data to enable inquirers to verify the 409 integrity of the data with respect to the publisher. 410

The security model for a registry and node can be extended beyond the mechanisms 411 described in this specification and represented by modeling the UDDI Web services and 412 through node and registry policy documentation. 413

1.8 Introduction to Internationalization 414

As part of its aim of providing a registry for universal description, discovery and integration, the 415 UDDI specification includes support for internationalization features. These features fall into 416 two broad groups: 417

• Support for multi-regional businesses, organization, and other Web service providers 418 to: 419

o Describe their operations across international or inter-region units 420

o Specify the timezone of each operation’s contacts 421

• Support for internationalization of UDDI data and services such as: 422

o XML and the Unicode Character Set 423

o Postal address 424

o Use of multiple languages or multiple scripts of the same language 425

o Mechanisms to specify additional language-specific sorting order 426

o Consistent search results independent of language of information being 427 searched 428

1.8.1 Multi-regional businesses 429

The UDDI specification provides features that enable Web service providers to describe the 430 location of different aspects of the business, e.g. where it offers its products and services, 431 where it is located, or even where it has stores, warehouses, or other branches. 432

�� principle


13/405

1.8.2 XML and Unicode Character Set 433

The UDDI specification uses XML and the Unicode Character Set (up to and including version 434 3.0 of the Unicode Standard). By basing the programming interface on XML, multilingual 435 handling capability is automatically achieved as XML uses the Universal Character Set (UCS) 436 defined by both the Unicode Consortium and ISO 10646. The UCS is a character set that 437 encompasses most of the language scripts used in computing. 438

1.8.3 Standardized Postal Address 439

In UDDI, an <address> element consists of a list of <addressLine> elements. While this is 440 useful for publishing addresses in a UDDI registry or simply printing them on paper, the 441 address’ logical structure and meaning is not explicit. 442

Moreover, different geographical regions specify their postal addresses differently 443

• By having different subelements (e.g. subdivisions, suburbs, lots, building 444 identifications, floor numbers) 445

• By grouping/sequencing the subelements. 446

To overcome the first concern, the UDDI specification exposes an address’ structure and 447 meaning by the use of attributes within each <addressLine> element to specify that line’s 448 structure and meaning. 449

To overcome the second concern, the UDDI Business Registry has specified a canonical 450 postal address structure with common address subelements (e.g. states, cities). This 451 canonical address structure describes address data via name/code pairs, enabling each 452 common address subelement to be identified by name or code3. 453

1.8.4 Use of Multi-languages and Multi-scripts 454

Multinational businesses or businesses involved in international trading at times require the 455 use of possibly several languages or multiple scripts of the same language for describing their 456 business. The UDDI specification supports this requirement through two means, first by 457 specifying the use of XML with its underlying Unicode representation, and second by 458 permitting the use of the xml:lang attribute for various items such as names, addresses, and 459 document descriptions to designate the language in which they are expressed. Further 460 information on this may be found in Section 3.3.2.3 name. 461

1.8.5 Adding Language-specific Sort Orders 462

The Universal Character Set supported through XML consists of characters of most of the 463 language scripts of the world. Each character has a distinct collation weight within the 464 language for use in the collation sequencing process. Handling the sort orders of different 465 language scripts, i.e. the assignment of collation weight values, can be very different, with the 466 complexity of handling dependent on whether the script is alphabetic, syllabic, or ideographic. 467 Some examples of sort order handling issues are: 468

• Where multiple languages share the same alphabetic script, it is possible for a 469 common character to have different collation weights when used in the different 470 languages. 471

• Ideographic languages have large character repertoires with multiple collation 472 sequencing possibilities depending on whether phonetic or stroke-order sequencing is 473 chosen. 474

3 See Section 3.3.3.65 address and Appendix ED Internationalization.

�� <#>Contact’s Timezone¶

In order to support human communication, the UDDI specification includes contact information such as phone numbers. The provision of time zone information helps in deriving the contact’s effective contactable hours. Businesses may indicate the timezone within which each contact operates by specifying it in the contact’s address.¶


14/405

• Where languages are bicameral (having upper and lower cases), collation sequencing 475 could depend on whether case-sensitive or insensitive sorting is required. 476 Conversely, specifying case-sensitive sort for non-bicameral languages is 477 meaningless. 478

• Where the language inherently has an obvious collation sequence, fastest sorting is 479 achieved by using binary sort. 480

The UDDI specification allows the collation sequence of results returned by the APIs to be 481 specified via qualifiers. The specification also supports a mechanism to specify additional 482 language-specific collation sequences for collating returned results. 483

1.8.6 Consistent Internationalized Search 484

The existence within the Universal Character Set of combining characters and of multiple 485 representations for what users perceive as the same character results in different (by content 486 and sometimes by length as well) XML strings that are the same when rendered visually. 487 These different XML strings, though different in their encoded binary form, should produce 488 positive match results during any search operation. This requirement makes it necessary to 489 define a canonical XML string representation. The canonical representation chosen is that of 490 the Unicode Normalization Form C4. For further details, see Section 4.6.1.1 Normalization and 491 Canonicalization. 492

493

494

4 Specified in Unicode Technical Standard, Technical Report #15 available at http://www.unicode.org/unicode/reports/tr15/


15/405

495

2 UDDI Schemas 496

UDDI uses the XML Schema Language (See http://www.w3.org/TR/xmlschema-0/, 497 http://www.w3.org/TR/xmlschema-1/ and http://www.w3.org/TR/xmlschema-2/) to formally 498 describe its data structures. A UDDI node MUST use an XML processor that meets the 499 definition of a minimally conforming schema aware processor as defined in XML Schema Part 500 1: Structures. The XML processor must further understand the references to schema 501 components (see Section 4.2.3 of XML Schema Part 1: Structures) across namespaces which 502 result from the import statements in the UDDI schemas. The complete definition comprises 9 503 schema files, as described below. 504

505

UDDI API Schema

Schema file http://uddi.org/schema/uddi_v3.xsd

Target namespace urn:uddi-org:api_v3

Referenced/imported namespaces

http://www.w3.org/2001/XMLSchema http://www.w3.org/2000/09/xmldsig# http://www.w3.org/XML/1998/namespace

Description This is the main UDDI Schema file. It defines all of the common UDDI data types and elements as well as those used in the Inquiry, Publishing, and Security API sets.

506

UDDI Custody Schema

Schema file http://uddi.org/schema/uddi_v3custody.xsd

Target namespace urn:uddi-org:custody_v3


urn:uddi-org:api_v3 urn:uddi-org:repl_v3 http://www.w3.org/2001/XMLSchema

Description This is the schema for the UDDI Custody and Ownership Transfer API set.

507

UDDI Subscription Schema

Schema file http://uddi.org/schema/uddi_v3subscription.xsd

Target namespace urn:uddi-org:sub_v3


urn:uddi-org:api_v3 http://www.w3.org/2001/XMLSchema

Description This is the schema for the UDDI Subscription API set.

508


16/405

509

UDDI Subscription Listener Schema

Schema file http://uddi.org/schema/uddi_v3subscriptionListener.xsd

Target namespace urn:uddi-org:subr_v3


urn:uddi-org:api_v3 urn:uddi-org:sub_v3 http://www.w3.org/2001/XMLSchema

Description This is the schema for the UDDI Subscription Listener API set.

510

UDDI Replication Schema

Schema file http://uddi.org/schema/uddi_v3replication.xsd

Target namespace urn:uddi-org:repl_v3


urn:uddi-org:api_v3 http://www.w3.org/2000/09/xmldsig# http://www.w3.org/2001/XMLSchema

Description This is the schema for the UDDI Replication API set.

511

UDDI Value Set Validation Schema

Schema file http://uddi.org/schema/uddi_v3valueset.xsd

Target namespace urn:uddi-org:vs_v3



Description This is the schema for the UDDI Value Set Validation API set.

512

UDDI Value Set Caching

Schema file http://uddi.org/schema/uddi_v3valuesetcaching.xsd

Target namespace urn:uddi-org:vscache_v3



Description This is the schema for the UDDI Value Set Data API set.


17/405

513

UDDI Policy

Schema file http://uddi.org/schema/uddi_v3policy.xsd

Target namespace urn:uddi-org:policy_v3


http://www.w3.org/2001/XMLSchema http://www.w3.org/2000/09/xmldsig# http://www.w3.org/XML/1998/namespace

Description This is the schema for the UDDI Policy Document for the Policy Service.

514

UDDI Policy Instance Parameters

Schema file http://uddi.org/schema/uddi_v3policy_instanceParms.xsd

Target namespace urn:uddi-org:policy_instanceParms_v3


http://www.w3.org/2001/XMLSchema

Description This is the schema for the instance parameters that are used in modeling UDDI policies.

515

2.1 Schema versioning 516

UDDI follows the commonly encountered convention of changing the target namespace 517 whenever a specification revision changes the schema in a way that changes the set of 518 documents that is valid under the schema. In addition, UDDI changes the target namespace 519 whenever a specification revision changes in a way that changes the behavior a compliant 520 registry is permitted to display with respect to the schema, even if the set of documents that 521 are valid under the schema remains unchanged. UDDI does not change the target namespace 522 for other kinds of changes. For example, the target namespace is not changed for purely 523 editorial or formatting errata, either to the Specification or to a schema. 524

The form of the target namespace is (using ABNF notation): 525

namespace = "urn:uddi-org:" schemaName "_v" versionNumber [":" revisionNumber] 526 versionNumber = decimalInteger 527 revisionNumber = decimalInteger 528 schemaName = "api" / "custody" / "sub" / “subr” / "repl" / "vs" / “vscache” / “policy” / 529 “policy_instanceParms” 530 decimalInteger = Unsigned integer with no leading zeroes. 531

Where versionNumber is the same as the version number of UDDI of which the schema is a 532 part. E.g., for UDDI v3, versionNumber is 3. The value of revisionsNumber is the number of 533 the revision to the specification in which the schema is used. 534

When the specification is first released revisionsNumber is 0. It is incremented by 1 with each 535 released revision. 536

So, for example, namespace for the UDDI API Schema corresponding to UDDI v3 in its first 537 release is "urn:uddi-org:api_v3:0". 538

In addition, the UDDI schemas use the version attribute of the schema element to mark 539 changes to the text of the schema in the following manner. The value of the version attribute is 540 an unsigned decimal integer. When a schema is first created for a given version of UDDI its 541

�� V3


18/405

version is 0. The value of version is incremented by at least 1 each time the schema is made 542 publicly available. 543

2.2 Schema Extensibility 544

As defined in the UDDI schemas, all UDDI data structures are designed to permit UDDI node 545 implementers to extend them using the XML Schema derivation-by-extension feature. While 546 extending the UDDI schemas in this way can be a relatively straightforward process, designing 547 an extension that includes behavioral modification is likely to be a complex undertaking that 548 should be done with considerable care. See Appendix H Extensibility for more information on 549 extending UDDI. 550

2.3 Element and attribute types and lengths 551

To ease the replication of data between nodes of a registry and to facilitate sharing data 552 among the registries of an affiliation, UDDI imposes length restrictions on the types in its 553 information model. The following tables summarize all the stored elements and attributes in the 554 UDDI schemas that correspond to XML schema simpleTypes. They provide data types and, 555 for those whose length is not specified by XML, their allowed lengths. The lengths are the 556 storage length limits for information that is saved in a UDDI registry, given in Unicode 557 characters. Since these limits are imposed in the schemas, structures containing data that 558 exceeds the constraints depicted below are not valid. The lengths specified in the UDDI 559 schemas are the definitive source for type and length information. 560

2.3.1 Data structure, publication API, inquiry API and security API 561

Element/attribute Name Data Type Length

accessPoint string 4096

addressLine string 80

authInfo string 4096

bindingKey anyURI 255

businessKey anyURI 255

deleted boolean

description string 255

discoveryURL anyURI 4096

email string 255

fromKey anyURI 255

instanceParms string 8192

keyName string 255

keyValue string 255

name string 255

operator string 255

overviewURL anyURI 4096

personName string 255

phone string 50

serviceKey anyURI 255


19/405


sortCode string 10

tModelKey anyURI 255

toKey anyURI 255

useType string 255

completionStatus NMTOKEN 32

xml:lang string 26

562

2.3.2 Subscription API 563


brief boolean

endPoint dateTime

notificationInterval duration

exipresAfter dateTime

startPoint dateTime

maxEntities integer

subscriptionKey anyURI 255

564

2.3.3 Replication API 565


acknowledgementRequested boolean

nodeId anyURI 255

notifyingNode anyURI 255

originatingUSN integer

operatorNodeID anyURI 255

requestingNode anyURI 255

responseLimitCount integer

566

567

�� i


20/405

568

569

3 UDDI Registry Data Structures 570

3.1 Data structure overview 571

This chapter describes the semantics of the data structures that are specified by the UDDI API 572 Schema. Refinements that are specific to individual APIs are described in Chapter 5 UDDI 573 Programmers API’s. 574

As described in Section 1.6 Representing Information within UDDI, the information that makes 575 up a UDDI registry consists of instances of four core data structure types, the businessEntity, 576 the businessService, the bindingTemplate and the tModel, together with instances of additional 577 data structure types defined in the UDDI API Schema. 578

The four core types and their relationships are shown in a simplified diagram in Figure 1 and 579 are explained in detail in this chapter. 580

581

582

583

Figure 1 - UDDI core data structures 584

The schema also defines a number of request and response structures, each of which contain 585 the core structures, references to the core structures, or summary versions of them; see 586 Chapter 5 UDDI Programmers API’s for details. 587

3.2 Design Principles 588

Each of the core data structure types is used to express specific types of data, arranged in the 589 relationship shown in Figure 1. A particular instance of an individual fact or set of related facts 590 is expressed using XML according to the definition of these core types. For instance, two 591 separate businesses may publish information in a UDDI registry about Web services they 592 offer. Information describing each business and its Web services all exists as separate 593 instances of the core data structures stored within the UDDI registry. 594


21/405

3.2.1 Keys as unique identifiers 595

Instances of many data structures in UDDI, including all of the core data structures are kept 596 separately, and are accessed individually by way of unique identifiers called keys. An instance 597 in the registry gets its keys at the time it is first published. Publishers may assign keys; if they 598 don’t, the UDDI node MUST assign them. See Section 4.4 About uddiKeys. 599

3.2.2 Containment and references 600

The core data structures are sensitive to the containment relationships found in the UDDI API 601 schema and shown in Figure 1. The businessEntity structure contains one or more distinct 602 businessService structures. Similarly, individual businessService structures contain specific 603 instances of bindingTemplate structures. 604

It is important to note that no single instance of an entity is ever “contained” by more than one 605 containing entity. This means, for example, that only one specific businessEntity structure 606 (identified by its unique key value) will ever contain a specific instance of a businessService 607 structure (also identified by its own unique key). 608

References, on the other hand, operate differently. We can see an example of this in Figure 1 609 where the bindingTemplate entities refer to instances of tModel entities. References to a given 610 entity can occur multiple times, as needed. 611

Determining what is a reference and what is the key for a specific entity is straightforward. 612 Each kind of keyed entity has an attribute whose type is a corresponding type of key. For 613 example, businessEntity has a businessKey attribute and a businessService has a serviceKey 614 attribute. The value of this attribute is the entity’s key. All other keys are references or 615 containment relationships. Taking the bindingTemplate as an example, the tModelKey that 616 occurs in its inner structure is a reference and the serviceKey that occurs in the 617 bindingTemplate is a containment relationship. 618

3.2.3 Collections 619

Many elements in the UDDI API Schema may occur multiple times. Those elements that do 620 not have a complex inner structure, for example, name and description, are provided in a list. 621 Elements that do have a more complex inner structure are usually grouped in their own 622 container element. For example, the contacts structure is a container where one or more 623 contact structures reside. 624

3.2.4 Optional attributes 625

In the data structure elements of the UDDI API Schema, there are many optional attributes, for 626 example, keyName and useType. Most optional attributes have defaults of empty string (“”). 627 During schema assessment, this produces a single representation for an omitted or empty 628 string in an optional attribute. Consider the following two keyedReferences: 629

<keyedRef er ence 630 t Model Key=” uddi : uddi . or g: ubr : cat egor i zat i on: i so3166” 631 keyName=” ” 632 keyVal ue=” US- CA” / > 633 <keyedRef er ence 634 t Model Key=” uddi : uddi . or g: ubr : cat egor i zat i on: i so3166” 635 keyVal ue=” US- CA” / > 636

637

Semantically speaking from the perspective of UDDI, omitted attributes are identical to empty 638 attributes. However, with respect to signing, specifically, canonicalization, omitted attributes are 639 different from empty attributes. Therefore, the digital signatures of the above two 640 keyedReferences are different, even though clients would consider the two keyedReferences 641 be identical. 642

�� ubr .

�� geo3166- 2

�� ubr .

�� geo3166- 2


22/405

The difference, from a perspective of canonicalization, puts additional burden on clients in 643 publishing entities. As a result, when applicable, the data structure elements of UDDI API 644 Schema define default values for optional attributes, so that omitted attributes are treated as 645 attributes with default value with respect to signing. 646

The exceptions are xml:lang and keyValue in addressLine. Both prohibit empty string. Hence, 647 the ambiguity discussed above is not applicable. In the case of xml:lang, empty string is not a 648 valid language code. In the case of keyValue in addressLine, the definition of keyValue 649 requires the string to have a minimal length of one. 650

3.3 businessEntity Structure 651

Each businessEntity entity contains descriptive information about a business or organization 652 and, through its contained businessService entities, information about the services that it 653 offers. From an XML standpoint, the businessEntity is the top-level data structure that holds 654 descriptive information about the business or organization it describes. Each contained 655 businessService describes a logical service offered by the business or organization. Similarly, 656 each bindingTemplate contained within a given businessService provides the technical 657 description of a Web service that belongs to the logical service that is described by the 658 businessService. 659

3.3.1 Structure diagram 660

661

Attributes 662

Name Use

businessKey optional

663

3.3.2 Documentation 664

A given instance of the businessEntity structure is uniquely identified by its businessKey. 665 When a businessEntity is published within a UDDI registry, the businessKey MUST be omitted 666


23/405

if the publisher wants the registry to generate a key. When a businessEntity is retrieved from a 667 UDDI registry, the businessKey MUST be present. 668

discoveryURLs is a list of Uniform Resource Locators (URL) that point to alternate, file based 669 service discovery mechanisms. 670

Simple textual information about the businessEntity, potentially in multiple languages, is given 671 by its name, short business description and contacts. The required, non-empty name and 672 the optional description can occur multiple times. contacts is a simple list of single contact 673 information. 674

businessServices is a list of business services provided by the businessEntity. 675

In addition to the businessKey, that uniquely identifies the businessEntity within the registry, 676 the identifierBag contains a list of other identifiers, each valid in its own identifier system. 677 Examples of identifiers are a tax identifier or D-U-N-S® number. 678

The categoryBag contains a list of business categories that each describes a specific 679 business aspect of the businessEntity. Examples of categories are industry, product category 680 or geographic region. 681

A businessEntity entity MAY be digitally signed using XML digital signatures. When a 682 businessEntity is signed, each digital signature MUST be provided by its own dsig:Signature 683 element. Appendix I Support for XML Digital Signatures covers the use of this element in 684 accordance with the XML-Signature specification. 685

3.3.2.1 discoveryURLs 686

The discoveryURLs structure is a simple container of one or more discoveryURL elements. 687

688

3.3.2.2 discoveryURL 689

A discoveryURL is a URL that points to Web addressable (via HTTP GET) discovery 690 documents. The expected return document is not defined. Rather, a framework for 691 establishing conventions is provided, and a particular convention is defined within this 692 specification. 693

Attributes 694

Name Use

useType optional

695

Each individual discoveryURL MAY be adorned with a useType attribute that designates the 696 name of the convention that the referenced document follows. A reserved convention value is 697 “businessEntity”. It is RECOMMENDED that discoveryURLs qualified with this value point to 698 XML documents of the type businessEntity, as defined in the UDDI API Schema. 699

An example of a discoveryURL, generated by a UDDI node that is accessible at 700 www.example.com and rendered by the publisher of the businessEntity that is identified by the 701 businessKey “uddi:example.com:registry:sales:53”, is: 702

<discoveryURL useType=”businessEntity”> 703 http://www.example.com?businessKey=uddi:example.com:registry:sales:53 704 </discoveryURL> 705


24/405

706 Another reserved value for discoveryURL is “homepage”. Adorning a discoveryURL with this 707 value signifies that a business’s homepage can be discovered at that URL. 708

709

3.3.2.3 name 710

A businessEntity MAY contain more than one name. Multiple names are useful, for example, 711 in order to specify both the legal name and a known abbreviation of a businessEntity, or in 712 order to support romanization (see Appendix D Internationalization). 713

Attributes 714

Name Use

xml:lang optional

715

When a name is expressed in a specific language (such as the language into which a name 716 has been romanized), it SHOULD carry the xml:lang attribute to signify this. When a name 717 does not have an associated language (such as a neologism not associated with a particular 718 language), the xml:lang attribute SHOULD be omitted. 719

As is defined in the XML specification, an occurrence of the xml:lang attribute indicates that the 720 content to which it applies (namely the element on which it is found and to all its children, 721 unless subsequently overridden) is to be interpreted as being in a certain natural language. 722 Legal values for such attributes conform to RFC 30665 with one exception: UDDI imposes a 723 maximum length of 26 characters. 724

As is the case for RFC 3066, all tags are to be treated as case insensitive; there exist 725 conventions for capitalization of some of them, but these should not be taken to carry meaning. 726 For instance, [ISO 3166] recommends that country codes are capitalized (MN Mongolia), while 727 [ISO 639] recommends that language codes are written in lower case (mn Mongolian). 728

Examples include: "EN-us", "FR-ca". 729

3.3.2.4 description 730

A businessEntity can contain several descriptions, for example, in different languages. 731

Attributes 732

Name Use

xml:lang optional

733

In order to signify the language in which the descriptions are expressed, they MAY carry 734 xml:lang values. There is no restriction on the number of descriptions or on what xml:lang 735 value that they may have. 736

3.3.2.5 contacts 737

The contacts structure itself is a simple collection of one or more contact structures. 738

5 Note that the language type in the XML Schema Recommendation does not conform to RFC 3066. It is necessary to use schema assessment conforming to the errata for XML Schema (see http://www.w3.org/2001/05/xmlschema-errata#e2-25)

�� are specified in the IETF

standard��

RFC 1766 and its successors (including, as of the time of the present writing, RFC ��

). As is indicated therein, language values begin��

primary language tag, and are optionally followed by a series of hyphen-delimited sub-tags ��

country or dialect identification; the tags are ��

case-sensitive.


25/405

739

3.3.2.6 contact 740

The contact structure records contact information for a person or a job role within the 741 businessEntity so that someone who finds the information can make human contact for any 742 purpose. This information consists of one or more optional elements, along with a person’s 743 name. Contact information exists by containment relationship alone; the contact structure does 744 not provide keys for tracking individual contact instances. 745

746

Attributes 747

Name Use

useType optional

748

The useType attribute is used to describe the type of contact in unstructured text. Suggested 749 examples include “technical questions”, “technical contact”, “establish account”, “sales 750 contact”, etc. 751

description is used to describe how the contact information should be used. Publishing 752 several descriptions, e.g. in different languages, is supported. To signify the language in which 753 the descriptions are expressed, they MAY carry xml:lang values. 754

personName is the name of the person or name of the job role supporting the contact. 755 Publishing several names, e.g. for romanization purposes, is supported. 756

757

758

Attributes 759


26/405

Name Use

xml:lang optional

760

In order to signify the contextual language (if any) in which a given name is expressed in (such 761 as the language into which a name has been romanized), it SHOULD carry the xml:lang 762 attribute See Section 3.3.2.3 name for details on using xml:lang values in name elements. 763 There is no restriction on the number of personNames or what xml:lang value each may have. 764 An example for a role might be: 765

<cont act useType=” Techni cal suppor t ” > 766 <per sonName>Admi ni st r at or </ per sonName> 767 … 768 </ cont act > 769

770

phone is used to hold telephone numbers for the contact. This element MAY be adorned with 771 an optional useType attribute for descriptive purposes. 772

email is the email address for the contact. This element MAY be adorned with an optional 773 useType attribute for descriptive purposes. 774

address is the postal address for the contact. 775

3.3.2.7 address 776

address represents the contact’s postal address, in a form suitable for addressing an 777 envelope. The address structure is a simple list of address lines. 778

Attributes 779

Name Use

xml:lang optional

useType optional

sortCode optional

tModelKey optional

780

Address structures have four optional attributes. 781

The xml:lang value describes the language the address is expressed in. There is no 782 restriction on the number of addresses or what xml:lang value they may have. Publication of 783 addresses in several languages, e.g. for use in multilingual countries, is supported. See 784 Appendix D Internationalization for an example. 785

The useType describes the address’ type in unstructured text. Suggested examples include 786 “headquarters”, “sales office”, “billing department”, etc. 787

The sortCode attribute is deprecated because of the guarantee of preserving the document 788 order (see Section 4.5.3 Preservation of Document Order). In order to achieve this behavior, 789 the data has just to be published in the desired order. 790

The tModelKey is a tModel reference that specifies that keyName keyValue pairs given by 791 subsequent addressLine elements, if addressLine elements are present at all, are to be 792 interpreted by the address structure associated with the tModel that is referenced. For a 793 description of how to use tModels in order to give the addressLine list structure and meaning, 794 see Appendix D Internationalization. 795


27/405

3.3.2.8 addressLine 796

addressLine contains a part of the actual address in text form. 797

Attributes 798

Name Use

keyName optional

keyValue optional

799

Each addressLine element MAY be adorned with two optional descriptive attributes, keyName 800 and keyValue. Both attributes MUST be present in each address line if a tModelKey is 801 specified in the address structure. When no tModelKey is provided for the address structure, 802 the keyName and keyValue attributes have no defined meaning. 803

3.3.2.9 businessServices 804

The businessServices structure is used to describe families of Web services. This simple 805 container holds one or more businessService entities (see Section 3.4 businessService 806 structure). 807

808

3.3.2.10 identifierBag 809

The optional identifierBag element allows businessEntity structures to be identified according 810 to published identifier systems, for example, Dun & Bradstreet D-U-N-S

�

numbers or tax 811 identifiers. 812

813

An identifierBag is a list of one or more keyedReference structures, each representing a 814 single identification. 815

For a full description on how to establish an identity, see Appendix E Using Identifiers. 816

3.3.2.11 keyedReference (in identifierBags) 817

A keyedReference, when included in an identifierBag, represents an identifier of a specific 818 identifier system. 819

820

821

822

Attributes 823

Name Use


28/405

tModelKey required

keyName optional

keyValue required

824

The keyedReference consists of the three attributes tModelKey, keyName and keyValue. 825 The required tModelKey refers to the tModel that represents the identifier system, and the 826 required keyValue contains the actual identifier within this system. The optional keyName MAY 827 be used to provide a descriptive name for the identifier. Omitted keyNames are treated as 828 empty keyNames. 829

For example, identifying SAP AG by its Dun & Bradstreet D-U-N-S® Number, using the 830 corresponding tModelKey within the UDDI Business Registry, is done as follows: 831

<identifierBag> 832 <keyedReference 833 tModelKey=”uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s” 834 keyName=”SAP AG” 835 keyValue=”31-626-8655” /> 836 </identifierBag> 837

838

3.3.2.12 categoryBag 839

The optional categoryBag element allows businessEntity structures to be categorized 840 according to published categorization systems. For example, a businessEntity might contain 841 UNSPSC product and service categorizations that describe its product and service offering 842 and ISO 3166 geographical regions that describe the geographical area where these products 843 and services are offered. 844

845

Similar to the identifierBag, a categoryBag contains a simple list of keyedReference 846 structures, each containing a single categorization. The categoryBag MAY also contain a 847 simple list of keyedReferenceGroup structures. At least one keyedReference or one 848 keyedReferenceGroup MUST be provided within the categoryBag. 849

For a full description of how to establish a categorization, see Appendix F Using 850 Categorization. 851

3.3.2.13 keyedReference (in categoryBags) 852

As within an identifierBag (see Section 3.3.2.13 keyedReference (in identifierBags)), a 853 keyedReference contains the three attributes tModelKey, keyName and keyValue. The 854 required tModelKey refers to the tModel that represents the categorization system, and the 855 required keyValue contains the actual categorization within this system. The optional keyName 856 can be used to provide a descriptive name of the categorization. Omitted keyNames are 857 treated as empty keyNames. A keyName MUST be provided in a keyedReference if its 858

�� ubr.

�� D-U-N-S


29/405

tModelKey refers to the general_keywords category system (see also Section 5.1.7 Matching 859 Rules for keyedReferences and keyedReferenceGroups). 860

For example, in order to categorize a businessEntity as offering goods and services in 861 California, USA, using the corresponding ISO 3166 tModelKey within the UDDI Business 862 Registry, one would add the following keyedReference to the businessEntity’s categoryBag: 863

<keyedReference 864 tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” 865 keyName=”California, USA” 866 keyValue=”US-CA” /> 867

868

3.3.2.14 keyedReferenceGroup 869

A keyedReferenceGroup, by itself, is a simple list of keyedReference structures that logically 870 belong together. 871

872

Attributes 873

Name Use

tModelKey required

874

The keyedReferenceGroup MUST contain a tModelKey attribute that specifies the structure 875 and meaning of the keyedReferences contained in the keyedReferenceGroup. A 876 keyedReferenceGroup MUST also contain at least one keyedReference when published. 877

For example, to categorize a businessEntity as being located at the geodetic point that is 878 specified by the latitude/longitude pair 49.6827/8.2952 using the corresponding World 879 Geodetic System 1984 (WGS 84) tModelKey within the UDDI Business Registry, one would 880 add the following keyedReferenceGroup to the businessEntity’s categoryBag: 881

<keyedReferenceGroup tModelKey=”uddi:uddi.org:ubr:categorizationGroup:wgs84” > 882 <keyedReference 883 tModelKey=”uddi:uddi.org:ubr:categorization:wgs84:latitude” 884 keyName=”WGS 84 Latitude” 885 keyValue=”+49.682700” /> 886 <keyedReference 887 tModelKey=”uddi:uddi.org:ubr:categorization:wgs84:longitude” 888 keyName=”WGS 84 Longitude” 889 keyValue=”+008.295200” /> 890 </keyedReferenceGroup> 891

3.4 businessService Structure 892

The businessService structure represents a logical service and contains descriptive 893 information in business terms. A businessService is the logical child of a single businessEntity, 894 the provider of this businessService. Technical information about the businessService is found 895 in the contained bindingTemplate entities. 896

In some cases, businesses would like to share or reuse services, e.g. when a large enterprise 897 publishes separate businessEntity structures. This can be done by using the businessService 898 structure as a projection to a published businessService, as explained below. 899

�� ubr.

�� geo3166-2

�� ubr.

�� ubr.

�� ubr.


30/405

3.4.1 Structure Diagram 900

901

Attributes 902

Name Use

serviceKey optional


903


A given businessService entity is uniquely identified by its serviceKey. When a 905 businessService is published within a UDDI registry, the serviceKey MUST be omitted if the 906 publisher wants the registry to generate a key. When a businessService is retrieved from a 907 UDDI registry, the serviceKey MUST be present. 908

The businessKey attribute uniquely identifies the businessEntity which is the provider of the 909 businessService. Every businessService is “contained” in exactly one businessEntity. 910

When a businessService is published within a UDDI registry, the businessKey MAY be omitted 911 if the businessService is a part of a fully expressed businessEntity element. When a 912 businessService is retrieved from a UDDI registry, the businessKey MUST be present. This 913 behavior provides the ability to browse through the containment relationships given any of the 914 core elements as a starting point. 915

The businessKey may differ from the publishing businessEntity’s businessKey. This indicates 916 a service projection. A service projection allows a business or organization to include in its 917 businessEntity a businessService offered by some other business or organization. A projected 918 businessService is made a part of a businessEntity by reference as opposed to by 919 containment. Projections to the same service can be made in any number of business entities. 920

Simple textual information about the businessService, potentially in multiple languages, is 921 given by its name and short service description. The non-empty name, required except when 922 indicating a service projection, and the optional description can occur multiple times. More 923 information about the structure of the name and description elements can be found in Section 924 3.3 businessEntity Structure. 925

bindingTemplates is a list of technical descriptions for the Web services provided. 926

The categoryBag contains a list of business categories that each describes a specific 927 business aspect of the businessService (e.g. industry, product category or geographic region) 928


31/405

and is valid in its own category system. More information about the categoryBag element can 929 be found in Section 3.3 businessEntity Structure. 930

A businessService entity MAY be digitally signed using XML digital signatures. When a 931 businessService is signed, each digital signature MUST be provided by its own 932 dsig:Signature element. Appendix I Support for XML Digital Signature covers the use of this 933 element in accordance with the XML-Signature specification. 934

3.4.2.1 bindingTemplates 935

The bindingTemplates structure holds, for a given businessService, the bindingTemplate 936 entities that provide the technical descriptions of the Web services that constitute the 937 businessService. 938

939

See Section 3.5 bindingTemplate structure for details on bindingTemplates. 940

3.5 bindingTemplate Structure 941

Technical descriptions of Web services are provided by bindingTemplate entities. Each 942 bindingTemplate describes an instance of a Web service offered at a particular network 943 address, typically given in the form of a URL. The bindingTemplate also describes the type of 944 Web service being offered using references to tModels, application-specific parameters, and 945 settings. 946

Each bindingTemplate is contained in a businessService. 947


32/405

948


950

951

Attributes 952

Name Use

bindingKey optional

serviceKey optional

953


A given bindingTemplate entity is uniquely identified by its bindingKey. When a 955 bindingTemplate is published within a UDDI registry, the bindingKey MUST be omitted if the 956 publisher wants the registry to generate a key. When a bindingTemplate is retrieved from a 957 UDDI registry, the bindingKey MUST be present. 958

The serviceKey attribute uniquely identifies the businessService that contains the 959 bindingTemplate. When a bindingTemplate is published within a UDDI registry, the serviceKey 960 MAY be omitted if the bindingTemplate is a part of a fully expressed businessService element. 961 When a bindingTemplate is retrieved from a UDDI registry, the serviceKey MUST be present. 962

Simple textual information about the bindingTemplate, potentially in multiple languages, is 963 given by its short binding description. It is optional and can occur multiple times. More 964 information about the structure of the description element can be found in Section 3.3 965 businessEntity structure. 966

The accessPoint is a string used to convey the network address suitable for invoking the Web 967 service being described. This is typically a URL but may be an electronic mail address, or even 968 a telephone number. No assumptions about the type of data in this field can be made without 969 first understanding the technical requirements associated with the Web service. 970

The hostingRedirector is a deprecated element, since its functionality is now covered by the 971 accessPoint. For backward-compatibility, it can still be used, but it is not recommended. See 972 the set of UDDI Version 2 Specifications for a description on hostingRedirector. 973

Either an accessPoint or a hostingRedirector must be provided within a bindingTemplate. 974


33/405

The tModelInstanceDetails structure is a list of one or more tModelInstanceInfo elements. 975 The collection of tModelKey attributes found in the tModelInstanceInfo elements together form 976 the "technical fingerprint" of a Web service that can be used to identify compatible services. 977

The categoryBag contains a list of categorizations that each describes a specific aspect of the 978 bindingTemplate and is valid in its own category system. A categoryBag in a bindingTemplate 979 can be used, for example, to indicate that the Web service described by the bindingTemplate 980 has the status “test” or “production”. More information about the structure of the categoryBag 981 element can be found in Section 3.3 businessEntity Structure. 982

A bindingTemplate entity MAY be digitally signed using XML digital signatures. When a 983 bindingTemplate is signed, each digital signature MUST be provided by its own 984 dsig:Signature element. Appendix I Support for XML Digital Signature covers the use of this 985 element in accordance with the XML-Signature specification. 986

3.5.2.1 accessPoint 987

The accessPoint element is an attribute-qualified URI, typically a URL, representing the 988 network address of the Web service being described. The notion of Web service seen here is 989 fairly abstract and many types of network addresses are accommodated. 990

Attributes 991

Name Use

useType optional

992

The purpose of the optional attribute useType is to facilitate the description of several types of 993 accessPoints. 994

The following useType attributes values are pre-defined by UDDI: 995

• endPoint: designates that the accessPoint points to the actual service endpoint, i.e. 996 the network address at which the Web service can be invoked, 997

• bindingTemplate: designates that the accessPoint contains a bindingKey that points 998 to a different bindingTemplate entry. The value in providing this facility is seen when a 999 business or entity wants to expose a service description (e.g. advertise that they have 1000 a service available that suits a specific purpose) that is actually a service that is 1001 described in a separate bindingTemplate record. This might occur when many service 1002 descriptions could benefit from a single service description, 1003

• hostingRedirector: designates that the accessPoint can only be determined by 1004 querying another UDDI registry. This might occur when a service is remotely hosted. 1005

• wsdlDeployment: designates that the accessPoint points to a remotely hosted 1006 WSDL document that already contains the necessary binding information, including 1007 the actual service endpoint. 1008

The useType attribute may contain other values than the four listed above. See Appendix B 1009 Using and Extending the useType Attribute for more information. 1010


34/405

1011

3.5.2.2 tModelInstanceDetails 1012

This structure is a container for one or more tModelInstanceInfo structures. 1013

1014

When a bindingTemplate is published it SHOULD contain, a tModelInstanceDetails element 1015 that in turn contains in its tModelInstanceInfo structures one or more tModel references. This 1016 arbitrarily ordered collection of references is called the “technical fingerprint” of the Web 1017 service. It indicates that the Web service being described complies with the specific and 1018 identifiable specifications implied by the tModelKey values provided. During an inquiry, 1019 interested parties can use this information to look for bindingTemplate entities that contain a 1020 specific fingerprint or partial fingerprint. 1021

3.5.2.3 tModelInstanceInfo 1022

Each tModelInstanceInfo structure represents bindingTemplate entity-specific details for each 1023 tModel referenced. 1024

1025

Attributes 1026

Name Use

tModelKey required

1027

The required tModelKey attribute references a tModel that represents a specification with 1028 which the Web service represented by the containing bindingTemplate complies. 1029

The description is an optional repeating element. Each description, optionally qualified by an 1030 xml:lang attribute, describes what role the tModel plays in the overall service description. 1031

The optional instanceDetails element can be used when tModel-specific settings or other 1032 descriptive information are required either to describe a tModel specific component of a service 1033 description or to support services that require additional technical data support (e.g. via 1034 settings or other handshake operations). 1035


35/405

1036

3.5.2.4 instanceDetails 1037

This structure holds service instance-specific information that is required to either understand 1038 the service implementation details relative to a specific tModel, or to provide further parameter 1039 and settings support. 1040

1041 The description is an optional repeating element. Each description, optionally qualified by an 1042 xml:lang attribute, describes the purpose and/or use of the particular instanceDetails entry. 1043

The overviewDoc is a mandatory repeating element, used to house references to remote 1044 descriptive information or instructions related to the use of a particular tModel and its 1045 instanceParms. Multiple overviewDoc elements are useful, for example, to handle alternative 1046 representations of the documentation. 1047

The instanceParms is an optional element of type string, used to locally contain settings or 1048 parameters related to the proper use of a tModelInstanceInfo. The suggested format is a 1049 namespace-qualified XML document so that the settings or parameters can be found in the 1050 XML documents elements and attributes. 1051

At least one overviewDoc or instanceParms MUST be provided within the instanceDetails. 1052

3.5.2.5 overviewDoc 1053

This structure describes overview information about a particular tModel use within a 1054 bindingTemplate. 1055

1056

The description is a mandatory repeating element. Each description, optionally qualified by 1057 an xml:lang attribute, holds a short descriptive overview of how a particular tModel is to be 1058 used. 1059

The optional overviewURL is to be used to hold a URL that refers to a long form of an 1060 overview document that covers the way a particular tModel is used as a component of an 1061 overall Web service description. 1062

�� an optional

�� has to

�� an optional


36/405

At least one description or an overviewURL MUST be provided within the overviewDoc. 1063

3.5.2.6 overviewURL 1064

The RECOMMENDED format for the overviewURL is a URI that is suitable for retrieving the 1065 actual overview document with an HTTP GET operation, for example, via a Web browser. 1066

Attributes 1067

Name Use

useType optional

1068

The optional useType attribute is used to provide information about the type of document at 1069 that URL. One common value used in the useType attribute is “text”. Using this value denotes 1070 that the overviewURL contains additional textual information. The content of the useType 1071 attribute may contain other values. See Appendix B Using and Extending the useType 1072 Attribute for more information. 1073

3.6 tModel Structure 1074

Making it easy to describe Web services in ways that are meaningful enough to be useful 1075 during searches is an important goal of UDDI. Another goal is to provide a facility to make 1076 these descriptions complete enough that people and programs can discover how to interact 1077 with Web services they do not know much about. To do this, there needs to be a way to mark 1078 a description with information that designates how it behaves, what conventions it follows, and 1079 what specifications or standards the service complies with. 1080

Providing the ability to describe compliance with specifications, concepts, or even shared 1081 design is one of the roles that the tModel structure fills. 1082

Each tModel instance is a keyed entity in UDDI. In a general sense, the purpose of tModel 1083 entities is to provide a reference system based on abstraction. There are two primary uses for 1084 tModel entities: as sources for determining compatibility of Web services and as keyed 1085 namespace references. 1086

3.6.1 Common tModel uses 1087

There are several places within a businessEntity that can refer to tModels. References to the 1088 same tModel instance can be found in many businessEntity structures. tModel references also 1089 occur in various API calls. 1090

Section 3.6 tModel Structure gives an overview of the different types of tModels. 1091

3.6.1.1 Defining the technical fingerprint 1092

One common use for tModel entities is to represent technical specifications or concepts. For 1093 example, a tModel can be used to represent a specification that defines wire protocols, 1094 interchange formats and interchange sequencing rules. Examples can be seen in the 1095 RosettaNet Partner Interface Processes6 specification, the Open Applications Group 1096 Integration Specification7 and various Electronic Document Interchange (EDI) efforts. 1097

6 See http://www.rosettanet.org

7 See http://www.openapplications.org

�� must


37/405

Software that communicates with other software invariably adheres to some pre-agreed 1098 specifications. In situations where this is true, the designers of the specifications can establish 1099 a unique technical identity within a UDDI registry by publishing information about the 1100 specification in a tModel. While the main reason of registering a tModel with a specific UDDI 1101 registry is to define its identity, the actual specification or set of documents that describes the 1102 concept of a tModel is not a part of the registry and is remotely referenced using the 1103 overviewDoc structure. Publishers SHOULD choose well-known formats and description 1104 languages for the documents that describe the concept each tModel represents. 1105

Once a tModel is published, other parties can express the availability of Web services that are 1106 compliant with a specification the tModel represents by simply including a reference to the 1107 tModel – i.e., its tModelKey – in their technical service descriptions bindingTemplate data. 1108

This approach facilitates searching for registered Web services that are compatible with a 1109 particular specification. Once the proper tModelKey value is known, it is easy to discover that a 1110 particular businessEntity has registered a Web service that references the tModel. In this way, 1111 the tModelKey becomes a technical fingerprint that is unique to a given specification. 1112

3.6.1.2 Defining value sets 1113

The second general use for tModel entities is within the identifierBag, categoryBag, address 1114 and publisherAssertion structures that are used to specify organizational identity and various 1115 categories. Used in this context, a tModel represents the system of values used to identify or 1116 categorize UDDI entities. 1117

For example, to represent the fact that a business described by a businessEntity has a 1118 particular US Tax identifier, a keyedReference is placed into the identifierBag of the 1119 businessEntity. The keyedReference has a keyValue that is the tax ID and refers to the tModel 1120 that means “the system of US Tax code identifiers”. Together, the keyValue and the tModel 1121 reference specify a particular value in a particular system of values. 1122

3.6.1.3 Defining a find qualifier 1123

The third general use for tModel entities is to represent find qualifiers. Find qualifiers are values 1124 that modify how the find_xx APIs work. For example, to cause find_business to sort its results 1125 in the order in which they were published, the uddi:uddi.org:findqualifier:sortbydateasc may be 1126 specified. See Section 5.1.4 Find Qualifiers for details. 1127

�� findQualifier:sortByDateAsc


38/405

1128


1130

1131

Attributes 1132

Name Use

tModelKey optional

deleted optional

1133


A given tModel entity is uniquely identified by its tModelKey. When a tModel is published 1135 within a UDDI registry, the tModelKey MUST be omitted if the publisher wants the registry to 1136 generate a key. When a tModel is retrieved from a UDDI registry, the tModelKey MUST be 1137 present. 1138

In retrieved tModel data, the deleted attribute, an information-only field, indicates whether the 1139 tModel is logically deleted. The two allowed values for this attribute are “true” and “false”. 1140

Simple textual information about the tModel, potentially in multiple languages, is given by its 1141 name and short description. While the tModel has exactly one non-empty name, it can have 1142 zero or more descriptions. The name SHOULD be formatted as a URI and, as a 1143 consequence, the xml:lang attribute of the name element SHOULD NOT be used. More 1144 information about the structure of the name and description elements can be found in Section 1145 3.3 businessEntity structure. 1146

The overviewDoc is an optional repeating element, used to house references to remote 1147 descriptive information or instructions related to the tModel. For more information about the 1148 structure of the overviewDoc v, see Section 3.5 bindingTemplate Structure. 1149

The optional useType attribute contained in the overviewURL of the overviewDoc is used to 1150 provide information about the type of document at that URL. One common value used in the 1151 useType attribute is “text”. Using this value denotes that the overviewURL contains additional 1152 textual information. Another common value is “wsdlInterface”, which is used to designate that 1153

��


39/405

the overviewURL contains a WSDL interface document that can be re-used by many 1154 implementations. The content of the useType attribute may contain other values. See 1155 Appendix B Using and Extending the useType Attribute for more information. 1156

In addition to the tModelKey that uniquely identifies the tModel within the registry, the 1157 identifierBag contains a list of logical identifiers, each valid in its own identifier system. For 1158 more information about identifierBags, see Section 3.3 businessEntity Structure. 1159

The categoryBag contains a list of categories that describe specific aspects of the tModel 1160 (e.g. its technical type). Each category is valid in its own category system. For more 1161 information about categoryBags, see Section 3.3 businessEntity structure. 1162

A tModel entity MAY be digitally signed using XML digital signatures. When a tModel is signed, 1163 each digital signature MUST be provided by its own dsig:Signature element. Appendix I 1164 Support for XML Digital Signatures covers the use of this element in accordance with the XML-1165 Signature specification. 1166

3.7 publisherAssertion Structure 1167

Many businesses and organizations are not effectively represented by a single businessEntity, 1168 because their description and discovery are likely to be diverse. Examples include corporations 1169 with a variety of subsidiaries, private exchanges with sets of suppliers and their customers and 1170 industry consortiums with their members. An obvious solution is to publish several 1171 businessEntity structures. Such a set of businessEntity structures represents a more or less 1172 coupled community whose members often would like to make some of their relationships 1173 visible in their UDDI registrations. This may be accomplished by using the publisherAssertion 1174 structure. To eliminate the possibility that one publisher claims a relationship to another that is 1175 not reciprocated, both publishers must publish identical assertions for the relationship to 1176 become visible. More detailed information about relationships and publisher assertions is given 1177 in Appendix A Relationships and Publisher Assertions. 1178


1180


The two businessEntity instances between which an assertion is made are uniquely identified 1182 by the required fromKey and toKey elements. The keyedReference describes the 1183 relationship between the businessEntity elements identified by fromKey and toKey. Similar to 1184 the general behavior of a keyedReference in a categoryBag (see full description in Section 3.3 1185 businessEntity Structure), the included tModelKey uniquely identifies the relationship type 1186 system and the keyName keyValue pair designate a specific relationship type within this value 1187 set. Omitted keyNames are treated as empty keyNames. 1188

A publisherAssertion entity MAY be digitally signed using XML digital signatures. When a 1189 publisherAssertion is signed, each digital signature MUST be provided by its own 1190


40/405

dsig:Signature element. Appendix I Support For XML Digital Signatures covers the use of this 1191 element in accordance with the XML-Signature specification. 1192

3.8 operationalInfo Structure 1193

Information about a publishing operation is captured whenever a UDDI core data structure is 1194 published. This data includes the date and time that the data structure was created and 1195 modified, the identifier of the UDDI node at which the publish operation took place, and the 1196 identity of the publisher. Operational information for a UDDI data structure is made accessible 1197 using the get_operationalInfo inquiry API. See Section 5.1.16 get_operationalInfo. 1198

The operationalInfo structure is used to convey the operational information for the UDDI core 1199 data structures, that is, the businessEntity, businessService, bindingTemplate and tModel 1200 structures. 1201


1203

Attributes 1204

Name Use

entityKey required

1205


The UDDI entity with which the operationalInfo is associated is uniquely identified by the 1207 required entityKey attribute. 1208

The created element indicates the instant in time at which the entity with which the 1209 operationalInfo is associated first appeared in a registry. 1210

The modified element indicates the instant in time at which the entity with which the 1211 operationalInfo is associated was last changed by a save operation that may have updated its 1212 content. This will initially be equivalent to the value of the created element, but will diverge as 1213 changes are made over time. 1214

Some UDDI core data structures are containers of other UDDI core data structures. For 1215 instance, businessService elements are contained by businessEntity elements and 1216 bindingTemplate elements are contained by businessService elements. Independent changes 1217 made to contained entities of such entities (for example, changes to an existing 1218 businessService within a businessEntity by means of a save_service API call) do not affect the 1219 value of the modified element associated with the containing entity. Instead, the 1220 modifiedIncludingChildren element in the containing entity contains the maximum of its own 1221 modified element and the modifiedIncludingChildren elements of each of the entities it contains 1222


41/405

(if any). If a contained entity is deleted or moved elsewhere, the modifiedIncludingChildren 1223 element is also updated, since such operations would otherwise not be documented 1224 elsewhere. Changes in a service that is being projected do not affect the 1225 modifiedIncludingChildren element of the businessEntity in which it is projected. 1226

The degree to which the clocks of each UDDI node used to generate the created, modified, 1227 and modifiedIncludingChildren elements are synchronized is not architecturally specified, but 1228 rather is a matter of registry policy. Likewise, the frequency with which each clock is 1229 incremented (e.g.: 60Hz, 100Hz, etc.) is also a matter of registry policy. 1230

The UDDI node (if any) that has custody of the entity to which an operationalInfo element is 1231 attached is identified by the nodeID element. The nodeID contains a unique key that is used to 1232 identify this node within a UDDI registry. As described in Section 7.5.2 Configuration of a UDDI 1233 Node – operator element for nodes that implement UDDI Replication, this element MUST 1234 match the value specified in the Replication Configuration element associated with the node. 1235

A node may provide an indication of the owner of the data corresponding to the entityKey in 1236 the authorizedName element. The exact contents of this element and how the 1237 authorizedName element should be interpreted depends on the authentication, identification 1238 and privacy policies of the registry and node (see Chapter 9, Policy). 1239

�� The information provided

by the modifiedIncludingChildren element is logically redundant, since it can be computed by inquirers. It is, however, commonly desired and is therefore provided directly in pre-computed form.


42/405

1240

4 Using UDDI APIs 1241

UDDI specifies a number of API sets that are described in Chapter 5 UDDI Programmer APIs 1242 and Section 7.4 Replication API Set. If a node claims to support a UDDI API it MUST 1243 implement the API in conformance with this specification. Node and registry policy determine 1244 the transport and security mechanisms used for each API set. See Chapter 9 Policy for more 1245 information. 1246

A UDDI registry MUST have at least one node that offers a Web service compliant Inquiry API 1247 set. A UDDI registry SHOULD have at least one node that offers a Web service compliant 1248 with the Publication, Security, and Custody and Ownership Transfer API sets. If a UDDI 1249 registry has multiple nodes, all nodes SHOULD offer Web services that are compliant with the 1250 Replication API set. The Subscription and Value Set API sets are OPTIONAL for all nodes 1251 and all registries. 1252

The API descriptions that follow in Chapter 5 UDDI Programmers APIs designate input 1253 elements as optional or required. Required input elements MUST be provided within the 1254 guidelines described by the UDDI schema and in the API descriptions. Optional input 1255 elements MAY be provided, and when they are, they too must follow the guidelines described 1256 by the UDDI schema and in the API description. 1257

4.1 SOAP Usage 1258

This section describes the SOAP specific conventions and requirements applicable to UDDI. 1259

Any use of SOAP by a UDDI implementation that differs from or extends the behavior 1260 described below should be modeled by publishing a tModel to represent this different use of 1261 SOAP. Any Web services that make use of the different SOAP behavior should reference the 1262 tModel in the tModelInstanceDetails of the Web service’s bindingTemplate. See Section 9.4.4 1263 UDDI Data and Information Model for more information. 1264

4.1.1 Support for SOAPAction 1265

SOAP 1.1 requires the presence of the Hyper Text Transport Protocol (HTTP) header field 1266 named SOAPAction when an HTTP binding is specified. UDDI requires the presence of this 1267 HTTP Header field to be SOAP 1.1 compliant. Different SOAP toolkits treat this HTTP header 1268 field differently. For maximum tool compatibility, the SOAPAction may contain any value, 1269 including an empty string. 1270

Both of the following message styles (among others) are permitted in UDDI. 1271

POST / someVer bHer e HTTP/ 1. 1 1272 Host : www. somenode. or g 1273 Cont ent - Type: t ext / xml ; char set =" ut f - 8" 1274 Cont ent - Lengt h: nnnn 1275 SOAPAct i on: " " 1276 1277 <?xml ver si on=" 1. 0" encodi ng=" UTF- 8" ?> 1278 <Envel ope xml ns=" ht t p: / / schemas. xml soap. or g/ soap/ envel ope/ " > 1279 <Body> 1280 <get _bi ndi ngDet ai l xml ns=" ur n: uddi - or g: api _v3" > 1281 … 1282


43/405

and 1283

POST / someVer bHer e HTTP/ 1. 1 1284 Host : www. somenode. or g 1285 Cont ent - Type: t ext / xml ; char set =" ut f - 8" 1286 Cont ent - Lengt h: nnnn 1287 SOAPAct i on: " get _bi ndi ngDet ai l " 1288 1289 <?xml ver si on=" 1. 0" encodi ng=" UTF- 8" ?> 1290 <Envel ope xml ns=" ht t p: / / schemas. xml soap. or g/ soap/ envel ope/ " > 1291 <Body> 1292 <get _bi ndi ngDet ai l xml ns=" ur n: uddi - or g: api _v3" > 1293 … 1294

1295

4.1.2 Support for SOAP Actor 1296

The SOAP Actor feature is not supported by UDDI. UDDI nodes MUST reject any request that 1297 arrives with a SOAP Actor attribute in the SOAP Header element by returning a generic SOAP 1298 fault with no detail element and a “Client” faultcode. The faultstring will clearly indicate the 1299 problem. 1300

4.1.3 Support for SOAP encoding 1301

The SOAP encoding feature (i.e., SOAP 1.1. section 5) is not supported by UDDI. In 1302 messages sent to a UDDI node there must be no claims made about the encoding style of any 1303 element within the “urn:uddi-org:*” namespace. If such claims are made, the node must 1304 respond with a generic SOAP fault with no detail element and a “Client” faultcode. The 1305 faultstring will clearly indicate the problem 1306

4.1.4 Support for SOAP Headers 1307

UDDI registries MAY ignore the contents of SOAP header. SOAP headers that have the 1308 must_understand attribute set to true MUST be rejected with a SOAP fault - MustUnderstand. 1309 UDDI registries MAY ignore other extension headers received. 1310

4.1.5 Support for SOAP Fault 1311

UDDI registries signal a generic SOAP Fault8 when unknown API references are invoked, 1312 validation failures occur, etc. UDDI specific errors MUST be handled via a SOAP Fault 1313 element containing a UDDI dispositionReport element. The following SOAP fault codes are 1314 used: 1315

• VersionMismatch: An invalid namespace reference for the SOAP envelope element 1316 was passed. The valid namespace value is “http://www.xmlsoap.org/soap/envelope/". 1317

• MustUnderstand: A SOAP header element, permitted to be ignored by a UDDI node, 1318 was received with the Must_Understand attribute set to true. In response, a UDDI 1319 node MUST return this response. See Section 4.8 Success and Error Reporting and 1320 Chapter 12 Error Codes. 1321

• Client: A message was incorrectly formed or did not contain enough information to 1322 perform more exhaustive error reporting. 1323

• Server: The Server class of errors indicate that the message could not be processed 1324 for reasons not directly attributable to the contents of the message itself but rather to 1325 the processing of the message. For example, processing could include 1326

8 See section 4.4.1, "SOAP Fault Codes," in SOAP 1.1 specification for descriptive information.


44/405

communicating with an upstream processor which did not respond. The message 1327 may succeed at a later point in time. 1328

4.1.6 XML prefix conventions – default namespace support 1329

UDDI nodes are REQUIRED to support the use of the default namespaces (i.e. no XML prefix) 1330 in SOAP request and response documents as shown in the following HTTP example: 1331

POST / someVer bHer e HTTP/ 1. 1 1332 Host : www. exampl e. com 1333 Cont ent - Type: t ext / xml ; char set =" ut f - 8" 1334 Cont ent - Lengt h: nnnn 1335 SOAPAct i on: " " 1336 1337 <?xml ver si on=" 1. 0" encodi ng=" UTF- 8" ?> 1338 <Envel ope xml ns=" ht t p: / / schemas. xml soap. or g/ soap/ envel ope/ " > 1339 <Body> 1340 <get _bi ndi ngDet ai l xml ns=" ur n: uddi - or g: api _v3" > 1341 … 1342

4.2 XML Encoding Requirements 1343

All messages sent to and received from UDDI nodes MUST be encoded in either UTF-8 or 1344 UTF-16, and MUST specify the Hyper Text Transport Protocol (HTTP) Content-Type header 1345 with a charset parameter of "utf-8" or “utf-16” respectively and a content type of text/xml. All 1346 such messages MUST also have the corresponding 'encoding="UTF-8"' or 'encoding="UTF-1347 16"' markup in the XML-DECL that appears on the initial line. Other encoding name variants, 1348 such as UTF8, UTF_8, etc. MAY NOT be used. 1349

Therefore, to be explicit, when using UTF-8, the initial line MUST be: 1350

<?xml ver si on=" 1. 0" encodi ng=" UTF- 8" ?> 1351 1352

and the Content-Type header MUST be: 1353

Cont ent - t ype: t ext / xml ; char set =" ut f - 8" 1354 1355

When using UTF-16, the initial line MUST be: 1356

<?xml ver si on=" 1. 0" encodi ng=" UTF- 16" ?> 1357 1358

and the Content-Type header MUST be: 1359

Cont ent - t ype: t ext / xml ; char set =" ut f - 16" 1360 1361

All parts of the Content-type header are case insensitive and quotations are optional. 1362

UDDI nodes MUST reject messages that do not conform to this requirement. 1363

For simplification purposes, all examples in this document use UTF-8. 1364

4.3 Support for Unicode: Byte Order Mark 1365

Unicode UTF-8 allows data to be transmitted with an OPTIONAL three-byte signature, also 1366 known as Byte Order Mark (BOM), preceding the XML data. This signature does not contain 1367 information that is useful for decoding the contents; but, in the case of UTF-8, tells the 1368 receiving program that the rest of the text is in UTF-8. Its presence makes no difference to the 1369 endianness of the byte stream as UTF-8 always has the same byte order. The BOM is not 1370 part of the textual content therefore UDDI nodes MAY remove the BOM prior to processing 1371 messages received. 1372

UDDI nodes MUST be prepared to accept messages that contain Byte Order Marks, but the 1373 Byte Order Mark is not required to process SOAP messages successfully. 1374

�� as

��


45/405

UDDI nodes MUST NOT return a Byte Order Mark with any of the response messages 1375 defined in this specification. 1376

All UDDI nodes MUST support all of the Unicode characters, including all compatibility 1377 characters. See Section 4.6.1.1 XML Normalization and Canonicalization for further 1378 information on required behavior with respect to character set normalization and 1379 canonicalization. 1380

4.4 About uddiKeys 1381

UDDI registries MUST use keys that conform to the following grammar. All UDDI keys are 1382 URIs that conform to RFC 2396 but not all URIs are valid UDDI keys. The URIs that are valid 1383 as UDDI keys correspond to a subset of the opaque part alternative of the absoluteURI rule in 1384 RFC 2396. Further, registries MUST use keys from the scheme “uddi” following the syntactic 1385 and semantic rules for that scheme as given in this section, in Section 5.2.2 Publishing Entities 1386 with Publisher Assigned Keys, in Section 8.2 Data Management Policies and Procedures 1387 Across Registries, and Section 9.4.3 Policy Abstractions for the UDDI keying scheme. The 1388 primary motivations for the scheme for uddiKeys is to allow publishers to specify keys for 1389 entities they publish in UDDI registries using “sensible looking” keys and to promote 1390 interoperation among UDDI registries. See Chapter 10 Multi-Version Support for issues 1391 regarding backwards compatibility. 1392

Keys in UDDI are declared as language independent case insensitive and must be case-1393 folded by nodes as part of processing any API. With the inclusion of the attribute 1394 caseMapKind=”fold” from Schema Centric Canonicalization in the schema declaration for 1395 uddiKey type, the normalized form of a uddiKey element is produced using Unicode Case 1396 Folding as defined in the Unicode Technical Report on Case Mappings (see 1397 http://www.unicode.org/unicode/reports/tr21/ for keys. Further, it is RECOMMENDED that 1398 registries use keys from the scheme “uddi” following the syntactic and semantic rules for that 1399 scheme as given in this section, in Section 5.2.2 Publishing Entities with Publisher Assigned 1400 Keys, in Section 8.2 Data Management Policies and Procedures Across Registries, and 1401 Section 9.4.3 Policy Abstractions for the UDDI recommended keying scheme. The primary 1402 motivations for the recommendation to use uddiKeys is to allow publishers to specify keys for 1403 entities they publish in UDDI registries using “sensible looking” keys and to promote 1404 interoperation among UDDI registries. See Chapter 10 Multi-Version Support for issues 1405 regarding backwards compatibility. 1406

Keys in the recommended scheme are case insensitive. The canonicalization algorithm does 1407 not normalize the case of URIs, which implies it does not normalize the case of keys. Even so, 1408 UDDI is required to preserve the case on uddiKeys to keep from invalidating digital signatures 1409 on signed entities that have publisher assigned keys. 1410

4.4.1 Recommended Syntax9 1411

uddiKey = uuidKey / domainKey / derivedKey 1412

uuidKey = "uddi:" uuid 1413

domainKey = "uddi:" domain 1414

derivedKey = uddiKey ":" KSS 1415

KSS = 1*KSSChars 1416

KSSChars = upper / lower / number / other 1417

9 The notation used here is “Augmented Backus-Naur Form” (ABNF) as defined in RFC 2234.

��

�� All such responses MUST

be encoded in UTF-8.

�� URIs conforming

�� RFC 2396


46/405

uuid = 8hexNumber “-“ 4hexNumber “-“ 4hexNumber “-“ 1418

4hexNumber “-“ 12hexNumber 1419

upper = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / 1420

"M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / 1421

"X" / "Y" / "Z" 1422

lower = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / 1423

"m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / 1424

"x" / "y" / "z" 1425

number = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 1426

hexNumber = number / “A” / “B” / “C” / “D” / “F” / “a” / “b” / “c” / “d” / “f” 1427

other = "(" / ")" / "+" / "," / "-" / "." / "=" / "@" / ";" / "$" / "_" / "!" / "'" 1428

1429

Where <domain> is a dNSname as defined in RFC 2459 section 4.2.1.7. A <uuid> is often 1430 referred to as a “formatted Universally Unique Identifier” or “formatted UUID”. A <KSS> is 1431 sometimes referred to as a “key specific string”. 1432

). 1433

4.4.2 Key Syntax10 1434 uddi Scheme = %d117. 100. 100. 105 ; “ uddi ” i n l ower case 1435 1436 uddi Key = nonKeyGener at or Key / keyGener at or Key 1437 1438 nonKeyGener at or Key = uui dKey / domai nKey / der i vedKey 1439 1440 uui dKey = uddi Scheme “ : ” uui d_par t 1441 1442 uui d_par t = 8HEXDI G “ - “ 1443 4HEXDI G “ - “ 1444 4HEXDI G “ - “ 1445 4HEXDI G “ - “ 1446 12HEXDI G 1447 1448 domai nKey = uddi Scheme “ : ” host name 1449 1450 host name = * ( domai nl abel “ . ” ) t opl abel [ “ . ” ] 1451 1452 domai nl abel = al phanum / al phanum * ( al phanum / “ - “ ) al phanum 1453 1454 t opl abel = ALPHA / ALPHA * ( al phanum / “ - “ ) al phanum 1455 1456 al phanum = ALPHA / DI GI T 1457 1458 der i vedKey = nonKeyGener at or Key “ : ” KSS 1459 1460 keyGener at or Key = nonKeyGener at or Key “ : ” “ keygener at or ” 1461 1462 KSS = 1* ur i c ; KSS MUST NOT be “ keygener at or ” 1463 1464 ur i c = r eser ved / unr eser ved / escaped 1465 1466 r eser ved = “ ; ” / “ / ” / “ ?” / “ : ” / “ @” / “ &” / “ =” / “ +” / “ $” / “ , ” 1467

10

The notation used here is “Augmented Backus-Naur Form” (ABNF) as defined in RFC 2234.


47/405

1468 unr eser ved = al phanum / mar k 1469 1470 mar k = “ - ” / “ _” / “ . ” / “ ! ” / “ ~” / “ * ” / “ ’ ” / “ ( “ / “ ) ” 1471 1472 escaped = “ %” HEXDI G HEXDI G 1473

1474

There are some extra restrictions on domain names that are not captured in the ABNF syntax 1475 above: 1476

1. The maximum length of a string representation of a hostname is 253 1477 characters/octets. 1478

2. The maximum length of an individual domainlabel is 63 characters/octets. 1479

There is an additional restriction on KSS that is not captured in the ABNF syntax above: 1480

1. KSS MUST NOT be “keygenerator”. 1481

1482

The keyword “keygenerator” is case-insensitive. 1483

4.4.3 Examples of keys 1484

The following are examples of legal domainKeys. 1485

uddi:tempuri.com 1486

Here, “tempuri.com” is the domain of this key. 1487

uddi:us.tempuri.com 1488

Here, “us.tempuri.com” is the domain. 1489

The following is an example of a legal uuidKey. 1490

uddi:4CD7E4BC-648B-426D-9936-443EAAC8AE23 1491

“4CD7E4BC-648B-426D-9936-443EAAC8AE23” is the uuid of this key. 1492

The following are examples of legal derivedkeys 1493

uddi:AC104DCC-D623-452F-88A7-F8ACD94D9B2B:xyzzy 1494

This is a derived Key based on the <uuidKey> “uddi:AC104DCC-D623-452F-1495 88A7-F8ACD94D9B2B”. The string “xyzzy” is key’s KSS. 1496

uddi:tempuri.com:fish:buyingservice 1497

This key is based on the derivedKey “uddi:tempuri.com”. Its <KSS. 1498

The following is an example of a legal key generator key 1499

uddi:tempuri.com:keygenerator 1500

This key is based on the domainKey “uddi:tempuri.com” 1501

4.5 Data insertion and document order 1502

4.5.1 Inserting Data in Entities During save_xx Operations 1503

When saving a businessEntity, businessService, bindingTemplate or tModel, the UDDI node is 1504 required to add or replace certain elements and attributes if they are not present or are 1505 incorrectly specified in the entity passed to the save_xx API. These are: For businessEntity, 1506 businessService, bindingTemplate and tModel structures, the businessKey, serviceKey, 1507 bindingKey, and tModelKey of the structure being saved. 1508

�� <

�� >

�� <

�� >

�� <

�� >

�� <

�� >

�� <

�� >

�� <

�� >

�� <

�� >

�� <

�� >

�� keyGenerator

�� <domainKey>

�� :fish”. The string

“buyingService” is the key’s ��

> is “keyGenerator”��

fish:buyingService��

<derivedKey>��

:fish”. The string “buyingService” is the key’s <KSS>.


48/405

4.5.2 Inserting Elements in Existing Entities 1509

When a new child element is inserted by a publication API, the UDDI node MUST add the new 1510 child as the last of its siblings. For example, the save_service call can be used to add a 1511 businessService to a businessEntity. The added businessService appears as the last one in 1512 the (possibly single item) list of such businessService structures. When inserting a 1513 businessService using save_service or a bindingTemplate using save_binding, any digital 1514 signatures on the containing UDDI data structure may become invalid with the addition of a 1515 new child. 1516

4.5.3 Preservation of Document Order 1517

The UDDI data model requires UDDI nodes to preserve the order of all descendent elements 1518 in the UDDI core data structures. When a UDDI node responds to an inquiry API call, the 1519 descendent elements of the core data structures in the response must have the order specified 1520 by their publishers or by the order of insertion. 1521

4.6 XML Normalization and Canonicalization 1522

UDDI registries provide publishers with the ability to digitally sign and save entities they 1523 publish, and inquirers with the ability to retrieve and validate the digital signatures on published 1524 material. In order for this to be possible, publishers and registries MUST handle “normalization” 1525 and “canonicalization” as described in this section. 1526

Normalization is the process of standardizing the representation of the characters that make 1527 up a document. In Unicode data there is often more than one way to represent a given glyph. 1528 For example, the character “Å” may be represented as one single character “LATIN CAPITAL 1529 LETTER A WITH RING ABOVE” (hexadecimal 00C5), as another single character 1530 “ANGSTROM SIGN” (hexadecimal 212B) or as a composition of “LATIN CAPITAL LETTER 1531 A” (hexadecimal 0041) and “COMBINING RING ABOVE” (hexadecimal 030A). Normalization 1532 chooses one standard representation in every such case. 1533

Canonicalization is the process of generating a standard representation of XML. It deals with 1534 issues such as the representation of tags; attribute ordering; namespace declaration, 1535 expansion and ordering; and whitespace handling. 1536

4.6.1 Behavior of UDDI nodes 1537

4.6.1.1 Normalization and Canonicalization 1538

UDDI registries MUST exhibit certain behavior with respect to the saved vs. retrieved 1539 representations of the entities they handle. Aspects of this behavior REQUIRE attention to the 1540 Schema Centric XML Canonicalization (see 1541 http://uddi.org/pubs/SchemaCentricCanonicalization.htm) for this function. More specifically, 1542 registries MUST exhibit the following behavior with respect to the data they store and retrieve. 1543 Let: 1544

• C(d, S) be the Schema Centric XML Canonicalization transform of 1545 document d with respect to the set of schemas S, 1546

• U be the set of UDDI v3 schemas, 1547

• x and y be UDDI entities, 1548

• R be a UDDI registry. 1549

For all x saved in R, if y is x as retrieved from R, it MUST be the case that C(x, U) = C(y, U) in 1550 a literal bit-by-bit sense. 1551

�� V3


49/405

Stated informally, if you save an entity in a UDDI registry and later retrieve it, the 1552 canonicalization of what you saved will be the same as the canonicalization of what you got 1553 back. However, this is only guaranteed to be true with respect to the Schema Centric 1554 Canonicalization algorithm; in particular such guarantees are not provided with respect to the 1555 Canonical XML algorithm or its Exclusive Canonical XML variation (see 1556 http://www.w3.org/TR/xml-exc-c14n).11 1557

4.6.2 Client Behavior 1558

The behavior of UDDI registries with respect to normalization and canonicalization means that 1559 if an entity, x, is published and later retrieved from a registry as y, y will not, in general, be 1560 precisely the same bits as x; only a canonicalized form of x and y are guaranteed to be bitwise 1561 identical. This behavior means that for digital signatures to work, publishers and inquirers 1562 SHOULD take certain actions. 1563

4.6.2.1 Publishers 1564

Publishers SHOULD prepare entities they wish to sign by including in their XML DSIG 1565 SignedInfo a Transform which canonicalizes them using Schema Centric XML 1566 Canonicalization (see Section 4.6.1.1 Normalization and Canonicalization) before calculating 1567 the signatures. Publishers SHOULD avoid inserting elements into published signed entities as 1568 doing so likely invalidates the signature. 1569

4.6.2.2 Inquirers 1570

To validate signed entities, inquirers SHOULD adhere to the strictures and processes of the 1571 XML DSIG specification. If, as will almost always be the case in UDDI, the Schema Centric 1572 Canonicalization12 algorithm was indicated by the signer, then execution of the algorithm will 1573 be necessary as part of the process of validating the signature. 1574

4.7 About Access Control and the authInfo Element 1575

The Authorization Policy for a Registry defines how/if access control is implemented. See 1576 Chapter 9 for a discussion of Policy issues. 1577

The authInfo element is an OPTIONAL element on every API call of the Publication, Inquiry 1578 and Subscription API sets. Using an optional element allows different UDDI registries and 1579 nodes within the registries to implement access control on whichever sets of operations such 1580 control is desired. 1581

AuthInfo is an opaque element whose content is meaningful only to the node that created it. It 1582 is intended to enable a variety of authentication mechanisms. For example, it may be used 1583 with: 1584

• Id/password based systems in which the authInfo is an authorization token generated 1585 by the authentication operation (i.e. Kerberos Tickets) 1586

• Authorization assertions (i.e., SAML, X509 Attribute Certificates) 1587

When a node uses authInfo elements it MAY offer the get_authToken and discard_authToken 1588 APIs as a means of obtaining and disposing of them. Alternatively, or in addition, it MAY offer 1589 other means for doing this. 1590

11

As a matter of implementation, registries can straightforwardly support this guarantee by doing little more than simply returning data which is valid against its schema(s). That is, the implementation burden of this requirement is minimal. In particular, registries need not actually execute the canonicalization algorithm as part of the save or retrieval processes.

12 http://uddi.org/pubs/SchemaCentricCanonicalization.htm


50/405

The use of authInfo elements is not the only means a node may use for access control. For 1591 example, if a node chooses to implement authentication at the transport level, it may well rely 1592 on the authorization information supplied by the transport. 1593


51/405

1594

4.8 Success and Error Reporting 1595

The first line of error reporting is governed by the SOAP specification. SOAP fault reporting 1596 and fault codes will be returned for most invalid requests or any request where the intent of the 1597 caller cannot be determined. 1598

If any application level error occurs in processing a request message, a dispositionReport 1599 element will be returned to the caller within a SOAP fault report. Faults that contain disposition 1600 reports contain error information that includes descriptions and the type of key associated with 1601 an entity that can be used to determine the cause of the error. API-specific interpretations of 1602 error codes are provided with each API description. 1603

In a manner consistent with the SOAP processing rules (Section 6.2 of the SOAP 1.1 1604 specification) UDDI follows the semantics of the Hyper Text Transport Protocol (HTTP) Status 1605 codes for communicating status information in HTTP. As is the case for SOAP, success 1606 reporting will use a 200 status code to indicate that the client's request including the SOAP 1607 component was successfully processed. 1608

UDDI application-level errors SHOULD be conveyed using standard HTTP status code where 1609 a 500-level code indicates a server-induced error. In such cases, the UDDI node MUST issue 1610 an HTTP 500 "Internal Server Error" response and return a dispositionReport inside a SOAP 1611 fault report. 1612

Many of the API constructs defined in this specification allow one or more of a given type of 1613 information to be passed. These API calls each conceptually represent a request on the part 1614 of the caller. The general error handling treatment recommended for UDDI nodes is to detect 1615 errors in a request prior to processing the request. Any errors in the request detected will 1616 invalidate the entire request, and cause a dispositionReport to be generated within a SOAP 1617 Fault as described below. 1618

In the case of an API call that involves passing multiples of a given structure, the 1619 dispositionReport will call out only the first detected error, and is not responsible for reporting 1620 multiple errors or reflecting intermediate “good” data. In situations where a specific reference 1621 within a request causes an error to be generated, the corresponding disposition/fault report will 1622 contain a clear indication of the key value that caused the rejection of the rejected request. 1623

In general, UDDI nodes may return any UDDI error code needed to describe an error. The 1624 error codes specified within each API call description are characteristic of the API call, but 1625 other UDDI error codes may be returned in unusual circumstances or when doing so adds 1626 additional descriptive information. See Chapter 12 Error Codes for a summary of UDDI error 1627 codes. 1628

4.8.1 dispositionReport element 1629

A dispositionReport is returned by many of the APIs whether the call completes successfully or 1630 not. Error information is always returned in the dispositionReport. A dispositionReport has the 1631 form: 1632

1633


52/405

1634

Attributes 1635

Name Use

truncated optional

1636

The dispositionReport is a non-empty list of success or error conditions, each described in a 1637 result element. The truncated attribute indicates whether error conditions occurred that are 1638 not listed in the dispositionReport. 1639

1640

Attributes 1641

Name Use

keyType optional

errno required

1642

The result element contains an optional keyType and a required errno attribute. The errno 1643 attribute is set to the value described in Chapter 12 Error Codes. The keyType attribute is used 1644 to indicate the type of the uddiKey that is being reported on, e.g. in an E_invalidKeyPassed 1645 error condition. Valid values for keyType are “businessKey”, “serviceKey”, “bindingKey”, 1646 “tModelKey” and “subscriptionKey”. Detailed information about the error condition can be 1647 found in the optional errInfo element. 1648

The errInfo element, if necessary, describes the error condition in more detail. It contains a 1649 string that is adorned with an errCode attribute, set to the string described in Chapter 12 Error 1650 Codes. 1651

Like other UDDI data structures, the disposition report includes a namespace that identifies the 1652 UDDI version for which it applies. When a UDDI node receives a message with a namespace 1653 that cannot be used to determine the version, a disposition report is return for the most current 1654 UDDI version that the node supports. 1655

4.8.2 Success reporting using the dispositionReport element 1656

The general form of a success report is: 1657

<?xml version="1.0" encoding="UTF-8" ?> 1658 <Envelope xmlns="http://schemas.xmlsoaporg.org/soap/envelope/"> 1659 <Body> 1660 <dispositionReport xmlns="urn:uddi-org:api_v3" > 1661 <result errno="0" > 1662 <errInfo errCode=“E_success" /> 1663 </result> 1664 </dispositionReport> 1665 </Body> 1666 </Envelope> 1667 1668

In the case of success structures, the dispositionReport element is used as a normal SOAP 1669 message with the dispositionReport returned directly within the SOAP Body element. 1670


53/405

4.8.3 Error reporting using the dispositionReport element 1671

All application errors are communicated via the use of the SOAP FAULT element. The 1672 general form of an error report is: 1673

<?xml version="1.0" encoding="UTF-8" ?> 1674 <Envelope xmlns="http://schemas.xmlsoaporg.org/soap/envelope/"> 1675 <Body> 1676 <Fault> 1677 <faultcode>Client</faultcode> 1678 <faultstring>Client Error</faultstring> 1679 <detail> 1680 <dispositionReport xmlns="urn:uddi-org:api_v3"> 1681 <result errno="10500"> 1682 <errInfo errCode=“E_fatalError">The findQualifier 1683 value passed is unrecognized: XYZ</errInfo> 1684 </result> 1685 </dispositionReport> 1686 </detail> 1687 </Fault> 1688 </Body> 1689 </Envelope> 1690

1691

Multiple result elements may be present within the dispositionReport element, and can be 1692 used to provide very detailed error reports for multiple error conditions. The number of result 1693 elements returned within a disposition report is implementation specific. In general it is 1694 permissible to return an error response as soon as the first error in a request is detected. 1695 References within the API reference sections that describe error text content rules pertain to 1696 the content of the errInfo element. 1697

1698


54/405

1699

5 UDDI Programmers APIs 1700

1701

This API reference is divided into a number of logical sections, each addressing a particular 1702 programming focus. These sections cover the inquiry API, the publishing API and the 1703 OPTIONAL security, custody transfer, subscription and value set APIs. 1704

In all cases, the XML structures, attributes and element names shown in the API examples are 1705 derived from the UDDI API schemas described in Chapter 2 UDDI Schemas. For a full 1706 understanding of structure contents, refer to this chapter, the UDDI schemas, and Chapter 3 1707 UDDI Registry Data Structures. 1708

Each API set has one or more corresponding tModels that are referenced in bindingTemplate 1709 structures to indicate that a compliant Web service is offered for the API set. See Section 1710 11.21.9 UDDI Registry API tModels. 1711

5.1 Inquiry API Set 1712

The inquiry API set allows one to locate and obtain detail on entries in a UDDI registry. The 1713 Inquiry API provides three forms of query that follow broadly used conventions which match 1714 the needs of software traditionally used with registries. Three distinct patterns of inquiry are 1715 supported. 1716

5.1.1 The browse pattern 1717

Software that allows people to explore and examine large quantities of data requires browse 1718 capabilities. The browse pattern characteristically involves starting with some broad 1719 information, performing a search, finding general result sets and then selecting more specific 1720 information for drill-down. 1721

This specification supports the browse pattern by way of the API calls involving “find” 1722 operations (hereafter referred to as the “find_xx” APIs). These calls form the search 1723 capabilities provided by the API and are matched with summary return structures that return 1724 overview information about the registered information associated with the inquiry API and the 1725 search criteria specified in the inquiry. 1726

A typical browse sequence might involve finding whether a particular business with a particular 1727 name has any information registered. This sequence starts with a call to find_business, 1728 passing the business name (which could involve the use of just a portion of the name together 1729 with a wildcard character by using the approximateMatch findQualifier described below). This 1730 returns a businessList result - overview information (keys, names and descriptions) derived 1731 from the registered businessEntity information, matching on the name. Information in the list 1732 may be used to select among the businesses and then to drill down into the corresponding 1733 businessService information, looking for one which matches a particular technical fingerprint 1734 (i.e., tModel such as for purchasing, shipping, etc) using the find_service API call. UDDI 1735 provides many similar sequences of API calls that let callers start with a broad notion of the 1736 kind of information they wish to retrieve from a registry, retrieve summary information, and then 1737 drill down to get details. 1738

5.1.2 The drill-down pattern 1739

Each instance of the core data structures – businessEntity, businessService, bindingTemplate 1740 and tModel – has a key which is one of the items in the summary information retrieved by 1741


55/405

find_xx APIs. Given such a key, it is easy to retrieve the full registered details for the 1742 corresponding instance by passing the key to the relevant get_xx API. 1743

Continuing the example from the previous section on browsing, the businessKey associated 1744 with the business being sought is one of the items in the businessList returned by 1745 find_business. This key can be passed as an argument to get_businessDetail. Upon 1746 success, this API returns a businessDetail containing the full registered information, including 1747 the businessEntity structure for the entity whose key value was passed. 1748

5.1.3 The invocation pattern 1749

To have an application take advantage of a Web service that is registered within a UDDI 1750 registry, that application must be prepared to use the information found in the registry for the 1751 specific Web service being invoked. This type of inter-business service call has traditionally 1752 been a task that is undertaken entirely at development time. The degree to which this 1753 changes with Web services is an application design choice, but the existence of UDDI registry 1754 entries makes it significantly easier to do dynamic binding using the following pattern. 1755

Obtain the bindingTemplate data for the Web service of interest from a UDDI registry, such as 1756 the UDDI Business Registry. Typically this is done using one of the browse-and-drill-down 1757 patterns discussed above. The bindingTemplate contains the specific details about an instance 1758 of a given interface type, including the location at which a program starts interacting with the 1759 Web service. The calling application caches this information and uses it to contact the Web 1760 service at the registered address whenever it needs to communicate with the Web service 1761 instance. 1762

If a call fails using cached information previously obtained from a UDDI registry, the application 1763 SHOULD query the UDDI registry for fresh bindingTemplate information. The proper call is 1764 get_bindingDetail passing the original bindingKey value. If the data returned is different from 1765 the cached information, the application SHOULD retry the invocation using the fresh 1766 information. If the result of this retry is successful, the new information SHOULD replace the 1767 cached information. 1768

By using this pattern with Web services, applications can interact with partners without undue 1769 communication and coordination costs. For example, if a business has activated a disaster 1770 recovery site, most of the calls from partners will fail when they try to invoke Web services at 1771 the failed site. By updating the UDDI information with the new address for the Web service, 1772 partners who use the invocation pattern will automatically locate the new Web service 1773 information and recover without further administrative action. Cached binding information 1774 could alternatively be kept up to date by means of notification or polling. 1775

5.1.4 Find Qualifiers 1776

Each of the find_xx APIs accepts an optional findQualifiers argument, which may contain 1777 multiple findQualifier values. Find qualifiers may be either tModelKeys or may be referenced 1778 by a string containing a “short name”. Each of the pre-defined findQualifiers in UDDI can be 1779 referenced using either the appropriate tModelKey, or by its short name. Registries MUST 1780 support both forms, and MUST accept the find qualifiers case-insensitively. The use of 1781 tModelKeys for findQualifiers allows extension to create additional new qualifiers, but registries 1782 are not obligated to support them. Find qualifiers not recognized by a node will return the error 1783 E_unsupported. 1784

Matching behavior for the find_xx APIs when multiple criteria are specified is logical “AND” by 1785 default. Find qualifiers allow the default search behaviors to be overridden. Not all find_xx 1786 APIs support all findQualifier element values. The following table identifies which findQualifiers 1787 apply to each API: 1788

�� web

�� web

�� web

�� web

�� web

�� web

�� web

�� web

�� criterions


56/405

Table 1: Find Qualifiers by API 1789

Find Qualifier Short Name and tModel Name

find_business find _service find_binding find_tModel find_related

Businesses

“andAllKeys”

(uddi-org:andAllKeys)

YES

default for categoryBag, tModelBag, applicable to identifierBag

YES

default for tModelBag & categoryBag

YES

default for categoryBag, tModelBag

YES

default for categoryBag, applicable to identifierBag

NO

“approximateMatch”

(uddi-org:approximateMatch:SQL99)

YES YES YES YES YES

“binarySort”

(uddi-org:binarySort)

YES YES NO YES NO

“bindingSubset”

(uddi-org:bindingSubset)

YES

applicable to categoryBag on bindingTemplate

YES

applicable to categoryBag on bindingTemplate

NO NO NO

“caseInsensitiveSort”

(uddi-org:caseInsensitiveSort)

YES YES NO YES YES

“caseInsensitiveMatch”

(uddi-org:caseInsensitiveMatch)

YES YES YES YES YES

“caseSensitiveSort” 13

(uddi-org:caseSensitiveSort)

YES YES NO YES YES

“caseSensitiveMatch” 14

(uddi-org:caseSensitiveMatch)

YES YES YES YES YES

“combineCategoryBags”

(uddi-org:combineCategoryBags)

YES YES NO NO NO

“diacriticInsensitiveMatch” 15

(uddi-org:diacriticInsensitiveMatch)

YES YES YES YES YES

“diacriticSensitiveMatch” 16

(uddi-org:diacriticSensitiveMatch)

YES YES YES YES YES

13

This is the default behavior.

14 This is the default behavior.

15 Implementation of this findQualifier by nodes is OPTIONAL.



57/405

Find Qualifier Short Name and tModel Name

find_business find _service find_binding find_tModel find_related

Businesses

“exactMatch” 17

(uddi-org:exactMatch)

YES YES YES YES YES

“signaturePresent”

(uddi-org:signaturePresent)

YES YES YES YES YES

“orAllKeys”

(uddi-org:orAllKeys)

YES

default for identifierBag, applicable to tModelBag or categoryBag

YES

applicable to categoryBag, tModelBag

YES

applicable to categoryBag, tModelBag

YES

applicable to categoryBag, default for identifierBag

NO

“orLikeKeys”

(uddi-org:orLikeKeys)

YES

applicable to identifierBag, categoryBag

YES

applicable to categoryBag

YES

applicable to categoryBag

YES

applicable to categoryBag, identifierBag

NO

“serviceSubset”

(uddi-org:serviceSubset)

YES NO NO NO NO

“sortByNameAsc” 18

(uddi-org:sortByNameAsc)

YES YES NO YES YES

“sortByNameDesc”

(uddi-org:sortByNameDesc)

YES YES NO YES YES

“sortByDateAsc”

(uddi-org:sortByDateAsc)

YES YES YES

default behavior

YES YES

“sortByDateDesc”

(uddi-org:sortByDateDesc)

YES YES YES YES YES

“suppressProjectedServices”

(uddi-org:suppressProjectedServices)

YES YES NO NO NO

“UTS-10” 19

(uddi-org:UTS-10)

YES YES NO YES YES

1790

5.1.4.1 Invalid Find Qualifier Combinations 1791

Using a findQualifier with one of the find_xx APIs to which it does not apply, will generally 1792 result in that qualifier being ignored, but there are a few situations for which certain 1793

17

This is the default behavior.


19 Implementation of this findQualifier by nodes is OPTIONAL.


58/405

findQualifiers elements are mutually exclusive and supplying them together will result in an 1794 E_invalidCombination error. The invalid combinations are: 1795

• andAllKeys, orAllKeys, and orLikeKeys are mutually exclusive 1796

• sortByNameAsc and sortByNameDesc are mutually exclusive 1797

• sortByDateAsc and sortByDateDesc are mutually exclusive 1798

• combineCategoryBags, serviceSubset and bindingSubset are mutually exclusive 1799

• exactMatch and approximateMatch are mutually exclusive 1800

• exactMatch and caseInsensitiveMatch are mutually exclusive 1801

• binarySort and UTS-10 are mutually exclusive, as are all collation algorithm tModels 1802 with each other 1803

• diacriticSensitiveMatch and diacriticInsensitiveMatch are mutually exclusive 1804

• exactMatch and diacriticInsensitiveMatch are mutually exclusive 1805

• caseSensitiveSort and caseInsensitiveSort are mutually exclusive 1806

• caseSensitiveMatch and caseInsensitiveMatch are mutually exclusive 1807

See Chapter 11, Utility tModels and Conventions for further information on find qualifier 1808 tModels. 1809

5.1.4.2 General Form of Find Qualifiers 1810

Find qualifiers are expressed by using a findQualifiers argument. The general form of the 1811 findQualifiers element is: 1812

1813

1814

where a findQualifier can be either a string (with a maximum length of 255), or a tModelKey. 1815

5.1.4.3 Find Qualifier Descriptions 1816

The value passed in each findQualifier element indicates the behavior change desired. This 1817 list defines the set of UDDI defined valid qualifiers. Nodes MUST implement all of these 1818 except as noted. 1819

• andAllKeys: this changes the behavior for identifierBag to AND keys rather than OR 1820 them. This is already the default for categoryBag and tModelBag. 1821

• approximateMatch: signifies that wildcard search behavior is desired. This behavior is 1822 defined by the uddi-org:approximatematch:SQL99 tModel and means "approximate 1823 matching as defined for the character like predicate in ISO/IEC9075-2:1999(E) 1824 Section 8.5 like predicate, where the percent sign (%) indicates any number of 1825 characters and an underscore (_) indicates any single character. The backslash 1826 character (\) is used as an escape character for the percent sign, underscore and 1827 backslash characters. This find qualifier adjusts the matching behavior for name, 1828 keyValue and keyName (where applicable). 1829

• binarySort: this qualifier allows for greater speed in sorting. It causes a binary sort by 1830 name, as represented in Unicode codepoints. 1831

�� :uddi.

�� findQualifier:approximateMa

tch ��

<��

>��

<��

>


59/405

• bindingSubset: this is used in the find_business API or the find_service API and is 1832 used only in conjunction with a categoryBag argument. It causes the component of 1833 the search that involves categorization to use only the categoryBag elements from 1834 contained bindingTemplate elements within the registered data and ignores any 1835 entries found in the categoryBag which are not direct descendent elements of 1836 registered businessEntity elements or businessService elements. The resulting 1837 businessList or serviceList return those businesses or services that matched based 1838 on this modified behavior, in conjunction with any other search arguments provided. 1839 Additionally, in the case of the returned businessList from a find_business, the 1840 contained serviceInfos elements will only reflect summary data (in a serviceInfo 1841 element) for those services (contained or referenced) that contained a binding that 1842 matched on one of the supplied categoryBag arguments. 1843

• caseInsensitiveMatch: signifies that the matching behavior for name, keyValue and 1844 keyName (where applicable) should be performed without regard to case. 1845

• caseInsensitiveSort: signifies that the result set should be sorted without regard to 1846 case. This overrides the default case sensitive sorting behavior. 1847

• caseSensitiveMatch: signifies that the matching behavior for name, keyValue and 1848 keyName (where applicable) should be performed with regard to case. This is the 1849 default behavior. 1850

• caseSensitiveSort: signifies that the result set should be sorted with regard to case. 1851 This is the default behavior. 1852

• combineCategoryBags: this may only be used in the find_business and find_service 1853 calls. In the case of find_business, this qualifier makes the categoryBag entries for 1854 the full businessEntity element behave as though all categoryBag elements found at 1855 the businessEntity level and in all contained or referenced businessService elements 1856 and bindingTemplate elements were combined. Searching for a category will yield a 1857 positive match on a registered business if any of the categoryBag elements contained 1858 within the full businessEntity element (including the categoryBag elements within 1859 contained or referenced businessService elements or bindingTemplate elements) 1860 contains the filter criteria. In the case of find_service, this qualifier makes the 1861 categoryBag entries for the full businessService element behave as though all 1862 categoryBag elements found at the businessService level and in all contained or 1863 referenced elements in the bindingTemplate elements were combined. Searching for 1864 a category will yield a positive match on a registered service if any of the categoryBag 1865 elements contained within the full businessService element (including the 1866 categoryBag elements within contained or referenced bindingTemplate elements) 1867 contains the filter criteria. 1868

• diacriticInsensitiveMatch: signifies that matching behavior for name, keyValue and 1869 keyName (where applicable) should be performed without regard to diacritics. 1870 Support for this findQualifier by nodes is OPTIONAL. 1871

• diacriticSensitiveMatch: signifies that the matching behavior for name, keyValue and 1872 keyName (where applicable) should be performed with regard to diacritics. This is the 1873 default behavior. 1874

• exactMatch: signifies that only entries with names, keyValues and keyNames (where 1875 applicable) that exactly match the name argument passed in, after normalization, will 1876 be returned. This qualifier is sensitive to case and diacritics where applicable. This 1877 qualifier represents the default behavior. 1878

• orAllKeys: this changes the behavior for tModelBag and categoryBag to OR the keys 1879 within a bag, rather than to AND them. Using this findQualifier with both a 1880 categoryBag and a tModelBag, will cause all of the keys in BOTH the categoryBag 1881 and the tModelBag to be OR’d together rather than AND’d. It is not possible to OR the 1882

�� canonicalization


60/405

categories and retain the default AND behavior of the tModels. The behavior of 1883 keyedReferenceGroups in a categoryBag is analogous to that of individual 1884 keyedReferences, that is, the complete categoryBag is changed to OR the keys. 1885

• orLikeKeys: when a bag container (i.e. categoryBag or identifierBag) contains multiple 1886 keyedReference elements, any keyedReference filters that come from the same 1887 namespace (e.g. have the same tModelKey value) are OR’d together rather than 1888 AND’d. For example “find any of these four values from this namespace, and any of 1889 these two values from this namespace”. The behavior of keyedReferenceGroups is 1890 analogous to that of keyedReferences, that is, keyedReferenceGroups that have the 1891 same tModelKey value are OR’d together rather than AND’d. 1892

• serviceSubset: this is used only with the find_business API and is used only in 1893 conjunction with a categoryBag argument. It causes the component of the search that 1894 involves categorization to use only the categoryBag elements from contained or 1895 referenced businessService elements within the registered data and ignores any 1896 entries found in the categoryBag which are not direct descendent elements of 1897 registered businessEntity elements. The resulting businessList structure contains 1898 those businesses that matched based on this modified behavior, in conjunction with 1899 any other search arguments provided. Additionally, the contained serviceInfos 1900 elements will only reflect summary data (in a serviceInfo element) for those services 1901 (contained or referenced) that matched on one of the supplied categoryBag 1902 arguments. 1903

• signaturePresent: this is used with any find_xx API to restrict the result set to entities 1904 which either contain an XML Digital Signature element, or are contained in an entity 1905 which contains one. The Signature element is retrieved using a get_xx API call and 1906 SHOULD be verified by the client. A UDDI node may or may not verify the signature 1907 and therefore use of this find qualifier, or the presence of a Signature element 1908 SHOULD only be for the refinement of the result set from the find_xx API and 1909 SHOULD not be used as a verification mechanism by UDDI clients. 1910

• sortByNameAsc: causes the result set returned by a find_xx or get_xx inquiry APIs to 1911 be sorted on the name field in ascending order. This sort is applied prior to any 1912 truncation of result sets. It is only applicable to queries that return a name element in 1913 the top-most detail level of the result set and if no conflicting sort qualifier is specified, 1914 this is the default sorting direction. This findQualifier takes precedence over 1915 sortByDateAsc and sortByDateDesc qualifiers, but if a sortByDateXxx findQualifier is 1916 used without a sortByNameXxx qualifier, sorting is performed based on date with or 1917 without regard to name. 1918

• sortByNameDesc: causes the result set returned by a find_xx or get_xx inquiry call to 1919 be sorted on the name field in descending order. This sort is applied prior to any 1920 truncation of result sets. It is only applicable to queries that return a name element in 1921 the top-most detail level of the result set. This is the reverse of the default sorting 1922 direction. This findQualifier takes precedence over sortByDateAsc and 1923 sortByDateDesc qualifiers but if a sortByDateXxx findQualifier is used without a 1924 sortByNameXxx qualifier, sorting is performed based on date with or without regard to 1925 name. 1926

• sortByDateAsc: causes the result set returned by a find_xx or get_xx inquiry call to be 1927 sorted based on the most recent date when each entity, or any entities they contain, 1928 were last updated, in ascending chronological order (oldest are returned first). When 1929 names are included in the result set returned, this find qualifier may also be used in 1930 conjunction with either the sortByNameAsc or sortByNameDesc findQualifiers. When 1931 so combined, the date-based sort is secondary to the name-based sort (results are 1932 sorted within name by date, oldest to newest). 1933


61/405

• sortByDateDesc: causes the result set returned by a find_xx or get_xx inquiry call to 1934 be sorted based on the most recent date when each entity, or any entities they 1935 contain, were last updated, in descending chronological order (most recently changed 1936 are returned first. When names are included in the result set returned, this find 1937 qualifier may also be used in conjunction with either the sortByNameAsc or 1938 sortByNameDesc find qualifiers. When so combined, the date-based sort is 1939 secondary to the name-based sort (results are sorted within name by date, newest to 1940 oldest). 1941

• suppressProjectedServices: signifies that service projections MUST NOT be returned 1942 by the find_service or find_business APIs with which this findQualifier is associated. 1943 This findQualifier is automatically enabled by default whenever find_service is used 1944 without a businessKey. 1945

• UTS-10: this is used to cause sorting of results based on the Unicode Collation 1946 Algorithm on elements normalized according to Unicode Normalization Form C. 1947 When this qualifier is referenced, a sort is performed according to the Unicode 1948 Collation Element Table in conjunction with the Unicode Collation Algorithm on the 1949 name field, normalized using Unicode Normalization Form C. Support of this 1950 findQualifier by nodes is OPTIONAL. 1951

At this time, these are the only UDDI find qualifiers defined. UDDI registries and individual 1952 nodes may define more find qualifier values than these – but all nodes and fully compatible 1953 software MUST support the above qualifiers, except where indicated otherwise. 1954

5.1.4.4 Sorting Details 1955

Sorting behavior of results returned as part of a UDDI inquiry is controlled by the following sort 1956 order find qualifiers: sortByDateAsc, sortByDateDesc, sortByNameAsc, sortByNameDesc, 1957 caseInsensitiveSort, binarySort and UTS-10. These find qualifiers specify four aspects of 1958 sorting behavior as shown in Table 2: Find Qualifier Sorting Behaviors below. For information 1959 on which find qualifiers are mutually exclusive, see Section 5.1.4.1 Invalid Find Qualifier 1960 Combinations. Not all aspects of sorting are controlled through use of a single sort order find 1961 qualifier. In order to control any combination of aspects of sorting behavior, multiple sort order 1962 find qualifiers can be specified. For example, specifying sortByNameDesc and UTS-10 1963 causes sorting of the result set on the name element according to the Unicode Technical 1964 Standard (UTS) #10 Collation Sequence, but in descending order. 1965


62/405

1966

Table 2: Find Qualifier Sorting Behaviors 1967

Find Qualifier Field being sorted

Direction of sort

Indicates Collation sequence

Controls Case Sensitivity

sortByNameAsc Name Asc

sortByNameDesc Name Desc

caseInsensitiveSort �

caseSensitiveSort �

binarySort �

UTS-10 �

sortByDateAsc Date Asc

sortByDateDesc Date Desc

1968

The default sort order aspects are to perform a case sensitive sort on the primary name 1969 element (where present), or the last change date (when a name is not present), in ascending 1970 order, using the collation sequence as determined by node policy. Nodes MAY choose to 1971 perform a secondary date or name-based sort of duplicate entries in each of these cases. If a 1972 name-based findQualifier is specified without a date-based sort, then nodes MAY perform a 1973 secondary date-based sort of duplicate entries. Similarly, when a date-based sort findQualifier 1974 is specified without a name-based sort, nodes MAY perform a secondary name-based sort of 1975 duplicate entries (where applicable). 1976

Comparison and sorting is performed based on a canonicalized representation. Specifying an 1977 unsupported sort order will result in the error E_unsupported. For more on canonicalization, 1978 refer to Section 4.6 XML Normalization and Canonicalization. 1979

Different sorting behavior can be obtained through the use of different sort orders, which are 1980 represented by their corresponding tModels. The use of alternative collation sequences is 1981 achieved by referencing the corresponding tModelKey as the findQualifier argument supplied 1982 in the search. Support for sorting based tModels describing any collation sequences other 1983 than binary by a node is OPTIONAL. 1984

When a result set is being sorted by name only, then by default the first name stored for the 1985 businessEntity is the one against which sorting is performed. Nodes that offer language-1986 specific sort collation sequences MAY sort based the name element associated with the 1987 collation language.1988


63/405

1989

5.1.5 Use of listDescription 1990

Several of the inquiry APIs cause a list of results to be returned. In such cases, an element 1991 called listDescription MAY also be returned: 1992

1993

Where: 1994

• includeCount: is the number of list items returned for the particular response 1995

• actualCount: is the number of all available matches at the time this particular query 1996 was made 1997

• listHead: is an index (with origin of 1) which indicates the index position within all 1998 available matches of the first element of the returned result set after any sorting has 1999 been applied. 2000

When a listDescription is returned as part of the result set, it includes a listHead value that 2001 indicates the index position of the first result in the set relative to the beginning of the list of all 2002 matches for the query. The query can specify that the result set returned should start with a 2003 particular element in the list of all matches for the query by including a listHead attribute on the 2004 query (find_xx API). The maximum number of results included in response to a query may be 2005 determined by the maxRows attribute of the query (find_xx API) or by the node’s policy. The 2006 listDescription on the response is useful when the node determines that the size of the 2007 resultant list is too large to be returned or when the maxRows and listHead values specified by 2008 the client do not allow all of the results to be returned in response to a single query. 2009

For example, a query with a maxRows attribute set to 10 could be issued to a node where 18 2010 results match the query. The response to this query should contain items 1 through 10 and 2011 the listDescription would have an actualCount value of 18, a listHead value of 1 and an 2012 includeCount value of 10. If the data matching the query does not change and the query is 2013 sent again to the node with a listHead attribute value of 11, the result set should contain items 2014 11-18 and the listDescription would have an actualCount value of 18, a listHead value of 11 2015 and an includeCount value of 8. If the listHead value is less than 1, a value of 1 will be used to 2016 produce the result. If the listHead value exceeds the total number of results provided, an 2017 empty result set will be returned. 2018

listDescription is not a true “cursoring” feature. Since both the registry content and the 2019 associated result set can change between queries, supplying a particular value for listHead on 2020 subsequent queries may result in either duplicate reporting of an element which was returned 2021 as part of the original query, or a failure to report on an element. 2022

The results of using a find_xx API will include a listDescription only if the resultant list is greater 2023 than what a node implementation can return in a single group. For example, if the result set 2024 contains 20 items and all 20 are returned at once, then the listDescription element is allowable, 2025 but not required. If the result set is 1000 and only 500 items can be returned at once, then a 2026 listDescription is required (if the truncated attribute is not used). 2027

�� When a listDescription is

returned as part of the result set, it provides a listHead value that indicates the index position within all matches with which the returned result list starts. For example, if the result set returned contains items 1 through 10 of 18, then the listHead would be 1, or if the current result set contained items 11-18 of 18, then the listHead would be 11. The optional listHead argument to a find_xx API MAY be used to force the list returned to start with a particular element by making further calls. This is useful when the size of the resultant list is too large to be returned in a single query. ¶

�� .


64/405

5.1.6 About wildcards 2028

The default behavior of UDDI with respect to matching is “exact match”. No wildcard behavior 2029 is assumed. Many UDDI inquiry APIs take the arguments “name,” “keyName,” and “keyValue” 2030 whose values are of type string. All such arguments may be specified using a wildcard 2031 character to obtain an “approximate match”. In order to obtain wildcard searching behavior, 2032 the findQualifier tModel uddi-org:approximateMatch:SQL99 (whose tModelKey is 2033 uddi:uddi.org:findqualifier:approximatematch), or its short name “approximateMatch” MUST be 2034 specified. 2035

Wildcards, when they are allowed, may occur at any position in the string of characters that 2036 constitutes the argument value and may occur more than once. Wildcards are denoted with a 2037 percent sign (%) to indicate any value for any number of characters and an underscore (_) to 2038 indicate any value for a single character. The backslash character (\) is used as an escape 2039 character for the percent sign, underscore and backslash characters. Use of the “exactMatch” 2040 findQualifier will cause wildcard characters to be interpreted literally, and as such should not 2041 also be combined with the escape character. Detailed rules for interpretation are defined by 2042 the above tModel for approximate matching. Examples of the use of wildcards may be found 2043 in Appendix G Wildcards. 2044

5.1.7 Matching Rules for keyedReferences and 2045

keyedReferenceGroups 2046

When determining matching behavior in searches involving keyedReferences in categoryBags 2047 and identifierBags, a match occurs if and only if: 2048

1. The tModelKeys refer to the same tModel. This key MUST be specified and MUST 2049 NOT be empty. 2050

2. The keyValues match (an exact match is the default, but the matching behavior is 2051 modified appropriately if the caseInsensitiveMatch, diacriticInsensitiveMatch or 2052 approximateMatch findQualifiers are used); and 2053

3. If the tModelKey involved is “uddi:uddi-org:general_keywords”, the keyName must 2054 match (wildcard matching rules apply if the approximateMatch findQualifier is used). 2055 Omitted keyNames are treated as empty keyNames. Otherwise, keyNames are not 2056 significant unless so indicated in the individual API sections below. 2057

A given keyedReferenceGroup “X” (e.g., within a given categoryBag) matches a 2058 keyedReferenceGroup “Y” in the registry if and only if the tModelKey assigned to the 2059 keyedReferenceGroup X matches the tModelKey assigned to the keyedReferenceGroup Y 2060 and the set of keyedReferences in “X” are a subset of the set of keyedReferences in “Y.” The 2061 order of individual keyedReferences within a keyedReferenceGroup is not important. Matching 2062 rules for the individual contained keyedReference elements are the same as above. 2063

For additional information and examples, refer to Appendix E Using Identifiers and Appendix F 2064 Using Categorization. 2065

5.1.8 Inquiry API functions 2066

The APIs in this section represent inquiries that can be used to retrieve data from a UDDI 2067 registry. These calls all behave synchronously and are suitable for being exposed via HTTP-2068 POST. The calls constituting the UDDI inquiry API are: 2069

• find_binding: Used to locate bindings within or across one or more registered 2070 businessServices. Returns a bindingDetail structure. See Section 5.1.9 find_binding. 2071

• find_business: Used to locate information about one or more businesses. Returns a 2072 businessList structure. See Section 5.1.10 find_business. 2073

�� findQualifier:approximateMa

tch


65/405

• find_relatedBusinesses: Used to locate information about businessEntity registrations 2074 that are related to a specific business entity whose key is passed in the inquiry. See 2075 Section 5.1.11 find_relatedBusinesses. 2076

• find_service: Used to locate specific services within registered business entities. 2077 Returns a serviceList structure. See Section 5.1.12 find_service. 2078

• find_tModel: Used to locate one or more tModel information structures. Returns a 2079 tModelList structure. See Section 5.1.13 find_tModel. 2080

• get_bindingDetail: Used to get bindingTemplate information suitable for making 2081 service requests. Returns a bindingDetail structure. See Section 5.1.14 2082 get_bindingDetail. 2083

• get_businessDetail: Used to get the businessEntity information for one or more 2084 businesses or organizations. Returns a businessDetail structure. See Section 5.1.15 2085 get_businessDetail. 2086

• get_operationalInfo: Used to retrieve operational information pertaining to one or 2087 more entities in the registry. Returns an operationalInfos structure. See Section 2088 5.1.16 get_operationalInfo. 2089

• get_serviceDetail: Used to get full details for a given set of registered businessService 2090 data. Returns a serviceDetail structure. See Section 5.1.16 get_serviceDetail. 2091

• get_tModelDetail: Used to get full details for a given set of registered tModel data. 2092 Returns a tModelDetail structure. See Section 5.1.18 get_tModelDetail. 2093

Several of the find_xx APIs (find_binding, find_business and find_service) support nested 2094 queries, where one or more of the arguments to these APIs can itself be another (inner) query, 2095 the results of which are used to filter the overall results of the primary (outer) query along with 2096 the other criterions supplied. Any findQualifier arguments used only apply directly to the part of 2097 the query (outer or inner) for which they are supplied. They do not propagate inward or 2098 outward. 2099

5.1.9 find_binding 2100

The find_binding API is used to find UDDI bindingTemplate elements. The find_binding API 2101 call returns a bindingDetail that contains zero or more bindingTemplate structures matching 2102 the criteria specified in the argument list. 2103

5.1.9.1 Syntax: 2104

2105

2106


66/405

2107

Attributes 2108

Name Use

maxRows optional

serviceKey optional

listHead optional

2109

5.1.9.2 Arguments: 2110

• authInfo: This optional argument is an element that contains an authentication token. 2111 Registries that wish to restrict who can perform an inquiry typically require authInfo for 2112 this call. 2113

• categoryBag: This optional argument is a list of category references in the form of 2114 keyedReference elements and keyedReferenceGroup structures. When used, the 2115 returned bindingDetail for this API will contain elements matching all of the categories 2116 passed (logical AND by default). Specifying the appropriate findQualifiers can 2117 override this behavior. Matching rules for each can be found in Section 5.1.7 2118 Matching Rules for keyedReferences and keyedReferenceGroups. 2119

• findQualifiers: This optional collection of findQualifier elements can be used to alter 2120 the default behavior of search functionality. See Section 5.1.4 Find Qualifiers, for 2121 more information. 2122

• find_tModel: This argument provides an alternative or additional way of specifying 2123 tModelKeys that are to be used to find the bindingTemplate elements. When 2124 specified, the find_tModel argument is treated as an embedded inquiry that is 2125 performed prior to searching for bindingTemplate elements. The tModelKeys found 2126 are those whose tModels match the criteria contained within the find_tModel element. 2127 The tModelKeys found are added to the (possibly empty) collection specified by the 2128 tModelBag prior to finding qualified bindingTemplates. Note that the authInfo 2129 argument to this embedded find_tModel argument is always ignored. Large result set 2130 behavior involving the return of a listDescription does not apply within an embedded 2131 argument. If the intermediate result set produced is too large, then the overall query 2132 will return E_resultSetTooLarge with an indication that the embedded query returned 2133 too many results. If an E_unsupported error occurs as part of processing this 2134 embedded argument, it is propagated up to the containing (calling) API. 2135

• listHead: This optional integer value is used to indicate which item SHOULD be 2136 returned as the head of the list. The client may request a subset of the matching data 2137 by indicating which item in the resultant set constitutes the beginning of the returned 2138 data. The use of the listDescription element is mutually exclusive to the use of the 2139 truncated attribute that simply indicates a truncated result list in the Inquiry APIs. See 2140 Section 5.1.5 Use of listDescription, for a detailed description of the listHead 2141 argument. 2142

• maxRows: This optional integer value allows the requesting program to limit the 2143 number of results returned. This argument can be used in conjunction with the 2144 listHead argument. 2145

• serviceKey: This optional uddi_key is used to specify a particular instance of a 2146 businessService element in the registered data. Only bindings in the specific 2147 businessService data identified by the serviceKey passed are searched. When it is 2148 either omitted or specified as empty (i.e., serviceKey=””), this indicates that all 2149

�� :

�� is to

�� .

�� .

�� default value is 1, which

returns data from the start ��

. If an invalid value is supplied for the listHead, implementations SHOULD use the default value for completing the request, instead��

issuing an E_fatalError.¶


67/405

businessServices are to be searched for bindings that meet the other criteria supplied 2150 without regard to the service that provides them, and “projected” services are 2151 suppressed. 2152

• tModelBag: This collection of tModelKey elements represent in part or in whole the 2153 technical fingerprint of the bindingTemplate structures for which the search is being 2154 performed. At least one of either a tModelBag or a find_tModel argument SHOULD be 2155 supplied, unless a categoryBag based search is being used. 2156

If a find_tModel argument is specified (see above), it is treated as an embedded 2157 inquiry. The tModelKeys returned as a result of this embedded find_tModel argument 2158 are used as if they had been supplied in a tModelBag argument. Changing the order 2159 of the keys in the collection or specifying the same tModelKey more than once does 2160 not change the behavior of the find. 2161

By default, only bindingTemplates that have a technical fingerprint containing all of the 2162 supplied tModelKeys match (logical AND). Specifying appropriate findQualifiers can 2163 override this behavior so that bindingTemplates with a technical fingerprint containing 2164 any of the specified tModelKeys are returned (logical OR). 2165

5.1.9.3 Returns: 2166

This API call returns a bindingDetail upon success: 2167

2168

Attributes 2169

Name Use

truncated optional

2170

In the event that no matches were located for the specified criteria, the bindingDetail structure 2171 returned is empty (i.e., it contains no bindingTemplate data). This signifies a zero match result. 2172 If no arguments are passed, a zero-match result set will be returned. 2173

If the number of matches exceeds the value of the maxRows attribute, the result set MAY be 2174 truncated. If this occurs, the response contains the attribute “truncated “ with the value “true”. 2175

As an alternative to the truncated attribute, a registry MAY return a listDescription element. 2176 See Section 5.1.5 Use of listDescription, for additional information. 2177

5.1.9.4 Caveats: 2178

If an error occurs in processing this API, a dispositionReport element is returned to the caller 2179 within a SOAP Fault. In addition to the errors common to all APIs, the following error 2180 information is relevant here: 2181

• E_invalidCombination: signifies that conflicting findQualifiers have been specified. 2182 The error text clearly identifies the findQualifiers that caused the problem. 2183

• E_invalidKeyPassed: signifies that the uddi_key value passed did not match with 2184 any known serviceKey or tModelKey values. The error structure signifies the 2185 condition that occurred and the error text clearly calls out the offending key. 2186

��

¶


68/405

• E_resultSetTooLarge: signifies that the particular node queried has deemed that the 2187 entire result set is too large to manage. Therefore, the result set is not available. 2188 Search criteria must be adjusted to obtain a result. 2189

• E_unsupported: signifies that one of the findQualifier values passed was invalid. 2190 The invalid qualifier will be indicated clearly in text. 2191

5.1.10 find_business 2192

The find_business API is used to find UDDI businessEntity elements. The find_business API 2193 call returns a businessList that matches the criteria specified in the arguments. 2194

5.1.10.1 Syntax: 2195

2196

Attributes 2197

Name Use

maxRows optional

listHead optional

2198

5.1.10.2 Arguments: 2199

• authInfo: This optional argument is an element that contains an authentication token. 2200 Registries that wish to restrict who can perform an inquiry in them typically require 2201 authInfo for this call. 2202

• categoryBag: This is a list of category references in the form of keyedReference 2203 elements and keyedReferenceGroup structures. The returned businessList contains 2204 businessInfo elements matching all of the categories passed (logical AND by default). 2205 Specifying the appropriate findQualifiers can override this behavior. Matching rules 2206 for each can be found in Section 5.1.7 Matching Rules for keyedReferences and 2207 keyedReferenceGroups. 2208

�� MaxRows


69/405

• discoveryURLs: This is a list of discoveryURL structures to be matched against the 2209 discoveryURL data associated with registered businessEntity information. To search 2210 for URL without regard to useType attribute values, omit the useType attribute or pass 2211 it as an empty attribute. If useType values are included, the match occurs only on 2212 registered information that matches both the useType and URL value. The returned 2213 businessList contains businessInfo structures matching any of the URL's passed 2214 (logical OR). 2215

• identifierBag: This is a list of business identifier references in the form of 2216 keyedReference elements. The returned businessList contains businessInfo 2217 structures matching any of the identifiers passed (logical OR by default). Specifying 2218 the appropriate findQualifiers can override this behavior. Matching rules can be found 2219 in Section 5.1.7 Matching Rules for keyedReferences and keyedReferenceGroups. 2220

• findQualifiers: This collection of findQualifier elements can be used to alter the 2221 default behavior of search functionality. See the Section 5.1.4 Find Qualifiers, for 2222 more information. 2223

• find_relatedBusinesses: This argument is an embedded inquiry and limits the 2224 search results to those businesses that are related to a specified business in a 2225 specified way. The result is comprised of an intersection of the businesses located 2226 with this embedded inquiry and the businesses discovered using the remaining inquiry 2227 criteria. The standard syntax and arguments for find_relatedBusinesses apply here. 2228 Note that the authInfo argument to this embedded find_relatedBusinesses argument 2229 is always ignored. Large result set behavior involving the return of a listDescription 2230 does not apply within an embedded argument. If the intermediate result set produced 2231 is too large, then the overall query will return E_resultSetTooLarge with an indication 2232 that the embedded query returned too many results. If an E_unsupported error 2233 occurs as part of processing this embedded argument, it is propagated up to the 2234 containing (calling) API. See Section 5.1.11 find_relatedBusinesses, for further 2235 information. 2236

• find_tModel: This argument provides an alternative or additional way of specifying 2237 tModelKeys that are used to find businesses which have service bindings with specific 2238 technical fingerprints as described above for the tModelBag element. When specified, 2239 the find_tModel argument is treated as an embedded inquiry that is performed prior to 2240 searching for businesses. The tModelKeys found are those whose tModels match the 2241 criteria contained within the find_tModel element. The tModelKeys found are added to 2242 the (possibly empty) collection specified by the tModelBag prior to finding qualified 2243 businesses. Note that the authInfo argument to this embedded find_tModel argument 2244 is always ignored. Large result set behavior involving the return of a listDescription 2245 does not apply within an embedded argument. If the intermediate result set produced 2246 is too large, then the overall query will return E_resultSetTooLarge with an indication 2247 that the embedded query returned too many results. If an E_unsupported error 2248 occurs as part of processing this embedded argument, it is propagated up to the 2249 containing (calling) API. 2250



�� :

�� .

�� .

�� default value

�� 1, which returns data from

the start of the list


70/405

• name: This optional collection of string values represents one or more names 2261 potentially qualified with xml:lang attributes. Since “exactMatch” is the default 2262 behavior, the value supplied for the name argument must be an exact match. If the 2263 “approximateMatch” findQualifier is used together with an appropriate wildcard 2264 character in the name, then any businessEntity matching this name with wildcards 2265 and the other criteria will be referenced in the results. For more on wildcard matching, 2266 see Section 5.1.6 About Wildcards. The businessList returned contains businessInfo 2267 structures for businesses whose name matches the value(s) passed (lexical-order 2268 match – i.e., leftmost in left-to-right languages). If multiple name values are passed, 2269 the match occurs on a logical OR basis. Each name MAY be marked with an xml:lang 2270 adornment. If a language markup is specified, the search results report a match only 2271 on those entries that match both the name value and language criteria. The match on 2272 language is a leftmost case-insensitive comparison of the characters supplied. This 2273 allows one to find all businesses whose name begins with an "A" and are expressed 2274 in any dialect of French, for example. Values which can be passed in the language 2275 criteria adornment MUST obey the rules governing the xml:lang data type as defined 2276 in Section 3.3.2.3 name. 2277

• tModelBag: Every Web service instance exposed by a registered businessEntity is 2278 represented in UDDI by a bindingTemplate contained within the businessEntity. Each 2279 bindingTemplate contains a collection of tModel references called its “technical 2280 fingerprint” that specifies its type. The tModelBag argument is a collection of 2281 tModelKey elements specifying that the search results are to be limited to businesses 2282 that expose Web services with technical fingerprints that match. 2283

If a find_tModel argument is specified (see above), it is treated as an embedded 2284 inquiry. The tModelKeys returned as a result of this embedded find_tModel argument 2285 are used as if they had been supplied in a tModelBag argument. Changing the order 2286 of the keys in the collection or specifying the same tModelKey more than once does 2287 not change the behavior of the find. 2288

By default, only bindingTemplates that contain all of the tModelKeys in the technical 2289 fingerprint match (logical AND). Specifying appropriate findQualifiers can override this 2290 behavior so that bindingTemplates containing any of the specified tModelKeys match 2291 (logical OR). 2292

5.1.10.3 Returns: 2293

This API call returns a businessList on success. This structure contains information about 2294 each matching business, including summaries of its businessServices: 2295

2296

2297

Attributes 2298

Name Use

truncated optional

2299

The businessList’s businessInfos structure and its businessInfo structures contain: 2300

�� web


71/405

2301

2302

2303

Attributes 2304

Name Use

businessKey required

2305

If a tModelBag or find_tModel was used in the search, the resulting serviceInfos structure 2306 reflects data only for the businessServices that actually contained a matching 2307 bindingTemplate. For more information on serviceInfos, see Section 5.1.12.3 [find_service] 2308 Returns. 2309

Projected services are treated exactly the same as services that are naturally a part of 2310 businessEntities unless the suppressProjectedServices findQualifier is specified, in which case 2311 they are omitted from the serviceInfos structure returned and are not considered when 2312 determining which businesses match the inquiry criteria. In the event that no matches are 2313 found for the specified criteria, a businessList structure containing no businessInfos structure is 2314 returned. 2315

In the event that no matches were located for the specified criteria, the businessList structure 2316 returned is empty (i.e., it contains no businessInfos data). This signifies a zero match result. If 2317 no arguments are passed, a zero-match result set will be returned. 2318

In the event of a large number of matches, (as determined by the UDDI node), or if the number 2319 of matches exceeds the value of the maxRows attribute, the UDDI node MAY truncate the 2320 result set. If this occurs, the businessList will contain the attribute “truncated” with the value 2321 “true”. 2322

Second level elements (serviceInfos) within the returned businessList will be sorted in the 2323 order in which they were saved. 2324

As an alternative to the truncated attribute, a registry MAY return a listDescription element. 2325 See Section 5.1.5 Use of listDescription, for additional information. 2326

5.1.10.4 Caveats: 2327

If any error occurs in processing this API call, a dispositionReport structure is returned to the 2328 caller in a SOAP Fault. In addition to the errors common to all APIs, the following error 2329 information is relevant here: 2330


72/405


• E_unsupported: signifies that one of the findQualifier values passed was invalid. 2333 The findQualifier value that was not recognized will be clearly indicated in the error 2334 text. 2335

• E_invalidKeyPassed: signifies that a uddi_key or tModelKey value passed did not 2336 match with any known businessKey key or tModelKey values. The error structure 2337 signifies the condition that occurred and the error text clearly calls out the offending 2338 key. 2339

• E_resultSetTooLarge: signifies that the node deems that a result set from an inquiry 2340 is too large and does not honor requests to obtain the results for this inquiry, even 2341 using subsets. The inquiry that triggered this error SHOULD be refined and re-issued. 2342

5.1.11 find_relatedBusinesses 2343

The find_relatedBusinesses API is used to find businessEntity elements, which have a 2344 completed relationship with the specified businessEntity that matches the criteria supplied. 2345 The find_relatedBusinesses API call returns a relatedBusinessesList structure containing 2346 results that match the criteria specified in the arguments. For additional information on the use 2347 of find_relatedBusinesses, refer to Appendix A: Relationships and Publisher Assertions, for 2348 more information on business relationships. 2349

5.1.11.1 Syntax: 2350

2351

Attributes 2352

Name Use

maxRows optional

listHead optional

2353

5.1.11.2 Arguments: 2354



73/405

• businessKey: This uddi_key is used to specify a particular businessEntity instance 2358 to use as the focal point of the search. It MUST NOT be used in conjunction with the 2359 fromKey or toKey arguments. It MUST refer to the businessKey of an existing 2360 businessEntity in the registry. The result set reports businesses that are related in 2361 some way to the businessEntity whose key is specified. 2362

• findQualifiers: This collection of findQualifier elements can be used to alter the 2363 default behavior of search functionality. See Section 5.1.4 Find Qualifiers, for more 2364 information. 2365

• fromKey: This uddi_key is used to specify a particular businessEntity instance which 2366 corresponds to the fromKey of a completed businessRelationship, for use as the focal 2367 point of the search. It MUST NOT be used in conjunction with the businessKey or 2368 toKey arguments. The result set reports businesses for which a relationship whose 2369 fromKey matches the key specified exists. 2370

• keyedReference: This is a single, optional keyedReference element that is used to 2371 specify a relationship type, such that only businesses that are related to the focal point 2372 in a specific way are included in the results. Specifying a keyedReference only affects 2373 whether a business is selected for inclusion in the results. If a business is selected, 2374 the results include the full set of completed relationships between it and the focal 2375 point. See Appendix A: Relationships and Publisher Assertions, for more information 2376 on specifying relationships. Matching rules for the use of keyedReferences are 2377 described in Section 5.1.7 Matching Rules for keyedReferences and 2378 keyedReferenceGroups, with the exception that keyNames MUST also match if they 2379 are non-empty in the search criteria for this API. Omitted keyNames are treated as 2380 empty keyNames. 2381



• toKey: This uddi_key is used to specify a particular businessEntity instance which 2392 corresponds to the toKey of an existing businessRelationship, for use as the focal 2393 point of the search. It MUST NOT be used in conjunction with the businessKey or 2394 fromKey arguments. The result set reports businesses for which a relationship whose 2395 toKey matches the key specified exists. 2396

5.1.11.3 Returns: 2397

This API call returns a relatedBusinessesList on success: 2398

2399

�� :

�� .

�� is to constitute

�� .


returns data from the start


74/405

Attributes 2400

Name Use

truncated optional

2401

Here, the businessKey returned with relatedBusinessesList is the same one provided with the 2402 find_relatedBusinesses API call. The relatedBusinessInfos structure and the 2403 relatedBusinessInfo structures it contains each have this syntax: 2404

2405

2406

2407

The businessKey returned in each relatedBusinessInfo structure pertains to a business, which 2408 matched the search criteria supplied in the find_relatedBusinesses API call. The 2409 sharedRelationships structures then have this syntax: 2410

2411

Attributes 2412

Name Use

direction required

2413

The direction attribute identifies the relationship from the perspective of the business whose 2414 uddi_key was used to specify a particular businessEntity instance to use as a focal point for 2415 the find_relatedBusinesses call. This attribute is either expressed as “fromKey” or “toKey” 2416 depending on the relationship of the business to those returned by the call. 2417


75/405

The example below depicts that Matt's Garage is related to the focal business (i.e. whose 2418 business key is uddi:ws-o-rama-cars.com:be47 and which appeared in the 2419 find_relatedBusinesses) by exactly one relationship -- the "subsidiary" parent-child relationship 2420 -- and that Matt's Garage is a subsidiary of the focal business. In such cases, the direction 2421 attribute is set to “toKey”. 2422

<r el at edBusi nessesLi st oper at or =” uddi . someoper at or ” t r uncat ed=” f al se” 2423 xml ns=” ur n: uddi - or g: api _v3” > 2424 <busi nessKey>uddi : ws- o- r ama- car s. com: be47</ busi nessKey> 2425 <r el at edBusi nessI nf os> 2426 <r el at edBusi nessI nf o> 2427 <busi nessKey>uddi : ws- o- r ama- car s. com: mat t sgar age: be3</ busi nessKey> 2428 <name>Mat t ’ s Gar age</ name> 2429 <descr i pt i on>Car ser vi ces i n …</ descr i pt i on> 2430 <shar edRel at i onshi ps di r ect i on=” t oKey” > 2431 <keyedRef er ence t Model Key=“ uddi : uddi . or g: r el at i onshi ps” 2432 keyName=” Subsi di ar y” 2433 keyVal ue=” par ent - chi l d” > 2434 …] 2435 [ …] 2436 2437

A publisherAssertion structure is only returned if it contains a signature and it has the following 2438 syntax: 2439

2440

In the event that no matches were located for the specified criteria, the relatedBusinessesList 2441 structure returned does not contain a relatedBusinessInfos element. This signifies zero 2442 matches. 2443

In the event of a large number of matches (as determined by the node), or if the number of 2444 matches exceeds the value of the maxRows attribute, the node MAY truncate the result set. 2445 When this occurs, the relatedBusinessesList contains the attribute “truncated” with the value of 2446 this attribute set to “true”. 2447

As an alternative to use of the truncated attribute, a registry MAY return a listDescription 2448 element. See Section 5.1.5 Use of listDescription, for additional information. 2449

5.1.11.4 Caveats: 2450



• E_invalidKeyPassed: signifies that an uddi_key or tModelKey value passed did not 2456 match with any known businessKey key or tModelKey values. The error structure 2457 signifies that the condition occurred and the error text clearly calls out the offending 2458 key. 2459


76/405




77/405

5.1.12 find_service 2466

The find_service API is used to find UDDI businessService elements. The find_service API call 2467 returns a serviceList structure that matches the conditions specified in the arguments. 2468

5.1.12.1 Syntax: 2469

2470

2471

Attributes 2472

Name Use

maxRows optional


listHead optional

2473

5.1.12.2 Arguments: 2474


• businessKey: This optional uddi_key is used to specify a particular businessEntity 2478 instance to search. When supplied, this argument is used to specify an existing 2479 businessEntity within which services should be found. Projected services are 2480 included unless the “suppressProjectedServices” findQualifier is used. If businessKey 2481 it is either omitted or specified as empty (i.e., businessKey=””), this indicates that all 2482 businessEntities are to be searched for services that meet the other criteria supplied 2483 without regard to the business that provides them and service projections does not 2484 apply. 2485

• categoryBag: This is a list of category references. The returned serviceList contains 2486 serviceInfo structures matching all of the categories passed (logical AND by default). 2487 Specifying the appropriate findQualifiers can override this behavior. Matching rules 2488 for the use of keyedReferences and keyedReferenceGroups are described in Section 2489 5.1.7 Matching Rules for keyedReferences and keyedReferenceGroups. 2490

�� ListHead


78/405

• findQualifiers: This optional collection of findQualifier elements can be used to alter 2491 the default behavior of search functionality. See Section 5.1.4 Find Qualifiers, for 2492 more information. 2493

• find_tModel: This argument provides an alternative or additional way of specifying 2494 tModelKeys that are used to find services which have service bindings with specific 2495 technical fingerprints, as described above for the tModelBag element. When 2496 specified, the find_tModel argument is treated as an embedded inquiry that is 2497 performed prior to searching for services. The tModelKeys found are those whose 2498 tModels match the criteria contained within the find_tModel element. The tModelKeys 2499 found are added to the (possibly empty) collection specified by the tModelBag prior to 2500 finding qualified services. Note that the authInfo argument to this embedded 2501 find_tModel argument is always ignored. Large result set behavior involving the 2502 return of a listDescription does not apply within an embedded argument. If an 2503 E_unsupported error occurs as part of processing this embedded argument, it is 2504 propagated up to the containing (calling) API. 2505



• name: This optional collection of string values represents one or more names 2516 potentially qualified with xml:lang attributes. Since “exactMatch” is the default 2517 behavior, the value supplied for the name argument must be an exact match. If the 2518 “approximateMatch” findQualifier is used together with an appropriate wildcard 2519 character in the name, then any businessService data contained in the specified 2520 businessEntity (or across all businesses if the businessKey is omitted or specified as 2521 empty) with matching name value will be returned. Matching occurs using wildcard 2522 matching rules. See Section 5.1.6 About Wildcards. If multiple name values are 2523 passed, the match occurs on a logical OR basis within any names supplied. Each 2524 name MAY be marked with an xml:lang adornment. If a language markup is 2525 specified, the search results report a match only on those entries that match both the 2526 name value and language criteria. The match on language is a leftmost case-2527 insensitive comparison of the characters supplied. This allows one to find all services 2528 whose name begins with an "A" and are expressed in any dialect of French, for 2529 example. Values which can be passed in the language criteria adornment MUST 2530 obey the rules governing the xml:lang data type as defined in Section 3.3.2.3 name. 2531

• tModelBag: Every Web service instance is represented in UDDI by a 2532 bindingTemplate contained within some businessService. A bindingTemplate contains 2533 a collection of tModel references called its “technical fingerprint” that specifies its type. 2534 The tModelBag argument is a collection of tModelKey values specifying that the 2535 search results are to be limited to businessServices containing bindingTemplates with 2536 technical fingerprints that match. 2537

If a find_tModel argument is specified (see below), it is treated as an embedded 2538 inquiry. The tModelKeys returned as a result of this embedded find_tModel argument 2539 are used as if they had been supplied in a tModelBag argument. Changing the order 2540 of the keys in the collection or specifying the same tModelKey more than once does 2541 not change the behavior of the find. 2542

�� :

�� .


�� .


returns data from the start

�� web


79/405

By default, only bindingTemplates that contain all of the tModelKeys in the technical 2543 fingerprint match (logical AND). Specifying appropriate findQualifiers can override this 2544 behavior so that bindingTemplates containing any of the specified tModelKeys match 2545 (logical OR). 2546

5.1.12.3 Returns: 2547

This API call returns a serviceList on success: 2548

2549 Attributes 2550

Name Use

truncated optional

2551

The serviceInfos and contained serviceInfo structures have the syntax: 2552

2553

2554

Attributes 2555

Name Use

serviceKey required

businessKey required

2556

In the event that no matches were located for the specified criteria, the serviceList structure 2557 returned does not contain a serviceInfos element. This signifies zero matches. If no search 2558 arguments (including businessKey) are passed, a zero-match result set is returned. If only the 2559 businessKey search argument is passed, the entire set of services for the business is returned. 2560 The named arguments are all optional, and with the exception of name, may appear at most 2561 once. When more than one distinct named argument is passed, matching services are those 2562 which match on all of the criteria. 2563

When a businessKey is supplied, the resulting serviceList contains only services that are 2564 associated with the designated business. Service projections are included in this list unless 2565 explicitly excluded using the suppressProjectedServices find Qualifier. When the businessKey 2566 is omitted or specified as empty (i.e., businessKey=””), all services that meet the other criteria 2567 are returned in the serviceList, without regard to the business which own them. Service 2568


80/405

projections are not returned when a businessKey is omitted or left empty because they are 2569 exact duplicates of the services being projected upon. 2570

Since a serviceInfo structure can represent a projection to a deleted businessService, the 2571 name element within the serviceInfo structure is optional (see Section 5.2.16 save_business 2572 on deleting projected services). 2573

In the event of a large number of matches (as determined by the node), or if the number of 2574 matches exceeds the value of the maxRows attribute, the result set MAY be truncated. When 2575 this occurs, the serviceList contains the attribute “truncated” with the value of this attribute set 2576 to “true”. 2577

As an alternative to the truncated attribute, a registry MAY return a listDescription element. 2578 See Section 5.1.5 Use of listDescription for additional information. 2579

5.1.12.4 Caveats: 2580



• E_invalidKeyPassed: signifies that the uddi_key value passed did not match with 2586 any known businessKey key or tModelKey values. The error structure signifies the 2587 condition that occurred and the error text clearly calls out the offending key. 2588



find_tModel 2595

The find_tModel API is used to find UDDI tModel elements. The find_tModel API call returns a 2596 list of tModel entries that match a set of specific criteria. The response consists of summary 2597 information about registered tModel data returned in a tModelList structure. 2598

5.1.13.1 Syntax: 2599

2600 Attributes 2601

Name Use

�� ¶ ��


81/405

maxRows optional

listHead optional

2602

5.1.13.2 Arguments: 2603


• categoryBag: This is a list of category references. The returned tModelList contains 2607 tModelInfo elements whose associated tModels match all of the categories passed 2608 (logical AND by default). Specifying the appropriate findQualifiers can override this 2609 behavior. Matching rules for the use of keyedReferences and 2610 keyedReferenceGroups are described in Section 5.1.7 Matching Rules for 2611 keyedReferences and keyedReferenceGroups. 2612

• findQualifiers: This collection of findQualifier elements is used to alter the default 2613 behavior of search functionality. See Section 5.1.4 Find Qualifiers for more 2614 information. 2615

• identifierBag This is a list of identifier references in the form of keyedReference 2616 elements. The returned tModelList contains tModelInfo elements whose associated 2617 tModels match any of the identifiers passed (logical OR by default). Specifying the 2618 appropriate findQualifiers can override this behavior. Matching rules are described in 2619 Section 5.1.7 Matching Rules for keyedReferences and keyedReferenceGroups. 2620



• name: This string value represents the name of the tModel elements to be found. 2631 Since tModel data only has a single name, only a single name may be passed. The 2632 argument must match exactly since “exactMatch” is the default behavior, but if the 2633 “approximateMatch” findQualifier is used together with the appropriate wildcard 2634 character, then matching is done according to wildcard rules. See Section 5.1.6 About 2635 Wildcards for additional information. The name MAY be marked with an xml:lang 2636 adornment. If a language markup is specified, the search results report a match only 2637 on those entries that match both the name value and language criteria. The match on 2638 language is a leftmost case-insensitive comparison of the characters supplied. This 2639 allows one to find all tModels whose name begins with an "A" and are expressed in 2640 any dialect of French, for example. Values which can be passed in the language 2641 criteria adornment MUST obey the rules governing the xml:lang data type as defined 2642 in Section 3.3.2.3 name. 2643

5.1.13.3 Returns: 2644

This API call returns a tModelList structure on success: 2645

�� :

�� .


�� .

�� default value

�� 1, which returns data from

the start of the list


82/405

2646

Attributes 2647

Name Use

truncated optional

2648

The tModelInfos and contained tModelInfo structures have the syntax: 2649

2650

2651

Attributes 2652

Name Use

tModelKey required

2653

In the event that no matches were located for the specified criteria, the tModelList returned will 2654 not contain a tModelInfos element. This signifies zero matches. If no arguments are passed, 2655 a zero-match result is returned. 2656

In the event of a large number of matches (as determined by the node), or if the number of 2657 matches exceeds the value of the maxRows attribute, the result set MAY be truncated. When 2658 this occurs, the tModelList contains the attribute “truncated” with the value “true”. 2659

As an alternative to the truncated attribute, a registry MAY return a listDescription element. 2660 See Section 5.1.5 Use of listDescription for additional information. 2661

5.1.13.4 Caveats: 2662

If any error occurs in processing this API call, a dispositionReport element is returned to the 2663 caller within a SOAP Fault. In addition to the errors common to all APIs, the following error 2664 information is relevant here: 2665



83/405

• E_invalidKeyPassed: signifies that the uddi_key value passed did not match with 2668 any known tModelKey values. The error structure signifies the condition that 2669 occurred and the error text clearly calls out the offending key. 2670

• E_unsupported: signifies that one of the findQualifier values passed was invalid. 2671 The invalid qualifier is clearly indicated in the error text. 2672


get_bindingDetail 2676

The get_bindingDetail API call returns the bindingTemplate structure corresponding to each of 2677 the bindingKey values specified. 2678

5.1.14.1 Syntax: 2679

2680

2681

5.1.14.2 Arguments: 2682


• bindingKey: One or more uddi_key values that represent the UDDI assigned keys for 2686 specific instances of registered bindingTemplate data. 2687

5.1.14.3 Returns: 2688

This API call returns a bindingDetail on successful match of the specified bindingKey values. 2689 See Section 5.1.9.3 [find_binding] Returns for information on this structure. If multiple 2690 bindingKey values were passed, the results are returned in the same order as the keys 2691 passed. 2692

If a large number of keys are passed, the node MAY truncate the result set. When this occurs, 2693 the bindingDetail result contains the attribute “truncated” with the value “true”. 2694

A node MUST NOT return a listDescription element as part of the bindingDetail in response to 2695 this API call. 2696

5.1.14.4 Caveats: 2697


• E_invalidKeyPassed: signifies that one of the uddi_key values passed did not match 2701 with any known bindingKey key values. No partial results are returned – if any 2702 bindingKey values passed are not valid bindingKey values, this error is returned. The 2703 error text clearly calls out the offending key. 2704

��


84/405

get_businessDetail 2705

The get_businessDetail API call returns the businessEntity structure corresponding to each of 2706 the businessKey values specified. 2707

5.1.15.1 Syntax: 2708

2709

2710

5.1.15.2 Arguments: 2711


• businessKey: One or more uddi_key values that represent specific instances of 2715 known businessEntity data. 2716

5.1.15.3 Returns: 2717

This API call returns a businessDetail on successful match of the specified businessKey 2718 values: 2719

2720

Attributes 2721

Name Use

truncated optional

2722

If multiple businessKey values were passed, the results MUST be returned in the same order 2723 as the keys passed. 2724

If a large number of keys are passed, a node MAY truncate the result set. When this occurs, 2725 the businessDetail response contains the attribute “truncated “ with the value “true”. 2726

businessEntity elements retrieved with get_businessDetail can contain service projections. 2727 Such projected services appear in full in the businessEntity in which they occur. Projected 2728 services can be distinguished from the services that are naturally contained in the 2729 businessEntity in which they appear by their businessKey. Services naturally contained in the 2730 businessEntity have the businessKey of the businessEntity in which they appear. Projected 2731 services have the businessKey of the businessEntity of which they are a natural part. 2732

��


85/405

5.1.15.4 Caveats: 2733


• E_invalidKeyPassed: signifies that one of the uddi_key values passed did not match 2737 with any known businessKey values. No partial results are returned – if any 2738 businessKey values passed are not valid, this error is returned. The error text clearly 2739 calls out the offending key. 2740

5.1.16 get_operationalInfo 2741

The get_operationalnfo API call is used to retrieve entity level operational information (such as 2742 the date and time that the data structure was created and last modified, the identifier of the 2743 UDDI node at which the entity was published and the identity of the publisher) pertaining to 2744 one or more entities. The get_operationalInfo API call returns an operationalInfos structure 2745 corresponding to each of the entityKey values specified. 2746

5.1.16.1 Syntax: 2747

2748

5.1.16.2 Arguments: 2749


• entityKey: One or more uddi_key values that represent businessEntity, 2753 businessService, bindingTemplate or tModelKeys. 2754

5.1.16.3 Returns: 2755

This API returns an operationalInfos structure that contains an operationalInfo element for 2756 each entity requested by the inquirer. 2757

The operationalInfos structure has the form: 2758

2759

Attributes 2760

Name Use

truncated optional

2761

For information on the operationalInfo structure, see Section 3.8, operationalInfo Structure. 2762


86/405

5.1.16.4 Caveats: 2763


• E_invalidKeyPassed: signifies that one of the uddi_key values passed did not match 2767 with any known entityKey values. No partial results are returned – if any entityKey 2768 values passed are not valid, this error is returned. The error text clearly calls out the 2769 offending key(s). 2770

5.1.17 get_serviceDetail 2771

The get_serviceDetail API call returns the businessService structure corresponding to each of 2772 the serviceKey values specified. 2773

5.1.17.1 Syntax: 2774

2775

5.1.17.2 Arguments: 2776


• serviceKey: One or more uddi_key values that represent UDDI assigned serviceKey 2780 values of specific instances of known businessService data. 2781

5.1.17.3 Returns: 2782

This API call returns a serviceDetail on successful match of the specified serviceKey values. 2783

2784

Attributes 2785

Name Use

truncated optional

2786

If multiple serviceKey values were passed, the results will be returned in the same order as the 2787 keys passed. 2788

If a large number of keys are passed, a node MAY truncate the result set. When this occurs, 2789 the response contains the attribute “truncated” with the value “true”. 2790


87/405

5.1.17.4 Caveats: 2791


• E_invalidKeyPassed: signifies that one of the uddi_key values passed did not match 2795 with any known serviceKey values. No partial results are returned – if any serviceKey 2796 values passed are not valid, this error is returned. The error text clearly calls out the 2797 offending key. 2798

get_tModelDetail 2799

The get_tModelDetail API call returns the tModel structure, corresponding to each of the 2800 tModelKey values specified. 2801

5.1.18.1 Syntax: 2802

2803

5.1.18.2 Arguments: 2804


• tModelKey: One or more uddi_key values that represent UDDI assigned tModelKey 2808 values of specific instances of known tModel data. 2809

5.1.18.3 Returns: 2810

This API call returns a tModelDetail on successful match of the specified tModelKey values. 2811

2812

Attributes 2813

Name Use

truncated optional

2814

If multiple tModelKey values were passed, the results are returned in the same order as the 2815 keys passed. 2816

If a large number of keys are passed, a node MAY truncate the result set. When this occurs, 2817 the response contains the attribute “truncated” with the value of “true”. 2818

��


88/405

2819

5.1.18.4 Caveats: 2820


• E_invalidKeyPassed: signifies that one of the uddi_key values passed did not match 2824 with any known tModelKey values. No partial results are returned – if any tModelKey 2825 values passed are not valid, this error is returned. The error text clearly calls out the 2826 offending key. 2827


89/405

2828

5.2 Publication API Set 2829

The API calls in this section are used to publish and update information contained in a UDDI 2830 registry. According to the policy of the UDDI registry, a publisher selects a UDDI node where it 2831 will publish the information. 2832

API calls in this section MUST all be implemented as synchronous and “atomic” from the point 2833 of view of the caller. That is, each call MUST either succeed completely or fail completely. 2834 Partial results MUST NOT be returned. 2835

5.2.1 Publishing entities with node assigned keys 2836

When a publisher does not provide keys for new entities, the UDDI node will assign keys in 2837 accordance with registry policy. Node-assigned keys MUST use keys that conform to the 2838 grammar in Section 4.4 About uddiKeys. 2839

5.2.2 Publishing entities with publisher-assigned keys 2840

The registry keying policy MAY allow an entity’s key to be proposed by the publisher. If the 2841 publisher does not propose a key for an entity, the registry MUST assign one. 2842

Since entity keys MUST be unique in a registry without regard to the type of entity and since 2843 registries MUST define to impose policies concerning which publishers may publish which 2844 keys, publisher-assigned keys are subject to rules that UDDI registries enforce. Behavior that 2845 ensures uniqueness across entity types (businessEntity, businessService, bindingTemplate, 2846 tModel and subscription) is REQUIRED for all registries. In this section we discuss the 2847 behavior of registries that use the recommended “uddi:” key structure. This behavior provides 2848 uniqueness and promotes interoperability among registries, while allowing various registry-2849 specific policies to be built. Practical guidance for the use of this facility may be found in 2850 Section 9.4.2 General Keying Policy and Section 9.4.3 Policy Abstractions for the UDDI keying 2851 scheme. 2852

5.2.2.1 Key generator keys and their partitions 2853

To ensure that publisher-generated keys do not conflict with one another, registries assign the 2854 authority to generate keys to publishers in the following manner: 2855

1. The conceptual space of uddiKeys is divided into non-overlapping, hierarchically 2856 arranged partitions, each of which can be associated with a publisher. 2857

2. Only the publisher associated with a particular partition is given the authority to assign 2858 keys within the partition. 2859

3. The publisher with authority for a given partition may designate any publisher it 2860 chooses for any partition directly below the partition it manages, provided it has not 2861 already designated a publisher to that partition. 2862

4. The publisher with authority for a partition may transfer its authority to another 2863 publisher. 2864

5. Initially, the registry itself has authority for the root partition of the hierarchy. 2865

The specific mechanisms that enforce these rules are explained below. 2866

Each node of a registry is a generator of keys. This is required to enable the node to generate 2867 keys not provided by publishers. In addition, the policies of a registry MAY allow individual 2868 publishers to obtain the authority to be generators of keys for specific partitions within the 2869 space of uddiKeys. Publishers obtain this authority by owning a particular tModel called a key 2870

��

��

�� UDDI provides no

automated means to reconcile multiple or registrations that are published at different nodes of the same registry.

�� SHOULD follow

�� uuidKey format described

�� recommended

�� following the recommended

keying scheme


90/405

generator tModel. The key generator tModel contains a key generator key, and it specifies the 2871 partition for which the publisher may assign keys. 2872

The subset of derivedKeys called key generator keys consists of all the keys of the form: 2873

keyGeneratorKey = uddiKey ":keygenerator" 2874

As described in Section 4.4.1, a derivedKey is one that is formed from another key by 2875 appending a non-empty, colon-prefixed string to another uddiKey. A derivedKey is said to be 2876 "based on" this uddiKey. With this in mind, the complete partition of a given keyGeneratorKey 2877 is the set of keys consisting of: 2878

2879

1. The set of derivedKeys based on the same uddiKey that the keyGeneratorKey is 2880 based upon. 2881

2. The set of keyGeneratorKeys based on a key that is in the partition. 2882

3. The domainKey, if the keyGeneratorKey is based upon that domainKey. 2883

2884

Note that the partition's keyGeneratorKey itself is exluded from the partition. 2885

A rootKeyGeneratorKey is a keyGeneratorKey that is not based on a derivedKey. That is: 2886

rootKeyGeneratorKey = (uuidKey / domainKey) ":keygenerator" 2887

2888

5.2.2.1.1 Examples 2889

Based on the rules above, it is possible to construct the keyGeneratorKey for any key by 2892 manipulating the string representation of the key. To illustrate, suppose the key is x, then the 2893 following pseudo-code will determine the keyGeneratoryKey: 2894

I f x i s a keyGener at or Key, and y i s t hat key mi nus t he “ : keygener at or ” suf f i x, 2895 t hen i f y i s a domai nKey 2896 t hen x i s a t op- l evel keyGener at or , and has no keyGener at or Key ( 1. a) 2897 el se y i s a der i vedKey, based on z, 2898 and x’ s keyGener at or Key i s z: keyGener at or ( 1. b) 2899 el se 2900

I f x i s a domai nKey 2901 t hen x’ s keyGener at or key i s x: keyGener at or ( 2) 2902 el se x i s based on a key y, and x’ s keyGener at or i s y: keyGener at or ( 3) 2903

2904

Using this pseudo-code illustration, the following table provides examples of legal URI’s and 2905 their associated key generators for each of the four cases noted: 2906

Key keyGeneratorKey Case in pseudo-code

uddi:tempuri.com uddi:tempuri.com:keygenerator 2

uddi:tempuri.com:keygenerator <none> 1.a

uddi:tempuri.com:xxx:keygenerator uddi:tempuri.com:keygenerator 1.b

uddi:tempuri.com:xxx uddi:tempuri.com:keygenerator 3

uddi:tempuri.com:xxx:yyy uddi:tempuri.com:xxx:keygenerator 3

2907

The following keys do NOT belong to the partition of the key generator key 2908 “uddi:tempuri.com:keygenerator”. 2909

�� <

�� >

�� keyGenerator

�� The complete partition of a

given <keyGeneratorKey> is the set of keys consisting of ¶the partition name (the <uddiKey>��

precedes the ��

“:keyGenerator”) together with; ¶keys assigned ��

this partition (those <��

>s ��

that same <��

>) together with;��

first-level subpartition <��

>s (those <��

>s based on a <derivedKey> within the partition); ��

but, excluding the initial <��

>��

¶��

<��

>��

<��

>��

<��

>��

>��

keyGenerator��

The following keys all belong to the partition of the key generator key “uddi:tempuri.com:keyGenerator”.¶¶“uddi:tempuri.com” � � � ��


91/405

“uddi:tempuri.com:keygenerator” The keyGeneratorKey does not belong to the partition it designates.

“uddi:tempuri.com:xxx:yyy” This key belongs to the partition of the keyGeneratorKey “uddi:tempuri.com:xxx:keygenerator”, not this one.

“uddi:tempuri.com:keygenerator:zzz” This key does not belong in any partition – it is an invalid key.

2910

5.2.2.2 Behavior of publishers 2911

To successfully publish a new entity with a proposed key, the publisher needs to own the key 2912 generator tModel for the partition in which the key lies. Typically, a publisher gets ownership by 2913 publishing the tModel in question, but publishers can also get ownership in other ways, for 2914 example by having another publisher transfer ownership. 2915

Once a publisher owns a key generator tModel that publisher MAY publish new entities20 and 2916 assign them keys within the key generator tModel’s partition. Publishers are responsible for 2917 managing the uniqueness of the keys in the partition they own. If a publisher fails to do so, and 2918 generates an already used key, a publish operation could inadvertently replace an entity 2919 previously published by that publisher. 2920

If a publisher owns key generator tModels with the same key in multiple registries – for 2921 example one in the publisher’s private test registry and one in the UDDI Business Registry – 2922 that publisher MAY publish the entities with identical keys in those registries. This enables 2923 many interesting capabilities. For example, publishers may choose to develop their UDDI 2924 entities by publishing them into test registries and then, at appropriate times, “promote” them to 2925 the UDDI Business Registry. 2926

5.2.2.3 Behavior of UDDI nodes 2927

To ensure that publisher-assigned keys work correctly all UDDI implementations behave as 2928 follows. 2929

5.2.2.3.1 “New” and “existing” entities defined 2930

During a publish operation, the entity or entities being published are either “new” or “existing”. 2931 An existing entity is one that has a key that matches the key of an entity already in the registry. 2932 A new entity is one that does not. If a new entity has a key, this key is the key proposed for that 2933 entity by its publisher. 2934

5.2.2.3.2 Behavior with respect to entities for which no key is proposed. 2935

A UDDI node MUST generate and assign a key to each entity for which the publisher 2936 proposes no key. It may generate uuidKeys for use as the keys of new entities for which no 2937 key is proposed or it may generate keys in the partition of a key generator tModel it owns. 2938

A registry whose nodes assign uddiKeys to new entities is called a root registry. The UDDI 2939 Business Registry is a root registry. A registry whose nodes gain ownership of their key 2940

20

Assuming, of course, the publisher is otherwise authorized to publish the entities in question. Some registries, for example, impose limits on the numbers of entities a publisher may publish.

�� <uuidKey>s

�� <

�� >


92/405

generator tModels by publishing them in the UDDI Business Registry are affiliates of the UDDI 2941 Business Registry. See Section 1.5.5 Affiliations of Registries. 2942

5.2.2.3.3 Behavior with respect to uuidKeys 2943

A UDDI node SHOULD accept a uuidKey as the key for a new entity during a publish 2944 operation if the publisher is a trusted publisher of such keys, according to the policies of the 2945 registry. UDDI nodes MUST NOT allow other publishers to generate uuidKeys. 2946

5.2.2.3.4 Behavior with respect to key generator keys 2947

A UDDI node MUST NOT publish any non-tModel entity whose proposed key is a key 2948 generator key. A tModel whose proposed key is a key generator key MUST include a 2949 category bag with a keyed reference with the tModelKey set to 2950 “uddi:uddi.org:categorization:types” and the keyValue set to “keyGenerator”. 2951

5.2.2.3.5 Behavior with respect to root key generator keys 2952

During a publish operation a UDDI node SHOULD accept a root key generator key as the key 2953 for a new tModel if it is proposed by a publisher authorized to publish the key, according to the 2954 policies of the registry. The policy MUST prevent more than one publisher from publishing 2955 tModels with the same root key generator key. 2956

An appropriate policy for root and for affiliated registries is given in Chapter 9 Policy. 2957

5.2.2.3.6 Behavior with respect to other proposed keys 2958

A UDDI node SHOULD accept keys proposed for new entities during publishing operations if 2959 they meet both of the following criteria. 2960

• The proposed key lies in the partition of the key of an existing key generator tModel. 2961

• The same publisher who is proposing the new key owns the key generator tModel 2962 referred to in the previous bullet. 21 2963

21

The rules given in section 5.2.2.3 are safe for the following reasons. From a technical point of view the base requirement is that the keys for each entity be unique within the registry in which it is published. Because UDDI can be a replicated data store, the uniqueness requirement means that each trusted source of keys must be able to assert that the keys it publishes will not conflict with the keys published by any other trusted source. The sources in a given registry must trust one another not to generate duplicate keys, just as they do in V1 and V2. In V1 and V2 the only sources of keys are the nodes themselves.

The <rootKeyGeneratorKey>s come from two sources, those based on <uuidKey>s and those based on <domainKey>s.domainKeys. Since no <domain> is also a <UUID>, the two sources never overlap and can be considered separately.

Those <rootKeyGenerator>s based on <uuidKey>s are safe because they are generated by the nodes in the same way that <uuidKey>s are, except that the nodes append a “:keyGeneratorkeygenerator” onto the end. The <rootKeyGeneratorKey>s based on <domainKey>s are safe because they are checked for uniqueness before publishing using the UDDI registry’s policy, which is required to check for uniqueness.

All the other keys are generated based on a key generator tModel. At any given time each key generator tModel is owned by a publisher and only this publisher is allowed to generate keys based on it. Further, publication may take place only on the node that has custody of the key generator tModel in question. Taken together, this means that each node can ensure for the registry as a whole that only the owner uses a given tModel to generate new keys. These features allow the nodes to apply whatever political/legal policies they wish to apply to the generation of such keys.

As for registry-wide uniqueness, any node at which a publish operation takes place can determine whether a key based on a key generator tModel is new or already existing by looking only at local information. This is obviously true for keys based on tModels that have been in the custody of the same node since their creation since all previous key creations based on the tModel in question must have been done at the custodial node. But it is also true for key generator tModels whose custody has been transferred from one node to another. This is so because any key created using the tModel must have been created prior to the custody transfer. This means that all entities with keys based on a transferred key generator tModel will precede the transfer of custody in the replication stream and thus be available at the local node.

�� <

�� >

�� <

�� >

�� <

�� >

�� <keyGeneratorKeys>

�� <keyGeneratorKey>.¶

�� <rootKeyGeneratorKey>




93/405

5.2.2.4 Affiliations of registries 2964

A set of registries may cooperate in managing a single multi-registry key space by designating 2965 one of the registries in the group to be the “root registry” and assigning it to be the authority for 2966 the root partition. Other registries in the set are said to be affiliate registries. See Section 1.5.5 2967 Affiliations of Registries for more information 2968

The UDDI Business Registry is a root registry. Its policies and procedures are designed to 2969 make it simple for any UDDI registry to be affiliated with it. 2970

Designating new authorities is done by publishing key generator tModels in the root registry, in 2971 one or more of the registries affiliated with the root registry or both. The owner of a key 2972 generator tModel is the naming authority for the partition the tModel represents. 2973

5.2.3 Special considerations for validated value sets 2974

Several of the APIs defined in this section allow publishers to save category and identifier 2975 information in support of searches that use category and identifier system references. The 2976 save_business, save_service, save_binding and save_tModel APIs allow designation of these 2977 value set references. Categorization is specified using the element named categoryBag, 2978 which contains namespace-qualified references to categories and descriptions. categoryBags 2979 can also contain groups of these references to categories and descriptions. Identifiers are 2980 specified using the identifierBag element, which contains namespace-qualified references to 2981 identifiers and descriptions. 2982

Similarly, the add_publisherAssertions and set_publisherAssertions APIs allow 2983 publisherAssertion elements to be saved. These publisherAssertion elements contain a 2984 characterization of the relationship being established using a keyedReference element that 2985 refers to a relationship type system. 2986

Identifier, category and relationship type systems taken together are referred to as “value sets.” 2987 UDDI allows value sets to be checked or unchecked. References to checked value sets that 2988 are registered in UDDI can be checked internally by the UDDI nodes where publishing takes 2989 place, or externally by a provider of a validation Web service. The UDDI node can also 2990 choose to not support some or all checked value sets. 2991

When a UDDI node encounters a reference to a checked value set in a keyedReference it will 2992 either ensure the reference is validated or fail the save. Such references to supported 2993 checked value sets are verified for validity according to the validation algorithm defined for the 2994 value set and described by its tModel. When all checks succeed, the save is permitted. An 2995 E_unvalidatable error indicates the checked value set is supported but its validation algorithm 2996 is not available. An E_unsupported indicates the checked value set is not supported by the 2997 node. E_invalidValue or E_valueNotAllowed indicate one or more references failed validation. 2998 When the checked value set is not supported, the value set’s validation algorithm is 2999 unavailable, or any of the references fail validation, the save operation MUST fail. 3000

When the UDDI node supports a checked value set it may check the references itself, or 3001 consult a validation Web service. For cached checked value sets, the UDDI node verifies that 3002 referenced keyValues are in the set of valid values for the value set. The selection of an 3003 algorithm for verifying a checked value set is a matter of registry policy as detailed in Chapter 9 3004 Policy. 3005

A category group system is portrayed by a keyedRefererenceGroup element. Each 3006 keyedReferenceGroup has a tModelKey that references the category group system, and a set 3007 of contained keyedReference elements that make up the actual group of categories. Similar to 3008 references to checked value sets, validation is carried out for a keyedReferenceGroup if the 3009 referenced category group system is checked. Such validation entails verification that the 3010 keyedReferenceGroup is valid according to the validation algorithm described by the tModel 3011 for the category group system. Validation for a keyedReferenceGroup that references a 3012 cached checked category group system involves verification that the tModels referenced by 3013

�� for


94/405

the contained keyedReference elements are valid for the category group system. The set of 3014 valid values for such a cacheable checked category group system is defined by the 3015 tModelKeys for the set of tModels that can participate in the group. 3016

No validation is performed on references to unchecked value sets 3017

5.2.4 Special considerations for the xml:lang attribute 3018

During save_xx API calls, the name, description, address, and personName UDDI elements 3019 MAY be adorned with the xml:lang attribute to indicate the language in which their content is 3020 expressed. (See Chapter 3 UDDI Registry Data Structures.) When an optional xml:lang 3021 attribute is omitted from an element, no xml:lang attribute will be saved for that element. 3022

Name elements in UDDI core data structures are frequently the main targets for sorts during 3023 UDDI inquiries. When a UDDI data structure has multiple names, sorting occurs on the first 3024 name. Care should be taken to list the primary name first when the entity is saved to ensure 3025 the proper placement of the entity in a sorted result set. 3026

Values which can be passed in the language supplied in a save_xx API call MUST obey the 3027 recommended rules and syntax governing the xml:lang data type as defined in Section 3.3.2.3 3028 name. 3029

5.2.5 Publisher API summary 3030

The publishing API calls are: 3031

• add_publisherAssertions: Used to add relationship assertions to the existing set of 3032 assertions. See Appendix A Relationships and Publisher Assertions. 3033

• delete_binding: Used to remove an existing bindingTemplate from the registry. 3034

• delete_business: Used to delete existing businessEntity information from the 3035 registry. 3036

• delete_publisherAssertions: Used to delete specific publisher assertions from the 3037 assertion collection controlled by a particular publisher. Deleting assertions from the 3038 assertion collection affects the visibility of business relationships. Deleting an 3039 assertion causes any relationships based on that assertion to become incomplete. 3040

• delete_service: Used to delete an existing businessService from the registry. 3041

• delete_tModel: Used to hide existing information about a tModel. Any tModel hidden 3042 in this way is still usable for reference purposes and accessible via the 3043 get_tModelDetail API, but is hidden from find_tModel result sets. There is no 3044 specified way to delete a tModel. 3045

• get_assertionStatusReport: Used to get a status report containing publisher 3046 assertions and status information. This report is useful to help an administrator 3047 manage publisher assertions. Returns an assertionStatusReport that includes the 3048 status of all assertions made involving any businessEntity controlled by the requesting 3049 publisher. 3050

• get_publisherAssertions: Used to get a list of publisher assertions that are 3051 controlled by an individual publisher. Returns a publisherAssertions structure 3052 containing all publisher assertions associated with a specific publisher. 3053

• get_registeredInfo: Used to request an abbreviated list of businesses and tModels 3054 currently managed by a given publisher. 3055

• save_binding: Used to register new bindingTemplate information or to update 3056 existing bindingTemplate information. Use this to control information about technical 3057 capabilities exposed by a registered business. 3058


95/405

• save_business: Used to register new businessEntity information or update existing 3059 businessEntity information. Use this to control the full set of information about the 3060 entire business, including its businessService and bindingTemplate structures. This 3061 API has the broadest effect of all of the save_xx APIs. 3062

• save_service: Used to register or update complete information about a 3063 businessService. 3064

• save_tModel: Used to register or update information about a tModel. 3065

• set_publisherAssertions: Used to save the complete set of publisher assertions for 3066 an individual publisher. Replaces any existing assertions, and causes any old 3067 assertions that are not reasserted to be removed from the registry. 3068

3069

3070

5.2.6 add_publisherAssertions 3071

The add_publisherAssertions API call causes one or more publisherAssertions to be added to 3072 an individual publisher’s assertion collection. See Appendix A Relationships and Publisher 3073 Assertions describing relationships and the API get_publisherAssertions for more information 3074 on this collection. 3075

5.2.6.1 Syntax: 3076

3077

5.2.6.2 Arguments: 3078

• authInfo: This optional argument is an element that contains an authentication token. 3079 Authentication tokens are obtained using the get_authToken API call or through some 3080 other method external to this specification. Registries that serve multiple publishers 3081 and registries that restrict who can publish in them typically require authInfo for this 3082 call. 3083

• publisherAssertion: This required repeating element holds the relationship 3084 assertions that are being added. Relationship assertions consist of a reference to two 3085 businessEntity key values as designated by the fromKey and toKey elements, as well 3086 as a REQUIRED expression of directional relationship within the contained 3087 keyedReference element. See Appendix A Relationships and PublisherAssertions on 3088 managing relationships. The fromKey, the toKey, and all three parts of the 3089 keyedReference – the tModelKey, the keyName, and the keyValue MUST be 3090 specified or the call will fail with the error E_fatalError. Empty (zero length) keyNames 3091 and keyValues are permitted. 3092

5.2.6.3 Behavior: 3093

The publisher must own the businessEntity referenced in the fromKey, the toKey, or both. If 3094 both of the businessKey values passed within an assertion are owned by the publisher, then 3095 the assertion is automatically complete and the relationship described in the assertion is visible 3096 via the find_relatedBusinesses API. To form a relationship when the publisher only owns one 3097


96/405

of the two keys passed, the assertion MUST be matched exactly by an assertion made by the 3098 publisher who owns the other business referenced. Assertions exactly match if and only if they: 3099

1. refer to the same businessEntity in their fromKeys; 3100

2. refer to the same businessEntity in their toKeys; 3101

3. refer to the same tModel in their tModelKeys; 3102

4. have identical keyNames; and 3103

5. have identical keyValues. 3104

When a publisherAssertion being added references a checked relationship system using the 3105 tModelKey in the contained keyedReference, the reference MUST be checked for validity prior 3106 to completion of the add, or the node must return E_unsupported, indicating it does not support 3107 the referenced checked relationship system. Validation of a relationship system reference 3108 entails verification that the reference is valid according to the validation algorithm defined for 3109 the relationship system and described by its tModel. For cached checked relationship 3110 systems, the validation algorithm verifies that referenced keyValues are in the set of valid 3111 values for the relationship system. 3112

5.2.6.4 Returns: 3113

Upon successful completion, a dispositionReport structure is returned with a single success 3114 indicator. 3115

5.2.6.5 Caveats: 3116

If an error occurs in processing this API call, a dispositionReport structure MUST be returned 3117 to the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the 3118 errors common to all APIs, the following error information is relevant here: 3119

• E_invalidKeyPassed: signifies that one of the uddiKey values passed did not match 3120 with any known businessKey or tModelKey values. The key and element or attribute 3121 that caused the problem SHOULD be clearly indicated in the error text. 3122

• E_userMismatch: signifies that neither of the businessKey values passed in the 3123 embedded fromKey and toKey elements is owned by the publisher associated with 3124 the authentication token. The error text SHOULD clearly indicate which assertion 3125 caused the error. 3126


97/405

3127

5.2.7 delete_binding 3128

The delete_binding API call causes one or more instances of bindingTemplate data to be 3129 deleted from the UDDI registry. 3130

5.2.7.1 Syntax: 3131

3132

3133

5.2.7.2 Arguments: 3134

• authInfo: This optional argument is an element that contains an authentication token. 3135 Authentication tokens are obtained using the get_authToken API call or through some 3136 other method external to this specification. Registries that serve multiple publishers 3137 and registries that restrict who can publish in them typically require authInfo for this 3138 call. 3139

• bindingKey: One or more required uddiKey values that represent specific instances 3140 of known bindingTemplate data. 3141

5.2.7.3 Returns: 3142

Upon successful completion, a dispositionReport is returned with a single success indicator. 3143 Section 4.8 Success and Error Reporting. 3144

5.2.7.4 Caveats: 3145


• E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match 3149 with any known bindingKey values or multiple instances of the same bindingKey 3150 values were passed. No partial results are returned – if any bindingKey values 3151 passed are not valid, this error is returned. The key that caused the problem 3152 SHOULD clearly be indicated in the error text. 3153

• E_userMismatch: Signifies that one or more of the bindingKey values passed refers 3154 to a bindingTemplate that is not owned by the individual publisher associated with the 3155 authentication token. 3156


98/405

5.2.8 delete_business 3157

The delete_business API call is used to remove one or more business registrations and all 3158 elements that correspond to the natural content of the corresponding businessEntity elements 3159 from a UDDI registry. 3160

5.2.8.1 Syntax: 3161

3162

3163

5.2.8.2 Arguments: 3164

• authInfo: This optional argument is an element that contains an authentication token. 3165 Authentication tokens are obtained using the get_authToken API call or through some 3166 other means external to this specification. Registries that serve multiple publishers 3167 and registries that restrict who can publish in them typically require authInfo for this 3168 call. 3169

• businessKey: One or more required uddiKey values that represent specific instances 3170 of known businessEntity data. 3171

5.2.8.3 Behavior: 3172

The UDDI registry MUST permanently remove all of the natural contents22 of the passed 3173 businessEntity elements, including any currently nested businessService and bindingTemplate 3174 data, from the UDDI registry. 3175

If there are service projections23 that reference businessService elements deleted in this way, 3176 they are left untouched. Such “broken” service projections appear in their businessEntity as 3177 businessService elements containing the businessKey and serviceKey attributes as their only 3178 content. For this reason, it is a best practice to coordinate references to businessService data 3179 published under another businessEntity with the party who manages that data. 3180

All publisher assertions that reference the businessKey of the businessEntity being deleted in 3181 either the fromKey or toKey of the publisherAssertion MUST be automatically deleted. A 3182 deleted business MUST not be returned in the find_relatedBusinesses API. 3183

3184

22

When a business registration is first saved, all of the contained data found in the registered businessEntity element is referred to as the natural contents. UDDI defines several types of referencing mechanisms – and referenced elements are not considered to be natural contents of registered businessEntity data. Natural contents can be recognized by matching businessKey values between businessService and businessEntity data, or matching serviceKey values between businessService elements and bindingTemplate elements.

23 UDDI allows save_business API calls to be processed that contain businessService data references that are the natural children

of a different business registration. Doing this creates a businessService projection that results in the data associated with the referenced businessService to be projected as though it were contained in the referencing businessEntity. These are called service projections.


99/405

5.2.8.4 Returns: 3185

Upon successful completion, a dispositionReport structure is returned with a single success 3186 indicator. See Section 4.8 Success and Error Reporting. 3187

5.2.8.5 Caveats: 3188

If an error occurs in processing this API call, a dispositionReport element MUST be returned to 3189 the caller within a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to 3190 the errors common to all APIs, the following error information is relevant here: 3191

• E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match 3192 with any known businessKey values or multiple instances of the same businessKey 3193 values were passed. The key that caused the error SHOULD be clearly indicated in 3194 the error text. 3195

• E_userMismatch: Signifies that one or more of the businessKey values passed 3196 refers to data that is not owned by the individual publisher who is represented by the 3197 authentication token. 3198

3199


100/405

5.2.9 delete_publisherAssertions 3200

The delete_publisherAssertions API call causes one or more publisherAssertion elements to 3201 be removed from a publisher’s assertion collection. See Appendix A Relationships and 3202 Publisher Assertions and the API get_publisherAssertions for more information on this 3203 collection. 3204

5.2.9.1 Syntax: 3205

3206

5.2.9.2 Arguments: 3207


• publisherAssertion: One or more required publisher assertion structures exactly 3213 matching an existing assertion in the publisher’s assertion collection. 3214

5.2.9.3 Behavior: 3215

The UDDI registry scans the assertion collection associated with the publisher, and removes 3216 any assertions that exactly match all parts of each publisherAssertion passed. Any assertions 3217 described that cannot be located result in an error. The removal of assertions in this API 3218 causes the corresponding relationships to no longer be visible via the find_relatedBusinesses 3219 API. 3220

5.2.9.4 Returns: 3221


5.2.9.5 Caveats: 3224


• E_assertionNotFound: Signifies that one of the assertion structures passed does not 3228 have any corresponding match in the publisher’s assertion collection or multiple 3229 instances of the same publisherAssertions elements were passed. The assertion that 3230 caused the problem SHOULD be clearly indicated in the error text. 3231


101/405

5.2.10 delete_service 3232

The delete_service API call is used to remove one or more businessService elements from the 3233 UDDI registry and from its containing businessEntity parent. 3234

5.2.10.1 Syntax: 3235

3236

5.2.10.2 Arguments: 3237


• serviceKey: One or more required uddiKey values that represent specific instances 3243 of known businessService data. 3244

5.2.10.3 Returns: 3245

Upon successful completion, a dispositionReport is returned with a single success indicator. 3246 See Section 4.8 Success and Error Reporting. 3247

All contained bindingTemplate data MUST also be removed from the registry as a result of this 3248 call. 3249

If a business service being deleted is the target of a business service projection associated 3250 with another businessEntity, the referencing businessService elements are left untouched. 3251 Such “broken” service projections appear in their businessEntity and businessService 3252 elements containing the businessKey and serviceKey attributes as their only content. For this 3253 reason, it is recommended that references to businessService data published under another 3254 businessEntity be coordinated with the party that manages that data. 3255

5.2.10.4 Caveats: 3256


• E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match 3260 with any known serviceKey values or multiple instances of the same serviceKey 3261 values were passed. The key causing the error SHOULD be clearly indicated in the 3262 error text. 3263

• E_userMismatch: Signifies that one or more of the serviceKey values passed refers 3264 to data that is not owned by the individual publisher who is represented by the 3265 authentication token. 3266


102/405

3267

5.2.11 delete_tModel 3268

The delete_tModel API call is used to logically delete one or more tModel structures. Logical 3269 deletion hides the deleted tModels from find_tModel result sets but does not physically delete 3270 them. New references to deleted (hidden) tModels can be established by publishers that know 3271 their keys. Deleting an already deleted tModel has no effect. 3272

5.2.11.1 Syntax: 3273

3274

3275

5.2.11.2 Arguments: 3276


• tModelKey: One or more required uddiKey values that represent specific instances of 3282 known tModel data. 3283

5.2.11.3 Returns: 3284


If a tModel is hidden in this way it MUST not be physically deleted as a result of this call. Any 3287 tModels hidden in this way are still accessible, via the get_registeredInfo and get_tModelDetail 3288 APIs, but are omitted from any results returned by calls to find_tModel. All other inquiry APIs 3289 may include references to tModelKeys of deleted tModelKeys, and UDDI data structures that 3290 reference these tModels are found and retrieved. 3291

The purpose of the delete_tModel behavior is to ensure that the details associated with a 3292 hidden tModel are still available to anyone currently using the tModel. A hidden tModel can be 3293 restored and made visible to search results by invoking the save_tModel API at a later time, 3294 passing the original data and the tModelKey value of the hidden tModel. 3295

5.2.11.4 Caveats: 3296


• E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match 3300 with any known tModelKey values or multiple instances of the same tModelKey 3301 values were passed. The invalid key references SHOULD be clearly indicated in the 3302 error text. 3303


103/405

• E_userMismatch: Signifies that one or more of the tModelKey values passed refers 3304 to data that is not owned by the individual publisher who is represented by the 3305 authentication token. 3306

3307


104/405

5.2.12 get_assertionStatusReport 3308

The get_assertionStatusReport API call provides administrative support for determining the 3309 status of current and outstanding publisher assertions that involve any of the business 3310 registrations managed by the individual publisher. Using this API, a publisher can see the 3311 status of assertions that they have made, as well as see assertions that others have made that 3312 involve businessEntity structures controlled by the requesting publisher. See Appendix A 3313 Relationships and Publisher Assertions for more information. 3314

5.2.12.1 Syntax: 3315

3316

5.2.12.2 Arguments: 3317


• completionStatus: This optional argument lets the publisher restrict the result set to 3323 only those relationships that have the specified status value. Assertion status is a 3324 calculated result based on the sum total of assertions made by the individuals that 3325 control specific business registrations. When no completionStatus element is 3326 provided, all assertions involving the businesses that the publisher owns are retrieved, 3327 without regard to the completeness of the relationship. completionStatus MUST 3328 contain one of the following values 3329

o status:complete: Passing this value causes only the publisher assertions 3330 that are complete to be returned. Each businessEntity listed in assertions 3331 that are complete has a visible relationship that directly reflects the data in a 3332 complete assertion (as described in the find_relatedBusinesses API). 3333

o status:toKey_incomplete: Passing this value causes only those publisher 3334 assertions where the party who controls the businessEntity referenced by the 3335 toKey value in an assertion, has not made a matching assertion, to be listed. 3336

o status:fromKey_incomplete: Passing this value causes only those 3337 publisher assertions where the party who controls the businessEntity 3338 referenced by the fromKey value in an assertion, has not made a matching 3339 assertion, to be listed. 3340


105/405

3341

5.2.12.3 Returns: 3342

Upon successful completion, an assertionStatusReport structure is returned containing zero or 3343 more assertionStatusItem structures. 3344

The assertionStatusReport has the form: 3345

3346

The assertionStatusReport reports all complete and incomplete assertions and serves an 3347 administrative use for determining if there are any outstanding, incomplete assertions 3348 pertaining to relationships involving businesses with which the publisher is associated. 3349

Since the publisher who was authenticated by the get_assertionStatusReport API may own 3350 several businesses, the assertionStatusReport structure shows the assertions made for all 3351 businesses owned by the publisher. 3352

The assertion status report is composed of a set of assertionStatusItem elements that describe 3353 the assertions in which the publisher’s businesses participate. The assertionStatusItem 3354 element has the form: 3355

3356

3357

The assertionStatusItem structure has the following attribute: 3358

Name Use

completionStatus required

3359

While the elements fromKey, toKey and keyedReference together identify the assertion on 3360 whose status a report is being provided, the keysOwned element designates those 3361 businessKeys the publisher manages. The keysOwned element has the form: 3362

3363


106/405

An assertion is part of a reciprocal relationship only if the completionStatus attribute has a 3364 value “status:complete”. If completionStatus has a value “status:toKey_incomplete” or 3365 “status:fromKey_incomplete”, the party who controls the businessEntity referenced by the 3366 toKey or the fromKey has not yet made a matching assertion. 3367

5.2.12.4 Caveats: 3368


• E_invalidCompletionStatus: Signifies that the completionStatus value passed is 3372 unrecognized. The completion status that caused the problem SHOULD be clearly 3373 indicated in the error text. 3374


107/405

3375

5.2.13 get_publisherAssertions 3376

The get_publisherAssertions API call is used to obtain the full set of publisher assertions that is 3377 associated with an individual publisher. It complements the get_registeredInfo API which 3378 returns information about businesses, services, bindings, and tModels managed by a 3379 publisher. 3380

5.2.13.1 Syntax: 3381

3382

5.2.13.2 Arguments: 3383


5.2.13.3 Returns: 3389

This API call returns a publisherAssertions structure that contains a publisherAssertion 3390 element for each publisher assertion registered by the publisher. When the registry 3391 distinguishes between publishers, this information is associated with the authentication 3392 information. Only assertions made by the publisher are returned. See 3393 get_assertionStatusReport and Appendix A Relationships and Publisher Assertions for more 3394 details. 3395

The publisherAssertions structure has the form: 3396

3397

3398

3399

5.2.13.4 Caveats: 3400

None, other than those common to all UDDI APIs. See Section 12.1 Common Error Codes. 3401

3402

3403


108/405

3404

5.2.14 get_registeredInfo 3405

The get_registeredInfo API call is used to get an abbreviated list of all businessEntity and 3406 tModel data that are controlled by a publisher. When the registry distinguishes between 3407 publishers, this is the individual associated with the credentials passed in the authInfo element. 3408 This returned information is intended, for example, for driving tools that display lists of 3409 registered information and then provide drill-down features. This is the recommended API to 3410 use after a network problem results in an unknown status of saved information. 3411

3412

5.2.14.1 Syntax: 3413

3414

3415

Attributes 3416

Name Use

infoSelection required

3417

5.2.14.2 Arguments: 3418


• infoSelection: This required argument represents an enumerated choice that 3424 determines which tModels are returned. “all” indicates all visible and hidden tModels 3425 owned by the publisher are to be returned (this is the default). “visible” indicates only 3426 visible tModels owned by the publisher are to be returned. “hidden” indicates only 3427 hidden (logically deleted) tModels owned by the publisher are to be returned. 3428

5.2.14.3 Returns: 3429

Upon successful completion, a registeredInfo structure MUST be returned, listing abbreviated 3430 business information in one or more businessInfo elements, and tModel information in one or 3431 more tModelInfo elements. This API is useful for determining the full extent of registered 3432 business and tModel information owned by a single publisher in a single call. This structure 3433 complements the get_publisherAssertions API call, which returns information about assertions 3434 owned by an individual publisher. 3435

The registeredInfo structure has the form: 3436


109/405

3437

5.2.14.4 Caveats: 3438

None, other than those common to all UDDI APIs. See Section 12.1 Common Error Codes. 3439

3440

5.2.15 save_binding 3441

The save_binding API call is used to save or update a complete bindingTemplate element. It 3442 can be used to add or update one or more bindingTemplate elements as well as the 3443 container/contained relationship that each bindingTemplate has with one or more existing 3444 businessService elements. Each bindingTemplate MAY be signed and MAY have publisher-3445 assigned keys. 3446

5.2.15.1 Syntax: 3447

3448

5.2.15.2 Arguments: 3449


• bindingTemplate: Required repeating element containing one or more complete 3455 bindingTemplate structures. To save a new bindingTemplate, a bindingTemplate 3456 element is passed with either an empty bindingKey attribute value, or with a publisher-3457 assigned bindingKey. See Section 5.2.2.2 Behavior of Publishers. 3458

5.2.15.3 Behavior 3459

Each new bindingTemplate passed MUST contain a serviceKey value that corresponds to a 3460 registered businessService controlled by the same publisher. An existing binding template 3461 MAY contain a serviceKey value that corresponds to a registered businessService controlled 3462 by the same publisher. The net effect of this call is to determine the containing parent 3463 businessService for each bindingTemplate affected by this call. If the same bindingTemplate 3464 (determined by matching bindingKey value) is listed more than once, any relationship to the 3465 containing businessService is determined by processing order, which is determined by the 3466 position of the bindingTemplate data in first to last order. 3467

�� unless the

�� can be obtained through

inspecting the structure in which the bindingTemplate resides


110/405

If the bindingKey within a bindingTemplate element is missing or is passed with an empty 3468 value, this is a signal that the bindingTemplate is being inserted for the first time. When this 3469 occurs, the node MUST automatically generate a new key for the bindingTemplate that is 3470 without an associated key. New bindingTemplate structures can also be added with publisher-3471 assigned keys. See Section 5.2.2.2 Behavior of Publishers. 3472

Using this API call it is possible to move an existing bindingTemplate from one 3473 businessService to another by simply specifying a different parent businessService 3474 relationship along with the complete bindingTemplate. Changing a parent relationship in this 3475 way causes two businessService structures to be affected. The net result of such a move is 3476 that the bindingTemplate still resides within one, and only one businessService based on the 3477 value of the serviceKey passed. An attempt to move a bindingTemplate in this manner by a 3478 party who is not the publisher of the businessService that is specified by the serviceKey MUST 3479 be rejected with an error E_userMismatch. 3480

When a bindingTemplate is saved with a categoryBag content that is associated with a 3481 checked value set or category group system tModel, the references MUST be checked for 3482 validity prior to completion of the save, or the node must return E_unsupported, indicating it 3483 does not support the referenced checked value set or category group system. See Section 3484 5.2.3 Special considerations for validated value sets and Appendix F Using Categorization for 3485 additional details. 3486

5.2.15.4 Returns: 3487

This API returns a bindingDetail structure containing the results of the call that reflects the 3488 newly registered information for the effected bindingTemplate elements. If more than one 3489 bindingTemplate is saved in a single save_binding call, the resulting bindingDetail MUST 3490 return results in the same order that they appeared in the save_binding call. If the same 3491 bindingTemplate (determined by matching bindingKey) is listed more than once in the 3492 save_binding call, it MAY be listed once in the result for each appearance in the save_binding 3493 call. If the same bindingTemplate appears more than once in the response, the last occurrence 3494 of the bindingTemplate in the results represents the state stored in the registry. Any 3495 bindingKeys that were assigned as a result of processing the save_binding call are included in 3496 the bindingTemplate data. 3497

The bindingDetail structure has the form: 3498

3499

5.2.15.5 Caveats: 3500

If an error occurs in processing this API call, a dispositionReport element MUST be returned to 3501 the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. In addition to the 3502 errors common to all APIs, the following error information is relevant here: 3503

• E_accountLimitExceeded: Signifies that user account limits have been exceeded. 3504

• E_invalidKeyPassed: Signifies that the request cannot be satisfied because one or 3505 more uddiKey values specified are not valid key values for the entities being 3506 published. tModelKey, serviceKey, or bindingKey values that either do not exist, or 3507 exist with a different entity type, or are not authorized to be proposed by the publisher 3508 are considered to be invalid values. The key causing the error SHOULD be clearly 3509 indicated in the error text. This error code will also be returned in the event that the 3510 serviceKey is not provided and the bindingKey is either absent or has a value not 3511

�� in

�� is

�� a

�� ,

�� the publisher is not

authorized to publish an entity ��

the��

value, or that a tModelKey��

a categoryBag keyedReference is missing or invalid


111/405

registered in the registry. In this case, the error text SHOULD clearly indicate the use 3512 of an incomplete bindingTemplate. 3513

• E_invalidValue: A value that was passed in a keyValue attribute did not pass 3514 validation. This applies to checked value sets that are referenced using 3515 keyedReferences. The error text SHOULD clearly indicate the key and value 3516 combination that failed validation. 3517

• E_keyUnavailable: Indicates that the proposed key has already been assigned to 3518 some other publisher or is not within the partition defined by a key generator tModel 3519 that the publisher owns. 3520

• E_requestTimeout: Signifies that the request could not be carried out because a 3521 needed validate_values service did not respond in a reasonable amount of time. 3522 Details identifying the failing Web service SHOULD be included in the 3523 dispositionReport element. 3524

• E_userMismatch: Signifies that one or more of the uddiKey values passed refers to 3525 data that is not owned by the individual publisher who is represented by the 3526 authentication token. 3527

• E_valueNotAllowed: Restrictions have been placed by the value set provider on the 3528 types of information that should be included at that location within a specific value set. 3529 A validate_values Web service chosen by the UDDI node has rejected this 3530 businessEntity for at least one specified keyedReference. The error text SHOULD 3531 clearly indicate the keyedReference that was not successfully validated. 3532

�� keyGenerator


112/405

3533

5.2.16 save_business 3534

The save_business API call is used to save or update information about a complete 3535 businessEntity structure. This API has the broadest scope of all of the save_xx API calls, and 3536 can be used to make sweeping changes to the published information for one or more 3537 businessEntity elements controlled by an individual. 3538

This API call can be used to establish a reference relationship to businessService structures 3539 that are managed as the contents of another businessEntity. In this way, a businessService 3540 that is a natural part of one businessEntity can appear as a projected service of another 3541 businessEntity. The content of a businessService projected in this way (by way of a reference 3542 established by this API) are not managed as a part of the referencing entity. 3543

businessEntity structures MAY be signed and MAY have publisher-assigned keys. 3544

5.2.16.1 Syntax: 3545

3546

5.2.16.2 Arguments: 3547


• businessEntity: Required repeating element containing one or more businessEntity 3553 structures. These can be obtained in advance by using the get_businessDetail API 3554 call or by any other means. 3555

5.2.16.3 Behavior: 3556

If any of the uddiKey values within a businessEntity element (e.g. any data with a key value 3557 regulated by a businessKey, serviceKey or bindingKey) is missing or is passed with an empty 3558 value, this is a signal that the data that is so keyed is being inserted for the first time.24 When 3559 this occurs, the node MUST automatically generate a new key for the data passed that is 3560 without an associated key. New entities can also be added with publisher-assigned keys. See 3561 Section 5.2.2.2 Behavior of Publishers. 3562

To make this API call perform an update to existing registered data, the keyed entities 3563 (businessEntity, businessService or bindingTemplate) MUST have uddiKey values that 3564 correspond to the registered data to be updated. 3565

24

This does not apply to structures that use keys to refer to other keyed data, such as tModelKey references within bindingTemplate or keyedReference structures, since these are references. These keys MUST contain values that refer to actual entities.

�� <sp>¶

�� in


113/405

Data can be deleted with this API call when registered information is different from the new 3566 information provided. Any businessService and bindingTemplate structures found in the 3567 custodial UDDI node, but missing from the businessEntity information provided in this call, are 3568 deleted from the registry by this call. 3569

Data contained within businessEntity structures can be rearranged with this API call. This can 3570 be done by redefining parent container relationships for other registered information. For 3571 instance, if a new businessEntity is saved with information about a businessService that is 3572 registered already as part of a different businessEntity, this results in the businessService 3573 being moved from its current container to the new businessEntity. This condition occurs when 3574 the businessKey of the businessService being saved matches the businessKey of the 3575 businessEntity being saved. An attempt to delete or move a businessService in this manner by 3576 a party who is not the publisher of the businessService MUST be rejected with an error 3577 E_userMismatch. 3578

If the businessEntity being saved contains a businessService that has a businessKey referring 3579 to some businessEntity other than the businessEntity being saved, the UDDI registry notes a 3580 reference, called a “service projection”, to the existing businessService. Subsequent calls to 3581 the get_businessDetail API, passing either the businessKey of the businessEntity that contains 3582 the referenced businessService or the businessKey of the businessEntity that contains the 3583 service projection will result in an identical businessService element being included as part of 3584 the result set. 3585

A businessEntity must not contain a businessService and a service projection to this 3586 businessService. As a result, a businessService cannot be moved to a businessEntity that 3587 already has a service projection to that businessService. Regardless of the order of operation, 3588 a businessService and a service projection can never appear under the same businessEntity. 3589 Implementations are required to reject and return an E_fatalError during such a save_business 3590 operation. 3591

No changes to the referenced businessService are effected by the act of establishing a service 3592 projection. Existing service projections associated with the businessEntity being saved that 3593 are not contained in the call to save_business are deleted automatically. This reference 3594 deletion does not cause any changes to the referenced businessService. If the referenced 3595 businessService is deleted by any means, all references to it associated with other 3596 businessEntity structures are left untouched. Such “broken” service projections appear in their 3597 businessEntity as businessService elements containing the businessKey and serviceKey 3598 attributes as their only content. If the businessService is moved to another business, all 3599 projections will be updated to reflect the new businessKey25. For this reason, it is good practice 3600 to coordinate references to businessService data published under another businessEntity with 3601 the party who manages that data 3602

When saving a businessEntity containing a service projection, all of the content of the 3603 businessService provided in the save_business, with the exception of the serviceKey and 3604 businessKey, is ignored. The businessKey and serviceKey of the businessService being 3605 referenced are used to determine if the businessService is for a service projection or not. If the 3606 businessService identified by the serviceKey is not part of the businessEntity identified by the 3607 businessKey, the error E_invalidProjection will be returned. 3608

When a businessEntity is saved with identifierBag or categoryBag contents that is associated 3609 with a checked value set or category group system tModel, the references MUST be checked 3610 for validity prior to completion of the save or the node must return E_unsupported, indicating it 3611 does not support the referenced checked value set or category group system. See Section 3612

25 This solution emphasizes that in all circumstances the real service should be used to retrieve the properties within a service projection. Based on this premise, there should be no validation or ownership verification done on the businessKey associated with a service during replication.

�� than

�� is

�� (

�� )

��

�� or moved

�� .


114/405

5.2.3 Special considerations for validated value sets, Appendix E Using Identifiers and 3613 Appendix F Using Categorization for additional details. 3614

5.2.16.4 Returns: 3615

This API returns a businessDetail structure containing the final results of the call that reflects 3616 the new registered information for the businessEntity information provided. Any businessKey, 3617 serviceKey, or bindingKey attributes that were assigned as a result of processing the 3618 save_business are included in the returned data. These results include any businessService 3619 elements that are contained by reference. If the same entity (businessEntity, businessService, 3620 or bindingTemplate), determined by matching key, is listed more than once in the 3621 save_business call, it MAY be listed once in the result for each appearance in the call. If the 3622 same entity appears more than once in the response, the last appearance occurrence of the 3623 entity in the results represents the final saved state stored in the registry. 3624

The businessDetail has the form: 3625

3626

5.2.16.5 Caveats 3627



• E_invalidKeyPassed: Signifies that the request cannot be satisfied because one or 3632 more uddiKey values specified are not valid key values for the entities being 3633 published. tModelKey, businessKey, serviceKey, or bindingKey values that either do 3634 not exist, or exist with a different entity type, or are not authorized to be proposed by 3635 the publisher are considered to be invalid values. The key causing the error SHOULD 3636 be clearly indicated in the error text. 3637

• E_invalidProjection: Signifies that an attempt was made to save a businessEntity 3638 containing a service projection where the businessService being projected is not a 3639 part of the businessEntity that is identified by the businessKey in the businessService. 3640 The serviceKey of at least one such businessService SHOULD be included in the 3641 dispositionReport. 3642

• E_userMismatch: Signifies that one or more of the uddiKey values passed refers to 3643 data that is not owned by the individual publisher who is represented by the 3644 authentication token. The key causing the error SHOULD be clearly indicated in the 3645 error text. 3646

• E_invalidValue: A value that was passed in a keyValue attribute did not pass 3647 validation. This applies to checked value sets that are referenced using 3648 keyedReferences. The error text SHOULD clearly indicate the key and value 3649 combination that failed validation. 3650


• E_requestTimeout: Signifies that the request could not be carried out because a 3654 needed validate_values service did not respond in a reasonable amount of time. 3655

�� stricture

�� is

�� a

�� value

�� entity

�� An invalid value may be

caused by ��

references��

by references to serviceKey or ��

otherwise

�� keyGenerator


115/405

Details identifying the failing Web service SHOULD be included in the 3656 dispositionReport element. 3657

• E_unsupported: A keyedReference in a categoryBag or an identifierBag that 3658 references a checked value set cannot be validated by the UDDI node because the 3659 node does not support the referenced checked value set. The error text should 3660 clearly indicate the keyedReference that cannot be validated. 3661

• E_unvalidatable: A keyedReference in a categoryBag or an identifierBag that 3662 references a checked value set cannot be validated by the UDDI node because the 3663 referenced tModel has been marked unvalidatable. The error text should clearly 3664 indicate the keyedReference that cannot be validated. 3665

• E_valueNotAllowed: Restrictions have been placed by the value set provider on the 3666 types of information that should be included at that location within a specific value set. 3667 A validate_values Web service chosen by the UDDI node has rejected this 3668 businessEntity for at least one specified keyedReference. The error text SHOULD 3669 clearly indicate the keyedReference that was not successfully validated. 3670


116/405

3671

5.2.17 save_service 3672

The save_service API call adds or updates one or more businessService elements. Each 3673 businessService MAY be signed and MAY have publisher-assigned keys. 3674

5.2.17.1 Syntax: 3675

3676

5.2.17.2 Arguments: 3677


• businessService: Required repeating element containing one or more complete 3683 businessService elements. For the purpose of performing round trip updates, this 3684 data can be obtained in advance by using the get_serviceDetail API call or by any 3685 other means. 3686

5.2.17.3 Behavior: 3687

Each new businessService passed MUST contain a businessKey value that corresponds to a 3688 registered businessEntity controlled by the same publisher. An existing business service MAY 3689 contain a businessKey value that corresponds to a registered businessEntity controlled by the 3690 same publisher. 3691

If any of the uddiKey values within a businessService element (i.e., any data with a key value 3692 regulated by a serviceKey or bindingKey) is passed with an empty value, this is a signal that 3693 the data that is so keyed is being inserted for the first time. 26 In this case, a new key value 3694 MUST be automatically generated for the data which was passed without an associated key 3695 value. New entities can also be added with publisher-assigned keys. See Section 5.2.2.2 3696 Behavior of Publishers. 3697

If the same businessService is contained in more than one businessService argument, the 3698 final relationship to the containing businessEntity is determined by processing order – which is 3699 determined by first to last order of the information passed in the request. Analogously, if the 3700 same bindingTemplate is specified in the call as being in more than one businessService, the 3701 businessService that is its container at the conclusion of the call is last one listed. 3702

26

This does not apply to structures that use keys to refer to other keyed data, such as tModelKey references within bindingTemplate or keyedReference structures, since these are references. These keys MUST contain values that refer to actual entities.

�� who is making the save_

�� request.¶

If any of the uddiKey values within


117/405

Using this API call it is possible to move an existing bindingTemplate element from one 3703 businessService element to another, or move an existing businessService element from one 3704 businessEntity to another by simply specifying a different parent businessEntity relationship. 3705 Changing a parent relationship in this way causes two businessEntity or two businessService 3706 structures to be changed. An attempt to move a bindingTemplate or a businessService in this 3707 manner by a party who is not the publisher of the businessService that is specified by the 3708 serviceKey or the businessEntity that is specified by the businessKey MUST be rejected with 3709 an error E_userMismatch. 3710

When a businessService is saved with categoryBag contents that is associated with a checked 3711 value set or category group system tModel, the references MUST be checked for validity prior 3712 to completion of the save or the node MUST return E_unsupported, indicating it does not 3713 support the referenced checked value set or category group system. See Section 5.2.3 3714 Special considerations for validated value sets and Appendix F Using Categorization for 3715 additional details. 3716

5.2.17.4 Returns: 3717

This API call returns a serviceDetail containing the final results of the call that reflects the newly 3718 registered information for the affected businessService elements. In cases where multiple 3719 businessService elements are passed in the request, the result contains the final results for 3720 each businessService passed and these appear in the same order as found in the request. 3721 Any serviceKey and bindingKey values that were assigned as a result of processing the 3722 save_service API are included in the businessService data. 3723

If the same entity (businessService, or bindingTemplate), determined by matching key, is listed 3724 more than once in the save_service API, it MAY be listed once in the result for each 3725 appearance in the save_service API. If the same entity appears more than once in the 3726 response, the last occurrence of the entity in the results represents the state stored in the 3727 registry. 3728

The serviceDetail has the form: 3729

3730

3731

5.2.17.5 Caveats: 3732



• E_invalidKeyPassed: Signifies that the request cannot be satisfied because one or 3737 more uddiKey values specified are not valid key values for the entities being 3738 published. tModelKey, businessKey, serviceKey, or bindingKey values that either do 3739 not exist, or exist with a different entity type, or are not authorized to be proposed by 3740 the publisher are considered to be invalid values. The key causing the error SHOULD 3741 be clearly indicated in the error text. This error code will also be returned in the event 3742 that the businessKey is not provided and the serviceKey is either absent or has a 3743

�� is

�� a

�� the publisher is not

authorized to publish an entity ��

the ��

key value. An invalid key value may be caused ��

a tModelKey reference��

non-existent tModel data.


118/405

value not registered in the registry. In this case, the error text SHOULD clearly 3744 indicate the use of an incomplete businessService. 3745

• E_invalidValue: A value that was passed in a keyValue attribute did not pass 3746 validation. This applies to checked value sets referenced using keyedReferences. 3747 The error text SHOULD clearly indicate the key and value combination that failed 3748 validation. 3749


• E_requestTimeout: Signifies that the request could not be carried out because a 3753 needed validate_values service did not respond in a reasonable amount of time. 3754 Details identifying the failing Web service SHOULD be included in the 3755 dispositionReport element. 3756


• E_unsupported: A keyedReference in a categoryBag that references a checked 3760 value set cannot be validated by the UDDI node because the node does not support 3761 the referenced checked value set. The error text SHOULD clearly indicate the 3762 keyedReference that cannot be validated. 3763

• E_unvalidatable: A keyedReference in a categoryBag that references a checked 3764 value set cannot be validated by the UDDI node because the referenced tModel has 3765 been marked unvalidatable. The error text SHOULD clearly indicate the 3766 keyedReference that cannot be validated. 3767

• E_valueNotAllowed: The value set validation routine chosen by the UDDI node has 3768 rejected the businessService data provided. The error text SHOULD clearly indicate 3769 the keyedReference that was not successfully validated. 3770

�� keyGenerator

�� should

�� should


119/405

3771

5.2.18 save_tModel 3772

The save_tModel API call adds or updates one or more registered tModel elements. tModels 3773 MAY be signed and tModels MAY be saved with publisher-assigned keys, including those 3774 tModels that establish the domain partition of publisher-assigned keys, known as domain key 3775 generator tModels. 3776

5.2.18.1 Syntax: 3777

3778

3779

5.2.18.2 Arguments: 3780


• tModel: Required repeating element containing one or more required repeating 3786 complete tModel elements. For the purpose of performing round-trip updates, this 3787 data can be obtained in advance by using the get_tModel API call or by other means. 3788

5.2.18.3 Behavior: 3789

If the uddiKey value within a tModel (i.e., tModelKey) is missing or is passed with an empty 3790 value, this is a signal that a new tModel is being inserted and that the UDDI registry MUST 3791 assign a new tModelKey identifier to this data. If the new tModel is categorized with the 3792 keyGenerator value from the uddi:uddi.org:categorization:types category system, any 3793 publisher assigned key MUST end with the string “:keygenerator” , making the tModel a key 3794 generator tModel. If the new tModel is categorized with the keyGenerator value from the 3795 uddi:uddi.org:categorization:types category, an empty uddiKey signifies that the tModelKey 3796 generated by the node will end with the string “:keygenerator”, making the tModel a key 3797 generator tModel. New tModels can also be added with publisher-assigned keys. See Section 3798 5.2.2.2 Behavior of Publishers and Section 5.2.18.3.1 Domain Key Generator tModels. 3799

This API call performs an update to existing registered data when the tModelKey values have 3800 uddiKey values that correspond to already registered data. 3801

If a tModelKey value is passed that corresponds to a tModel that was previously hidden via the 3802 delete_tModel API call, the save_tModel service restores the tModel to full visibility, making it 3803 available for return in find_tModel results. 3804

The value of the deleted attribute in the tModel is set to false in all saves. Saving a tModel that 3805 has specified a value of true for the deleted attribute MUST result in an error. 3806

Multiple representations of the overview document MAY be registered for a tModel allowing, 3807 for example, both technical and human readable representations of the technical overview to 3808 be provided. 3809

�� ¶

<sp>¶

�� in

�� The new key value MUST

be returned in the tModelDetail response. For registries that use the recommended key syntax, if��

the��

term :


120/405

When a tModel is saved with keyedReferences, all tModelKeys used in keyedReferences 3810 must refer to tModels that existed prior to processing the tModel containing the references. A 3811 save_tModel API call may contain a sequence of tModels, in which case a keyedReference in 3812 a tModel may refer to tModelKeys created earlier but not later in the sequence. A tModel being 3813 created must not refer to itself. Self-referencing tModels can be created by using two 3814 subsequent save_tModel API calls, the first one without the reference, and the second one 3815 with the reference (to the already saved tModel). If these conditions are not met, the node 3816 MUST return E_invalidKeyPassed. 3817

When a tModel is saved with identifierBag or categoryBag contents that is associated with a 3818 checked value set or category group system tModel, the references MUST be checked for 3819 validity prior to completion of the save, or the node MUST return E_unsupported, indicating it 3820 does not support the referenced checked value set or category group system. See Section 3821 5.2.3 Special considerations for validated value sets, Appendix E Using Identifiers and 3822 Appendix F Using Categorization for additional details. 3823

5.2.18.3.1 Domain key generator tModels 3824

For registries that use the recommended key syntax, a domain key generator tModel 3825 establishes a key partition from which uddiKeys can be derived and used in other entities 3826 controlled by the publisher, as described in Section 4.4.1 Key Syntax. Additional 3827 considerations are involved when publishing a domain key generator tModel for the first time. 3828

1. The tModelKey MUST be in the form of a domain_key and MUST end with the 3829 term: keyGenerator. 3830

2. The tModelKey MUST be categorized with the keyGenerator value from the 3831 uddi:uddi.org:categorization:types category system. 3832

3. Registry policy for establishing key domains MAY require the tModel to be signed. 3833

Also, publishers of key generator tModels MAY use the overviewDoc to describe how the key 3834 space is defined. 3835

The save_tModel API call does a first pass check of the tModel to check its suitability and, if it 3836 is acceptable according to the policy of the registry for saving domain key generator tModels, 3837 returns the tModelDetail for the registry. If it is not acceptable the reason is clearly indicated in 3838 the returned dispositionReport and no further processing takes place. 3839

If the registry has multiple nodes, returning the tModelDetail is not an indication that the 3840 domain key generator tModel has been published successfully. A registry that allows publisher 3841 assigned keys MUST have a policy to ensure domainKey collisions do not occur. The 3842 custodial node MUST ensure that the domain key generator tModel is not in the process of 3843 being published simultaneously on some other node. If, after the conclusion of a full replication 3844 cycle, no UDDI node has already assigned or attempted to assign the partition (e.g., no 3845 change record has been received from other nodes), the custodial node completes the publish 3846 operation of the domain key generator tModel, assigning it to the publisher. If some other node 3847 has already been assigned the partition, the tModel is not published. See Section 7.3.97.3.9 3848 changeRecordNewDataConditional for more information on the replication structure, and 3849 Section 9.4.29.4.2 General Keying Policy and Section 9.4.39.4.3 Policy Abstractions for the 3850 UDDI keying scheme for the recommended policy that addresses acceptance of a domain key 3851 generator. 3852

When the publishing of a domain key generator tModel has completed, the custodial node 3853 MAY notify the publisher that the tModel is ready for use. Whether a node does this and the 3854 means by which it does so is a node policy. A typical node policy is to notify the publisher by e-3855 mail using an e-mail address gathered at the time the publisher account was set up. 3856

��

�� Recommended Syntax

�� keyGenerator

�� recommended

�� keyGenerator.


121/405

Before the publish operation is complete, the domain key generator tModel will be ignored by 3857 find_xx and get_xx API calls, and will return an E_keyUnavailable error to further save_tModel 3858 calls. 3859

If after the replication cycle the publisher is in doubt about the outcome, get_tModelDetail may 3860 be issued specifying the key of the domain key generator tModel being published. If a tModel 3861 is retrieved and the publisher is the owner, the operation succeeded. If a tModel is retrieved 3862 and some other publisher is the owner, the operation failed because another publisher 3863 published a domain key generator with the chosen domain_key first. If no tModel is retrieved, 3864 then either the registry experienced a failure, or two publishers tried to publish tModels with the 3865 same key "simultaneously", and neither succeeded. In either of these cases, the save_tModel 3866 operation may be retried. 3867

5.2.18.4 Returns: 3868

In most cases this API returns a tModelDetail containing the final results of the call that reflects 3869 the new or pending registered information for the affected tModel structures. Any tModelKey 3870 attributes that were assigned as a result of processing the save_tModel API are included in the 3871 tModel data. When a domain key generator is saved for the first time, the tModel that is 3872 returned in the tModelDetail represents an interim state, until all nodes in the registry have 3873 ascertained that the requested key domain does in fact belong to the publisher27. See Section 3874 7.3.9 changeRecordNewDataConditional for more information. If multiple tModel elements are 3875 passed in the save_tModel request, the order of the response MUST exactly match the order 3876 that the elements appeared in the save. If the same tModel, determined by matching key, is 3877 listed more than once in the save_tModel API, it MAY be listed only once in the result for each 3878 appearance in the save_tModel API. If the same tModel appears more than once in the 3879 response, the last occurrence of the tModel in the results represents the state stored in the 3880 registry. 3881

The tModelDetail has the form: 3882

3883

3884

5.2.18.5 Caveats: 3885



• E_invalidKeyPassed: Signifies that the request cannot be satisfied because one or 3890 more uddiKey values specified are not valid key values for the entities being 3891 published. tModelKey values that either do not exist, or exist with a different entity 3892 type, or are not authorized to be proposed by the publisher are considered to be 3893

27

It is not possible to deterministically know when a save_tModel API call for a keyGenerator tModel has been unsuccessful when such failure occurs as a result of checking performed subsequent to the synchronous response provided with the save_tModel API. Nodes are, however, encouraged to provide publishers with details on such failures using out-of-band communication mechanisms, such as e-mail

�� domainKeyGenerator

�� is

�� a

�� , or

�� the publisher is

�� publish an entity with the

�� key value


122/405

invalid values. The key causing the error SHOULD be clearly indicated in the error 3894 text. 3895

• E_invalidValue: A value that was passed in a keyValue attribute did not pass 3896 validation. This applies to checked value sets referenced using keyedReferences. 3897 The error text SHOULD clearly indicate the key and value combination that failed 3898 validation. 3899

• E_keyUnavailable: Indicates that the proposed key has already been assigned to 3900 some other publisher, is not within the partition defined by a key generator tModel that 3901 the publisher owns, or, in the case of a domain key generator tModel being saved for 3902 the first time, is assigned to some other publisher or is still pending its first save. 3903

• E_requestTimeout: Signifies that the request could not be carried out because a 3904 needed validate_values Web service did not respond in a reasonable amount of time. 3905 Details identifying the failing Web service SHOULD be included in the 3906 dispositionReport element. 3907

• E_unacceptableSignature: Indicates that the digital signature in the tModel is 3908 missing or does not meet the requirements of the registry. The errInfo element 3909 provides additional details. 3910


• E_unsupported: A keyedReference in a categoryBag or an identifierBag that 3914 references a checked value set cannot be validated by the UDDI node because the 3915 node does not support the referenced checked value set. The error text SHOULD 3916 clearly indicate the keyedReference that cannot be validated. 3917

• E_unvalidatable: A keyedReference in a categoryBag or an identifierBag that 3918 references a checked value set cannot be validated by the UDDI node because the 3919 referenced tModel has been marked unvalidatable. The error text SHOULD clearly 3920 indicate the keyedReference that cannot be validated. 3921

• E_valueNotAllowed: Restrictions have been placed by the value set provider on the 3922 types of information that should be included at that location within a specific value set. 3923 The validation routine chosen by the UDDI node has rejected this tModel for at least 3924 one specified keyedReference. The error text SHOULD clearly indicate the 3925 keyedReference that was not successfully validated. 3926

�� value that causes an

�� clearly

�� keyGenerator

�� The errInfo content begins

with one of the following strings

�� should

�� should


123/405

3927

5.2.19 set_publisherAssertions 3928

The set_publisherAssertions API call is used to manage all of the tracked relationship 3929 assertions associated with an individual publisher. See Appendix A Relationships and 3930 Publisher Assertions for more information. 3931

5.2.19.1 Syntax: 3932

3933

3934

5.2.19.2 Arguments: 3935


• publisherAssertion: Optional repeating element asserting a relationship. 3941 Relationship assertions consist of a reference to two businessEntity key values as 3942 designated by the fromKey and toKey elements, as well as a REQUIRED expression 3943 of the directional relationship within the contained keyedReference element. See 3944 Appendix A Relationships and Publisher Assertions. The fromKey, the toKey, and all 3945 three parts of the keyedReference – the tModelKey, the keyName, and the keyValue 3946 – MUST be specified. E_fatalError is returned if any of these elements are missing in 3947 any of the publisherAssertion elements. Empty (zero length) keyNames and 3948 keyValues are permitted. 3949

5.2.19.3 Behavior: 3950

The full set of assertions associated with a publisher is effectively replaced whenever this API 3951 is used. When this API call is processed, the publisher assertions that exist prior to this API 3952 call for a given publisher are examined by the UDDI registry. Any new assertions not present 3953 prior to the call are added to the assertions attributed to the publisher. Any existing assertions 3954 not present in the call are deleted. As a result, new relationships may be completed (e.g. 3955 determined to have a completed status), and existing relationships may be dissolved. Invoking 3956 this API with no publisherAssertion elements deletes all assertions associated with the 3957 publisher. 3958

Any relationships attributed to assertions previously present but not present in the data 3959 provided in this call are deactivated and are no longer visible via the find_relatedBusinesses 3960 API. For the sake of determining uniqueness within an assertion set, the fromKey, toKey, and 3961 the entire keyedReference within the publisherAssertion element are significant. Any 3962 differences in any of the individual publisherAssertion element contents constitute a new 3963 unique assertion for purposes of detecting new assertions. The direction of the relationship, as 3964


124/405

indicated by the two businessKey values in the fromKey and toKey elements, is also relevant 3965 in determining assertion uniqueness. 3966

The publisher must own the businessEntity referenced in the fromKey, the toKey, or both. If 3967 both of the businessKey values passed within an assertion are owned by the publisher, then 3968 the assertion is automatically complete and the relationship described in the assertion is visible 3969 via the find_relatedBusinesses API. To form a relationship when the publisher only owns one 3970 of the two keys passed, the assertion MUST be matched exactly by an assertion made by the 3971 publisher who owns the other business referenced. Assertions exactly match if and only if they: 3972

1. refer to the same businessEntity in their fromKeys; 3973

2. refer to the same businessEntity in their toKeys; 3974

3. refer to the same tModel in their tModelKeys; 3975

4. have identical keyNames; and 3976

5. have identical keyValues. 3977

When a publisherAssertion that is being saved references a checked relationship system 3978 using the tModelKey in the contained keyedReference, the reference MUST be checked for 3979 validity prior to completion of the save, or the node must return E_unsupported, indicating it 3980 does not support the referenced checked relationship system. Validation of a relationship 3981 system reference entails verification that the reference is valid according to the validation 3982 algorithm defined for the relationship system and described by its tModel. For cached checked 3983 relationship system, the validation algorithm verifies that referenced keyedReferences are valid 3984 for the relationship system. 3985

5.2.19.4 Returns: 3986

Upon successful completion, a publisherAssertions structure is returned containing all of the 3987 relationship assertions currently attributed to the publisher. When registries distinguish 3988 between publishers, the structure contains assertion data that is associated with the authInfo 3989 passed. 3990

See Section 5.2.13.3 get_publisherAssertions for more information on the publisherAssertions 3991 structure and contents. 3992

This API returns all assertions made by the publisher who was authenticated in the 3993 set_publisherAssertions API. 3994

5.2.19.5 Caveats: 3995


• E_invalidKeyPassed: Signifies that one of the uddiKey values passed did not match 3999 with any known businessKey or tModelKey values. The assertion element and the 4000 key that caused the problem SHOULD be clearly indicated in the error text. 4001

• E_userMismatch: Signifies that neither of the businessKey values passed in the 4002 embedded fromKey and toKey elements is controlled by the publisher associated with 4003 the authentication token. The error text SHOULD clearly indicate which assertion 4004 caused the error. 4005


125/405

4006

4007

5.3 Security Policy API Set 4008

The security API includes the following API calls: 4009

• discard_authToken: Used to inform a node that a previously obtained authentication 4010 token is no longer required and should be considered invalid if used after this 4011 message is received. 4012

• get_authToken: Used to request an authentication token in the form of an authInfo 4013 element from a UDDI node. An authInfo element MAY be required when using the 4014 API calls defined in Section 5.1 Inquiry API Set, Section 5.2 Publication API Set, 4015 Section 5.4 Custody and Ownership Transfer API Set, and Section 5.5 Subscription 4016 API Set. 4017

Whether authInfo elements are required on API calls is determined by node policy as 4018 described in Section 4.8 About Access Control and the authInfo Element. In the event that an 4019 authInfo element is not discarded, a node MAY choose to expire the authentication token so it 4020 is no longer valid for authentication in API calls after a period of time. If an expired token is 4021 passed to an API call other than discard_authToken, the error E_authTokenExpired will be 4022 returned as described in Chapter 12, Error Codes. 4023

A UDDI node typically does not support the Security API set if it does not support using an 4024 authInfo element in any API set. If the node does support using an authInfo element in any of 4025 the API set provided by the node, it SHOULD support the Security API set. A node MAY 4026 provide an alternative mechanism for obtaining authInfo elements. 4027

5.3.1 discard_authToken 4028

The discard_authToken API call is used to inform a node that the passed authentication token 4029 is to be discarded, effectively ending the session. 4030

5.3.1.1 Syntax: 4031

4032

4033

5.3.1.2 Arguments: 4034

• authInfo: This required argument is an element that contains an authentication token. 4035 Authentication tokens are obtained using the get_authToken API call. 4036

5.3.1.3 Returns: 4037

Upon successful completion, a dispositionReport is returned with a single success indicator. 4038 Discarding an expired authToken is processed and reported as a success condition. 4039

5.3.1.4 Caveats: 4040

If an error occurs in processing this API call, a dispositionReport structure will be returned to 4041 the caller in a SOAP Fault. 4042


126/405

4043

5.3.2 get_authToken 4044

The get_authToken API call is used to obtain an authentication token. An authToken element 4045 MAY be required when using the API calls defined in Section 5.1 Inquiry API Set, Section 5.2 4046 Publication API Set, Section 5.4 Custody and Ownership Transfer API Set, and Section 5.5 4047 Subscription API Set. 4048

5.3.2.1 Syntax: 4049

4050

4051

Attributes 4052

Name Use

userID Required

cred Required

4053

5.3.2.2 Arguments: 4054

• userID: This required attribute argument is the user identifier that an individual 4055 authorized user was assigned by a UDDI node. Nodes SHOULD provide a means for 4056 individuals to obtain a userID and password credentials that will be valid at the given 4057 node. 4058

• cred: This required attribute argument is the password or credential that is associated 4059 with the user. 4060

5.3.2.3 Returns: 4061

Upon successful completion this API call returns an authToken structure that contains a valid 4062 authInfo element that can be used in subsequent calls to API calls that require an authInfo 4063 value. 4064

The authToken message has the form: 4065

4066

The authToken structure contains a single authInfo element that represents a token that is to 4067 be passed back in API calls that require one. This structure is always returned as a 4068 synchronous response to the get_authToken message. 4069


127/405

4070

5.3.2.4 Caveats: 4071

If an error occurs in processing this API call, a dispositionReport element will be returned to the 4072 caller within a SOAP Fault. In addition to the errors common to all APIs, the following error 4073 information is relevant here: 4074

• E_unknownUser: Signifies that the UDDI node that received the request does not 4075 accept the userID and/or cred argument values passed as valid credentials. 4076

4077


128/405

4078

5.4 Custody and Ownership Transfer API Set 4079

This section defines the UDDI Custody and Ownership Transfer API Set28. Data custody is 4080 introduced in Section 1.5.6 Data Custody. Ownership transfer is introduced in Section 1.5.7 4081 Transfer of Ownership. By virtue of having created an entity, a publisher has ownership of the 4082 entity and is said to be the owner of the entity. A custodial node MUST maintain a relationship 4083 of ownership between an entity and its publisher by means of authorization mechanisms. 4084 Every node of a multi-node registry MUST guarantee the integrity of an entity's custody. As 4085 such, a node MUST not permit changes to an entity unless it has custody of it. 4086

The Custody and Ownership Transfer API Set enables any nodes of a registry to cooperatively 4087 transfer custody of one or more businessEntity or tModel structures from one node to another, 4088 as well as allowing the transfer of ownership of these structures from one publisher to another. 4089 Associated entities of a businessEntity such as its businessService, bindingTemplate, and 4090 publisherAssertion structures are transferred as part of the custody transfer of the business 4091 entity. 4092

From a custody transfer point of view, the publishers are always distinct, though it may be the 4093 case that the publishers are the same person. Also, the two nodes may or may not be distinct; 4094 intra-node transfer between two publishers is simply a degenerate case in which node custody 4095 does not change. Thus, in the case of an inter-node transfer, ownership transfer is implied. In 4096 the case of an intra-node transfer the behavior results in the transfer of ownership between two 4097 publishers. 4098

For example, one UDDI registry, UDDI-1, MAY allow each node in UDDI-1 (composed of 4099 nodes 1A, 1B and 1C) to define its own policies for registration, authentication and 4100 authorization. In this case, a “person”, (P1) would need to review the policies of all 3 nodes 4101 and decide upon the node with which it chooses to register with. P1 may choose to register 4102 with more than one node. P1 registers with node1A . Node1A also specifies how P1 is 4103 authenticated. If P1 successfully authenticates and publishes a business entity (BE1) then P1 4104 becomes the “owner” of BE1. Node1A is said to be the “custodian” of BE1. P1 can also 4105 register at node1B. If P1 successfully authenticates and publishes a business entity (BE2) then 4106 P1 becomes the “owner” of BE2. Node1B is said to be the “custodian” of BE2. There is no 4107 assumption that the registry UDDI-1 or its nodes (node1A and node1B) are aware that P1 is 4108 the same “person”. P1 is responsible for maintaining the appropriate identity and 4109 authenticating correctly to each node within a registry. 4110

Another UDDI registry, UDDI-2, MAY require each of its nodes (node2-1, node2-2 and node2-4111 3) to use the same registration, authentication and authorization mechanisms. In this case, the 4112 policies are the same across all nodes. The relationship of registration, publication and 4113 ownership remains the same. If P1 wants to register with different nodes in UDDI-2, then it 4114 needs to differentiate its registration with the different nodes, since an attempt to register at 4115 node2-2 after registering at node2-1, would fail as “already registered” (since by policy the 4116 nodes all share the same registration, authentication and authorization). 4117

5.4.1 Overview 4118

There are a number of scenarios where a publisher may choose to transfer custodianship or 4119 ownership of one or more entities. These are described in this section. 4120

28

The Custody Transfer tModel is but one of several tModels defined for UDDI. See Section 11.3.5 UDDI Custody Transfer API tModel for more information.


129/405

5.4.1.1 Intra-Node Ownership Transfer 4121

Intra-node ownership transfer involves transferring entity ownership from one publisher to 4122 another within the same UDDI node. Usage scenarios for this type of transfer include the 4123 following: 4124

• Businesses or organizational merges: Multiple organizations need to be consolidated 4125 under the control of a single publisher. 4126

• Domain key generators: One use of ownership transfer is the transfer of ownership of 4127 a derived key generator from one publisher to another to enable her or him to publish 4128 entities using keys in that domain. 4129

The save_xx APIs can also be used to move entities between parent entities that are owned 4130 by the same publisher. The save_service API, for example, can be used to move services 4131 (and binding templates) between one business entity and another as described in Section 4132 5.2.17.3 Behavior of the save_service API. Using the parent relationship in this way causes 4133 two businessEntity structures to be changed. Doing so enables the following scenarios: 4134

• Divestitures: An organization needs to reassign the control of a set of services to two 4135 or more publishers. 4136

• Consolidation of registry entities: There are multiple entities for a given business that 4137 are to be consolidated under a single publisher. 4138

5.4.1.2 Inter-Node Custody Transfer 4139

Inter-node custody transfer involves the custody transfer of a set of entities across nodes of a 4140 UDDI registry. A transfer of ownership ensues as a consequence of this custody transfer. In 4141 addition to the intra-node scenarios described above, inter-node custody transfer may be used 4142 to address the following use cases: 4143

• Unsatisfactory service level: The functionality or service level provided by a given 4144 node operator is insufficient, and the publisher wishes to move their UDDI data to 4145 another node. 4146

• Change in availability for a UDDI node: A node is no longer providing UDDI services, 4147 and all publishers need to be migrated to one or more nodes of the registry. 4148

• Organizational Mergers, Divestitures or Consolidations: Changes in organizational 4149 structure may result in the need to make changes to the set of publishers used to 4150 manage the entities at various nodes of a registry. 4151

For any of these intra and inter-node scenarios, a mechanism is specified to facilitate the 4152 transfer the custody of businessEntity and tModel entities between nodes whether the entity is 4153 being transferred within a single node or whether a custody transfer occurs between nodes of 4154 a registry. 4155

5.4.2 Custody Transfer Considerations 4156

When a businessEntity is transferred, all related businessService and bindingTemplate 4157 elements are transferred as well. In addition, any publisherAssertion elements that reference 4158 the businessEntity element’s businessKey that are owned by the publisher are also 4159 transferred. 4160

Note that the relinquishing publisher is not required to transfer all of its UDDI entities (i.e. 4161 businessEntity and/or tModel entities) in a single custody transfer request, nor is it required to 4162 transfer all of its entities to the same target publisher or target node. Any combination or 4163 subset of UDDI registry entities may be transferred to any number of target publishers or 4164 nodes. 4165

�� keyGenerator

�� ¶

In conjunction with ownership transfer, ��

Changing ��

save_service call it is possible to move an existing businessService element from one businessEntity to another by simply specifying a different parent businessEntity relationship. Changing a


130/405

5.4.3 Transfer Execution 4166

The Custody and Ownership Transfer API Set enables two publishers P1 and P2 and two 4167 nodes, N1 and N2, in a registry to cooperatively transfer custody of one or more existing 4168 businessEntity or tModel structures, E1…En, from N1 to N2 and, and by extension to transfer 4169 ownership of the entities from P1 to P2. Related businessService, bindingTemplate, and 4170 publisherAssertion structures are transferred with their related businessEntities. From the 4171 registry’s point of view, the publishers are always distinct, though it may be the case that P1 4172 and P2 are the same party. The two nodes may or may not be distinct; intra-node transfer of 4173 ownership from P1 to P2 is simply a degenerate case in which node custody does not change. 4174

The Custody and Ownership Transfer API Set is divided into two parts, a set of two client APIs 4175 and a single inter-node API. These client APIs are get_transferToken and transfer_entities; in 4176 short, this constitutes the Ownership Transfer API portion of this API set. The inter-node-API is 4177 transfer_ custody which when combined with replication makes up the Custody Transfer API 4178 portion of this API set. 4179

The overall flow of custody and ownership transfer is as follows: 4180

Publisher P1 invokes get_transferToken on N1, specifying the keys K1…Kn of the entities 4181 E1…En that are to be transferred. If P1 is authorized to do this (i.e., if P1 has ownership of 4182 E1…En), N1 returns a structure T, called a transfer token, that represents authority to transfer 4183 the entities, including all of the naturally contained children and publisher assertions related to 4184 business entities involved in the transfer that are owned by P1. The transferToken is a 4185 structure that consists of an opaque string that is meaningful only to the node that issued it, an 4186 expiration time, and a node identifier. 4187

P1 then gives T to P2 (typically by some secure means since T is valuable). The publisher 4188 obtaining the custody information needs to have previously obtained a publishers account on 4189 the node accepting custody of the entity before he/she can complete the custody transfer. P2 4190 then invokes transfer_entities on N2, passing K1…Kn and T. If transfer_entities completes 4191 successfully, the entities E1…En and their related structures (businessService, 4192 bindingTemplate, and publisherAssertion) are in the custody of N2 and are owned by P2. If the 4193 operation fails, nothing happens to the entities. The actual transfer proceeds as follows, in the 4194 processing of transfer_entities. 4195

If N1 and N2 are not distinct nodes, the ownership transfer from P1 to P2 is an operation that is 4196 purely internal to the node – how it happens is up to the implementation. If N1 and N2 are 4197 distinct, the following protocol occurs while processing the transfer_entities request on N2. 4198

Upon receipt of a transfer_entities request, N2 checks that K1…Kn are valid keys. There is the 4199 possibility that P1 might transfer more data than P2 can accept due to policy-based restrictions 4200 on the limit of entities allowed to be owned by P2 at N2. As is described below, replication is 4201 used to complete the custody transfer process. A question that arises is at the time of 4202 accepting the datum related to the transfer, could N2 throw a replication error because the 4203 data being transferred exceeds the limits of user P2? Such limits can not be enforced during 4204 replication because they are node-local policy decisions from the perspective of enforcement. 4205 Thus, it is therefore possible that as a result of a custody transfer a publisher may be caused to 4206 hold more data that he/she would have been able to publish. Should this situation occur, P2 4207 MUST not be allowed to publish any additional data unless P2 first reduces the number of 4208 entries it owns to an allowable limit. 4209

If all is well, N2 invokes the inter-node API transfer_custody on N1, presenting the keys of top-4210 level entities to be transferred, K1…Kn, P2’s identity (using the publisher’s authorizedName), 4211 N2’s node identifier (as known in the Replication Configuration structure, see Section 7.5.2 4212 Configuration of a UDDI Node – operator element), and T. The transferToken, T, implies 4213 permission to transfer the entire content of the entities it identifies, including all of the contained 4214 entities and related publisherAssertions, if any. N1 checks to see whether T is a valid 4215 transferToken that it issued and that T represents the authority to transfer E1…En. If the 4216 validation is successful, N1 prevents further changes to entities E1…En. N1 then updates the 4217

�� K2


131/405

authorizedName and nodeID of the operationalInfo of E1…En and related entities so that they 4218 are shown to be in the custody of N2 and owned by P2. Finally, N1 responds to N2 with a 4219 dispositionReport which triggers N2 to respond to the transfer_entities caller with a 4220 corresponding dispositionReport. This completes the processing for the transfer_entities 4221 request. 4222

In the case that the datum being transferred is a key generator tModel, N1 will disallow further 4223 generation of keys associated with this key partition at its node. 4224

Following the issue of the dispositionReport by N1 to the transfer_custody call, N1 will submit 4225 into the replication stream a changeRecordNewData providing in the operationalInfo, N2’s 4226 nodeID identifying it as the node where the datum is being transferred to, and the 4227 authorizedName of P2. The acknowledgmentRequested attribute of this change record MUST 4228 be set to “true”. 4229

The last modified date timestamp in the operationalInfo must change to reflect the custody 4230 transfer. Figure 2 depicts the flow of a custody transfer between P1 and P2. 4231

4232

4233

4234

Figure 2 - Custody Transfer 4235

4236

Once N2 receives the changes via the replication stream it assumes custody of E1…En and 4237 assigns ownership of the entities and related entities owned by P1 to P2. 4238

5.4.3.1 Content of a transferToken 4239

The transferToken is a structure that consists of an opaque string that is meaningful only to the 4240 node that issued it, an expiration time, and a node identifier. It represents the one-time 4241

�� keyGenerator

�� There is no change to any

of��

timestamps as a result of a ��

operation


132/405

authority to transfer ownership of a specific set of entities to any publisher and to transfer 4242 custody of them to any node in the registry. Issuing it does not cause any such transfer to 4243 occur; it is simply an authorization for such a transfer to take place. The authority represented 4244 by a transferToken expires after some period of time, per node policy. 4245

The expiration time represents the time, according to the node that issued the transferToken, 4246 after which the token is no longer valid. The expiration time is only a convenience; changing it 4247 does not change the time at which the authority expires. The node identification identifies, in a 4248 registry dependent way, the node that issued the transferToken. It is used by the node that 4249 receives the transferToken to determine which node in the registry to direct the 4250 transfer_custody request to. 4251

The opaque token SHOULD reflect the entities that the custodial publisher has sought 4252 permission to be transferred. It is often used in the latter stages of the custody transfer 4253 process by the custodial node to verify that the entities that the target publisher is requesting to 4254 own have been authorized by the target node under the auspices of the transferToken. 4255

5.4.4 discard_transferToken 4256

The discard_transferToken API is a client API used to discard a transferToken obtained 4257 through the get_transferToken API at the same node. This API accepts either a transferToken 4258 or a keyBag as parameters to remove the permission to transfer data associated with a 4259 particular transferToken. If a keyBag is provided, all tokens corresponding to the keys in the 4260 keyBag will be discarded and will no longer be valid for custody or ownership transfer after the 4261 discard_transferToken is processed. In the event that the keyBag represents a subset of the 4262 keyBag for one or more transferToken elements, the transferToken is discarded and will no 4263 longer be valid for transferring any entity. 4264

5.4.4.1 Syntax 4265

4266

5.4.4.2 Arguments 4267

• authInfo: This OPTIONAL argument is an element that contains an authentication 4268 token. Authentication tokens are obtained using the get_authToken API call or 4269 through some other means external to this specification, and represent the identity of 4270 the publisher at a UDDI node. 4271

• transferToken: This is a known transferToken obtained by a publisher at the node 4272 where the get_transferToken API was invoked. 4273

• keyBag: One or more uddiKeys associated either with businessEntity or tModel 4274 entities owned by the publisher that were to be transferred to some other publisher 4275 and/or node in the registry as the result of invocation of get_transferToken. At least 4276 one businessKey or tModelKey must be provided in a keyBag. 4277

5.4.4.3 Returns 4278


��

¶<#>get_transferToken ¶The get_transferToken API is a client API used to initiate the transfer of custody of one or more businessEntity or tModel entities from one node to another. As previously stated, the two nodes may or may not be distinct; intra-node transfer between two publishers is simply a degenerate case in which node custody does not change. No actual transfer takes place with the invocation of this API. Instead, this API obtains permission from the custodial node, in the form of a transferToken, to perform the transfer. The publisher who will be recipient of the transferToken returned by this API must invoke the transfer_entities API on the target custodial node to actually transfer the entities.¶<#>Syntax¶

�� ¶

¶��

.


133/405

No error will be reported if the transferToken provided in the call does not match an existing 4281 token. No error will be reported if a token is not found for a particular key in the keyBag. 4282

5.4.4.4 Caveats 4283


• E_invalidKeyPassed: signifies that one of the uddiKey values passed for entities to 4287 be transferred did not match with any known businessKey or tModelKey values. The 4288 key and element or attribute that caused the problem SHOULD be clearly indicated in 4289 the error text. 4290

• E_userMismatch: signifies that one or more of the businessKey or tModelKey 4291 elements that identify entities to be transferred are not owned by the publisher 4292 identified by the authInfo element. The error text SHOULD clearly indicate which 4293 entity keys caused the error. 4294

5.4.5 get_transferToken 4295

The get_transferToken API is a client API used to initiate the transfer of custody of one or more 4296 businessEntity or tModel entities from one node to another. As previously stated, the two 4297 nodes may or may not be distinct; intra-node transfer between two publishers is simply a 4298 degenerate case in which node custody does not change. No actual transfer takes place with 4299 the invocation of this API. Instead, this API obtains permission from the custodial node, in the 4300 form of a transferToken, to perform the transfer. The publisher who will be recipient of the 4301 transferToken returned by this API must invoke the transfer_entities API on the target custodial 4302 node to actually transfer the entities. 4303

5.4.5.1 Syntax 4304

4305

4306

4307

4308


• authInfo: This OPTIONAL argument is an element that contains an authentication 4310 token. Authentication tokens are obtained using the get_authToken API call or 4311 through some other means external to this specification and represent the identity of 4312 the publisher at a UDDI node. 4313

• keyBag: One or more key (of type uddi:uddiKey) associated either with 4314 businessEntity or tModel entities owned by the publisher that are to be transferred to 4315


134/405

some other publisher and/or node in the registry. At least one businessKey or 4316 tModelKey must be provided. 4317

5.4.5.3 Returns 4318

If the publisher identified by the authInfo element owns the businessEntity elements identified 4319 by the businessKey elements provided and the tModel elements identified by the tModelKey 4320 elements provided, a transferToken is returned that represents the one-time permission to 4321 transfer custody of the identified entities. 4322

4323

4324

4325

The transfer token consists of a nodeID, an expirationTime and an opaqueToken. The nodeID 4326 is used during the transfer_entities API by the recipient node to confirm with the relinquishing 4327 custodial node that the custody transfer is authorized and still valid. The nodeID of the 4328 transferToken is the value of the nodeID element of the Replication Configuration Structure. 4329 Refer to Section 7.5.2 Configuration of a UDDI Node – operator Element. 4330

The expirationTime, defined as xsd:dateTime, represents the time at which the transfer token 4331 is no longer valid. 4332

The opaqueToken is only meaningful to the node that issues it. The opaqueToken is defined 4333 as xsd:base64Binary to allow for a RECOMMENDED encryption of the token under the 4334 relinquishing custody node’s own encryption key. 4335

5.4.5.4 Caveats 4336

If an error occurs in processing this API call, a dispositionReport structure MUST be returned 4337 to the caller in a SOAP Fault. See section 4.8 Success and Error Reporting. In addition to the 4338 errors common to all APIs, the following error information is relevant here: 4339


• E_tokenAlreadyExists: signifies that one or more of the businessKey or tModelKey 4344 elements that identify entities to be transferred are associated with a transferToken 4345 that is still valid and has not been discarded, used or expired. The error text SHOULD 4346 clearly indicate which entity keys caused the error. 4347

• E_userMismatch: signifies that one or more of the businessKey or tModelKey 4348 elements that identify entities to be transferred are not owned by the publisher 4349 identified by the authInfo element. The error text SHOULD clearly indicate which 4350 entity keys caused the error. 4351

4352

�� is

��


135/405

5.4.6 transfer_entities 4353

The transfer_entities API is used by publishers to whom custody is being transferred to 4354 actually perform the transfer. The recipient publisher must have an unexpired transferToken 4355 that was issued by the custodial node for the entities being transferred. 4356

5.4.6.1 Syntax 4357

4358


• authInfo: This OPTIONAL argument is an element that contains an authentication 4360 token. Authentication tokens are obtained using the get_authToken API call or 4361 through some other means external to this specification, and represent the identity of 4362 the publisher at a UDDI node, in this case, the new owner of the entities being 4363 transferred. 4364

• transferToken: Required argument obtained from the custodial node via a call to 4365 get_transferToken by the publisher requesting a transfer of custody. The 4366 transferToken contains an opaque token, an expiration date, and the identity of the 4367 custodial node. The transferToken represents permission to transfer the entities that 4368 have been identified via a prior call to the get_transferToken API. 4369

• keyBag: One or more uddiKeys associated with businessEntity or tModel entities that 4370 are to be transferred to this publisher at the target node in the registry. The set of keys 4371 must be the same as the set of keys in the keyBag of the get_transferToken API call 4372 from which the given transferToken was once obtained. 4373

5.4.6.3 Returns 4374

The target node responds to this API by performing the transfer operation. This operation is 4375 comprised of four steps: 4376

• Verification that the entity keys are valid. 4377

• Verification that ownership of the entities by the recipient publisher is allowed and 4378 would not violate any policies at the target node related to publisher limits. 4379

• Verification with the custodial node that the transfer of the designated entities is 4380 allowed. This is accomplished by invoking transfer_custody on the custodial node 4381 that is identified by the nodeID element in the transferToken. Any errors returned by 4382 the custodial node cause this API to fail and are propagated to the caller. 4383

• Changing custody and ownership of the designated entities and entering these 4384 changes into the replication stream. 4385

Upon successful completion, a dispositionReport is returned indicating the success of the 4386 transfer operation. In the case of an inter-node custody transfer, while the transfer is in 4387 process, the entities being transferred are not available for modification. To determine the state 4388 of the data, UDDI clients can use the get_operationalInfo API to determine when custody and 4389

�� key (of type uddi:uddiKey)

�� At least one businessKey

or tModelKey��

provided


136/405

ownership transfer has taken place. A change in the nodeID of the operationalInfo provides 4390 such an indication. 4391

5.4.6.4 Caveats 4392


• E_accountLimitExceeded: signifies that the target node has determined that the 4396 transfer of custody of the identified entities would result in the target publisher 4397 exceeding policy limits for the number of owned entities. The error text SHOULD 4398 clearly indicate which entities cause the publishers limits to be exceeded. It is possible 4399 for a publisher to come into possession of more data than the target node’s policy 4400 allows. The condition and node behavior under these circumstances are described in 4401 Section 5.4.3Transfer Execution. 4402


• E_transferNotAllowed: signifies that the transfer of one or more entities has been 4407 rejected by the target node or the custodial node. Reasons for rejection include 4408 expiration of the transferToken and attempts to transfer a set of entities that does not 4409 match the one represented by the transferToken. The reason for rejecting the custody 4410 transfer SHOULD be clearly indicated in the error text. 4411

�� an unauthorized entity


137/405

4412

5.4.7 transfer_custody 4413

Invoked by the target node in a custody transfer operation in response to transfer_entities, this 4414 API is used by the custodial node to ensure that permission has been granted to transfer 4415 custody of the entities that the target publisher has requested. 4416

5.4.7.1 Syntax 4417

4418

4419


• transferToken: Required argument obtained from the custodial node via a call to 4421 get_transferToken by the publisher requesting a transfer of custody. The 4422 transferToken contains an opaque token, an expiration date, and the identity of the 4423 custodial node. The transferToken represents permission to transfer the entities that 4424 have been identified via a prior call to the get_transferToken API. The custodial node 4425 MUST verify that the transferToken has not expired and that the businessKey and 4426 tModelKey elements that the target publisher has provided in transfer_entities are 4427 allowed to be transferred as captured in the transfer token’s opaqueToken. 4428

• keyBag: One or more uddiKeys associated with businessEntity or tModel entities that 4429 the target publisher is requesting ownership of at the target node in the registry. The 4430 set of keys must be the same as the set of keys in the keyBag of the 4431 get_transferToken API call from which the given transferToken was once obtained. 4432

• transferOperationalInfo: Required argument. The accepting publisher’s 4433 authorizedName and the accepting node’s nodeID are provided on input to the 4434 relinquishing custodial node to allow it to update the operationalInfo associated with 4435 the entities whose custody is being transferred. The authorizedName and nodeID 4436 elements are both required. The accepting node’s nodeID is obtained via the 4437 Replication Configuration structure as described in Section 7.5.2 Configuration of a 4438 UDDI Node – operator element. The authorizedName is obtained from the call to 4439 transfer_entities by the requesting publisher. 4440

5.4.7.3 Returns 4441

The custodial node must verify that it has granted permission to transfer the entities identified 4442 and that this permission is still valid. This operation is comprised of two steps: 4443

�� key (of type uddi:uddiKey)

�� At least one businessKey

or tModelKey��

provided


138/405

1. Verification that the transferToken was issued by it, that it has not expired, that it 4444 represents the authority to transfer no more and no less than those entities identified 4445 by the businessKey and tModelKey elements and that all these entities are still valid 4446 and not yet transferred. The transferToken is invalidated if any of these conditions are 4447 not met. 4448

2. If the conditions above are met, the custodial node will prevent any further changes to 4449 the entities identified by the businessKey and tModelKey elements identified. The 4450 entity will remain in this state until the replication stream indicates it has been 4451 successfully processed via the replication stream. 4452

Upon successful verification of the custody transfer request by the custodial node, a 4453 dispositionReport is returned by it indicating the success of the request and acknowledging the 4454 custody transfer. 4455

Following the issue of the dispositionReport, the custodial node will submit into the replication 4456 stream a changeRecordNewData providing in the operationalInfo, the nodeID accepting 4457 custody of the datum and the authorizedName of the publisher accepting ownership. The 4458 acknowledgmentRequested attribute of this change record MUST be set to “true”. 4459

Finally, the custodial node invalidates the transferToken in order to prevent additional calls of 4460 the transfer_entities API. 4461

5.4.7.4 Caveats 4462


• E_transferNotAllowed: signifies that the transfer of one or more entities has been 4466 rejected by the custodial node. Reasons for rejection include expiration of the 4467 transferToken and attempts to transfer a set of entities that does not match the one 4468 represented by the transferToken. The reason for rejecting the custody transfer 4469 SHOULD be clearly indicated in the error text. 4470


5.4.8 Security Configuration for transfer_custody 4475

The use of mutual authentication of UDDI nodes in conjunction with the transfer_custody API 4476 is RECOMMENDED. This MAY be achieved using mutual X.509v3 certificate-based 4477 authentication as described in the Secure Sockets Layer (SSL) 3.0 protocol. SSL 3.0 with 4478 mutual authentication is represented by the tModel uddi-org:mutualAuthenticatedSSL3 as 4479 described within Section 11.3.2 Secure Sockets Layer Version 3 with Mutual Authentication. 4480

�� and

�� the

�� .

�� shows

�� to have

�� an unauthorized entity


139/405

4481

5.5 Subscription API Set 4482

Subscription provides clients, known as subscribers, with the ability to register their interest in 4483 receiving information concerning changes made in a UDDI registry. These changes can be 4484 scoped based on preferences provided with the request. The APIs described below support 4485 this capability. Usage scenarios and examples are provided in Appendix C Supporting 4486 Subscribers. Each of the subscription APIs described here are OPTIONAL for UDDI 4487 implementations and MAY be implemented entirely at the discretion of a Node. 4488

5.5.1 About UDDI Subscription API functions 4489

The subscription API set satisfies a variety of requirements. The flexibility of the subscription 4490 API allows monitoring of activity in a registry by registering to track new, changed and deleted 4491 entries for each of these entities: 4492

• businessEntity 4493

• businessService 4494

• bindingTemplate 4495

• tModel 4496

• related businessEntity 4497

• publisherAssertion (limited to those publisherAssertions for which the subscriber owns 4498 at least one of the businesses referenced) 4499

With the exception of single publisher registries subscription typically is limited to authorized 4500 clients as a matter of node policy. Therefore, subscribers MUST typically authenticate with the 4501 node before saving subscription requests. Individual nodes, including those in the UDDI 4502 Business Registry, MAY establish policies concerning the use of the subscription APIs they 4503 choose to offer. Such policies might include restricting the use of subscription, defining which 4504 APIs are supported, establishing whether subscriptions require authentication, defining special 4505 rules affecting different classes of subscriptions, or even imposing fees for the use of these 4506 services. The use of the authInfo argument is OPTIONAL throughout the subscription APIs, 4507 although registries which support multiple users or which require authentication for publishing 4508 operations typically require it. 4509

Subscription allows subscribers to “monitor” a particular subset of data within a registry. Two 4510 patterns are defined. Nodes MAY support either or both: 4511

• Asynchronous notification – subscribers choose to be asynchronously notified by the 4512 node when registry data of interest changes via calls to the notify_subscriptionListener 4513 API, which they implement as a “subscription listener” service. 4514

• Synchronous change tracking – subscribers issue a synchronous request using the 4515 get_subscriptionResults API to obtain information on activity in the registry which 4516 matches their subscription preferences. 4517

A subscription request establishes criteria for the subscription and specifies how and if the 4518 subscriber is to be notified of changes matching the specified criteria. Any of the existing 4519 standard inquiry APIs (find_xx and get_xx) may be used within a subscription request to define 4520 the criteria, although nodes are free to restrict which inquiry APIs are supported in subscription 4521 as a matter of policy. The duration, or life of a subscription is also a matter of node policy, but 4522 subscribers can renew existing subscriptions periodically instead of having to create new ones. 4523 Subscribers may also create multiple subscriptions. Each subscription request is treated 4524 independently. The level of detail provided for the data returned is controlled by the 4525 subscription request. 4526

�� is


140/405

When asynchronous notifications are requested, subscriptions provide information on new, 4527 changed or deleted entities within a registry that occur after the point in time that the 4528 subscription is registered. A node notifies subscribers based upon its identification of data 4529 matching the requested subscription criteria. Subscribers can choose to have these 4530 notifications provided via email or an HTTP/SOAP-based Web service, which the subscriber 4531 MAY implement. Such services are called “subscription listeners.” Notifications are made 4532 periodically rather than in response to the continuous stream of changes that normally occur 4533 within the registry. This means that subscription results provided via notifications pertain only 4534 to the current state of the entities at the time they are reported – intermediate state changes 4535 are not provided. While subscribers can specify a frequency for these notifications, nodes 4536 MAY choose to restrict this as a matter of policy. 4537

When synchronous requests are made for subscription results, the current state of the registry 4538 data, which matches the subscription criteria, is returned for entries that were last created, 4539 changed or deleted within a specified date range. Prior states of the registry data are not 4540 available and are not returned. 4541

Subscriptions are owned by the subscriber who creates them. A subscriptionKey, which 4542 distinguishes each individual subscription, is not visible to anyone except the subscriber. 4543 While node policy MAY permit others besides the subscription’s owner to receive or retrieve 4544 subscription results, such interested parties require knowledge of the relevant subscriptionKey 4545 from the subscription owner in order to do so. 4546

5.5.1.1 Definition of Changed Entities 4547

As stated above, the subscription API allows monitoring of new, changed and deleted entities. 4548 This section provides the definition of changed entities. The following are the criteria for 4549 considering an entity to have been “changed”: 4550

• For businessEntity, businessService, bindingTemplate, and tModel: 4551 The entity is considered to be changed if the modifiedIncludingChildren element of the 4552 operationalInfo element of the entity has been changed. 4553

• For publisherAssertion: 4554 A publisherAssertion is considered to be changed if the publisher has updated the 4555 publisherAssertion via the set_publisherAssertions, or add_publisherAssertions APIs. 4556

• For related businessEntity: 4557 A related businessEntity (related to the business specified in the businessKey 4558 argument of find_relatedBusinesses API) is considered to be changed if either: 4559

1. the related businessEntity is changed, or 4560

2. at least one of the two reciprocal publisherAssertions that represents the 4561 relationship is changed. 4562

5.5.2 Specifying Durations 4563

Time durations used in the subscription APIs are of type xsd:duration defined in XML Schema 4564 from [ISO 8601]. Any form supported by this data type is permitted. For example, the lexical 4565 representation extended format can be used, which is of the form PnYnMnDTnHnMnS, where 4566 nY represents the number of years, nM the number of months, nD the number of days, 'T' is 4567 the date/time separator, nH the number of hours, nM the number of minutes and nS the 4568 number of seconds. The “P” identifies the field as duration. The number of seconds can 4569 include decimal digits to arbitrary precision. 4570

5.5.3 Specifying Points in Time 4571

Points in time used in the subscription APIs are all of the XML Schema type, xsd:dateTime. 4572 Two points in time are used to specify a period of time. 4573

�� web


141/405

5.5.4 Subscription Coverage Period 4574

The APIs, which support each of the patterns previously described for obtaining subscription 4575 results, accept a coveragePeriod argument, which is composed of two points in time. Each of 4576 these corresponds to the last point in time which any given entity in the registry was modified 4577 (i.e., created, deleted or changed). The syntax of this element is: 4578

4579

Where: 4580

• startPoint: Signifies the point in time after which subscription results are to be 4581 collected and/or returned. The startPoint is optional. If it is not specified, this indicates 4582 that all available results are to be returned from the beginning of the registry. 4583

• endPoint: Signifies the point in time corresponding to the last activity date for entities 4584 matching subscription results. No activity among matching entities, which occurred 4585 after this point in time, is returned. The endPoint is optional. If not provided, it signifies 4586 that the latest changes available, which match the subscription criterions that are to be 4587 returned. 4588

With respect to notifications, the startPoint of a given notification SHOULD align with the 4589 endPoint of the previous notification. If this is not the case, the subscriber SHOULD assume a 4590 notification was missed, or lost. The subscriber can then take corrective action by using the 4591 get_subscriptionResults API. Note that it is permissible for nodes to send the same data more 4592 than once, depending on overlaps in these times. 4593

5.5.5 Chunking of Returned Subscription Data 4594

If a subscriber specifies a maximum number of entries to be returned with a subscription and 4595 the amount of data to be returned exceeds this limit, or if the node determines based on its 4596 policy that there are too many entries to be returned in a single group, then the node SHOULD 4597 provide a chunkToken with results. The chunkToken is a string based token which is used by 4598 the node to maintain the state of the subscription results for a particular caller, when these 4599 results are chunked across multiple responses. The format and content of the chunkToken is 4600 a matter of implementation choice by individual nodes. The chunkToken returned with a 4601 particular subscription result set SHOULD be used to retrieve subsequent results when 4602 subscription results are requested in a synchronous manor. If no more results are pending, 4603 the value of the chunkToken MUST be “0”. 4604

A chunkToken is intended as a short-term aid in obtaining contiguous results across multiple 4605 API calls and is therefore likely to remain valid for only a short time. Nodes MAY establish 4606 policies on how long a chunkToken remains valid. 4607

5.5.6 Use of keyBag in Subscription 4608

The subscription results returned by the subscription APIs allow for the use of a structure 4609 called a keyBag. A keyBag contains a list of entity keys, which correspond to any of the core 4610 data structures (businessEntity, businessService, bindingTemplate or tModel). The keyBag 4611 has two uses. 4612

• Returning results when a “brief” format is selected, which minimizes returned 4613 information. 4614


142/405

• Indicating entities which have been deleted, or which no longer match the subscription 4615 criteria provided with the subscription. This later situation is referred to as a “virtual 4616 delete”, in that the entity in question may not actually have be deleted from the 4617 registry, but it no longer matches the criterion which the subscriber defined in the 4618 subscription for tracking registry changes. It should be noted that nodes MUST 4619 maintain information pertaining to registry changes for both forms of deletion, to be 4620 reported with subscription results for applicable subscriptions, although they MAY 4621 establish policies on how long such information is retained. Further details on the use 4622 of this structure are discussed in the relevant API sections that follow. When the 4623 keyBag is used for deleted entities, the deleted element is set to “true,” and all entities 4624 listed in such a keyBag are assumed to represent deletions. 4625 4626

�� "!�#�$�!�%�� $��&��"�� '(� �&�� *)�� &��+� , '-��&� %� ��.� �4627 !�#�$�!�%�� )� � ��"%�� &�$�#��/0&!�� , ��1��&�� %� 2� ��"!�#�$!�%�� )� � ��4628 %�� &�$�� .!�#�$�!%�+� $��/0&�!.� �� .��.��3� �.��&�� % �4

4629

A UDDI node MAY inform a subscriber about the real or virtual deletion of an entity multiple 4630 times. 4631

The syntax of a keyBag is shown here: 4632

4633

5.5.7 Subscription API functions 4634

The APIs in this section describe how to interact with a UDDI node implementation to create 4635 and manage requests for the tracking of new and changed registry content. These APIs are 4636 synchronous and are exposed via SOAP, although the notifications they may generate are not. 4637

The subscription APIs are: 4638

• delete_subscription: Cancels one or more specified subscriptions. 4639

• get_subscriptionResults: Synchronously returns registry data pertaining to a 4640 particular subscription within a specified time period. 4641

• get_subscriptions: Returns a list of existing subscriptions previously saved by the 4642 subscriber. 4643

• save_subscription: Establishes a new subscription or changes an existing one. 4644 Also used to renew existing subscriptions. 4645

The OPTIONAL client API is: 4646


143/405

notify_subscriptionListener: A node invoked API which the client implements as a 4647 subscription listener service to accept notifications containing the data that changed since 4648 notify_subscriptionListener was last invoked for a particular subscription. 4649

5.5.8 save_subscription 4650

The save_subscription API registers a request to monitor specific registry content and to have 4651 the node periodically notify the subscriber when changes are available. Notifications are not 4652 returned synchronously with results for this API. Only data that matches the requested 4653 subscription criteria and which changes after the point in time that the subscription request is 4654 accepted is returned to the subscriber via a notification. 4655

This API returns a duration for which this particular subscription is valid. Depending upon the 4656 policy of the Node, subscriptions need to be renewed before the expiration date in order to 4657 insure that they remain active. Subscriptions can also be redefined or renewed using this API. 4658 The subscriptionKey pertaining to the subscription to be renewed must be supplied in the 4659 save_subscription invocation in order to accomplish this. This allows both renewal and 4660 changes to the subscription. Invoking save_subscription automatically resets the expiration 4661 period for the subscription in question to a value based upon the node’s policy. 4662

5.5.8.1 Syntax: 4663

4664

The syntax of the subscription structure is: 4665

4666

Attributes 4667

Name Use

brief optional

4668

�� ¶ ��


144/405

4669

The syntax of the subscriptionFilter structure is: 4670

4671

5.5.8.2 Arguments: 4672

• authInfo: This optional argument is an element that contains an authentication token. 4673 Registries that wish to restrict who can save a subscription typically require authInfo 4674 for this call, though this is a matter of node policy. 4675

• bindingKey: This optional argument of type anyURI specifies the bindingTemplate 4676 which the node is to use to deliver notifications to subscription listeners. It is only 4677 required when asynchronous notifications are used. This bindingTemplate MUST 4678 define either a Web service that implements notify_subscriptionListener (see below), 4679 or an email address to receive the notifications. If a notify_subscriptionListener Web 4680 service is identified, the node invokes it to deliver notifications. If an email address is 4681 identified, the node delivers notifications via email to the address supplied. When 4682 notifications are delivered via email, the body of the email contains the body of the 4683 SOAP message, which would have been sent to the notify_subscriptionListener 4684 service if that option had been chosen. The publisher making the subscription request 4685 MUST own the bindingTemplate. If this argument is not supplied, no notifications are 4686 sent, although subscribers may still use the get_subscriptionResults API to obtain 4687 subscription results. See Section 5.5.11 get_subscriptionResults for details. If email 4688 delivery to the specified address fails, nodes MAY attempt re-delivery, but are not 4689 obligated to do so. Depending upon node policy, excessive delivery failures MAY 4690 result in cancellation of the corresponding subscription. 4691

• brief: This optional argument controls the level of detail returned to a subscription 4692 listener. The default is “false” when omitted. When set to “true,” it indicates that the 4693 subscription results are to be returned to the subscriber in the form of a keyBag, listing 4694 all of the entities that matched the subscriptionFilter. Refer to Section 5.5.6 Use of 4695 keyBag in Subscription, for additional information. This option has no effect on the 4696 assertionStatusReport structure, which is returned as part of a notification when the 4697


145/405

subscriptionFilter specifies the get_assertionStatusReport filter criteria. See the 4698 explanation of subscriptionFilter below. 4699

• expiresAfter: This optional argument allows subscribers to specify the period of time 4700 for which they would like the subscription to exist. It is of the XML Schema type 4701 xsd:dateTime. Specifying a value for this argument is no guarantee that the node will 4702 accept it without change. Information on the format of expiresAfter can be found in 4703 Section 5.5.21.1 Specifying Durations. 4704

• maxEntities: This optional integer specifies the maximum number of entities in a 4705 notification returned to a subscription listener. If not specified, the number of entities 4706 sent is not limited, unless by node policy. 4707

• subscriptionFilter: This argument specifies the filtering criteria which limits the 4708 scope of a subscription to a subset of registry records. It is required except when 4709 renewing an existing subscription. The get_xx and find_xx APIs are all valid choices 4710 for use as a subscriptionFilter. Only one of these can be chosen for each 4711 subscription. Notifications, based on the subscriptionFilter, are sent to the subscriber 4712 if and only if there are changes at the node, which match this criterion during a 4713 notification period. A subscriptionFilter MUST contain exactly one of the allowed 4714 inquiry elements. The authInfo argument of the specified get_xx or find_xx API call is 4715 not required here and is ignored if specified. All of the other arguments supported 4716 with each of these inquiry APIs are valid for use here. 4717

Specifying find_relatedBusinesses is useful for tracking when reciprocal relationships 4718 are formed or dissolved. Specifying get_assertionStatusReport can be used in 4719 tracking when reciprocal relationships (which pertain to a business owned by the 4720 subscriber) are formed, dissolved, or requested by the owners of some other 4721 business. 4722

• subscriptionKey: This optional argument of type anyURI identifies the subscription. 4723 To renew or change an existing subscription, a valid subscriptionKey MUST be 4724 provided. When establishing a new subscription, the subscriptionKey MAY also be 4725 either omitted or specified as an empty string in which case the node MUST assign a 4726 unique key. If subscriptionKey is specified for a new subscription, the key MUST 4727 conform to the registry’s policy on publisher-assigned keys. 4728

• notificationInterval: This optional argument is only required when asynchronous 4729 notifications are used. It is of type xsd:duration and specifies how often change 4730 notifications are to be provided to a subscriber. If the notificationInterval specified is 4731 not acceptable due to node policy, then the node adjusts the value to match the next 4732 longer time period that is supported. The adjusted value is provided with the returns 4733 from this API. Also see Section 5.5.21.1 Specifying Durations. 4734

5.5.8.3 Returns: 4735

Upon successful completion this API returns a subscriptions structure. Included in the 4736 subscription structure(s) it MUST contain is a subscriptionKey (of type anyURI) that is used by 4737 the subscriber to manage the subscription. This key is required in order to delete 4738 (unsubscribe), modify or renew the subscription. If a subscriber has multiple subscriptions, 4739 the subscriptionKey can be used to distinguish between different subscriptions. The 4740 subscriptionKey is also part of the data contained in the notifications returned to subscription 4741 listeners. 4742

4743

The subscription structure(s) returned from this API, MUST each contain an expiresAfter 4744 value, which has been assigned by the node. Nodes SHOULD attempt to honor the value(s) 4745 provided with the save_subscription request, but MAY modify them based on node policy. 4746 Depending upon the node’s policy, the node MAY delete a subscription after it has expired. 4747


146/405

The value of the notificationInterval included in the subscription structure(s) returned MAY be 4748 adjusted by the node to the value closest to that requested which is supported by its policies. 4749 Depending upon the Registry’s workload a node MAY skip a notification cycle. If a cycle is 4750 skipped, the next notification sent SHOULD include information based on registry activity, 4751 which has occurred since the last notification was issued. 4752

5.5.8.4 Caveats: 4753


• E_invalidKeyPassed: signifies that an entity key value passed did not match with 4757 any known key values. The error structure signifies that the condition occurred and 4758 the error text clearly calls out the offending key. 4759

• E_unsupported: signifies that one of the argument values was not supported by this 4760 implementation. The offending argument is clearly indicated in the error text. 4761

• E_resultSetTooLarge: signifies that the node refuses to accept the subscription 4762 because it deems that result sets associated with the subscription are too large. The 4763 subscription criteria that triggered this error should be refined and re-issued. 4764

• E_accountLimitExceeded: signifies that the request exceeded the quantity limits for 4765 subscription requests, based on node policy. 4766

• E_userMismatch: signifies that an attempt has been made to use the subscription 4767 API to change a subscription that is controlled by another party. Or that the 4768 bindingTemplate specified does not belong to the publisher. 4769

• E_requestDenied: signifies that the subscription cannot be renewed. The request 4770 has been denied due to either node or registry policy. 4771

5.5.9 delete_subscription 4772

Cancels an existing subscription. 4773

5.5.9.1 Syntax: 4774

4775

5.5.9.2 Arguments: 4776

• authInfo: This optional argument is an element that contains an authentication token. 4777 Registries that wish to restrict who can delete a subscription typically require authInfo 4778 for this call, though this is a matter of node policy. 4779

• subscriptionKey: This required argument specifies, using anyURIs, the subscription 4780 or subscriptions to be deleted. 4781

5.5.9.3 Returns: 4782

If no errors occur, then E_success and a successful dispositionReport are returned. 4783


147/405

4784

5.5.9.4 Caveats: 4785

If an error occurs in processing this API call, a dispositionReport structure is returned to the 4786 caller in a SOAP Fault. In addition to the errors common to all APIs, the following error 4787 information is relevant here: 4788

• E_userMismatch: signifies that an attempt has been made to use the subscription 4789 API to delete a subscription that is controlled by another party. 4790

• E_invalidKeyPassed: signifies that the subscriptionKey is invalid or that the 4791 subscription has expired. 4792

5.5.10 get_subscriptions 4793

Returns the complete list of existing subscriptions owned by the subscriber. 4794

5.5.10.1 Syntax: 4795

4796

5.5.10.2 Arguments: 4797

• authInfo: This optional argument is an element that contains an authentication token. 4798 Registries that wish to restrict who can obtain information on subscriptions typically 4799 require authInfo for this call, though this is a matter of node policy. 4800

5.5.10.3 Returns: 4801

This API call returns information on all of the subscriptions owned by the subscriber, together 4802 with the expiration date for each. The subscriptions structure returned contains one or more 4803 subscription structures, each pertaining to a subscription. Only subscriptions created by the 4804 invoking subscriber are returned. See Section 5.5.8.1, [save_subscription] Syntax, for details 4805 on these structures. 4806

5.5.10.4 Caveats: 4807

If any error occurs in processing this API call, a dispositionReport structure is returned to the 4808 caller in a SOAP Fault. There is no specific error information, other than the errors common to 4809 all APIs. 4810


148/405

4811

5.5.11 get_subscriptionResults 4812

This API allows a subscriber to request that the information pertaining to an existing 4813 subscription be returned. This is useful, for example, to obtain historical data when a 4814 subscription is first set up or when a subscriber misses the notification normally provided by 4815 the registry. The results are returned synchronously as the response to this call. The 4816 get_subscriptionResults API can also be used as an alternative to notifications for obtaining 4817 subscription data. If this is the preference, then the subscriber SHOULD not provide a 4818 bindingKey when saving the associated subscription. See Section 5.5.8 save_subscription. 4819 This API is not affected by the value of the notificationInterval in the subscription. 4820

5.5.11.1 Syntax: 4821

4822

5.5.11.2 Arguments: 4823

• authInfo: This optional argument is an element that contains an authentication token. 4824 Registries that wish to restrict who can retrieve subscription data typically require 4825 authInfo for this call, though this is a matter of node policy. 4826

• chunkToken: This optional argument is used to retrieve subsequent groups of data 4827 when the first call to this API indicates more data is available. This occurs when a 4828 chunkToken is returned whose value is not “0” in the subscriptionResultsList structure 4829 described in the next section. To retrieve the next chunk of data, the value returned 4830 should be used as an argument to the next invocation of this API. 4831

• coveragePeriod: This structure defines the time period over which the most recent 4832 changes in node data are compared with the subscription criteria in order to produce 4833 the result set. It provides start and end date/time information according to the format 4834 described in Section 5.5.4 Subscription Coverage Period. The “current” state of 4835 registry entries pertaining to the subscription referenced by the subscriptionKey 4836 provided are returned if they were last created, changed or deleted during the 4837 specified time period. 4838

• subscriptionKey: This required argument of type anyURI identifies the subscription 4839 for which non-recurring synchronous results are being sought. 4840

5.5.11.3 Returns: 4841

A subscriptionResultsList is returned whose content is determined by the coveragePeriod and 4842 the criteria in the subscription: 4843


149/405

4844

Attributes 4845

Name Use

someResultsUnavailable optional

4846

Subscription results MAY be chunked. See Section 5.5.5 Chunking of Returned Subscription 4847 Data, for more information on chunking of results. If results are chunked, then subsequent 4848 “chunks” can be retrieved using the chunkToken returned as an argument in a subsequent 4849 invocation of this API. 4850

Note that the results returned in the subscriptionResultsList represent a snapshot of the current 4851 state of relevant entries in the registry. They are non-transactional in nature and prior states 4852 cannot be returned. Deleted entities and virtual deletes of entities, which have been changed 4853 in such a way that they no longer match the subscription criterion saved with the subscription, 4854 are returned only in the form of a keyBag structure, for which the deleted element is set to 4855 “true”. A UDDI node MAY inform a subscriber about the real or virtual deletion of an entity 4856 multiple times. 4857

The someResultsUnavailable attribute is set to “true” whenever the node has found it 4858 necessary to flush subscription results information pertaining to entity deletions (either actual or 4859 virtual) which pertain to this subscription, which have not yet been reported through prior calls 4860 to this API, or through use of the notify_subscriptionListener API described below. The period 4861


150/405

of time which a node retains information on deletions for a given subscription is a matter of 4862 node policy. 4863

4864

5.5.11.4 Caveats: 4865


• E_invalidKeyPassed: signifies that the subscriptionKey is invalid or that the 4869 subscription has expired. 4870

• E_invalidValue: signifies that the chunkToken value supplied is either invalid or has 4871 expired. 4872

• E_unsupported: signifies that one of the argument values was not supported by this 4873 implementation. The offending argument is clearly indicated in the error text. 4874

• E_userMismatch: signifies that, in a violation of node policy, an attempt has been 4875 made to use the subscription API to change a subscription that is controlled by 4876 another party. 4877

• E_invalidTime: signifies that one or both of the values provided in the 4878 coveragePeriod range is invalid or does not define a range. The error structure 4879 signifies the condition that occurred and the error text clearly calls out the cause of the 4880 problem. 4881


151/405

4882

5.5.12 notify_subscriptionListener 4883

This API, when implemented by a subscriber and specified in a subscription, enables the node 4884 to deliver notifications to subscription listeners by invoking a Web service. New, modified, and 4885 deleted data that matches the subscription is passed to notify_subscriptionListener. If the brief 4886 attribute of the subscription is “true”, then only the relevant keys will be sent; full details of the 4887 changed data can be accomplished via the standard get_xx API’s if required. If a particular 4888 item that matches the subscription criteria is deleted during the notificationInterval, or is 4889 changed in such a way that it no longer matches the criterion defined for the subscription, then 4890 these entities are included in a keyBag containing a deleted element with a value of “true”. 4891

To allow subscribers to determine whether a notification has been lost, the coverage period of 4892 the notification is included. A date/time indicating the date/time values corresponding to the 4893 start and end points of this is provided. The start date/time used in this call SHOULD align with 4894 the end date/time of the previous call and so fourth. 4895

If the maxEntities option was specified in the save_subscription call, the response supplied via 4896 this call is limited to that number of entities. If the node cannot send all of the results in a 4897 single notify_subscriptionListener call, then the node repeatedly invokes the 4898 notify_subscriptionListener service until all information has been transmitted. In no case will 4899 the data sent to notify_subscriptionListener exceed the maximum message size per the policy 4900 of the node. 4901

5.5.12.1 Syntax: 4902

4903

4904

5.5.12.2 Arguments: 4905

• authInfo: This optional argument is an element that contains an authentication token. 4906 Subscription listener services that wish to restrict who can transmit subscription data 4907 MAY require authInfo for this call, though this is a matter of client policy. 4908

• subscriptionResultsList: This list contains the results for this notification, which 4909 consist of the result structures which are normally returned for standard find_xx or 4910 get_xx APIs, based upon the criteria saved in the subscriptionFilter for the 4911 subscription which is generating this notification. Note that the chunkToken is not 4912 returned with this structure for this API. The subscriptionResultsList also contains a 4913 coveragePeriod structure which defines the time period over which the node data is 4914 compared with the subscription criterion in order to produce the result set. It provides 4915 the start and end date/time information according to the format described in Section 4916 5.5.4 Subscription Coverage Period. The “current” state of registry entries pertaining 4917 to the subscription referenced by the subscriptionKey provided are returned if they 4918 were last changed during the specified time period. See Section 5.5.11.3 Returns for 4919 more information on the subscriptionResultsList’s content. 4920

�� Node


152/405

5.5.12.3 Returns: 4921

Upon successful completion, notify_subscriptionListener returns a dispositionReport indicating 4922 E_success. Note that this is being returned by the client supported API. 4923

5.5.12.4 Caveats: 4924


• E_fatalError: signifies the client’s failure to receive notification data. The node is not 4928 obligated to retry. 4929


153/405

5.6 Value Set API Set 4930

Whenever a keyedReference is involved in a save operation it may be checked to see that it is 4931 valid. Similarly, a keyedReferenceGroup element that is involved in a save operation may also 4932 be checked to ensure that it is valid. Checking is performed for tModels that are deemed to be 4933 "checked", as determined by the policy of the UDDI registry. 4934

UDDI provides the ability for third parties to register value sets, and then control the validation 4935 process used by UDDI to perform such checks. UDDI registries MAY support caching of these 4936 external value sets. UDDI registries MAY also support external validation. Node and registry 4937 policies determine the manner in which validation of references to external value sets is 4938 performed. The APIs in this section can be used by UDDI registries and nodes in their 4939 validation policies. 4940

Third parties that want to provide an external checking capability may be required by the UDDI 4941 registry to implement a Web service in the same manner that UDDI does (e.g. using SOAP for 4942 message passing using literal encoding) that exposes a single method named validate_values. 4943 The interface for validate_values is described here. 4944

In some cases a node may desire to eliminate or minimize the number of calls to external 4945 validation Web services. It can do so by caching valid values for those external value sets that 4946 allow caching of their values. A node has two normative options for obtaining the set of valid 4947 values. One is to periodically obtain the set of valid values from those value set providers that 4948 implement a Web service that handles the get_allValidValues API. This API is described 4949 below. The other method of obtaining a cache of valid values is to accumulate the valid values 4950 from successful calls to validate_values. 4951

5.6.1 Value Set Programming Interfaces 4952

The Application Programming Interfaces in this section represent capabilities that a UDDI 4953 registry MAY use to enable validation of references to value sets. Registry policy determines 4954 which external value sets are supported and how. See Section 9.4.19 Value Set Policies and 4955 Section 9.6.65Value Sets for more information on registry support of external value sets. 4956 These SOAP messages all behave synchronously. 4957

The publicly accessible APIs that are used to support external value set validation are: 4958

• validate_values: Used by nodes to allow external providers of value set validation 4959 Web services to assess whether keyedReferences or keyedReferenceGroups are 4960 valid. Returns a dispositionReport structure. 4961

• get_allValidValues: Used by nodes that support caching of valid values from 4962 cacheable checked value sets to obtain the set of valid values. Returns a 4963 validValuesList structure. 4964

Registry policy may require value set providers that offer one of these Web services to publish 4965 the bindingTemplate for the service and the tModel for the value set in a particular way so that 4966 the proper Web service can be discovered. See Section 9.6.65 Value sets for more 4967 information. When a value set provider offers one of these Web services, a tModel for the 4968 checked value set SHOULD be published in any registry the provider wishes to offer it, and a 4969 bindingTemplate SHOULD be published for the Web service(s) the value set provider offers 4970 for the checked value set. The tModel SHOULD have categorizations from the uddi-org:types 4971 category system to indicate the type of value set (categorization, identifier, relationship, 4972 categorizationGroup), that it is checked (checked), and, if the value set provider allows 4973 validation to occur against node caches of valid values, the cacheable categorization should 4974 also be provided. The tModel should also have a categorization reference to the 4975 bindingTemplate of the get_allValidValues or validate_values Web service that the value set 4976 provider designates, using the uddi-org:validatedBy category system. See Section 11.1.1 4977

�� provision


154/405

UDDI Types Category System and Section 11.1.7 Validated By Category System for more 4978 information. 4979

The bindingTemplate for the get_allValidValues or the validate_values Web service SHOULD 4980 reference in its tModelInstanceDetails the appropriate value set API tModel (Section 11.2.7 4981 Value Set Caching API tModel or Section 11.2.8 Value Set Validation API tModel) as well 4982 tModels for all of the value sets the service applies to. 4983

5.6.2 validate_values 4984

A UDDI node that supports external validation sends the validate_values API to the 4985 appropriate external Web service, of which there is exactly one, whenever a publisher saves 4986 data that uses a keyedReference or keyedReferenceGroup whose use is regulated by the 4987 external party who controls that Web service. For purposes of discussion, the identifier, 4988 category, and relationship type systems that the keyedReference elements refer to are called 4989 checked value sets. The category group systems that the keyedReferenceGroup elements 4990 refer to are similarly called checked category group systems. 4991

The normal use for checked value sets is to verify that specific values (checking the keyValue 4992 attribute of values supplied) exist within the value set. For certain value sets the value set 4993 provider may further restrict the use of a value based on a contextual evaluation of the passed 4994 data. The provider may do enable this contextual checking by offering a validation Web 4995 service. 4996

Validation algorithms for checked category group systems similarly verify that the contents of 4997 the keyedReferenceGroup elements form a valid set according to the validation algorithm for 4998 the checked category group system. Frequently such validation ensures that the value sets 4999 identified in contained keyedReferences are allowed to participate in the category group 5000 system. 5001

5.6.2.1 Syntax: 5002

5003

5004


155/405

5.6.2.2 Arguments: 5005

The UDDI node that is calling validate_values MUST pass one or more businessEntity 5006 elements, one or more businessService elements, one or more bindingTemplate elements, 5007 one or more tModel elements, or one or more publisherAssertion elements as the sole 5008 argument to this Web service. The one or more elements passed represents the outermost 5009 UDDI data structure(s) being passed within a save_business, save_service, save_binding, 5010 save_tModel, add_publisherAssertion, or set_publisherAssertions API call. Multiple elements 5011 of the same type may be passed together if multiples are included in the same save 5012 invocation. 5013

The optional authInfo argument is an element that contains an authentication token. An 5014 authentication token is obtained using the get_authToken API call or through some other 5015 means external to this specification. Providers of validate_values Web services that serve 5016 multiple registries and providers that restrict who can use their service may require authInfo for 5017 this API. 5018

5.6.2.3 Behavior 5019

The called Web service for a checked value set performs validation on all of the 5020 keyedReferences or keyedReferenceGroups that are associated with the value sets the Web 5021 service is authorized to check. This can involve merely checking that the keyValue values 5022 supplied are good for the given value set (as signified by the embedded keyedReference 5023 tModelKey values). Other types of validation as desired may be performed, including context 5024 sensitive checks that utilize the information passed in the entity being saved. 5025

The entity being saved may contain multiple references to values from the value set(s) that the 5026 validation Web service is authorized to validate. When the entity being saved is a 5027 businessEntity, contained businessService and bindingTemplate entities may themselves 5028 reference values from the authorized value sets as well. All references to values that are 5029 associated with the value set(s) that the validation Web service is authorized to check MUST 5030 be validated without regard to their placement in the entity being saved. 5031

If the external value set and the node both support caching of valid values, the node may not 5032 invoke validate_values if it already knows that the referenced values are valid, through 5033 checking its cache. 5034

A checked category group system is treated in the same manner as a checked value set. The 5035 tModelKey associated with the keyedReferenceGroup identifies the checked category group 5036 system. A node may be able to validate a reference to a cacheable checked category group 5037 system without calling validate_values if it can determine using its cache that the tModelKey 5038 attributes from the keyedReference elements contained in the keyedReferenceGroup are 5039 allowed for the category group system. 5040

5.6.2.4 Returns: 5041

If all values referenced in the entity being saved are valid from the value set(s) or category 5042 group system(s) that the validation Web service is authorized to validate, the proper response 5043 is a dispositionReport structure as specified in Section 4.8 Success and Error Reporting. The 5044 error code value returned MUST be E_success and the errno value in the result MUST be "0". 5045

5.6.2.5 Caveats: 5046

If any error is found, or the called Web service needs to signal that the information being saved 5047 is not valid based on the validation algorithm chosen by the external Web service provider, 5048 then the Web service MUST raise a SOAP Fault as specified in Section 4.8 Success and Error 5049 Reporting. 5050

When an error is signaled in this fashion, the UDDI node MUST reject the pending change and 5051 return to the original caller the same SOAP fault data returned by the validation Web service. 5052

�� "

�� "


156/405

The error codes indicate one of the following reasons, and the error text clearly indicates the 5053 keyedReference or keyedReferenceGroup data that is being rejected and the reason it is 5054 being rejected. 5055

• E_invalidValue: One or more of the keyValues in the keyedReference or 5056 keyedReferences in the keyedReferenceGroup supplied failed validation. Only the 5057 first error encountered need be reported. 5058

• E_valueNotAllowed: The values may be valid, but are not allowed contextually. 5059

5.6.3 get_allValidValues 5060

A UDDI node that supports external value sets MAY invoke a get_allValidValues Web service 5061 offered by a value set provider that has granted permission to that registry to cache the valid 5062 values for that value set. The external value set provider MAY offer the get_allValidValues 5063 Web service and the UDDI node MAY use it. The normal use is to return a full set of valid 5064 values for the identified value set. If the value set provider determines there are too many 5065 values to return in one chunk, the set of valid values may be returned in chunks. 5066

Registry policy may require the value set provider that offers a get_allValidValues Web service 5067 to republish its value set tModel when the cache should be re-acquired by participating nodes. 5068 See Section 9.6.65 Value Sets for more information. 5069

get_allValidValues can similarly be used to obtain the set of tModelKeys for value sets that can 5070 participate in a cached category group system. 5071

5.6.3.1 Syntax: 5072

5073

5.6.3.2 Arguments: 5074

• tModelKey: A required uddiKey value that identifies the specific instance of the 5075 tModel which describes the value set or category group system for which a Web 5076 service to get all valid values has been provided. It uniquely identifies the category, 5077 identifier, or category group system for which valid values are being requested. 5078

• chunkToken: Optional element used to retrieve subsequent groups of data when the 5079 first invocation of this API indicates more data is available. This occurs when a 5080 chunkToken is returned whose value is not “0” in the validValuesList structure 5081 described in the next section. To retrieve the next chunk of data, the chunkToken 5082 returned should be used as an argument to the next invocation of this API. 5083

• authInfo: An optional element that contains an authentication token. Authentication 5084 tokens are obtained using the get_authToken API call or through some other means 5085 external to this specification. Providers of get_allValidValues Web services that serve 5086 multiple registries and providers that restrict who can use their service may require 5087 authInfo for this API. 5088

5089


157/405

5.6.3.3 Returns 5090

A validValuesList structure is returned containing the set of valid values for the external 5091 category or identifier system. The list MUST contain a chunkToken if the Web service provider 5092 wishes to provide the data in packets. The validValuesList has the form: 5093

5094

And its contained validValue element has the form: 5095

5096

5.6.3.4 Behavior 5097

The called Web service returns the set of valid values in a validValuesList on success. This 5098 structure lists every valid value associated with the value set or category group system that is 5099 described by the tModelKey provided. In the event too many values exist to be returned in a 5100 single response (i.e., the message size exceeds the maximum number of bytes allowed by the 5101 UDDI registry), or the value set provider wants to supply the values in multiple packets, then 5102 the validValueList includes the chunkToken element and the API can be re-issued to get the 5103 remaining valid values. 5104

5.6.3.4.1 Chunking of valid values 5105

If the value set provider determines that there are too many values to be returned in a single 5106 group, then the provider SHOULD provide a chunkToken with the results. The chunkToken is 5107 a string based token which is used by the value set provider to maintain the state of the set of 5108 values for a particular caller, when these results are chunked across multiple responses. 5109 Providers should establish their own policies for determining the content and format of the 5110 chunkToken. The chunkToken returned with a particular value set result set SHOULD be used 5111 to retrieve subsequent results. If no more results are pending, the value of the chunkToken will 5112 be “0” or the chunkToken will be absent. 5113

A chunkToken is intended as a short-term aid in obtaining contiguous results across multiple 5114 API calls and is therefore likely to remain valid for only a short time. Value set providers may 5115 establish policies on how long a chunkToken remains valid. 5116

5.6.3.5 Caveats: 5117

If any error occurs in processing this API, a dispositionReport structure MUST be returned to 5118 the caller in a SOAP Fault. See Section 4.8 Success and Error Reporting. The following error 5119 information is relevant: 5120

• E_invalidKeyPassed: Signifies that the tModelKey passed did not match with the 5121 uddiKey of any known tModels. The details on the invalid key SHOULD be included 5122 in the dispositionReport element. 5123

• E_noValuesAvailable: Signifies that no values could be returned. 5124

• E_unsupported: Signifies that the Web service does not support this API. 5125

�� value

�� (10210)

�� (40200)

�� (10050)


158/405

• E_invalidValue: Signifies that the chunkToken value supplied is either invalid or has 5126 expired. 5127

5128

5129

�� (20200)


159/405

5130

6 Node Operation 5131

This chapter defines the normative behavior required of an operator hosting a UDDI node. It 5132 outlines the operational parameters and requirements that a node MUST follow. It also 5133 provides guidance when first bringing a node online. The intended audience for this chapter is 5134 someone intending to implement and host a UDDI node. 5135

Note that this chapter alone is not sufficient to understand how to implement and host a node. 5136 Refer to each of the preceding chapters, in order to understand the full scope of the UDDI 5137 specification. They provide the normative behavior in terms of how the APIs work. 5138 Considerations regarding intra-registry operation (such as replication between nodes) and 5139 inter-registry operation (such as publishing data across multiple registries) are dealt with in 5140 Chapter 7 Inter-Node Operation and Chapter 8 Publishing Across Multiple Registries 5141 respectively. Also, node implementers must be cognizant of the policy decisions that they 5142 must make; the list of policy-related decisions can be found in Chapter 9 Policy. 5143

This chapter addresses only the operational specifics that must be followed when hosting a 5144 node, regardless of whether that node exists as the sole node in a registry or takes part in a 5145 multi-node environment. 5146

6.1 Managing Node Contents 5147

This section provides procedures and requirements for managing and maintaining the 5148 information within the UDDI registry. 5149

6.1.1 XML Requirements 5150

Given the use of XML, XML Schema, SOAP, and XML-Dsig within UDDI, a node must take 5151 care to adhere to these standards when processing data. Specific additional requirements 5152 layered upon these standards are included in the UDDI specification. Each node is 5153 responsible for implementing these additional requirements as well as those defined by the 5154 published standards. 5155

6.1.1.1 Processing by XML Schema Assessment 5156

UDDI nodes MUST assess the validity of the XML elements that comprise the API requests 5157 they receive. This SHOULD be carried out by means of appealing to the 2nd or 3rd approaches 5158 enumerated in Section 5.2 Assessing Schema-Validity of XML Schema Structures 5159 (http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#validation_outcome). API request 5160 elements which, having been so assessed are not found to have a [validity] property 5161 (http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#sic-e-outcome) of valid, MUST 5162 not be further processed by the node. An indication of this fact MUST be reported to the client 5163 by returning an error. 5164

Note that a side effect of processing by XML Schema Assessment is that whitespace in 5165 elements and attributes is normalized (http://www.w3.org/TR/2001/REC-xmlschema-1-5166 20010502/section-White-Space-Normalization-during-Validation) in a well-defined manner. 5167

6.1.1.2 Normalization and Canonicalization 5168

UDDI registries provide publishers with the ability to digitally sign entities they publish, and 5169 inquirers with the ability to validate the digital signatures on published material. In order for this 5170 to be possible, publishers and registries MUST handle “normalization” and “canonicalization” 5171 as described in Section 4.6.1.1 Normalization and Canonicalization. 5172


160/405

6.1.2 Key Generation and Maintenance 5173

At the core of the UDDI specification is the ability to uniquely identify entities in a UDDI registry. 5174

6.1.2.1 Key Uniqueness 5175

Each key stored by a node must be verified to be unique. The node must not allow the 5176 generation or storage of a key that is already present somewhere in the registry. This applies 5177 to both the node where the entry was originally saved, and, in the event the node is a part of a 5178 multi-node registry, any other node in the registry. See Section 4.4 About uddiKeys for an 5179 extensive discussion around considerations in key generation and Chapter 9 Policy for more 5180 on policy decisions a node must make around key generation. 5181

6.1.2.2 Node Generated Keys 5182

When a node generates a uuidKey for an entity, it must make certain that the process of 5183 creating these is a correct one. Nodes SHOULD use the time-based or random number based 5184 UUID generation algorithm as defined at http://uddi.org/pubs/draft-leach-uuids-guids-01.txt. 5185

6.1.3 Updates and Deletions 5186

When an entity that contains other entities is updated, the entire content of the updated entity, 5187 including contained entities, is replaced. When making updates to the registered information, 5188 the integrity of the overall registry must be maintained. 5189

In particular, when deleting information from the UDDI registry, the following atomicity must be 5190 maintained: 5191

• When the deletion of an entity occurs and that entity contains other entities (i.e., a 5192 businessService within a businessEntity), all contained entities MUST also be deleted. 5193

• Any referenced entities (i.e., a tModel reference) MUST NOT be deleted. 5194

• tModel deletion (more accurately described as deprecation or "hiding") behavior is 5195 different from that of the other UDDI entities. The result of a tModel deletion request is 5196 that it is stored in a deprecated state. 5197

6.2 Considerations When Instantiating a Node 5198

When first bringing a node online, several steps should be followed. 5199

6.2.1 Canonical tModel Bootstrapping 5200

A node MUST provide the canonical UDDI tModels (outlined in Chapter 11 Utility tModels and 5201 Conventions) for entities to reference. The node MAY acquire these canonical tModels either 5202 through performing an import of these tModels, through participating in a replication topology 5203 or through other means. 5204

6.2.2 Self-Registration of Node Business Entity 5205

6.2.2.1 Normative Modeling of Node Business Entity 5206

A node MUST register itself in the UDDI registry of which it is a part, so that it can be uniquely 5207 distinguished within a registry. This UDDI entry is known as the “Node Business Entity”. The 5208 node MUST categorize its Node Business Entity with the uddi:uddi.org:categorization:nodes 5209 tModel using the keyValue, “node”: 5210

<categoryBag> 5211 <keyedReference 5212 tModelKey="uddi:uddi.org:categorization:nodes” 5213 keyName=”” 5214

�� node business entity

�� ¶


161/405

keyValue="node"/> 5215 </categoryBag> 5216

5217

This checked category system is only permitted to be used by the node itself. If another 5218 publisher attempts to save a categoryBag that has a reference to the 5219 “uddi:uddi.org:categorization:nodes” category system, the node MUST return an error. This 5220 checking guarantees the ability to query a single node and determine all the nodes that 5221 participate in a given registry. 5222

6.2.2.2 Recommended Modeling of Node Business Entity 5223

A node is composed of Web services that implement one or more UDDI API sets. A node 5224 SHOULD model those Web services within its Node Business Entity. The modeling of the 5225 Node Business Entity SHOULD include the following characteristics: 5226

• Each bindingTemplate that describes an implementation of a UDDI API set SHOULD 5227 use tModelInstanceInfos that reference the API tModels of the API sets the 5228 implementation supports (e.g., uddi-org:inquiry_v3). See Chapter 9 Policy and 5229 Section 11.21.9 UDDI Registry API tModels. 5230

• Each bindingTemplate provided SHOULD model the transport protocols and security 5231 protocols supported by the implementation it describes. 5232

• Each bindingTemplate provided SHOULD model the policies of the given node. One 5233 option is to provide those policies in a document that can be found via the 5234 overviewURL of the tModelInstanceInfo of a given bindingTemplate. Another option is 5235 to model those policies using instanceParms, categorization schemes or other UDDI 5236 constructs. 5237

Because the UDDI data model offers great flexibility in how the modeling of services is 5238 achieved and because the context in which a node might exist varies greatly, normative 5239 mandates on the modeling of a Node Business Entity are inappropriate. However, it may be 5240 the policy of a given registry that each node participating in that registry must model its Node 5241 Business Entity according to a given template or pattern. 5242

6.3 User Credential Requirements 5243

6.3.1 Establishing User Credentials 5244

A UDDI node MAY require users to establish an account with the node, before they are 5245 allowed to utilize some or all of the services at the node. The process for registration is 5246 determined by policy and may be node-specific. 5247

For registries or nodes that enforce a policy relating particular publishers as owners of 5248 particular datum, it is essential that there is a mechanism to identify the publisher of each entity 5249 published at the node. Although this data is not reflected in the schema provided by UDDI, it 5250 should be stored and obtainable by a node for entities for which it has custody of. See Section 5251 1.5.8 Data Custody and Section 1.5.6 Person, Publisher and Owner. 5252

6.3.2 Changing Entity Ownership 5253

A UDDI node SHOULD provide an interface to permit a user to transfer ownership of data it 5254 currently owns to another user within that node. An API for this procedure is given in Section 5255 5.4 Custody and Ownership Transfer API. 5256


162/405

6.4 Checked Value Set Validation 5257

This section describes the normative node behavior with respect to value set references. 5258 Much of the node behavior in this area is not normative, but instead is driven by registry and 5259 node policy. 5260

For more on external validation checking, see Section 5.6 Value Set API and Chapter 9 Policy. 5261

6.4.1 Normative behavior during saves 5262

Every time a publisher saves an entity that has a keyedReference associated with a checked 5263 value set, the node MUST perform validation in a manner that is acceptable to the value set 5264 provider, or MUST reject the reference with an E_unsupported error code. How a UDDI node 5265 determines that the referenced value set is checked, where that value set is hosted, locates 5266 and invokes the validation algorithm, determines that a validation algorithm is acceptable, and 5267 deals with unavailability of the validation algorithm is all driven by registry, and in some cases, 5268 node policy. 5269

When a UDDI node encounters a reference to a checked value set that it validates it MUST: 5270

• Perform validation for each top-level entity being saved. 5271

• Inspect tModel references in categoryBag, identifierBag or publisherAssertion 5272 keyedReferences, and keyedReferenceGroups to determine if references are to be 5273 checked. 5274

• Fail the save when any keyedReference fails validation. 5275

• Pass along error information for E_ invalidValue and E_valueNotAllowed errors from 5276 the validation algorithm to the caller of the save operation. 5277

• Return E_unvalidatable if the validation algorithm is unavailable. 5278

A UDDI node that encounters a keyedReference for a checked value set that it validates 5279 MUST do so using one of the following methods: 5280

• Invoke the validation algorithm once for each individual reference, or once for the for 5281 the collective set of references to all value sets that share the same validation 5282 algorithm 5283

• Perform validation itself on cached values for checked value sets that the value set 5284 provider has allowed to be cached. 5285

• Grandfather previously validated value references when the validation algorithm is not 5286 available such that existing keyedReferences are considered still valid and are not re-5287 checked while the validation algorithm is unavailable. Nodes MAY allow previously 5288 validated keyedReferences associated with that unavailable value set to be 5289 (re)published without failing the save (e.g. the references are grandfathered and 5290 remain valid even though they can't be checked). This gives nodes the opportunity to 5291 not penalize those publishers that attempt to reference a value set marked 5292 unvalidatable. However, new value references an unavailable value sets MUST be 5293 rejected. 5294

6.5 HTTP GET Services for UDDI Data Structures 5295

A node may offer an HTTP GET service for access to the XML representations of UDDI data 5296 structures. If a node offers this service, the URLs should be in a format that is predictable and 5297 uses the entity key as a URL parameter. 5298

The RECOMMENDED syntax for the URLs for such a service is as follows: 5299


163/405

If a UDDI node’s base URI is http://uddi.example.org/mybase, then the URI 5300 http://uddi.example.org/mybase?<entity>Key=uddiKey would retrieve the XML for the 5301 data structure whose type is <entity> and whose key is uddiKey. For example, the 5302 XML representation of a tModel whose key is "uddi:tempuri.com:fish:interface" can be 5303 retrieved by using the URL 5304 http://uddi.example.org/mybase?tModelKey=uddi:tempuri.com:fish:interface. 5305

In the case of businessEntities, the node MAY add these URIs to the businessEntity’s 5306 discoveryURLs structure, though this is NOT RECOMMENDED behavior as it complicates the 5307 use of digital signatures. 5308

�� <

�� >

�� <

�� >


164/405

5309

7 Inter-Node Operation 5310

This chapter defines the normative behavior of UDDI nodes interacting as a single UDDI 5311 registry. It outlines the operational parameters and requirements that UDDI nodes and UDDI 5312 registries must follow. These parameters and requirements are policies that a registry must 5313 establish and that the nodes must enforce. This chapter also describes the OPTIONAL 5314 replication protocol for propagation of UDDI data among nodes of a registry. The intended 5315 audiences for this chapter are registry administrators and node operators intending to 5316 implement and host a multi-node UDDI registry. 5317

Considerations regarding inter-registry operation, such as data import and export between 5318 affiliated registries, are detailed in Section 8.2 Data Management Policies and Procedures 5319 Across Registries. 5320

7.1 Inter-Node Policy Assertions 5321

Any set of nodes composing a single UDDI registry MUST enforce a set of policies for keying, 5322 data management and value sets as defined in Chapter 9. 5323

This chapter focuses on the replication protocol that is appropriate to a multi-node registry that 5324 uses a single-master data model and assumes the data custody policy in the following section. 5325

7.1.1 Data Custody 5326

Registries that use the replication protocol defined in Section 7.4 Replication API Set MUST 5327 enforce the data custody policy specified in Section 1.5.6 Data Custody. 5328

Portions of the Custody Transfer process discussed in Section 5.4 Custody and Ownership 5329 Transfer API are designed to utilize UDDI Replication.5330


165/405

5331

7.2 Concepts and Definitions 5332

Where two or more nodes are integrated into a registry, the use of the replication API 5333 described in this chapter allows the registry to be viewed as a single logical entity. A registry 5334 designed in this way supports uniform access to a complete set of registry data from any node 5335 within the registry. The goal of replication is to facilitate the establishment and maintenance of 5336 a single consistent shared set of registry data. Replication latency notwithstanding, all nodes in 5337 a registry should at all times contain common content. 5338

This chapter describes the data replication process and programmatic interface required to 5339 achieve complete data replication in UDDI registries composed of more than one node. The 5340 replication process makes use of Extensible Markup Language (XML) and Simple Object 5341 Access Protocol (SOAP) specification for using XML in simple message-based exchanges as 5342 described in Section 7.4 Replication API Set. 5343

In general terms this section describes the replication API’s and behavior required of any node 5344 that intends to support UDDI replication. This function may be thought of as satisfying the 5345 following base requirements: 5346

• Support the addition of a node, by supplying to it an image of the current registry 5347 contents. 5348

• Support periodic replication between the nodes that compose a registry. 5349

• Support recovery from errors encountered during replication processing. 5350

Note: Please refer to Chapter 2 UDDI Schemas for the reference to the UDDI XML Schema 5351 and to the UDDI Replication XML Schema files. 5352

7.2.1 Update Sequence Number 5353

Each node SHALL maintain a strictly increasing register known as its Originating Update 5354 Sequence Number (USN). An originating USN is assigned to a change record at its creation 5355 by a node. The originating USN SHALL NEVER decrease in value, even in the face of system 5356 crashes and restarts. UDDI nodes MUST NOT rely on an originating USN sequence 5357 increasing monotonically by a value of “1”. Gaps in a node's originating USN sequence MUST 5358 be allowed for as they are likely to occur in the face of system crashes and restarts. 5359

While processing changes to the Registry as a result of performing UDDI Replication, all 5360 replicated data MUST be assigned an additional unique and locally generated USN register 5361 value – a local USN. 5362

The originating and local USN registers MUST be sufficiently large such that register rollover is 5363 not a concern. For this purpose, UDDI nodes MUST implement a USN of exactly 63 bits in 5364 size. 5365

Note that it is semantically meaningless to compare USNs that have been generated on 5366 different nodes; only USNs generated on the same node may be meaningfully compared to 5367 each other. 5368

NO change record MAY have a USN equal to 0 (zero). 5369

�� a


166/405

5370

7.2.2 Change Records 5371

When a publisher changes a specific datum at a node, the node will create a change record 5372 that describes the details of the change. 5373

Each change record contains the following information: 5374

• The unique key of the originating node at which the change record was initially 5375 created. 5376

• An originating USN with which the change record is assigned at its creation by its 5377 originating node. 5378

• A payload of data that conveys the semantics of the change in question. These are 5379 elaborated and specified later in this chapter. 5380

The UDDI replication process defines how change records are transmitted between nodes of a 5381 registry. Each step of replication involves the transmission of such records from one node to 5382 another, say from Node A to Node B. As Node B receives change records from Node A, Node 5383 B assigns each incoming record with a fourth piece of (Node-B-generated) information, a local 5384 USN. 5385

It is RECOMMENDED that within an implementation, a node should first process a new or 5386 updated record and then increment its originating and local USN registers. This process 5387 assures that the USN values remain unique. 5388

Should an implementer choose to record change records generated by an implementation 5389 within a Change Record Journal, the local USN and the originating USN values it assigns to a 5390 given change record MAY be set to an identical USN value. Thus, all change records ever 5391 processed by a node can be sequenced in order of the time of arrival via the replication stream 5392 by sorting on the local USNs values of change records it holds. 5393

A node that is ready to initiate replication of change records held at another node within the 5394 registry uses the get_changeRecords message. Part of the message is a high water mark 5395 vector that contains for each node of the registry the originating USN of the most recent 5396 change record that has been successfully processed by the invocating node. The effect of 5397 receiving a get_changeRecords message causes a node to return to the calling node change 5398 records it has generated locally and processed from other nodes constrained by the directives 5399 of the high water mark vector specified. As such, by invoking get_changeRecords a node 5400 obtains from its adjacent node all change records (constrained by the high water mark vector) 5401 the adjacent node has generated locally or successfully processed from other nodes 5402 participating in the replication topology. What constitutes an adjacent node is governed by the 5403 replication communication graph. Replication topology is controlled via a Replication 5404 Configuration Structure. Amongst other parameters, the Replication Configuration Structure 5405 identifies one unique URL to represent the replication point, soapReplicationURL, of each of 5406 the nodes of the registry. 5407

Upon receiving a get_changeRecords message, a node MUST return change records strictly 5408 in increasing order of its local USN values. This property, together with the rules by which local 5409 USNs are assigned, provides the following guarantee: Suppose a publisher, whose data is 5410 held at node B (that is, Node B is the custodian of that data) changes its data. Node B 5411 originates a change record cr. Then it is guaranteed that any other node that receives change 5412 record cr will have previously received all changes which on Node B had a local USN less than 5413 the local (and originating) USN of cr. This, however, is true only of changes cr that Node B 5414 originates. 5415

This important cause and effect relationship is relied upon in several places in the UDDI 5416 Replication design, notably the algorithm by which information is ultimately deleted from the 5417 UDDI registry. 5418

�� ChangeRecords


167/405

5419

7.2.3 Change Record Journal 5420

Accurate replication of data within a UDDI registry relies on accurate and faithful creation, 5421 transmission, and retransmission of change records between all nodes of the UDDI registry. A 5422 change record originated by a node is the authoritative reference for change information 5423 propagation. It is critical that change records are not inadvertently altered as they are 5424 conveyed from the originating node through intermediate nodes to reach other nodes in the 5425 UDDI registry. 5426

To that end, each node SHOULD create and maintain as part of their internal implementation 5427 a change record journal that explicitly records verbatim the XML text of change records as they 5428 are received from other nodes. This journaling may be performed before or after standard 5429 XML parsing of the change record. 5430

Implementers may find it convenient to also place their own change records in their change 5431 record journal as described above. 5432

7.2.4 High Water Mark Vector 5433

Each node maintains state information in the form of a high water mark vector that contains the 5434 originating USN of the most recent change record that has been successfully processed by 5435 each node of the registry. This vector has one entry for each node that can now or has ever 5436 introduced change records into the replication stream. Each entry contains the following 5437 information: 5438

• nodeID, that provides the unique key of a node in the replication communication 5439 graph, and 5440

• originatingUSN, that provides the originating USN of the most recent change 5441 associated with the node identified by operatorNodeID that has been successfully 5442 consumed. Since changes originating from a given node are always originated and 5443 thus consumed in order, this will necessarily normally be the largest originating USN 5444 that the calling node has successfully consumed from the node identified. 5445

A consuming node MAY reset the originating USN to another value that had been previously 5446 been requested for a given node. This may occur due to the need to obtain change records 5447 from other nodes as part of a recovery operation following a system failure. 5448

5449

7.2.5 Replication Messages 5450

Replication processing consists of the notification of changes that are available and then the 5451 subsequent “pulling” of changes from one of the nodes within the registry. A node within the 5452 registry MAY advertise that changes are available at that node. The advertisement of changes 5453 available includes sufficient information so that another node within the registry can determine 5454 if and when it should pull the changes from the offering node to itself for replication processing. 5455

UDDI Replication defines four messages. The first two presented here are used to perform 5456 replication and issue notifications. These are: 5457

• get_changeRecords - This message is used to initiate the replication of change 5458 records from one node to another. The invoking node, wishing to receive new change 5459

�� identified in

�� communication graph


168/405

records, provides as part of the message a high water mark vector. This is used by 5460 the replication source node to determine what change records satisfy the caller’s 5461 request. 5462

• notify_changeRecordsAvailable - Nodes can inform others that they have new 5463 change records available for consumption by replication by using this message. The 5464 notify_changeRecordsAvailable message is the predecessor to the 5465 get_changeRecords message. 5466

Figure 3 depicts the use of the get_changeRecords and notify_changeRecordsAvailable 5467 messages to carry out the process of replicating changes between UDDI nodes. 5468

5469

Figure 3 - Replication Processing 5470

5471

Two ancillary messages are also defined to support UDDI Replication. These are: 5472

• do_ping - This UDDI API message provides the means by which the current 5473 existence and replication readiness of a node may be obtained. 5474

• get_highWaterMarks - This UDDI API message provides a means to obtain a list of 5475 highWaterMark elements containing the highest known USN for all nodes in the 5476 replication communication graph. 5477

7.2.6 Replication Processing 5478

Replication SHOULD be configured so that in the absence of failures, changes propagate 5479 throughout the UDDI registry within a set amount of time. This requirement means that 5480 get_changeRecords requests MAY have to be sent in some scheduled manner. 5481

For example, assume that the communications graph is a cycle of 4 nodes (A, B, C, and D) 5482 such that D places get_changeRecords request to C (D>C), C>B, B>A, and then finally A>D. 5483

In this example, A starts the Replication process. Periodically, A generates a timer event and 5484 notifies B of its high water vector; if necessary, B issues a get_changeRecords request to A, 5485 and then sends C its high water vector. This continues around the cycle (B>A, C>B, D>C, 5486 A>D), but doesn't stop there. B has not received any changes from C or D for the current 5487 period, and C has not received any changes from D. 5488

So A continues this algorithm around the cycle again (B>A, C>B, D>C). At this point, all 5489 changes that existed when A handled its timer event have been circulated to all nodes. 5490 (Subsequent changes may have also been propagated.) 5491

Nodes within the registry MAY do local optimizations of changes prior to replicating the 5492 changes throughout the UDDI registry. Any local optimizations performed must be invisible to 5493 other nodes within the registry. 5494


169/405

This UDDI API provides a means to obtain a list of highWaterMark elements containing the 5495 highest known USN for all nodes in the replication communication graph. 5496

Validation of replicated data is discussed in Section 7.7 Validation of Replicated Data. Error 5497 detection and processing is discussed in Section 7.6 Error Detection and Processing. 5498

7.3 Change Record Structures 5499

This section provides the definition of the various changeRecord elements defined for use for 5500 UDDI Replication. The overall changeRecord element is defined as follows. 5501

5502

5503

Each change record contains a changeID that identifies the node on which the change 5504 originated and the originating USN of the change within that node. It then contains one of 5505 several allowed forms of change indication; these are elaborated below. With the exception of 5506 a changeRecordAcknowledgement type record, a changeRecord may contain an 5507 acknowledgementRequested attribute. 5508

If present with the acknowledgementRequested value set to “true,” then when each node 5509 receives a change record and successfully processes it into internal data store, that node 5510 MUST in turn originate a new changeRecord with a changeRecordPayload_type of 5511 changeRecordAcknowledgement. This is done to acknowledge the message processing 5512 success and allow that knowledge to be disseminated through the rest of the UDDI registry. 5513

As each changeRecord element first arrives at a node, it must be assigned a local USN value 5514 from the receiving node’s USN register. This local USN allows the node to maintain over time 5515 the relative order of changes it has received from others and changes it has originated locally. 5516 As was mentioned previously, when changes are replicated to others in response to a 5517 get_changeRecords request, the change records are provided in ascending order according to 5518 this local USN. However, the local USN itself never actually appears in any node-to-node data 5519 transmission. 5520

In the event that any changeRecordPayload_type listed below is deprecated in a future version 5521 of this specification, transmissions of the change records of the deprecated 5522 changeRecordPayload_type MUST be treated as replication errors. The corresponding 5523


170/405

handling of those replication transmission errors is specified within Section 7.6 Error Detection 5524 and Processing. 5525


171/405

5526

7.3.1 changeRecordNull 5527

The changeRecordNull element is defined as follows: 5528

5529

Change records of this form do not in fact indicate any sort of semantic change. Rather, their 5530 utility largely lies in providing a convenient and safe means to exercise and test certain aspects 5531 of the UDDI replication infrastructure. In addition, a changeRecordNull to which an 5532 acknowledgement request is attached expands this testing capability of the UDDI registry. 5533

A changeRecordNull is considered “successfully processed” once a node has received it and 5534 durably stored it in its Change Record Journal. 5535

7.3.2 changeRecordNewData 5536

The changeRecordNewData element is defined as follows: 5537

5538

5539

A changeRecordNewData MUST not be empty; it must contain a valid semantic piece of new 5540 data. Change records of this type provide new or updated business or modeling information 5541 that is to be incorporated. Partial updates to a datum are not provided for; rather, the entire 5542 new contents of the datum are to be provided, and these replace any existing definition of the 5543 datum with the recipient of the change record. 5544

The operationalInfo element MUST contain the operational information associated with the 5545 indicated new data. 5546

A changeRecordNewData is considered “successfully processed” once a node has received it, 5547 assigned a local USN to it, validated it, durably stored it in its change record journal, and then 5548 successfully incorporated it into the node’s data store. 5549


172/405

7.3.3 changeRecordHide 5550

The changeRecordHide element is defined as follows: 5551

5552

A changeRecordHide element corresponds to the behavior of hiding a tModel described in the 5553 delete_tModel in the Publish API section of this Specification. A tModel listed in a 5554 changeRecordHide should be marked as hidden, so that it is not returned in response to a 5555 find_tModel API call. 5556

7.3.4 changeRecordDelete 5557

The changeRecordDelete element is defined as follows: 5558

5559

A changeRecordDelete element indicates that an item defined in the UDDI registry is to no 5560 longer be used and expunged from the data stores in each of the nodes. The item to be 5561 deleted is indicated in the change record by the key of an appropriate entity type; this must 5562 contain the unique key of some businessEntity, businessService, bindingTemplate, or tModel 5563 that is presently defined. The changeRecordDelete element for deleting tModels corresponds 5564 to the administrative deletion of a tModel described in Section 6.1.3 Updates and Deletions of 5565 this specification. The changeRecordDelete for a tModel does not correspond to any API 5566 described in this specification and should only appear in the replication stream as the result of 5567 an administrative function to permanently remove a tModel. 5568

Permanent deletions of tModel information within the node may be made administratively. In 5569 this event, a UDDI Node may insert a delete operation into the replication stream. The 5570 publisher identifier for this operation is the account associated with the UDDI Node. Note that 5571 a permanent deletion of tModel information from the registry must have the prior approval of 5572 the other nodes participating within the registry. 5573


173/405

5574

7.3.5 changeRecordPublisherAssertion 5575

The changeRecordPublisherAssertion element describes the information that UDDI replication 5576 MUST convey in order to support the business-to-business relationship definition supported by 5577 UDDI. 5578

An implementation MUST be able to determine the Registry changes from the information 5579 transmitted within the replication stream. The fromBusinessCheck and toBusinessCheck 5580 elements are Boolean values that represent which side of the business relationship is being 5581 asserted. A changeRecordPublisherAssertion message may include one or both sides of the 5582 relationship. For example, if the fromBusinessCheck is present and set to “true” then the 5583 assertion represents the parent-side of a parent-child relationship. 5584

5585

A changeRecordPublisherAssertion element indicates that one or both sides of the business 5586 relationship are to be inserted. 5587

a. changeRecordPublisherAssertion with: 5588

<fromBusinessCheck>true</fromBusinessCheck> and 5589 <toBusinessCheck>true</toBusinessCheck> is used to indicate that both sides of the 5590 publisherAssertion (i.e., business relationship) are to be inserted. The two businessEntity 5591 elements that are referred to within the publisherAssertion MUST be in the custody of the 5592 node that originates the changeRecord. 5593

b. changeRecordPublisherAssertion with: 5594

<fromBusinessCheck>true</fromBusinessCheck> and 5595 <toBusinessCheck>false</toBusinessCheck> is used to indicate that the 5596 fromBusinessCheck side of the publisherAssertion (i.e., business relationship) is to be 5597 inserted. The businessEntity that is referred to in the fromBusinessCheck MUST be in the 5598 custody of the node that originates the changeRecord. 5599

c. changeRecordPublisherAssertion with: 5600

<fromBusinessCheck>false</fromBusinessCheck> and 5601 <toBusinessCheck>true</toBusinessCheck> is used to indicate that the toBusinessCheck 5602 side of the publisherAssertion (i.e., business relationship) is to be inserted. The 5603 businessEntity that is referred to in the toBusinessCheck MUST be in the custody of the 5604 node that originates the changeRecord. 5605

d. changeRecordPublisherAssertion with: 5606

<fromBusinessCheck>false</fromBusinessCheck> and 5607 <toBusinessCheck>false</toBusinessCheck> if this is received in the replication stream, 5608 such a changeRecord will not generate any change to the registry. The node SHOULD log 5609 any events such as this. 5610

5611

�� The fromBusinessCheck

and toBusinessCheck elements are Boolean values that represent which side of the business relationship is being inserted. A changeRecordPublisherAssertion message may reference one or both sides of the relationship.¶


174/405

7.3.6 changeRecordDeleteAssertion 5612

The changeRecordDeleteAssertion element is defined as follows: 5613

5614

5615

A changeRecordDeleteAssertion element indicates that one or both sides of the business 5616 relationship are to be deleted. 5617

a. changeRecordDeleteAssertion with: 5618

<fromBusinessCheck>true</fromBusinessCheck> and 5619 <toBusinessCheck>true</toBusinessCheck> is used to indicate that both sides of the 5620 publisherAssertion (i.e., business relationship) are to be deleted. The two businessEntity 5621 elements that are referred to within the publisherAssertion MUST be in the custody of the 5622 node that originates the changeRecord. 5623

b. changeRecordDeleteAssertion with: 5624

<fromBusinessCheck>true</fromBusinessCheck> and 5625 <toBusinessCheck>false</toBusinessCheck> is used to indicate that the 5626 fromBusinessCheck side of the publisherAssertion (i.e., business relationship) is to be 5627 deleted. The businessEntity that is referred to in the fromBusinessCheck MUST be in the 5628 custody of the node that originates the changeRecord. 5629

c. changeRecordDeleteAssertion with: 5630

<fromBusinessCheck>false</fromBusinessCheck> and 5631 <toBusinessCheck>true</toBusinessCheck> is used to indicate that the toBusinessCheck 5632 side of the publisherAssertion (i.e., business relationship) is to be deleted. The 5633 businessEntity that is referred to in the toBusinessCheck MUST be in the custody of the 5634 node that originates the changeRecord. 5635

d. changeRecordDeleteAssertion with: 5636

<fromBusinessCheck>false</fromBusinessCheck> and 5637 <toBusinessCheck>false</toBusinessCheck> if this is received in the replication stream, 5638 such a changeRecord will not generate any change to the registry. The node SHOULD log 5639 any events such as this. 5640

In the event that a businessEntity deleted with a delete_business API message references 5641 publisherAssertions, the node SHOULD NOT create corresponding changeRecords for the 5642 referenced publisherAssertions. Please refer to Section 7.2.6 Replication Processing for more 5643 discussion related to this. 5644

�� The fromBusinessCheck

and toBusinessCheck elements are Boolean values that represent which side of the business relationship is being deleted. A changeRecordDeleteAssertion message may reference one or both sides of the relationship.


175/405

5645

7.3.7 changeRecordAcknowledgment 5646

The changeRecordAcknowledgement element is defined as follows: 5647

5648

5649

5650

A node MUST originate a changeRecordAcknowledgement message when it receives and 5651 successfully processes a changeRecord that contains an acknowledgementRequested 5652 attribute set to true. The changeRecordAcknowledgement message contains the identification 5653 of the change that it is acknowledging. 5654

It is specifically required that all nodes receiving a changeRecord with an acknowledgement 5655 request MUST originate an acknowledgement for it, even the node that originated the 5656 changeRecord in the first place. 5657

7.3.8 changeRecordCorrection 5658

A changeRecordCorrection contains information that is the corrected version of a change 5659 record that was previously originated in error. The correction simply contains the whole 5660 changeRecord that should have been transmitted in the first place; the originating node and 5661 originating USN information therein can be used to locate the offending record in change 5662 record journals. 5663

5664

When a node receives a changeRecordCorrection, it processes it only by making annotations 5665 in its change record journal; the data store of the node is not otherwise updated with the 5666 corrected change29. Specifically, and simply put, if the original offending change is still present 5667 in the node’s change record journal, its entry SHOULD be merely annotated in such a way that 5668 if the change needs to be propagated to a replication partner that the correct contents of the 5669 change are transmitted instead of the original. The changeRecordCorrection may be 5670 considered successfully processed once this has been durably accomplished and the 5671 changeRecordCorrection itself durably recorded in the change record journal. 5672

7.3.9 changeRecordNewDataConditional 5673

From time to time, registries may find it useful to permit certain new data with certain particular 5674 keys to be introduced at possibly any of their nodes. For example, registries which choose to 5675 use the recommended keying scheme (see Section 4.4 About UddiKeys) for their keys face 5676 the issue that the tModel representing the definition of a new domainKey partition in the keying 5677 scheme may be published at any node, and thus possibly at more than one node 5678

29

The job of bringing data stores up to date should be addressed by a following change containing the now-current state of the data modified by the offending change.

�� , generally speaking,

�� that


176/405

simultaneously. Some means is therefore necessary to prevent the introduction at multiple 5679 nodes of different (and thus conflicting) data under the key in question. 5680

The changeRecordNewDataConditional element provides a means by which this can be 5681 accomplished. Such elements necessarily contain wholly new data, that is, data residing under 5682 a key that does not yet exist in the registry. The replication and processing of these records 5683 ensure that either (a) the new data contained therein is introduced throughout the registry 5684 without conflict with other such introductions, or (b) that a conflict is detected by all nodes in the 5685 registry and as a consequence all nodes deem the data not to be introduced. That is, race 5686 conditions are detected and resolved. 5687

It is a matter of registry policy which forms of data, if any, may be replicated within a given 5688 registry using the changeRecordNewDataConditional element. 5689

5690

Change records of type changeRecordNewDataConditional MUST be replicated in change 5691 records with an acknowledgementRequested attribute set to “true”. For this type of change 5692 record nodes that originate such change records MAY emit their own acknowledgment to their 5693 own request at any time after having originated it. 5694

If a Node A originates a change record a with payload of type 5695 changeRecordNewDataConditional, then, at the instant of origination (that is, at the instant at 5696 which the change record a is assigned its local USN by Node A), it MUST be the case at Node 5697 A that the following three rules all are adhered to: 5698

1. The new data is valid at Node A. That is, Node A would at this instant be willing to 5699 have the data published into the registry’s data set. Thus, the data in question must 5700 conform to all the specifications and policies applicable to it. In particular, for example, 5701 if the registry in question supports publisher assigned keys and the data is a tModel 5702 representing the introduction of a new domainKey, then the tModel MUST be 5703 categorized with the value “keyGenerator” from the uddi-org:types category system, 5704 must be trusted as legitimate according to the policy of the registry, and so on. 5705

2. The key k is not an existing key at Node A. That is, at Node A there does not exist 5706 a change record x with local USN less than that of the USN of the change record a 5707 where x contains a changeRecordNewData or changeRecordNewDataConditional 5708 payload using the key k in its datum, and there does not exist subsequent to x a 5709 change record z with payload changeRecordDelete or 5710 changeRecordNewDataConditional also containing the key k. 5711

3. No other node is known by Node A to have requested the key k first. That is, at 5712 Node A there does not exist a change record x with local USN less than that of the 5713 USN of the change record a where x contains a payload of type 5714 changeRecordNewDataConditional whose contained data also has key k and for 5715 which it has not been determined that x was involved in a race in the manner set forth 5716 below. 5717

7.3.9.1 Detection of collisions in conditional new data publication 5718

The description within this section uses domain key generator tModels as an example. The 5719 behavior described MUST be applied to any type of new data that is found to collide with data 5720 from other nodes within the registry. 5721

When two nodes have saved a domainKey key generator tModel with the same domainKey, a 5722 collision has occurred. Only one publisher can establish a domainKey domain at only one 5723 node. When multiple publishers attempt to establish ownership over a single key domain only 5724 one can be allowed to succeed to guarantee uniqueness of publisher assigned keys. 5725

�� s

�� with

�� uses the “uddi:” keying

scheme

�� domainKeyGenerator

�� in the recommended keying

scheme ��

��

keyGenerator


177/405

Suppose an arbitrary Node A originates a changeRecordNewDataConditional change record 5726 a. Let Node B be an arbitrary other node which also originates a 5727 changeRecordNewDataConditional change record (call it b) which contains a datum with 5728 same key as that of the datum in a. Let Node C be any arbitrary other node in the registry. Let 5729 the notation (x,Y) represent the acknowledgement by Node Y (in a 5730 changeRecordAcknowledgement originated by Node Y) of changeRecordNewDataConditional 5731 change record x, and let the notation x < y denote the fact that, at a certain node, the local 5732 USN of x is less than the local USN of y. 5733

Then, recalling the ordering principle of replication of change records mentioned in Section 5734 7.2.2 Change Records, all of the following facts must be true: 5735

5736

At Node A At Node B At Node C

Fact Reason Fact Reason Fact Reason

A1: a < b Rule(3) B1: b < a Rule(3) C1: a < (a,B) B2 + ordering principle

A2: b < (b,A) One can acknowledge only what one has seen

B2: a < (a,B) One can acknowledge only what one has seen

C2: a < (b,A) A3 + ordering principle

A3: a < (b,A) A1 + A2 B3: b < (a,B) B1 + B2 C3: b < (a,B) B3 + ordering principle

A4: a < (a,B) B2 + ordering principle

B4: b < (b,A) A2 + ordering principle

C4: b < (b,A) A2 + ordering principle

A5: b < (a,B) B3 + ordering principle

B5: a < (b,A) A3 + ordering principle

5737

Thus, at all nodes in the registry, both requests a and b come before both acknowledgements 5738 (a,B) and (b,A); that is, at all nodes, { a, b } < { (b,A), (a,B) }. 5739

Therefore, we can in a well-formed manner specify the following decision procedure: 5740

• If at any Node X (including at Node A), an acknowledgement (a,Y) is seen for all 5741 nodes Y other than Node A before any such b is seen, then Node X SHOULD 5742 conclude no such b in fact exists, that Node A now safely has published the key in 5743 question, and that the data contained in the changeRecordNewData inside of record a 5744 is successfully incorporated into the node’s data store. 5745

• Conversely, if record b is seen before all the acknowledgements from nodes other 5746 than Node A, then Node X SHOULD conclude that a race has occurred, that therefore 5747 neither Node A nor any node that it was racing with has published the key, and that 5748 the introduction of neither records a nor b into the replication stream had any enduring 5749 effect on the data of the registry (they were no-ops). 5750

Moreover, the relative orderings established above ensure that all nodes in the registry 5751 (including Node A) will reach the same conclusions in these matters. 5752

In typical uses of the changeRecordNewDataConditional functionality, these sorts of races 5753 only arise due to the end-user error of attempting to simultaneously establish new data (such 5754 as domainKey key generators) at more than one node. The outcome of such errors is that the 5755 new data is not introduced at all, and thus the user must try again. 5756


178/405

5757

7.4 Replication API Set 5758

UDDI Replication defines four APIs. The first two presented here are used to perform 5759 replication and issue notifications. The latter ancillary APIs provide support for other aspects of 5760 UDDI Replication. 5761

• get_changeRecords 5762

• notify_changeRecordsAvailable 5763

• do_ping 5764

• get_highWaterMarks 5765

7.4.1 get_changeRecords Message 5766

The get_changeRecords message is used to initiate the replication of change records from 5767 one node to another. The caller, who wishes to receive new change records, provides as part 5768 of the message a high water mark vector. This is used by the replication source node to 5769 determine what change records satisfy the caller’s request. 5770

7.4.1.1 Syntax 5771

5772

5773

5774


179/405

5775


• requestingNode: The requestingNode element provides the identity of the calling 5777 node. This is the unique key for the calling node and SHOULD be specified within the 5778 Replication Configuration Structure. 5779

• changesAlreadySeen: The changesAlreadySeen element, if present, indicates 5780 changes from each node that the requestor has successfully processed, and thus 5781 which should not be resent, if possible. 5782

• responseLimitCount or responseLimitVector: A caller MAY place an upper bound 5783 on the number of change records he wishes to receive in response to this message 5784 by either providing a integer responseLimitCount, or, using responseLimitVector, 5785 indicating for each node in the graph the first change originating there that he does not 5786 wish to be returned. 5787

More specifically, the recipient determines the particular change records that are returned by 5788 comparing the originating USNs in the caller’s high water mark vector with the originating 5789 USNs of each of the changes the recipient has seen from others or generated by itself. The 5790 recipient SHOULD only return change records that have originating USNs that are greater 5791 than those listed in the changesAlreadySeen highWaterMarkVector and less than the limit 5792 required by either the responseLimitCount or the responseLimitVector. 5793

In nodes that support pre-bundled replication responses, the recipient of the 5794 get_changeRecords message MAY return more change records than requested by the caller. 5795 In this scenario, the caller MUST also be prepared to deal with such redundant changes where 5796 a USN is less than the USN specified in the changesAlreadySeen highWaterMarkVector. 5797

The response to a get_changeRecords message is a changeRecords element. Under all 5798 circumstances, all change records returned therein by the message recipient MUST be 5799 returned sorted in increasing order according to the recipient’s local USN. 5800

7.4.1.3 Returns: 5801

A node will respond with the corresponding changeRecords. 5802

7.4.1.4 Caveats: 5803

Processing an inbound replication message may fail due to a server internal error. The 5804 common behavior for all error cases is to return an E_fatalError error code. Error reporting 5805 SHALL be that specified by Section 4.8 – Success and Error Reporting of this specification. 5806

�� ‘

�� ’


180/405

5807

7.4.2 notify_changeRecordsAvailable Message 5808

Nodes can inform other nodes that they have new change records available for consumption 5809 by replication by using this message. This provides a proactive means through which 5810 replication can be initiated, potentially reducing the latency of the dissemination of changes 5811 throughout the set of UDDI nodes. The notify_changeRecordsAvailable message is the 5812 predecessor to the get_changeRecords message. 5813

Each node MUST respond with the message defined within the Section 7.4.2.3 Returns when 5814 a valid notify_changeRecordsAvailable message is received. 5815

At an interval set by policy after the origination of new change records within its node, a node 5816 SHOULD send this message to each of the other nodes with which it is configured to 5817 communicate this message according to the currently configured communication graph. It 5818 SHOULD ignore any response (errors or otherwise) returned by such invocations. 5819

7.4.2.1 Syntax 5820

5821

5822

5823


• notifyingNode: The parameter to this message indicates that the notifyingNode has 5825 available the indicated set of changes for request via get_changeRecords. 5826

• changesAvailable: When sending the notify_changeRecordsAvailable message, a 5827 node shall provide a high water mark vector identifying what changes it knows to exist 5828 both locally and on other nodes with which it might have had communications. 5829 Typically, no communication graph restrictions are present for the 5830 notify_changeRecordsAvailable message. In the event that the sending node does 5831 not know the USN for a specific node within the CommunicationGraph, the 5832 changesAvailable element MAY contain a highWaterMark for that node with an 5833 unspecified nodeID element. 5834


181/405

5835

7.4.2.3 Returns 5836

A node MUST respond with a disposition report with the E_success error code when a valid 5837 notify_changeRecordsAvailable message is received. Success reporting SHALL be that 5838 specified by Section 4.8 – Success and Error Reporting of this specification. 5839

7.4.2.4 Caveats: 5840


7.4.3 do_ping Message 5844

This UDDI API message provides the means by which the current existence and replication 5845 readiness of a node may be obtained. 5846

7.4.3.1 Syntax 5847

5848

5849


None 5851

7.4.3.3 Returns 5852

The response to this message must contain the operatorNodeID element of the pinged node. 5853

5854

7.4.3.4 Caveats: 5855


�� ¶

<?xml version="1.0" encoding="UTF-8" ?>¶<Envelope xmlns="http://schemas.xmlsoaporg.org/soap/envelope/">¶<Body>¶<dispositionReport

xmlns="urn:uddi-org:api_v3" >¶

<result errno="0" >¶<errInfo

errCode=“E_success" />¶</result>¶

</dispositionReport>¶</Body>¶

</Envelope>¶¶��

‘��

’

�� ‘

�� ’


182/405

5859

7.4.4 get_highWaterMarks Message 5860

This UDDI API message provides a means to obtain a list of highWaterMark element 5861 containing the highest known USN for all nodes in the replication graph. 5862

7.4.4.1 Syntax 5863

5864

5865


None 5867

7.4.4.3 Returns 5868

A highWaterMarks element is returned that contains a list of highWaterMark elements listing 5869 the highest known USN for all nodes in the replication communication graph. See Section 5870 7.2.4 High Water Mark Vector for details. 5871

5872

If the highest originatingUSN for a specific node within the registry is not known, then the 5873 responding node MUST return a highWaterMark for that node with an originatingUSN of 0 5874 (zero). 5875

<highWaterMark> 5876 <nodeID>…</nodeID> 5877 <originatingUSN>0</originatingUSN> 5878 </highWaterMark> 5879

5880

7.4.4.4 Caveats: 5881


5885

�� ‘

�� ’


183/405

5886

7.5 Replication Configuration 5887

7.5.1 Replication Configuration Structure 5888

The replication of UDDI data within a registry SHOULD be governed by information maintained 5889 within a Replication Configuration Structure. This structure MAY be contained within a 5890 Replication Configuration File. The structure includes sufficient information to uniquely identify 5891 each node within the UDDI registry. If used, each node within the registry MUST specify at 5892 least one contact as described below. 5893

If used, UDDI nodes MUST manage any and all changes to the contents of the Replication 5894 Configuration Structure. 5895

The XML schema definition describing the replicationConfiguration element is shown below. 5896 The root element of an instance document of this XML schema must be a 5897 replicationConfiguration element as defined in the UDDI v3 replication schema30: 5898

5899

5900

5901

The Replication Configuration Structure contains a serial number which is increased by at least 5902 one each time the published configuration is updated or changed. For the convenience of 5903 users, the element timeOfConfigurationUpdate identifies the time of the last update. The 5904 formatting of the timeOfConfigurationUpdate element is described later in this specification. 5905 The registryContact identifies a party who maintains and updates the Replication Configuration 5906 Structure. 5907

The element, maximumTimeToGetChanges, allows for the specification of the maximum 5908 amount of time (in hours) that an individual node may wait to request changes. Nodes MUST 5909 perform a get_changeRecords replication message within the time frame defined by the value 5910

30

All schema definitions here are presented per the 2001 Recommendation of XML Schema. Note that the schema definitions in this present document should be considered as informative only; the normative schema definitions are found in an accompanying .XSD specification file.

�� V3


184/405

of the maximumTimeToGetChanges element defined within the Replication Configuration 5911 Structure. Thus, change data can always be propagated throughout the UDDI registry within a 5912 finite amount of time, while at the same time changes will often propagate quickly. Use of this 5913 element is determined by registry policy as detailed in Section 9.6.54 Replication Policies. 5914

The operator elements in a Replication Configuration Structure are a list of the nodes and 5915 established paths of communication between the nodes within a registry. The communication 5916 paths and general replication topology considerations are discussed later in this specification. 5917

The element, maximumTimeToSyncRegistry, allows for the specification of when (in hours) a 5918 change made at any single node in the Registry is expected to be visible at all nodes within the 5919 registry. The element, maximumTimeToGetChanges, allows for the specification of the 5920 maximum amount of time (in hours) that an individual node may wait to request changes. Use 5921 of this element is determined by registry policy as detailed in Section 9.6.54 Replication 5922 Policies. 5923

The dsig:Signature elements in a Replication Configuration Structure allow for signing of the 5924 document for assurance of its integrity using XML Digital Signature. 5925

7.5.2 Configuration of a UDDI Node – operator element 5926

Each current UDDI node within the Registry is identified with an operator element in the 5927 replicationConfiguration: 5928

5929

5930

The operatorNodeID contains a unique key that is used to uniquely identify this node 5931 throughout the UDDI registry. The value used MUST match the businessKey of the Node 5932 Business Entity as referenced in Section 6.2.2 Self-Registration of Node Business Entity. The 5933 contact or contacts listed provide information about humans who should be contacted in the 5934 face of administrative and technical situations of various sorts. . The dsig:KeyInfo elements are 5935 intended to contain the certificate details if the soapReplicationURL makes use of Secure 5936 Sockets Layer 3.0 with mutual authentication as described in Section 7.5.5 Security 5937 Configuration. 5938

�� datum

�� n

�� node


185/405

5939

7.5.3 Replication Communication Graph 5940

The Replication Configuration Structure provides a means by which the UDDI replication traffic 5941 can be controlled and administered. This is achieved with the use of a communicationGraph 5942 element: 5943

5944

5945

5946

The communicationGraph element begins by explicitly listing a unique ID for each node within 5947 the registry. This second listing of the unique IDs within the Replication Configuration 5948 Structure enables the separate control of communication with a node from the management of 5949 other aspects of the node’s configuration. 5950

Following the listing of nodes is the controlledMessage element that lists the set of messages 5951 over which this communication graph is intended to administer control of. If a message 5952 element local name is listed in the controlledMessage element, then such messages SHALL 5953 only be sent between nodes that are listed in the subsequent edges of the graph. In contrast, 5954 communication restrictions are not imposed on replication messages not identified in the 5955 controlledMessage element. 5956

The next element of the communication graph, the edge element, identifies the graph edges 5957 imposed for those nodes that are listed. All node ID’s listed in an edge MUST have been 5958 previously identified in the node element of the communication graph. 5959

Each edge in the graph is a directed edge. The message elements contain the local name of 5960 the Replication API message elements. They indicate that only messages of the type explicitly 5961 identified for a particular edge MAY be sent from the specified messageSender to the specified 5962 messageReceiver. Restricted two-way communication between nodes MUST, if desired, be 5963 identified as a pair of edges with opposing directionality. A given directed edge MAY be listed 5964 at most once: for each edge, the pairing (messageSender, messageReceiver) MUST be 5965 unique over the entire set of edges of the graph. 5966

For each directed edge, an ordered sequence of zero or more alternate, backup edges MAY 5967 be listed using the messageReceiverAlternate element. Should a communications failure 5968 prevent message communication over the indicated primary edge, the backup edges MAY be 5969 tried in order until communication succeeds. 5970


186/405

In the absence of a communicationGraph element from the Replication Configuration 5971 Structure, all nodes listed in the node element MAY send any and all messages to any other 5972 node of the registry. 5973

A non-normative example of the use of the CommunicationGraph can be found within 5974 Appendix J UDDI Replication Examples. 5975

7.5.4 SOAP Configuration 5976

In UDDI, node-to-node replication communication MUST be carried out by means of SOAP 5977 messages and responses. The soapReplicationURL element of the operator element indicates 5978 where such messages should be sent to communicate with a given node. Specifically, in order 5979 to carry out a message invocation of type X with a given node in the registry, a message is 5980 sent using HTTP POST, as described in Chapter 4, to the URL identified within the Replication 5981 Configuration Structure. 5982

7.5.5 Security Configuration 5983

Mutual authentication of UDDI nodes is RECOMMENDED. This MAY be achieved using 5984 mutual X.509v3 certificate-based authentication as described in the Secure Sockets Layer 5985 (SSL) 3.0 protocol. SSL 3.0 with mutual authentication is represented by the tModel uddi-5986 org:mutualAuthenticatedSSL3 as described within Section 11.3.2 Secure Sockets Layer 5987 Version 3 with Mutual Authentication. The certificate credentials that SHOULD be used for the 5988 mutual authentication SHOULD be included in the dsig:KeyInfo element(s) for each node 5989 Replication Configuration Structure. 5990

7.6 Error Detection and Processing 5991

While replication errors are expected to happen rarely, mechanisms must be in place to detect, 5992 deal with, and help manage the correction of such problems. 5993

Throughout this section we will consider a UDDI registry consisting of 4 nodes (A, B, C, and D) 5994 configured in a cyclic replication pattern such that D places get_changeRecords requests to C 5995 (D>C), C>B, B>A, A>D. In addition to each node’s primary replication edge a set of alternate 5996 edges have been defined for each node which, in case of difficulty, permits it to bypass each 5997 upstream node in turn (i.e. B has two secondary edges: B>D and B>C). For clarity, only one is 5998 depicted below in Figure 4. 5999

6000

Figure 4 - Alternate Edge Example 6001


187/405

6002

Asserting an invalid change record, it follows that: 6003

In all of the cases below we assume that the following steps are executed, in the order 6004 listed: 6005

1. A Publisher of data held in custody at Node D saves changes to that data 6006

2. Node D originates a change record x. 6007

3. Node A issues a get_changeRecords request to Node D and successfully 6008 processes the change record set containing x which D issued in response. 6009

4. Node B issues a get_changeRecords request to Node A and processes the 6010 change record set that Node A issued in response. During processing of the 6011 change record set Node B encounters x and is unable to validate it. 6012

When Node B is unable to validate x it is required to signal that it has encountered a 6013 change record that it considers invalid (see Section 7.7 Validation of Replicated Data for a 6014 precise definition of what it means for a change record to be ‘invalid’). It does this by 6015 communicating to all of the UDDI nodes. The communication must include the following: 6016

• The originating Node’s USN Value 6017

• The reporting Operator Node ID 6018

• The Originating Node ID 6019

• The Replication operation type being processed (i.e., 6020 changeRecordPayload_type) 6021

• The unique key of the datum being processed 6022

• The type of datum being processed (i.e., businessEntity, businessService, 6023 tModel, etc.) 6024

In addition Node B must refuse to accept x from Node A (i.e. it MUST NOT add x to its 6025 journal, MUST NOT process x into its registry, and MUST NOT update its high water mark 6026 vector to reflect processing of x) and MUST NOT consider x to be successfully processed. 6027 Recall that Node A is required to deliver records ordered by local USN and Node B is 6028 required to consume records in the order they are provided. As a consequence, Node B 6029 will for the moment be unable to accept any other new records from Node A. Note that 6030 Node B may have successfully processed other change records from the change record 6031 set it received from Node A. If those change records preceded x, then they are unaffected 6032 by the issues associated with x. 6033

This design avoids polluting Node B with data that it knows to be invalid, while preserving 6034 the important ordering guarantee of change propagation upon which other replication 6035 semantics rely. 6036

7.6.1 UDDI Registry Investigation and Correction 6037

Once Node B has asserted the existence of an invalid change record the UDDI nodes MUST 6038 take remedial action. The investigation of Node B's assertion regarding x MAY have a number 6039 of outcomes. Those are documented in the cases below. 6040

The following change records are used in these cases: 6041

• x: a changeRecordNewData message created by Node D that Node B asserts is 6042 invalid. 6043

• y: a changeRecordCorrection message created by Node D containing x’, a corrected 6044 payload for x. 6045


188/405

• z: a changeRecordNewData message created by Node D containing current payload 6046 for x. 6047

7.6.1.1 Case 1: Invalid record validation 6048

The UDDI nodes MAY determine that Node B’s assertion that x is invalid MAY be a result of 6049 overly aggressive checking and validation in Node B’s UDDI implementation. In this case: 6050

• Node B WILL BE REQUIRED to change its code, 6051

• Node B WILL continue to participate in replication cycles, retrying propagation of x 6052 from A to B in each cycle until the code changes are deployed and x is processed 6053 successfully. 6054

7.6.1.2 Case 2: Invalid interim representation 6055

The assertion by Node B that x is incorrect MAY reflect incorrect handling of x by interim Node 6056 A (recall that x is replicated first from node D to Node A, then from Node A to Node B). Note 6057 that the originating Node D contains a valid x. In these cases: 6058

• Node A WILL BE REQUIRED to change its code. 6059

• Node D WILL BE REQUIRED to generate y and z. 6060

• Node A WILL continue to participate in replication, processing y (annotating x in its 6061 journal to refer to x’ in y) and z in one or more change record sets from Node D, 6062

• Node B WILL continue to participate in replication in subsequent cycles. In each it 6063 WILL attempt to propagate x from Node A, then begin to exercise its alternate edges, 6064 descending one additional edge each cycle (i.e. in cycle (n+1) it WILL attempt to 6065 replicate using B>A and B>D). At some point node B MAY process a valid x from an 6066 alternate node, in these instances, Node B WILL later process y (annotating x to point 6067 to x’ in y) and z from Node A. If Node B has not processed a valid x from an alternate 6068 node prior to issuing a get_changeRecords to Node A which has processed y, then 6069 Node B WILL process x’, y (annotating x to point to x’ in y), and z from Node A. 6070

• Node C WILL continue replication and will receive x, y, and z from Node B. 6071

Expanded Description: 6072

Handling of the assertion that change record x delivered by Node A is invalid begins in 6073 replication cycle (n+0) with Node B communicating the details of the issue to all nodes within 6074 the UDDI registry, discarding x and all subsequent change records received from Node A, and 6075 halting its replication. 6076

During its next replication cycle (n+1) Node B WILL attempt to process a change record set 6077 from Node A. Assuming that Node A has not yet processed y produced by Node D, Node B 6078 WILL encounter an invalid x as the first record in the change record. In this case Node B WILL 6079 NOT issue a redundant message including the details of the issue to all nodes within the UDDI 6080 registry, however it WILL again discard x and all subsequent change records within the set 6081 issued by Node A. Node B WILL then use its first alternate replication edge (B>D) to 6082 circumvent Node A and will process a change record set containing x returned by Node D. 6083

In its next replication cycle (n+2) Node B WILL successfully process a change record returned 6084 by Node A. Since Node B’s high water mark vector entry for Node D has been updated to 6085 reflect its successful processing of x, Node A WILL NOT be asked to deliver x, and should it do 6086 so Node B WILL NOT attempt to process it (recall that a node responding to a 6087 get_changeRecords request MUST reply with at least the data requested, but MAY respond 6088 with more data than was requested by the caller). 6089

During an arbitrary replication cycle following Node B’s receipt of an invalid x from Node A, 6090 Node D WILL produce a changeRecordCorrection y containing a valid version x’ of x. Node A 6091


189/405

WILL process y annotating x within its journal to indicate that the payload in x is replaced by x’ 6092 in y. Note that although Node A’s journal now contains a valid x, Node A’s registry does not. 6093

Node B’s next get_changeRecords request to Node A WILL result in a change record set 6094 containing either x’ and y or only y. Change record x’ is delivered in instances where Node A 6095 processed y before Node B issued its (n+1) get_changeRecords request to A. 6096

Following production of y, Node D WILL produce z (which contains the now-current contents of 6097 the information manipulated by x). Change record z WILL be propagated normally through 6098 replication. 6099

7.6.1.3 Case 3: Invalid generation 6100

The assertion that x is invalid MAY be due to Node D having improperly generated x. In this 6101 case: 6102

• Node D WILL BE REQUIRED to change its code so that in future it generates correct 6103 change records, and to generate y and z. 6104

• Node A WILL BE REQUIRED to change its code so that in future it detects invalid 6105 change records such as x. 6106

• Node A WILL continue participating in replication, processing y (annotating x to point 6107 to x’ in y) and z. 6108

• Node B WILL continue participating in cycles, continuing to attempt propagation of x 6109 from Node A to Node B until it processes x’, y (annotating x to point to x’ in y), and z. 6110

• Node C WILL continue replication cycles, receiving x’, y (annotating x to point to x’ in 6111 y), and z. 6112

6113

Expanded Description: 6114

In this case handling of the assertion that record x delivered by Node A is invalid begins in 6115 replication cycle (n+0) with Node B communicating the details of the issue to all nodes within 6116 the UDDI registry, discarding x and all subsequent change records received from Node A, and 6117 halting its replication. 6118

During its next replication cycle (n+1) Node B WILL again process a change record set from 6119 Node A. It should encounter x as the first record in the change record set returned by Node A. 6120 If processing of x again yields an error, Node B WILL NOT issue a redundant message 6121 including the details of the issue to all nodes within the UDDI registry, it WILL discard x and all 6122 subsequent change records from Node A. Node B WILL then use its first alternate replication 6123 edge (B>D) to circumvent Node A and request change records from another node (D). In 6124 processing the change record set returned by Node D it WILL encounter an invalid x. It WILL 6125 then communicate the details of the issue to all nodes within the UDDI registry (pointing to 6126 Node D as the originating and the sending node), discard x and all subsequent change 6127 records received from Node D, and halt its replication. 6128

In its next replication cycle (n+2) Node B WILL again process a change record set from Node 6129 A. Should it again encounter an invalid x as the first record in the set it WILL discard x and all 6130 subsequent change records from Node A and proceed to its first alternate replication (B>D). 6131 Should processing a change record set from Node D again uncover an invalid x as the first 6132 record in the set from Node D, Node B WILL discard x and all subsequent change records 6133 from Node D and proceed to its second alternate replication edge (B>C) to circumvent nodes 6134 A and D. Since Node C has not received x the change record set is produces should be valid. 6135

During an arbitrary replication cycle following production of x, Node D WILL produce a 6136 changeRecordCorrection y containing the corrected version x’ of x. This new change record y 6137 propagates using the normal replication mechanism. Node A WILL process y, annotating x in 6138


190/405

its journal to now refer to x’ in y. At this point Node A’s journal is correct, however its registry 6139 still contains an invalid version of x. 6140

In a subsequent replication cycle, Nodes B and C WILL process x’ and y. Following production 6141 of y, Node D WILL produce z. In a subsequent replication cycle Nodes A, B, and C WILL 6142 process z. At this point all three nodes contain a valid representation of the data addressed by 6143 x. 6144


191/405

6145

7.7 Validation of Replicated Data 6146

UDDI nodes MUST enforce the validity of all the data entering their data store, both data they 6147 originate themselves, and data that they receive from other nodes through replication. A 6148 registry policy should define the level of validation that nodes enforce above and beyond 6149 validating that the data conforms to the UDDI schemas and does not cause corruption of the 6150 node data store. 6151

Specifically, it is required that a node fail to accept any publication API request which would, 6152 were it accepted, at that instant put its data store into an invalid state. Nodes must also support 6153 analogous enforcement through any user interfaces or other means by which the data in their 6154 data store may be added to or updated. 6155

Moreover, as a node receives replicated changeRecords from another node in response to a 6156 get_changeRecords request, it must consider the potential effect of the incorporation of the 6157 change into its data store. If the incorporation by the receiving node of such a change record 6158 (together, of course, with any preceding changes) would put its data store into an invalid state, 6159 then an error in one or more of the UDDI node implementations within the registry has been 6160 detected. In response, the receiving node must carry out the error detection processing 6161 sequence described in Section 7.6 Error Detection and Processing. 6162

Upon the receipt of changeRecords related to publisherAssertions that refer to businesses that 6163 have been previously deleted, or access point information that refers to invalid bindingKeys, or 6164 a tModelKey of a keyedReference that refers to a tModel that no longer exist, or any attempts 6165 to project a service that no longer exist at the node, or a reference in a isReplacedBy 6166 keyedReference to an invalid or missing businessEntity or tModel key, nodes MUST NOT 6167 raise replication errors. Nodes MUST include the respective changeRecords in a response to 6168 relevant get_changeRecord messages. 6169

Note as a point of implementation that it might often be useful to batch together several 6170 incoming change records under one validity check; this is a valid optimization since later 6171 change records cannot adversely affect the validity of earlier changes. However, should such 6172 an optimized validity check fail, an implementation must be prepared to back out of and fail to 6173 accept the entire set of candidate change records involved and then reconsider each 6174 individually in turn. 6175

As a checked value set reference may be validated or checked at an originating node within 6176 the registry, it need not be checked again at a node in the midst of processing a replication 6177 stream. If a checked value set reference is checked again during replication it SHOULD not 6178 generate a replication stream error. 6179

7.8 Adding a Node to a Registry Using Replication 6180

The following steps MAY be used to add a node to a registry that uses UDDI v3 replication. A 6181 registry policy may be defined for the addition of a node and the policy MAY define a different 6182 or more detailed process than the following process: 6183

1. Add the new node to the Replication Configuration Structure with the operatorStatus 6184 value set to “new”. If a communicationGraph is used in the registry’s replication 6185 Configuration Structure, one or more edges MUST be added so the new node may 6186 call the get_changeRecords API. 6187

2. Administrators of the existing nodes are notified of the update. They each retrieve and 6188 process the new information in the configuration file in order to add the new node as 6189 one of the parties with which their implementations are willing to authenticate and 6190 communicate. To verify the ability to communicate, each node pair within the current 6191 UDDI registry SHALL successfully exchange the do_ping message. 6192

�� V3


192/405

3. Once all existing nodes within the registry have verified the ability to successfully 6193 communicate with the new node, the configuration file is changed a second time to 6194 add appropriate edges to the communicationGraph in order to introduce the new node 6195 into the active replication graph. The messages allowed between the new node and 6196 its primary may be restricted to allow for startup processing. Replication then 6197 proceeds to provide change records to the new node which establish in it a current 6198 image of the registry. 6199

4. The new node MUST issue a get_changeRecords API call to an existing node and 6200 SHOULD process all available changeRecord elements. As nodes MAY limit the 6201 number of changeRecord elements in a response, processing all available 6202 changeRecord elements MAY require several get_changeRecords API calls. 6203

5. When the new node has completed processing of the change history and is ready to 6204 engage in all UDDI registry activities, the operatorStatus value, within the Replication 6205 Configuration Structure, WILL be updated from “new” to “normal” and any message 6206 restriction that may have been imposed earlier may be removed. The updated 6207 replicationConfiguration will be distributed to the nodes defined within the 6208 communicationGraph via replication. 6209

7.9 Removing a Node from a Registry Using Replication 6210

The following steps MAY be used to remove a node to a registry that uses UDDI v3 replication. 6211 A registry policy may be defined for the removal of a node and the policy MAY define a 6212 different or more detailed process than the following process 6213

1. At least one node in the registry MUST obtain all changeRecord elements 6214 representing the final state of the node that will be removed. 6215

2. The value of the operatorStatus element in the operator element in the Replication 6216 Configuration Structure of the node that is being removed MUST be changed from 6217 “normal” to “resigned.” In addition any edge elements that include the node that is 6218 being removed MUST be removed from the communicationGraph element. The 6219 operator element for the removed node remains in the Replication Configuration 6220 Structure so other nodes in the registry accept the changeRecord elements from the 6221 removed node. 6222

3. Depending on registry policy, the custody of the UDDI data from the removed node 6223 MAY subsequently be changed to one or more nodes in the registry. 6224

�� V3


193/405

6225

8 Publishing Across Multiple Registries 6226

In prior versions of the UDDI Specification, the behavior in which a publisher wished to copy 6227 the entirety of a UDDI registry entity from one registry to another while preserving the identical 6228 key was explicitly not allowed. The Version 1 and 2 specifications mandated that only the 6229 UDDI node could generate keys. A publisher could not pre-assign the key of a UDDI entity. 6230 With this stipulation in place, a publisher could not import or export data between registries. 6231 The rationale behind this mandate was to insure that no duplicate keys would ever be 6232 generated in a given registry because only nodes within that registry had the authority to 6233 generate keys. Consequently data sharing between registries in Version 1 and 2 of UDDI was 6234 functionally not allowed. 6235

Version 3 of UDDI approaches the issue of key generation in a significantly different fashion 6236 and, as such, the possibility of publishing an entity to another UDDI registry while preserving 6237 the key is allowed. This behavior is known as entity promotion. With this version of UDDI, a 6238 publisher is permitted to propose a new key for an entity, and, given the policies of a registry, 6239 that key and the entity associated with that key may be inserted into the registry. Thus, the 6240 possibility of sharing data among UDDI registries is a reality and, with this new functionality, 6241 UDDI’s scope in terms of a more broadly distributed environment is made manifest. 6242

At its core, registry-to-registry data sharing, or the publishing of data across multiple registries, 6243 involves the sharing of data between two UDDI registries. With such a notion, individual UDDI 6244 registries can be connected in complex ways. In fact, for a given registry, a publisher may 6245 have the authority to add many entities to a registry and, as such, a publisher could potentially 6246 publish the entirety of a registry’s contents into another registry, effectively mirroring the data. 6247 Or, the publisher might be interested in only a subset of data from another registry and only 6248 copy a portion of that data. When considering the implications of entity promotion, it is 6249 important to conceive of a publisher in a broader context, which makes possible a number of 6250 interesting scenarios. 6251

The most important aspect to consider in terms of data that has been published across 6252 multiple registries is that no a priori assumptions can be made about the nature of a 6253 relationship between the data in two registries and, by implication, no assumption can be 6254 made about the relationship between an entity that happens to exist in two (or more) registries. 6255 The data associated with a given key is by default scoped to a single registry and not to 6256 multiple registries. Consequently, inter-registry publication is quite different than inter-node 6257 behavior, i.e., the behavior of replication of nodes within a single registry. In replication, there 6258 is a normative model for the nodes that participate in a replication topology and the for data 6259 management of those nodes. However, a normative model for inter-registry publication does 6260 not exist and therefore cannot be assumed. The nature of interaction between two given 6261 registries is not mandated by the UDDI specification. The trust models and data management 6262 procedures between two registries are a matter of policy established by the two registries and 6263 are defined as non-normative behavior in terms of the UDDI v3 specification. In this way, inter-6264 registry interaction differs significantly from inter-node replication. 6265

While normative inter-registry behavior is outside the scope of the specification, an explanation 6266 of exactly how the specification enables the ability to share data between registries is in order. 6267 The focus of this chapter is to outline further the rationale for inter-registry communication, to 6268

�� 31


194/405

introduce the different kinds of inter-registry communication, and to provide guidance when 6269 considering engaging in inter-registry publication. 6270

8.1 Relationships between Registries 6271

8.1.1 Root Registries and Affiliate Registries 6272

For this new capability to be useful, care must be taken to avoid key collision between 6273 registries. The recommended way to prevent such collision is to establish a root registry, a 6274 registry that acts as the authority for key spaces. A root registry serves to delegate key 6275 partitions such that other registries can rely upon the root registry for verification and validation 6276 of a given key partition. All other registries that interact with the root registry are called affiliate 6277 registries. Affiliate registries rely on the root registry to delegate key partitions and insure that 6278 uniqueness across key partitions is maintained. By relying on a common root registry as an 6279 arbitrator of key spaces, affiliate registries can share data with both the root registry and 6280 among one another with the knowledge that a given partition is unique. Note that it is still the 6281 responsibility of each registry, both a root registry and its affiliates, to insure the data integrity 6282 and uniqueness of the keys within its custody. 6283

An important example of a root registry is the UDDI Business Registry, which has a set of 6284 policies in place to generate unique uuidKeys as well as to validate domainKeys through 6285 signatures that correlate with DNS records. These policies insure the uniqueness of both 6286 domainKeys and uuidKeys within the UDDI Business Registry, and thus the UBR serves as a 6287 reasonable root registry for many purposes. In fact, establishing alternate root registries is not 6288 recommended, as this would ultimately defeat the goal of publishers being able to share data 6289 between multiple registries with an assurance of avoiding a key collision. By acknowledging 6290 the UDDI Business Registry as a root, an affiliate registry can establish inter-registry 6291 communication policies and procedures with both the UDDI Business Registry and any other 6292 registry which is an affiliate of the UDDI Business Registry. 6293

8.1.2 A Closer Look at Inter-Registry Communication Models 6294

Before looking at the operational details of sharing data between registries, a look at some of 6295 the permutations of inter-registry communication is in order. Using a Venn diagram to 6296 represent the cross publication models between three registries sheds some light on 6297 permutations of data sharing. Note that the diagram below does not represent the directional 6298 flow with regard to how exactly how the data might move between registries. However, the 6299 diagram does provide a conceptual framework to begin thinking about how the data in multiple 6300 registries might be related. 6301

In the Venn diagram below, the circle (1) represents the UDDI Business Registry, a root 6302 registry, while the two other circles represent registry A and registry B, two affiliate registries 6303

6304


195/405

6305

6306

6307

Consider Scenario (1), in which the three registries contain data that exist independent of the 6308 other registries. There are certainly scenarios that exist in which data would not be of value or 6309 interest to another registry, and thus would exist in one and only one registry. In this case, it 6310 may appear that there are not concerns about possible key collision with another registry. 6311

However, it is critical to realize that, registry policy aside, nothing prevents a user of a registry 6312 from promoting entities from one registry to another registry. Put another way, no registry is an 6313 island. A user with read authority in one registry and publish authority in some other registry 6314 can retrieve entities from the first and publish them in the second. And, once that data has 6315 been promoted, nothing prevents the publisher from altering the data in the original registry. 6316 This concern is mitigated with the advent of digital signature support. A signed UDDI entity can 6317 be copied across multiple registries and the publisher can verify that the original content has 6318 not been modified. 6319

It is important for both nodes and clients to remember that a registry typically does not control 6320 the data outside of itself. A client of a given registry must be aware that different registries 6321 might contain identical keys with different data. In some scenarios, this is the desired 6322


196/405

behavior, but there are also cases where such behavior could be construed as malicious. As 6323 such, clients need to be cognizant of the policies and procedures of registries they interact 6324 with. 6325

In Scenario (2), Affiliate A and Affiliate B each have data that exists in both an affiliate registry 6326 and the UDDI Business Registry. This could have occurred in several different ways. A 6327 publisher in Affiliate A may have subscribed to a certain set of entities in the root registry, 6328 publishing them in itself on an ongoing basis as changes are received. Or, a publisher in 6329 Affiliate A may have generated a set of entities in its local registry and then published them to 6330 the UBR. Such data exchange is potentially a two-way process: the data may originate in the 6331 root and end up in Affiliate A, or it may originate in Affiliate A and end up in the root. 6332

In Scenario (3), the two affiliates share data. Again, this sharing has several permutations. 6333 Publishers in Affiliate A and B may have an explicit agreement to subscribe to one another’s 6334 data, or a publisher of one of the registries may have simply copied a set of data from another 6335 registry, unbeknownst to that registry, and published the data to its registry. 6336

Scenario (4) brings the interaction among these three registries to a zenith: there is the case 6337 where all three registries share a common set of data, such as key generator tModels. Again, 6338 the circumstances and mechanisms through which such a common dataset is established are 6339 manifold. 6340

Given the above exercise, it is critical both for nodes of registries and for clients of registries to 6341 understand the different ways in which inter-registry communication can occur. In particular, 6342 understanding how the establishment of key generators within different registries regulates the 6343 process of inter-registry publication is paramount. 6344

8.2 Data Management Policies and Procedures Across 6345

Registries 6346

8.2.1 Establishing a Relationship with a Root Registry 6347

If a registry intends to allow the users of that registry to copy entities into other registries, some 6348 considerations need to be taken when that registry goes online, before it generates a single 6349 key. This is crucial because if the registry begins to generate keys before establishing a key 6350 generator with a root registry, the registry may not be able to become an affiliate later on. 6351

To bring up each node in a registry affiliated with a root registry, the node should begin by 6352 publishing a new key generator tModel of type keyGenerator32 in the root UDDI registry. The 6353 node should then save this tModel in itself exactly as it has been saved in the root registry. 6354 This tModel then becomes the key generator tModel for the new node. Owning the imported 6355 tModel gives the new node the capability it needs to generate new keys that are guaranteed to 6356 be unique within the root registry by deriving them from its key generator. 6357

During normal operation, nodes need to generate keys – i.e., while saving new entities for 6358 which keys have not been proposed by their publisher. They do this by deriving them from key 6359 generators they own. Nodes may choose any algorithm they wish to generate the key-specific 6360 string33 that makes each of the derived keys unique. Each node is responsible for managing 6361 the uniqueness of the keys it generates for itself. One way to do this is to use UUIDs for the 6362 extensions it generates. Another is to use sequential integers. 6363

Once a key generator is established with the root registry, the affiliate registry can begin safely 6364 generating keys that are unique in the context of the root registry and unique in any registries 6365

32

See section 5.3.18.3.1 Domain Key Generator tModels

33 See section 5.3.2 Publishing Entities With Publisher Assigned Keys

�� keyGenerator

�� keyGenerator

�� keyGenerator

�� keyGenerators

�� keyGenerator


197/405

that share an affiliation with the root registry and have followed the recommended keying 6366 policy. 6367

For example, imagine Registry X is established by a company as an affiliate of the UDDI 6368 Business Registry. The following steps would occur: 6369

1. To begin Registry X would publish a tModel of type keyGenerator in one of the UBR 6370 nodes. The tModel might be as follows: uddi:AC104DCC-D623-452F-88A7-6371 F8ACD94D9B2B:keygenerator. Note that this example uses a uuidKey for its key 6372 partition. It could have used a domainKey as well. 6373

2. Then, Registry X would save that tModel into its own registry. 6374

3. Additionally, Registry X would establish that all entities saved to Registry X that need 6375 a new key generated would be programmatically derived from uddi:AC104DCC-6376 D623-452F-88A7-F8ACD94D9B2B:keygenerator. For example, Registry X might use 6377 sequential numbering to perform this task, so that the first businessEntity saved into 6378 node x would get key uddi:AC104DCC-D623-452F-88A7-F8ACD94D9B2B:1, the 2nd 6379 would get the key uddi:AC104DCC-D623-452F-88A7-F8ACD94D9B2B:2 and so on. 6380

A consequence of the way key generation works is that if a registry exports a key generator 6381 tModel from some other registry and assigns it to a publisher, that publisher may use that 6382 tModel to generate keys in that registry. In other words, the procedure outlined above can be 6383 used between affiliate registries as well. 6384

Note: If a registry has started generating keys without first becoming an affiliate of a root 6385 registry and its publishers still wish to share data with another registry, the registry would need 6386 to become an affiliate and then re-key its data with keys derived from the registry’s key 6387 generator. In the case where the registry has begun generating keys as a v1 or v2 registry, the 6388 keys will need special consideration34. 6389

8.2.2 Data Sharing 6390

The actual operation of sharing data between registries is accomplished using the existing API 6391 sets. The Inquiry API and/or the Subscription API are used to get data from a registry; the 6392 Publish API is used to promote entities into a registry. A new set of terms is introduced to help 6393 clarify the behavior: 6394

A source registry is a registry with data to share. 6395

A target registry is a registry that will consume data. 6396

An importer is a publisher who reads data via the Inquiry or Subscription API from one or more 6397 source registries and publishes it to a target registry. Likely, importers are software applications 6398 that use the UDDI APIs to achieve this multi-step process. 6399

8.2.2.1 Sharing Data 6400

Importers copy entities from one or more source registries and publish them, potentially with 6401 modification35, in a target registry. Given its description, every importer is a publisher in its 6402 target registry and an inquirer in its source registries. Importers can read their source registries 6403 by subscribing to them or by simply issuing find_xx and get_xx Inquiry APIs calls. 6404

For an importer to do its work it must own the requisite key generator tModels in the target 6405 registry, and the target registry must have a policy that allows publisher-assigned keys. In this 6406

34

See Chapter 10 Multi-Version Support

35 Signed entities may not be modified without breaking the signature

�� keyGenerator

�� keyGenerator

�� keyGenerator


198/405

way, the importer can preserve the keys of the entities it reads from the source registry and 6407 publishes to the target registry. 6408

An important case for which this is particularly simple is the one in which the importer is a part 6409 of the operation of an affiliate, the source registry is that affiliate, the target is the root, and the 6410 data to be imported has keys based on the affiliate’s key generator. Since the affiliate already 6411 owns the requisite key generator in the target, and the root, by definition, accepts publisher-6412 assigned keys, the required conditions are met. This scenario is visually represented by case 6413 2 in the diagram above. 6414

Another important but simple case is one in which the source registry is the root, the target is 6415 an affiliate, and the importer is a part of the operation of the target registry. Since the target is 6416 the importer, it is granted the authority to publish root key generators and entities with uuid 6417 keys. With these permissions, the importer can import any entities from the root that the 6418 target’s policy dictates. Because the importer is still bound by the rules for key generation – in 6419 particular because it is not permitted to generate keys in a partition for which it does not own 6420 the key generator – the importer cannot cause key conflict. This scenario is also visually 6421 represented by case 2 in the diagram above; but with the reverse data flow. 6422

In the case where both the source and the target are affiliates, the process may not be as 6423 simple. First, the target registry must have a policy that allows it to accept publisher-assigned 6424 keys. Assuming this is the case, the importer must own the necessary key generator tModels 6425 in the target registry. The recommended way for the importer to obtain the required ownership 6426 is to have the target registry import key generators from the root registry and then transfer 6427 ownership of them to the importer. In other words, out-of-band communication is required that 6428 cannot be conducted simply by a save_tModel call from the importer. The out-of-band 6429 communication is important because it provides the target registry with an opportunity to verify 6430 that the importer should be allowed to be the proxy in the target for whoever owns the key 6431 generator in the root. 6432

Consider an example. An importer wants to copy data from Registry K to Registry J, both of 6433 which are affiliates of the UDDI Business Registry. The importer must get Registry J to grant it 6434 the authority to be a publisher and must get Registry J to give it ownership of the key 6435 generator(s) it needs to publish the entities it wishes to import from Registry K. If Registry J 6436 trusts the importer, it grants the importer publishing authority, imports the key generator 6437 tModels requested by the importer from the root, and transfers ownership of them from itself to 6438 the importer. Typically, the key generators the importer needs include the key generator(s) 6439 used by Registry K when it generates keys. 6440

Phrased differently, target registries should establish a trust relationship with those it grants 6441 ownership of the key generators it imports. By granting a publisher ownership of an imported 6442 key generator, the target registry is granting the publisher the authority to be the representative 6443 in the target registry of whoever owns the key generator in the root. 6444

�� keyGenerator

�� keyGenerator

�� rootKeyGenerators

�� uuidKeys

�� keyGenerator

�� keyGenerator


�� keyGenerator

�� keyGenerator

�� keyGenerator


�� keyGenerator


�� keyGenerator

�� keyGenerator


199/405

6445

9 Policy 6446

Policies within UDDI are statements of required and expected behavior. Within the UDDI 6447 architecture there are registries which are composed of one or more nodes. The registry 6448 defines the domain of the policy for the nodes that make it up and may delegate the definition 6449 of a particular policy to one or more of the nodes within its domain. Within policy then, there is 6450 a hierarchical relationship between registry policies and node policies including whether a 6451 registry allows nodes to specify polices. Registries MUST also identify the Policy Decision 6452 Points. Policy Enforcement Points are responsible for enforcing the policies and these MAY be 6453 the same as the Policy Decision Point. 6454

Registries may also affiliate. Affiliated registries are sets of registries that share compatible 6455 policies for assigning keys and managing data. (See Section 1.5.5.Affiliations of Registries) 6456

9.1 Definitions 6457

See Appendix L Glossary of Terms for definitions of terms appearing in bold. Many of these 6458 are derived from general terms in RFC 3198, the IETF glossary for policy. See 6459 http://ietf.org/rfc/rfc3198.txt. 6460

9.2 Policy 6461

This specification defines policy abstractions. Registries MUST define a policy rule for each 6462 of the policy abstractions. Each policy rule is decided by a Policy Decision Point (PDP). For 6463 some policy abstractions the PDP MUST be the registry. Part of each policy rule is to 6464 designate the Policy Enforcement Points (PEP) that is responsible for enforcing the policy. 6465 The PEP MAY be the same component as the Policy Decision Point. 6466

The combination of policies and implementation for a UDDI registry should form an explicit 6467 security model that is available for evaluation in a risk assessment. It is recommended that 6468 implementers of UDDI nodes and registries and users of those registries obtain or perform a 6469 risk assessment of the implementation. 6470

In the following Section 9.4 UDDI Registry Policy Abstractions, the registry policy abstractions 6471 are defined in a narrative form. Other policies MAY be delegated to the node and these are 6472 defined in Section 9.5 UDDI Node Policy Abstractions. At the end of the document is a 6473 summary table which captures the abstractions in a way that cross references to the narrative 6474 text and includes some additional information. 6475

A registry MAY specify additional policy abstractions and rules. A registry MAY also allow 6476 nodes in the registry to specify additional policy abstractions and rules. Representation of the 6477 policy rules corresponding to policy abstractions in this chapter and any additional policy 6478 abstractions SHOULD be communicated as described in the following section. 6479

9.3 Representation of Policy 6480

There are two types of polices defined in the following sections. There are policies that can be 6481 communicated through representation in an XML document and there are policies that can be 6482 modeled within UDDI through the use of UDDI elements. Section 9.7 UDDI Policy Summary 6483 recommends a method (document or model) for conveying each policy. 6484

If a policy abstraction can be modeled, Section 9.4 and Section 9.5 describe how this MAY be 6485 done. Policies that impact the configuration of UDDI clients SHOULD be modeled in the UDDI 6486 data structures. 6487


200/405

Policies communicated through an XML document SHOULD include the name of the policy 6488 abstraction from this section, a description of the policy rule and a declaration of the policy 6489 decision point and the policy enforcement point. An XML Schema for creating this document 6490 has been created in the namespace urn:uddi-org:policy_v3 and is described below in Section 6491 9.3.1 Policy Schema. 6492

When documenting policies, there is a hierarchy in the way policies are defined. A registry 6493 defines the broad registry policy abstractions, one of which is whether or not a policy may be 6494 defined by the individual nodes within the registry. If a registry allows nodes to specify policies 6495 it is said to be “delegating” the policy expression to the node. 6496

If policies are “delegated” to nodes to specify, the node may specify the abstraction or it may 6497 specify policy rules. 6498

The picture below illustrates the relationship between a registry and its nodes. The registry as 6499 the Policy Decision Point for the registry and its nodes defines its policy abstractions and rules. 6500

If the registry allows delegation, the nodes may also define policy abstractions and rules, but 6501 these must be consistent with the policies inherited from the registry. 6502

6503

6504


201/405

9.3.1 Policy Schema 6505

The policies element illustrated below represents all of the policies as a sequence of policy 6506 elements. Each policy element in the sequence represents one policy listed in the policy 6507 abstractions that are applicable to the UDDI API set. In the policy document instance 6508 referenced by the policy service, there should be one instance of a policy element for each 6509 policy that applies to all API sets provided by the node. The policies element MAY also 6510 contain an XML Signature using the dsig:Signature element. Signing a policy document is 6511 described in Appendix I. 6512

6513

A policy element represents one individual policy. It contains the name of the policy abstraction 6514 in the policyName element, a string describing where the policy is decided in the 6515 policyDecisionPoint element and the actual description of the policy in one or more languages 6516 in the sequence of policyDescription elements. 6517

6518

The policyName element contains the policy name defined in the policy abstractions below in 6519 Section 9.4 and 9.5. 6520

The policyDescription element contains a description of the effect of the policy implementation. 6521 This element can be adorned with the xml:lang attribute and can appear multiple times to allow 6522 for translations of the policy description. 6523

The policyDecisionPoint element contains a string describing where the policy is decided. 6524 Typically, this value will be either the string “node” or “registry”. Use of an alternative policy 6525 decision point should be described in this element. 6526

9.3.2 Policy Documents 6527

An instance of the policy document should be a Web accessible document and the URL for 6528 retrieving this document should be included in the overviewDoc element in the instanceDetails 6529 element of a tModelInstanceInfo element referencing a UDDI API set tModel. The contents of 6530 the elements in the policy document are intended to be human readable. 6531


202/405

Appendix K contains an example of an instance of a policy document and the corresponding 6532 Node Business Entity element for the implementation of a UDDI API set. The instance of the 6533 policy document that is associated with each API set SHOULD include all policies of the 6534 registry and of the node that are applicable to the API set. 6535

It is RECOMMENDED that the instance of the policy XML Document(s) conform to the XML 6536 Schema for policy in the namespace urn:uddi-org:policy_v3. A policy document SHOULD be 6537 provided for each UDDI API set binding and the location of the policy document SHOULD be 6538 an HTTP GET accessible document with the URL identified in the overviewURL element of the 6539 overviewDoc in the instanceDetails element of a tModelInstanceInfo element referencing a 6540 UDDI API set tModel. 6541

In the event that another form of policy documentation format or standard for policy declaration 6542 captures a policy decision or decisions in a manner more appropriate to the particular node 6543 and registry, it is recommended that this standard be registered as a tModel with the 6544 overviewURL identifying the documentation for the document format. Registering a tModel 6545 allows different policy document formats and standards to be used by a particular 6546 implementation of a UDDI node or registry. The actual instance of the policy document 6547 SHOULD be provided for each UDDI API set binding where the policies will be enforced. In the 6548 bindingTemplate element, the location of the policy document SHOULD be an HTTP GET 6549 accessible document with the URL identified in the overviewURL element. 6550

9.3.3 Policy Service within UDDI 6551

By using the UDDI model for defining Web services it is possible to define a policy service 6552 which supplies the documented policies of the registry and node. 6553

It is RECOMMENDED that a UDDI node provide a separate businessService of the Node 6554 Business Entity that represents the general policy service. This businessService MUST have 6555 one bindingTemplate that references the uddi-org:v3_policy tModel described in Section 6556 11.5.3 UDDI Policy Description Specification. This policy service is described below in Section 6557 9.3.3 Policy Service within UDDI. 6558

9.3.4 Policy Modeling 6559

Policy decisions that can impact the configuration of a UDDI client SHOULD be represented in 6560 UDDI data structures for discovery by UDDI clients. The modeling of policy makes use of the 6561 data structures of UDDI by representing policy concepts as tModels. Use of the concept by an 6562 implementation of a UDDI API set is reflected by including the tModel in the bindingTemplate 6563 for the UDDI API set. Options within a concept are represented as instance parameters in the 6564 instanceParms element. Instance parameter values that are related to options described in 6565 the UDDI Version 3.0 Specification are included in the UDDI Version 3.0 Policy Instance 6566 Parameters schema which is in the namespace, urn:uddi-org:policy_v3_instanceParms 6567

Support of an API set, described in Chapter 5, by a node as part of this procedure MUST be 6568 represented in a bindingTemplate in each Node Business Entity that supports it. 6569

As multiple policy instance parameter elements need to be reflected in the instanceParms 6570 element, the container element, UDDIInstanceParmsContainer, MUST be used to wrap other 6571 elements as defined in the Policy Instance Parameters schema. 6572

It is important to note that XML in instanceParms MUST be encoded as described in Section 6573 3.5.2.4 instanceDetails. 6574

See Appendix K Modeling UDDI within UDDI - A Sample for examples. 6575

9.4 UDDI Registry Policy Abstractions 6576

This section includes the highest level of policy abstractions, the registry policy abstractions. 6577 Since registries may be composed of nodes, the next level of abstraction is the node 6578

�� web



203/405

abstraction which is described in Section 9.5 Node Policy Abstractions. In some cases there 6579 are UDDI policies that are “recommended”. These are documented in Section 9.5.16 UDDI 6580 Recommended Registry Policies. 6581

9.4.1 Registry Policy Delegation 6582

A registry MUST specify whether or not it supports delegation of policies to the nodes within it. 6583 The definition of policies that a registry identifies MAY be delegated to a node to specify a 6584 node-specific policy. This is indicated in the summary table as “may be delegated”. 6585

9.4.2 Registry General Keying Policy 6586

UDDI Version 3 introduces the ability for publishers to generate entity keys. This feature 6587 preserves the requirement for distinct keys while enabling keys to be created in a safe, efficient 6588 manner. 6589

A registry MUST have a policy on key format and key generation. The registry MUST have a 6590 policy on data integrity or how the keyspace is protected from unauthorized modification. 6591

Registries MAY use whatever keying policies they wish subject only to the constraints that 6592 keys MUST be URIs, and the registry MUST have policies that prevent key collisions. 6593

9.4.3 UDDI keying scheme 6594

This specification presents a keying scheme (in Section 9.54.4 About uddiKeys ) that all 6595 registries MUST use. Policy decisions MUST be defined for the following policy abstractions. 6596

9.4.3.1 Registry Key Generation for Nodes 6597

Registries MUST establish policies for deciding whether a given node is permitted to publish a 6598 given key generator tModel. Section 4.4 About uddiKeys contains details on key generation. 6599 See Section 5.2 Publication API Set for details on publish APIs. 6600

9.4.3.2 Registry Key Generation for Publishers 6601

Registries MUST establish policies for deciding whether publishers are permitted to publish 6602 key generator tModels. Section 4.4 About uddiKeys contains details on key generation. See 6603 Section 5.2 Publication API Set for details on publish APIs. 6604

Also, registries MUST establish policies for the criteria by which a given publisher is allowed to 6605 register a given key generator tModel. Chapter 5 UDDI Programmers APIs also contains 6606 details on key generator tModels and this section should be reviewed before creating the key 6607 generation policy. 6608

9.4.3.3 Registry Key Default 6609

The registry MUST specify what the policy is when a key is not supplied on an API, but MAY 6610 delegate the generation of default keying to its nodes. 6611

9.4.3.4 Registry Support of uuidKeys 6612

Another policy decision is whether nodes will accept a key generator tModel that is NOT a 6613 domainKey, but is a uuidKey. 6614

9.4.3.5 Root Key Generation 6615

In order for an affiliation to be established among UDDI registries, the registries involved 6616 MUST have compatible policies regarding key generation. The keying scheme facilitates this 6617 by designating one of registries in the affiliation as “the root registry”. The root UDDI registry 6618 serves as the naming authority by assigning first-order or “root” partitions of the space of keys 6619

��

�� recommended

�� recommended

�� SHOULD

�� The

�� are REQUIRED when

using the recommended scheme��

following the recommended keying scheme ��

keyGenerator��

following the recommended keying scheme ��

keyGenerator��

Registries following the recommended keying scheme also

�� keyGenerator

�� using the recommended

keying scheme��

recommended ��

achieves


204/405

to registries and others who need to generate keys. All registries that participate in that 6620 affiliation look to the root registry as the source on which to establish the uniqueness of a given 6621 set of keys. An example of a root registry is the UDDI Business Registry. See Section below 6622 on UBR policies to see the details of the UBR Root Key Generation Policy. 6623

9.4.4 UDDI Information Access Control Policy 6624

The goal of a UDDI registry is to be a useful, reliable registry of business services. To achieve 6625 this purpose each registry must establish the policies needed to appropriately protect the 6626 information in its possession. The policies that a registry defines to protect business 6627 information is its information management policy. 6628

UDDI nodes that maintain custody of UDDI information and implement a data storage 6629 mechanism are responsible for the Data Model of the underlying storage of the data elements 6630 and its mapping to the Information Model. 6631

The mapping to the information model is represented by the implementation of the API sets 6632 defined in this specification. This information model MAY be extended as described in 6633 Appendix H Extensibility. When an extension to the information model is used, it MUST be 6634 represented by a different tModel as described in Appendix H and the extension MAY have a 6635 significant impact on interpretation of the information and the policies of the registry. Use of an 6636 extension MAY be prohibited by a registry, and if allowed, it is STRONGLY RECOMMENDED 6637 that an impact of an extension on the information model of UDDI is assessed by both 6638 operators and users of the registry. 6639

9.4.5 Adding nodes to a registry 6640

A registry MUST specify how nodes are added to and deleted from the registry. If a registry 6641 supports the removal of nodes, then it MUST specify how the node custody will be transferred 6642 and how the data migration will occur. 6643

If a registry uses configuration information for tracking the nodes of the registry, then it must 6644 state how this configuration information is protected from unauthorized access. Protection of 6645 information is provided through access control, data integrity and data confidentiality policies. 6646

9.4.6 Person, Publisher and Owner 6647

When publishing information in a UDDI registry the information becomes part of the published 6648 content of the registry. During publication of an item of UDDI information, a relationship is 6649 established between the publisher, the item published and the node at which the publish 6650 operation takes place. A registry may be composed of more than one node. The node to which 6651 the information was submitted and accepted via the UDDI v3 publication API set is the 6652 custodian of the item. A registry MUST specify whether transfer of ownership is supported and 6653 how this is accomplished. 6654

9.4.6.1 Registry Registration Policy 6655

A registry MUST specify how individuals who want to publish information become known to the 6656 registry. The registry may delegate registration to its nodes. 6657

9.4.6.2 Publication Limits 6658

When defining who can publish information, a registry may also constrain the amount of 6659 information that an individual can publish and through what means. A registry may establish 6660 different limits for different classes of users. These are known as “tier limits”. This policy may 6661 be delegated to the nodes in a registry. 6662

�� .

�� Universal

�� V3


205/405

9.4.7 Transfer of Ownership 6663

The registry must define whether intra-node ownership transfer is a service that is supported. 6664 If it is supported, the node must ensure that the UDDI information model is preserved while 6665 the data model is modified. A process for ownership transfer that MAY be supported by a 6666 registry or node is outlined in Section 5.4 Custody and Ownership Transfer API Set. 6667

9.4.7.1 Modeling of Ownership Transfer Support 6668

It is RECOMMENDED that the Custody and Ownership Transfer API Set described in Section 6669 5.4 be used for intra-node ownership transfer of businesses and tModels. If this 6670 recommended API is supported by a node, this MUST be represented as an instance of the 6671 uddi-org:custody_v3 tModel in a bindingTemplate in the Node Business Entity. Use of a 6672 different API set for ownership transfer is outside the scope of this specification, but should be 6673 modeled as a tModel referenced by a bindingTemplate in the Node Business Entity. 6674

9.4.8 Registry Authorization Policy 6675

A registry MUST have a policy on access to the information registered in it. A registry may 6676 specify a policy of global access for all API’s or it may specify a different type of access for 6677 each API and/or each publisher. The registry policy MAY specify that the authInfo element is 6678 required for an API. The policy describing who has access to what information is called the 6679 authorization policy. The implementation of each API, as reflected by the bindingTemplate that 6680 describes it (see section below), is a Policy Enforcement Point. 6681

9.4.8.1 Delegation of Authorization Policy 6682

A registry MAY allow nodes to specify their own access policies (delegation of policy), but an 6683 individual node’s access policy MUST be consistent with that of the other nodes in the registry 6684 and MUST NOT compromise the data in the registry as a whole. 6685

If the registry policy for authorization requires a unique identity for each owner of UDDI data, 6686 the registry MAY delegate the registration to each node in the registry but the registry MUST 6687 specify how the registration maps to the authorization policy. 6688

9.4.9 Modeling Authorization 6689

A policy that requires authorization to use a particular UDDI API set SHOULD be represented 6690 in the structures of the Node Business Entity element. An authorization concept used by an 6691 implementation of a UDDI API set SHOULD be represented by a tModel. This tModel 6692 SHOULD be referenced in the bindingTemplate implementing a UDDI API set that uses the 6693 particular authorization concept. An example of this modeling would be a tModel representing 6694 an authorization concept that requires the use of authentication credentials transmitted as 6695 HTTP headers. An implementation using this concept in conjunction with the publication API 6696 would be represented by a bindingTemplate containing both a tModelInstanceInfo for the 6697 publication API set tModel and a tModelInstanceInfo for the tModel for the authorization 6698 concept. 6699

In addition to authorization methods that are outside the scope of this specification, several of 6700 the UDDI API sets allow implementations to enforce authorization using an authInfo element 6701 obtained through the Security API set described in Section 5.3 Security Policy API Set. The 6702 bindingTemplate element representing each UDDI API set implementation SHOULD indicate if 6703 the authInfo element is required, optional or ignored in the bindingTemplate for the API set. It 6704 is RECOMMENDED that an XML document be inserted in the instanceParms element of the 6705 bindingTemplate element that represents an implementation of the Inquiry, Publication or 6706 Subscription API set. The XML element that SHOULD be in the instanceParms XML 6707 document is an instance of one of the NMTOKEN values for authInfoUse included in the UDDI 6708 v3 Policy Instance Parameters schema: 6709

�� V3


206/405

<authInfoUse xmlns="urn:uddi-org:api_v3_instanceParms”>required</authInfoUse> 6710 <authInfoUse xmlns="urn:uddi-org:api_v3_instanceParms”>optional</authInfoUse> 6711 <authInfoUse xmlns="urn:uddi-org:api_v3_instanceParms”>ignored</authInfoUse> 6712

6713

9.4.10 Registry Data Integrity 6714

A registry MUST specify how it maintains the information registered in it. The nodes MUST 6715 enforce this policy. The policy MUST state how the deletions of elements affect sub-elements. 6716 The policy MUST state whether and how physical tModel deletions are done. 6717

9.4.11 Registry Approved Certificate Authorities 6718

Each registry MUST establish the certificate authorities it recognizes. A registry MAY delegate 6719 this policy to a node. 6720

9.4.12 Registry Data Confidentiality 6721

A registry MAY have a policy for protecting the information under the custody of its nodes from 6722 unauthorized access. This policy has two dimensions. 6723

9.4.12.1 Persistent Data Confidentiality 6724

A registry MAY specify a policy for the encryption of UDDI data when stored .This policy MAY 6725 be delegated to the node to implement and is usually referred to as persistent data 6726 confidentiality 6727

9.4.12.2 Transient Data Confidentiality 6728

The data supplied in an API MAY need to be protected from being “sniffed” on the wire while 6729 being transmitted. This confidentiality (or the encryption of the information) MAY be specified 6730 as part of the transport of the API. Each API set MAY have different policies for Data 6731 Confidentiality. 6732

It is also possible to extend the transport of the information model in UDDI. This allows other 6733 transport protocols and extensions of SOAP to be used by an implementation. The impact of 6734 such an extension may, and will likely impact the information model presented in this 6735 specification. These extensions MUST be represented in the UDDI structures as tModels, or 6736 concepts, which include documentation to explain the concept of the extension or substitution 6737 of a transport protocol. Extension or substitution of any portion of the normative or 6738 recommended mechanisms in this specification is treated as an extension or substitution of the 6739 UDDI information model. In accordance with extensions to the information model, it is 6740 STRONGLY RECOMMENDED that an impact of an extension on the information model of 6741 UDDI is assessed by both operators and users of the registry. 6742

9.4.12.3 Modeling Data Confidentiality 6743

The RECOMMENDED means of conveying the policy for data confidentiality in transmission is 6744 to include a tModelInstanceInfo referencing a tModel that represents the mechanism for 6745 confidentiality in the binding for the UDDI API set. One example of modeling data 6746 confidentiality in transmission is represented by the application protocol tModel in Section 6747 11.3.1 Secure Sockets Layer Version 3 with Server Authentication. 6748

9.4.13 Registry Audit Policy 6749

A registry MAY specify a policy for the recording of information to maintain an account of the 6750 activity that has been processed. The audit policy MAY be delegated to the nodes in a registry. 6751 The audit policy SHOULD state what actions are audited and under what conditions. Also, the 6752 audit policy SHOULD state who has access to the audit trail. Audit policies could conceivably 6753


207/405

need to be presented as evidence in a legal proceeding and a UDDI registry SHOULD have a 6754 risk analysis done in order to assess the critical information that needs to be recorded. 6755

9.4.14 Registry Privacy Policy 6756

A registry MAY specify a policy for protecting the information collected about users of the 6757 registry. The privacy policy MAY be delegated to the nodes in a registry. 6758

9.4.15 Registry Clock Synchronization Policy 6759

The degree to which the clocks of each UDDI node are synchronized is a matter of registry 6760 policy. The clock is used to generate the created, modified and modifiedIncludingChildren 6761 elements. The frequency with which each clock is incremented (e.g.: 60 Hz, 100 Hz, etc) is 6762 also a matter of registry policy. 6763

9.4.16 Registry Replication Policy 6764

When a registry consists of a single node, replication is not required. If the registry consists of 6765 multiple nodes, then a policy for replication of the information in each node to every other node 6766 of the registry MUST be specified. 6767

9.4.16.1 Registry with Single-Master data model 6768

Registries that use the replication protocol defined in Chapter 7 Inter-Node Operation to 6769 replicate data use a single-master data model. See the section below on UDDI Node Policy 6770 Abstractions for recommendations for a single-master data model of replication. 6771

9.4.17 Support for Custody Transfer 6772

A multi-node registry MUST establish a policy stating if it allows transfer of custody of its data 6773 from one node in the registry to another node. 6774

9.4.17.1 Modeling Custody Transfer 6775

It is RECOMMENDED that the Custody Transfer API Set described in Section 5.4 be used to 6776 initiate inter-node custody transfer. If this recommended API is supported by a registry this 6777 MUST be represented as instances of the uddi-org:custody_v3 tModel in bindingTemplate 6778 elements in each participating node’s Node Business Entity. 6779 6780 It is further RECOMMENDED that the transfer_entities API described in Section 5.4 be used to 6781 communicate the custody transfer between nodes. If this recommended API is supported by a 6782 registry this MUST be represented as instances of the uddi-org:custody_ transfer_v3 tModel in 6783 bindingTemplate elements in each participating node’s Node Business Entity 6784

Use of a different API set for custody transfer is outside the scope of this specification but 6785 should be modeled as a tModel referenced by bindingTemplate in the node’s Node Business 6786 Entity. 6787

9.4.18 Registry Subscription Policy 6788

A registry must define a policy for supporting subscriptions including whether nodes may 6789 define their own policy. Individual nodes, including those in the UDDI Business Registry MAY 6790 establish policies concerning the use of the subscription API. A registry that supports 6791 subscription MUST contain at least one node that has a bindingTemplate referencing the uddi-6792 org:subscription_v3 tModel in its Node Business Entity. 6793


208/405

9.4.18.1 Registry Limits on Volume, Renewal and Retries 6794

Such policies might include restricting the use of subscription, defining which APIs are 6795 supported, establishing authentication requirements for subscriptions, or even imposing fees 6796 for the use of subscription services. 6797

9.4.18.2 Subscription Duration 6798

The duration or life of a subscription is also a matter of node policy. Subscribers may also 6799 create multiple subscriptions and registries may impose limits on the number or type of 6800 subscriptions subscribers may create. 6801

9.4.18.3 Authorization for Subscription 6802

A registry MUST specify a policy for deciding who is able to create, subscribe to and receive 6803 subscriptions including whether each node may have its own policies on subscription. The 6804 policies that include authorization SHOULD be reconciled with other authorization policies 6805 including the registries policy for authorization of APIs. 6806

9.4.18.4 Modeling Subscription 6807

A registry that supports subscription MUST contain at least one node that has a 6808 bindingTemplate referencing the uddi-org:subscription_v3 tModel in its Node Business Entity. 6809

The bindingTemplate element describing the subscription API set implementation SHOULD 6810 indicate whether find API elements as a filter are supported by the implementation. It is 6811 RECOMMENDED that an XML document be inserted in the instanceParms element of the 6812 bindingTemplate that represents an implementation of the Subscription API set. The XML 6813 element that SHOULD be in the instanceParms XML document is an instance of one of the 6814 NMTOKEN values for filterUsingFindAPI included in the UDDI v3 Policy schema: 6815

<filterUsingFindAPI xmlns="urn:uddi-org:policy_v3_instanceParms> 6816 supported</filterUsingFindAPI > 6817 <filterUsingFindAPI xmlns="urn:uddi-org:policy_v3_instanceParms> 6818 unsupported</filterUsingFindAPI> 6819

6820


9.4.19 Registry Value Set Policies 6823

UDDI allows for the creation of category, identifier, and category group systems and allows this 6824 information to be referenced within the registry. The node is the enforcement point for value set 6825 policies. The node MUST respond with an E_unsupported error code to requests to publish 6826 which include references to the unsupported checked value set tModels. 6827

9.4.19.1 Value set delegation policy 6828

The registry MUST have a policy on whether or not it allows individual nodes to specify their 6829 own policies for value sets. 6830

9.4.19.2 Checked value sets policy 6831

Value sets can be checked or unchecked. A registry must decide if it supports checked value 6832 sets. If checked value sets are allowed, the registry MUST have a policy for differentiating 6833 checked and unchecked value sets. Further, the registry MAY have a policy for determining 6834 which checked value sets it supports. 6835


�� V3


209/405

9.4.19.3 Uncached checked value sets policy 6836

If checked value sets are allowed, the registry MUST have a policy for determining whether 6837 uncached checked value sets are supported. 6838

9.4.19.4 Cache invalidation policy 6839

If cached checked value sets are supported, the registry must establish a policy for detecting a 6840 need for cache invalidation. 6841

9.4.19.5 External validation Web service supported policy 6842

If uncached checked value sets are supported, the registry must establish a policy for 6843 determining whether external validation Web services are supported. 6844

9.4.19.6 Value set Web service discovery policy 6845

If checked value sets are supported, the registry must establish a policy for modeling external 6846 value set caching and/or validation Web services, and their means of discovery. 6847

9.5 UDDI Node Policy Abstractions 6848

This section describes the policy abstractions that a registry MAY delegate to a node to define. 6849 These node policies need to be consistent with those of the registry. 6850

9.5.1 Node Key Generation 6851

If a registry delegates Key Generation, the nodes MUST establish policies for deciding 6852 whether publishers MAY publish a given key generator tModel. Section 5.2.2 Publishing 6853 entities with publisher-assigned keys contains details on key generation. See section 5.2 6854 Publication API Set for details on publication APIs. 6855

If delegated, the node MUST specify what the policy is when a key is not supplied on a 6856 publication API. 6857

9.5.2 Node Publisher Generated Key Assertion 6858

Each node must establish whether it will accept publisher generated keys. Nodes may accept 6859 a key generator tModel that is NOT a domainKey but is a uuidKey. 6860

9.5.3 Node Information Policy 6861

UDDI nodes that maintain custody of UDDI information and implement a data storage 6862 mechanism are responsible for the Data Model of the underlying storage of the data elements 6863 and its mapping to the Information Model. 6864

9.5.4 Node Authorization Policy 6865

If a registry allows nodes to specify their own access policies (delegation of policy), an 6866 individual node access policy MUST be consistent with the other nodes in the registry and 6867 MUST not compromise the data in the registry as a whole. 6868

If the registry policy for authorization requires a unique identity for each owner and is delegated 6869 to the node, each node in the registry MUST specify how the registration maps to the 6870 authorization policy. 6871

9.5.5 Node Registration and Authentication 6872

The node, as custodian of registry information MUST have a policy on what publishers are 6873 known to it. This is called the registration policy. The registration policy MUST support the 6874

�� web

�� keyGenerator

�� keyGenerator


210/405

implementation of the authorization policy. The registration policy MAY specify that all access 6875 to the information is public. The registration policy MAY specify that all users are required to 6876 authenticate to the node before API access is allowed. 6877

The node MUST specify whether (or under what conditions) any meta information about a 6878 publisher is accessible (name, company, phone number, etc). The protection and release of 6879 such meta information MAY also be considered to be a privacy policy. 6880

9.5.6 Node Publication Limits 6881

A node MAY chose to establish limits for the amount of information publishers are allowed to 6882 publish. 6883

9.5.7 Node Policy for Contesting Entries 6884

Each node SHOULD establish a convention for contesting entries. 6885

9.5.8 Node Audit Policy 6886

The audit policy MAY be delegated to the nodes in a registry. 6887

9.5.8.1 Node Availability Policy 6888

Each node SHOULD make available its policies for UDDI service availability. Each node 6889 SHOULD make clearly visible planned outage and maintenance schedules. 6890

9.5.9 Node Sort Order Policy 6891

Each node MUST specify the default sort order which it supports. A node MAY specify support 6892 for optional additional sort orders. All sort orders are specified via use of sortOrder tModels. 6893

9.5.9.1 Modeling Sort Orders 6894

The tModels for all supported sort orders SHOULD be included in the bindingTemplate for the 6895 UDDI Inquiry API set. The default sort order SHOULD be indicated as an instance parameter 6896 using the defaultSortOder element declared in the UDDI v3 Policy Instance Parameters 6897 schema 6898

<defaultSortOrder xmlns="urn:uddi-org:api_v3_instanceParms> 6899 binarySort</defaultSortOrder> 6900

6901

9.5.10 Find Qualifier Policy 6902

Each node MUST specify the find qualifiers which it supports on the Inquiry API Set and 6903 Subscription API Set. A node MAY specify support for optional additional find qualifiers not 6904 documented in this specification by registering them as a tModel. All find qualifiers are 6905 specified via use of findQualifier tModels. 6906

9.5.10.1 Modeling Find Qualifiers 6907

The tModels for all supported find qualifiers beyond those listed as required by UDDI 6908 implementations in Section 5.1.4 SHOULD be included in the bindingTemplate for the UDDI 6909 Inquiry API and Subscription API sets. All find qualifiers in Section 5.1.4, with the exception of 6910 the OPTIONAL diacriticInsensitveMatch find qualifier, are supported by a UDDI Web service 6911 referenced in a bindingTemplate which references the Inquiry API set tModel or a Subscription 6912 API set tModel where a find API is supported as a filter. 6913

�� V3


211/405

9.5.11 Node Approved Certificate Authorities 6914

Each node MUST establish the certificate authorities it recognizes. 6915

9.5.12 Node Subscription API Assertion 6916

The Subscription API is an optional API that may or may not be implemented by a node. Each 6917 node MUST determine whether subscription is in fact supported and, if so, the exact kinds of 6918 subscription that are supported. 6919

9.5.13 Node Element Limits 6920

A node may limit the number of <name>, <personName> or <description> elements decorated 6921 with the same xml:lang attribute. So, for example, a node may reject a message if the node 6922 policy is to only allow two name elements with the same language and more than two 6923 elements are supplied. 6924

An additional limit that a node may impose is a limit on the size of requests to a particular API. 6925 The limit should be expressed as the maximum number of bytes that will be accepted for 6926 subsequent processing in one request message. 6927

9.5.13.1 Modeling Request Size Limit 6928

The bindingTemplate element describing the API which limits the size of a request message 6929 SHOULD indicate the limit in number of bytes in the instanceParms element. The XML 6930 element that SHOULD be in the instanceParms XML document is an instance of one of the 6931 maximumRequestMessageSize elements included in the UDDI v3 Policy schema: 6932

<maximumRequestMessageSize xmlns="urn:uddi-org:policy_v3_instanceParms> 6933 2000000</maximumRequestMessageSize> 6934 6935


9.5.14 Node HTTP GET Services 6938

A node MAY specify if it supports an HTTP GET service for access to the XML representations 6939 of UDDI data structures. If the node does offer such a service, it SHOULD specify the base 6940 URI to be used. The base URI SHOULD be specified in the policyDescription element of the 6941 policy element for the "HTTP GET Support" policy. See Section 6.5 Node HTTP GET 6942 Services. 6943

9.5.15 Node discoveryURL Generation 6944

A node MAY establish a policy on whether it generates and adds discoveryURLs to 6945 businessEntity elements. This is NOT RECOMMENDED behavior as it complicates the use of 6946 digital signatures. 6947

9.5.16 Node XML Encoding Policy 6948

A node MAY establish a policy on whether it uses UTF-8 or UTF-16 as the character encoding 6949 it uses in response messages so that client-side XML document processing can be optimized. 6950

�� V3

��


212/405

9.6 UDDI Recommended Registry Policies 6951

The policies listed in this section are those that are RECOMMENDED in order to provide an 6952 example of a UDDI Registry instance. Each registry MAY chose to define its own policies but 6953 should be cautious and understand the relationships between policies, registries and nodes. 6954

. 6955

9.6.1 Key Generator tModels 6956

It is RECOMMENDED that the saving of a key generator tModel is disallowed and rejected 6957 from v1 and v2 clients. 6958

9.6.2 Information Model 6959

The UDDI information model is instantiated in the data model through the descriptions of the 6960 data structures (see Chapter 3 Data Structures), operations (see Chapter 5 UDDI 6961 Programmers APIs) and the policies described in this section. 6962

A registry MAY offer different bindings for the APIs across the constituent nodes of the registry. 6963 A particular node in a UDDI registry MAY provide access to the UDDI data through one or 6964 more UDDI API sets. A UDDI node MAY also support any number of bindings for the number 6965 of APIs it offers. Variations of policies for these different bindings MAY be different. For 6966 example, a node might choose to offer both http and https bindings for the inquiry API and 6967 apply different access policies depending on which binding is used. 6968

9.6.2.1 Modeling UDDI APIs 6969

A UDDI registry MUST have at least one node that offers a Web service compliant with the 6970 Inquiry API set. A UDDI registry SHOULD have at least one node that offers a Web service 6971 compliant with the Publication, Security, and Custody and Ownership Transfer API sets. If a 6972 UDDI registry has multiple nodes, all nodes SHOULD offer Web services that are compliant 6973 with the Replication API set. The Subscription and Value Set API sets are OPTIONAL for all 6974 nodes and all registries. 6975

The availability of one or more UDDI API sets at a node SHOULD be reflected through a 6976 bindingTemplate referencing the appropriate UDDI API set tModel for each Web service 6977 endpoint.6978

�� <#>Key Format¶

It is RECOMMENDED that registries define their key format policy to use keys from the scheme “uddi” following the syntactic and semantic rules for that scheme as given in this specification��

keyGenerator

�� web

�� web

�� web


213/405

6979

API Set tModel Recommended Transport

Recommended Security Mechanisms

Integrity / Confidentiality

Authentication

Inquiry uddi-org:inquiry_v3 HTTP

Publication uddi-org:publication_v3 HTTP SSL V3

Security uddi-org:security_v3 HTTP SSL V3

Custody Transfer

uddi-org:custody_v3 HTTP SSL V3

Replication uddi-org:replication_v3 HTTP SSL V3 Mutual authentication

Subscription uddi-org:subscription_v3

uddi-org:subscriptionListener_v3

HTTP SSL V3

Value Set uddi-org:valueSetValidation_v3

uddi-org:valueSetCaching_v3

HTTP

6980

9.6.3 Keying 6981

UDDI MUST use URIs conforming to RFC 2396 for keys. Further, it is RECOMMENDED that 6982 registries use keys from the scheme “uddi” following the syntactic and semantic rules for that 6983 scheme as given in this section, in section 5.2.2 Publishing Entities with Publisher Assigned 6984 Keys, in Section 8.2 Data Management Policies and Procedures Across Registries, and 6985 Section 9.4.2 General Keying Policy. The primary motivations for the recommendation to use 6986 uddiKeys is to allow publishers to specify keys for entities they publish in UDDI registries using 6987 “sensible looking” keys and to promote interoperation among UDDI registries. See Chapter 10 6988 Multi-Version Support for issues regarding backwards compatibility. 6989

9.6.4 Domain key generator tModels 6990

For registries that use the recommended key syntax, a root key generator tModel based on a 6991 domain key establishes a key partition from which uddiKeys can be derived and used in other 6992 entities controlled by the publisher, as described in section 4.4.1 Recommended Syntax. 6993 Additional considerations are involved when publishing a domain key generator tModel for the 6994 first time. 6995

1. As described in section 5.2.2.1 Key generator keys and their partitions the tModelKey 6996 MUST be based on a domainKey and MUST end with the term: keyGenerator. 6997

2. Registry policy for publishing such tModels MAY require the tModel to be signed. 6998

It is recommended that an authorization policy for saving a root key generator tModel based on 6999 a domain key be established by the registry. This policy should include whether the registry 7000 requires a Signature element and what constitutes a valid signature for saving the domain key 7001 generator tModel.. 7002


214/405

9.6.5 Replication Policies 7003

Registries that use the replication protocol defined in Chapter 7 Inter-Node Operation to 7004 replicate data use a single-master data model. The nodes in a registry using this replication 7005 protocol MUST enforce the recommended policy in Section 7.1 Inter-Node Policy Assertions. 7006 The registry SHOULD define policies detailing the topology for replication and the frequency of 7007 replication API calls, or acceptable latency for processing changeRecord elements. 7008

These policies MAY be declared using the Replication Configuration Structure as described in 7009 Section 7.5 Replication Configuration. If the registry policy requires that the nodes adhere to 7010 the details in the registry Replication Configuration Structure, a policy SHOULD further detail 7011 management of the Replication Configuration Structure. The policy for the management of the 7012 Replication Configuration Structure SHOULD include details on the authorized publisher of the 7013 Replication Configuration Structure and it is RECOMMENDED that the authorized publisher 7014 use the dsig:Signature element to sign the Replication Configuration Structure for integrity. It is 7015 further RECOMMENDED that the registry distribute the Replication Configuration Structure in 7016 a manner that restricts access to the file to the operators of nodes in the registry. Changes to 7017 the replication topology as well as the number of nodes in a registry MAY be initiated through 7018 changes to the Replication Configuration Structure. The RECOMMENDED method for using 7019 the Replication Configuration Structure to add and remove nodes from a registry using 7020 replication is described in Sections 7.8 and 7.9. 7021

The registry SHOULD define policies detailing the authentication method that is used to 7022 authorize access to the change record journal for each node in the registry. It is 7023 RECOMMENDED that SSL Version 3.0 with mutual authentication be implemented by each 7024 node in a registry using the replication API set as described in Section 7.5.5 Security 7025 Configuration. 7026

The total set of replication policies SHOULD be documented using the Replication 7027 Configuration Structure in conjunction with human readable documentation that is distributed 7028 to the operators of the nodes in a registry using the replication protocol. 7029

This section describes the registry and node policies that must be established surrounding the 7030 use of value sets in UDDI. Value sets are identifier and categorization systems that are 7031 referenced using keyedReferences and are applied to tModels, businessEntities, 7032 businessServices, and binding Templates by publishers. Inquirers can use value sets to 7033 enhance discovery. 7034

9.6.6 Value sets 7035

9.6.6.1 Recognizing value sets 7036

Publishers of value set tModels SHOULD categorize those that are for category systems with 7037 the categorization value, for identifier systems with the identifier value, and for category group 7038 systems with the categorizationGroup value. 7039

9.6.6.2 Unchecked value sets 7040

An unchecked value set is one that allows unrestricted references to its values. A UDDI 7041 registry is REQUIRED to have a policy to differentiate between unchecked value sets and 7042 checked value sets. UDDI registries MUST allow unchecked value sets to be referred to in 7043 keyedReferences. tModels that represent unchecked value sets SHOULD be categorized with 7044 the unchecked value from the uddi-org:types category system. 7045

9.6.6.3 Checked value sets 7046

Published keyedReferences involving checked value sets are validated using a validation 7047 algorithm acceptable to the value set provider. The most common validation is that referenced 7048 values are part of a predefined set. Checking can often be accommodated by the node using 7049


215/405

a cached set of valid values. More complicated or contextual validation can be handled by 7050 external validation services. See Section 5.6 Value Set API Set for more information. 7051

tModels that represent checked value sets SHOULD be categorized with the checked value 7052 from the uddi-org:types category system. 7053

Validation algorithms that do no more than verify that referenced values are part of a set of 7054 approved values can often be hosted by a node if the value set provider agrees to allow this to 7055 happen. tModels for checked value sets that allow caching of valid values for this simple kind 7056 of validation SHOULD be categorized with the cacheable categorization from the uddi-7057 org:types category system. Similarly, if a tModel for a checked value set does not support 7058 caching of its values for validation, it SHOULD be categorized with the uncacheable 7059 categorization by uddi-org:types category system. 7060

A node may acquire the set of valid values for a cached checked value set through private 7061 arrangements or through the invocation of a get_allValidValues Web service. A node can 7062 similarly validate references to a checked value set through private arrangements or through 7063 the invocation of a validate_values Web service. The tModel for a checked value set that has a 7064 get_allValidValues or validate_values Web service SHOULD be categorized with a reference 7065 to the bindingTemplate for the get_allValidValues or validate_values Web service using the 7066 uddi-org:validatedBy category system. The referred to bindingTemplate SHOULD contain a 7067 reference to all value set tModels to which the value set Web service applies in the 7068 tModelInstanceDetails element. 7069

A node SHOULD flush a valid values cache that was previously obtained through invocation of 7070 a get_allValidValues service when it receives notice as the custodial node or through the 7071 replication stream that the tModel for the checked value set has been republished. The 7072 recommended technique for a provider of a cached checked value set to notify UDDI nodes of 7073 new valid values is to republish the tModel for the value set. Providers of cached value sets 7074 SHOULD NOT delete valid values from the value set or change the meaning of values as this 7075 adversely affects entities that previously referenced the value set and erodes the confidence in 7076 these references. 7077

9.7 UDDI Policy Summary 7078

The tables below summarize the information presented in this chapter for easy access. 7079

9.7.1 UDDI Registry Policy Abstractions 7080

The following table captures the policies that a registry MAY specify. 7081

Policy Group

Policy Name Policy Rule Description PDP Sections Type

Policy Delegation

Registry Policy Delegation

The registry may allow nodes to define their own policies.

Registry 9.4.1 Registry Policy Delegation

Document

Delegation of User registration

A registry defines if nodes may specify their own user registration

Registry 1.7 Introduction to Security

Document

Delegation of Authorization

A registry defines if nodes may specify their own access control policy

Registry 1.7 Introduction to Security

9.4.8.1 Delegation of Authorization Policy

Document


216/405

Policy Group


Delegation of Subscription Policy

The registry defines if nodes may define their own policies for subscription.

Registry

9.4.18 Registry Subscription Policy

Document

Value set policy delegation policy

Value set policy delegated to node

Registry 9.4.19.1 Value Set Delegation Policy

Document

Keying Registry General Keying Policy

The registry defines a policy for key format and key generation.

Registry 9.4.2 Registry General Keying Policy

Document

UDDI keying

Registry Key Generation

The registry defines a policy for whether and how a given node or publisher is allowed to register a key generator tModel.

Registry

[may be delegated]

5.2.2 Publishing entities with publisher assigned keys

Document

Registry Key Default

The registry defines what happens when a key is not supplied.

Registry

[may be delegated]

9.4.3.3 Registry Key Default

Document

Registry Support of UUIDKeys

The registry defines whether uuidKeys are accepted.

Registry 9.4.3.4 Registry Support of UUID Keys

Document

Registry Root Key Generation

The registry defines whether or not affiliations are allowed and how key partitions are maintained.

Registry

[may be delegated]

9.4.3.5 Root Key Generation

Document

UDDI Information and Access Control Policies

Registry Registration

The registry defines a policy for registration of users.

Registry

[may be delegated]

1.7 Introduction to Security

9.4.4 UDDI Information and Access Control Policy

Document

Registry Authorization

The registry defines a policy for Authorization of users.

Registry

[may be delegated]

9.4.8 Registry Authorization Policy

Model

Registry Data Integrity

The registry defines a policy for Data Integrity.

Registry

[may be delegated]

9.4.10 Registry Data Integrity

Model

Registry Persistent Data Confidentiality

The registry defines a policy for persistent Data Confidentiality (data in the data repository)

Registry

[may be delegated]

9.4.12 Registry Data Confidentiality

Document

�� recommended

�� keyGenerator


217/405

Policy Group


Registry Audit The registry defines a policy for Audit

Registry

[may be delegated]

9.4.13 Registry Policy Audit

Document

Registry Privacy

The registry defines a policy for Privacy.

Registry

[may be delegated]

9.4.14 Registry Privacy Policy

Document

Registry Extensibility

The registry defines a policy for extensibility

Registry Appendix H Model

Registering Nodes in a registry

The registry defines how nodes are added and deleted from a registry.

Registry 7.8 Adding a Node to a Registry Using Replication

Document

APIs Data Confidentiality for Inquiry

The registry defines a policy for Data Confidentiality for the inquiry API set.

Registry

[may be delegated]


Model

Authorization for Inquiry

The registry determines if authorization is required on the API set and how this is supplied.

Registry

[may be delegated]

9.4.9 Modeling Authorization

Model

Data Confidentiality for Publish

The registry defines a policy for Data Confidentiality for the publish API set.

Registry

[may be delegated]


Model

Authorization for Publish


Registry

[may be delegated]


Model

Data Confidentiality for Subscription

The registry defines a policy for Data Confidentiality for the subscription API set.

Registry

[may be delegated]


Model

Authorization for subscription


Registry

[may be delegated]


Model

Data Confidentiality for Replication

The registry defines a policy for Data Confidentiality for the replication API set.

Registry

[may be delegated]


Model

Authorization for replication


Registry

[may be delegated]


Model


218/405

Policy Group


Data Confidentiality for Custody Transfer

The registry defines a policy for Data Confidentiality for the Custody and Ownership Transfer API set.

Registry

[may be delegated]


Model

Authorization for custody transfer


Registry

[may be delegated]


Model

Data Confidentiality for External validations

The registry defines a policy for Data Confidentiality for the external validations API set.

Registry

[may be delegated]


Model

Authorization for external validations


Registry

[may be delegated]


Model

Time Policies

Clock Synchroniza-tion Policy

The registry may define how nodes in a registry synchronize their clocks.

Registry 9.4.15 Registry Clock Synchronization Policy

Document

User Policies

Publication Limits

A registry defines the amount of information that publishers are able to publish.

Registry

[may be delegated]

9.4.6.2 Publication Limits

Document

Person, Publisher and Owner

A registry defines the relationship between data and publishers.

Registry 9.4.6 Person, Publisher and Owner

Document

Transfer of Ownership

A registry defines if data is able to be transferred between owners in the registry.

Registry 9.4.7 Transfer of Ownership

Document

Data Custody

Registry support for Data Custody

Registries must specify whether custody transfer is supported

Registry 9.4.17.1 Modeling custody transfer

Document

Replication Replication support for Data Custody

A registry defines if replication of transfer is supported

Registry 9.4.17 Replication support for Custody Transfer

Document

Registry Support for Replication

The registry defines if replication is supported

Registry 7.1 Inter-Node Policy Assertions

Model

Single Master Replication

The registry defines if the Single master data model for replication is supported

Registry 7.1 Inter-Node Policy Assertions

Model


219/405

Policy Group


Subscription Registry Support for Subscription

The registry defines if subscription is supported.

Registry

[may be delegated]

5.5 Subscription API Set


Model

Registry limits for email subscriptions

The registry defines limits for the number of email subscription-related notification-based retries.

Registry

[may be delegated]


Document

Registry support for filter criteria

The registry defines if the Inquiry APIs are available for use as filter criteria in a subscription

Registry

[may be delegated]

9.4.18.1 Registry Limits

Model

Registry conditions for subscription renewal

The registry defines conditions for subscription renewal

Registry

[may be delegated]


Document

Registry limits on subscription volume

The registry defines the limit on the volume of data to be returned in subscription results.

Registry

[may be delegated]


Document

Subscription Duration

The registry defines the duration of time in which a subscription remains active.

Registry

[may be delegated]

9.4.18.2 Subscription Duration

Document

Value Set Policy

Checked value sets policy

Checked values sets supported

Registry

9.4.19 Registry Value Set Policies

Document

Cache invalidation policy

Cache Invalidation Trigger

Registry 9.4.19.4 Cache Invalidation Policy.

Document

Uncached checked value sets policy

Uncached value sets supported

Registry

[delegated]

9.4.19.3 Uncached checked value sets policy

Document

External validation Web service supported policy

External validation Web services supported

Registry

[delegated]

9.4.19.5 External Validation Policies

Document

Value set Web service discovery policy

Modeling policy for registering and discovering value set Web services

9.4.19 Registry Value Set Policies

Document


220/405

Policy Group


Data Integrity/Data Confidentiality

A policy for certificate authorities is supported

Node 9.4.11 Registry Approved Certificate Authorities

Document

7082

9.7.2 UDDI Node Policy Abstractions 7083

Policy Group


Node Key Policies

Node Key Generation

If delegated, a node may define which publishers are allowed to register tModels.

Node 5.2.1 Publishing entities with node assigned keys

Document

Node Publisher Generated Key Assertion

Each node must establish whether or not it will accept publisher generated keys.

Node 9.5.2 Node Publisher Generated Keys

Document

Node Information

Policy

Node Message Limit

A node may limit the maximum size of a request message

Node 9.5.13 Node Element Limits

Model

Node Registration

The node defines a Policy for registration of users.

Node 9.5.5 Node Registration and Authentication

Document

Node Publication Limits

A node defines the amount of information that publishers are able to publish.

Node 9.5.6 Node Publication Limits

Document

Disclaimers A policy for contesting entries is supported

Node 9.5.7 Node Policy for Contesting Entries

Document

Node Authentication

The node defines a policy for Authentication of its registered users. Mapping between identification and authorization

Node 1.7 Introduction to Security

9.5.5 Node Registration and Authentication

Model

Node Authorization

The node defines a policy for Authorization of its users.

Node 9.5.4 Node Authorization Policy

Model

Node Privacy Policy

A node defines the privacy policy for the operational information that it collects and maintains as a result of registration.

Node Document


221/405

Policy Group


Node Audit Policy

A node defines its local policy for audit

Node Document

Node Availability Policy

A node defines a policy for its service availability.

Node Document

Node Sort Order

Each node MUST specify the default sort order supported. A node MAY specify support for any optional additional sort orders. All sort orders are specified via use of a sortOrder tModel.

Node 9.5.9 Node Sort Order Policy

Document

Node APIs Node use of Security APIs

The node defines if the criteria for identifying authorized publishers is via authInfo

Node 4.7 About Access control and the authInfo Element

Model

Authorization for Inquiry APIs

AuthInfo is supported on the Inquiry APIs


Model

Authorization for Publish APIs

AuthInfo is supported on the Publish APIs


Model

Authorization for Custody APIs

AuthInfo is supported on the Custody and Ownership Transfer APIs


Model

Authorization for Subscription APIs

AuthInfo is supported on the Subscription APIs


Model

Authorization for Value Set APIs

AuthInfo is supported on the Value Set APIs


Model

Data Integrity/Data Confidentiality

A policy for certificate authorities is supported

Node 9.5.11Node Approved Certificate Authorities

Document

Misc. Node Element Limits

A node may limit the number of elements within the same language.

Node 9.5.13 Node Element Limits

Document

Node Discovery URLs

A node may establish a policy on whether or not it generates Discovery URLs.

Node 9.5.15 Node discoveryURL Generation

Document


222/405

Policy Group


Node HTTP Get Service

A node MAY specify if it supports an HTTP GET service for access to the XML representations of UDDI data structures

Node 9.5.14 Node HTTP GET Services

Document

Node XML Encoding

A node MAY specify the character encoding (UTF-8 or UTF-16) it uses in response messages.

Node 4.2 XML Encoding Requirements

9.5.16 Node XML Encoding Policy

Document

7084


223/405

7085

10 Multi-Version Support 7086

There are instances when a UDDI node may support multiple UDDI API versions that interact 7087 with a common set of UDDI data. A UDDI node MAY choose to support the Version 3 7088 specification while continuing to allow users to perform Version 2 inquiry and publish API 7089 calls36. In such a configuration, a node MUST respond to an API with behavior according to 7090 the namespace from which the API originated. For example, a find_business call within the 7091 uddi-org:api_v2 namespace MUST behave according to the Version 2 specification, while a 7092 find_business call within the uddi-org:api_v3 namespace MUST behave according the Version 7093 3 specification – regardless of the fact that these queries were issued on an identical dataset. 7094

There are situations where this guiding principle is not sufficient to address differences in the 7095 behavior of existing APIs as well as entirely new APIs that may not exist in an earlier version. 7096 To help node implementers in these unclear situations, this chapter will review the special 7097 considerations to be taken into account when supporting a multi-versioned node. This chapter 7098 also covers the considerations of migrating earlier versions of UDDI data to the Version 3 data 7099 structures. 7100

10.1 Entity Key Compatibility with Earlier Versions of UDDI 7101

The V3 key format change has some important considerations for implementations that wish to 7102 simultaneously support several versions of the UDDI APIs. This section explores how to 7103 support a multi-versioned UDDI implementation with regard to entity keys. 7104

10.1.1 Generating Keys From a Version 3 API Call 7105

A UDDI registry that wishes to support both UDDI v2 and UDDI v3 interfaces is faced (among 7106 other issues) with the problem of needing to manifest to its v2 inquirers keys for entities that 7107 were created using UDDI v3 and thus do not natively possess keys acceptable to the UDDI v2 7108 key format as is the case for a v3 domainKey. The manner in which a UDDI v2 key is 7109 associated with such a UDDI v3 entity is not normatively defined, and so may be carried out by 7110 any means desired so long (of course) as the same result is seen by all UDDI v2 inquirers at 7111 any node in the registry. 7112

The following approach is straightforward and efficient, and is RECOMMENDED. In particular, 7113 since this approach is entirely algorithmic, no additional information need be communicated or 7114 conveyed for this purpose between the nodes of the registry beyond that which would normally 7115 be necessary in a UDDI-v3-only registry. 7116

A registry may establish as part of its key management policy, use of a direct mapping 7118 algorithm for UUID keys. This mapping consists of what follows: V3 keys that are UUID keys 7119 are transformed to V2 keys by removing the “uddi:” prefix, and in the case of a key referring to 7120 a tModel, pre-pending “uuid:” to the UUID. All other V3 keys that are not UUID keys are 7121 hashed using the hashing algorithm described herein. 7122

Let k3 be a UDDI v3 key. 7123

1. take an MD5 hash of the concatenation of: 7124

a. the 16-byte sequence 14 e3 a2 b1 3b d8 4c f5 af a6 0d 14 1b f3 20 76 7125

36

The same principal holds true for version 1 API calls.

�� principal

�� using the recommended

key scheme

�� Let k3 be a UDDI v3 key. In

the table below we define an associated UUID uuid(k3). Once this is done, one straightforwardly defines a UUID v2 key for the entity denoted by k3 in the normal UDDI v2 manner as appropriate for the type of that entity.¶Let uuid(k3) be the UUID defined as follows:¶<#>Let h(k3) be the MD5 hash of the concatenation of ¶<#>the 16-byte sequence 0f 86 ac ae 5d f4 fc 4c b0 ef 7c 6c 36 f8 0f 53¶<#>the bytes of the key k3¶�� ¶<#>Let u(k3) be the 16-octet endian-sensitive value created as follows (illustrated in both big-endian and little-endian forms of u(k3))¶Octet # � � ��


224/405

b. the normalized form of k3 (including the required “uddi:” prefix); see Section 7126 4.4 About uuidKeys for the normalization process 7127

2. modify the 16 octets output of the MD5 hash: 7128

a. change the four most significant bits of the seventh octet to ‘0011’ 7129

b. change the two most significant bits of the ninth octet to ‘10’ 7130

3. format the 16 octets in the form of a UUID string; in making this interpretation, we rely 7131 on the specification of UUIDs as found in http://www.uddi.org/pubs/draft-leach-uuids-7132 guids-01.txt: 7133

a. convert them into a hexadecimal string 7134

b. separate them into groups of 8, 4, 4, 4, and 12 hexadecimal digits with 7135 hyphens 7136

Once this is done, one straightforwardly defines a UUID v2 key for the entity 7137 denoted by k3 in the normal UDDI v2 manner as appropriate for the type of 7138 that entity. 7139

Some examples of V3 domainKeys that have been processed into UUID-based UDDI Version 7140 1 and 2 keys using this algorithm are: 7141

For the businessKey uddi:tempuri.org = 5de0d2b4-ce18-318a-a7fa-64692c42dc25 7142

For the tModelKey uddi:tempuri.org:keygenerator = uuid:eabe885f-9de2-3924-bd41-7143 9eff2ce52606 7144

As shown in the examples above, keys for tModels in UDDI Version 1 and 2 were denoted 7145 with a prefix “uuid:” followed by the UUID. All other keys in UDDI Version 1 and 2 are in the 7146 format of a UUID without the prefix. 7147

Note that while there exists a mapping between two keys, a client must use the appropriate 7148 key for the version being used. A Version 2 API must specify an entity with a Version 2 key 7149 and vice versa. 7150

10.1.2 Generating Keys from a Version 2 API Call 7151

In the case where an entity is saved in a multi-versioned registry using a Version 2 API, a 7152 different set of issues arise. Again, the manner in which this is accomplished is non-normative, 7153 but a correlation must be in place between the v2 and v3 entity. A recommended approach to 7154 this requirement is to generate a v3 key prior to generating a v2 key and then using the 7155 recommended hashing algorithm and/or a mapping algorithm to create a v2 key for the user. 7156 Again, because this approach is algorithmic, it introduces no replication issues. 7157

As an example of the hashing algorithm, suppose a tModel is being published at a node of a 7158 registry that generates its V3 keys in the partition of the key generator 7159 “uddi:example.com:registry:sales:keygenerator”. And suppose that the node assures 7160 uniqueness in the partition by generating monotonically increasing serial numbers. 7161

When the publication is done with a v2 API, the node first generates a v3 key of the form 7162 “uddi:example.com:registry:sales:y” where y is the next serial number. It then generates a v2 7163 using the MD5 hash discussed above. 7164

As an example of the mapping algorithm, the node first generates a v3 UUID key of the form 7165 “uddi:3942306d-2438-492a-9b2a-185413b93673”, it then generates the v2 key as “3942306d-7166 2438-492a-9b2a-185413b93673” or “uuid:3942306d-2438-492a-9b2a-185413b93673” if the 7167 entity is a tModel. 7168

Note that a publisher cannot perform “backward migration”. In other words, one cannot 7169 correlate a v3 key that is proposed by a publisher and an existing v2 key. For example, if a 7170 business had published a businessEntity under v2 and then acquired a domainKey generator 7171

��

�� http://www.uddi.org/pubs/dr

aft-leach-uuids-guids-01.txt

�� 28155ef3-a852-36d5-84b3-

db52fa53645f¶��

keyGenerator��

c8f22986-0e4e-3869-b03f-21f7f3ee9e02

�� !#"%$�& "#��'

�� From

�� For

�� keyGenerator

�� Y

�� Y


225/405

under v3, that publisher could not create a domainKey and have it be associated with the 7172 existing businessKey created for the v2 entry. In this case, the publisher would have to delete 7173 the first entity and resave the entity with the new domainKey. 7174

10.1.3 Migrating Version 2 keys to a Version 3 Registry 7175

Migrating data containing v2 format keys is introduces a different set of issues. One needs to 7176 generate and add v3-format keys to match keys already in the data. Implementations are free 7177 to choose whatever algorithm they choose for this, but a correlation must be maintained 7178 between the existing v2 entity and its correlative v3 entity. Because the hashing solution 7179 discussed above is a one way hash, a different mapping is required to preserve the v2 key of 7180 the existing v2 entity while creating a valid v3 key. 7181

A mapping can still be created algorithmically which does not require nodes to transmit 7182 additional information to one another as follows: 7183

10.1.3.1 Within a Root Registry 7184

During migration, to generate a v3 key corresponding to a v2 tModelKey, replace the “uuid:” 7185 prefix with the v3 prefix “uddi:”. To generate the v3 key corresponding to any other type of key, 7186 prepend the v2 key with the v3 prefix “uddi:”. 7187

For example, the v2 tModelKey “uuid:68DE9E80-AD09-469D-8A37-088422BFBC36” would 7188 correspond to the v3 key “uddi:68DE9E80-AD09-469D-8A37-088422BFBC36” and the v2 7189 businessKey “D2033110-3AAF-11D5-80DC-002035229C64” would correspond to the v3 key 7190 “uddi:D2033110-3AAF-11D5-80DC-002035229C64”. 7191

Note that this algorithm is transitive: after migration, given a v3 key, one can determine its v2 7192 equivalent by applying this same pattern in reverse. 7193

10.1.3.2 Within an Affiliate Registry 7194

In order to insure that the affiliate registry’s keys are unique in the context of other registries, 7195 the affiliate registry cannot migrate to v3 keys until it has established a key generator tModel 7196 with the root registry. By establishing a key generator, the affiliate registry can then migrate its 7197 keys, using the keyGenerator prefix as a basis for its keys. 7198

For example, the affiliate might establish the key generator, “uddi:example.com:keygenerator”. 7199 It would use this prefix when migrating the entirety of its v2 keys. For example, the v2 7200 tModelKey “uuid:68DE9E80-AD09-469D-8A37-088422BFBC36” would correspond to the v3 7201 key “uddi:example.com:68DE9E80-AD09-469D-8A37-088422BFBC36” and the v2 7202 businessKey “D2033110-3AAF-11D5-80DC-002035229C64” would correspond to the v3 key 7203 “uddi:example.com:D2033110-3AAF-11D5-80DC-002035229C64”. 7204

Again, this algorithm is transitive: after migration, given a v3 key, one can determine its v2 7205 equivalent by stripping the keyGenerator prefix and, in the case of tModel, appending “uuid:”. 7206 It is important that all nodes in the affiliate registry are aware of the algorithm used during the 7207 migration such that a correlation is maintained. 7208

10.1.4 Mapping v1/v2 Canonical tModel Keys to v3 Evolved Keys 7209

Another exception to the algorithmic mapping is for the v1/v2 canonical tModel keys. In order 7210 to preserve these ubiquitous keys, there must be a direct mapping to the v1/v2 GUIDs 7211 documented in the v1/v2 specification. As such, nodes responding to a v2 request with one of 7212 the v3 canonical tModels must not generate a hashed key, but rather must correlate the v3 7213 with an existing GUID. The list of those GUIDs and domainKeys are listed below and are also 7214 clearly noted in Chapter 11 Utility tModels and Conventions as evolved keys as opposed to 7215 derived keys. 7216

7217

�� keyGenerator

�� keyGenerator

�� keyGenerator

�� keyGenerator


226/405

V3 key V1/V2 key

uddi:uddi.org:categorization:types uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4

uddi:uddi.org:categorization:general_keywords uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4

uddi:uddi.org:categorization:nodes uuid:327A56F0-3299-4461-BC23-5CD513E95C55

uddi:uddi.org:relationships uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03

uddi:uddi.org:categorization:owningbusiness uuid:4064C064-6D14-4F35-8953-9652106476A9

uddi:uddi.org:identifier:isreplacedby uuid:E59AE320-77A5-11D5-B898-0004AC49CC1E

uddi:uddi.org:transport:http uuid:68DE9E80-AD09-469D-8A37-088422BFBC36

uddi:uddi.org:transport:smtp uuid:93335D49-3EFB-48A0-ACEA-EA102B60DDC6

uddi:uddi.org:transport:ftp uuid:5FCF5CD0-629A-4C50-8B16-F94E9CF2A674

uddi:uddi.org:transport:fax uuid:1A2B00BE-6E2C-42F5-875B-56F32686E0E7

uddi:uddi.org:transport:telephone uuid:38E12427-5536-4260-A6F9-B5B530E63A07

�� catgorization

�� uddi:uddi.org:identifier:owni

ngBusiness

�� isReplacedBy


227/405

7218

10.2 Other Considerations of Version 2 Inquiry API Calls 7219

10.2.1 keyedReferenceGroup data 7220

Because keyedReferenceGroups elements did not exist in Version 2, they will not be returned 7221 when a Version 2 API requests an entity that in fact has keyedReferenceGroup elements. 7222

10.2.2 keyedReference data 7223

With Version 3, tModelKey elements MUST be specified for a keyedReference structure 7224 contained within an Inquiry API requests. Requests to the Version 3 namespace containing 7225 keyedReference structures without tModelKey elements will fail schema validation and be 7226 rejected. 7227

10.2.3 Multiple overviewDoc data 7228

With Version 3, an entity may have multiple overviewDoc elements. If a Version 2 API queries 7229 such an entity, the first overviewDoc element will be returned according to its document order. 7230

10.2.4 Multiple personName data 7231

With Version 3, a contact may have multiple personName elements. If a Version 2 API 7232 queries such an entity, the first personName element will be returned according to its 7233 document order. 7234

10.2.5 Multiple xml:lang attributes of the same language 7235

In Versions 2 there could only be one name or description element with a given xml:lang. In 7236 Version 3 of UDDI there can be multiple names with the same language attribute. When this 7237 occurs the first name or description is considered the default for that language. 7238

10.2.6 New error codes 7239

Registries that support multiple versions of the UDDI APIs respond with error codes 7240 appropriate to the version of the APIs that are invoked. For example, when a v2 API is 7241 invoked, a registry MUST NOT respond with a NEW v3 error code. 7242

10.2.7 Service Projections 7243

Because service projections are not available in UDDI Version 1, they never appear in the 7244 result set of a Version 1 find_business or find_service inquiry. 7245

10.2.8 Length Discrepancies 7246

A number of fields are permitted to be longer in v3 than in prior versions of the UDDI 7247 specification. In the case when a v2 inquiry is made on a UDDI node which supports multiple 7248 versions, it is permissible for the node to return a field length longer than is specified in the v2 7249 specification. 7250

10.2.9 Schema Assessment 7251

The UDDI v3 specification mandates use of schema assessment. (See Section 6.1.1.1 7252 Processing By XML Schema Assessment.) It is RECOMMENDED that a multi-version registry 7253 perform schema assessment on earlier versioned APIs. It is further RECOMMENDED that a 7254 multi-version registry perform schema assessment according to the errata for XML Schema for 7255


228/405

conformance to RFC 3066 for the language type used by xml:lang (see 7256 http://www.w3.org/2001/05/xmlschema-errata#e2-25). 7257

10.2.10 White Space Handling 7258

The v3 specification mandates the usage of schema assessment with regard to the handling of 7259 white space, which differs slightly from the handling of white space in earlier versions. (See 7260 Section 6.1.1.1 Processing By XML Schema Assessment.) A multi-version node may return 7261 XML to an earlier versioned API with data that has been processed by v3 schema 7262 assessment. 7263

10.2.11 Mapping Between URLType and useType attribute on 7264

accessPoint 7265

The v3 specification no longer supports the attribute URLType on the accessPoint element. 7266 Rather, it uses the useType attribute. This necessitates a mapping between the values of the 7267 v2 URLType with the values of the v3 useType. 7268

If an entity is saved with the v3 namespace and a v2 inquiry is made, the URLType will be 7269 returned as “other”. In the case when a v3 inquiry is made on an entity published with the v2 7270 namespace, the v3 useType attribute will be returned as “endPoint”. 7271

10.2.12 Supporting External Value Set Providers Across Versions 7272

A situation may arise when there may be incongruent value sets of a checked taxonomy 7273 between two different versions. For example, the uddi:uddi.org:categorization:types taxonomy 7274 has new values in Version 3 that were not specified in Version 2. In such a situation, it is 7275 permissible for an inquiry API to return data that would be considered “invalid” given the valid 7276 values for that taxonomy. 7277

In the case of external value sets, the same schema version specified in a save_xx API call, 7278 whose categoryBag or identifierBag references an externally validated value set, is used by 7279 the node in the associated validate_values API call performed in order to complete the 7280 save_xx request. If the needed validate_values API is not available at the required schema 7281 version, then the save_xx request results in the error E_unsupported. In such cases, the error 7282 text clearly indicates the cause of the problem. 7283

10.2.13 Sorting and Matching Behavior 7284

The set of sorting and matching findQualifiers, as well as default sorting and matching 7285 behavior, for the Version 3 namespace has changed significantly. Please refer to the 7286 appropriate version-specific specifications for detailed explanations of sorting and matching 7287 semantics. 7288

10.2.14 XML Encoding 7289

Because UTF-16 is not supported in both UDDI Version 1 and 2, all response messages to 7290 UDDI Version 1 or 2 API calls are encoded in UTF-8. 7291

10.3 Data Migration Considerations 7292

10.3.1 Version 3 Schema Strictness 7293

In Version 3, the schema was changed to no longer allow “empty containers” – XML wrapper 7294 tags that stored no data. Version 3 enforces a minOccurs=1. This change requires that a 7295 migration of the data from v2 to v3 must prune any XML structures that were saved with such 7296 a structure. Without such pruning, it is possible that a v3 API call might return XML that is not 7297 valid according to the v3 schema. This would hold true for both structures within the find_xx 7298


229/405

API calls as well as structures within the get_xx and save_xx API calls. The following 7299 structures need to be taken into consideration during such a migration: 7300

• <addressLine> in <address> 7301

• <bindingTemplate> in <bindingTemplates> 7302

• <businessEntity> in <save_business> 7303

• <businessInfo> in <businessInfos> 7304

• <businessService> in <businessServices> 7305

• <contact> in <contacts> 7306

• <description> or <overviewURL> in <overviewDoc> 7307

• <findQualifier> in <findQualifiers> 7308

• <fromKey> or <tokey> in <keysOwned> 7309

• <instanceParms> or <overviewDoc> in <instanceDetails> 7310

• <keyedReference> or <keyedReferenceGroup> in <categoryBag> 7311

• <keyedReference> in <identifierBag> 7312

• <relatedBusinessInfo> in <relatedBusinessInfos> 7313

• <serviceInfo> in <serviceInfos> 7314

• <tModel> in <save_tModel> 7315

• <tModelInfo> in <tModelInfos> 7316

• <tModelInstanceInfo> in <tModelInstanceDetails> 7317

7318

Similarly, Version 3 introduces the notion of length validation – both minLength and maxLength 7319 -- within the schema. This change also affects data that is migrated from v2 to v3. The 7320 following elements now enforce such length validation: 7321

7322

• accessPoint37 7323

• addressLine 7324

• authInfo 7325

• description 7326

• discoveryURL 7327

• email 7328

• keyName 7329

• keyValue 7330

• name 7331

37

The Version 2 Schema requires the accessPoint field, but the schema does not enforce a minLength. However, Version 2 errata clarified this behavior and enforced through the specification that an accessPoint of minLength one is required. Therefore, migrating accessPoint between v2 and v3 is not an issue.


230/405

• personName38 7332

• phone 7333

• useType 7334

7335

When a client submits a value that exceeds the maxLength, the value will no longer be 7336 truncated by the node, but rather, the XML message will not pass validation. More importantly, 7337 in terms of the minLength requirement, if there are instances of v2 elements and attributes that 7338 are not of the required minLength, those v2 entities will need to be pruned, so that they will 7339 return XML that is valid according to the v3 schema. 7340

7341

Example: Consider the following valid XML file from a v2 registry: 7342

<businessDetail generic="2.0" operator="Microsoft UDDI Services" 7343 truncated="false" xmlns="urn:uddi-org:api_v2"> 7344 <businessEntity businessKey="176a3131-0c20-45d1-b31d-efb4f61b8b14" 7345 operator="sample" authorizedName="sample"> 7346 <discoveryURLs> 7347 <discoveryURL useType="businessEntity"> 7348 http://sample/uddipublic/discovery.ashx?businessKey=176a3131... 7349 </discoveryURL> 7350 </discoveryURLs> 7351 <name>sample</name> 7352 <description xml:lang="en" /> 7353 <contacts/> 7354 </businessEntity> 7355 </businessDetail> 7356

7357

In order to be compatible with a v3 registry, the v2 XML response would have to be migrated 7358 and returned as follows: 7359

<businessDetail generic="2.0" operator="Microsoft UDDI Services" 7360 truncated="false" xmlns="urn:uddi-org:api_v2"> 7361 <businessEntity businessKey="176a3131-0c20-45d1-b31d-efb4f61b8b14" 7362 operator="sample" authorizedName="sample"> 7363 <discoveryURLs> 7364 <discoveryURL useType="businessEntity"> 7365 http://sample/uddipublic/discovery.ashx?businessKey=176a3131... 7366 </discoveryURL> 7367 </discoveryURLs> 7368 <name>sample</name> 7369 </businessEntity> 7370 </businessDetail> 7371

7372

Note that the <description> element and the <contacts/> element have been pruned. 7373

10.4 Considerations of Version 2 Publish API Calls 7374

10.4.1 Data update semantics consistent with request namespace 7375

If a publisher saves data using a Version 3 API call and then attempts to update that data by 7376 performing a Version 2 save_xx API call and passing the identical key, the entity will not 7377 preserve any Version 3 data that is not part of the Version 2 entity. As is true with all save_xx 7378

38

The Version 2 Schema requires personName and the specification allows it to be minLength=0. This presents a problem during migration. There is not a normative way to handle this migration issue; nodes may handle this situation as they choose.


231/405

operations, a Version 2 save_xx operation performed on a Version 3 registry that supports it 7379 completely replaces the entity being saved. If the entity being replaced previously contained 7380 data not expressible in that prior version, it will no longer contain such data after a successful 7381 prior version save_xx operation. 7382

For example, if the Version 3 entity contained a signature and was then re-saved with a 7383 Version 2 call, the signature would be lost. This same principle holds true for Version 1 API 7384 calls. 7385

10.4.2 keyedReference data 7386

With Version 3, tModelKey elements MUST be specified for a keyedReference structure 7387 contained within Publish API requests. Requests to the Version 3 namespace containing 7388 keyedReference structures without tModelKey elements will fail schema validation and be 7389 rejected. 7390

When migrating Version 2 keyedReference data to a Version 3 node, publishers MUST 7391 construct tModelKey values for migrated data in a manner consistent with Section 10.1.4 7392 Mapping v1/v2 Canonical tModel Keys to v3 Evolved Keys. 7393

10.5 Value sets with entity keys as valid values 7394

There are value sets which use entity keys as valid values. Special handling of these values is 7395 necessary in a multi-version registry. They must be mapped as entity keys are everywhere 7396 else they are used. For example, if a V2 application saves a tModel that includes a 7397 keyedReference that uses the owningBusiness Value Set, the keyValue that will be used will 7398 be the V2 key of the appropriate businessEntity. If a V3 application retrieves this tModel then 7399 the keyValue returned MUST be the V3 key of the same businessEntity. See Section 11.1.9 7400 UDDI “Entity Key Values” Category System.7401

�� principal

�� ¶


232/405

7402

11 Utility tModels and Conventions 7403

To facilitate consistency in Service Description (tModel) registration, and to provide a 7404 framework for their basic organization within UDDI registries, a set of tModels has been 7405 established for UDDI. This section describes this set of tModels that facilitate registration of 7406 common information and the services provided by the UDDI registry itself. Registration of 7407 these tModels is MANDATORY for all UDDI registries. Implementation of these tModels 7408 depends on the type of tModel and on the structure of the registry. 7409

In addition to these “canonical” conventions and tModels, the UDDI Business Registry has 7410 established further conventions and tModels that registries MAY wish to adopt. See the UDDI 7411 Business Registry for additional useful tModel descriptions39. 7412

In the sections that follow a number of attributes are called out for each tModel described. 7413 These include the name of the tModel, the description of the tModel, its categorization(s), and 7414 its keys. Version 3 format keys are used when accessing a UDDI Version 3 registry using 7415 UDDI Version 3 APIs. When a node supports multiple versions of UDDI, Version 1 and 2 7416 format keys are used for the tModels when the Version 3 registry is accessed with a prior 7417 version API. 7418

There are two kinds of Version 1 and 2 format keys. There are those keys for tModels that are 7419 new in Version 3. The Version 1 and 2 format keys for these tModels can be derived 7420 algorithmically. See Section 10.1.1 Generating Keys From a Version 3 API Call for more 7421 information. tModels with this kind of V1 and V2 format key have the Derived V1, V2 Format 7422 Key attribute. tModels that existed in a prior version of UDDI have a V1 and V2 format key that 7423 is migrated following the algorithm described in Section 10.1.4 Mapping v1/v2 Canonical 7424 tModel Keys to v3 Evolved Keys. tModels with this kind of V1 and V2 format key have the 7425 Evolved V1, V2 Format Key attribute. 7426

11.1 Canonical Category Systems, Identifier Systems and 7427

Relationship Systems 7428

In UDDI, tModels are used to establish the existence of a variety of concepts and to point to 7429 their technical definitions. tModels that represent value sets such as category, identifier, and 7430 relationship systems are used to provide additional data to the UDDI core entities to facilitate 7431 discovery along a number of dimensions. This additional data is captured in keyedReferences 7432 that reside in categoryBags, identifierBags, or publisherAssertions. The tModelKey attributes 7433 in these keyedReferences refer to the value set that related to the concept or namespace 7434 being represented. The keyValues contain the actual values from that value set. In some 7435 cases keyNames are significant, such as for describing relationships and when using the 7436 general keywords value set. In all other cases, however, keyNames are used to provide a 7437 human readable version of what is in the keyValue. 7438

tModels related to value sets can be checked or unchecked. keyValue references to 7439 unchecked value sets are never validated. Their use is unrestricted. keyValue references to 7440 checked value sets are either rejected out of hand (when the UDDI node does not support the 7441 referenced checked value set) or validated. Validation can occur internally by a node or by 7442 invoking an external validation Web service. 7443

39 Some of the tModels that appeared in prior versions of the UDDI specification are not considered normative and are therefore not part of this specification. The UDDI Business Registry, however, continues to support these tModels.

�� 2


233/405

tModels related to value sets can also be placed out of service by marking them unvalidatable. 7444 When a new reference to a tModel that is marked unvalidatable is encountered, the reference 7445 is automatically rejected. 7446

Registration of and support for the tModels that follow are MANDATORY for all UDDI 7447 registries. In addition to these tModels, the UDDI Business Registry has defined a number of 7448 common value sets, for example the NAICS and UNSPSC category systems, that UDDI 7449 registries MAY support. These are described in the overviewURLs for the UDDI Business 7450 Registry tModels. 7451

11.1.1 UDDI Types Category System 7452

11.1.1.1 Introduction 7453

To distinguish among various types of concept, UDDI has established the Types category 7454 system. Publishers should categorize the tModels they publish using values from uddi-7455 org:types to make them easy to find. The approach to categorization of tModels within the 7456 UDDI Type Category system is consistent with that used for categorizing other entities using 7457 other category systems. The categorization information for each tModel is added to the 7458 <categoryBag> elements in a save_tModel API. One or more <keyedReference> elements 7459 are added to the category bag to indicate the types of the tModel that is being registered. See 7460 Appendix F Using Categorization for more information. 7461

11.1.1.2 Design Goals 7462

The goal of the UDDI Types category system is to establish an unambiguous, simple UDDI-7463 compatible category system that distinguishes the kinds of concepts that tModels can 7464 represent. 7465

11.1.1.3 tModel Definition 7466

Name: uddi-org:types

Description: UDDI Type Category System

UDDI Key (V3): uddi:uddi.org:categorization:types

Evolved V1,V2 format key: uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4

Categorization: categorization

Checked: Yes

11.1.1.3.1 tModel Structure 7468

This tModel is represented with the following structure: 7469

<tModel tModelKey=”uddi:uddi.org:categorization:types”> 7470 <name>uddi-org:types</name> 7471 <description>UDDI Type Category System</description> 7472 <overviewDoc> 7473 <overviewURL useType=”text”> 7474 http://uddi.org/pubs/uddi_v3.htm#UDDITypes 7475 </overviewURL> 7476 </overviewDoc> 7477 <categoryBag> 7478 <keyedReference keyName=”uddi-org:types:categorization” 7479 keyValue="categorization" 7480 tModelKey="uddi:uddi.org:categorization:types”/> 7481 <keyedReference keyName=”uddi-org:types:checked” 7482 keyValue="checked" 7483

�� Name: uddi-org:types¶

Description: UDDI Type Category System¶UDDI Key (V3):

uddi:uddi.org:categorization:types¶Evolved V1,V2 format key: uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4¶Categorization: categorization¶Checked: Yes ¶


234/405

tModelKey="uddi:uddi.org:categorization:types”/> 7484 <keyedReference keyName=”uddi-org:types:cacheable” 7485 keyValue="cacheable" 7486 tModelKey="uddi:uddi.org:categorization:types”/> 7487 </categoryBag> 7488 </tModel> 7489 7490

11.1.1.4 Valid Values 7491

Checking of references to this value set consists of ensuring that the keyValues are from the 7492 set of categories listed below. No contextual checks are performed. 7493

The following constitute the value set for this category system. The valid values are those 7494 categories marked as being "allowed". These values are used in the keyValue attributes of 7495 keyedReference elements that are contained in categoryBag elements. 7496

7497

ID Parent ID Allowed Description

tModel No These types are used for tModels

valueSet tModel Yes Value set

identifier valueSet Yes Identifier system

namespace valueSet Yes Namespace

categorization valueSet Yes Categorization system

postalAddress categorization Yes Postal address system

categorizationGroup tModel Yes Category group system

relationship tModel Yes Relationship type system

specification tModel Yes Specification for a Web service

xmlSpec specification Yes Specification for a Web service using XML messages

soapSpec xmlSpec Yes Specification for interaction with a Web service using SOAP messages

wsdlSpec specification Yes Specification for a Web service described in WSDL

protocol tModel Yes Protocol

transport protocol Yes Wire/transport protocol

signatureComponent tModel Yes Signature component

unvalidatable tModel Yes Prevents a checked value set from being used

checked tModel Yes Checked value set

unchecked tModel Yes Unchecked value set

cacheable tModel Yes Cacheable checked value set

uncacheable tModel Yes Uncacheable checked value set

keyGenerator tModel Yes Key generator

findQualifier tModel Yes Find qualifier


235/405

ID Parent ID Allowed Description

sortOrder findQualifier Yes Sort order

useTypeDesignator tModel Yes Designates a kind of usage for the pieces of data with which it is associated

bindingTemplate No These types are used for bindingTemplates

wsdlDeployment bindingTemplate Yes bindingTemplate represents the WSDL deployment of a Web service

7498

• tModel: The UDDI type category system is structured to allow for categorization of 7499 registry entries other than tModels. This key is the root of the branch of the category 7500 system that is intended for use in categorization of tModels within the UDDI registry. 7501 Categorization is not allowed with this key. 7502

• valueSet: A valueSet is the parent branch for the identifier, namespace, and 7503 categorization values in this category system. A tModel categorized with this value 7504 indicates it can be referenced by some other value set tModel to indicate redefinition 7505 of purpose, derivation, extension or equivalence. 7506

• identifier: An identifier tModel represents a specific set of values used to uniquely 7507 identify information. Identifier tModels are intended to be used in keyedReferences 7508 inside of identifierBags. For example, a Dun & Bradstreet D-U-N-S® Number uniquely 7509 identifies companies globally. The D-U-N-S® Number system is an identifier system. 7510

• namespace: A namespace tModel represents a scoping constraint or domain for a set 7511 of information. In contrast to an identifier, a namespace does not have a predefined 7512 set of values within the domain, but acts to avoid collisions. It is similar to the 7513 namespace functionality used for XML. For example, the uddi-org:relationships 7514 tModel, which is used to assert relationships between businessEntity elements, is a 7515 namespace tModel. 7516

• categorization: A categorization tModel is used for category systems within the UDDI 7517 registry. NAICS and UNSPSC are examples of categorization tModels. 7518

• postalAddress: A postalAddress tModel is used to identify different forms of postal 7519 address within the UDDI registry. postalAddress tModels may be used with the 7520 address element to distinguish different forms of postal address. 7521

• categorizationGroup: A categorizationGroup tModel is used to relate one or more 7522 category system tModels to one another so that they can be used in 7523 keyedReferenceGroups. 7524

• relationship: A relationship tModel is used for relationship categorizations within the 7525 UDDI registry. relationship tModels are typically used in connection with publisher 7526 relationship assertions. 7527

• specification: A specification tModel is used for tModels that define interactions with a 7528 Web service. These interactions typically include the definition of the set of requests 7529 and responses, or other types of interaction that are prescribed by the Web service. 7530 tModels describing XML, COM, CORBA, or any other Web services are specification 7531 tModels. 7532

• xmlSpec: An xmlSpec tModel is a refinement of the specification tModel type. It is 7533 used to indicate that the interaction with the Web service is via XML. The UDDI API 7534 tModels are xmlSpec tModels. 7535


236/405

• soapSpec: Further refining the xmlSpec tModel type, a soapSpec is used to indicate 7536 that the interaction with the Web service is via SOAP. The UDDI API tModels are 7537 soapSpec tModels, in addition to xmlSpec tModels. 7538

• wsdlSpec: A tModel for a Web service described using WSDL is categorized as a 7539 wsdlSpec. 7540

• protocol: A tModel describing a protocol of any sort. 7541

• transport: A transport tModel is a specific type of protocol. HTTP, FTP, and SMTP are 7542 types of transport tModels. 7543

• signatureComponent: A signature component is used to for cases where a single 7544 tModel can not represent a complete specification for a Web service. This is the case 7545 for specifications like RosettaNet, where implementation requires the composition of 7546 three tModels to be complete - a general tModel indicating RNIF, one for the specific 7547 PIP, and one for the error handling services. Each of these tModels would be of type 7548 signature component, in addition to any others as appropriate. 7549

• unvalidatable: Used to mark a categorization or identifier tModel as unavailable for 7550 use by keyedReferences. A value set provider may mark its value set tModel 7551 unvalidatable if it wants to temporarily disallow its use. See Section 6.4 Checked 7552 Value Set Validation for more information. 7553

• checked: Marking a tModel with this categorization asserts that it represents a value 7554 set or category group system whose use, through keyedReferences, may be 7555 checked. Registry, and possibly node policy determines when and how a checked 7556 value set is supported. 7557

• unchecked: Marking a tModel with this categorization asserts that it represents a 7558 value set or category group system whose use, through keyedReferences, is not 7559 checked. 7560

• cacheable: Marking a tModel with this categorization asserts that it represents a 7561 checked value set or category group system whose values may be cached for 7562 validation. The validation algorithm for a supported cacheable checked value set or 7563 category group system must rely solely upon matching references against the cached 7564 set of values. 7565

• uncacheable: Marking a tModel with this categorization asserts that it represents a 7566 checked value set or category group system whose values must not be cached for 7567 validation. The validation algorithm for a supported uncacheable checked value set 7568 must be specified and associated with the tModel marked with this categorization and 7569 may consider contextual criteria involving the entity associated with the reference. 7570

• keyGenerator: Marking a tModel with this categorization designates it as one whose 7571 tModelKey identifies a key generator partition that can be used by its owner to derive 7572 and assign other entity keys. 7573

• findQualifier: A findQualifier tModel is used as the value of a findQualifier element to 7574 indicate the type of processing to occur for the inquiry function in which it is included. 7575

• sortOrder: A sort order tModel defines a collation sequence that can be used during 7576 inquiries to control ordering of the results. 7577

• useTypeDesignator: A useTypeDesignator tModel is used to describe the way a piece 7578 of data should be interpreted. It is frequently used to extend the space of resource 7579 types found at a URI, such as access points, overview URLs, and discovery URLs. 7580 UDDI designates a set of common use types as simple strings; tModels of the 7581 useTypeDesignator type are used to describe others. 7582


237/405

• bindingTemplate: This key is the root of the branch of the category system that is 7583 intended for use in categorization of bindingTemplates within the UDDI registry. 7584 Categorization is not allowed with this key. 7585

• wsdlDeployment: A bindingTemplate categorized as a wsdlDeployment contains 7586 within its accessPoint the endpoint for a WSDL deployment document. 7587

7588

11.1.1.5 Example of Use 7589

The following demonstrates how to categorize a tModel as representing a checked value set. 7590 The UDDI approximateMatch findQualifier tModel, for example, is categorized this way. 7591

<tModel 7592 tModelKey=”uddi:uddi.org:findqualifier:approximatematch”> 7593 … 7594 <categoryBag> 7595 <keyedRef er ence keyName=” uddi - or g: t ypes: cat egor i zat i on” 7596 keyVal ue=" f i ndQual i f i er " 7597 t Model Key=" uddi : uddi . or g: cat egor i zat i on: t ypes” / > 7598 </categoryBag> 7599 </tModel> 7600 7601

11.1.2 General Keyword Category System 7602


Usually, category systems in UDDI are defined by registering a new tModel to represent the 7604 value set, but sometimes such formality is unnecessary. The UDDI General Keywords 7605 Category System provides a way of informally defining any number of unchecked value sets, 7606 each consisting of a namespace identifier and an associated set of category values. See 7607 Appendix F Using Categorization for more information. 7608


Provide a simple, lightweight means for establishing and using unchecked UDDI category 7610 systems. Such value sets are generally fairly simple and often of interest only to a small 7611 number of people. Checked value sets must, and complex or broadly interesting value sets 7612 should be defined by registering a new tModel, which is the formal means of documenting the 7613 meaning and intended use of a value set. 7614


Name: uddi-org:general_keywords

Description: Category system consisting of namespace identifiers and the keywords associated with the namespaces

UDDI Key (V3): uddi:uddi.org:categorization:general_keywords

Evolved V1,V2 format key: uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4


Checked: Yes



�� findQualifier:approxi

mateMatch

�� Name: uddi-

org:general_keywords¶Description: Category system consisting of namespace identifiers and the keywords associated with the namespaces¶UDDI Key (V3):

uddi:uddi.org:categorization:general_keywords¶Evolved V1,V2 format key: uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4¶Categorization: categorization¶Checked: Yes ¶

��

¶


238/405

<tModel tModelKey=”uddi:uddi.org:categorization:general_keywords”> 7619 <name>uddi-org:general_keywords</name> 7620 <description>Category system consisting of namespace 7621 identifiers and the keywords associated with 7622 the namespaces. 7623 </description> 7624 <overviewDoc> 7625 <overviewURL useType=”text”> 7626 http://uddi.org/pubs/uddi_v3.htm#GenKW 7627 </overviewURL> 7628 </overviewDoc> 7629 <categoryBag> 7630 <keyedReference keyName=”uddi-org:types:categorization” 7631 keyValue="categorization" 7632 tModelKey="uddi:uddi.org:categorization:types”/> 7633 <keyedReference keyName=”uddi-org:types:checked” 7634 keyValue="checked" 7635 tModelKey="uddi:uddi.org:categorization:types”/> 7636 </categoryBag> 7637 </tModel> 7638

7639


The general_keywords category system in UDDI behaves differently than do any of the other 7641 category systems. Like other category systems, the general_keyword category system is used 7642 in keyedReference elements to categorize the entities. Unlike other category systems, in the 7643 general_keyword category system both the keyName and the keyValue attributes of 7644 keyedReference elements are semantically meaningful and are required. The keyName 7645 identifies a particular value set and the keyValue specifies the value within that value set. With 7646 other category systems, the keyName plays no semantic role -- it is essentially commentary. 7647 This difference is reflected in the UDDI inquiry APIs: When a keyedReference containing a 7648 reference to the general_keywords category system appears in an inquiry, the keyNames are 7649 used. 7650

Although UDDI requires only that keyName attributes be specified when used with the 7651 general_keywords, such keyNames SHOULD be URNs -- with what the W3C calls "an 7652 institutional commitment to persistence" -- in a domain name space you own. Following this 7653 convention will help avoid name collisions. 7654

UDDI places no limitations on the value of keyValue attributes for keyedReferences that 7655 reference this tModel. 7656

Checking for this category system consists of ensuring that keyName is not omitted or 7657 specified as the zero-length string; UDDI registries MUST fail save operations that contain 7658 keyedReferences that involve uddi-org:general_keywords and that do not specify a non-empty 7659 keyName. 7660


In The Analytical Language of John Wilkins (translated from the Spanish El idioma analítico de 7662 John Wilkins by Lilia Graciela Vázquez; edited by Jan Frederik Solem with assistance from 7663 Bjørn Are Davidsen and Rolf Andersen) Jorge Luis Borges discusses the problems inherent to 7664 any system of classification. The "ambiguities, redundancies and deficiencies remind us of 7665 those which doctor Franz Kuhn attributes to a certain Chinese encyclopedia entitled Celestial 7666 Empire of Benevolent Knowledge. In its remote pages it is written that the animals are divided 7667 into: (a) belonging to the emperor, (b) embalmed, (c) tame, (d) sucking pigs, (e) sirens, (f) 7668 fabulous, (g) stray dogs, (h) included in the present classification, (i) frenzied, (j) innumerable, 7669 (k) drawn with a very fine camelhair brush, (l) et cetera, (m) having just broken the water 7670 pitcher, (n) that from a long way off look like flies." 7671

�� un

�� un


239/405

While this taxonomy has been widely referred to, it turns out that Borges probably made the 7672 whole thing up. Legitimate or bogus, the taxonomy certainly makes his point: "[I]t is clear that 7673 there is no classification of the Universe not being arbitrary and full of conjectures." 7674

For some unknowable reason, Island Trading (islandtrading.example, a completely fictitious 7675 outfit) is organized internally using this category system, one division per category. (Division 7676 "m" is very small.) It wishes to categorize the business services it offers according to the 7677 division that offers it, and it wants to use the Celestial Empire taxonomy to do so. Since the 7678 category is only of interest to Island Trading, it is decided that the general_keyword approach 7679 will be used. "islandtrading.example:categorization:animals" is chosen to represent the 7680 taxonomy. This is the URN that is placed into the keyName attributes of keyedReferences that 7681 refer to this taxonomy. The Tame Division and the Fabulous Division both have catalog 7682 browsing business services. They appear as follows: 7683

<businessServices> 7684 <businessService> 7685 <name>Island Trading Tame Animal Catalog Service</name> 7686 <description xml:lang="en"> 7687 Search our Tame animals catalog on line 7688 </description> 7689 <bindingTemplates> 7690 <bindingTemplate> 7691 <accessPoint useType="endpoint"> 7692 https://islandtrading.example/tame/catalog.html 7693 </accessPoint> 7694 <tModelInstanceDetails> 7695 <tModelInstanceInfo 7696 tModelKey="uddi:uddi.org:ubr:transport:http"> 7697 </tModelInstanceInfo> 7698 </tModelInstanceDetails> 7699 </bindingTemplate> 7700 </bindingTemplates> 7701 <categoryBag> 7702 <keyedReference 7703 tModelKey="uddi:uddi.org:categorization:general_keywords" 7704 keyName="islandtrading.example:categorization:animals" 7705 keyValue="c"/> 7706 <keyedReference 7707 tModelKey="uddi:uddi.org:ubr:categorization:unspsc" 7708 keyName="UNSPSC: Livestock" keyValue="101015"/> 7709 </categoryBag> 7710 </businessService> 7711 <businessService> 7712 <name> 7713 Celestial Animals Fabulous Animal Books Catalog Service 7714 </name> 7715 <description xml:lang="en"> 7716 Search our tame animals catalog on line 7717 </description> 7718 <bindingTemplates> 7719 <bindingTemplate> 7720 <accessPoint content="endpoint"> 7721 https://islandtrading.example/fabulous/catalog.html 7722 </accessPoint> 7723 <tModelInstanceDetails> 7724 <tModelInstanceInfo 7725 tModelKey="uddi:uddi.org:ubr:transport:http"> 7726 </tModelInstanceInfo> 7727 </tModelInstanceDetails> 7728 </bindingTemplate> 7729 </bindingTemplates> 7730 <categoryBag> 7731 <keyedReference 7732 tModelKey="uddi:uddi.org:categorization:general_keywords" 7733 keyName="islandtrading.example:categorization:animals" 7734 keyValue="f"/> 7735 <keyedReference 7736 tModelKey="uddi:uddi.org:ubr:categorization:unspsc" 7737

�� ubr.

�� ubr.

�� ubr.

�� ubr.

�� UNSPSC


240/405

keyName="unspsc-org:UNSPSC: Picture or drawing or 7738 coloring books for children" 7739 keyValue="55-10-15-07"/> 7740 </categoryBag> 7741 </businessService> 7742 </businessServices> 7743 7744 7745

11.1.3 UDDI Nodes Category System 7746


UDDI provides a mechanism that may be used by publishers to categorize businessEntity and 7748 tModel elements according to any number of category systems and by inquirers to discover 7749 entities so categorized. See Appendix F Using Categorization for more information. 7750

This section defines a tModel used to categorize a businessEntity as representing a UDDI 7751 node in the registry in which the businessEntity appears. See Section 6.2.2.1 Normative 7752 Modeling of Node Business Entity. 7753


Each UDDI registry can be comprised of a number of nodes. Each UDDI node has a special 7755 businessEntity associated with it, called its Node Business Entity. The businessService 7756 elements in this businessEntity represent Web services that relate to the node's role in the 7757 UDDI registry. 7758

The uddi-org:nodes category system is designed to allow reliable discovery of the Node 7759 Business Entity structures for nodes in a UDDI registry so that UDDI clients can locate the 7760 businessService structures associated with the operation of the registry. 7761


Name: uddi-org:nodes

Description: Category system for identifying nodes of a registry

UDDI Key (V3): uddi:uddi.org:categorization:nodes

Evolved V1,V2 format key: uuid:327A56F0-3299-4461-BC23-5CD513E95C55


Checked: Yes



<tModel tModelKey=”uddi:uddi.org:categorization:nodes”> 7766 <name>uddi-org:nodes</name> 7767 <description>Category system for identifying the nodes 7768 of a registry. 7769 </description> 7770 <overviewDoc> 7771 <overviewURL useType=”text”> 7772 http://uddi.org/pubs/uddi_v3.htm#Nodes 7773 </overviewURL> 7774 </overviewDoc> 7775 <categoryBag> 7776 <keyedReference keyName=”uddi-org:types:categorization” 7777 keyValue="categorization" 7778

�� Name: uddi-org:nodes¶

Description: Category system for identifying nodes of a registry¶UDDI Key (V3):

uddi:uddi.org:catgorization:nodes¶Evolved V1, V2 format key: uuid:327A56F0-3299-4461-BC23-5CD513E95C55¶Categorization: categorization¶Checked: Yes ¶

��

¶

241/405

tModelKey="uddi:uddi.org:categorization:types”/> 7779 <keyedReference keyName=”uddi-org:types:checked” 7780 keyValue="checked" 7781 tModelKey="uddi:uddi.org:categorization:types”/> 7782 <keyedReference keyName=”uddi-org:types:uncacheable” 7783 keyValue="uncacheable" 7784 tModelKey="uddi:uddi.org:categorization:types”/> 7785 </categoryBag> 7786 </tModel> 7787 7788 7789


Checking of references to this value set consists of ensuring that the publisher is the UDDI 7791 node and the keyValue has the value “node”. Each node allows the use of uddi-org:nodes 7792 only by itself, only on its own Node Business Entity, and only with the value of “node”. This 7793 value is used in the keyValue attributes of keyedReference elements that are contained in 7794 categoryBag elements to locate the Node Business Entity elements in the registry. 7795


Consolidated Holdings (consolidatedholdings.example, a fictitious company) has become a 7797 node in a UDDI registry. As it sets itself up, it categorizes its Node Business Entity with the 7798 uddi:-org:nodes category system in the following way: 7799

<businessEntity businessKey="uddi:consolidatedholdings.example" 7800 ... 7801 <categoryBag> 7802  7803 <keyedReference keyName="uddi-org:nodes:Consolidated Holdings" 7804 keyValue="node" 7805 tModelKey="uddi:uddi.org:categorization:nodes"/> 7806 </categoryBag> 7807 ... 7808 </businessEntity> 7809 7810


242/405

7811

11.1.4 UDDI Relationships System 7812


UDDI provides a mechanism that may be used by publishers to assert relationships between 7814 businessEntity structures they publish and other businessEntity structures according to any 7815 number of relationship type schemes. See Appendix A Relationships and Publisher Assertions 7816 for more information. This section defines a tModel representing a relationship type system for 7817 use in describing the way businessEntity structures relate to one another. 7818


While UDDI provides for any number of relationship type system to be used in relating 7820 businessEntity structures to one another, it is useful to define a "starter set" of relationship 7821 types that publishers may use without needing to define their own. The uddi-org:relationships 7822 relationship type system is such a starter set that covers a number of basic relationships. All 7823 three attributes are significant in keyedReferences that describe relationship types. The 7824 keyValue attributes should contain well known but somewhat broad versions of the relationship 7825 type, like those described in this relationship type set. The keyName attributes should be used 7826 to more explicitly type the relationship. 7827


Name: uddi-org:relationships

Description: Basic types of businessEntity relationships

UDDI Key (V3): uddi:uddi.org:relationships

Evolved V1,V2 format key: uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03

Categorization: relationship

Checked: No

7830



<tModel tModelKey=”uddi:uddi.org:relationships”> 7833 <name>uddi-org:relationships</name> 7834 <description>Basic types of business relationships 7835 </description> 7836 <overviewDoc> 7837 <overviewURL useType=”text”> 7838 http://uddi.org/pubs/uddi_v3.htm#Relationships 7839 </overviewURL> 7840 </overviewDoc> 7841 <categoryBag> 7842 <keyedReference keyName=”uddi-org:types:categorization” 7843 keyValue="categorization" 7844 tModelKey="uddi:uddi.org:categorization:types”/> 7845 <keyedReference keyName=”uddi-org:types:unchecked” 7846 keyValue="unchecked" 7847 tModelKey="uddi:uddi.org:categorization:types”/> 7848 </categoryBag> 7849 </tModel> 7850 7851

�� Name: uddi-

org:relationships¶Description: Basic types of businessEntity relationships¶UDDI Key (V3):

uddi:uddi.org:relationships¶Evolved V1, V2 format key: uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03¶Categorization: relationship¶Checked: No¶

243/405

7852


The following constitute the value set for this relationship type system. The valid values are 7854 those types marked as being allowed. These values are used in the keyValue attributes of 7855 keyedReferences that are associated with publisherAssertions. The keyName attributes are 7856 also significant when used in publisherAssertions and can be used to more explicitly describe 7857 the relationship. 7858

7859

ID ParentID Allowed Description

Relationship No The root of the relationships type system.

peer-peer Relationship Yes Indicates that the two businessEntity structures are related as peers.

parent-child Relationship Yes Indicates that the businessEntity referred to by the fromKey is in some sense the parent of the businessEntity referred to by the toKey.

identity Relationship Yes Indicates that the businessEntity referred to by the fromKey represents the same business or organization as the businessEntity referred to by the toKey.

7860


Tokyo Traders has a subsidiary, Chiba Traders, and wishes to assert that Chiba Traders is, 7862 indeed, its subsidiary. It wishes to use the uddi-org:relationships type system to assert that the 7863 businessEntity for Tokyo Traders is related via a parent-child subsidiary relationship to Chiba 7864 Traders. To do so it sends an add_publisherAssertions API to the node at which it published its 7865 businessEntity. The new assertion contained in the API looks as follows: 7866

<publisherAssertion> 7867  7868 <fromKey> 7869 uddi:tokyotraders.example:business 7870 </fromKey> 7871  7872 <toKey> 7873 uddi:chibatraders.example:business 7874 </toKey> 7875  7876 <keyedReference keyName="subsidiary" 7877 keyValue="parent-child" 7878 tModelKey="uddi:uddi.org:relationships"/> 7879 </publisherAssertion> 7880 7881

In the example above, the keyName is used to qualify the parent-child relationship. 7882

Once Tokyo Traders has added this assertion and Chiba Traders has done the same, a 7883 relationship is formed. The find_relatedBusinesses API may then be used to, for example, find 7884 Tokyo Traders' subsidiaries. The result would include Chiba Traders. 7885

Note: A relationship between two businessEntity structures will be formed using the 7886 publisherAssertion mechanism only if the publisher of each of the businessEntity structures 7887


244/405

involved asserts an identical publisherAssertion. In particular, this means that the 7888 keyedReferences must match exactly on keyName, keyValue, and tModelKey. 7889

11.1.5 UDDI “Owning Business” Category System 7890

The owningBusiness tModel represents a category system that may be used to locate the 7891 businessEntity associated with the publisher of a tModel. 7892


It is often desirable to be able to discover the business entity that represents the publisher of a 7894 given tModel. When choosing among similar Web service definitions, for example, it is useful 7895 to be able to determine that one of them is published by a known organization. For most UDDI 7896 entities this can be deduced by inspecting the containment hierarchy of the entity to its root 7897 businessEntity. For tModels, the UDDI owningBusiness category system fills this need by 7898 allowing tModels to point to the businessEntity of their publisher. 7899


Name: uddi-org:owningBusiness

Description: Category system used to point to the businessEntity associated with the publisher of the tModel

UDDI Key (V3): uddi:uddi.org:categorization:owningbusiness

Evolved V1,V2 format key: uuid:4064c064-6d14-4f35-8953-9652106476a9


Checked: Yes

7902



<tModel tModelKey=”uddi:uddi.org:categorization:owningbusiness”> 7905 <name>uddi-org:owningBusiness_v3</name> 7906 <description>Category system used to point to the businessEntity 7907 associated with the publisher of the tModel. 7908 </description> 7909 <overviewDoc> 7910 <overviewURL useType=”text”> 7911 http://uddi.org/pubs/uddi_v3.htm#owningBusiness 7912 </overviewURL> 7913 </overviewDoc> 7914 <categoryBag> 7915 <keyedReference keyName=”uddi-org:types:categorization” 7916 keyValue="categorization" 7917 tModelKey="uddi:uddi.org:categorization:types”/> 7918 <keyedReference keyName=”uddi-org:types:checked” 7919 keyValue="checked" 7920 tModelKey="uddi:uddi.org:categorization:types”/> 7921 <keyedReference keyName=”uddi-org:types:uncacheable” 7922 keyValue="uncacheable" 7923 tModelKey="uddi:uddi.org:categorization:types”/> 7924 <keyedReference keyName=”entityKeyValues” 7925 keyValue="businessKey" 7926 tModelKey="uddi:uddi.org:categorization:entitykeyvalues”/> 7927 </categoryBag> 7928 </tModel> 7929

�� owningBusiness

�� This version of the

owningBusiness category system replaces the prior version of this category system by providing a means for referring to businesses that have version 3 format keys.��

who��

entity is. ��

web��

��

��

¶The owningBusiness category system exists in prior versions of UDDI. keyedReferences that refer to this original owningBusiness category system contain businessKeys for version 1 and 2 businessEntity elements, expressed in the format of these versions of UDDI (as a UUID with no scheme prefix). When accessed using a prior version API in a multi-version registry, the older owningBusiness category system yields valid references to businessEntity elements that are in the format of the prior version, and thus remain valid. When viewed ��

Name: uddi-org:owningBusiness_v3¶��

owningBusiness”>��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

� � � � ��

� � � � ��

� � � � ��


245/405

7930


The value set of this value set is the set of businessKeys. The content of keyValue in 7932 keyedReferences that refers to this tModel must be a businessKey. The keyValue is used to 7933 specify that the businessEntity whose businessKey is the keyValue in a keyedReference 7934 "owns" the tagged tModel. The entity tagged must be a tModel, the referred-to businessEntity 7935 must exist, and it must have been published by the same publisher. 7936


The My API specification was published by some business. To indicate that this is so, the My 7938 API specification tModel has a keyedReference in its categoryBag that uses uddi-7939 org:owningBusiness to point to the some business businessEntity. 7940

<tModel tModelKey="uddi:some.business.example:myapispecification"> 7941 <name>some-business-example:MyAPI</name> 7942 <categoryBag> 7943 <keyedReference keyName="owningBusiness:someBusiness" 7944 keyValue="uddi:some.business.example:business" 7945 tModelKey="uddi:uddi.org:categorization:owningbusiness"/> 7946 </categoryBag> 7947 ... 7948 </tModel> 7949 7950

In this example, the keyName field serves to help readability but has no further meaning. 7951

11.1.6 UDDI “Is Replaced By” Identifier System 7952

UDDI provides a mechanism that may be used by publishers to tag their businessEntities and 7953 tModels with information that identifies them according to any number of identification systems. 7954 This tModel represents an identifier system that may be used to identify the tModel or 7955 businessEntity that logically replaces the tModel or businessEntity in which it is used. This 7956 version of the isReplacedBy identifier system replaces the prior version of this identifier system 7957 by providing a means for referring to replacement entities that have version 3 format keys. 7958


It is often desirable to gracefully retire a tModel in favor of a replacement. For example, when a 7960 Web service definition is replaced by an incompatible version, the publisher of the specification 7961 may wish to leave the tModel for the existing definition in place so that existing uses will not be 7962 disturbed, while at the same time making it clear that there is a replacement available. The 7963 UDDI isReplacedBy identifier system, coupled with the behavior of UDDI with respect to 7964 obsolete tModels, fills this need by allowing the obsolete tModel to point to its replacement. 7965 See Section 5.2.11 delete_tModel. 7966

The isReplacedBy identifier system exists in prior versions of UDDI. keyedReferences that 7967 refer to this original isReplacedBy identifier system contain entity keys in the version 1 and 2 7968 formats (as UUIDs with the uuid or no scheme prefix). When accessed using a prior version 7969 API in a multi-version registry, the older isReplacedBy identifier system yields valid references 7970 to businessEntity or tModel keys that are in the format of the prior version, and thus remain 7971 valid. When viewed using the version 3 UDDI API these same references to the earlier 7972 isReplacedBy identifier system contain invalid version 3 format keys. A new version of this 7973 identifier system is required to be able to reference the set of values defined by version 3 7974 format keys. 7975


Name: uddi-org:isReplacedBy

�� version 3 format

�� that publishes the tagged

information

�� business

�� myAPISpecification

��

��

��

��

��

�� owningBusiness

��

��

�� isReplacedBy

�� ,

�� deleting

�� obsolescent

��

��

�� Name: uddi-

org:isReplacedBy¶Description: An identifier system used to point to the entity, using UDDI keys, that is the logical replacement for the one in which isReplacedBy is used. ¶UDDI Key (V3):

uddi:uddi.org:identifier:isReplacedBy¶Derived V1, V2 format key: uuid:54AF30AE-9B61-385C-9D1D-AB572E72BFF2¶Categorization: identifier¶Checked: Yes ¶


246/405

Description: An identifier system used to point to the entity, using UDDI keys, that is the logical replacement for the one in which isReplacedBy is used.

UDDI Key (V3): uddi:uddi.org:identifier:isreplacedby

Evolved V1,V2 format key: uuid:e59ae320-77a5-11d5-b898-0004ac49cc1e

Categorization: identifier

Checked: Yes



<tModel tModelKey=”uddi:uddi.org:identifier:isreplacedby”> 7980 <name>uddi-org:isReplacedBy</name> 7981 <description>Identifier system used to point to the UDDI entity, 7982 using UDDI keys, that is the logical replacement 7983 for the one in which isReplacedBy is used. 7984 </description> 7985 <overviewDoc> 7986 <overviewURL useType=”text”> 7987 http://uddi.org/pubs/uddi_v3.htm#IsReplacedBy 7988 </overviewURL> 7989 </overviewDoc> 7990 <categoryBag> 7991 <keyedReference keyName=”uddi-org:types:identifier” 7992 keyValue="identifier" 7993 tModelKey="uddi:uddi.org:categorization:types”/> 7994 <keyedReference keyName=”uddi-org:types:checked” 7995 keyValue="checked" 7996 tModelKey="uddi:uddi.org:categorization:types”/> 7997 <keyedReference keyName=”uddi-org:types:uncacheable” 7998 keyValue="uncacheable" 7999 tModelKey="uddi:uddi.org:categorization:types”/> 8000 <keyedReference keyName=”entityKeyValues” 8001 keyValue="businessKey" 8002 tModelKey="uddi:uddi.org:categorization:entitykeyvalues”/> 8003 <keyedReference keyName=”entityKeyValues” 8004 keyValue="tModelKey" 8005 tModelKey="uddi:uddi.org:categorization:entitykeyvalues”/> 8006 </categoryBag> 8007 </tModel> 8008 8009 8010


The keyValues in keyedReferences that refer to this tModel must be tModelKeys or 8012 businessKeys. Such a keyValue specifies the entity that is the replacement for the entity in 8013 which the keyedReference appears. The above and further validation requirements are as 8014 follows: 8015

a. In the case where a reference is made from an obsolete business entity the following 8016 validation rules apply: 8017

1. reference to a new business entity; this is a valid operation 8018

2. reference to self; this is invalid 8019

3. reference to a service, binding or tModel; this is an invalid operation given that the 8020 entity being pointed to must be a business 8021

�� isReplacedBy”>

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

</categoryBag></tModel>

247/405

4. reference to another publisher’s business; this is a valid operation; no ownership 8022 check is made 8023

5. reference to another publisher’s service, binding or tModel; this is an invalid 8024 operation because of a.3 above 8025

6. reference to invalid keys; this is an invalid operation; a key must be valid. 8026

b. In the case where a reference is made from an obsolete tModel the following 8027 validation rules apply: 8028

1. reference to a new tModel; this is a valid operation 8029

2. reference to self; this is invalid 8030

3. reference to a service, binding or business; this is an invalid operation given that 8031 the entity being pointed to must be a tModel 8032

4. reference to another publisher’s tModel; this is a valid operation; no ownership 8033 check is made 8034

5. reference to another publisher’s service, binding or business; this is an invalid 8035 operation because of b.3 above 8036

6. reference to invalid keys; this is an invalid operation; a key must be valid. 8037

7. reference to a hidden tModel; this is a valid operation 8038

c. Adding isReplacedBy to a service’s or binding’s category bag: this is a semantically 8039 wrong operation and will be rejected. 8040

When returning an error encountered in the above, E_invalidValue will be returned to indicate 8041 that a value that was passed in a keyValue attribute did not pass validation. 8042

While this validation is intended at save time, references to replacing business entities may 8043 become invalid if (A) the business is deleted and (B) in V3 the business is deleted and then the 8044 key is re-used for a different entity. As such, in a replicating registry, nodes processing 8045 changeRecords related to business entities or tModels that refer to (now) invalid or missing 8046 business or tModels entity keys respectively, MUST NOT raise replication errors. 8047


In the example below, the UDDI Version 2 uddi-org:publication_v2 tModel has been replaced 8049 by the uddi-org:publication_v3 tModel. To indicate this, the uddi-org:isReplacedBy identifier 8050 system is used to point the Version 2 uddi-org:publication_v2 tModel to the uddi-8051 org:publication_v3 tModel. To do this the uddi-org:publication_v2 tModel has a 8052 keyedReference added to its identifierBag, as follows: 8053

<tModel tModelKey="uuid:A2F33B65-2D66-4088-ABC7-914D0E05EB9E"> 8054 ... 8055 <name>uddi-org:publication_v2</name> 8056 ... 8057 <identifierBag> 8058  8061 <keyedReference keyName="isReplacedBy:publication_v3" 8062 keyValue="uuid:72ade754-c6cc-315b-b014-7c94791fe15c" 8063 tModelKey="uuid:e59ae320-77a5-11d5-b898-0004ac49cc1e"/> 8064 </identifierBag> 8065 ... 8066 </tModel> 8067 8068

Here the keyName attribute is commentary serving to help readability. The keyValue specifies 8069 which tModel replaces this one -- the version 3 publication tModel in this case. And the 8070

�� ...¶

��

...¶ ��

��

��

��

��

keyValue="uddi:uddi.org:v3_publication"¶ tModelKey="uddi:uddi.org:identifier:isReplacedBy"/>¶ ��


248/405

tModelKey specifies that the keyedReference is using the uddi-org:isReplacedBy identifier 8071 system. 8072

11.1.7 UDDI “Validated By” Category System 8073

This tModel represents a category system that is used to point a tModel representing a 8074 checked value set to the bindingTemplate for a value set caching or value set validation Web 8075 service. 8076


One of the concepts that tModels can represent is a checked value set. A checked value set 8078 is one whose use is monitored by a validation algorithm. There are two types of validation 8079 algorithms: simple checking of referenced values against a pre-defined set of allowable values, 8080 and any other kind of validation. UDDI provides the Value Set API set (see Section 5.6 Value 8081 Set API Set) to acquire the set of allowable values or execute an external validation algorithm. 8082

A validation algorithm for a checked value set can be acquired by nodes privately, or can be 8083 obtained through normal UDDI discovery. The validatedBy category system facilitates 8084 discovery of the value set caching or value set validation Web service for a checked value set 8085 tModel by pointing to the bindingTemplate for the Web service. 8086

For the Web service to be useful, it must recognize any and all checked value sets that it is 8087 expected to be associated with. The recommended way for doing so is to place the tModels 8088 for the checked value sets it supports in the tModelInstanceDetails of the bindingTemplate for 8089 the Web service. Registry policy may require that providers of the Web service recognize 8090 value sets supported using this technique. 8091


Name: uddi-org:validatedBy

Description: A category system used to point a value set or category group system tModel to associated value set Web service implementations.

UDDI Key (V3): uddi:uddi.org:categorization:validatedby

Derived V1,V2 format key: uuid:25b22e3e-3dfa-3024-b02a-3438b9050b59


Checked: Yes

8094



<tModel tModelKey=”uddi:uddi.org:categorization:validatedby”> 8097 <name>uddi-org:validatedBy</name> 8098 <description>Category system used to point a value set or category 8099 group system tModel to associated value set Web service 8100 implementations. 8101 </description> 8102 <overviewDoc> 8103 <overviewURL useType=”text”> 8104 http://uddi.org/pubs/uddi_v3.htm#validatedBy 8105 </overviewURL> 8106 </overviewDoc> 8107 <categoryBag> 8108

�� IsReplacedBy

�� .

�� validatedBy

�� Name: uddi-

org:validatedBy¶Description: A category system used to point a value set or category group system tModel to ¶

associated value set Web service implementations. ¶UDDI Key (V3):

uddi:uddi.org:categorization:validatedBy¶Derived V1, V2 format key: uuid:82984443-0485-3d17-a934-b0933b3fc2f1¶Categorization: categorization¶Checked: Yes ¶��

¶

�� validatedBy

249/405

<keyedReference keyName=”uddi-org:types:categorization” 8109 keyValue="categorization" 8110 tModelKey="uddi:uddi.org:categorization:types”/> 8111 <keyedReference keyName=”uddi-org:types:checked” 8112 keyValue="checked" 8113 tModelKey="uddi:uddi.org:categorization:types”/> 8114 <keyedReference keyName=”uddi-org:types:uncacheable” 8115 keyValue="uncacheable" 8116 tModelKey="uddi:uddi.org:categorization:types”/> 8117

<keyedReference keyName=”entityKeyValues” 8118 keyValue=”bindingKey” 8119 tModelKey=”uddi:uddi.org:categorization:entitykeyvalues”/> 8120

</categoryBag> 8121 </tModel> 8122 8123


The keyValues in keyedReferences that refer to this tModel must be bindingKeys. Such a 8125 keyValue SHOULD reference a bindingTemplate that specifies a Web service that implements 8126 a value set caching or value set validation API and which SHOULD reference the value set 8127 tModel so categorized with this category system. No other contextual checks are performed. 8128


In the example below, an example checked value set tModel uses the validatedBy category 8130 system to refer to the bindingTemplate of a get_allValidValues Web service that is prepared to 8131 yield the set of valid values for the value set. The referenced bindingTemplate is shown below 8132 the tModel: 8133

<tModel tModelKey="uddi:anexample:mycheckedvalueset"> 8134 ... 8135 <categoryBag> 8136 <keyedReference keyName=”uddi-org:types:categorization” 8137 keyValue="categorization" 8138 tModelKey="uddi:uddi.org:categorization:types”/> 8139 <keyedReference keyName=”uddi-org:types:checked” 8140 keyValue="checked" 8141 tModelKey="uddi:uddi.org:categorization:types”/> 8142 <keyedReference keyName=”uddi-org:types:cacheable” 8143 keyValue="cacheable" 8144 tModelKey="uddi:uddi.org:categorization:types”/> 8145  8148 <keyedReference keyName="validatedBy:myCheckedValueSet:values" 8149 keyValue="uddi:anexample:mycheckedvalueset:values" 8150 tModelKey="uddi:uddi.org:identifier:validatedby"/> 8151 </categoryBag> 8152 ... 8153 </tModel> 8154 8155

The referenced bindingTemplate for the get_allValidValues Web service is shown below. Note 8156 that the bindingTemplate references the value set tModel above, indicating it can yield valid 8157 values for that value set. 8158

<bindingTemplate bindingKey=”uddi:anexample:mycheckedvalueset:values” 8159 serviceKey=”…”> 8160 <description>Web service to retrieve valid values for myCheckedValueSet 8161 </description> 8162 <accessPoint useType=”endpoint”> 8163 http://URL_of_service 8164 </accessPoint> 8165 <tModelInstanceDetails> 8166 <tModelInstanceInfo 8167 tModelKey=”uddi:uddi.org:v3_valuesetcaching” /> 8168 <tModelInstanceInfo 8169 tModelKey="uddi:anexample:mycheckedvalueset" /> 8170

��

��

�� anExample:myCheckedVa

lueSet


lueSet��

validatedBy


lueSet

�� valueSetCaching


lueSet


250/405

</tModelInstanceDetails> 8171 </bindingTemplate> 8172

8173

11.1.8 UDDI “Derived From” Category System 8174


UDDI provides a mechanism that may be used by publishers to categorize UDDI 8176 entities according to any number of category systems. See Appendix F Using Categorization 8177 for more information. This section defines a tModel used to associate a tModel, frequently a 8178 category system, with some other tModel, frequently the value set of some other category 8179 system, for the purpose of extension or redefinition of purpose. 8180


Most value sets are used with some purpose in mind. To avoid ambiguity in publisher and 8182 inquirer intent it is not uncommon for this purpose to be explicitly associated with the value set 8183 in its tModel. The IS0 3166 geographic category system, for example, has the purpose service 8184 offering area. 8185

Similarly, the UDDI API is comprised of a fixed set of programming interfaces and structures. 8186 UDDI registries can extend the UDDI API through schema derivation, to offer additional 8187 functionality. 8188

The Derived From category system exists to allow tModels to refer to the tModels that they 8189 extend in some way. Value set values can be re-used by referring a derived value set tModel 8190 to the values in some other value set tModel. The reason for reuse can be for assigning 8191 another purpose to the set of values, for extending the set of values, for associating one set of 8192 values with another, or for some other kind of derivation. 8193

Specification tModels that extend some other specification tModel can similarly use this 8194 category system to refer to the tModels they extend, providing end users with knowledge about 8195 the full scope of the API. 8196


251/405

8197


Name: uddi-org:derivedFrom

Description: Category system for referring tModels to other tModels for the purpose of reuse

UDDI Key (V3): uddi:uddi.org:categorization:derivedfrom

Derived V1,V2 format key: uuid:5678dd4f-f95d-35f9-9ea6-f79a7dd64656


Checked: Yes

8200



<tModel tModelKey=”uddi:uddi.org:categorization:derivedfrom”> 8203 <name>uddi-org:derivedFrom</name> 8204 <description>Category system for referring tModels to other 8205 tModels for the purpose of reuse. 8206 </description> 8207 <overviewDoc> 8208 <overviewURL useType=”text”> 8209 http://uddi.org/pubs/uddi_v3.htm#DerivedFrom 8210 </overviewURL> 8211 </overviewDoc> 8212 <categoryBag> 8213 <keyedReference keyName=”uddi-org:types:categorization” 8214 keyValue="categorization" 8215 tModelKey="uddi:uddi.org:categorization:types”/> 8216 <keyedReference keyName=”uddi-org:types:checked” 8217 keyValue="checked" 8218 tModelKey="uddi:uddi.org:categorization:types”/> 8219 <keyedReference keyName=”uddi-org:types:uncacheable” 8220 keyValue="uncacheable" 8221 tModelKey="uddi:uddi.org:categorization:types”/> 8222

<keyedReference keyName=”entityKeyValues” 8223 keyValue=”tModelKey” 8224

tModelKey=”uddi:uddi.org:categorization:entitykeyvalues”/> 8225 </categoryBag> 8226 </tModel> 8227 8228 8229


The keyValue attribute in a keyedReference element that references this tModel within a 8231 categoryBag must be some other tModelKey in the UDDI registry. For value set derivations the 8232 tModel that is referred to contain the root values for the derived value set. A tModel for a 8233 derived value set is not automatically checked if the referred to value set is checked. The 8234 derived value set must itself go through the registry's process for making the derived value set 8235 checked. 8236

�� Name: uddi-

org:derivedFrom¶Description: Category system for referring tModels to other tModels for the purpose of reuse.¶UDDI Key (V3):

uddi:uddi.org:categorization:derivedFrom¶Derived V1, V2 format key: uuid:0894546b-91ed-37a0-af79-64136fa3f337¶Categorization: categorization¶Checked: Yes ¶

�� derivedFrom

��

</categoryBag></tModel>

252/405

8237


Assume that the ISO 3166 Geographic system is a checked value set used to characterize 8239 where a business offers its Web services. Its tModel, after going through the registry's process 8240 for obtaining a checked value set looks like this: 8241

<tModel tModelKey="uddi:uddi.org:ubr:categorization:iso3166"> 8242 <name>ubr-uddi-org:iso-ch:3166-1999</name> 8243 <categoryBag> 8244  8247 <keyedReference keyName="uddi-org:types:categorization" 8248 keyValue="categorization" 8249 tModelKey="uddi:uddi.org:categorization:types"/> 8250 <keyedReference keyName="uddi-org:types:checked" 8251 keyValue="checked" 8252 tModelKey="uddi:uddi.org:categorization:types"/> 8253 <keyedReference keyName="uddi-org:types:cacheable" 8254 keyValue="cacheable" 8255 tModelKey="uddi:uddi.org:categorization:types"/> 8256  8258 <keyedReference keyName="uddi-org:types:valueSet" 8259 keyValue="valueSet" 8260 tModelKey="uddi:uddi.org:categorization:types"/> 8261 </categoryBag> 8262 </tModel> 8263 8264

To use the ISO 3166 values for the purpose of describing geographic location, a derived 8265 tModel is created with the new purpose. Note that even though the ISO 3166 value set tModel 8266 above is checked, meaning references to its values are validated, the derived tModel for 8267 describing the geographic location is not necessarily checked itself. To actually be checked, 8268 the provider of the validation algorithm must agree to check the values associated with the 8269 derived value set. 8270

<tModel 8271 tModelKey="uddi:uddi.org:ubr:categorization:iso3166: 8272 business_location"> 8273 <name>ubr-uddi-org:iso-ch:3166-1999:business_location</name> 8274 <categoryBag> 8275  8276 <keyedReference 8277 keyName="derivedFrom:ubr-uddi-org:iso-ch:3166-1999" 8278 keyValue="uddi:uddi.org:ubr:categorization:iso3166" 8279 tModelKey="uddi:uddi.org:categorization:derivedfrom"/> 8280  8283 <keyedReference keyName="uddi-org:types" 8284 keyValue="categorization" 8285 tModelKey="uddi:uddi.org:categorization:types"/> 8286 <keyedReference keyName="uddi-org:types" 8287 keyValue="unchecked" 8288 tModelKey="uddi:uddi.org:categorization:types"/> 8289 </categoryBag> 8290 </tModel> 8291

8292

�� ubr.

�� geo3166-2

�� ubr.

�� geo3166-2

�� ubr.

�� geo3166-2

�� derivedFrom

253/405

8293

A businessEntity that is categorized with geographic information with both intended purposes 8294 might look like this: 8295

<businessEntity businessKey="uddi:a_business_key" 8296 ... 8297 <categoryBag> 8298  8300 <keyedReference 8301 keyName="geoServiceArea:California, USA" 8302 keyValue="US-CA" 8303 tModelKey="uddi:uddi.org:ubr:categorization:iso3166"/> 8304  8306 <keyedReference keyName="geoLocation:California, USA" 8307 keyValue="US-CA" 8308 tModelKey="uddi:uddi.org:ubr:categorization:iso3166: 8309 business_location"/> 8310 </categoryBag> 8311 ... 8312 </businessEntity> 8313 8314

For an example on using the derivedFrom category system with a specification extension, see 8315 Appendix H Extensibility. 8316

8317

�� ubr.

�� geo3166-2

�� ubr.

�� geo3166-2


254/405

8318

11.1.9 UDDI “Entity Key Values” Category System 8319

The entity key values tModel represents a category system that may be used to indicate that a 8320 value set uses entity keys for its valid values. 8321


There are several value sets in UDDI that have entity keys as valid values, and other such 8323 value sets may be defined. Special handling of the keyValue values is required for these value 8324 sets to ensure that they can be used by applications using any version of the UDDI API. By 8325 categorizing a value set with this tModel the publisher of the value set indicates that entity keys 8326 form the valid values of the value set. This allows a UDDI implementation to map entity keys 8327 between versions as is done with all other uses of entity keys. 8328

If keys of only one type are valid for a particular value set, then that value set should have a 8329 single keyedReference relating to this tModel and the keyValue should contain the type of 8330 entity key that is valid, for example “tModelKey”. If multiple types of key are valid, as in the 8331 case of uddi-org:isReplacedBy, then multiple keyedReferences can be used, one for each type 8332 of key. If any type of key is valid then a single keyedReference should be used with a 8333 keyValue of “entityKey”. 8334

A value set categorized with this tModel SHOULD be treated as an internally checked value 8335 set, whether or not it is also categorized as checked. 8336

If the entity key supplied as the keyValue in a keyedReference relating to such a value set is 8337 not a valid entity key, or is the key of an entity of a type not supported by the particular value 8338 set, then the error E_invalidValue MAY be returned. 8339

Value sets may require additional validation, and this additional validation MAY be performed 8340 before or after the validation of the key itself, therefore a different error MAY be returned if one 8341 of these additional validation steps fails before the validation of the key itself. 8342


Name: uddi-org:entityKeyValues

Description: Category system used to declare that a value set uses entity keys as valid values

UDDI Key (V3): uddi:uddi.org:categorization:entitykeyvalues

Derived V1,V2 format key: uuid:916b87bf-0756-3919-8eae-97dfa325e5a4


Checked: Yes



<tModel tModelKey=”uddi:uddi.org:categorization:entitykeyvalues”> 8346 <name>uddi-org:entityKeyValues</name> 8347 <description>Category system used to declare that a value set 8348 uses entity keys as valid values. 8349 </description> 8350 <overviewDoc> 8351 <overviewURL useType=”text”> 8352 http://uddi.org/pubs/uddi_v3.htm#entityKeyValues 8353


255/405

</overviewURL> 8354 </overviewDoc> 8355 <categoryBag> 8356 <keyedReference keyName=”uddi-org:types:categorization” 8357 keyValue="categorization" 8358 tModelKey="uddi:uddi.org:categorization:types”/> 8359 <keyedReference keyName=”uddi-org:types:checked” 8360 keyValue="checked" 8361 tModelKey="uddi:uddi.org:categorization:types”/> 8362 </categoryBag> 8363 </tModel> 8364


The valid values of this categorization system are the following strings: 8366

• “entityKey” 8367

• “businessKey“ 8368

• “tModelKey” 8369

• “serviceKey” 8370

• “bindingKey” 8371

• “subscriptionKey” 8372


The V3 version of the owningBusiness Category System has the following extra 8374 keyedReference added to its tModel to declare that the valid values of the owningBusiness 8375 value set are business keys: 8376

<keyedReference keyName="entityKeyValues" 8377 keyValue="businessKey" 8378 tModelKey="uddi:uddi.org:categorization:entitykeyvalues"/> 8379

8380

11.2 UDDI Registry API tModels 8381

UDDI defines a number of tModels to represent the UDDI application programming interface. 8382 Each of the core tModels are listed in this section. Every registry is required to register these 8383 tModels whether Web services that conform to these specifications are offered or not. 8384 Equivalent registry tModels from prior versions can be found in prior versions of the UDDI 8385 specification. 8386

11.2.1 UDDI Inquiry API 8387


The group of APIs represented by this tModel deals with finding and retrieving information from 8389 the registry. To be a UDDI Version 3 compliant registry at least one of the nodes in a registry 8390 must provide a Web service that implements this tModel. See Section 5.1 Inquiry API Set. 8391


The UDDI inquiry API provides a simple, complete set of programming interfaces that are used 8393 to: 8394

• Search a UDDI registry to locate registry entries meeting a particular technical or 8395 business need. 8396

• Retrieve details of registry entries once they have been found. 8397


256/405


Name: uddi-org:inquiry_v3

Description: UDDI Inquiry API Version 3 - Core Specification

UDDI Key (V3): uddi:uddi.org:v3_inquiry

Derived V1,V2 format key: uuid:01b9bbff-a8f5-3735-9a5e-5ea5ade7daaf

Categorization: specification, xmlSpec, soapSpec, wsdlSpec



<tModel tModelKey=”uddi:uddi.org:v3_inquiry”> 8402 <name>uddi-org:inquiry_v3</name> 8403 <description>UDDI Inquiry API V3.0</description> 8404 <overviewDoc> 8405 <overviewURL useType=”wsdlInterface”> 8406 http://uddi.org/wsdl/uddi_api_v3_binding.wsdl#UDDI_Inquiry_SoapBinding 8407 </overviewURL> 8408 </overviewDoc> 8409 <overviewDoc> 8410 <overviewURL useType=”text”> 8411 http://uddi.org/pubs/uddi_v3.htm#InqV3 8412 </overviewURL> 8413 </overviewDoc> 8414 <categoryBag> 8415 <keyedReference keyName=”uddi-org:types:wsdl” 8416 keyValue="wsdlSpec" 8417 tModelKey="uddi:uddi.org:categorization:types”/> 8418 <keyedReference keyName=”uddi-org:types:soap” 8419 keyValue="soapSpec" 8420 tModelKey="uddi:uddi.org:categorization:types”/> 8421 <keyedReference keyName=”uddi-org:types:xml” 8422 keyValue="xmlSpec" 8423 tModelKey="uddi:uddi.org:categorization:types”/> 8424 <keyedReference keyName=”uddi-org:types:specification” 8425 keyValue="specification" 8426 tModelKey="uddi:uddi.org:categorization:types”/> 8427 </categoryBag> 8428 </tModel> 8429

8430

11.2.1.4 Programming Interfaces Covered 8431

The UDDI APIs covered by this tModel are: 8432

• find_binding: Used to locate specific bindings within a registered businessService. 8433 Returns a bindingDetail structure. 8434

• find_business: Used to locate information about one or more businesses. Returns a 8435 businessList structure. 8436

• find_relatedBusinesses: Used to locate information about businessEntity structures 8437 that are related to a specific business entity whose key is passed in the inquiry. The 8438 relatedBusinesses feature was introduced in UDDI version 2 and is used to manage 8439 registration of business units and subsequently relate them based on organizational 8440 hierarchies or business partner relationships. Returns a relatedBusinesses structure. 8441

• find_service: Used to locate specific businessService structures within a registered 8442 businessEntity. Returns a serviceList structure. 8443

�� Name: uddi-

org:inquiry_v3¶Description: UDDI Inquiry API Version 3 - Core Specification¶UDDI Key (V3):

uddi:uddi.org:v3_inquiry¶Derived V1,V2 format key: uuid:c521c906-53c9-35b2-9d1c-5a66ddbbd3c4¶Categorization: specification, xmlSpec, soapSpec, wsdlSpec¶��

¶


257/405

• find_tModel: Used to locate one or more tModel information structures. Returns a 8444 tModelList structure. 8445

• get_bindingDetail: Used to get full bindingTemplate information suitable for making 8446 one or more service requests. Returns a bindingDetail structure. 8447

• get_businessDetail: Used to get the full businessEntity information for one or more 8448 businesses or organizations. Returns a businessDetail structure. 8449

• get_businessDetailExt: Used to get extended businessEntity information. Returns a 8450 businessDetailExt structure. 8451

• get_operationalInfo: Used to obtain metadata associated with core entities. Returns 8452 an operationalInfo structure. 8453

• get_serviceDetail: Used to get full details for a given set of registered businessService 8454 date. Returns a serviceDetail structure. 8455

• get_tModelDetail: Used to get full details for a given set of registered tModel data. 8456 Returns a tModelDetail structure. 8457


The following is a typical bindingTemplate for a Web Service that implements the UDDI 8459 Version 3 Inquiry API: 8460

<bindingTemplate bindingKey=”…” serviceKey=”…”> 8461 <description>UDDI Inquiry API V3</description> 8462 <accessPoint useType=”endpoint”> 8463 http://URL_of_service 8464 </accessPoint> 8465 <tModelInstanceDetails> 8466 <tModelInstanceInfo 8467 tModelKey=”uddi:uddi.org:v3_inquiry”> 8468 <instanceDetails> 8469 <instanceParms> 8470 <![CDATA[ 8471 <?xml version=”1.0” encoding=”utf-8” ?> 8472 <UDDIinstanceParmsContainer 8473 xmlns=”urn:uddi-org:policy_v3_instanceParms”> 8474 <defaultSortOrder> 8475 uddi:uddi.org:sortorder:binarysort 8476 </defaultSortOrder> 8477 </UDDIinstanceParmsContainer> 8478 ]]> 8479 </instanceParms> 8480 </instanceDetails> 8481 </tModelInstanceInfo> 8482 </tModelInstanceDetails> 8483 </bindingTemplate> 8484

8485

11.2.2 UDDI Publication API 8486


The group of programming interfaces represented by this tModel deals with adding or 8488 modifying information in the registry. While a UDDI Version 3 compliant registry is not required 8489 to have any of its nodes provide a Web service that implements this tModel, most do 8490 implement this tModel as a standard mechanism for providing the data on which the UDDI 8491 Inquiry API is based. See Section 5.2 Publication API Set. 8492

�� sortOrder:binarySort


258/405


The UDDI publication API provides a simple, complete set of programming interfaces that 8494 publishers of registry entries can use to publish UDDI registry entries. 8495


Name: uddi-org:publication_v3

Description: UDDI Publication API Version 3

UDDI Key (V3): uddi:uddi.org:v3_publication

Derived V1,V2 format key: uuid:72ade754-c6cc-315b-b014-7c94791fe15c




<tModel tModelKey=”uddi:uddi.org:v3_publication”> 8500 <name>uddi-org:publication_v3</name> 8501 <description>UDDI Publication API V3.0</description> 8502 <overviewDoc> 8503 <overviewURL useType=”wsdlInterface”> 8504 http://uddi.org/wsdl/uddi_api_v3_binding.wsdl#UDDI_Publication_SoapBinding 8505 </overviewURL> 8506 </overviewDoc> 8507 <overviewDoc> 8508 <overviewURL useType=”text”> 8509 http://uddi.org/pubs/uddi_v3.htm#PubV3 8510 </overviewURL> 8511 </overviewDoc> 8512 <categoryBag> 8513 <keyedReference keyName=”uddi-org:types:wsdl” 8514 keyValue="wsdlSpec" 8515 tModelKey="uddi:uddi.org:categorization:types”/> 8516 <keyedReference keyName=”uddi-org:types:soap” 8517 keyValue="soapSpec" 8518 tModelKey="uddi:uddi.org:categorization:types”/> 8519 <keyedReference keyName=”uddi-org:types:xml” 8520 keyValue="xmlSpec" 8521 tModelKey="uddi:uddi.org:categorization:types”/> 8522 <keyedReference keyName=”uddi-org:types:specification” 8523 keyValue="specification" 8524 tModelKey="uddi:uddi.org:categorization:types”/> 8525 </categoryBag> 8526 </tModel> 8527

8528



• add_publisherAssertions: Used to add relationship assertions to the existing set of 8531 assertions. See Appendix A Relationships and Publisher Assertions for more 8532 information. 8533

• delete_binding: Used to remove an existing bindingTemplate from the 8534 bindingTemplates collection that is part of a specified businessService structure. 8535

• delete_business: Used to delete registered businessEntity information from the 8536 registry. 8537

��

¶

�� Name: uddi-

org:publication_v3¶Description: UDDI Publication API Version 3¶UDDI Key (V3):

uddi:uddi.org:v3_publication¶Derived V1,V2 format key: uuid:320c268f-05b5-336f-bd42-d2c5edadcd81¶Categorization: specification, xmlSpec, soapSpec, wsdlSpec ¶¶


259/405

• delete_publisherAssertions: Used to delete specific assertions from the assertion set 8538 managed by a particular publisher account. Only effects the relationship assertions 8539 specified, causing any relationships formed by virtue of a prior assertion to be 8540 invalidated. 8541

• delete_service: Used to delete an existing businessService from the businessServices 8542 collection that is part of a specified businessEntity. 8543

• delete_tModel: Used to hide registered information about a tModel. Any tModel 8544 hidden in this way is still usable for reference purposes, but is simply hidden from 8545 find_tModel result sets. There is no way to actually cause a tModel to be deleted, 8546 except by administrative petition. 8547

• get_assertionStatusReport: Used to get a list of relationship assertions that is useful 8548 for display in tools that help an administrator manage active and tentative assertions 8549 regarding relationships. Relationships help manage complex business structures that 8550 require more than one businessEntity or more than one publisher account to manage 8551 parts of a businessEntity. Returns an assertionStatusReport that includes the status of 8552 all assertions made involving any businessEntity controlled by the requesting 8553 publisher account. 8554

• get_publisherAssertions: Used to get a list of active relationship assertions that are 8555 controlled by an individual publisher account. Returns a publisherAssertions structure 8556 containing a document that contains all relationship assertions associated with a 8557 specific publisher account. 8558

• get_registeredInfo: Used to request an abbreviated synopsis of all information 8559 currently managed by a given individual. 8560

• save_binding: Used to register new bindingTemplate information or update existing 8561 bindingTemplate information. Use this to control information about technical 8562 capabilities exposed by a registered business. 8563

• save_business: Used to register new businessEntity information or update existing 8564 businessEntity information. Use this to control the full set of information about the 8565 entire business. Of the save_xx API’s this one has the broadest effect. 8566

• save_service: Used to register or update complete information about a 8567 businessService exposed by a specified businessEntity. 8568

• save_tModel: Used to register or update complete information about a tModel. 8569

• set_publisherAssertions: Used to save the complete set of relationship assertions for 8570 an individual publisher account. Replaces any existing assertions, and causes any old 8571 assertions that are not reasserted to be removed from the registry. 8572

�� are


260/405

8573


The following is a typical bindingTemplate for a Web Service that implements the UDDI 8575 Version 3 Publication API: 8576

<bindingTemplate bindingKey=”…” serviceKey=”…”> 8577 <description>UDDI Publication API V3</description> 8578 <accessPoint useType=”endpoint”> 8579 https://URL_of_service 8580 </accessPoint> 8581 <tModelInstanceDetails> 8582 <tModelInstanceInfo 8583 tModelKey=”uddi:uddi.org:v3_publication”> 8584 <instanceDetails> 8585 <instanceParms> 8586 <![CDATA[ 8587 <?xml version=”1.0” encoding=”utf-8” ?> 8588 <UDDIinstanceParmsContainer 8589 xmlns=”urn:uddi-org:policy_v3_instanceParms”> 8590 <authInfoUse>required</authInfoUse> 8591 </UDDIinstanceParmsContainer> 8592 ]]> 8593 </instanceParms> 8594 </instanceDetails> 8595 </tModelInstanceInfo> 8596 <tModelInstanceInfo 8597 tModelKey="uddi:uddi.org:protocol:serverauthenticatedssl3" /> 8598 </tModelInstanceDetails> 8599 </bindingTemplate> 8600

8601

�� serverAuthenticatedSS

L3


261/405

8602

11.2.3 UDDI Security API 8603


The group of programming interfaces represented by this tModel pertains to authenticating 8605 with a UDDI node. Each registry and its nodes define policies for registering, authenticating 8606 and authorizing publishers and these APIs offer one way to provide tokens for use in 8607 authorizing other API access.. 8608


The UDDI security API provides a simple, complete set of APIs that users of registry entries 8610 MAY use to obtain the security credentials necessary to use all or parts of UDDI registries that 8611 distinguish between publishers. See Section 5.3 Security Policy API Set. 8612


Name: uddi-org:security_v3

Description: UDDI Security API Version 3

UDDI Key (V3): uddi:uddi.org:v3_security

Derived V1,V2 format key: uuid:e4cd70e2-22ec-3032-b1e6-cc31a9d55935


8615



<tModel tModelKey=”uddi:uddi.org:v3_security”> 8618 <name>uddi-org:security_v3</name> 8619 <description>UDDI Security API V3.0</description> 8620 <overviewDoc> 8621 <overviewURL useType=”wsdlInterface”> 8622 http://uddi.org/wsdl/uddi_api_v3_binding.wsdl#UDDI_Security_SoapBinding 8623 </overviewURL> 8624 </overviewDoc> 8625 <overviewDoc> 8626 <overviewURL useType=”text”> 8627 http://uddi.org/pubs/uddi_v3.htm#SecV3 8628 </overviewURL> 8629 </overviewDoc> 8630 <categoryBag> 8631 <keyedReference keyName=”uddi-org:types:wsdl” 8632 keyValue="wsdlSpec" 8633 tModelKey="uddi:uddi.org:categorization:types”/> 8634 <keyedReference keyName=”uddi-org:types:soap” 8635 keyValue="soapSpec" 8636 tModelKey="uddi:uddi.org:categorization:types”/> 8637 <keyedReference keyName=”uddi-org:types:xml” 8638 keyValue="xmlSpec" 8639 tModelKey="uddi:uddi.org:categorization:types”/> 8640 <keyedReference keyName=”uddi-org:types:specification” 8641 keyValue="specification" 8642 tModelKey="uddi:uddi.org:categorization:types”/> 8643 </categoryBag> 8644 </tModel> 8645

�� Name: uddi-

org:security_v3¶Description: UDDI Security API Version 3¶UDDI Key (V3):

uddi:uddi.org:v3_security¶Derived V1,V2 format key: uuid:5f7e1d45-3c2e-3e6f-9b9c-737a20022a4f¶Categorization: specification, xmlSpec, soapSpec, wsdlS¶

�� wsdlInterface


262/405

8646



• discard_authToken: Used to inform a UDDI node that a previously obtained 8649 authentication token is no longer required and should be considered invalid if used 8650 after this call is received. 8651

• get_authToken: Used to request an authentication token in the form of an authInfo 8652 element from a UDDI node. An authInfo element MAY be required when using the 8653 API calls defined in Section 5.1 Inquiry API Set, Section 5.2 Publication API Set, 8654 Section 5.4 Custody and Ownership Transfer API Set, and Section 5.5 Subscription 8655 API Set. 8656


The following is a typical bindingTemplate for a Web Service that implements the UDDI 8658 Version 3 Security API: 8659

<bindingTemplate bindingKey=”…” serviceKey=”…”> 8660 <description>UDDI Security API V3</description> 8661 <accessPoint useType=”endpoint”> 8662 https://URL_of_service 8663 </accessPoint> 8664 <tModelInstanceDetails> 8665 <tModelInstanceInfo tModelKey=”uddi:uddi.org:v3_security”/> 8666 <tModelInstanceInfo 8667 tModelKey="uddi:uddi.org:protocol:serverauthenticatedssl3"/> 8668 </tModelInstanceDetails> 8669 </bindingTemplate> 8670

8671

11.2.4 UDDI Replication API 8672


The group of programming interfaces represented by this tModel deals with managing the 8674 replication of information between nodes in a UDDI registry. See Section 7.4 Replication API 8675 Set. Nodes in multi-node UDDI registries SHOULD each offer Web services that conform to 8676 this specification. 8677


The UDDI Replication API set provides a simple, complete set of APIs that UDDI nodes can 8679 use to replicate custodial data with other nodes in a multi-node registry. 8680


Name: uddi-org:replication_v3

Description: UDDI Replication API Version 3

UDDI Key (V3): uddi:uddi.org:v3_replication

Derived V1,V2 format key: uuid:998053a9-8672-3bf3-908a-c82deb4baecf


: 8683

��

��

”> <instanceDetails>¶ <instanceParms>¶ <![CDATA[¶ <?xml version=”1.0” encoding=”utf-8” ?>¶ <UDDIinstanceParmsContainer ¶ xmlns=”urn:uddi-org:policy_v3_instanceParms”>¶ <authInfoUse>required</authInfoUse>¶ </UDDIinstanceParmsContainer>¶ ]]>¶ </instanceParms>¶ </instanceDetails> </tModelInstanceInfo��

serverAuthenticatedSSL3" ��

Name: uddi-org:replication_v3¶Description: UDDI Replication API Version 3¶UDDI Key (V3):

uddi:uddi.org:v3_replication¶Derived V1,V2 format key: uuid:e3a042c0-1c2f-3797-8197-c6258229e8c7 ¶Categorization: specification, xmlSpec, soapSpec, wsdlSpec¶


263/405



<tModel tModelKey=”uddi:uddi.org:v3_replication”> 8686 <name>uddi-org:replication_v3</name> 8687 <description>UDDI Replication API V3.0</description> 8688 <overviewDoc> 8689 <overviewURL useType=”wsdlInterface”> 8690 http://uddi.org/wsdl/uddi_repl_v3_binding.wsdl 8691 </overviewURL> 8692 </overviewDoc> 8693 <overviewDoc> 8694 <overviewURL useType=”text”> 8695 http://uddi.org/pubs/uddi_v3.htm#Repl 8696 </overviewURL> 8697 </overviewDoc> 8698 <categoryBag> 8699 <keyedReference keyName=”uddi-org:types:wsdl” 8700 keyValue="wsdlSpec" 8701 tModelKey="uddi:uddi.org:categorization:types”/> 8702 <keyedReference keyName=”uddi-org:types:soap” 8703 keyValue="soapSpec" 8704 tModelKey="uddi:uddi.org:categorization:types”/> 8705 <keyedReference keyName=”uddi-org:types:xml” 8706 keyValue="xmlSpec" 8707 tModelKey="uddi:uddi.org:categorization:types”/> 8708 <keyedReference keyName=”uddi-org:types:specification” 8709 keyValue="specification" 8710 tModelKey="uddi:uddi.org:categorization:types”/> 8711 </categoryBag> 8712 </tModel> 8713

8714



• do_ping: Used to discover the existence and replication readiness of a node. 8717

• get_changeRecords: Used to initiate the replication of change records from one node 8718 to another. 8719

• notify_changeRecordsAvailable: Used to notify other nodes that the sending node has 8720 change data to be replicated. 8721

• get_highWaterMarks: Used to obtain the high water marks from a node. 8722


264/405

8723


The following is a typical bindingTemplate for a Web Service that implements the UDDI 8725 Version 3 Replication API: 8726

<bindingTemplate bindingKey=”…” serviceKey=”…”> 8727 <description>UDDI Replication API V3</description> 8728 <accessPoint useType=”endpoint”> 8729 https://URL_of_service 8730 </accessPoint> 8731 <tModelInstanceDetails> 8732 <tModelInstanceInfo 8733 tModelKey=”uddi:uddi.org:v3_replication” /> 8734 <tModelInstanceInfo 8735 tModelKey="uddi:uddi.org:protocol:mutualauthenticatedssl3" /> 8736 </tModelInstanceDetails> 8737 </bindingTemplate> 8738

8739

11.2.5 UDDI Custody and Ownership Transfer API 8740


The group of programming interfaces represented by this tModel enables two publishers to 8742 cooperatively transfer ownership of one or more existing businessEntity or tModel structures 8743 from one publisher to another. See Section 5.4 Custody and Ownership Transfer API Set. 8744 Registries that offer a publishing Web service (uddi-org:v3_publish) SHOULD also offer a 8745 custody transfer Web service. 8746


The UDDI Custody and Ownership Transfer API provides a simple, complete set of APIs that 8748 publishers can use to transfer ownership of UDDI entities from one publisher account to 8749 another and initiate custody transfer from one node to another. 8750


Name: uddi-org:ownership_transfer_v3

Description: UDDI Custody and Ownership Transfer API Version 3

UDDI Key (V3): uddi:uddi.org:v3_ownership_transfer

Derived V1,V2 format key: uuid:07ae0f8f-1bdc-32a7-b8dc-fe1d93d929a7


: 8753



<tModel tModelKey=”uddi:uddi.org:v3_ownership_transfer”> 8756 <name>uddi-org: ownership_transfer_v3</name> 8757 <description>UDDI Custody and Ownership Transfer API V3.0</description> 8758 <overviewDoc> 8759 <overviewURL useType=”wsdlInterface”> 8760 http://uddi.org/wsdl/uddi_custody_v3_binding.wsdl 8761 </overviewURL> 8762 </overviewDoc> 8763 <overviewDoc> 8764

�� mutualAuthenticatedSS

L3

�� Name: uddi-

org:ownership_transfer_v3¶Description: UDDI Custody and Ownership Transfer API Version 3¶UDDI Key (V3):

uddi:uddi.org:ownership_transfer_v3¶Derived V1, V2 format key: uuid:c68509e9-1e76-345f-8bae-0aef223f9de1¶Categorization: specification, xmlSpec, soapSpec, wsdl¶

�� _v3


265/405

<overviewURL useType=”text”> 8765 http://uddi.org/pubs/uddi_v3.htm#OwnershipTransfer 8766 </overviewURL> 8767 </overviewDoc> 8768 <categoryBag> 8769 <keyedReference keyName=”uddi-org:types:wsdl” 8770 keyValue="wsdlSpec" 8771 tModelKey="uddi:uddi.org:categorization:types”/> 8772 <keyedReference keyName=”uddi-org:types:soap” 8773 keyValue="soapSpec" 8774 tModelKey="uddi:uddi.org:categorization:types”/> 8775 <keyedReference keyName=”uddi-org:types:xml” 8776 keyValue="xmlSpec" 8777 tModelKey="uddi:uddi.org:categorization:types”/> 8778 <keyedReference keyName=”uddi-org:types:specification” 8779 keyValue="specification" 8780 tModelKey="uddi:uddi.org:categorization:types”/> 8781 </categoryBag> 8782 </tModel> 8783

8784


The UDDI APIs used to transfer ownership of entities and initiate custody transfer by this 8786 tModel are: 8787

• get_transferToken: Used by a custodial publisher to initiate an ownership and/or 8788 custody transfer process at the custodial UDDI node. 8789

• transfer_entities: Used by the target publisher to perform the transfer of ownership 8790 and/or initiate a custody transfer at the target node. 8791


The following is a typical bindingTemplate for a Web Service that implements the UDDI 8793 Version 3 Custody and Ownership Transfer API set: 8794

<bindingTemplate bindingKey=”” serviceKey=”…”> 8795 <description>UDDI Custody and Ownership Transfer API V3</description> 8796 <accessPoint useType=”endpoint”> 8797 https://URL_of_service 8798 </accessPoint> 8799 <tModelInstanceDetails> 8800 <tModelInstanceInfo 8801 tModelKey=”uddi:uddi.org:v3_ownership_transfer”> 8802 <instanceDetails> 8803 <instanceParms> 8804 <![CDATA[ 8805 <?xml version=”1.0” encoding=”utf-8” ?> 8806 <UDDIinstanceParmsContainer 8807 xmlns=”urn:uddi-org:policy_v3_instanceParms”> 8808 <authInfoUse>required</authInfoUse> 8809 </UDDIinstanceParmsContainer> 8810 ]]> 8811 </instanceParms> 8812 </instanceDetails> 8813 </tModelInstanceInfo> 8814 <tModelInstanceInfo 8815 tModelKey="uddi:uddi.org:protocol:serverauthenticatedssl3" /> 8816 </tModelInstanceDetails> 8817 </bindingTemplate> 8818

8819

�� _v3


L3


266/405

11.2.6 UDDI Node Custody Transfer API 8820


The programming interface represented by this tModel enables two nodes in a registry to 8822 cooperatively transfer custody of one or more existing businessEntity or tModel structures from 8823 one node to another and at the same time to transfer ownership of the entities from one 8824 publisher to another. The API represented by this tModel is used to complete an inter-node 8825 custody transfer. See Section 5.4 Custody and Ownership Transfer API Set. Multi-node 8826 registries that offer a publishing Web service (uddi-org:v3_publish) and a custody transfer Web 8827 service (uddi-org:v3_custody) SHOULD offer the node custody transfer API. 8828


The UDDI Node Custody Transfer API provides an API that UDDI nodes can use to complete 8830 a publisher request to transfer custody of UDDI entities from one node to another. 8831


Name: uddi-org:node_custody_transfer_v3

Description: UDDI Node Custody Transfer API Version 3

UDDI Key (V3): uddi:uddi.org:v3_node_custody_transfer

Derived V1,V2 format key: uuid:215c7844-5e81-347c-a2bf-54023ad463c8


8834



<tModel tModelKey="uddi:uddi.org:v3_node_custody_transfer"> 8837 <name>uddi-org:node_custody_transfer_v3</name> 8838 <description>UDDI Node Custody Transfer API V3.0</description> 8839 <overviewDoc> 8840 <overviewURL useType="wsdlInterface"> 8841 http://uddi.org/wsdl/uddi_custody_v3_binding.wsdl 8842 </overviewURL> 8843 </overviewDoc> 8844 <overviewDoc> 8845 <overviewURL useType="text"> 8846 http://uddi.org/pubs/uddi_v3.htm#NodeCustodyTransfer 8847 </overviewURL> 8848 </overviewDoc> 8849 <categoryBag> 8850 <keyedReference keyName="uddi-org:types:wsdl" 8851 keyValue="wsdlSpec" 8852 tModelKey="uddi:uddi.org:categorization:types"/> 8853 <keyedReference keyName="uddi-org:types:soap" 8854 keyValue="soapSpec" 8855 tModelKey="uddi:uddi.org:categorization:types"/> 8856 <keyedReference keyName="uddi-org:types:xml" 8857 keyValue="xmlSpec" 8858 tModelKey="uddi:uddi.org:categorization:types"/> 8859 <keyedReference keyName="uddi-org:types:specification" 8860 keyValue="specification" 8861 tModelKey="uddi:uddi.org:categorization:types"/> 8862 </categoryBag> 8863 </tModel> 8864 8865

�� Name: uddi-

org:node_custody_transfer_v3¶Description: UDDI Node Custody Transfer API Version 3¶UDDI Key (V3):

uddi:node_custody_transfer_v3¶Derived V1,V2 format key: uuid:89aa7d66-a871-30fb-b168-bea37c587c11 ¶Categorization: specification, xmlSpec, soapSpec, wsdl¶

�� _v3


267/405


The UDDI API covered by this tModel is: 8867

• transfer_custody: In a multi-node custody transfer, used when processing 8868 transfer_entities by the target node to verify acceptability of the transfer with the 8869 custodial node and to initiate the process of transferring the data between nodes. 8870


The following is a typical bindingTemplate for a Web Service that implements the UDDI 8872 Version 3 Custody Transfer API: 8873

<bindingTemplate bindingKey=”…” serviceKey=”…”> 8874 <description>UDDI Node Custody Transfer API V3</description> 8875 <accessPoint useType=”endpoint”> 8876 https://URL_of_service 8877 </accessPoint> 8878 <tModelInstanceDetails> 8879 <tModelInstanceInfo 8880 tModelKey=”uddi:uddi.org:v3_node_custody_transfer”> 8881 </tModelInstanceInfo> 8882 <tModelInstanceInfo 8883 tModelKey="uddi:uddi.org:protocol:mutualauthenticatedssl3"/> 8884 </tModelInstanceDetails> 8885 </bindingTemplate> 8886 8887

11.2.7 UDDI Value Set Caching API 8888


The programming interface represented by this tModel deals with obtaining a set of values for 8890 a checked value set so UDDI nodes may perform validation of publisher references 8891 themselves using the cached values obtained from such a Web service. See Section 5.6 8892 Value Set API Set. Providers of registry checked value sets SHOULD offer a Web service that 8893 conforms to this specification. 8894


The version 3.0 UDDI Value Set API defines programming interfaces that may be used by 8896 UDDI registries in the validation of references to checked category and identifier systems. The 8897 Value Set Caching API is a subset of the Value Set API. The usage restrictions can vary from 8898 simple to complex. A common example is insisting that the keyValues in keyedReferences 8899 come from a well-defined set. The UDDI registry and value set provider may agree that the 8900 UDDI nodes may cache the set of valid values. The provider may offer, and UDDI nodes use, 8901 a Web service to obtain the entire set of valid values at one time. 8902


Name: uddi-org:valueSetCaching_v3

Description: UDDI Value Set Caching API Version 3

UDDI Key (V3): uddi:uddi.org:v3_valuesetcaching

Derived V1,V2 format key: uuid:a24d9150-cdbb-3cb4-8843-41a5d0547170


8905

�� _v3


L3"

��

¶

�� Name: uddi-

org:valueSetCaching_v3¶Description: UDDI Value Set Caching API Version 3¶UDDI Key (V3):

uddi:uddi.org:v3_valueSetCaching¶Derived V1,V2 format key: uuid:fec572e8-500a-3474-a0c2-67964f5dc81b ¶Categorization: specification, xmlSpec, soapSpec, wsdlSpec ¶�� !

¶


268/405



<tModel tModelKey=”uddi:uddi.org:v3_valuesetcaching”> 8908 <name>uddi-org:valueSetCaching_v3</name> 8909 <description>UDDI Value Set Caching API V3.0</description> 8910 <overviewDoc> 8911 <overviewURL useType=”wsdlInterface”> 8912 http://uddi.org/wsdl/uddi_vscache_v3_binding.wsdl 8913 </overviewURL> 8914 </overviewDoc> 8915 <overviewDoc> 8916 <overviewURL useType=”text”> 8917 http://uddi.org/pubs/uddi_v3.htm#VSCaching 8918 </overviewURL> 8919 </overviewDoc> 8920 <categoryBag> 8921 <keyedReference keyName=”uddi-org:types:wsdl” 8922 keyValue="wsdlSpec" 8923 tModelKey="uddi:uddi.org:categorization:types”/> 8924 <keyedReference keyName=”uddi-org:types:soap” 8925 keyValue="soapSpec" 8926 tModelKey="uddi:uddi.org:categorization:types”/> 8927 <keyedReference keyName=”uddi-org:types:xml” 8928 keyValue="xmlSpec" 8929 tModelKey="uddi:uddi.org:categorization:types”/> 8930 <keyedReference keyName=”uddi-org:types:specification” 8931 keyValue="specification" 8932 tModelKey="uddi:uddi.org:categorization:types”/> 8933 </categoryBag> 8934 </tModel> 8935

8936

11.2.7.4 Programming Interface Covered 8937

The UDDI version 3 Value Set Caching API consists of one optional API: 8938

• get_allValidValues: A UDDI registry that supports caching of external value sets may 8939 send the get_allValidValues API to the appropriate external Web service to refresh a 8940 cache of valid values for a category or identifier system that has granted permission to 8941 have its values cached. 8942

8943


The following is a typical bindingTemplate for a Web Service that implements the UDDI 8945 Version 3 Value Set Caching API. This Web service is registered by a value set provider: 8946

<bindingTemplate bindingKey=”” serviceKey=”…”> 8947 <description>UDDI Value Set Caching API V3</description> 8948 <accessPoint useType=”endpoint”> 8949 http://URL_of_service 8950 </accessPoint> 8951 <tModelInstanceDetails> 8952 <tModelInstanceInfo 8953 tModelKey=”uddi:uddi.org:v3_valuesetcaching” /> 8954 </tModelInstanceDetails> 8955 </bindingTemplate> 8956

8957




269/405

11.2.8 UDDI Value Set Validation API 8958


The programming interface represented by this tModel deals with validating publisher use of 8960 category and identifier systems when describing their businessEntity, businessService, and 8961 tModel structures. See Section 5.6 Value Set API Set. Providers of externally checked value 8962 sets SHOULD offer a Web service that conforms to this specification. 8963


The version 3.0 UDDI Value Set API defines programming interfaces that may be used by 8965 UDDI registries in the validation of references to checked value sets. The Value Set Validation 8966 API is a subset of the Value Set API and consists of a single programming interface that may 8967 be offered by a value set provider and used by UDDI nodes to validate references to checked 8968 value sets. The usage restrictions can vary from simple to complex. 8969


Name: uddi-org:valueSetValidation_v3

Description: UDDI Value Set Validation API Version 3

UDDI Key (V3): uddi:uddi.org:v3_valuesetvalidation

Derived V1,V2 format key: uuid:056fc4a2-bea3-30e5-8382-6d61e1ee23ce


8972



<tModel tModelKey=”uddi:uddi.org:v3_valuesetvalidation”> 8975 <name>uddi-org:valueSetValidation_v3</name> 8976 <description>UDDI Value Set Validation API V3.0</description> 8977 <overviewDoc> 8978 <overviewURL useType=”wsdlInterface”> 8979 http://uddi.org/wsdl/uddi_vs_v3_binding.wsdl 8980 </overviewURL> 8981 </overviewDoc> 8982 <overviewDoc> 8983 <overviewURL useType=”text”> 8984 http://uddi.org/pubs/uddi_v3.htm#VSValid 8985 </overviewURL> 8986 </overviewDoc> 8987 <categoryBag> 8988 <keyedReference keyName=”uddi-org:types:wsdl” 8989 keyValue="wsdlSpec" 8990 tModelKey="uddi:uddi.org:categorization:types”/> 8991 <keyedReference keyName=”uddi-org:types:soap” 8992 keyValue="soapSpec" 8993 tModelKey="uddi:uddi.org:categorization:types”/> 8994 <keyedReference keyName=”uddi-org:types:xml” 8995 keyValue="xmlSpec" 8996 tModelKey="uddi:uddi.org:categorization:types”/> 8997 <keyedReference keyName=”uddi-org:types:specification” 8998 keyValue="specification" 8999 tModelKey="uddi:uddi.org:categorization:types”/> 9000 </categoryBag> 9001 </tModel> 9002

9003

�� Name: uddi-

org:valueSetValidation_v3¶Description: UDDI Value Set Validation API Version 3¶UDDI Key (V3):

uddi:uddi.org:v3_valueSetValidation¶Derived V1,V2 format key: uuid:d1a7a708-fd46-38a5-b60d-6ba9c2d115c2 ¶Categorization: specification, xmlSpec, soapSpec, wsdlSpec ¶��

¶

�� valueSetValidation


270/405

11.2.8.4 Programming Interface Covered 9004

The UDDI version 3 Value Set Validation API consists of one optional API: 9005

• validate_values: A UDDI registry that supports externally validated value sets may 9006 send the validate_values API to the appropriate external validation Web service when 9007 a publisher saves data that uses a value set whose use is regulated by the external 9008 party who controls that Web service. The normal use is to verify that specific 9009 categories or identifiers (keyValues) exist within the given value set. For certain value 9010 sets, the party providing the validation Web service may further restrict the use of a 9011 value based on other information known about the publisher or passed in the API. 9012


The complete process a value set provider must follow to publish and activate a validation 9014 Web service for checked value set is determined by the registry's policy as detailed in Section 9015 9.6.65 Value Set Policies. The following is a typical bindingTemplate for a Web Service that 9016 implements the UDDI Version 3 Value Set Validation API. This Web service is registered by a 9017 value set provider: 9018

<bindingTemplate bindingKey=”” serviceKey=”…”> 9019 <description>UDDI Value Set Validation API V3</description> 9020 <accessPoint useType=”endpoint”> 9021 http://URL_of_service 9022 </accessPoint> 9023 <tModelInstanceDetails> 9024 <tModelInstanceInfo 9025 tModelKey=”uddi:uddi.org:v3_valuesetvalidation” /> 9026 </tModelInstanceDetails> 9027 </bindingTemplate> 9028

9029

11.2.9 UDDI Subscription API 9030


The group of programming interfaces represented by this tModel deals with the subscription of 9032 changed data from a UDDI registry. UDDI nodes can implement a subscription capability 9033 based on this API if they choose, but are not required to do so. The UDDI Subscription API is 9034 comprised of two complementary Web services: one that is implemented by a registry to 9035 enable and manage subscriptions and notify subscribers of changes; and one that can be 9036 implemented by subscribers to receive update notifications from a UDDI registry. See Section 9037 5.5 Subscription API Set. 9038


The UDDI Subscription API provides a simple, complete set of programming interfaces that 9040 subscribers of registry entries can use and/or implement to obtain updates to a UDDI registry. 9041 This API is comprised of two parts. The subscription capability is covered here. The subscriber 9042 portion of the API is covered in Section 11.2.10 UDDI Subscription Listener API. 9043


Name: uddi-org:subscription_v3

Description: UDDI Subscription API

UDDI Key (V3): uddi:uddi.org:v3_subscription

Derived V1,V2 format key: uuid:c6eb3d94-8051-3fbb-9320-a6147e266e57

��

¶

�� valueSetValidation

�� Name: uddi-

org:subscription_v3¶Description: UDDI Subscription API¶UDDI Key (V3):

uddi:uddi.org:v3_subscription¶Derived V1,V2 format key: uuid:f32e8fe3-c054-30e4-ab98-97a19a15988b ¶Categorization: specification, xmlSpec, soapSpec, wsdlSpec ¶��

¶


271/405


9046



<tModel tModelKey=”uddi:uddi.org:v3_subscription”> 9049 <name>uddi-org:subscription_v3</name> 9050 <description>UDDI Subscription API V3.0</description> 9051 <overviewDoc> 9052 <overviewURL useType=”wsdlInterface”> 9053 http://uddi.org/wsdl/uddi_sub_v3_binding.wsdl 9054 </overviewURL> 9055 </overviewDoc> 9056 <overviewDoc> 9057 <overviewURL useType=”text”> 9058 http://uddi.org/pubs/uddi_v3.htm#Sub 9059 </overviewURL> 9060 </overviewDoc> 9061 <categoryBag> 9062 <keyedReference keyName=”uddi-org:types:wsdl” 9063 keyValue="wsdlSpec" 9064 tModelKey="uddi:uddi.org:categorization:types”/> 9065 <keyedReference keyName=”uddi-org:types:soap” 9066 keyValue="soapSpec" 9067 tModelKey="uddi:uddi.org:categorization:types”/> 9068 <keyedReference keyName=”uddi-org:types:xml” 9069 keyValue="xmlSpec" 9070 tModelKey="uddi:uddi.org:categorization:types”/> 9071 <keyedReference keyName=”uddi-org:types:specification” 9072 keyValue="specification" 9073 tModelKey="uddi:uddi.org:categorization:types”/> 9074 </categoryBag> 9075 </tModel> 9076

9077


The UDDI APIs that are covered by this tModel are: 9079

• delete_subscription: Used to remove an existing subscription from the UDDI node. 9080 Notifications of changes will cease. 9081

• get_subscriptions: Used by a publisher to obtain all of the subscriptions that are in 9082 effect for that publisher's account. 9083

• get_notification: Used to request that a notification be resent. 9084

• save_subscription: Used to register new subscription information or update existing 9085 subscription information. 9086


272/405

9087


The following is a typical bindingTemplate for a Web Service that implements the UDDI 9089 Version 3 Subscription API: 9090

<bindingTemplate bindingKey=”…” serviceKey=”…”> 9091 <description>UDDI Subscription API V3</description> 9092 <accessPoint useType=”endpoint”> 9093 https://URL_of_service 9094 </accessPoint> 9095 <tModelInstanceDetails> 9096 <tModelInstanceInfo 9097 tModelKey=”uddi:uddi.org:v3_subscription”> 9098 <instanceDetails> 9099 <instanceParms> 9100 <![CDATA[ 9101 <?xml version=”1.0” encoding=”utf-8” ?> 9102 <UDDIinstanceParmsContainer 9103 xmlns=”urn:uddi-org:policy_v3_instanceParms”> 9104 <authInfoUse>required</authInfoUse> 9105 <filterUsingFindAPI>supported</filterUsingFindAPI> 9106 </UDDIinstanceParmsContainer> 9107 ]]> 9108 </instanceParms> 9109 </instanceDetails> 9110 </tModelInstanceInfo> 9111 <tModelInstanceInfo 9112 tModelKey="uddi:uddi.org:protocol:serverauthenticatedssl3" /> 9113 </tModelInstanceDetails> 9114 </bindingTemplate> 9115

9116

11.2.10 UDDI Subscription Listener API 9117


This tModel complements the UDDI Subscription API. The programming interface represented 9119 by this tModel deals with receiving notifications from a UDDI node that implements the UDDI 9120 Subscription API. This API is implemented by UDDI subscribers when they wish to receive 9121 asynchronous notification of changes to UDDI entities. See Section 5.5 Subscription API Set. 9122


The version 3.0 UDDI SubscriptionListener API defines a programming interface to receive 9124 asynchronous information about changes to UDDI entities that the subscriber previously 9125 expressed interest in using the UDDI Subscription Listener API. 9126


Name: uddi-org:subscriptionListener_v3

Description: UDDI Subscription Listener API

UDDI Key (V3): uddi:uddi.org:v3_subscriptionlistener

Derived V1,V2 format key: uuid:0f965bee-b120-3a66-bdc2-4908819c1174


9129


L3

�� Name: uddi-

org:subscriptionListener_v3¶Description: UDDI Subscription Listener API¶UDDI Key (V3):

uddi:uddi.org:v3_subscriptionListener¶Derived V1, V2 format key: uuid:19a5cf6b-1d76-3b70-9e55-a8df186bd4b3 ¶Categorization: specification, xmlSpec, soapSpec, wsdlSpec ¶��

¶


273/405



<tModel tModelKey=”uddi:uddi.org:v3_subscriptionlistener”> 9132 <name>uddi-org:subscriptionListener_v3</name> 9133 <description>UDDI Subscription Listener API V3.0</description> 9134 <overviewDoc> 9135 <overviewURL useType=”wsdlInterface”> 9136 http://uddi.org/wsdl/uddi_subr_v3_binding.wsdl 9137 </overviewURL> 9138 </overviewDoc> 9139 <overviewDoc> 9140 <overviewURL useType=”text”> 9141 http://uddi.org/pubs/uddi_v3.htm#Subscribe 9142 </overviewURL> 9143 </overviewDoc> 9144 <categoryBag> 9145 <keyedReference keyName=”uddi-org:types:wsdl” 9146 keyValue="wsdlSpec" 9147 tModelKey="uddi:uddi.org:categorization:types”/> 9148 <keyedReference keyName=”uddi-org:types:soap” 9149 keyValue="soapSpec" 9150 tModelKey="uddi:uddi.org:categorization:types”/> 9151 <keyedReference keyName=”uddi-org:types:xml” 9152 keyValue="xmlSpec" 9153 tModelKey="uddi:uddi.org:categorization:types”/> 9154 <keyedReference keyName=”uddi-org:types:specification” 9155 keyValue="specification" 9156 tModelKey="uddi:uddi.org:categorization:types”/> 9157 </categoryBag> 9158 </tModel> 9159

9160


The UDDI version 3 Subscription Listener API consists of a single optional API: 9162

• notify_subscriptionListener: A UDDI node that supports subscription uses this 9163 programming interface to provide programmatic notification of records matching the 9164 criteria of a saved subscription to subscribers that have indicated they should receive 9165 asynchronous updates to subscribed UDDI entities using SOAP. 9166


The following is a typical bindingTemplate for a Web Service that implements the UDDI 9168 Version 3 Subscription Listener API. This Web service is registered by a subscriber of 9169 asynchronous updates to UDDI entities: 9170

<bindingTemplate bindingKey=”…” serviceKey=”…”> 9171 <description>UDDI Subscription Listener API V3</description> 9172 <accessPoint useType=”endpoint”> 9173 http://URL_of_service 9174 </accessPoint> 9175 <tModelInstanceDetails> 9176 <tModelInstanceInfo 9177 tModelKey=”uddi:uddi.org:v3_subscriptionlistener” /> 9178 </tModelInstanceDetails> 9179 </bindingTemplate> 9180

9181

�� subscriptionListener

��

¶



274/405

9182

11.3 Transport and Protocol tModels 9183

tModels of the transport and protocol sort are referenced by service bindings to describe the 9184 type of protocol or transport used to invoke the service. This is often done when other parts of 9185 the technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or 9186 ambiguous with respect to the protocol or transport used by the particular service binding, or 9187 when the provider of the Web service wants to explicitly call out the protocol or transport in the 9188 technical fingerprint, to enable proper discovery. Protocol and transport tModels are frequently 9189 coupled with other tModels that describe what the service does in detail. 9190

The tModels that follow correspond to protocols and transports that are recommended for 9191 different parts of the UDDI API as described in Section 9.6.32 Information Model. The 9192 bindingTemplate structures for the UDDI API described in Section 11.21.9 UDDI Registry API 9193 tModels SHOULD reference one or more of these tModels. 9194

11.3.1 Secure Sockets Layer Version 3 with Server Authentication 9195


The use of Secure Sockets Layer Version 3.0 (SSL 3.0) 40 for transport confidentiality and 9197 server authentication as an application protocol is represented by this tModel. The server 9198 authentication on SSL 3.0 represented by this tModel involves the presentation of a server side 9199 certificate to the client that initiates the SSL 3.0 connection. Web services that require use of 9200 SSL 3.0 SHOULD reference this tModel in their bindingTemplate structures. 9201


There are two principal design goals for the SSL 3.0 with server authentication tModel. The 9203 first is to separate the use of SSL 3.0 described from the application protocol HTTP and also 9204 from the higher level messaging protocol, such as SOAP. The second goal for this tModel is 9205 to facilitate discovery of Web services that support SSL 3.0 for transport confidentiality and 9206 server authentication. 9207


This tModel is used in bindingTemplate elements of Web services to indicate that the Web 9209 service implementation requires the use of SSL 3.0 with server authentication. 9210

Name: uddi-org:serverAuthenticatedSSL3

Description: Secure Sockets Layer 3.0 with Server Authentication

UDDI Key (V3): uddi:uddi.org:protocol:serverauthenticatedssl3

Derived V1,V2 format key: uuid:c8aea832-3faf-33c6-b32a-bbfd1b926294

Categorization: protocol

9212

40

40

http://www.netscape.com/eng/ssl3/draft302.txtindex.html ��

�� -

�� principle

�� Name: uddi-

org:serverAuthenticatedSSL3¶Description: Secure Sockets Layer 3.0 with Server Authentication ¶UDDI Key (V3):

uddi:uddi.org:protocol:serverAuthenticatedSSL3¶Derived V1,V2 format key: uuid:ef6ae0d7-3495-3abc-b420-49938b569f97¶Categorization: protocol ¶


275/405

9213



<tModel 9216 tModelKey=”uddi:uddi.org:protocol:serverauthenticatedssl3”> 9217 <name>uddi-org:serverAuthenticatedSSL3</name> 9218 <description>Secure Sockets Layer Version 3.0 with Server 9219 Authentication</description> 9220 <overviewDoc> 9221 <overviewURL useType=”text”> 9222 http://uddi.org/pubs/uddi_v3.htm#serverSSL3 9223 </overviewURL> 9224 </overviewDoc> 9225 <categoryBag> 9226 <keyedReference keyName=”uddi-org:types:protocol” 9227 keyValue="protocol" 9228 tModelKey="uddi:uddi.org:categorization:types”/> 9229 </categoryBag> 9230 </tModel> 9231

9232


The following is an example of a bindingTemplate for a UDDI Publish API Web service that 9234 uses the SSLv3 with server authentication tModel to represent the transport layer: 9235

<bindingTemplate bindingKey=”uddi:....” serviceKey=”uddi:....”> 9236 <description>UDDI Publication API V3</description> 9237 <accessPoint useType=”endpoint”> 9238 https://URL_of_service 9239 </accessPoint> 9240 <tModelInstanceDetails> 9241 <tModelInstanceInfo 9242 tModelKey=”uddi:uddi.org:v3_publication” /> 9243 <tModelInstanceInfo 9244 tModelKey="uddi:uddi.org:protocol:serverauthenticatedssl3"/> 9245 </tModelInstanceDetails> 9246 </bindingTemplate> 9247

9248

11.3.2 Secure Sockets Layer Version 3 with Mutual Authentication 9249


The use of Secure Sockets Layer Version 3.0 (SSL 3.0) 41 for transport confidentiality and 9251 mutual authentication as an application protocol is represented by this tModel. Mutual 9252 authentication as represented by this tModel includes both client and server authentication. 9253 The server authentication using SSL 3.0 represented by this tModel involves the presentation 9254 of a server side certificate to the client that initiates the SSL 3.0 connection. The client 9255 authentication using SSL 3.0 represented by this tModel involves the server issuing a 9256 certificate request for a client certificate and the client sending a client certificate as described 9257 in the SSL 3.0 specification. Web services that require SSL 3.0 Mutual Authentication 9258 SHOULD reference this tModel in their bindingTemplate structures. 9259

41

http://www.netscape.com/eng/ssl3/index.html


L3


L3


276/405


There are two principal design goals for the SSL 3.0 with mutual authentication tModel. The 9261 first is to separate the use of SSL 3.0 described from the application protocol HTTP and also 9262 from the higher level messaging protocol, such as SOAP. The second goal for this tModel is 9263 to facilitate discovery of UDDI Web services that support SSL 3.0 for transport confidentiality 9264 and mutual authentication. 9265


This tModel is used in bindingTemplate elements of Web services to indicate that the Web 9267 service implementation requires the use of SSL 3.0 with mutual authentication. 9268

Name: uddi-org:mutualAuthenticatedSSL3

Description: Secure Sockets Layer 3.0 with Mutual Authentication

UDDI Key (V3): uddi:uddi.org:protocol:mutualauthenticatedssl3

Derived V1,V2 format key: uuid:9555b5b6-55d4-3b0e-bb17-e084fed4e33f

Categorization: protocol

9270



<tModel 9273 tModelKey=”uddi:uddi.org:protocol:mutualauthenticatedssl3”> 9274 <name>uddi-org:mutualAuthenticatedSSL3</name> 9275 <description>Secure Sockets Layer Version 3.0 with Mutual 9276 Authentication</description> 9277 <overviewDoc> 9278 <overviewURL useType=”text”> 9279 http://uddi.org/pubs/uddi_v3.htm#mutualSSL3 9280 </overviewURL> 9281 </overviewDoc> 9282 <categoryBag> 9283 <keyedReference keyName=”uddi-org:types:protocol” 9284 keyValue="protocol" 9285 tModelKey="uddi:uddi.org:categorization:types”/> 9286 </categoryBag> 9287 </tModel> 9288

9289


The following is an example of a bindingTemplate for a UDDI Replication API Web service 9291 using the SSLv3 with mutual authentication tModel to represent the transport layer: 9292

<bindingTemplate bindingKey=”....” serviceKey=”....”> 9293 <description>UDDI Replication API V3</description> 9294 <accessPoint useType=”endpoint”> 9295 https://URL_of_service 9296 </accessPoint> 9297 <tModelInstanceDetails> 9298 <tModelInstanceInfo 9299 tModelKey=”uddi:uddi.org:v3_replication” /> 9300 <tModelInstanceInfo 9301 tModelKey=" uddi:uddi.org:protocol:mutualauthenticatedssl3" /> 9302 </tModelInstanceDetails> 9303 </bindingTemplate> 9304

�� principle

�� Name: uddi-

org:mutualAuthenticatedSSL3¶Description: Secure Sockets Layer 3.0 with Mutual Authentication ¶UDDI Key (V3):

uddi:uddi.org:protocol:mutualAuthenticatedSSL3¶Derived V1,V2 format key: uuid:1c3152fd-04df-301b-a919-2b28cb80a536¶Categorization: protocol¶


L3


L3


277/405

9305

11.3.3 UDDI HTTP Transport 9306


In UDDI, tModels are used to establish the existence of a variety of concepts and to point to 9308 their technical definitions. Transport tModels are referenced by service bindings to describe the 9309 type of transport used to invoke the service, either when other parts of the technical fingerprint 9310 (other tModels referenced in the same bindingTemplate) do not specify the transport used by 9311 the particular service binding, or when the service provider wants to explicitly call out the 9312 transport in the technical fingerprint so as to enable discovery. Transport tModels are 9313 frequently coupled with other tModels that describe more completely what the service does. 9314 For example, the HTTP Transport tModel may be coupled with the SOAP Protocol tModel to 9315 indicate that a Web service communicates using SOAP over HTTP. The HTTP Transport 9316 tModel provides a means for designating that services transport messages using the HTTP 9317 protocol. 9318


The HTTP Transport tModel is provided to enable discovery of services that transport 9320 messages using the HTTP protocol. This tModel can be used alone to provide a technical 9321 fingerprint for simple services that are accessed through HTTP when they might otherwise not 9322 have a tModel to reference in their bindingTemplates, or it can be used in conjunction with 9323 other protocol tModels to indicate the applicable transport when other parts of the technical 9324 fingerprint are ambiguous or silent with respect to the transport to use. 9325


This tModel is used to describe a Web service that transports messages using the HTTP 9327 protocol. 9328

Name: uddi-org:http

Description: A Web service that uses HTTP transport

UDDI Key (V3): uddi:uddi.org:transport:http

Evolved V1,V2 format key: uuid:68DE9E80-AD09-469D-8A37-088422BFBC36

Categorization: transport

: 9330



<tModel 9333 tModelKey=”uddi:uddi.org:transport:http”> 9334 <name>uddi-org:http</name> 9335 <description> A Web service that uses HTTP transport</description> 9336 <overviewDoc> 9337 <overviewURL useType=”text”> 9338 http://uddi.org/pubs/uddi_v3.htm#overHTTP 9339 </overviewURL> 9340 </overviewDoc> 9341 <categoryBag> 9342 <keyedReference keyName=”uddi-org:types:transport” 9343 keyValue="transport" 9344 tModelKey="uddi:uddi.org:categorization:types”/> 9345

�� GET

�� of the transport sort

�� are silent or ambiguous with

respect to��

proper ��

-type��

For very simple services, a transport tModel may be the only tModel referenced in a bindingTemplate.��

GET ��

those services that are invoked by performing an HTTP GET on��

accessPoint in the bindingTemplate��

GET ��

are invoked by performing an HTTP GET on the accessPoint in the bindingTemplate, to mix-in the applicable transport when other parts of the technical fingerprint are ambiguous or silent with respect to the transport to use, and to enable simple services that are accessed through HTTP to have a technical fingerprint when they might otherwise not have a tModel to reference in their bindingTemplates��

web service that is invoked through a web browser and/or the http protocol.¶Name: uddi-org:http:get¶Description: A ��

accessed by performing an HTTP GET��

UDDI Key (V3): uddi:uddi.org:transport:http:get¶

Evolved V1, V2 format key: uuid:68DE9E80-AD09-469D-8A37-088422BFBC36¶Categorization: transport¶��

:get��

:get��

accessed by performing an HTTP GET

278/405

</categoryBag> 9346 </tModel> 9347 9348


The following is a typical bindingTemplate for a simple service that references the HTTP 9350 Transport tModel: 9351

<bindingTemplate bindingKey=”uddi:....” serviceKey="uddi:...."> 9352 <description xml:lang="en">Buy from Bigfoot Breweries over 9353 the Web</description> 9354 <accessPoint useType=”endpoint” 9355 http://www.bigfootbreweries.example/shop.html 9356 </accessPoint> 9357 <tModelInstanceDetails> 9358 <tModelInstanceInfo 9359 tModelKey="uddi:uddi.org:transport:http /> 9360 </tModelInstanceDetails> 9361 </bindingTemplate> 9362 9363

The next example shows a bindingTemplate for a service whose technical fingerprint (the first 9364 tModel referenced) specifies two alternative access techniques, of which HTTP is one: 9365

<bindingTemplate bindingKey=”uddi:....” serviceKey="uddi:..."> 9366 <description xml:lang="en">Obtain financing</description> 9367 <accessPoint useType=”endpoint”> 9368 http://www.consolidatedholdings.example/finance.html 9369 </accessPoint> 9370  9373 <tModelInstanceDetails> 9374 <tModelInstanceInfo tModelKey="uddi:some.tmodelkey…"/> 9375 </tModelInstanceDetails> 9376  9378 <tModelInstanceDetails> 9379 <tModelInstanceInfo 9380 tModelKey="uddi:uddi.org:transport:http"/> 9381 </tModelInstanceDetails> 9382 </bindingTemplate> 9383

�� :get"

�� tModelKey

�� :get


279/405

9384

11.3.4 UDDI SMTP Transport 9385


In UDDI, tModels are used to establish the existence of a variety of concepts and to point to 9387 their technical definitions. tModels of the transport sort are referenced by service bindings to 9388 describe the type of transport used to invoke the service, either when other parts of the 9389 technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or 9390 ambiguous with respect to the transport used by the particular service binding, or when the 9391 service provider wants to explicitly call out the transport in the technical fingerprint so as to 9392 enable proper discovery. Transport-type tModels are frequently coupled with other tModels 9393 that describe more completely what the service does. For very simple services, a transport 9394 tModel may be the only tModel referenced in a bindingTemplate. The SMTP transport tModel 9395 provides a means for designating those services that are invoked by sending an eMail to the 9396 accessPoint in the bindingTemplate. 9397


The SMTP Transport tModel is provided to enable discovery of services that are invoked by 9399 sending an eMail to the address in the accessPoint element of the bindingTemplate, to mix-in 9400 the applicable transport when other parts of the technical fingerprint are ambiguous or silent 9401 with respect to the transport to use, and to enable simple services that are accessed through 9402 eMail to have a technical fingerprint when they might otherwise not have a tModel to reference 9403 in their bindingTemplates. 9404


This tModel is used to describe a Web service that is invoked through SMTP eMail 9406 transmissions. These transmissions may be either between people or applications. 9407

Name: uddi-org:smtp

Description: E-mail based Web service

UDDI Key (V3): uddi:uddi.org:transport:smtp

Evolved V1,V2 format key: uuid:93335D49-3EFB-48A0-ACEA-EA102B60DDC6




<tModel 9411 tModelKey=”uddi:uddi.org:transport:smtp”> 9412 <name>uddi-org:smtp</name> 9413 <description>E-mail based Web service</description> 9414 <overviewDoc> 9415 <overviewURL useType=”text”> 9416 http://uddi.org/pubs/uddi_v3.htm#overSMTP 9417 </overviewURL> 9418 </overviewDoc> 9419 <categoryBag> 9420 <keyedReference keyName=”uddi-org:types:transport” 9421 keyValue="transport" 9422 tModelKey="uddi:uddi.org:categorization:types”/> 9423 </categoryBag> 9424 </tModel> 9425

�� web

�� Name: uddi-org:smtp¶

Description: E-mail based web service¶UDDI Key (V3):

uddi:uddi.org:transport:smtp¶Evolved V1, V2 format key: uuid:93335D49-3EFB-48A0-ACEA-EA102B60DDC6¶Categorization: transport ¶


280/405

9426


The following is a typical bindingTemplate that references the SMTP Transport tModel: 9428

<bindingTemplate bindingKey=”....” serviceKey="uddi:..."> 9429 <description xml:lang="en">Send eMail to buy from 9430 Island Trading</description> 9431 <accessPoint useType=”endpoint”> 9432 mailto:[email protected] 9433 </accessPoint> 9434 <tModelInstanceDetails> 9435 <tModelInstanceInfo 9436 tModelKey="uddi:uddi.org:transport:smtp"/> 9437 </tModelInstanceDetails> 9438 </bindingTemplate> 9439

9440

11.3.5 UDDI FTP Transport 9441


In UDDI, tModels are used to establish the existence of a variety of concepts and to point to 9443 their technical definitions. tModels of the transport sort are referenced by service bindings to 9444 describe the type of transport used to invoke the service, either when other parts of the 9445 technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or 9446 ambiguous with respect to the transport used by the particular service binding, or when the 9447 service provider wants to explicitly call out the transport in the technical fingerprint so as to 9448 enable proper discovery. Transport-type tModels are frequently coupled with other tModels 9449 that describe more completely what the service does. For very simple services, a transport 9450 tModel may be the only tModel referenced in a bindingTemplate. The FTP transport tModel 9451 provides a means for designating those services that are invoked using the File Transfer 9452 Protocol on the accessPoint in the bindingTemplate. 9453


The FTP Transport tModel is provided to enable discovery of services that are invoked by 9455 performing an FTP on the address in the accessPoint element of the bindingTemplate, to mix-9456 in the applicable transport when other parts of the technical fingerprint are ambiguous or silent 9457 with respect to the transport to use, and to enable simple services that are accessed using 9458 FTP to have a technical fingerprint when they might otherwise not have a tModel to reference 9459 in their bindingTemplates. 9460


This tModel is used to describe a Web service that is invoked through file transfers via the 9462 FTP. 9463

Name: uddi-org:ftp

Description: File Transfer Protocol (FTP) based Web service

UDDI Key (V3): uddi:uddi.org:transport:ftp

Evolved V1,V2 format key: uuid:5FCF5CD0-629A-4C50-8B16-F94E9CF2A674


9465

�� ftp

�� web

�� Name: uddi-org:ftp¶

Description: File Transfer Protocol (FTP) based web service¶UDDI Key (V3):

uddi:uddi.org:transport:ftp¶Evolved V1,V2 format keys: uuid:5FCF5CD0-629A-4C50-8B16-F94E9CF2A674¶Categorization: transport ¶

��

¶


281/405



<tModel 9468 tModelKey=”uddi:uddi.org:transport:ftp”> 9469 <name>uddi-org:ftp</name> 9470 <description>File Transfer Protocol (FTP) based Web service</description> 9471 <overviewDoc> 9472 <overviewURL useType=”text”> 9473 http://uddi.org/pubs/uddi_v3.htm#overFTP 9474 </overviewURL> 9475 </overviewDoc> 9476 <categoryBag> 9477 <keyedReference keyName=”uddi-org:types:transport” 9478 keyValue="transport" 9479 tModelKey="uddi:uddi.org:categorization:types”/> 9480 </categoryBag> 9481 </tModel> 9482

9483


The following is a typical bindingTemplate that references the FTP Transport tModel: 9485

<bindingTemplate bindingKey=”....” serviceKey="uddi:..."> 9486 <description xml:lang="en">Obtain Island Trading product 9487 catalog using FTP</description> 9488 <accessPoint useType=”endpoint”> 9489 ftp://islandtrading.example/catalog 9490 </accessPoint> 9491 <tModelInstanceDetails> 9492 <tModelInstanceInfo 9493 tModelKey="uddi:uddi.org:transport:ftp"/> 9494 </tModelInstanceDetails> 9495 </bindingTemplate> 9496

9497

11.3.6 UDDI Fax Transport 9498


In UDDI, tModels are used to establish the existence of a variety of concepts and to point to 9500 their technical definitions. tModels of the transport sort are referenced by service bindings to 9501 describe the type of transport used to invoke the service, either when other parts of the 9502 technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or 9503 ambiguous with respect to the transport used by the particular service binding, or when the 9504 service provider wants to explicitly call out the transport in the technical fingerprint so as to 9505 enable proper discovery. Transport-type tModels are frequently coupled with other tModels 9506 that describe more completely what the service does. For very simple services, a transport 9507 tModel may be the only tModel referenced in a bindingTemplate. The fax transport tModel 9508 provides a means for designating those services that are invoked using the fax machine on the 9509 accessPoint in the bindingTemplate. 9510


The Fax Transport tModel is provided to enable discovery of services that are invoked by 9512 sending a fax to the address in the accessPoint element of the bindingTemplate, to mix-in the 9513 applicable transport when other parts of the technical fingerprint are ambiguous or silent with 9514 respect to the transport to use, and to enable simple services that are accessed by sending a 9515 fax to have a technical fingerprint when they might otherwise not have a tModel to reference in 9516 their bindingTemplates. 9517

�� web


282/405


This tModel is used to describe a Web service that is invoked through fax transmissions. 9519 These transmissions may be either between people or applications. 9520

Name: uddi-org:fax

Description: Fax-based Web service

UDDI Key (V3): uddi:uddi.org:transport:fax

Evolved V1,V2 format key: uuid:1A2B00BE-6E2C-42F5-875B-56F32686E0E7




<tModel 9524 tModelKey=”uddi:uddi.org:transport:fax”> 9525 <name>uddi-org:fax</name> 9526 <description>Fax-based Web service</description> 9527 <overviewDoc> 9528 <overviewURL useType=”text”> 9529 http://uddi.org/pubs/uddi_v3.htm#overFax 9530 </overviewURL> 9531 </overviewDoc> 9532 <categoryBag> 9533 <keyedReference keyName=”uddi-org:types:transport” 9534 keyValue="transport" 9535 tModelKey="uddi:uddi.org:categorization:types”/> 9536 </categoryBag> 9537 </tModel> 9538

9539


The following is a typical bindingTemplate that references the Fax Transport tModel. Note that 9541 the accessPoint contains a URI using the fax scheme42. 9542

<bindingTemplate bindingKey=”....” serviceKey="uddi:…"> 9543 <description xml:lang="en">Send facsimile to buy from 9544 Island Trading</description> 9545 <accessPoint useType=”endpoint”>fax:+1-800-555-5555</accessPoint> 9546 <tModelInstanceDetails> 9547 <tModelInstanceInfo tModelKey="uddi:uddi.org:transport:fax"/> 9548 </tModelInstanceDetails> 9549 </bindingTemplate> 9550 9551

11.3.7 UDDI Telephone Transport 9552


In UDDI, tModels are used to establish the existence of a variety of concepts and to point to 9554 their technical definitions. tModels of the transport sort are referenced by service bindings to 9555 describe the type of transport used to invoke the service, either when other parts of the 9556 technical fingerprint (other tModels referenced in the same bindingTemplate) are silent or 9557

42

http://www.ietf.org/rfc/rfc2806

�� web

�� Name: uddi-org:fax¶

Description: Fax-based web service¶UDDI Key (V3):

uddi:uddi.org:transport:fax¶Evolved V1,V2 format key: uuid:1A2B00BE-6E2C-42F5-875B-56F32686E0E7¶Categorization: transport ¶

�� web


283/405

ambiguous with respect to the transport used by the particular service binding, or when the 9558 service provider wants to explicitly call out the transport in the technical fingerprint so as to 9559 enable proper discovery. Transport-type tModels are frequently coupled with other tModels 9560 that describe more completely what the service does. For very simple services, a transport 9561 tModel may be the only tModel referenced in a bindingTemplate. The telephone transport 9562 tModel provides a means for designating those services that are invoked using a voice over a 9563 telephone on the accessPoint in the bindingTemplate. 9564


The Telephone Transport tModel is provided to enable discovery of services that are accessed 9566 using voice with a telephone, to mix-in the voice over telephone access technique when other 9567 parts of the technical fingerprint are ambiguous or silent with respect to the way the service is 9568 accessed, and to enable simple services that are accessed by using a telephone to have a 9569 technical fingerprint when they might otherwise not have a tModel to reference in their 9570 bindingTemplates. 9571


This tModel is used to describe a service that is invoked through a telephone call and 9573 interaction by voice and/or touch-tone. 9574

Name: uddi-org:telephone

Description: Telephone based service

UDDI Key (V3): uddi:uddi.org:transport:telephone

Evolved V1,V2 format key: uuid:38E12427-5536-4260-A6F9-B5B530E63A07




<tModel 9578 tModelKey=”uddi:uddi.org:transport:telephone”> 9579 <name>uddi-org:telephone</name> 9580 <description>Telephone based service</description> 9581 <overviewDoc> 9582 <overviewURL useType=”text”> 9583 http://uddi.org/pubs/uddi_v3.htm#overPhone 9584 </overviewURL> 9585 </overviewDoc> 9586 <categoryBag> 9587 <keyedReference keyName=”uddi-org:types:transport” 9588 keyValue="transport" 9589 tModelKey="uddi:uddi.org:categorization:types”/> 9590 </categoryBag> 9591 </tModel> 9592

9593

�� web

�� Name: uddi-

org:telephone¶Description: Telephone based web service¶UDDI Key (V3):

uddi:uddi.org:transport:telephone¶Evolved V1,V2 format key: uuid:38E12427-5536-4260-A6F9-B5B530E63A07¶Categorization: transport ¶

�� web


284/405

9594


The following is a typical bindingTemplate that references the Telephone Specification tModel. 9596 Note that the accessPoint contains a URI using the tel scheme43. 9597

<bindingTemplate bindingKey=”....” serviceKey="uddi:..."> 9598 <description xml:lang="en">Buy from Island Trading over 9599 the phone</description> 9600 <accessPoint useType=”endpoint”>tel:+1-800-555-5555</accessPoint> 9601 <tModelInstanceDetails> 9602 <tModelInstanceInfo 9603 tModelKey="uddi:uddi.org:transport:telephone"/> 9604 </tModelInstanceDetails> 9605 </bindingTemplate> 9606

11.4 Find Qualifier tModels 9607

The tModels in this section are defined to be used when performing inquiry functions to qualify 9608 the inquiry criteria and describe treatment of the results. UDDI requires that all UDDI registries 9609 include these tModels. The designation “Support: Mandatory” indicates the tModel MUST be 9610 supported by UDDI nodes. Short names provided represent the short strings that can be used 9611 to identify the find qualifiers included herein. See Section 5.1.4 Find Qualifiers for more 9612 information. 9613

In UDDI, tModels are used to establish the existence of a variety of concepts and to point to 9614 their technical definitions. tModels of the find qualifier sort are referenced by findQualifier 9615 elements in UDDI inquiries to describe behaviors related to the search input data and 9616 treatment of the result set. 9617

11.4.1 UDDI SQL99 Approximate Match Find Qualifier 9618


The SQL 99 Approximate Match find qualifier allows wildcards to be specified in UDDI name 9620 and keyedReference elements according to the character version of the <like predicate> of 9621 section 8.5 of the SQL 99 specification44. 9622


The SQL99 Approximate Match tModel is provided to enable discovery of UDDI entities when 9624 exact matching criteria is unknown or too restrictive. Approximate matching is performed on 9625 UDDI name, keyValue, and where significant, keyName elements. Wildcards are denoted with 9626 a percent sign (%) to indicate any value for any number of characters and an underscore (_) to 9627 indicate any value for a single character. The backslash character (\) is used as an escape 9628 character for the percent sign, underscore and backslash characters. 9629


This tModel is a find qualifier that is used to enable approximate matching in UDDI inquiries. 9631 This tModel cannot be referenced in a find qualifier if the exactMatch find qualifier tModel is 9632 referenced. By default, case and diacritic sensitive matching is performed on any portion of 9633 the value provided. 9634

43


44 SQL99, ISO/IEC9075-2:1999(E) section 8.5

�� find

�� findQualifiers

�� findQualifier

�� find






285/405

Use of wildcards in the keyValue fields of keyedReferences takes precedence over the effects 9635 of category treatment find qualifiers such as andAllKeys, orAllKeys and orLikeKeys. This 9636 means that the individual elements from the set of keyValues that result from using a wildcard 9637 are not subject to the ANDing and ORing criteria described by these other find qualifiers, but 9638 the set itself is. For example, the inquiry of the form find businesses with services in Georgia 9639 that relate to transporting goods, is specified with Georgia as an explicit keyValue from a 9640 geographic value set, transporting goods as a partial keyValue from a product and services 9641 value set with a trailing wildcard, and the andAllKeys find qualifier (either explicitly specified, or 9642 omitted as it is the default behavior for the categoryBag). The inquiry is performed by finding 9643 the businesses that have the Georgia service location AND a product and services 9644 categorization starting with the product code for transportation of goods. 9645

Name: uddi-org:approximateMatch:SQL99

Short name: approximateMatch

Description: UDDI SQL99 approximate matching find qualifier

UDDI Key (V3): uddi:uddi.org:findqualifier:approximatematch

Derived V1,V2 format key: uuid:8af9e55a-5c35-30dd-915a-8a7961bc1054

Categorization: findQualifier

Support: Mandatory

: 9647



<tModel tModelKey=”uddi:uddi.org:findqualifier:approximatematch”> 9650 <name>uddi-org:exactMatch</name> 9651 <description>UDDI exact name matching find qualifier 9652 </description> 9653 <overviewDoc> 9654 <overviewURL useType=”text”> 9655 http://uddi.org/pubs/uddi_v3.htm#wildcard 9656 </overviewURL> 9657 </overviewDoc> 9658 <categoryBag> 9659 <keyedReference keyName=”uddi-org:types:findQualifier” 9660 keyValue="findQualifier" 9661 tModelKey="uddi:uddi.org:categorization:types”/> 9662 </categoryBag> 9663 </tModel> 9664 9665


The following represent a typical inquiry that uses the SQL99 approximateMatch find qualifier. 9667 This example shows an inquiry using the SQL99 approximateMatch find qualifier to find all 9668 businesses that are either themselves categorized or that have businessService or 9669 bindingTemplate structures categorized with any of the categories in the UNSPSC family 9670 "Telephones and personal telecommunications devices and accessories". In this example a 9671 wildcard character is added to the end of the keyValue specified for a UNSPSC 9672 keyedReference because this value set is formatted hierarchically with more detailed nodes 9673 represented by additional numeric fragments on the right side of the value. 9674

<find_business xmlns="urn:uddi-org:api_v3"> 9675 <findQualifiers> 9676 <findQualifier> 9677




�� Name: uddi-

org:approximateMatch:SQL99¶Short name: approximateMatch¶Description: UDDI SQL99 Approximate Matching findQualifier¶UDDI Key (V3):

uddi:uddi.org:findQualifier:approximateMatch¶Derived V1,V2 format key: uuid:ebddfefd-71e5-3f74-ac95-9671d4aecaba ¶Categorization: findQualifier¶Support: Mandatory ¶<#>tModel Structure¶This tModel is represented with the following structure¶<tModel tModelKey=”uddi:uddi.org:findQualifier:approximateMatch”> <name>uddi-org:approximateMatch:SQL99</name> <description>UDDI approximate matching findQualifier </description> <overviewDoc> <overviewURL useType=”text”> http://uddi.org/pubs/uddi_v3.htm#wildcard </overviewURL> </overviewDoc> <categoryBag> <keyedReference keyName=”uddi-org:types:findQualifier” ��

findQualifier:exactMatch��

approximateMatch:SQL99��

approximate��

findQualifier��

��

exactmatch��

��

represents ��

references��

Exact Name Match findQualifier tModel. All businesses with the name ‘My Company Name’ are returned

� � ��

� � ��


286/405

uddi:uddi.org:findqualifier:approximatematch 9678 </findQualifier> 9679 <findQualifier> 9680 uddi:uddi.org:findqualifier:combinecategorybags 9681 </findQualifier> 9682 </findQualifiers> 9683 <categoryBag> 9684 <keyedReference keyValue="34.10.%" 9685 tModelKey="uddi:uddi.org:ubr:categorization:unspsc"/> 9686 </categoryBag> 9687 </find_business> 9688 9689

11.4.2 UDDI Exact Match Find Qualifier 9690


The Exact Match find qualifier represents the default behavior for matching name, keyValue, 9692 and keyName arguments used in UDDI inquiry functions. This qualifier directs inquiry functions 9693 to find matches based on exactly what has been provided in the input criteria of the inquiry. 9694


The Exact Match find qualifier tModel is provided to enable discovery of UDDI entities with an 9696 exact match on the name, keyValue, and where applicable, keyName arguments, after 9697 normalization. 9698


This tModel is a find qualifier that is used to enable exact matching in UDDI inquiries. When 9700 this tModel is referenced in a find qualifier, only entities with names, keyValues, and where 9701 applicable, keyNames that match the value passed in the input criteria, after normalization, will 9702 be returned. This qualifier conflicts with any approximate match qualifier such as uddi-9703 org:approximateMatch and with uddi-org:caseInsensitiveMatch. 9704

Name: uddi-org:exactMatch

Short name: exactMatch

Description: UDDI Exact Matching find qualifier

UDDI Key (V3): uddi:uddi.org:findqualifier:exactmatch

Derived V1,V2 format key: uuid:05a6e3ef-2e94-3c91-9360-a31cd335c758


Support: Mandatory, default

9706



<tModel 9709 tModelKey=”uddi:uddi.org:findqualifier:exactmatch”> 9710 <name>uddi-org:exactMatch</name> 9711 <description>UDDI exact name matching findQualifier 9712 </description> 9713 <overviewDoc> 9714 <overviewURL useType=”text”> 9715 http://uddi.org/pubs/uddi_v3.htm#exactmatch 9716

�� :exactMatch

�� name>My Company

Name</name��

Case Insensitive��

find��

The Case Insensitive Match findQualifier allows matching to occur on any inquiry involving a name, keyValue, and where relevant, keyName, without regard to the case of the search argument(s)��

Case Insensitive��

findQualifier��

explicitly request��

when case sensitivity is not important��

findQualifier ��

case insensitive��

findQualifier, case is irrelevant in the search results��

all entries, independent of case,��

exactly ��

values��

search arguments��

This qualifier is ignored for languages that are not case-significant and cannot be used with the uddi-org:exactMatch or the uddi-org:caseSensitiveMatch findQualifiers��

Name: uddi-org:caseInsensitiveMatch¶Short name:

caseInsensitiveMatch¶Description: UDDI Case Insensitive Matching findQualifier¶UDDI Key (V3):

uddi:uddi.org:findQualifier:caseInsensitiveMatch¶Derived V1,V2 format key: uuid:51a80341-a1cd-3742-8bcd-d6995e6948aa ¶Categorization: findQualifier¶Support: Mandatory¶��

��

findQualifier:caseInsensitiveMatch��

caseInsensitiveMatch��

Case Insensitive Matching��

��

caseinsens


287/405

</overviewURL> 9717 </overviewDoc> 9718 <categoryBag> 9719 <keyedReference keyName=”uddi-org:types:findQualifier” 9720 keyValue="findQualifier" 9721 tModelKey="uddi:uddi.org:categorization:types”/> 9722 </categoryBag> 9723 </tModel> 9724 9725


The following represents a typical inquiry that references the Exact Name Match find qualifier 9727 tModel. All businesses with the name ‘rosetta’ are returned. 9728

<find_tModel xmlns="urn:uddi-org:api_v3"> 9729 <findQualifiers> 9730 <findQualifier> 9731 uddi:uddi.org:findqualifier:exactmatch 9732 </findQualifier> 9733 </findQualifiers> 9734 <name>rosetta%</name> 9735 </find_tModel> 9736 9737

11.4.3 UDDI Case Sensitive Match Find Qualifier 9738


The Case Sensitive Match find qualifier allows matching to occur on any inquiry involving a 9740 name, keyValue, and where relevant, keyName, where the case of the search argument(s). 9741


The Case Sensitive Match find qualifier tModel is provided to enable discovery of the case 9743 sensitivity is not important. 9744


This tModel is a find qualifier that is used to enable case sensitive matching in UDDI inquiries. 9746 When this tModel is referenced in a find qualifier, case is relevant in the search results and all 9747 entries that match the value passed in the search arguments will be returned. This qualifier is 9748 ignored for languages that are not case-significant and cannot be used with the uddi-9749 org:exactMatch or the uddi-org:caseSensitiveMatch find qualifiers. 9750

Name: uddi-org:caseInsensitiveMatch

Short name: caseInsensitiveMatch

Description: UDDI case insensitive matching find qualifier

UDDI Key (V3): uddi:uddi.org:findqualifier:caseinsensitivematch

Derived V1,V2 format key: uuid:9e217abc-51f0-3703-ba50-ccd9177040f0


Support: Mandatory

9752

��

�� ¶��

Case Insensitive Match findQualifier��

tModels that start��

My Company Name’��

, without regard to case��

business��

findQualifier:caseInsensitiveMatch </findQualifier> <findQualifier> uddi:uddi.org:findQualifier:approximateMatch��

My Company Name��

business��

Insensitive��

find��

Insensitive��

findQualifier��

without regard to ��

UDDI data must match case of the ��

Insensitive��

findQualifier��

the implied default for both approximate and exact matching. It is ��

allow explicit specification��

UDDI entities when��

criterion for the inquiry function��


specify��

in��

(the default) ��

findQualifier��

ir��

, independent of case,��

��

caseInsensitiveMatch findQualifier.¶Name: ��

Short name: caseSensitiveMatch¶

Description: UDDI Case Sensitive Matching findQualifier¶UDDI Key (V3):

uddi:uddi.org:findQualifier:caseSens� � � � ��


288/405



<tModel 9755 tModelKey=”uddi:uddi.org:findqualifier:caseinsensitivematch”> 9756 <name>uddi-org:caseSensitiveMatch</name> 9757 <description>UDDI case insensitive matching find qualifier 9758 </description> 9759 <overviewDoc> 9760 <overviewURL useType=”text”> 9761 http://uddi.org/pubs/uddi_v3.htm#casesens 9762 </overviewURL> 9763 </overviewDoc> 9764 <categoryBag> 9765 <keyedReference keyName=”uddi-org:types:findQualifier” 9766 keyValue="findQualifier" 9767 tModelKey="uddi:uddi.org:categorization:types”/> 9768 </categoryBag> 9769 </tModel> 9770 9771


The following represents a typical inquiry that references the Case Insensitive Match find 9773 qualifier tModel. All tModels that start with the name ‘rosetta’ are returned, without regard to 9774 case. 9775

<find_tModel xmlns="urn:uddi-org:api_v3"> 9776 <findQualifiers> 9777 <findQualifier> 9778 uddi:uddi.org:findqualifier:caseinsensitivematch 9779 </findQualifier> 9780 <findQualifier> 9781 uddi:uddi.org:findqualifier:approximatematch 9782 </findQualifier> 9783 </findQualifiers> 9784 <name>rosetta%</name> 9785 </find_tModel> 9786

9787

11.4.4 UDDI Case Sensitive Match Find Qualifier 9788


The Case Sensitive Match find qualifier allows matching to occur on any inquiry involving a 9790 name, keyValue, and where relevant, keyName, where the case of the UDDI data must match 9791 case of the search argument(s). 9792


The Case Sensitive Match find qualifier tModel is the implied default for both approximate and 9794 exact matching. It is provided to allow explicit specification of the case sensitivity criterion for 9795 the inquiry function. 9796


This tModel is a find qualifier that is used to specify case sensitive matching in UDDI inquiries. 9798 When this tModel is referenced in a find qualifier, case is relevant in the searched data and all 9799 entries that match the value passed in the input criteria will be returned. This qualifier is 9800

�� findQualifier:caseSen

sitiveMatch��

caseInsensitiveMatch��

Case Sensitive Matching findQualifier��

caseinsens�� ¶��

Sensitive Match findQualifier��

Note that because case sensitive matching is the default for inquiry functions, specification of this findQualifier is not necessary. This example finds tModels that are categorized with a rating of AAA from the example: Rating informal category system��

findQualifier:caseSensitiveMatch��

findQualifier:approximateMatch��

categoryBag> <keyedReference tModelKey=”uddi:uddi.org:categorization:generalKeywords” keyName=”example:Rating” keyValue=”AAA” /> </categoryBag��

Diacritics Insensitive��

find��

The Diacritics Insensitive Match findQualifier allows matching without regard to diacritics in the searched data��

The Diacritics Insensitive Match findQualifier tModel is provided to enable discovery of UDDI entities when diacritics sensitivity is not ��


enable diacritics in��


��

findQualifier, diacritic symbols (e.g. accents, diaeresis, ��

search results��

, independent of diacritics,��

base characters��


This qualifier uses as diacritics, that set of characters defined to constitute diacritics in the

� � ��

� � ��

� � ��


289/405

ignored for languages that are not case-significant and cannot be used with the uddi-9801 org:caseInsensitiveMatch find qualifier. 9802

Name: uddi-org:caseSensitiveMatch

Short name: caseSensitiveMatch

Description: UDDI Case Sensitive Matching find qualifier

UDDI Key (V3): uddi:uddi.org:findqualifier:casesensitivematch

Derived V1,V2 format key: uuid:272a64a3-73c8-3b3d-9560-c7dfaa79cc6d



9804



<t Model 9807 t Model Key=” uddi : uddi . or g: f i ndqual i f i er : casesensi t i vemat ch” > 9808 <name>uddi - or g: caseSensi t i veMat ch</ name> 9809 <descr i pt i on>UDDI Case Sensi t i ve Mat chi ng f i nd qual i f i er 9810 </ descr i pt i on> 9811 <over vi ewDoc> 9812 <over vi ewURL useType=” t ext ” > 9813 ht t p: / / uddi . or g/ pubs/ uddi _v3. ht m#casesens 9814 </ over vi ewURL> 9815 </ over vi ewDoc> 9816 <cat egor yBag> 9817 <keyedRef er ence keyName=” uddi - or g: t ypes: f i ndQual i f i er ” 9818 keyVal ue=" f i ndQual i f i er " 9819 t Model Key=" uddi : uddi . or g: cat egor i zat i on: t ypes” / > 9820 </ cat egor yBag> 9821 </ t Model > 9822 9823


The following represents a typical inquiry that references the Case Sensitive Match find 9825 qualifier tModel. Note that because case sensitive matching is the default for inquiry functions, 9826 specification of this find qualifier is not necessary. This example finds tModels that are 9827 categorized with a rating of AAA from the example: Rating informal category system. 9828

<f i nd_t Model xml ns=" ur n: uddi - or g: api _v3" > 9829 <f i ndQual i f i er s> 9830 <findQualifier> 9831 uddi:uddi.org:findqualifier:casesensitivematch 9832 </findQualifier> 9833 <f i ndQual i f i er > 9834 uddi : uddi . or g: f i ndqual i f i er : appr oxi mat emat ch 9835 </ f i ndQual i f i er > 9836 </ f i ndQual i f i er s> 9837 <cat egor yBag> 9838 <keyedRef er ence 9839 t Model Key=” uddi : uddi . or g: cat egor i zat i on: gener al _keywor ds” 9840 keyName=” exampl e: Rat i ng” 9841 keyVal ue=” AAA” / > 9842 </ cat egor yBag> 9843 </ f i nd_t Model > 9844

�� diacritics

�� exactMatch or uddi-

org:diacriticsSensitiveMatch findQualifiers��

Name: uddi-org:diacriticsInsensitiveMatch¶Short name:

diacriticsInsensitiveMatch¶Description: UDDI Diacritics Insensitive Matching findQualifier¶UDDI Key (V3):

uddi:uddi.org:findQualifier:diacriticsInsensitiveMatch¶Derived V1,V2 format key: uuid:9898243a-4a9c-3db0-9df1-9d216ea5fe32¶Categorization: findQualifier¶Support: Optional¶

�� f i ndQual i f i er : di acr i t

i cs I nsens i t i veMat ch��

di acr i t i cs I nsens i t i veMat ch��

Di acr i t i cs I nsens i t i ve��

f i ndQual i f i er��

di acr i t I nsens

��

�� Diacritics Insensitive Match

findQualifier��

All tModels that start with the name ‘Forte’ are returned, without regard to diacritics, even when the supplied search pattern, ‘Forté’ has a diacritic

�� findQualifier:diacrit

icsInsensitiveMatch

�� f i ndQual i f i er : appr ox i

mat eMat ch

�� name>For t é%</ name

�� ¶

¶


290/405

9845

11.4.5 UDDI Diacritics Sensitive Match Find Qualifier 9846


The Diacritics Sensitive Match find qualifier allows matching to diacritics in the UDDI data. 9848


The Case Sensitive Match find qualifier tModel is provided to enable discovery of the case 9850 sensitivity is not important. 9851


This tModel is a find qualifier that is used to specify case sensitive matching in UDDI inquiries. 9853 When this tModel is referenced in a find qualifier, diacritic symbols (e.g. accents, diaeresis, 9854 cedilla) are irrelevant in the searched data and all entries that match the value passed in the 9855 input criteria will be returned. This qualifier is ignored for languages that are not diacritics-9856 significant and cannot be used with uddi-org:exactMatch or uddi-org:diacriticsSensitiveMatch 9857 find qualifiers. 9858

Name: uddi-org:diacriticsInsensitiveMatch

Short name: diacriticsInsensitiveMatch

Description: UDDI Diacritics Insensitive Matching find qualifier

UDDI Key (V3): uddi:uddi.org:findqualifier:diacriticsinsensitivematch

Derived V1,V2 format key: uuid:81479f4e-018a-3e8a-9ef4-2c87232b6b19


Support: Optional

: 9860



<tModel 9863 tModelKey=”uddi:uddi.org:findqualifier:diacriticsinsensitivematch”> 9864 <name>uddi-org:diacriticsSensitiveMatch</name> 9865 <description>UDDI Diacritics Sensitive Matching find qualifier 9866 </description> 9867 <overviewDoc> 9868 <overviewURL useType=”text”> 9869 http://uddi.org/pubs/uddi_v3.htm#diacritSens 9870 </overviewURL> 9871 </overviewDoc> 9872 <categoryBag> 9873 <keyedReference keyName=”uddi-org:types:findQualifier” 9874 keyValue="findQualifier" 9875 tModelKey="uddi:uddi.org:categorization:types”/> 9876 </categoryBag> 9877 </tModel> 9878

�� Insensitive

�� find

�� Insensitive


�� without regard

�� occur on any inquiry

involving a name, keyValue, and where relevant, keyName, where the ��

searched��

must match diacritics in the search argument(s)��

Diacritics Insensitive��

findQualifier��

the implied default for both approximate and exact matching. It is ��

allow explicit specification��

UDDI entities when diacritics��

criterion for the inquiry function��


enable diacritics in��


��

findQualifier, case is ��

search results��

, independent of diacritics,��

base characters��


This qualifier uses as diacritics, that set of characters defined to constitute diacritics in the Default Unicode Collation Element Table46. ��

the ��

diacriticsInsensitiveMatch findQualifier.¶Name: ��

Short name: diacriticsSensitiveMatch¶

Description: UDDI Diacritics Sensitive Matching findQualifier¶UDDI Key (V3): ��

findQualifier:diacrit��

diacriticsInsensitive��

Insensitive��

findQualifier��

diacritInsens��

� � � ��

� � � ��


291/405

9879


The following represents a typical inquiry that references the Diacritics Insensitive Match find 9881 qualifier tModel. All tModels that start with the name ‘Forte’ are returned, without regard to 9882 diacritics, even when the supplied search pattern, ‘Forté’ has a diacritic. 9883

<f i nd_t Model xml ns=" ur n: uddi - or g: api _v3" > 9884 <f i ndQual i f i er s> 9885 <findQualifier> 9886 uddi:uddi.org:findqualifier:diacriticsinsensitivematch 9887 </findQualifier> 9888 <f i ndQual i f i er > 9889 uddi : uddi . or g: f i ndqual i f i er : appr oxi mat emat ch 9890 </ f i ndQual i f i er > 9891 </ f i ndQual i f i er s> 9892 <name>For t é%</ name> 9893 </ f i nd_t Model > 9894 9895 9896

11.4.6 UDDI Diacritics Sensitive Match Find Qualif ier 9897


The Diacritics Sensitive Match find qualifier allows matching to occur on any inquiry involving a 9899 name, keyValue, and where relevant, keyName, where the diacritics in the UDDI data must 9900 match diacritics in the search argument(s). 9901


The Case Sensitive Match find qualifier tModel is the implied default for both approximate and 9903 exact matching. It is provided to allow explicit specification of the case sensitivity criterion for 9904 the inquiry function. 9905


This tModel is a find qualifier that is used to enable binary sorting of UDDI inquiries. When this 9907 tModel is referenced in a find qualifier, case is relevant in the search results and all entries that 9908 match the value passed in the search arguments will be returned. This qualifier is ignored for 9909 languages that are not diacritics-significant and cannot be used with uddi-9910 org:diacriticsInsensitiveMatch find qualifier. 9911

Name: uddi-org:diacriticsSensitiveMatch

Short name: diacriticsSensitiveMatch

Description: UDDI Diacritics Sensitive Matching find qualifier

UDDI Key (V3): uddi:uddi.org:findqualifier:diacriticssensitivematch

Derived V1,V2 format key: uuid:ff85bfaf-1421-39a5-8207-d4df87fc2b17


�� Sensitive Match

findQualifier��

Note that because diacritic sensitive matching is the default for inquiry functions, specification of this findQualifier is not necessary. This example finds tModels that have names that start with Garçon��

findQualifier:diacriticsSensitiveMatch��

f i ndQual i f i er : appr ox imat eMat ch��

xml : l ang=” f r -ca” >Gar çon��

�� <#>UDDI Binary Sort

sortOrder quali fier¶

�� The sortOrder type of

findQualifier (a subset of findQualifier) represents a collation sequence applied to the result set. The Binary Sort sortOrder findQualifier directs that a binary sort be performed on the result set��

The Binary Sort sortOrder tModel is provided to direct inquiry results to be binary sorted


�� specify case sensitive

matching (the default) in ��

inquiry results. When this tModel is referenced in a findQualifier, a binary sort is performed on the name field, normalized using Unicode Normalization Form C47. This qualifier conflicts with any other findQualifier of the sortOrder type��

Name: uddi-org:binarySort¶Short name: binarySort¶Description: UDDI Binary Sort collation sequence findQualifier¶UDDI Key (V3):

uddi:uddi.org:sortOrder:binarySort¶Derived V1,V2 format key: uuid:3b16998b-86af-38c3-974d-e91c02d5a7d0 ¶Categorization: sortOrder, findQualifier¶Support: Mandatory ¶


292/405


9913



<t Model t Model Key=” uddi : uddi . or g: f i ndqual i f i er : di acr i t i cssensi t i vemat ch” > 9916 <name>uddi - or g: bi nar ySor t </ name> 9917 <descr i pt i on>UDDI Di acr i t i cs Sensi t i ve Mat chi ng f i nd qual i f i er 9918 </ descr i pt i on> 9919 <over vi ewDoc> 9920 <over vi ewURL useType=” t ext ” > 9921 ht t p: / / uddi . or g/ pubs/ uddi _v3. ht m#sor t Or d 9922 </ over vi ewURL> 9923 </ over vi ewDoc> 9924 <cat egor yBag> 9925 <keyedRef er ence keyName=” uddi - or g: t ypes: f i ndQual i f i er ” 9926 keyVal ue=" f i ndQual i f i er " 9927 t Model Key=" uddi : uddi . or g: cat egor i zat i on: t ypes” / > 9928 </ cat egor yBag> 9929 </ t Model > 9930

9931


The following represents a typical inquiry that references the Diacritics Sensitive Match find 9933 qualifier tModel. Note that because diacritic sensitive matching is the default for inquiry 9934 functions, specification of this find qualifier is not necessary. This example finds tModels that 9935 start with Garçon. 9936

<f i nd_t Model xml ns=" ur n: uddi - or g: api _v3" > 9937 <f i ndQual i f i er s> 9938 <findQualifier> 9939 uddi:uddi.org:findqualifier:diacriticssensitivematch 9940 </findQualifier> 9941 <f i ndQual i f i er > 9942 uddi : uddi . or g: f i ndqual i f i er : appr oxi mat emat ch 9943 </ f i ndQual i f i er > 9944 </ f i ndQual i f i er s> 9945 <name>Roset t a%</ name> 9946 </ f i nd_t Model > 9947

9948

11.4.7

��

�� sor t Or der : bi nar ySor t

�� di acr i t i csSens i t i veMa

t ch��

bi nar y sor t sor t Or der��

di acr i t Sens

�� sor t Or der ”

keyVal ue=" sor t Or der " t Model Key=" uddi : uddi . or g: categor i zat i on: t ypes” / > <keyedRef er ence keyName=” uddi - or g: t ypes:��

��

�� Binary Sort sortOrder

findQualifier��

all ��

have names that ��

‘Rosetta’, without regard to case and sorts the tModels that satisfy this criterion by date, oldest to newest, and within date, by name using a binary sorting collation sequence��

sortOrder:binarySort��

f i ndQual i f i er : sor t ByDat eAsc </ f i ndQual i f i er > <f i ndQual i f i er > uddi : uddi . or g: f i ndQual i f i er :appr ox i mat eMat ch </ f i ndQual i f i er > <f i ndQual i f i er > uddi : uddi . or g: f i ndQual i f i er :caseI nsens i t i veMat ch��

xml : l ang=” f r -ca” >Gar çon��

UDDI Unicode Technical Standard #10 sortOrder qualifier


293/405

9949

11.4.8 UDDI Binary Sort Order Qualifier 9950


The sortOrder type of find qualifier (a subset of find qualifier) represents a collation sequence 9952 applied to the result set. The Binary Sort sortOrder find qualifier directs that a sort be 9953 performed on the result set. 9954


The Binary Sort sortOrder tModel is provided to direct inquiry results to be sorted. 9956


This tModel is a find qualifier that is used to enable sorting of UDDI inquiry results. When this 9958 tModel is referenced in a find qualifier, a binary sort is performed on the name field, normalized 9959 using Unicode Normalization Form C. This qualifier conflicts with any other find qualifier of the 9960 sortOrder type. 9961

Name: uddi-org:binarySort

Short name: binarySort

Description: UDDI Binary Sort collation sequence find qualifier

UDDI Key (V3): uddi:uddi.org:sortorder:binarysort

Derived V1,V2 format key: uuid:c0d82cac-38fe-3a0d-982c-50e0e1253eb1

Categorization: sortOrder, findQualifier

Support: Mandatory



<tModel tModelKey=”uddi:uddi.org:sortorder:binarysort”> 9965 <name>uddi-org:UTS-10</name> 9966 <description>UDDI binary sort sortOrder qualifier 9967 </description> 9968 <overviewDoc> 9969 <overviewURL useType=”text”> 9970 http://uddi.org/pubs/uddi_v3.htm#sortOrd 9971 </overviewURL> 9972 </overviewDoc> 9973 <categoryBag> 9974 <keyedReference keyName=”uddi-org:types:sortOrder” 9975 keyValue="sortOrder" 9976



�� Unicode Technical Standard

#10 (UTS-10) sortOrder findQualifier��

binary ��

Unicode Normalization Form C48 representation of ��

elements��

Unicode Technical Standard #10��

enable��

binary ��

according to the Unicode Technical Standard #10 Collation Order49

�� ¶��

findQualifier��

binary ��

based on the Unicode Technical Standard 10 Collation Order on elements normalized according to Unicode Normalization Form C��

findQualifier, a��

according to the Default Unicode Collation Element Table in conjunction with Unicode Collation Algorithm50 �� 51


�� , such as

uddi.org:binarySort:��

Name: uddi-org:UTS-10¶Short name: UTS-10¶Description: UDDI Unicode Technical Standard #10 sort collation sequence findQualifier¶UDDI Key (V3):

uddi:uddi.org:sortOrder:UTS-10¶Derived V1,V2 format key: uuid:06472c03-7453-3cb1-803c-4df859c1429d ¶Categorization: sortOrder, findQualifier¶Support: Recommended ¶��

sortOrder:UTS-10��

binarySort��

Unicode Technical Standard #10 �� collation ��

UCASort

� � ��


294/405

tModelKey="uddi:uddi.org:categorization:types”/> 9977 <keyedReference keyName=”uddi-org:types:findQualifier” 9978 keyValue="findQualifier" 9979 tModelKey="uddi:uddi.org:categorization:types”/> 9980 </categoryBag> 9981 </tModel> 9982

9983


The following represents a typical inquiry that references the Binary Sort sortOrder find 9985 qualifier tModel. This example finds all tModels that start with ‘Rosetta’, without regard to case 9986 and sorts the tModels that satisfy this criterion by date, oldest to newest, and within date, by 9987 name using a binary sorting collation sequence. 9988

<find_tModel xmlns="urn:uddi-org:api_v3"> 9989 <findQualifiers> 9990 <findQualifier> 9991 uddi:uddi.org:sortorder:binarysort 9992 </findQualifier> 9993 <findQualifier> 9994 uddi:uddi.org:findqualifier:sortbydateasc 9995 </findQualifier> 9996 <findQualifier> 9997 uddi:uddi.org:findqualifier:approximatematch 9998 </findQualifier> 9999 <findQualifier> 10000 uddi:uddi.org:findqualifier:caseinsensitivematch 10001 </findQualifier> 10002 </findQualifiers> 10003 <name>Rosetta%</name> 10004 </find_tModel> 10005

10006

11.4.9 UDDI Case Insensitive Sort findQualifier 10007


The sortOrder type of find qualifier (a subset of find qualifier) represents a collation sequence 10009 applied to the result set. The Unicode Technical Standard #10 (UTS-10) sortOrder find qualifier 10010 directs that a sort be performed on the Unicode Normalization Form C52 representation of 10011 result set elements. 10012


The Unicode Technical Standard #10 sortOrder tModel is provided to enable inquiry results to 10014 be sorted according to the Unicode Technical Standard #10 Collation Order53. 10015

52

http://www.unicode.org/unicode/reports/tr15/

53 http://www.unicode.org/unicode/reports/tr10/

��

��

�� Unicode Technical Standard

#10 sortOrder findQualifier ��

This example finds businesses or their contained businessService or bindingTemplate structures that are categorized with any value using the ‘tempuri-org:CustomerType’ value set. The businessEntity structures so found are sorted first by name and for those that share a common name, by date, using the Unicode Technical Standard #10��

business ��

sortOrder:UTS-10��

:sortByDateDesc��

findQualifier:sortByNameAsc </findQualifier> <findQualifier> uddi:uddi.org:findQualifier:approximateMatch </findQualifier> <findQualifier> uddi:uddi.org:findQualifier:combineCategoryBags��

categoryBag> <keyedReference keyValue="%" keyName="tempuri-org:CustomerType" tModelKey="uddi:uddi.org:categorization:general_keywords"/> </categoryBag></find_business��

¶��

Unicode Technical Standard #10��

Order ��

The Case Insensitive Sort findQualifier directs that the result set be sorted without regard to case, using the collation sequence specified��

The purpose of the Case Insensitive Sort findQualifier is to provide a means for requesting the results to be sorted without regard to case. For result set elements that have names, this find qualifier uses the sorting sequence in effect, but without regard to case, sorting on the first name element contained in each result element


295/405

10016


This tModel is a find qualifier that is used to enable sorting of UDDI inquiry results using the 10018 collation sequence findQualifier in effect, but without regard to Unicode Normalization Form C. 10019 When this tModel is referenced in a find qualifier, a sort is performed according to the Default 10020 Unicode Collation Element Table in conjunction with Unicode Collation Algorithm54 on the 10021 name field, normalized using Unicode Normalization Form C. This qualifier conflicts with any 10022 other find qualifier of the uddi.org:binarySort: 10023

Name: uddi-org:UTS-10

Short name: UTS-10

Description: UDDI Unicode Technical Standard #10 sort collation sequence find qualifier

UDDI Key (V3): uddi:uddi.org:sortorder:uts-10

Derived V1,V2 format key: uuid:d93662bc-d3f5-3aab-8245-70bafc3b00dd


Support: Recommended

10025



<tModel tModelKey=”uddi:uddi.org:sortorder:uts-10”> 10028 <name>uddi-org:UTS-10</name> 10029 <description>UDDI sort 10030 collation sequence find qualifier 10031 </description> 10032 <overviewDoc> 10033 <overviewURL useType=”text”> 10034 http://uddi.org/pubs/uddi_v3.htm#UCASort 10035 </overviewURL> 10036 </overviewDoc> 10037 <categoryBag> 10038 <keyedReference keyName=”uddi-org:types:sortOrder” 10039 keyValue="sortOrder" 10040 tModelKey="uddi:uddi.org:categorization:types”/> 10041 </categoryBag> 10042 </tModel> 10043

54



�� ordering

�� based on the Unicode

Technical Standard 10 Collation Order on elements normalized according��

case. This sort qualifier is applied prior to any truncation of result sets and is only applicable to inquiries that return a name element in the top-most detail level of the result set. ��

sortOrder type, such as ��

-��

and the uddi-org:caseSensitiveSort sort qualifiers. When a sort qualifier is also provided for the Date (uddi-org:sortByDateAsc or uddi-org:sortByDateDesc), the sort is first performed on the name fields. Results that share the same name are then sorted by date.��

Name: uddi-org: caseInsensitiveSort¶Short name: caseInsensitiveSort¶Description: UDDI sort qualifier used to sort results without regard to case¶UDDI Key (V3):

uddi:uddi.org:findQualifier:caseInsensitiveSort¶Derived V1,V2 format key:uuid:aa441fda-ce7d-31a7-995c-51ee1d359d3d¶Categorization: findQualifier¶Support: Mandatory ¶��

findQualifier:caseInsensitiveSort��

caseInsensitiveSort��

Unicode Technical Standard #10 ��

used to sort results without regard to case��

caseInsensSort��

findQualifier��

findQualifier��

<keyedReference keyName=”uddi-org:types:findQualifier” keyValue="findQualifier" tModelKey="uddi:uddi.org:categorization:types”/>


296/405

10044


The following represents a typical inquiry that references the Unicode Technical Standard #10 10046 sortOrder find qualifier tModel. This inquiry seeks businesses that have Web service bindings 10047 that share a common name, by date, using the Unicode Technical Standard #10 collation 10048 sequence. 10049

<find_business xmlns="urn:uddi-org:api_v3"> 10050 <findQualifiers> 10051 <findQualifier> 10052 uddi:uddi.org:sortorder:uts-10 10053 </findQualifier> 10054 <findQualifier> 10055 uddi:uddi.org:findqualifier:sortbydatedesc 10056 </findQualifier> 10057 <findQualifier> 10058 uddi:uddi.org:findqualifier:sortbynameasc 10059 </findQualifier> 10060 <findQualifier> 10061 uddi:uddi.org:findqualifier:approximatematch 10062 </findQualifier> 10063 <findQualifier> 10064 uddi:uddi.org:findqualifier:combinecategorybags 10065 </findQualifier> 10066 </findQualifiers> 10067 <categoryBag> 10068 <keyedReference keyValue="%" 10069 keyName="tempuri-org:CustomerType" 10070 tModelKey="uddi:uddi.org:categorization:general_keywords"/> 10071 </categoryBag> 10072 </find_business> 10073

10074

11.4.10 UDDI Case Sensitive Sort Find Qualifier 10075


The Case Sensitive Sort find qualifier directs that the result set be sorted according to case, 10077 using the collation sequence specified. 10078

11.4.10.2 Design Goals 10079

The purpose of the Case Insensitive Sort find qualifier is to provide a means for requesting the 10080 results to be sorted without regard to case. For result set elements that have names, this find 10081 qualifier uses the sorting sequence in effect, but without regard to case, sorting on the first 10082 name element contained in each result element. 10083

�� ¶

�� Case Insensitive Sort sort

�� This example finds

businesses or their contained businessService or bindingTemplate structures that are categorized with any value using the ‘tempuri-org:CustomerType’ value set. The businessEntity structures so found are sorted first by name and for those��

implement��

RosettaNet interface and sorts the businesses returned��

but without regard to case��

:caseInsensitiveSort��

sortOrder:UTS-10

�� !--find businesses

that have bindings that reference the RosettaNet tModels --> <find_tModel> <findQualifiers> <findQualifier> uddi:uddi.org:findQualifier:approximateMatch </findQualifier> <findQualifier> uddi:uddi.org:findQualifier:caseInsensitiveMatch </findQualifier> </findQualifiers> <name>Rosetta%</name> </find_tModel��

¶��

Insensitive��

find��

Insensitive��

findQualifier��

without regard��

The Case Sensitive Sort findQualifier tModel is the implied default for sorting. It is provided to allow explicit specification of the case sensitivity criterion for the inquiry sorting function.¶


297/405

10084


This tModel is a find qualifier that is used to enable ordering of UDDI inquiry results using the 10086 collation sequence find qualifier in effect, taking case. This sort qualifier is applied prior to any 10087 truncation of result sets and is only applicable to inquiries that return a name element in the 10088 top-most detail level of the result set. This qualifier conflicts with the uddi-10089 org:caseInsensitiveSort sort qualifier. When a sort qualifier is also provided for the Date (uddi-10090 org:sortByDateAsc or uddi-org:sortByDateDesc), the sort is first performed on the name fields. 10091 Results that share the same name are then sorted by date. 10092

Name: uddi-org: caseInsensitiveSort

Short name: caseInsensitiveSort

Description: UDDI sort qualifier used to sort results without regard to case

UDDI Key (V3): uddi:uddi.org:findqualifier:caseinsensitivesort

Derived V1,V2 format key: uuid:9240a18a-915c-3352-9112-55b3c1b2aa7f


Support: Mandatory

10094



<tModel tModelKey=”uddi:uddi.org:findqualifier:caseinsensitivesort”> 10097 <name>uddi-org:caseSensitiveSort</name> 10098 <description>UDDI sort qualifier used to sort results using 10099 case sensitivity</description> 10100 <overviewDoc> 10101 <overviewURL useType=”text”> 10102 http://uddi.org/pubs/uddi_v3.htm#caseSensSort 10103 </overviewURL> 10104 </overviewDoc> 10105 <categoryBag> 10106 <keyedReference keyName=”uddi-org:types:findQualifier” 10107 keyValue="findQualifier" 10108 tModelKey="uddi:uddi.org:categorization:types”/> 10109 </categoryBag> 10110 </tModel> 10111



�� but without regard to

�� into consideration

�� binarySort and the uddi-

org:caseSensitiveSort��

s��

Name: uddi-org: caseSensitiveSort¶Short name: caseSensitiveSort¶Description: UDDI sort qualifier used to sort results considering case¶UDDI Key (V3):

uddi:uddi.org:findQualifier:caseSensitiveSort¶Derived V1,V2 format key:uuid:d0a6e4dd-64ca-3255-b364-e36d4d31496f¶Categorization: findQualifier¶Support: Mandatory, default¶

�� findQualifier:caseSen

sitiveSort��

caseInsensitiveSort��

without regard to case��

caseInsensSort

298/405

10112


The following represents a typical inquiry that references the Case Sensitive Sort sort qualifier 10114 tModel. This inquiry seeks businesses that have Web service bindings that implement a 10115 RosettaNet interface and sorts the businesses returned using the Unicode Technical Standard 10116 #10 collation sequence according to case. 10117

<find_business xmlns="urn:uddi-org:api_v3"> 10118 <findQualifiers> 10119 <findQualifier> 10120 uddi:uddi.org:findqualifier:caseinsensitivesort 10121 </findQualifier> 10122 <findQualifier> 10123 uddi:uddi.org:sortorder:uts-10 10124 </findQualifier> 10125 </findQualifiers> 10126  10128 <find_tModel> 10129 <findQualifiers> 10130 <findQualifier> 10131 uddi:uddi.org:findqualifier:approximatematch 10132 </findQualifier> 10133 <findQualifier> 10134 uddi:uddi.org:findqualifier:caseinsensitivematch 10135 </findQualifier> 10136 </findQualifiers> 10137 <name>Rosetta%</name> 10138 </find_tModel> 10139 </find_business> 10140

10141

11.4.11 UDDI Sort Find Qualifier 10142


The Sort find qualifier directs that the result set be sorted according to case, using the collation 10144 sequence specified. 10145

11.4.11.2 Design Goals 10146

The Case Sensitive Sort find qualifier tModel is the implied default for sorting. It is provided to 10147 allow explicit specification of the case sensitivity criterion for the inquiry sorting function. 10148

�� ¶

�� Insensitive

�� but without regard

�� Note that because case

sensitive sorting is the default for inquiry functions, specification of this findQualifier is not necessary. ��

findQualifier:caseSensitiveSort��

sortOrder:UTS


mateMatch

�� findQualifier:caseIns

ensitiveMatch

�� Case Sensitive

�� By Name Ascending find


�� By Name Ascending

findQualifier��

by name in ascending sequence��

The purpose of the Sort By Name Ascending findQualifier is to provide a means for requesting the field (name) and directionality (ascending) with which the results are sorted. For result set elements that have names this find qualifier captures the sorting sequence in effect, sorting on the first (known as the primary) name element contained in each result element.¶


299/405

10149


This tModel is a find qualifier that is used to enable ordering of UDDI inquiry results using the 10151 collation sequence find qualifier in effect. This sort qualifier is applied prior to any truncation of 10152 result sets and is only applicable to inquiries that return a name element in the top-most detail 10153 level of the result set. This qualifier conflicts with the Sort By Name Descending sort qualifier. 10154 When a sort qualifier is also provided for the Date (uddi-org:sortByDateAsc or uddi-10155 org:sortByDateDesc), the sort is first performed on the name fields. Results that share the 10156 same name are then sorted by date. 10157

Name: uddi-org: caseSensitiveSort

Short name: caseSensitiveSort

Description: UDDI sort qualifier used to sort results considering case

UDDI Key (V3): uddi:uddi.org:findqualifier:casesensitivesort

Derived V1,V2 format key: uuid:437df974-faba-3428-a59e-d1550d4494a9



10159



<tModel tModelKey=”uddi:uddi.org:findqualifier:casesensitivesort”> 10162 <name>uddi-org:sortByNameAsc</name> 10163 <description>UDDI sort qualifier used to sort results using 10164 case sensitivity</description> 10165 <overviewDoc> 10166 <overviewURL useType=”text”> 10167 http://uddi.org/pubs/uddi_v3.htm#nameAsc 10168 </overviewURL> 10169 </overviewDoc> 10170 <categoryBag> 10171 <keyedReference keyName=”uddi-org:types:sortOrder” 10172 keyValue="sortOrder" 10173 tModelKey="uddi:uddi.org:categorization:types”/> 10174 </categoryBag> 10175 </tModel> 10176


�� name element from a UDDI

core data structure, in an ascending sequence, as described by the ��


, taking case into consideration��

When no conflicting sort qualifier is specified, this is the default sort ordering behavior.��

uddi-org:caseInsensitiveSort��

Name: uddi-org:sortByNameAsc¶Short name: sortByNameAsc¶Description: UDDI sort qualifier used to sort results by name in ascending order¶UDDI Key (V3):

uddi:uddi.org:findQualifier:sortByNameAsc¶Derived V1,V2 format key: uuid:7693631b-9556-37b4-949d-d85092bfd29b¶Categorization: findQualifier¶Support: Mandatory , default¶

�� findQualifier:sortByN

ameAsc��

caseSensitiveSort��

by name in ascending order��

caseSensSort��



�� <keyedReference

keyName=”uddi-org:types:findQualifier” keyValue="findQualifier" tModelKey="uddi:uddi.org:categorization:types”/>

300/405

10177


The following represents a typical inquiry that references the Sort sort qualifier tModel. This 10179 inquiry seeks businesses that have Web service bindings that implement a RosettaNet 10180 interface and sort the businesses returned using the Unicode Technical Standard #10 collation 10181 sequence according to case. Note that because case sensitive sorting is the default for inquiry 10182 functions, specification of this find qualifier is not necessary. 10183

<find_business xmlns="urn:uddi-org:api_v3"> 10184 <findQualifiers> 10185 <findQualifier> 10186 uddi:uddi.org:findqualifier:casesensitivesort 10187 </findQualifier> 10188 <findQualifier> 10189 uddi:uddi.org:sortorder:uts-10 10190 </findQualifier> 10191 </findQualifiers> 10192  10194 <find_tModel> 10195 <findQualifiers> 10196 <findQualifier> 10197 uddi:uddi.org:findqualifier:approximatematch 10198 </findQualifier> 10199 <findQualifier> 10200 uddi:uddi.org:findqualifier:caseinsensitivematch 10201 </findQualifier> 10202 </findQualifiers> 10203 <name>Rosetta%</name> 10204 </find_tModel> 10205 </find_business> 10206

10207

11.4.12 UDDI Sort By Name Ascending Find Qualifier 10208


The Sort By Name Ascending find qualifier directs that the result set be sorted by name in 10210 descending order using the collation sequence specified. 10211

11.4.12.2 Design Goals 10212

The purpose of the Sort By Name Ascending find qualifier is to provide a means for requesting 10213 the field (name) and directionality (ascending) with which the results are sorted. For result set 10214 elements that have names this find qualifier captures the sorting sequence in effect, sorting on 10215 the first (known as the primary) name element contained in each result element. 10216


This tModel is a find qualifier that is used to enable ordering of UDDI inquiry results using the 10218 name element from a descending sequence, as described by the collation sequence find 10219 qualifier in effect. This sort qualifier is applied prior to any truncation of result sets and is only 10220 applicable to inquiries that return a name element in the top-most detail level of the result set. 10221 This qualifier conflicts with the Sort By Name Ascending sort qualifier. When a sort qualifier is 10222 also provided for the Date (uddi-org:sortByDateAsc or uddi-org:sortByDateDesc), the sort is 10223 first performed on the name fields. Results that share the same name are then sorted by date. 10224

Name: uddi-org:sortByNameAsc

Short name: sortByNameAsc


�� By Name Ascending

�� fixed interface or a

�� sorts

�� by name in ascending

sequence ��

.��

:sortByNameAsc </findQualifier> <findQualifier��

sortOrder:UTS��

<findQualifier> uddi:uddi.org:findQualifier:orAllKeys </findQualifier> ��

this fixed tModel --> <tModelBag> <tModelKey>uddi:some.specific.example:tModelKey</tModelKey> </tModelBag> <!--OR one of ��

xmlns="urn:uddi-org:api_v3"��

findQualifier:approximateMatch��

findQualifier:caseInsensitiveMatch </findQualifier>��

Descending find��

��

Descending findQualifier��

ascending sequence��

Descending findQualifier ��

descending��

overrides��

default directionality to enable��

, in a descending order��


in each result, in��

UDDI core data structure, in ��


When no conflicting sort ��

Descending��

Name: uddi-org:sortByNameDesc¶

� � ��

� � ��

� � ��

� � ��

� � ��!��

� � ��


301/405

Description: UDDI sort qualifier used to sort results by name in ascending order

UDDI Key (V3): uddi:uddi.org:findqualifier:sortbynameasc

Derived V1,V2 format key: uuid:8f0381c5-ef3e-3d0b-8483-5d7f480560a7



10226



<tModel tModelKey=”uddi:uddi.org:findqualifier:sortbynameasc”> 10229 <name>uddi-org:sortByNameAsc</name> 10230 <description>UDDI sort qualifier used to sort results by name 10231 in ascending order</description> 10232 <overviewDoc> 10233 <overviewURL useType=”text”> 10234 http://uddi.org/pubs/uddi_v3.htm#nameAsc 10235 </overviewURL> 10236 </overviewDoc> 10237 <categoryBag> 10238 <keyedReference keyName=”uddi-org:types:findQualifier” 10239 keyValue="findQualifier" 10240 tModelKey="uddi:uddi.org:categorization:types”/> 10241 </categoryBag> 10242 </tModel> 10243

��

�� :sortByNameDesc

302/405

10244


The following represents a typical inquiry that references the Sort By Name Ascending sort 10246 qualifier tModel. This inquiry seeks businesses that have Web service bindings that implement 10247 a fixed interface or a RosettaNet interface and sort the businesses returned by name in 10248 ascending sequence using the Unicode Technical Standard #10 collation sequence. 10249

<find_business xmlns="urn:uddi-org:api_v3"> 10250 <findQualifiers> 10251 <findQualifier> 10252 uddi:uddi.org:findqualifier:sortbynameasc 10253 </findQualifier> 10254 <findQualifier> 10255 uddi:uddi.org:sortorder:uts-10 10256 </findQualifier> 10257 <findQualifier> 10258 uddi:uddi.org:findqualifier:orallkeys 10259 </findQualifier> 10260 </findQualifiers> 10261  10263 <tModelBag> 10264 <tModelKey>uddi:some.specific.example:tmodelkey</tModelKey> 10265 </tModelBag> 10266  10267 <find_tModel xmlns="urn:uddi-org:api_v3"> 10268 <findQualifiers> 10269 <findQualifier> 10270 uddi:uddi.org:findqualifier:approximatematch 10271 </findQualifier> 10272 <findQualifier> 10273 uddi:uddi.org:findqualifier:caseinsensitivematch 10274 </findQualifier> 10275 <findQualifier> 10276 uddi:uddi.org:sortorder:uts-10 10277 </findQualifier> 10278 </findQualifiers> 10279 <name>Rosetta%</name> 10280 </find_tModel> 10281 </find_business> 10282


303/405

10283

11.4.13 UDDI Sort By Name Descending Find Qualifier 10284


The Sort By Name Descending find qualifier directs that the result set be sorted by name in 10286 descending order using the collation sequence specified. 10287

11.4.13.2 Design Goals 10288

The purpose of the Sort By Name Descending find qualifier is to provide a means for 10289 requesting the field (name) and directionality (descending) with which the results are sorted. 10290 For result set elements that have names this find qualifier overrides the default directionality to 10291 enable sorting on the first (known as the primary) name element contained in each result 10292 element, in a descending order. 10293


This tModel is a find qualifier that is used to enable ordering of UDDI inquiry results using the 10295 name element in each result, in a descending sequence, as described by the collation 10296 sequence find qualifier in effect. This sort qualifier is applied prior to any truncation of result 10297 sets and is only applicable to inquiries that return a name element in the top-most detail level 10298 of the result set. This qualifier conflicts with the Sort By Name Ascending sort qualifier. When a 10299 sort qualifier is also provided for the Date (uddi-org:sortByDateAsc or uddi-10300 org:sortByDateDesc), the sort is first performed on the name fields. Results that share the 10301 same name are then sorted by date. 10302

Name: uddi-org:sortByNameDesc

Short name: sortByNameDesc

Description: UDDI sort qualifier used to sort results by name in descending order

UDDI Key (V3): uddi:uddi.org:findqualifier:sortbynamedesc

Derived V1,V2 format key: uuid:fa909d90-0589-3c55-bdd9-94e9bafd7e97


Support: Mandatory



<tModel 10305 tModelKey=”uddi:uddi.org:findqualifier:sortbynamedesc”> 10306 <name>uddi-org:sortByNameDesc</name> 10307 <description>UDDI sort qualifier used to sort results by 10308 name in descending order</description> 10309 <overviewDoc> 10310 <overviewURL useType=”text”> 10311 http://uddi.org/pubs/uddi_v3.htm#nameDesc 10312 </overviewURL> 10313 </overviewDoc> 10314 <categoryBag> 10315 <keyedReference keyName=”uddi-org:types:findQualifier” 10316 keyValue="findQualifier" 10317 tModelKey="uddi:uddi.org:categorization:types”/> 10318

304/405

</categoryBag> 10319 </tModel> 10320

10321


The following represents a typical inquiry that references the Sort By Name Descending sort 10323 qualifier tModel. This inquiry seeks businesses that have Web service bindings for any WSDL-10324 based Web Service related to Transporting goods. The businesses that are discovered are 10325 then sorted by name in descending sequence using the Unicode Technical Standard #10 10326 collation sequence. 10327

<find_business xmlns="urn:uddi-org:api_v3"> 10328  10330 <findQualifiers> 10331 <findQualifier> 10332 uddi:uddi.org:findqualifier:sortbynamedesc 10333 </findQualifier> 10334 <findQualifier> 10335 uddi:uddi.org:sortorder:uts-10 10336 </findQualifier> 10337 <findQualifier> 10338 uddi:uddi.org:findqualifier:orallkeys 10339 </findQualifier> 10340 </findQualifiers> 10341  10343 <find_tModel xmlns="urn:uddi-org:api_v3"> 10344 <findQualifiers> 10345 <findQualifier> 10346 uddi:uddi.org:findqualifier:approximatematch 10347 </findQualifier> 10348 <findQualifier> 10349 uddi:uddi.org:findqualifier:orlikekeys 10350 </findQualifier> 10351 <findQualifier> 10352 uddi:uddi.org:sortorder:uts-10 10353 </findQualifier> 10354 </findQualifiers> 10355 <categoryBag> 10356 <keyedReference keyValue="wsdlSpec" 10357 tModelKey="uddi:uddi.org:categorization:types"/> 10358 <keyedReference keyValue="78%" 10359 tModelKey="uddi:uddi.org:ubr:categorization:unspsc"/> 10360 </categoryBag> 10361 </find_tModel> 10362 </find_business> 10363

10364

First tModels of the WSDL type and are related to the Transporting Goods product category 10365 are discovered and sorted by the tModel name using the UTS-10 sort order. Then the 10366 businesses that have bindingTemplate structures that reference any of the discovered tModels 10367 are located. The resulting businesses are sorted by the name of the business in descending 10368 sequence. 10369


ameDesc

�� sortOrder:UTS

�� findQualifier:orAllKe

ys


mateMatch

�� findQualifier:orLikeK

eys

�� sortOrder:UTS

�� ubr.


305/405

10370

11.4.14 UDDI Sort By Date Ascending Find Qualifier 10371


The Sort By Date Ascending find qualifier directs that the result set be sorted by the last date 10373 updated in ascending chronological order (earliest changes first) using the collation sequence 10374 specified. 10375

11.4.14.2 Design Goals 10376

The purpose of the Sort By Date Ascending findQualifier is to provide a means for requesting 10377 the field (last date modified) and directionality (earliest to most recent) with which the results 10378 are sorted. When this is the only sort order find qualifier specified, this find qualifier specifies 10379 sorting on the date the last update took place on each result. When a findQualifier to sort by 10380 name is also included for those result sets that contain name elements in their results, this find 10381 qualifier enables results that share a common name to be sorted by date. 10382


This tModel is a findQualifier that is used to enable ordering of UDDI inquiry results using the 10384 date last updated in each result, in an ascending sequence. See Section 3.8 operationalInfo 10385 Structure for more information about the date last updated. This sort qualifier is applied prior to 10386 any truncation of result sets. When the top most detail element in the result set does not 10387 contain a name element and there is no sort qualifier specified, the sort ordering behavior as 10388 defined by this findQualifier is the default sort ordering behavior. This qualifier conflicts with the 10389 Sort By Date Descending sort qualifier. Sort qualifiers involving date are secondary in 10390 precedence to the sortByName* qualifiers. Used in conjunction with one of the sortByName* 10391 qualifiers, this sort qualifier causes results to be sorted within name by date, oldest to newest. 10392

Name: uddi-org:sortByDateAsc 10393

Short name: sortByDateAsc 10394

Description: UDDI sort qualifier used to sort results by the last date updated in 10395 ascending order 10396

UDDI Key (V3): uddi:uddi.org:findQualifier:sortByDateAsc 10397

Derived V1,V2 format key: uuid:90a05e5b-2fbb-30a4-b672-5c8d12bd6dea 10398

Categorization: findQualifier 10399

Support: Mandatory 10400

�� find


306/405

10401


This tModel is represented with the following structure 10403

<tModel 10404 tModelKey=”uddi:uddi.org:findQualifier:sortByDateAsc”> 10405 <name>uddi-org:sortByDateAsc</name> 10406 <description>UDDI sort qualifier used to sort results by date in 10407 ascending order</description> 10408 <overviewDoc> 10409 <overviewURL useType=”text”> 10410 http://uddi.org/pubs/uddi_v3.htm#dateAsc 10411 </overviewURL> 10412 </overviewDoc> 10413 <categoryBag> 10414 <keyedReference keyName=”uddi-org:types:findQualifier” 10415 keyValue="findQualifier" 10416 tModelKey="uddi:uddi.org:categorization:types”/> 10417 </categoryBag> 10418 </tModel> 10419

10420


The following represents a typical inquiry that references the Sort By Date Ascending sort 10422 qualifier tModel. All branches of some_company are discovered. This intersection of this set 10423 of businesses with businesses that are located in California is then sorted by date, oldest to 10424 newest. 10425

<find_business xmlns="urn:uddi-org:api_v3"> 10426 <findQualifiers> 10427 <findQualifier> 10428 uddi:uddi.org:findQualifier:sortByDateAsc 10429 </findQualifier> 10430 </findQualifiers> 10431  10433 <categoryBag> 10434 <keyedReference keyValue="US-CA" 10435 tModelKey="uddi:ubr.uddi.org:categorization:geo3166-2: 10436 business_location"/> 10437 </categoryBag> 10438 <find_relatedBusinesses xmlns="urn:uddi-org:api_v3"> 10439 <fromKey>uddi:some_company:main_business</fromKey> 10440 <keyedReference keyValue="parent-child" 10441 keyName="branch" 10442 tModelKey="uddi:ubr.uddi.org:relationships"/> 10443 </find_relatedBusinesses> 10444 </find_business> 10445


307/405

10446

11.4.15 UDDI Sort By Date Descending findQualifier 10447


The Sort By Date Descending findQualifier directs that the result set be sorted by the last date 10449 updated in descending chronological order (most recent changes first) using the collation 10450 sequence specified. 10451

11.4.15.2 Design Goals 10452

The purpose of the Sort By Date Ascending find qualifier is to provide a means for requesting 10453 the field and directionality with which the results are sorted. This find qualifier specifies sorting 10454 on the date the last update took place on each result. When a find qualifier to sort by name is 10455 also included for those result sets that contain name elements in their results, this find qualifier 10456 enables results that share a common name to be sorted by date. 10457


This tModel is a find qualifier that is used to enable ordering of UDDI inquiry results using the 10459 date last updated in each result, in an ascending sequence. See Section 3.8 operationalInfo 10460 Structure for more information about the date last updated. This sort qualifier is applied prior to 10461 any truncation of result sets. When the top most detail element in the result set does not 10462 contain a name element and there is no sort qualifier specified, the sort ordering behavior as 10463 defined by this find qualifier is the default sort ordering behavior. This qualifier conflicts with the 10464 Sort By Date Ascending sort qualifier. Sort qualifiers involving date are secondary in 10465 precedence to the sortByName qualifiers. Used in conjunction with one of the sortByName 10466 qualifiers, this sort qualifier causes results to be sorted within name by date, newest. 10467

Name: uddi-org:sortByDateAsc

Short name: sortByDateAsc

Description: UDDI sort qualifier used to sort results by the last date updated in ascending order

UDDI Key (V3): uddi:uddi.org:findqualifier:sortbydateasc

Derived V1,V2 format key: uuid:6a5b9207-8b01-35ed-ac8e-b6502c92fc4b


Support: Mandatory

10469



<tModel 10472 tModelKey=”uddi:uddi.org:findqualifier:sortbydateasc”> 10473 <name>uddi-org:sortByDateAsc</name> 10474 <description>UDDI sort qualifier used to sort results by date in descending 10475 order</description> 10476 <overviewDoc> 10477 <overviewURL useType=”text”> 10478 http://uddi.org/pubs/uddi_v3.htm#dateAsc 10479 </overviewURL> 10480 </overviewDoc> 10481

��

�� Descending findQualifier

�� (last date modified)

�� (earliest to most recent)

�� When this is the only sort

order find qualifier specified, this��

the element in descending order (newest to oldest).��

findQualifier��

��


for ��

a descending

�� Descending

�� *

�� *

�� oldest to

�� to oldest

�� Name: uddi-

org:sortByDateDesc¶Short name: sortByDateDesc¶Description: UDDI sort qualifier used to sort results by the date last updated in descending order¶UDDI Key (V3):

uddi:uddi.org:findQualifier:sortByDateDesc¶Derived V1,V2 format key: uuid:ae947d4f-d689-3c3f-97d6-e77d1998b2f2¶Categorization: findQualifier¶Support: Mandatory ¶

�� findQualifier:sortByD

ateDesc��

sortByDateDesc��

��

ascending ��

dateDesc

308/405

<categoryBag> 10482 <keyedReference keyName=”uddi-org:types:findQualifier” 10483 keyValue="findQualifier" 10484 tModelKey="uddi:uddi.org:categorization:types”/> 10485 </categoryBag> 10486 </tModel> 10487

10488


The following represents a typical inquiry that references the Sort By Date Ascending sort 10490 qualifier tModel. This inquiry locates all of the approved value set validation Web services 10491 when the registry follows the recommended policy and sorts the tModels with the most recent 10492 ones first. 10493

<find_business xmlns="urn:uddi-org:api_v3"> 10494 <findQualifiers> 10495 <findQualifier> 10496 uddi:uddi.org:findqualifier:sortbydateasc 10497 </findQualifier> 10498 </findQualifiers> 10499  10501 <categoryBag> 10502 <keyedReference keyValue="US-CA" 10503 tModelKey="uddi:uddi.org:ubr:categorization:iso3166: 10504 business_location"/> 10505 </categoryBag> 10506 <find_relatedBusinesses xmlns="urn:uddi-org:api_v3"> 10507 <fromKey>uddi:some_company:main_business</fromKey> 10508 <keyedReference keyValue="parent-child" 10509 keyName="branch" 10510 tModelKey="uddi:uddi.org:ubr:relationships"/> 10511 </find_relatedBusinesses> 10512 </find_business> 10513

��

�� Descending

�� All branches of

some_company are discovered. This intersection of this set of businesses with businesses that are located in California is then sorted by date, oldest to newest��

findQualifier:sortByDateDesc </findQualifier> <findQualifier> uddi:uddi.org:findQualifier:approximateMatch </findQualifier> <findQualifier> uddi:uddi.org:findQualifier:orAllKeys��

find approved validation services within the registry's node businessEntities --> <tModelBag> <tModelKey>uddi:uddi.org:v3_checkedValueSet</tModelKey> </tModelBag> <identifierBag> <keyedReference keyValue="%" tModelKey="uddi:uddi.org:identifier:nodes"/> </identifierBag��

¶Node Business Entity elements are discovered that contain one or more descendent bindingTemplate elements that implement the validate_values API. These businesses are then sorted by date in descending sequence.¶¶


309/405

10514

11.4.16 UDDI Sort By Date Descending Find Qualifier 10515


The Sort By Date Descending find qualifier directs that the result set be sorted by the last date 10517 updated in descending chronological order (most recent changes first) using the collation 10518 sequence specified. 10519

11.4.16.2 Design Goals 10520

The purpose of the Sort By Date Descending find qualifier is to provide a means for requesting 10521 the field and directionality with which the results are sorted. This find qualifier specifies sorting 10522 on the date the last update took place on the element in descending order (newest to oldest). 10523 When a find qualifier to sort by name is also included for those result sets that contain name 10524 elements in their results, this find qualifier enables results that share a common name to be 10525 sorted by date. 10526


This tModel is a find qualifier that is used to enable ordering of UDDI inquiry results using the 10528 date last updated for each result, in a descending sequence. See Section 3.8 operationalInfo 10529 Structure for more information about the date last updated. This sort qualifier is applied prior to 10530 any truncation of result sets. This qualifier conflicts with the Sort By Date Ascending sort 10531 qualifier. Sort qualifiers involving date are secondary in precedence to the sortByName 10532 qualifiers. Used in conjunction with one of the sortByName qualifiers, this sort qualifier causes 10533 results to be sorted within name by date, newest to oldest. 10534

Name: uddi-org:sortByDateDesc

Short name: sortByDateDesc

Description: UDDI sort qualifier used to sort results by the date last updated in descending order

UDDI Key (V3): uddi:uddi.org:findqualifier:sortbydatedesc

Derived V1,V2 format key: uuid:d325de47-150c-3446-a646-b43fbeaf6905


Support: Mandatory

10535



<tModel 10538 tModelKey=”uddi:uddi.org:findqualifier:sortbydatedesc”> 10539 <name>uddi-org:andAllKeys</name> 10540 <description>UDDI findQualifier used to sort results 10541 by date in descending order</description> 10542 <overviewDoc> 10543 <overviewURL useType=”text”> 10544 http://uddi.org/pubs/uddi_v3.htm#andAll 10545 </overviewURL> 10546 </overviewDoc> 10547 <categoryBag> 10548 <keyedReference keyName=”uddi-org:types:findQualifier” 10549

�� And All Keys find

�� The And All Keys

findQualifier directs that a logical AND be performed on any bag contents prior to performing the specified search��

The design goal of the And All Keys findQualifier is to provide a means for finding entities that have all of the values specified, without regard to the value set that they are associated with. For some bags this findQualifier merely enforces default behavior (categoryBag and tModelBag). For identifierBags, this findQualifier overrides the default behavior.¶ �� ¶��

This tModel is referenced by a findQualifier in a UDDI inquiry API to AND the keys in identifierBag, categoryBag, and/or tModelBag prior to performing the actual search for results. Using this findQualifier tModel does not change the treatment of categoryBag or tModelBag contents because ANDing their bag contents is default behavior. ¶This findQualifier cannot be used with the uddi-org:orAllKeys or uddi-org:orLikeKeys findQualifier. The set of values that would result from use of a wildcard in a keyValue are always implicitly OR'd together independent of and after application of this wildcard. This allows an inquiry of the form ‘find businesses with services in Georgia that relate to transporting goods’, where Georgia would be specified as an explicit keyValue from a geographic value set and transporting goods would be specified using a partial value with a wildcard from a product and services value set.:¶Name: uddi-org:andAllKeys¶Short name: andAllKeys¶Description: UDDI findQualifier used to request that a logical AND be performed on bag contents prior to a search.¶UDDI Key (V3):

uddi:uddi.org:findQualifier:andAllKe��

findQualifier:andAllKeys��

sortByDateDesc��

sort qualifier ��

request that a logical AND be performed on bag contents prior to a search��

dateDesc

� � ��

310/405

keyValue="findQualifier" 10550 tModelKey="uddi:uddi.org:categorization:types”/> 10551 </categoryBag> 10552 </tModel> 10553

10554


The following represents a typical inquiry that references the And All Keys find qualifier tModel. 10556 This inquiry locates the tModels that are owned by some_company and which have a D-U-N-10557 S® identity. 10558

<find_business xmlns="urn:uddi-org:api_v3"> 10559 <findQualifiers> 10560 <findQualifier> 10561 uddi:uddi.org:findqualifier:sortbydatedesc 10562 </findQualifier> 10563 <findQualifier> 10564 uddi:uddi.org:findqualifier:approximatematch 10565 </findQualifier> 10566 <findQualifier> 10567 uddi:uddi.org:findqualifier:orallkeys 10568 </findQualifier> 10569 </findQualifiers> 10570  10572 <tModelBag> 10573 <tModelKey>uddi:uddi.org:v3_checkedvalueset</tModelKey> 10574 </tModelBag> 10575 <identifierBag> 10576 <keyedReference keyValue="%" 10577 tModelKey="uddi:uddi.org:identifier:nodes"/> 10578 </identifierBag> 10579 </find_business> 10580

10581

11.4.17 UDDI And All Keys Find Qualifier 10582


The And All Keys find qualifier directs that a logical OR be performed on any bag contents 10584 prior to performing the specified search. 10585

11.4.17.2 Design Goals 10586

The design goal of the Or All Keys find qualifier is to provide a means for finding entities that 10587 have all of the values, without regard to the value set that they are associated with. For some 10588 bags this find qualifier merely enforces default behavior (identifierBag). For identifierBags, this 10589 find qualifier overrides the default behavior. 10590


This tModel is referenced by a find qualifier in a UDDI inquiry API to OR the keys in 10592 identifierBag, categoryBag, and/or tModelBag prior to performing the actual search for results. 10593 Using this find qualifier tModel does not change the treatment of identifierBag contents 10594 because ORing the contents is default behavior. This find qualifier cannot be used with the 10595 uddi-org:orAllKeys or uddi-org:orLikeKeys find qualifier. The set of values that would result 10596 from use of a wildcard in a keyValue are always implicitly OR'd together independent of and 10597 after application of this wildcard. This allows an inquiry of the form ‘find businesses with 10598 services in Georgia that relate to transporting goods’, where Georgia would be specified as an 10599 explicit keyValue from a geographic value set and transporting goods would be specified using 10600 a partial value with a wildcard from a product and services value set.: 10601

��

Sort By Date Descending sort��

This inquiry locates all of the approved value set validation Web services when the registry follows the recommended policy and sorts the tModels with the most recent ones first��

findQualifier:andAllKeys��

:approximateMatch��

identifierBag> <keyedReference keyValue="uddi:some_company:main_business" tModelKey="uddi:ubr.uddi.org:identifier:owningBusiness"/> <keyedReference keyValue="%" tModelKey="uddi:ubr.uddi.org:identifier:dnb.com:D-U-N-S��

Node Business Entity ��

Or��

findQualifier¶<#>Introduction¶��

AND��

And��

findQualifier��

reference any one��

a set of ��

specified��

findQualifier��

categoryBag and ��

categoryBags and ��

findQualifier��

findQualifier��

AND��

findQualifier��

categoryBag or tModelBag��

ANDing their bag ��

of this bag ��

¶��

findQualifier��

andAllKeys��

findQualifiers.��

Name: uddi-org:orAllKeys¶

� � � � ��

� � � � ��

� � � � � ��

� � � � ��

� � � � ��

� � � � ��


311/405

Name: uddi-org:andAllKeys

Short name: andAllKeys

Description: UDDI find qualifier used to request that a logical AND be performed on bag contents prior to a search.

UDDI Key (V3): uddi:uddi.org:findqualifier:andallkeys

Derived V1,V2 format key: uuid:c2ec3b53-7bac-3f59-b313-61882e417cde


Support: Mandatory

10603



<tModel tModelKey=”uddi:uddi.org:findqualifier:andallkeys”> 10606 <name>uddi-org:andAllKeys</name> 10607 <description>UDDI find qualifier used to request that a 10608 logical OR be performed on bag contents 10609 prior to a search</description> 10610 <overviewDoc> 10611 <overviewURL useType=”text”> 10612 http://uddi.org/pubs/uddi_v3.htm#orAll 10613 </overviewURL> 10614 </overviewDoc> 10615 <categoryBag> 10616 <keyedReference keyName=”uddi-org:types:findQualifier” 10617 keyValue="findQualifier" 10618 tModelKey="uddi:uddi.org:categorization:types”/> 10619 </categoryBag> 10620 </tModel> 10621

10622


The following represents a typical inquiry that references the Or All Keys find qualifier tModel. 10624 This inquiry locates the tModels that are owned by some_company and which have a D-U-N-10625 S® identity. 10626

<find_business xmlns="urn:uddi-org:api_v3"> 10627 <findQualifiers> 10628 <findQualifier> 10629 uddi:uddi.org:findqualifier:andallkeys 10630 </findQualifier> 10631 <findQualifier> 10632 uddi:uddi.org:findqualifier:approximatematch 10633 </findQualifier> 10634 </findQualifiers> 10635 <categoryBag> 10636 <keyedReference keyValue="85.14.15.01.00" 10637 tModelKey="uddi:uddi.org:ubr:identifier:owningbusiness"/> 10638 <keyedReference keyValue="%" 10639 tModelKey="uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s"/> 10640 </identifierBag> 10641 </find_business> 10642

10643

��

�� findQualifier:orAllKe

ys��


AND��

��

andAll��

�� And

�� All businesses that are

themselves categorized or contain descendents that are categorized in some way as ‘Witch-doctors or voodoo services’ are returned. The Or All Keys findQualifier is used to find references to this product category as native references, or as a part of some group of references��

!--Find Businesses or their services that are categorized in some way as Witch-doctors or voodoo services --> <��

findQualifier:orAllKeys��

findQualifier:combineCategoryBags��

identifierBag��

uddi:some_company:main_business"��

ubr.��

categorization:unspsc"/> <keyedReferenceGroup ��

ubr.��

categorizationGroup: iso3166_unspsc"> <keyedReference keyValue="85.14.15.01.00" tModelKey="uddi:ubr.uddi.org:categorization:unspsc"/> </keyedReferenceGroup> </categoryBag��


312/405

11.4.18 UDDI Or All Keys Find Qualifier 10644


The Or All Keys find qualifier directs that a logical OR be performed on any bag contents prior 10646 to performing the specified search. 10647

11.4.18.2 Design Goals 10648

The design goal of the Or All Keys find qualifier is to provide a means for finding entities that 10649 reference any one of a set of values from each of value set that they are associated with. For 10650 some bags this find qualifier merely enforces default behavior (identifierBag). For 10651 categoryBags and tModelBags, this find qualifier overrides the default behavior. 10652


This tModel is referenced by a find qualifier in a UDDI inquiry API to OR the keys in 10654 categoryBag, and/or tModelBag prior to performing the actual search for results. Using this find 10655 qualifier tModel does not change the treatment of identifierBag contents because ORing the 10656 contents of this bag is default behavior. This find qualifier cannot be used with the uddi-10657 org:andAllKeys or uddi-org:orLikeKeys find qualifiers. 10658

Name: uddi-org:orAllKeys

Short name: orAllKeys

Description: UDDI find qualifier used to request that a logical OR be performed on bag contents prior to a search.

UDDI Key (V3): uddi:uddi.org:findqualifier:orallkeys

Derived V1,V2 format key: uuid:f5f07764-50ac-378e-9fdd-a42a87329838


Support: Mandatory

10660



<tModel tModelKey=”uddi:uddi.org:findqualifier:orallkeys”> 10663 <name>uddi-org:andAllKeys</name> 10664 <description>UDDI find qualifier used to request that a 10665 logical OR be performed on bag contents 10666 prior to a search</description> 10667 <overviewDoc> 10668 <overviewURL useType=”text”> 10669 http://uddi.org/pubs/uddi_v3.htm#orAll 10670 </overviewURL> 10671 </overviewDoc> 10672 <categoryBag> 10673 <keyedReference keyName=”uddi-org:types:findQualifier” 10674 keyValue="findQualifier" 10675 tModelKey="uddi:uddi.org:categorization:types”/> 10676 </categoryBag> 10677 </tModel> 10678

10679

�� Like

�� find

�� Like


�� that share the same value

set, as specified by the tModelKeys, and an AND be perform between designated value sets ��

Like��

findQualifier��

have at least��

the designated ��

, without regard to the ��

s referenced. This findQualifier allows entities to be discovered��

have been described��

different levels of specificity in their categoryBags and identifierBags��

findQualifier��

identifierBag, ��

identifierBags that are from the same value set, and AND the referenced value sets��

(i.e., one of the values A, B, or C from value set V1 AND one of the values X, Y, or Z form value set V2). The behavior of keyedReferenceGroups is analogous to that of keyedReferences, that is, keyedReferenceGroups that have the same tModelKey value are OR'd together rather than AND'd.��

findQualifier conflicts ��

and uddi-org:orAllKeys findQualifiers.:¶Name: ��

Short name: orLikeKeys¶Description: UDDI findQualifier used to find entities that reference one of the values from each referenced value set.¶UDDI Key (V3):

uddi:uddi.org:findQualifier:orLikeKeys¶Derived V1,V2 format key: uuid:fa2b751e-a8d6-35d8-a2ea-2a12d5b178e9¶Categorization: findQualifier¶Support: Mandatory¶��

findQualifier:orLikeKeys��

orLikeKeys

313/405


The following represents a typical inquiry that references the Or All Keys find qualifier tModel. 10681 All businesses that are themselves categorized or contain descendents that are categorized in 10682 some way as ‘Witch-doctors or voodoo services’ are returned. The Or All Keys find qualifier is 10683 used to find references to this product category as native references, or as a part of some 10684 group of references. 10685

<find_business xmlns="urn:uddi-org:api_v3"> 10686  10688 <findQualifiers> 10689 <findQualifier> 10690 uddi:uddi.org:findqualifier:orallkeys 10691 </findQualifier> 10692 <findQualifier> 10693 uddi:uddi.org:findqualifier:combinecategorybags 10694 </findQualifier> 10695 </findQualifiers> 10696 <categoryBag> 10697 <keyedReference keyValue="85.14.15.01.00" 10698 tModelKey="uddi:uddi.org:ubr:categorization:unspsc"/> 10699 <keyedReferenceGroup 10700 tModelKey="uddi:uddi.org:ubr:categorizationgroup: 10701 iso3166_unspsc"> 10702 <keyedReference keyValue="85.14.15.01.00" 10703 tModelKey="uddi:uddi.org:ubr:categorization:unspsc"/> 10704 </keyedReferenceGroup> 10705 </categoryBag> 10706 </find_business> 10707


314/405

10708

11.4.19 UDDI Or Like Keys Find Qualifier 10709


The Or Like Keys find qualifier directs that a logical OR be performed on any bag contents that 10711 share the same value set, as specified by the tModelKeys, and an AND be perform between 10712 designated value sets prior to performing the specified search. 10713

11.4.19.2 Design Goals 10714

The design goal of the Or Like Keys find qualifier is to provide a means for finding entities that 10715 have at least one of the designated values from each of value sets referenced. This find 10716 qualifier allows entities to be discovered that have been described with different levels of 10717 specificity in their categoryBags and identifierBags. 10718


This tModel is referenced by a find qualifier in a UDDI inquiry API to OR the keys in 10720 categoryBag, and/or identifierBags that are from the same value set, and AND the referenced 10721 value sets prior to performing the actual search for results (i.e., one of the values A, B, or C 10722 from value set V1 AND one of the values X, Y, or Z form value set V2). The behavior of 10723 keyedReferenceGroups is analogous to that of keyedReferences, that is, 10724 keyedReferenceGroups that have the same tModelKey value are OR'd together rather than 10725 AND'd. This find qualifier conflicts with the uddi-org:andAllKeys and uddi-org:orAllKeys find 10726 qualifiers: 10727

Name: uddi-org:orLikeKeys

Short name: orLikeKeys

Description: UDDI find qualifier used to find entities that reference one of the values from each referenced value set.

UDDI Key (V3): uddi:uddi.org:findqualifier:orlikekeys

Derived V1,V2 format key: uuid:ba01e855-5234-3d88-a84e-b878e37b505c


Support: Mandatory

10728



<tModel tModelKey=”uddi:uddi.org:findqualifier:orlikekeys”> 10731 <name>uddi-org:orLikeKeys</name> 10732 <description>UDDI find qualifier used to find entities 10733 that reference one of the values from each 10734 referenced value set</description> 10735 <overviewDoc> 10736 <overviewURL useType=”text”> 10737 http://uddi.org/pubs/uddi_v3.htm#orLike 10738 </overviewURL> 10739 </overviewDoc> 10740 <categoryBag> 10741 <keyedReference keyName=”uddi-org:types:findQualifier” 10742 keyValue="findQualifier" 10743

315/405

tModelKey="uddi:uddi.org:categorization:types”/> 10744 </categoryBag> 10745 </tModel> 10746

10747


The following represents a typical inquiry that references the Or Like Keys find qualifier tModel. 10749 This example seeks bridal clothing (Tuxedo or formal wear (mens) or Evening or bridal gown 10750 (womens)) rental stores (clothing stores) that serve California. 10751

<find_business xmlns="urn:uddi-org:api_v3"> 10752  10758 <findQualifiers> 10759 <findQualifier> 10760 uddi:uddi.org:findqualifier:orlikekeys 10761 </findQualifier> 10762 <findQualifier> 10763 uddi:uddi.org:findqualifier:combinecategorybags 10764 </findQualifier> 10765 <findQualifier> 10766 uddi:uddi.org:findqualifier:approximatematch 10767 </findQualifier> 10768 </findQualifiers> 10769 <categoryBag> 10770  10771 <keyedReference keyValue="7810%" 10772 tModelKey="uddi:uddi.org:ubr:categorization:naics:1997"/> 10773  10774 <keyedReference keyValue="91.10.18.01.00" 10775 tModelKey="uddi:uddi.org:ubr:categorization:unspsc"/> 10776  10777 <keyedReference keyValue="91.10.18.02.00" 10778 tModelKey="uddi:uddi.org:ubr:categorization:unspsc"/> 10779  10780 <keyedReference keyValue="US-CA" 10781 tModelKey="uddi:uddi.org:ubr:categorization:iso3166"/> 10782 </categoryBag> 10783 </find_business> 10784

10785

This example finds clothing stores that serve California which offer rental of wedding attire. 10786 This is represented using an industry categorization, a service location categorization, and two 10787 product and services categorizations. The inquiry is characterized using the categoryBag 10788 contents and the OrLikeKeys findQualifier as 10789

• is any clothing store AND 10790

• rents tuxedos OR bridal gowns AND 10791

• serves California. 10792

Because the ‘Tuxedo or formal wear rental’ and the ‘Evening or bridal gown or dress rental’ 10793 keyedReference elements are from the same value set as described by their tModelKeys, the 10794 OrLikeKeys find qualifier allows businesses to be found that reference either of these product 10795 categorizations. 10796

�� findQualifier:orLikeK

eys

�� findQualifier:combine

CategoryBags


mateMatch

�� ubr.

�� ubr.

�� ubr.

�� ubr.

�� geo3166-2


316/405

10797

11.4.20 UDDI Combine Category Bags Find Qualifier 10798


The Combine Category Bags find qualifier, applied to the find_business inquiry, combines the 10800 categoryBag contents of each businessEntity with those of its businessService structures to 10801 enable discovery based on categorization that is independent of where the publishers placed 10802 such categorizations. 10803

11.4.20.2 Design Goals 10804

The design goal of the Combine Category Bags find qualifier is to provide a means for finding 10805 entities without regard to placement of the categoryBags in the published entities. This find 10806 qualifier enables inquiries involving categorization to be successful independent of the 10807 modeling styles of the publishers. Some publishers may place certain categorizations at the 10808 business level, such as those related to the industries that their businesses operate in, and 10809 place others at the service level (product and service, for example). Inquirers may not care 10810 whether the categorization is at the business level or the service level. This find qualifier 10811 enables such inquiries. 10812


This tModel is referenced by a find qualifier in a UDDI find_business inquiry API to treat the 10814 categoryBag contents of businessEntity structures and contained businessService structures. 10815 Searching for a category yields a match on a registered business if any of the categoryBag 10816 elements contained businessService elements contains the filter criteria. 10817

This find qualifier overrides the default behavior of find_business which performs matching on 10818 categoryBags on the businessEntity structures themselves. The uddi-org:serviceSubset and 10819 uddi-org:bindingSubset find qualifiers conflict with this one. 10820

Name: uddi-org:combineCategoryBags

Short name: combineCategoryBags

Description: UDDI find qualifier used to treat all of the categoryBags within a businessEntity as if they were one during an inquiry.

UDDI Key (V3): uddi:uddi.org:findqualifier:combinecategorybags

Derived V1,V2 format key: uuid:58da61de-bd1e-3ea9-8796-2ec4bfcc15fc


Support: Mandatory

10822



<tModel 10825 tModelKey=”uddi:uddi.org:findqualifier:combinecategorybags”> 10826 <name>uddi-org:serviceSubset</name> 10827 <description>UDDI find qualifier used to use categoryBags within a businessEntity 10828 as if 10829 they were one during inquiry</description> 10830

�� find


�� ¶

<#>Design Goals¶The design goal of the Combine Category Bags findQualifier is to provide a means for finding entities without regard to placement of the categoryBags in the published entities. This findQualifier enables inquiries involving categorization to be successful independent of the modeling styles of the publishers. Some publishers may place certain categorizations at the business level, such as those related to the industries that their businesses operate in, and place others at the service level (product and service, for example). Inquirers may not care whether the categorization is at the business level or the service level. This findQualifier enables such inquiries.¶<#>tModel Definition¶This tModel is referenced by a ��

Publishers often categorize their business services with the ��

findQualifier��

ignore��

inspect only the categoryBags of ��

as one��

with��

will yield��

positive ��

associated with ��

within the businessEntity element or any of its contained or referenced ��

structures contain��

search category.��

findQualifier��

by instead performing matching on categoryBags ��

combineCategoryBags��

findQualifiers��

Name: uddi-org:serviceSubset¶Short name: serviceSubset¶��

findQualifier:service��

combineCategoryBags��


treat all of the��

.

� � � � ��

� � � � ��

� � � � ��

� � � � ��

� � � � ��

� � � � ��

� � � � ��


317/405

<overviewDoc> 10831 <overviewURL useType=”text”> 10832 http://uddi.org/pubs/uddi_v3.htm#servSubset 10833 </overviewURL> 10834 </overviewDoc> 10835 <categoryBag> 10836 <keyedReference keyName=”uddi-org:types:findQualifier” 10837 keyValue="findQualifier" 10838 tModelKey="uddi:uddi.org:categorization:types”/> 10839 </categoryBag> 10840 </tModel> 10841

10842


The following represents a typical inquiry that references the Service Subset find qualifier 10844 tModel. This example is used to locate businesses that are categorized as ‘computer facilities 10845 management services’ or that have descendents that are so categorized. 10846

<find_business xmlns="urn:uddi-org:api_v3"> 10847 <findQualifiers> 10848 <findQualifier> 10849 uddi:uddi.org:findqualifier:combinecategorybags 10850 </findQualifier> 10851 </findQualifiers> 10852 <tModelBag> 10853 <tModelKey>uddi:uddi.org:ubr:categorization:naics:1997"/> 10854 </categoryBag> 10855 </find_business> 10856

10857

11.4.21 UDDI Service Subset Find Qualifier 10858


The Service Subset find qualifier, applied to the find_business inquiry, causes only 10860 categoryBags on contained businessService structures to be inspected. The categoryBags on 10861 businessEntity structures themselves are ignored. 10862

11.4.21.2 Design Goals 10863

Publishers can categorize their business services with categories to distinguish between 10864 similar bindingTemplate structures. Such bindingTemplate structures. The design goal of the 10865 Service Subset find qualifier is to provide a means for finding businessEntity structures that 10866 have bindingTemplate structures categorized in a particular way. 10867


This tModel is referenced by a find qualifier in a UDDI find_business inquiry API to ignore the 10869 categoryBag contents of businessEntity structures and inspect only the categoryBags of 10870 contained bindingTemplate elements. Searching with a category yields a match on a 10871 registered business if any of the categoryBag elements associated with contained 10872 businessService structures contain the search category. 10873

This find qualifier overrides the default behavior of find_business which performs matching on 10874 categoryBags on the businessEntity elements themselves. The uddi-10875 org:combineCategoryBags and uddi-org:bindingSubset find qualifiers conflict with this one. 10876

Name: uddi-org:serviceSubset

Short name: serviceSubset

�� combineCatBags

��

Combine Category Bags ��

This inquiry returns businessEntity elements that have ��

!--Find computer ��

��

findQualifier:service��

categoryBag>��

="��

some.specific.example��

.uddi.org:categorizat��

Binding��

find��

Binding Subset findQualifier��

and find_service inquiries, cause��

descendent ��

and/or businessService ��

often��

bindingTemplate elements��

the industries, products, ��

the described services, and ��

with supersets of ��

may represent the same ��

Binding��

findQualifier��

business services using ��

elements or ��

may offer the kinds of ��

not specifically identified ��

as��

findQualifier��

or find_service ��

containing ��

and businessService ��

businessService structures.��

bindingTemplate structures ��

findQualifier��

structures��

, and of find_service which ��

serviceSubset findQualifiers��

Name: uddi-org:bindingSubset¶

� � ��

� � ��

� � ��

� � ��

� � ��

� � ��

� � ��

� � �� !"�

� � ��

� � ��

� � ��

� � �� !"�

� � ��

� � ��

� � �� #��

� � �� $�� #��

� � �� $��

� � �� $��

� � ��

� � ��


318/405

Description: UDDI find qualifier used to use categoryBags of businessService elements to satisfy the find_business inquiry.

UDDI Key (V3): uddi:uddi.org:findqualifier:servicesubset

Derived V1,V2 format key: uuid:55913724-e5ce-3188-9b73-4486f1ac7cd9


Support: Mandatory

: 10878



<tModel tModelKey=”uddi:uddi.org:findqualifier:servicesubset”> 10881 <name>uddi-org:serviceSubset</name> 10882 <description>UDDI find qualifier used to use categoryBags of bindingTempate 10883 elements to satisfy the find_business inquiry.</description> 10884 <overviewDoc> 10885 <overviewURL useType=”text”> 10886 http://uddi.org/pubs/uddi_v3.htm#servSubset 10887 </overviewURL> 10888 </overviewDoc> 10889 <categoryBag> 10890 <keyedReference keyName=”uddi-org:types:findQualifier” 10891 keyValue="findQualifier" 10892 tModelKey="uddi:uddi.org:categorization:types”/> 10893 </categoryBag> 10894 </tModel> 10895

��

�� findQualifier:binding

Subset��

bindingSubset��

findQualifier for specifying ��

of ��

of businessService��

��

��

or find_service inquiries. ��

bindSubset��

cagegoryBag>


319/405

10896


The following represents a typical inquiry that references the Service Subset find qualifier 10898 tModel. This inquiry returns businessEntity elements that have descendent businessService 10899 elements that are categorized with ‘Customer Type and which conform to some technical 10900 fingerprint. 10901

<find_business xmlns="urn:uddi-org:api_v3"> 10902 <findQualifiers> 10903 <findQualifier> 10904 uddi:uddi.org:findqualifier:servicesubset 10905 </findQualifier> 10906 <findQualifier> 10907 uddi:uddi.org:findqualifier:orallkeys 10908 </findQualifier> 10909 </findQualifiers> 10910 <tModelBag> 10911 <tModelKey>uddi:some.specific.example:tmodelkey</tModelKey> 10912 </tModelBag> 10913 <categoryBag> 10914 <keyedReference keyValue="541511" 10915 tModelKey="uddi:uddi.org:ubr:categorization:naics:1997"/> 10916 <keyedReference keyValue="541512" 10917 tModelKey="uddi:uddi.org:ubr:categorization:naics:1997"/> 10918 </categoryBag> 10919 </find_business> 10920

10921

11.4.22 UDDI Binding Subset Find Qualifier 10922


The Binding Subset find qualifier, applied to the find_business and find_service inquiries, 10924 cause only categoryBags on descendent bindingTemplate structures to be inspected. The 10925 categoryBags on businessEntity and/or businessService elements themselves are ignored. 10926

11.4.22.2 Design Goals 10927

Publishers can categorize their bindingTemplate elements with categories to distinguish 10928 between similar bindingTemplate structures. Such bindingTemplate structures may represent 10929 the same Web service but for different audiences or may represent different levels of release, 10930 for example. The design goal of the Binding Subset find qualifier is to provide a means for 10931 finding businessEntity elements or businessService elements that have bindingTemplate 10932 structures categorized in a particular way. 10933


This tModel is referenced as a find qualifier in a UDDI find_business or find_service inquiry API 10935 to ignore the matching algorithm and when building the serviceInfos to include in the result set. 10936 The behavior associated with this findQualifier is to ignore service projections in all stages of 10937 the inquiry, as if they are not there at all. 10938

�� Binding

�� bindingTemplate

�� the ‘Retail’

�� Computer Programming

Services’ or ’Computer Systems Design Services’ ��

findQualifier:bindingSubset��

findQualifier:caseInsensitiveMatch��

tModelKey��

Retail” keyName="tempuri-org:CustomerType��

general_keywords��

Suppress Projected Services find��

The Suppress Projected Services findQualifier, applied to the find_business or find_service inquiry, is used to exclude service projections from all matching comparisons and from the list of serviceInfos included in businessInfos. ��

The design goal of the Suppress Projected Services findQualifier is to provide a means for excluding projected services from appearing in result sets when such appearance is unnecessary or ambiguous. When find_service is issued with no businessKey, this findQualifier is implicitly in effect because without knowledge of the containing businessEntity, service projections appear as exact duplicates of the services on which they project. This findQualifier can be used to only include actual implementations of a service, excluding those that just refer to these concrete implementations.¶��

by ��

findQualifier��

service projections when performing ��

categoryBag contents of containing businessEntity��

businessService elements and inspect only ��

categoryBags of contained bindingTemplate elements. Searching with a category yields a match on a registered business if any of the categoryBag elements associated ��

When a UDDI inquiry couples this findQualifier with the use of tModelBags or the serviceSubset findQualifier, empty outer elements

� � � � ��

� � � � ��


320/405

10939

This find qualifier overrides the default behavior of find_business which performs matching on 10940 categoryBags on the businessEntity elements themselves, and of find_service which performs 10941 matching on categoryBags on the businessService elements themselves. The uddi-10942 org:combineCategoryBags and uddi-org:serviceSubset find qualifiers conflict with this one. 10943

Name: uddi-org:bindingSubset

Short name: bindingSubset

Description: UDDI find qualifier for specifying use of categoryBags of bindingTemplate elements to satisfy the find_business or find_service inquiries.

UDDI Key (V3): uddi:uddi.org:findqualifier:bindingsubset

Derived V1,V2 format key: uuid:81b2ec2b-e72e-31f6-8fce-7368a0d5a671


Support: Mandatory

10945



<tModel tModelKey=”uddi:uddi.org:findqualifier:bindingsubset”> 10948 <name>uddi-org:bindingSubset</name> 10949 <description>UDDI find qualifier for specifying use of 10950 categoryBags of bindingTempate elements to satisfy 10951 the find_business or find_service inquiries. 10952 </description> 10953 <overviewDoc> 10954 <overviewURL useType=”text”> 10955 http://uddi.org/pubs/uddi_v3.htm#bindSubset 10956 </overviewURL> 10957 </overviewDoc> 10958 <categoryBag> 10959 <keyedReference keyName=”uddi-org:types:findQualifier” 10960 keyValue="findQualifier" 10961 tModelKey="uddi:uddi.org:categorization:types”/> 10962 </cagegoryBag> 10963 </tModel> 10964

10965


The following represents a typical inquiry that references the Binding Subset find qualifier 10967 tModel. This inquiry returns businessEntity elements that have descendent bindingTemplate 10968 elements that are categorized with the ‘Retail’ Customer Type and which conform to some 10969 technical fingerprint. 10970

<find_business xmlns="urn:uddi-org:api_v3"> 10971 <findQualifiers> 10972 <findQualifier> 10973 uddi:uddi.org:findqualifier:bindingsubset 10974 </findQualifier> 10975 <findQualifier> 10976 uddi:uddi.org:findqualifier:caseinsensitivematch 10977 </findQualifier> 10978 </findQualifiers> 10979 <tModelBag> 10980

�� suppressProjectedServices¶

Short name: suppressProjectedServices¶

Description: UDDI findQualifier used to exclude service projections from an inquiry function at all levels.¶UDDI Key (V3): ��

:uddi.��

findQualifier:suppressProjectedServices��

Derived V1,V2 format key: uuid:0943f989-37f0-3c02-a0ae-6a9627f2bc95¶Categorization: findQualifier¶Support: Mandatory¶��

¶ ��

findQualifier: ¶ suppressProjectedServices”>¶��

suppressProjectedServices��

¶��

findQualifier used to exclude service¶ projections from an inquiry function at all¶ levels.��

¶��

¶��

¶��

suppressProjSvcs¶��

¶��

¶��

¶��

¶��

¶��

¶ </categoryBag>¶��

Suppress Projected Services ��

The businesses that are the actual providers of a business service ��

¶��

¶��

¶��

:suppressProjectedSer��

¶��

¶

� � � � ��

� � � � ��

� � � � ��


321/405

<tModelKey>uddi:some.specific.example:tmodelkey</tModelKey> 10981 </tModelBag> 10982 </find_business> 10983

10984

11.4.23 UDDI Suppress Projected Services Find Qualifier 10985


The Suppress Projected Services find qualifier, applied to the find_business or find_service 10987 inquiry, is used to exclude service projections from all matching comparisons and from the list 10988 of serviceInfos included in businessInfos. 10989

11.4.23.2 Design Goals 10990

The design goal of the Suppress Projected Services find qualifier is to provide a means for 10991 excluding projected services from appearing in result sets when such appearance is 10992 unnecessary or ambiguous. When find_service is issued with no businessKey, this find 10993 qualifier is implicitly in effect because without knowledge of the containing businessEntity, 10994 service projections appear as exact duplicates of the services on which they project. This find 10995 qualifier can be used to only include actual implementations of a service, excluding those that 10996 just refer to these concrete implementations. 10997


This tModel is referenced by a find qualifier in a UDDI find_business or find_service inquiry API 10999 to ignore service projections when performing the matching algorithm and when building the 11000 serviceInfos to include in the result set. The behavior associated with this find qualifier is to 11001 ignore service projections in all stages of the inquiry, as if they are not there at all. 11002

When a UDDI inquiry couples this find qualifier with the use of tModelBags or the 11003 serviceSubset find qualifier, empty outer elements (businessInfo for find_business; serviceInfo 11004 for find_service) are excluded from the result set when the only qualifying entity corresponds to 11005 a suppressed projected service. 11006

�� ¶

��

¶ </tModelKey>¶�� <categoryBag> <keyedReference keyValue="Retail” keyName="tempuri-org:CustomerType" tModelKey="uddi:uddi.org:categorization:general_keywords"/> </categoryBag>��

Signature Present find��

The Signature Present findQualifier filters the result set to include only entities that are signed or whose containing entities are signed��

The design goal of the Signature Present findQualifier is to provide a starting point for establishing some confidence in the entities returned from an inquiry. Only elements that are covered by XML Digital Signatures are returned. The actual signature(s) is obtained by subsequent get_xx API calls and can be verified by the client. ¶��

This tModel is referenced by a findQualifier in a UDDI inquiry API to only include UDDI entities that have XML Digital Signatures or that are descendents of UDDI entities that have XML Digital Signatures. To be returned, either the elements themselves must be signed, or at least one of the elements that contain them must be signed. For example when the Signature Present findQualifier is used with the find_business inquiry API, only businessEntity elements that have an XML Digital Signature are returned. Similarly, when Signature Present is used with the find_service inquiry API, only businessService elements that have an XML Digital Signature or whose containing businessEntity elements have an XML Digital Signature are returned. ¶The UDDI Inquiry API provides no verification associated with use of this findQualifier.¶Name: uddi-org:signaturePresent¶Short name: signaturePresent¶Description: UDDI findQualifier used to return only entities that have or are contained in entities that have XML Digital Signatures.¶UDDI Key (V3):

uddi:uddi.org:findQualifier:signaturePresent¶Derived V1,V2 format key: � � � � � ��

322/405

11007

This find qualifier overrides the default behavior of find_business and find_service (when a 11008 businessKey is provided). 11009

Name: uddi-org:suppressProjectedServices

Short name: suppressProjectedServices

Description: UDDI find qualifier used to exclude service projections from an inquiry function at all levels.

UDDI Key (V3): uddi:uddi.org:findqualifier:suppressprojectedservices

Derived V1,V2 format key: uuid:805e73a2-dcc0-3c1b-bfd8-66c5af40fc98


Support: Mandatory

: 11010



<tModel tModelKey=”uddi:uddi.org:findqualifier: 11013 suppressProjectedServices”> 11014 <name>uddi-org:suppressProjectedServices</name> 11015 <description>UDDI find qualifier used to exclude service 11016 projections from an inquiry function at all 11017 levels.</description> 11018 <overviewDoc> 11019 <overviewURL useType=”text”> 11020 http://uddi.org/pubs/uddi_v3.htm#suppressProjSvcs 11021 </overviewURL> 11022 </overviewDoc> 11023 <categoryBag> 11024 <keyedReference keyName=”uddi-org:types:findQualifier” 11025 keyValue="findQualifier" 11026 tModelKey="uddi:uddi.org:categorization:types”/> 11027 </categoryBag> 11028 </tModel> 11029

11030


The following represents a typical inquiry that references the Suppress Projected Services find 11032 qualifier tModel. The businesses that are the actual providers of a business service that 11033 adheres to some technical fingerprint are returned. Other businesses that refer to such 11034 businessService elements using service projections are excluded. 11035

<find_business xmlns="urn:uddi-org:api_v3"> 11036  11038 <findQualifiers> 11039 <findQualifier> 11040 uddi:uddi.org:findqualifier:suppressprojectedservices 11041 </findQualifier> 11042 </findQualifiers> 11043 <tModelBag> 11044 <tModelKey> 11045 uddi:some.specific.example:tmodelkey 11046 </tModelKey> 11047 </tModelBag> 11048 </find_business> 11049

�� ¶

��

findQualifier:signaturePresent”>


323/405

11050

11.4.24 UDDI Signature Present Find Qualifier 11051


The Signature Present find qualifier filters the result set to include only entities that are signed 11053 or whose containing entities are signed. 11054

11.4.24.2 Design Goals 11055

The design goal of the Signature Present find qualifier is to provide a starting point for 11056 establishing some confidence in the entities returned from an inquiry. Only elements that are 11057 covered by XML Digital Signatures are returned. The actual signature(s) is obtained by 11058 subsequent get_xx API calls and can be verified by the client. 11059


This tModel is referenced by a find qualifier in a UDDI inquiry API to only include UDDI entities 11061 that have XML Digital Signatures or that are descendents of UDDI entities that have XML 11062 Digital Signatures. To be returned, either the elements themselves must be signed, or at least 11063 one of the elements that contain them must be signed. For example when the Signature 11064 Present find qualifier is used with the find_business inquiry API, only businessEntity elements 11065 that have an XML Digital Signature are returned. Similarly, when Signature Present is used 11066 with the find_service inquiry API, only businessService elements that have an XML Digital 11067 Signature or whose containing businessEntity elements have an XML Digital Signature are 11068 returned. 11069

The UDDI Inquiry API provides no verification associated with use of this find qualifier. 11070

Name: uddi-org:signaturePresent

Short name: signaturePresent

Description: UDDI find qualifier used to return only entities that have or are contained in entities that have XML Digital Signatures.

UDDI Key (V3): uddi:uddi.org:findqualifier:signaturepresent

Derived V1,V2 format key: uuid:8a16ea11-6f8f-3085-a467-576f89f129c8


Support: Mandatory

11071



<tModel tModelKey=”uddi:uddi.org:findqualifier:signaturepresent”> 11074 <name>uddi-org:signaturePresent</name> 11075 <description>UDDI findQualifier used to return only entities 11076 that have or are contained in entities that have 11077 XML Digital Signatures.</description> 11078 <overviewDoc> 11079 <overviewURL useType=”text”> 11080 http://uddi.org/pubs/uddi_v3.htm#sign 11081 </overviewURL> 11082 </overviewDoc> 11083


324/405

<categoryBag> 11084 <keyedReference keyName=”uddi-org:types:findQualifier” 11085 keyValue="findQualifier" 11086 tModelKey="uddi:uddi.org:categorization:types”/> 11087 </categoryBag> 11088 </tModel> 11089

11090


The following represents a typical inquiry that references the Is Signed find qualifier tModel. 11092

<find_business xmlns="urn:uddi-org:api_v3"> 11093 <tModelBag> 11094 <tModelKey> 11095 uddi:some.specific.example:tmodelkey 11096 </tModelKey> 11097 </tModelBag> 11098 <find_relatedBusinesses xmlns="urn:uddi-org:api_v3"> 11099 <findQualifiers> 11100 <findQualifier> 11101 uddi:uddi.org:findqualifier:signaturepresent 11102 </findQualifier> 11103 </findQualifiers> 11104 <fromKey> 11105 uddi:some_trust_certifier.example:main_business 11106 </fromKey> 11107 </find_relatedBusinesses> 11108 </find_business> 11109

11110

This example performs a two phase inquiry. First, businesses that have a signed a 11111 relationship with some_trust_certifier are located using the embedded find_relatedBusinesses. 11112 An intersection is built between this set of businesses and the businesses that offer Web 11113 services compliant with the technical fingerprint captured in the tModelBag. Note that there is 11114 no verification that the signatures associated with the returned relationships is valid prior to 11115 obtaining businesses that have Web services that satisfy the technical fingerprint part of the 11116 inquiry. 11117

�� tModelKey

�� findQualifier:signatu

rePresent


325/405

11118

11.5 Other Canonical tModels 11119

The following tModels round out the set of tModels UDDI registries MUST contain. 11120

There are other tModels, beyond those listed here, which are defined to help classify elements 11121 within leading industry encoding schemes and standard protocols. These other tModels are 11122 maintained by the UDDI Business Registry and the list is expected to expand as appropriate 11123 as this registry expands. See the UDDI Business Registry for these tModels. 11124

11.5.1 Domain Key Generator for the UDDI Domain 11125


For UDDI tModels to have publisher assigned keys, a key generator tModel for the UDDI 11127 domain must be registered and owned by UDDI itself. Ownership of such a domain key 11128 generator tModel allows UDDI owned entities, such as tModels, to have keys derived from the 11129 UDDI domain. All tModels contain in this chapter have such keys. This tModel establishes the 11130 UDDI key generator domain. Other publishers that wish to provide their own keys for UDDI 11131 core entities must similarly register their own domain key generator tModels. 11132


The design goal for the UDDI Domain Key Generator tModel is to establish a key generator 11134 domain within a UDDI registry that allows UDDI to publish its canonical tModels. All other 11135 tModels described in this document have keys derived from the key generator domain 11136 established by this tModel. 11137


Name: uddi-org:keyGenerator

Description: UDDI domain key generator

UDDI Key (V3): uddi:uddi.org:keygenerator

Derived V1,V2 format key: uuid:dfd2e89d-59c1-3921-822c-da6a8f6ef57e

Categorization: keyGenerator

11140



<n0:tModel n0:tModelKey="uddi:uddi.org:keygenerator" 11143 xmlns:n0="urn:uddi-org:api_v3"> 11144 <n0:name>uddi-org:keyGenerator</n0:name> 11145 <n0:description>UDDI domain key generator</n0:description> 11146 <n0:overviewDoc> 11147 <n0:overviewURL n0:useType="text"> 11148 http://uddi.org/pubs/uddi_v3.htm#keyGen 11149 </n0:overviewURL> 11150 </n0:overviewDoc> 11151 <n0:categoryBag> 11152 <n0:keyedReference 11153 n0:keyName="uddi-org:types:keyGenerator" 11154 n0:keyValue="keyGenerator" 11155 n0:tModelKey="uddi:uddi.org:categorization:types"/> 11156 </n0:categoryBag> 11157

�� Beyond the

�� defined

�� additional tModels

�� register

�� This list is

�� be expanded

��

�� form

�� Name: uddi-

org:keyGenerator¶Description: UDDI domain key generator¶UDDI Key (V3):

uddi:uddi.org:keyGenerator¶Derived V1, V2 format key: uuid:536470bb-3294-3d30-91e4-df0fcbd1a5d9¶Categorization: keyGenerator¶

��

¶

�� keyGenerator


326/405

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 11158 <n0:SignedInfo xmlns:n0="http://www.w3.org/2000/09/xmldsig#"> 11159 <n0:CanonicalizationMethod 11160 n0:Algorithm="urn:uddi-org:schemaCentricC14N:2002-07-10"/> 11161 <n0:SignatureMethod 11162 n0:Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 11163 <n0:Reference n0:URI=""> 11164 <n0:Transforms> 11165 <n0:Transform 11166 n0:Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-11167 signature"/> 11168 <n0:Transform 11169 n0:Algorithm="urn:uddi-org:schemaCentricC14N:2002-07-10"/> 11170 </n0:Transforms> 11171 <n0:DigestMethod 11172 n0:Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 11173 <n0:DigestValue>07BhIj1QHu6F5/yCwpI74zVTmFE=</n0:DigestValue> 11174 </n0:Reference> 11175 </n0:SignedInfo> 11176 <ds:SignatureValue> 11177 lxehZiBI5CXUbf20GNfXlyjfARajEarqudaJCgJit6NtUBccAKoupMQgIdNaBKnwfjTMptvA 11178 h+TIx8mML3/acJhfWud8ciilNrRvKu9G4GhIMXD11camNbshOzqEOptJbMO74GtbyTZsGcK6 11179 1tS74H52O7nbw7KdDuDd73mww8I=</ds:SignatureValue> 11180 <ds:KeyInfo> 11181 <ds:KeyName>Public key of certificate</ds:KeyName> 11182 <ds:KeyValue> 11183 <ds:RSAKeyValue> 11184 <ds:Modulus> 11185 xUyQeJ+fVlyQlUaQS8vKFLDRVeVxbt8D9BpUIK6I9NlrufpEhUcRZk/1emEpJvKD4NJA3ITE 11186 bUHATVom/g0p31ca49KQ5se+9maxi2R3jEKDcTB6zaDbhHC9Cc63txmmaszbnaeT7zxrHedU 11187 7oGAemv5IyfTViPEv6agTOButk8= 11188 </ds:Modulus> 11189 <ds:Exponent>AQAB</ds:Exponent> 11190 </ds:RSAKeyValue> 11191 </ds:KeyValue> 11192 <ds:X509Data> 11193 <ds:X509Certificate> 11194 MIIDZDCCAs2gAwIBAgIQea2mBHYKs1o8gyI2gk94YDANBgkqhkiG9w0BAQUFADCBujEfMB0G 11195 A1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVyaVNpZ24sIEluYy4x 11196 MzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2VydmVyIENBIC0gQ2xhc3MgMzFJ 11197 MEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMgSW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZ 11198 IExURC4oYyk5NyBWZXJpU2lnbjAeFw0wMjA3MTkwMDAwMDBaFw0wNDA3MTgyMzU5NTlaMHox 11199 CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1Nb3VudGFpbiBW 11200 aWV3MREwDwYDVQQKEwh1ZGRpLm9yZzEYMBYGA1UECxMPVmVyaVNpZ24gU2lnbmVyMREwDwYD 11201 VQQDEwh1ZGRpLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxUyQeJ+fVlyQlUaQ 11202 S8vKFLDRVeVxbt8D9BpUIK6I9NlrufpEhUcRZk/1emEpJvKD4NJA3ITEbUHATVom/g0p31ca 11203 49KQ5se+9maxi2R3jEKDcTB6zaDbhHC9Cc63txmmaszbnaeT7zxrHedU7oGAemv5IyfTViPE 11204 v6agTOButk8CAwEAAaOBqTCBpjAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH 11205 FwMwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTBGBgNVHR8E 11206 PzA9MDugOaA3hjVodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9DbGFzczNJbnRlcm5hdGlvbmFs 11207 U2VydmVyLmNybDALBgNVHQ8EBAMCB4AwDQYJKoZIhvcNAQEFBQADgYEAn0Qz+JmvO2uRNTHC 11208 4QriIac96hBc0DKr38rDtw7C0yn79xPvurW8ZvU/wqU4hurTKKxqf8nLaayRv8Xe5mmuFq4C 11209 7rwWiH4IvgfFEg0k7n7AKyqpvpHKzzLz9Sx4JilbRPiWKbWGUqpw/5WP60SxkP19thMHPcwE 11210 8VGQiCaEX1E= 11211 </ds:X509Certificate> 11212 <ds:X509Certificate> 11213 MIIDhjCCAu+gAwIBAgIQeO5I3hhbIHHJycO1HXvdwTANBgkqhkiG9w0BAQUFADBfMQswCQYD 11214 VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDMgUHVi 11215 bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTcwNDE3MDAwMDAwWhcN 11216 MTExMDI0MjM1OTU5WjCBujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUG 11217 A1UECxMOVmVyaVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwg 11218 U2VydmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMgSW5j 11219 b3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjCBnzANBgkqhkiG9w0B 11220 AQEFAAOBjQAwgYkCgYEA2IKA6NYZAn0fhRg5JaJlK+G/1AXTvOY2O6rwTGxbtueqPHNFVbLx 11221 veqXQu2aNAoV1Klc9UAl3dkHwTKydWzEyruj/lYncUOqY/UwPpMo5frxCTvzt01OOfdcSVq4 11222 wR3Tsor+cDCVQsv+K1GLWjw6+SJPkLICp1OcTzTnqwSye28CAwEAAaOB5jCB4zAPBgNVHRME 11223 CDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHAQEwKjAoBggrBgEFBQcCARYcaHR0 11224 cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3Js 11225 LnZlcmlzaWduLmNvbS9wY2EzLWcyLmNybDA0BgNVHSUELTArBggrBgEFBQcDAQYIKwYBBQUH 11226 AwIGCWCGSAGG+EIEAQYKYIZIAYb4RQEIATALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQD 11227 AgEGMA0GCSqGSIb3DQEBBQUAA4GBACNd7qYkBf1202oa1rpGBqpqDwOQZrKwpsKeyR6jVVOv 11228


327/405

PkX93Iwn3VM4Cbt8Syu6lUr+cE4badY8908HxfIXWkyij6wLigbbudRrxR1Y2hdS4yHx0tda 11229 1eWrWXsheoZq1P4XETpTDZxgoErZXuQdDCmqEwdlhh+/tMmCU5wsAo8j 11230 </ds:X509Certificate> 11231 </ds:X509Data> 11232 </ds:KeyInfo> 11233 </ds:Signature> 11234 </n0:tModel> 11235 11236

11.5.2 UDDI Hosting Redirector Specification 11237


In UDDI, tModels are used to establish the existence of a variety of concepts and to point to 11239 their technical definitions. tModels of the specification sort are referenced by service bindings 11240 to describe the technical fingerprint of the business service. The hostingRedirector 11241 specification tModel establishes the concept of a hosting redirector Web service as described 11242 in Section 3.5.2.1 accessPoint. Refer to Appendix B Using and Extending the useType 11243 Attribute for usage details. Such Web services are used to dynamically obtain an access point 11244 for a Web service binding. 11245


The design goal for the Hosting Redirector tModel is to facilitate recognition and discovery of 11247 Web service bindings that are associated with a hosting redirector service and to standardize 11248 the interface for such Web services. 11249


This tModel is used in bindingTemplate structures of Hosting Redirector Web services to 11251 indicate that the Web service implementation responds to the get_bindingDetail API with a 11252 bindingTemplate that contains an actual access point for the redirected Web service. 11253

Name: uddi-org:hostingRedirector

Description: UDDI Hosting Redirector service specification

UDDI Key (V3): uddi:uddi.org:specification:hostingredirector

Derived V1,V2 format key: uuid:51c1535b-7e38-3860-9078-563d548420c5

Categorization: specification

11255



<tModel 11258 tModelKey=”uddi:uddi.org:specification:hostingredirector”> 11259 <name>uddi-org:hostingRedirector</name> 11260 <description>UDDI Hosting Redirector service specification</description> 11261 <overviewDoc> 11262 <overviewURL useType=”text”> 11263 http://uddi.org/pubs/uddi_v3.htm#hostDir 11264 </overviewURL> 11265 </overviewDoc> 11266 <categoryBag> 11267 <keyedReference keyName=”uddi-org:types:specification” 11268 keyValue="specification" 11269 tModelKey="uddi:uddi.org:categorization:types”/> 11270

�� Name: uddi-

org:hostingRedirector¶Description: UDDI Hosting Redirector service specification ¶UDDI Key (V3):

uddi:uddi.org:specification:hostingRedirector¶Derived V1,V2 format key: uuid:966a3c13-7d00-4586-9def-b270b1b32c7d¶Categorization: specification¶

�� hostingRedirector

328/405

</categoryBag> 11271 </tModel> 11272


The following is an example of a bindingTemplate for a Hosting Redirector Web service. The 11274 bindingTemplate of a Web service making use of indirection via a hostingRedirector Web 11275 service contains the bindingKey of the hosting redirector service’s bindingTemplate. The 11276 hosting redirector’s bindingTemplate contains the accessPoint of the Hosting Redirector Web 11277 service as shown in the following example: 11278

<bindingTemplate bindingKey=”....” serviceKey="uddi:sk1...."> 11279 <description xml:lang="en">My Redirector</description> 11280  11282 <accessPoint useType="hostingRedirector"> 11283 ...the URL of the host redirection service... 11284 </accessPoint> 11285 <tModelInstanceDetails> 11286 <tModelInstanceInfo 11287 tModelKey="uddi:uddi.org:specification:hostingredirector"/> 11288 </tMobdelInstanceDetails> 11289 </bindingTemplate> 11290

�� SK1


329/405

11291

11.5.3 UDDI Policy Description Specification 11292


In UDDI, tModels are used to establish the existence of a variety of concepts and to point to 11294 their technical definitions. tModels of the specification sort are referenced by service bindings 11295 to describe the technical fingerprint of the business service. The policy description specification 11296 tModel establishes the concept of a description of UDDI policy using schema-based XML. 11297


The design goal for the Policy Description tModel is to enable discovery of UDDI policy for a 11299 UDDI node. UDDI policy is described in a schema driven XML document that is accessible 11300 from the access points of bindingTemplates that reside with UDDI node business entities. 11301


This tModel is used in bindingTemplate structures to indicate that the service implementation 11303 describes the policy of the node according to the policy description schema. 11304

Name: uddi-org:v3_policy

Description: UDDI Policy Description service specification

UDDI Key (V3): uddi:uddi.org:specification:v3_policy

Derived V1,V2 format key: uuid:d52ce89c-01f8-3b53-a25e-89cfa5bbad17

Categorization: specification

11306



<tModel 11309 tModelKey=”uddi:uddi.org:specification:v3_policy”> 11310 <name>uddi-org:v3_policy</name> 11311 <description>UDDI Policy Description service specification</description> 11312 <overviewDoc> 11313 <overviewURL useType=”text”> 11314 http://uddi.org/pubs/uddi_v3.htm#policyDesc 11315 </overviewURL> 11316 </overviewDoc> 11317 <categoryBag> 11318 <keyedReference keyName=”uddi-org:types:specification” 11319 keyValue="specification" 11320 tModelKey="uddi:uddi.org:categorization:types”/> 11321 </categoryBag> 11322 </tModel> 11323

�� Name: uddi-

org:v3_policy¶Description: UDDI Policy Description service specification ¶UDDI Key (V3):

uddi:uddi.org:specification:v3_policy¶Derived V1,V2 format key: uuid:c6772d9e-360c-3c50-801e-5e10d3804ff3¶Categorization: specification¶


330/405

11324


The following is an example of a bindingTemplate for a Policy Description Web service. The 11326 policy description document is obtained using http: 11327

<bindingTemplate bindingKey=”....” serviceKey="uddi:sk1...."> 11328 <accessPoint useType="endpoint"> 11329 http://www.example.com/MyUDDIPolicy.xml 11330 </accessPoint> 11331 <tModelInstanceDetails> 11332 <tModelInstanceInfo 11333 tModelKey="uddi:uddi.org:specification:v3_policy"/> 11334 </tMobdelInstanceDetails> 11335 </bindingTemplate> 11336

�� SK1


331/405

11337

11338

12 Error Codes 11339

The following list of error codes can be returned in the error code and error number (errCode 11340 and errno attributes) within a dispositionReport response to the API calls defined in this 11341 specification. The descriptions in this section are general and when used with the specific 11342 return information defined in the individual API call descriptions are useful for determining the 11343 reason for failures or other reasons. A list of the valid UDDI errCode (errno) values follows: 11344

• E_accountLimitExceeded: (10160) Signifies that a save request exceeded the 11345 quantity limits for a given data type. Account limits are established based on the 11346 relationship between an individual publisher and an individual node. See your UDDI 11347 node’s policy for account limits for details. Other nodes in the registry MAY NOT place 11348 additional restrictions on publishing limits established by a custodial node. 11349

• E_assertionNotFound: (30000) Signifies that a particular publisher assertion cannot 11350 be identified in a save or delete operation. 11351

• E_authTokenExpired: (10110) Signifies that the authentication token information has 11352 timed out. 11353

• E_authTokenRequired: (10120) Signifies that an authentication token is missing or is 11354 invalid for an API call that requires authentication. 11355

• E_busy: (10400) Signifies that the request cannot be processed at the current time. 11356

• E_fatalError: (10500) Signifies that a serious technical error has occurred while 11357 processing the request. 11358

• E_historyDataNotAvailable: (40010) Signifies that the requested history data is not 11359 available for the time period requested. 11360

• E_invalidCombination: (40500) Signifies conflicting find qualifiers have been 11361 specified. The find qualifiers that caused the problem SHOULD be clearly indicated in 11362 the error text. 11363

• E_invalidCompletionStatus: (30100) Signifies that one of the assertion status 11364 values passed is unrecognized. The completion status that caused the problem 11365 SHOULD be clearly indicated in the error text. 11366

• E_invalidKeyPassed: (10210) Signifies that the uddiKey value passed did not match 11367 with any known key values. The details on the invalid key SHOULD be included in 11368 the dispositionReport element. 11369

• E_invalidProjection: (20230) Signifies that an attempt was made to save a 11370 businessEntity containing a service projection where the serviceKey does not belong 11371 to the business designated by the businessKey. The serviceKey of at least one such 11372 businessService SHOULD be included in the dispositionReport. 11373

• E_invalidTime: (40030) Signifies that the time period, the date/time, or the pair of 11374 date/time is invalid. The error structure signifies the condition that occurred and the 11375 error text clearly calls out the cause of the problem. 11376

• E_invalidValue: (20200) This error code has multiple uses. This error code applies 11377 to the subscription APIs and the value set APIs. It can be used to indicate that a value 11378 that was passed in a keyValue attribute did not pass validation. This applies to 11379 checked value sets that are referenced using keyedReferences. The error text 11380



��


332/405

SHOULD clearly indicate the key and value combination that failed validation. It can 11381 also be used to indicate that a chunkToken supplied is invalid. This applies in both 11382 subscription and value set APIs. The error text SHOULD clearly indicate the reason 11383 for failure. 11384

• E_keyUnavailable: (40100) Signifies that the proposed key is in a partition that has 11385 already been assigned to some other publisher. 11386

• E_messageTooLarge: (30110) Signifies that the message is too large. The upper 11387 limit SHOULD be clearly indicated in the error text. 11388

• E_noValuesAvailable: (40200) Signifies that an attempt to retrieve valid values 11389 yielded no (additional) values. 11390

• E_requestDenied: (20250) Signifies that a subscription cannot be renewed. The 11391 request has been denied due to either node or registry policy. 11392

• E_requestTimeout: (20240) Signifies that the request could not be carried out 11393 because a needed Web service, such as validate_values, did not respond in a 11394 reasonable amount of time. Details identifying the failing Web service SHOULD be 11395 included in the dispositionReport element. 11396

• E_resultSetTooLarge: (40300) Signifies that the UDDI node deems that a result set 11397 from an inquiry is too large, and requests to obtain the results are not honored, even 11398 using subsets. The inquiry that triggered this error should be refined and re-issued. 11399

• E_success: (0) Signifies no failure occurred. This return code is used with the 11400 dispositionReport for reporting results from requests with no natural response 11401 document. 11402

• E_tokenAlreadyExists: (40070) Signifies that one or more of the businessKey or 11403 tModelKey elements that identify entities to be transferred are not owned by the 11404 publisher identified by the authInfo element. The error text SHOULD clearly indicate 11405 which entity keys caused the error. 11406

• E_tooManyOptions: (10030) DEPRECATED. Signifies that too many arguments 11407 were passed. The error text SHOULD clearly indicate the nature of the problem. 11408

• E_transferNotAllowed: (40600) Signifies that the transfer of one or more entities has 11409 been by either the custodial node or the target node because the transfer token has 11410 expired or an attempt was made to transfer an unauthorized entity. 11411

• E_unacceptableSignature: (40400) Indicates that the digital signature in the entity is 11412 missing or does not meet the requirements of the registry. The errInfo element 11413 provides additional details. 11414

• E_unrecognizedVersion: (10040) Signifies that the value of the namespace attribute 11415 is unsupported by the node being queried. 11416

• E_unknownUser: (10150) Signifies that the user ID and password pair passed in a 11417 get_authToken API is not known to the UDDI node or is not valid. 11418

• E_unsupported: (10050) Signifies that the implementer does not support a feature or 11419 API. 11420

• E_userMismatch: (10140) Signifies that an attempt was made to use the publishing 11421 API to change data that is controlled by another party. 11422

• E_valueNotAllowed: (20210) Signifies that a value did not pass validation because 11423 of contextual issues. The value may be valid in some contexts, but not in the context 11424 used. The error text MAY contain information about the contextual problem. 11425


333/405

• E_unvalidatable: (20220) Signifies that an attempt was made to reference a value 11426 set in a keyedReference whose tModel is categorized with the unvalidatable 11427 categorization. 11428

11429

Non-error conditions are not reported by way of SOAP Faults but are instead reported using 11430 the dispositionReport element. 11431

12.1 Common Error Conditions 11432

In Chapter 5 UDDI Programmers APIs, a list of applicable error conditions are described in the 11433 Caveats sections of each API description. In addition to these error conditions that occur 11434 within each API’s context, there are error conditions that can occur at any time, for any of the 11435 UDDI APIs, for example, due to unavailability of the UDDI node or heavy network traffic. 11436 Unless there are special considerations associated with a given API, these overarching error 11437 conditions are not listed in the Caveats sections of the APIs. The error conditions that apply to 11438 the entire UDDI API are: 11439

• E_authTokenExpired 11440

• E_authTokenRequired 11441

• E_busy 11442

• E_fatalError 11443

• E_requestTimeout 11444

• E_unrecognizedVersion 11445

• E_unsupported. 11446

11447


334/405

11448

13 Related Standards and Specifications 11449

This document refers to other UDDI documents as well as several widely recognized 11450 standards and specifications. Detailed information on these may be found as follows: 11451

13.1 UDDI Specifications and documents 11452

UDDI Version 2.0 Operator’s Specification 11453

http://uddi.org/pubs/operators_v2.pdf 11454

UDDI Version 2.0 Custody Transfer Schema 11455

http://uddi.org/schema/uddi_2_custody.xsd 11456

UDDI Version 2.0 Programmer's API Specification 11457

http://uddi.org/pubs/ProgrammersAPI_v2.pdf 11458

UDDI Version 2.0 API Schema 11459

http://uddi.org/schema/uddi_v2.xsd 11460

UDDI Version 2.0 Replication Specification 11461

http://uddi.org/pubs/replication_v2.pdf 11462

UDDI Version 2.0 Replication Schema 11463

http://uddi.org/schema/uddi_v2_replication.xsd 11464

13.2 Standards and other Specifications 11465

Specification Location

Augmented BNF for Syntax Specifications: ABNF


Codes for the Representation of Names of Languages–Part 2: Alpha-3 Code

http://www.loc.gov/standards/iso639-2/langhome.html

Extensible Markup Language (XML) 1.0 http://www.w3.org/TR/1998/REC-xml-19980210.html

HTML 3.2 Reference Specification http://www.w3.org/TR/REC-html32

HTTP Over TLS http://www.ietf.org/rfc/rfc2818

Hypertext Transfer Protocol -- HTTP/1.1 http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf

Internet Security Glossary http://www.ietf.org/rfc/rfc2828

Internet X.509 Public Key Infrastructure http://www.ietf.org/rfc/rfc2459

ISO 3166-1: The Code List http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/index.html

ISO/IEC9075-2:1999(E)

Database Language - SQL

http://www.cse.iitb.ernet.in:8000/proxy/db/~dbms/Data/Papers-Other/SQL1999/

Schema Centric XML Canonicalization http://uddi.org/pubs/SchemaCentricCanonicalization.htm


335/405

Specification Location

Simple Object Access Protocol (SOAP) 1.1

http://www.w3.org/TR/SOAP

SMTP - Simple Mail Transfer Protocol http://www.ietf.org/rfc/rfc2821

SSL 3.0 Specification http://home.netscape.com/eng/ssl3/index.html

Tags for the Identification of Languages http://www.ietf.org/rfc/rfc3066

Terminology for Policy-Based Management


The Unicode Standard http://www.unicode.org/unicode/standard/standard.html

Unicode Standard Annex #15

UNICODE NORMALIZATION FORMS


Unicode Technical Standard #10

UNICODE COLLATION ALGORITHM


Uniform Resource Identifiers (URI): Generic Syntax


URLs for Telephone Calls http://www.ietf.org/rfc/rfc2806

UTF-16, an encoding of ISO 10646 http://www.ietf.org/rfc/rfc2781

UTF-8, a transformation format of ISO 10646


UUIDs and GUIDs http://uddi.org/pubs/draft-leach-uuids-guids-01.txt

Web Services Description Language (WSDL) 1.1

http://www.w3.org/TR/wsdl

XML Schema http://www.w3.org/XML/Schema#dev

11466


336/405

11467

A Appendix A: Relationships and Publisher 11468

Assertions 11469

UDDI includes a relationship feature based on “publisher assertions”. Publisher assertions 11470 are the basis for a mechanism to allow registered businessEntity elements to be linked in a 11471 manner that conveys a specific type of relationship. Publisher assertions are used to establish 11472 visible, reciprocal relationships between businessEntity elements in a way that once 11473 completed, a matching set of assertions can be seen by the find_relatedBusinesses and 11474 find_business calls. 11475

In order to make it possible for either party in a relationship to have some control over the 11476 visibility of the relationship, relationships are only visible when both parties of a potential 11477 relationship agree that such a relationship exists at a given point in time. This is done by both 11478 parties publishing publisherAssertions that are identical, with the exception of any optional 11479 digitalSignature elements that are assigned to the publisherAssertions. This addresses a 11480 problematic scenario that arises when one party falsely claims that it is related to some other 11481 party. 11482

Only publishers that control one of the businesses involved in the relationship are allowed to 11483 assert that a relationship exists. When a publisher controls both businessEntity structures 11484 involved in the relationship, a single publisherAssertion element satisfies the relationship (e.g., 11485 a second assertion is not required to form the relationship). In the case where a different 11486 publisher controls each businessEntity involved in such an expression, both parties must 11487 assert identical information about a specific relationship before UDDI surfaces any information 11488 about the relationship. In cases where two parties are involved and both parties do not agree 11489 as to the details of a given assertion, there is no requirement for either party to complete an 11490 assertion. No relationship is exposed via the Inquiry API in this case. 11491

A.1 Example 11492

The following picture shows the start of an assertion process: 11493

11494

11495

11496

Joe and Xina each manage a businessEntity within UDDI. As we start our scenario, both Joe 11497 and Xina have registered a businessEntity in the same UDDI registry. Joe and Xina wish to 11498 make it possible for users of this UDDI registry to find out that the two businesses are related 11499 and are in fact part of the same business, with Business1 being a parent-business. 11500

To make the relationship visible for anyone who calls find_relatedBusinesses passing either 11501 businessKey as a starting point, Joe and Xina must both make publisherAsssertion. As the 11502 name of the element suggests, a publisherAssertion is an assertion made by a publisher who 11503 is expressing a particular fact about a business registration and its relationship to some other 11504 business data within UDDI. 11505


337/405

Joe uses an add_publisherAssertions SOAP message to make a new publisherAssertion 11506 about Business1 and Business 2, expressing the fact that Business 1 is a corporate holding 11507 company. This message looks like: 11508

<add_publisherAssertions xmlns="urn:uddi-org:api_v3" > 11509 <authInfo>FFFFF</authInfo> 11510 <publisherAssertion> 11511 <fromKey>BK1</fromKey> 11512 <toKey>BK2</toKey> 11513 <keyedReference 11514 tModelKey=”uddi:uddi.org:relationships” 11515 keyName=”Holding Company” 11516 keyValue=”parent-child” /> 11517 </publisherAssertion> 11518 </add_publisherAssertions> 11519

11520

In this example, we see that Joe asserts that the businessEntity with the businessKey value of 11521 BK1 is the parent holding company of the businessEntity with the businessKey value of BK2. 11522 The publisherAssertion could be signed with an XML digital signature if Joe feels this is 11523 important. 11524

Because only Joe has asserted this fact, the information about the relationship is not yet visible 11525 via the inquiry API call, find_relatedBusinesses. Joe knows that for this assertion to become 11526 visible, the publisher of the businessEntity that has the businessKey BK2 must also express 11527 the same assertion. Joe calls Xina to let her know he wants her to make the assertion. 11528

In order to see the data that she must express, Xina sends a get_assertionStatusReport to her 11529 UDDI node. From the resulting assertionStatusReport, Xina sees that there is indeed an 11530 unmatched assertion listed against her businessEntity Business 2. Since Joe has contacted 11531 her and she agrees that the relationship should be visible within UDDI, Xina sends the exact 11532 same assertion (with a different authInfo credential) to her UDDI node. The publisherAssertion 11533 can be signed with an XML digital signature if such a signature is desired by Xina. 11534

The UDDI registry now sees both assertions made by the two publishers, each of whom 11535 control one of the two businesses involved. After checking that the requesting parties each 11536 control half of the relationship, UDDI matches the assertions together and the status of the 11537 relationship becomes complete. 11538

After this is done, anyone who calls the Inquiry API call, find_relatedBusinesses, and passes 11539 either BK1 or BK2 as the businessKey value will see the relationship. Prior to both publishers 11540 asserting this same fact, the data about the relationship is not visible via the Inquiry API. 11541

A.2 Managing relationship visibility 11542

The UDDI Publish API defines several APIs to allow assertions to be managed by UDDI 11543 publishers. These APIs fall into two general categories: administrative helpers and 11544 maintenance functions. The administrative helpers allow the publisher to see assertions that 11545 their businesses are involved in. In particular, the get_assertionStatusReport is the most 11546 useful for determining whether any assertions involving the business registrations owned by a 11547 publisher are incomplete. This provides information pertaining to assertions the publisher is 11548 expecting and also presents information about other publishers’ attempts at making 11549 unexpected assertions. 11550

The maintenance functions allow publishers to deal with all assertions as a single group (e.g. 11551 get_publisherAssertions / set_publisherAssertions) or individually (e.g. 11552 add_publisherAssertions / delete_publisherAssertions). The set_publisherAssertions call 11553 should be used with caution as it replaces all of the publisherAssertions for a publisher and can 11554 be used to invalidate existing completed relationships. The latter APIs are useful for adding 11555 one publisherAssertion at a time without having to keep track of all previous assertions. 11556


338/405

11557

B Appendix B: Using and Extending the useType 11558

Attribute 11559

UDDI provides type information through the useType attribute on the following UDDI elements: 11560 accessPoint, overviewURL, discoveryURL, contact, address, email and phone. The useType 11561 attribute is intended to provide information on how to use or invoke the resource contained 11562 within the element. This Appendix establishes and explains common values and conventions 11563 for the useType attribute in the context of certain elements, as well as a model for establishing 11564 new common values and conventions. 11565

B.1 accessPoint 11566

Four common values for providing type information about the accessPoint are: “endPoint”, 11567 “wsdlDeployment”, “bindingTemplate”, and “hostingRedirector. 11568

B.1.1 Using the “endPoint” value 11569

Typically, the network address of a Web service described by a bindingTemplate is found in 11570 the accessPoint element. This common behavior is denoted by using the string “endpoint” as 11571 the value of the accessPoint. Decorating an accessPoint with a useType=”endPoint” signifies 11572 that a user or application can invoke a Web service at that address. A sample of such 11573 behavior is as follows: 11574

<bindingTemplate bindingKey="uddi:example.org:catalog"> 11575 <description xml:lang="en"> 11576 Browse catalog Web service 11577 </description> 11578 <accessPoint useType=”endPoint”> 11579 http://www.example.org/CatalogWebService 11580 </accessPoint> 11581 <tModelInstanceDetails> 11582 <tModelInstanceInfo tModelKey="uddi:example.org:catalog_interface"/> 11583 <tModelInstanceInfo tModelKey="uddi:uddi.org:transport:http"/> 11584 </tModelInstanceDetails> 11585 </bindingTemplate> 11586 11587

In the example above, a client would be able to parse the bindingTemplate and discover the 11588 end point of the Web service itself. However, the information about how to invoke that Web 11589 service would be modeled using tModels. All interface information about that service would be 11590 represented by the tModelInstanceInfo structures contained as children of the 11591 bindingTemplate. 11592

The client knows the transport of the accessPoint either by checking to see if a protocol tModel 11593 has been associated with the bindingTemplate or inspecting the URI prefix. In the example 11594 above, the http transport was used, denoted by the tModelInstanceInfo. 11595


339/405

11596

UDDI RECOMMENDS that endpoints for phone, fax and modem communication follow the 11597 guidelines outlined in RFC 2806 URLs for Telephone Calls55. Following such a convention for 11598 a phone number accessPoint would result in the following bindingTemplate sample: 11599

<bindingTemplate bindingKey="uddi:example.org:catalog"> 11600 <description xml:lang="en"> 11601 Browse catalog Web service 11602 </description> 11603 <accessPoint useType=”endPoint”> 11604 tel:+1-512-555-1212 11605 </accessPoint> 11606 <tModelInstanceDetails> 11607 <tModelInstanceInfo tModelKey="uddi:uddi.org:transport:telephone"/> 11608 </tModelInstanceDetails> 11609 </bindingTemplate> 11610

11611

B.1.2 Using the “wsdlDeployment” value 11612

Instead of directly providing the network address in the accessPoint, it is occasionally useful or 11613 necessary to provide this information through indirect means. One common scenario for such 11614 a behavior is when the accessPoint is embedded within a WSDL file. In such a scenario, the 11615 UDDI accessPoint contains the address of the WSDL file, and the client then must retrieve the 11616 WSDL file and extract the end point address from the WSDL file itself. 11617

In this case, decorating the UDDI accessPoint with a useType=”wsdlDeployment” is 11618 appropriate. A sample of such behavior is as follows: 11619

<bindingTemplate bindingKey="uddi:example.org:catalog"> 11620 <description xml:lang="en"> 11621 Browse catalog Web service 11622 </description> 11623 <accessPoint useType=”wsdlDeployment”> 11624 http://www.example.org/CatalogWebService/catalog.wsdl 11625 </accessPoint> 11626 <categoryBag> 11627 <keyedReference keyName=”uddi-org:types:wsdl” 11628 keyValue="wsdlDeployment" 11629 tModelKey="uddi:uddi.org:categorization:types”/> 11630 </categoryBag> 11631 </bindingTemplate> 11632 11633

In the example above, a client would be able to parse the result of the bindingTemplate and 11634 determine the end point of the Web service within the WSDL file discovered in the accessPoint 11635 element. Note that the bindingTemplate has also been categorized with the “wsdlDeployment” 11636 value from the uddi.org:categorization:types scheme so that it can be discovered through a 11637 find_binding API call. 11638

B.1.3 Using the “bindingTemplate” value 11639

Another form of indirection uses UDDI itself to discover the location of the final end point. 11640 Categorizing a bindingTemplate with either “bindingTemplate” or “hostingRedirector” specifies 11641 that the accessPoint contains a bindingKey intended to be used in a get_bindingDetail API call 11642 to a UDDI registry Inquiry API Set. How the resultant bindingTemplate is interpreted depends 11643 on which one of the two methods described below is used. In the case of “bindingTemplate”, a 11644 bindingKey refers to another binding within the same UDDI registry. 11645

55



340/405

For example, suppose tempuri.com, the well known but fictitious maker of crispy batter coating 11646 for fried foods, contracts with the equally fictitious Web service hosting company ws-o-11647 rama.com to host tempuri’s Web service that exposes its product catalog. Tempuri.com 11648 wishes to publish a bindingTemplate for this service in the UDDI Business Registry, but wishes 11649 to leave the details of the technical implementation and its description up to ws-o-rama.com 11650 who may wish to change them over time. To do this, tempuri.com and ws-o-rama.com use 11651 bindingTemplate indirection. In the UDDI Business Registry the bindingTemplate in tempuri’s 11652 businessEntity that describes this service appears as follows: 11653

<bindingTemplate bindingKey="uddi:tempuri.com:catalog"> 11654 <description xml:lang="en"> 11655 Browse catalog Web service 11656 </description> 11657 <accessPoint useType=”bindingTemplate”> 11658 uddi:ws-o-rama.com:tempuri:bt1 11659 </accessPoint> 11660 </bindingTemplate> 11661 11662

Here, the bindingTemplate describing tempuri’s catalog browsing Web service uses an 11663 accessPoint to refer to the bindingTemplate (also in the UDDI Business Registry) whose 11664 bindingKey is uddi:ws-o-rama.com:tempura:bt1. When a client does a get_bindingDetail 11665 asking for the bindingTemplate with that key, the following bindingTemplate is returned: 11666

<bindingTemplate bindingKey="uddi:ws-o-rama.com:tempuri:bt1"> 11667 <description xml:lang="en"> 11668 Tempuri.com’s catalog browsing service hosted by ws-o-rama 11669 </description> 11670 <accessPoint useType=”endPoint”> 11671 http://sf1.ws-o-rama.com/tempuri/catalog/ 11672 </accessPoint> 11673 <tModelInstanceDetails> 11674 <tModelInstanceInfo tModelKey="uddi:..."/> 11675 </tModelInstanceDetails> 11676 </bindingTemplate> 11677

11678

This bindingTemplate describes the actual Web service that is to be used. 11679

B.1.4 Using the “hostingRedirector” value 11680

It may be necessary to “hide” the network address of a Web service from unauthorized 11681 access. In this case, a useType=”hostingRedirector” can be used to indicate that the client 11682 must follow a longer path of indirection to retrieve the accessPoint. In the bindingTemplate, 11683 the client will discover a bindingKey, which will lead to a bindingTemplate that contains the end 11684 point for a Web service which supports the UDDI get_bindingDetail Web Service. The client 11685 will then be able to re-issue the get_bindingDetail message with the original key, presumably 11686 with authentication, to this other Web service. Such an indirection mechanism allows a Web 11687 service to be discoverable but not accessible from a given node. 11688

For example, tempuri.com uses ws-o-rama.com to host more than just its publicly visible 11689 catalog browsing service. In particular it has a number of services it does not wish to expose 11690 fully in the UDDI Business Registry. Instead, it wishes to keep their full definition in its private 11691 UDDI registry, which ws-o-rama.com also happens to host, and supply the end points to these 11692 Web services only to authorized inquirers. 11693

In particular, tempuri has a Web service that its suppliers use to bill it for goods they deliver. In 11694 the UDDI Business Registry, tempuri publishes the following bindingTemplate, which contains 11695 a bindingKey. 11696

<bindingTemplate bindingKey="uddi:tempuri.com:billing"> 11697 <description xml:lang="en"> 11698 Tempuri supplier billing Web service 11699 </description> 11700 <accessPoint useType=”hostingRedirector”> 11701 uddi:ws-o-rama.com:tempuri:bt47 11702


341/405

</accessPoint> 11703 </bindingTemplate> 11704

11705

Here, the bindingTemplate describing tempuri’s supplier billing Web service uses an 11706 accessPoint to refer to the bindingTemplate (also in the UDDI Business Registry) whose 11707 bindingKey is uddi:ws-o-rama.com: tempuri:bt47. Note that the useType equals 11708 “hostingRedirector” which indicates that the bindingKey refers to a hostingRedirector service. 11709 When a client does a get_bindingDetail (on the UDDI Business Registry) asking for the 11710 bindingTemplate with that key, the following indirect bindingTemplate is returned: 11711

<bindingTemplate bindingKey="uddi:ws-o-rama.com:tempura:bt47"> 11712 <description xml:lang="en"> 11713 Hosting Redirector Service for Tempuri.com 11714 hosted by ws-o-rama.com 11715 </description> 11716 <accessPoint useType=”endPoint”> 11717 http://sf1.ws-o-rama.com/tempuri/uddi/inquiry 11718 </accessPoint> 11719 <tModelInstanceDetails> 11720 <tModelInstanceInfo 11721 tModelKey="uddi:uddi.org:specification:hostingredirector"/> 11722 </tModelInstanceDetails> 11723 </bindingTemplate> 11724 11725

This bindingTemplate describes the hosting redirector Web service hosted for tempuri.com by 11726 ws-o-rama.com. By definition, it responds to the get_bindingDetail API call using SOAP over 11727 HTTP. The description in the bindingTemplate says it responds only to authorized requests. 11728 For authorized clients, invoking get_bindingDetail, passing the key of the original 11729 bindingTemplate (uddi:tempuri.com:billing) retrieves the following bindingTemplate: 11730

<bindingTemplate bindingKey="uddi:tempuri.com:billing"> 11731 <description xml:lang="en"> 11732 Tempuri.com’s supplier billing browsing service 11733 hosted by ws-o-rama.com 11734 </description> 11735 <accessPoint useType=”endPoint”> 11736 http:sf1.ws-o-rama.com/tempuri/billing/ 11737 </accessPoint> 11738 <tModelInstanceDetails> 11739 <tModelInstanceInfo tModelKey="uddi:..."/> 11740 </tModelInstanceDetails> 11741 </bindingTemplate> 11742

11743

This bindingTemplate describes the actual Web service that is to be used. 11744

B.2 overviewURL 11745

The overviewURL appears as a child of the overviewDoc, which appears twice in the UDDI 11746 information model, once with tModel element and once with tModelInstanceInfo element. 11747 There are two conventions established, “text” and “wsdlInterface”. 11748



342/405

11749

B.2.1 Using the “text” value 11750

Using the useType of “text” signifies that textual information meant for human consumption is 11751 available at the resource specified by that URL. It is appropriate both for tModel and 11752 tModelInstanceInfo elements. 11753

The following example demonstrates an overviewURL that points to a .pdf file that discusses 11754 more about the implementation of the uddi:tempuri.org:catalog_interface tModel 11755 implemented. It might explain particular details about this implementation that a developer 11756 needs to know. 11757

<tModelInstanceInfo tModelKey="uddi:tempuri.org:catalog_interface"> 11758 <instanceDetails> 11759 <overviewDoc> 11760 <description xml:lang="en">This overviewURL provides additional 11761 information about this Web service.</description> 11762 <overviewURL useType="text">http://tempuri.org/info.pdf</overviewURL> 11763 </overviewDoc> 11764 </instanceDetails> 11765 </tModelInstanceInfo> 11766

11767

B.2.2 Using the “wsdlInterface” value 11768

The “wsdlInterface” value signifies that a WSDL file is located at this resource. Such a WSDL 11769 file has no implementation information, but exists purely as an abstract interface document. 11770 Using this convention within a tModelInstanceInfo is not appropriate. 11771

For example, the tModel below has two overviewDocs. The first, which uses the 11772 “wsdlInterface” value, denotes that the overviewURL points to WSDL file. The second 11773 overviewDoc provides additional information about the tModel, using the “text” value. 11774

<tModel tModelKey=”uddi:tempuri.org:catalog_interface”> 11775 <name>urn:tempuri.org:catalog_interface</name> 11776 <description>This WSDL interface has a set of APIs for querying the catalog 11777 service.</description> 11778 <overviewDoc> 11779 <overviewURL useType=”wsdlInterface”> 11780 http://www.tempuri.org/wsdl/catalog_interface.wsdl 11781 </overviewURL> 11782 </overviewDoc> 11783 <overviewDoc> 11784 <overviewURL useType=”text”> 11785 http://www.tempuri.org/wsdl/interface_info.pdf 11786 </overviewURL> 11787 </overviewDoc> 11788 <categoryBag> 11789 <keyedReference keyName=”uddi-org:types:wsdl” 11790 keyValue="wsdlSpec" 11791 tModelKey="uddi:uddi.org:categorization:types”/> 11792 <keyedReference keyName=”uddi-org:types:soap” 11793 keyValue="soapSpec" 11794 tModelKey="uddi:uddi.org:categorization:types”/> 11795 <keyedReference keyName=”uddi-org:types:xml” 11796 keyValue="xmlSpec" 11797 tModelKey="uddi:uddi.org:categorization:types”/> 11798 <keyedReference keyName=”uddi-org:types:specification” 11799 keyValue="specification" 11800 tModelKey="uddi:uddi.org:categorization:types”/> 11801 </categoryBag> 11802 </tModel> 11803


343/405

11804 11805 11806

B.3 discoveryURL 11807

The discoveryURL only appears at the businessEntity level. Two conventions have been 11808 established: “businessEntity” and “homepage”. 11809

B.3.1 Using the “businessEntity” value 11810

Per the UDDI Specification, discoveryURLs qualified with the value “businessEntity” point to 11811 XML documents of the type businessEntity, as defined in the UDDI API Schema. 11812

<discoveryURL useType=”businessEntity”> 11813 http://www.example.com?businessKey= uddi:example.com:registry:sales:53 11814 </discoveryURL> 11815 11816

B.3.2 Using the “homepage” value 11817

Frequently, businesses and providers want to register HTTP-accessible HTML Web 11818 “homepage” information. The discoveryURL useType of “homepage” satisfies that purpose: 11819

<discoveryURL useType=”homepage”> 11820 http://www.example.com 11821 </discoveryURL> 11822

B.4 Contact 11823

No conventions have been established. 11824

B.5 Address 11825


B.6 Phone 11827


B.7 Email 11829


B.8 Designating a new useType value 11831

While the useType conventions listed above cover a set of common cases, there may be 11832 situations which a new useType attribute for an element needs to be designated. UDDI 11833 RECOMMENDS56 that the creation of new useType values should map to UDDI tModelKeys. 11834 In such a way, a client can look up the tModel to understand the semantic meaning of this 11835 unknown useType attribute. 11836

For example, imagine a new kind of indirection mechanism for the accessPoint element is 11837 created that involves a new protocol. In this example the new protocol refers to files that have 11838 a file extension of .nwp (for NeW Protocol). In order to decorate accessPoints with a useType 11839 attribute that refers to this protocol, a new tModel should be published to UDDI, categorized by 11840 the UDDI Types taxonomy, as follows: 11841

11842

56

Because the datatype of the useType is xsd:string, any value can be placed in this attribute, such as a well known URI. However, by following the recommended practice, there is a known way of determining more information about the meaning of the alien useType value.

��


344/405

<tModel tModelKey=”uddi:tempuri.org:tmodel:newprotocol”> 11843 <name>tempuri.org:tModel:NewProtocol</name> 11844 <description>A tModel that represents the useType for the new protocol 11845 </description> 11846 <overviewDoc> 11847 <overviewURL useType=”text”> 11848 http://tempuri.org/NewProtocol/about.htm 11849 </overviewURL> 11850 </overviewDoc> 11851 <categoryBag> 11852 <keyedReference keyName=”uddi-org:types:useTypeDesignator” 11853 keyValue="useTypeDesignator" 11854 tModelKey="uddi:uddi.org:categorization:types”/> 11855 </categoryBag> 11856 </tModel> 11857

11858

This tModel establishes the new useType value “uddi:tempuri.org:tmodel:newprotocol”. Its 11859 categorization as a “useTypeDesignator” semantically signifies this purpose. When using this 11860 useType in an accessPoint, the key of the tModel is used as the value, as follows: 11861

<bindingTemplate bindingKey="uddi:tempuri.com:some_service"> 11862 <description xml:lang="en"> 11863 Tempuri Web service 11864 </description> 11865 <accessPoint useType=”uddi:tempuri.org:tmodel:newprotocol”> 11866 http://www.tempuri.org/service.nwp 11867 </accessPoint> 11868 </bindingTemplate> 11869

11870

When a client encounters this unfamiliar useType in a bindingTemplate, the client can issue a 11871 get_tModelDetail with the value found in the useType attribute, thus learning the technical 11872 nature of this accessPoint. 11873

11874

�� tModel:NewProtocol

��

�� tModel:NewProtocol”.

�� tModel:NewProtocol


345/405

11875

C Appendix C: Supporting Subscribers 11876

This appendix describes scenarios where subscription is useful and provides examples of how to use 11877 subscription. 11878

C.1 Subscription Scenarios 11879

Subscription support is intended to provide clients or subscribers with the ability to register interest in 11880 receiving information concerning changes made to the specified subsets of the data in a UDDI Registry 11881 and then to obtain updates to the subset on a periodic basis as the data changes. There are several 11882 scenarios for which subscription is useful. Among the common uses are: 11883

• Notification of new businesses or services that register - A subscriber may be 11884 interested in receiving notification whenever a new business or service becomes 11885 available that conforms to a pre-defined set of criteria. This might be a business that 11886 could be a new potential business partner. The subscriber can simply register to be 11887 informed when new users of certain tModels emerge, for instance, expanding his 11888 potential base of suppliers. 11889

• Monitoring of existing businesses or services - A subscriber may be interested in 11890 receiving an update on a particular business or service whenever it is altered in any 11891 manner, including deletion. A subscriber can use subscription to monitor a particular 11892 service or business, receiving a notification whenever there is a change in the registry 11893 entry for that particular service or business. 11894

• Obtaining Registry data for use in a private UDDI Registry – A subscriber might 11895 represent a private UDDI registry installation operated by a particular industry. A node 11896 might, for example, wish to augment its own content with relevant entries from the 11897 UDDI Business registry. Subscription allows them to track and receive all changes of 11898 interest for integration into their own registry. In another example, the private registry 11899 might even wish to mirror all of the data present in another registry with which it does 11900 not replicate. This capability is by creating a small number of subscriptions. 11901

• Obtaining Registry data for use by a Registrar – A subscriber might be a Registrar 11902 who facilitates creation and maintenance of Registry entries in the UDDI Business 11903 Registry for a specialized set of customers. As it happens, information about existing 11904 relationships in the Registry which various business partners maintain with each other 11905 affect the maintenance of business relationships with these customers. The 11906 Registrar offers a service to these customers to automatically maintain their 11907 relationship information based on a profile these customers maintain with the 11908 Registrar. Subscription enables the Registrar to perform this service by providing 11909 notification of changes in business relationships 11910

• Obtaining Registry data for use by eMarketplaces – A subscriber might represent 11911 an eMarketplace which has become a portal for a particular industry. The 11912 eMarketplace combines and organizes all of the Web service offerings across multiple 11913 UDDI Registries which interest its customers, offering them one-stop shopping. 11914 Subscription helps this eMarketplace keep abreast of new and changing service 11915 offerings without having to troll these Registries on a continuous basis. 11916


346/405

11917

C.2 Using Subscription 11918

This section describes the steps involved in using the subscription API set and provides several 11919 examples. 11920

C.2.1 Steps for Creating a Subscription 11921

Establishing a subscription and monitoring the results is in general a multi-step process: 11922

1. Create a service to receive the notifications the registry provides. Subscribers can choose to 11923 receive subscriptions through either HTTP/SOAP Web services they implement, or via e-mail. 11924 As many bindingTemplates of either type can be defined as desired if multiple endpoints are 11925 required, but only one bindingTemplate can be associated with a given subscription. 11926

2. Register the service with the registry, which the node is to use to deliver notifications. This 11927 requires registering of a single bindingTemplate describing the service. Note that a single 11928 service can be used to receive the notifications for multiple subscriptions or, if the subscriber 11929 chooses, separate services can be created for each subscription. 11930

3. Select the filter criteria to be used for the subscription. This requires some care – choosing 11931 more restrictive criteria reduces the result set returned making it simpler to analyze. In 11932 general, subscribers should insure that the subscriptionFilter criterion they use is as restrictive 11933 as possible. 11934

4. Save the subscription request using save_subscription. 11935

5. Process the incoming HTTP/SOAP or e-mail notifications as desired. 11936

C.2.2 Subscription Examples 11937

In most cases, the actual values of the various keys and authInfo elements involved in these examples 11938 are not shown, but are instead represented in bold italics descriptions. 11939

1. Create a subscription to track changes in businesses which offer services in the Motor Vehicle 11940 Parts industry. To accomplish this, the subscriber needs to register a service with a 11941 bindingTemplate indicating a desire to receive notifications through an endpoint which 11942 corresponds to either a notify_subscriptionListener service (which the subscriber implements), 11943 or via email. Here are examples of each of these two types of bindings: 11944

<save_binding xmlns="urn:uddi-org:api_v3"> 11945 <authInfo>myAuthCode</authInfo> 11946 <bindingTemplate bindingKey=”” serviceKey=”uddi:myservicekey”> 11947 <description>notify_subscriptionListener binding for 11948 my subscription. 11949 </description> 11950 <accessPoint URLType=”https”> 11951 https://www.myCompany.com/services/notify_subscriptionListener 11952 </accessPoint> 11953 <tModelInstanceDetails> 11954 <tModelInstanceInfo 11955 tModelKey="uddi:uddi.org:v3_subscriptionlistener" /> 11956 </tModelInstanceDetails> 11957 </bindingTemplate> 11958 </save_binding> 11959 <save_binding xmlns="urn:uddi-org:api_v3"> 11960 <authInfo>myAuthCode</authInfo> 11961 <bindingTemplate bindingKey=”” serviceKey=”uddi:myservicekey”> 11962 <description>E-mail binding for my subscription.</description> 11963 <accessPoint URLType=”email”> 11964 mailto:[email protected] 11965 </accessPoint> 11966 </bindingTemplate> 11967 </save_binding> 11968

�� myServiceKey


�� myServiceKey


347/405

11969

Let’s use the notify_subscriptionListener binding and register a subscription request to return a 11970 notification every 5 days. Our subscriptionFilter will limit the results to new, changed or deleted 11971 services categorized as “Motor Vehicle Supplies and New Parts Wholesalers” using the North 11972 American Industry Classification System (NAICS). Note that the brief attribute is used to force 11973 only entity keys to be returned in the results: 11974

<save_subscription xmlns=”urn:uddi-org:sub_v3”> 11975 <authInfo>myAuthCode</authInfo> 11976 <subscriptions> 11977 <subscription brief=”true”> 11978 <subscriptionFilter> 11979 <find_service xmlns="urn:uddi-org:api_v3" > 11980 <findQualifiers> 11981 <findQualifier> 11982 uddi:uddi.org:findqualifier:sql99:like 11983 </findQualifier> 11984 </findQualifiers> 11985 <categoryBag> 11986 <keyedReference 11987 tModeKey=”uddi:uddi.org:ubr:taxonomy:naics” 11988 keyName=”Motor Vehicle Parts” 11989 keyValue=”42112_”/> 11990 </categoryBag> 11991 </find_service> 11992 </subscriptionFilter> 11993 <bindingKey> 11994 bindingKeyOfTheClientsNotifySubscriptionListenerService 11995 </bindingKey> 11996 <notificationInterval>P5D</notificationInterval> 11997 <maxEntities>1000</maxEntities> 11998 </subscription> 11999 </subscriptions> 12000 </save_subscription> 12001

�� findQualifier:SQL99

�� ubr.


348/405

12002

An example of the node’s subsequent invocation of the client implemented 12003 notify_subscriptionListener API is shown below. The call to 12004 notify_subscriptionListener by the node transmits data for January 2002 using the 12005 lexical representation of dateTime as defined by [ISO 8601], in the extended format of 12006 CCYYMMDDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the 12007 month and "DD" the day. The letter "T" is the date/time separator and "hh", "mm", "ss" 12008 represent hour, minute and second respectively: 12009

<notify_subscriptionListener> 12010 <subscriptionResultsList> 12011 <coveragePeriod> 12012 <startPoint>20020101T00:00:00</startPoint> 12013 <endPoint>20020131T00:00:00</endPoint> 12014 </coveragePeriod> 12015 <subscription brief=”true”> 12016 <subscriptionFilter> 12017 <find_service xmlns="urn:uddi-org:api_v3" > 12018 <findQualifiers> 12019 <findQualifier> 12020 uddi:uddi.org:findqualifier:sql99:like 12021 </findQualifier> 12022 </findQualifiers> 12023 <categoryBag> 12024 <keyedReference 12025 tModeKey=”uddi:uddi.org:ubr:taxonomy:naics” 12026 keyName=”Motor Vehicle Parts” 12027 keyValue=”42112_”/> 12028 </categoryBag> 12029 </find_service> 12030 </subscriptionFilter> 12031 <bindingKey> 12032 bindingKeyOfTheClientsNotifySubscriptionListenerService 12033 </bindingKey> 12034 <notificationInterval>P5D</notificationInterval> 12035 <maxEntities>1000</maxEntities> 12036 <expiresAfter>20030101T00:00:00</expiresAfter> 12037 </subscription> 12038 <keyBag> 12039 <deleted>false</deleted> 12040 <serviceKey>matchingKey1</serviceKey> 12041 <serviceKey>matchingKey2</serviceKey> 12042 <serviceKey>matchingKey3</serviceKey> 12043 <serviceKey>matchingKey4</serviceKey> 12044 </keyBag> 12045 <keyBag> 12046 <deleted>true</deleted> 12047 <serviceKey>matchingKey5</serviceKey> 12048 <serviceKey>matchingKey6</serviceKey> 12049 </keyBag> 12050 </subscriptionResultsList> 12051 </notify_subscriptionListener> 12052 12053


�� ubr.


349/405

12054

2. Use get_subscriptionResults to retrieve chunked subscription results synchronously. In this 12055 example, we reuse the same <save_subscription> API call shown in example (1) with the 12056 exception that no <bindingKey> is provided. This prevents notifications from being sent under 12057 the assumption that the client desires to use the get_subscriptionResults API to do this 12058 instead. Here is a typical use of the get_subscriptionResults API. The request shown 12059 retrieves results available for changes made since the beginning of January 2002: 12060

<get_subscriptionResults> 12061 <authInfo>myAuthCode</authInfo> 12062 <subscriptionKey>mySubscriptionKey</subscriptionKey> 12063 <coveragePeriod> 12064 <startPoint>20020101T00:00:00</startPoint> 12065 </coveragePeriod> 12066 </get_subscriptionResults> 12067 12068

The above request should return all subscription results matching the criterion we 12069 saved in the subscription for entities whose last date of change was on or after 12070 January 1st, 2002, up through the present time. A subscriptionResultsList is returned 12071 synchronously by the get_subscriptionResults API: 12072

12073

<subscriptionResultsList> 12074 <chunkToken>”nodeGeneratedToken”</chunkToken> 12075 <coveragePeriod> 12076 <startPoint>20020101T00:00:00</startPoint> 12077 </coveragePeriod> 12078 <subscription brief=”true”> 12079 <subscriptionFilter> 12080 <find_service xmlns="urn:uddi-org:api_v3" > 12081 <findQualifiers> 12082 <findQualifier> 12083 uddi:uddi.org:findqualifier:sql99:like 12084 </findQualifier> 12085 </findQualifiers> 12086 <categoryBag> 12087 <keyedReference 12088 tModeKey=”uddi:uddi.org:ubr:taxonomy:naics” 12089 keyName=”Motor Vehicle Parts” 12090 keyValue=”42112_”/> 12091 </categoryBag> 12092 </find_service> 12093 </subscriptionFilter> 12094 <bindingKey> 12095 bindingKeyOfTheClientsNotifySubscriptionListenerService 12096 </bindingKey> 12097 <notificationInterval>P5D</notificationInterval> 12098 <maxEntities>1000</maxEntities> 12099 <expiresAfter>20030101T00:00:00</expiresAfter> 12100 </subscription> 12101 <keyBag> 12102 <deleted>false</deleted> 12103 <serviceKey>matchingKey1</serviceKey> 12104 <serviceKey>matchingKey2</serviceKey> 12105 <serviceKey>matchingKey3</serviceKey> 12106 <serviceKey>matchingKey4</serviceKey> 12107 </keyBag> 12108 </subscriptionResultsList> 12109 12110


�� ubr.


350/405

12111

Unfortunately, there are too many results for us to get them in one group since we 12112 noticed that the chunkToken value of “nodeGeneratedToken” returned was not “0”, 12113 so chunking is being used. We use this “nodeGeneratedToken” to call 12114 get_subscriptionResults again to retrieve the next group of results: 12115

12116

<get_subscriptionResults> 12117 <authInfo>myAuthCode</authInfo> 12118 <subscriptionKey>mySubscriptionKey</subscriptionKey> 12119 <coveragePeriod> 12120 <startPoint>20020101T00:00:00</startPoint> 12121 </coveragePeriod> 12122 <chunkToken>nodeGeneratedToken</chunkToken> 12123 </get_subscriptionResults> 12124 12125

The remaining results are returned synchronously in a subscriptionResultsList structure as 12126 before. The last results have been returned when the chunkToken returned in the 12127 subscriptionResultsList is “0”.12128


351/405

12129

D Appendix D: Internationalization 12130

12131

As part of the aim of providing a registry for universal description, discovery and integration of 12132 business entities and their services, the UDDI registry design includes support for 12133 internationalization features. Most of these internationalization features are directly exposed to 12134 end users through the API sets. Others are built into the design in order to enable the use of 12135 the UDDI registry as an international Web services discovery and description mechanism with 12136 multilingual descriptions of business entities worldwide. This appendix provides examples for 12137 some of the internationalization features supported: 12138

• multilingual descriptions, names and addresses 12139

• multiple names in the same language 12140

• internationalized address format 12141

• language-dependent collation 12142

D.1 Multilingual descriptions, names and addresses 12143

The description, name, personName, or address elements may each have an xml:lang 12144 attribute to indicate the language used in the content of these elements. Thus names and 12145 addresses, for example, may have characters from language scripts other than the Latin script 12146 found in ASCII. Similarly, variants of names, due to transliteration, e.g. romanization, to 12147 different languages, are indicated through the use of the xml:lang attribute. The rules and 12148 syntax governing the xml:lang data type are as defined in Section 3.3.2.3 name. 12149

The following shows an example of romanization where the primary name of the business (a 12150 Chinese flower shop) is in Chinese, and its alternative name is a romanization: 12151

<businessEntity . . . > 12152 ........ 12153 <name xml:lang="zh">�� </name> 12154 <name xml:lang="en">Huang He Hwa Dian</name> 12155 ..... 12156 </businessEntity> 12157

12158

The following shows an example of transliteration where the primary name of the business is 12159 in Chinese, and is a transliteration of its alternative English name: 12160

<businessEntity . . . > 12161 ........ 12162 <name xml:lang="zh">�� </name> 12163 <name xml:lang="en">Compaq Computer Taiwan Limited</name> 12164 ..... 12165 </businessEntity> 12166


352/405

12167

The following example XML fragment shows an address written in two languages, English and 12168 Chinese, as indicated by the xml:lang attribute: 12169

<address useType=”Sales office” xml:lang="en" tModelKey=”uddi:…”> 12170 <addressLine>7 F</addressLine> 12171 <addressLine>No. 245 </addressLine> 12172 <addressLine>Sec. 1</addressLine> 12173 <addressLine>Tunhua South Road</addressLine> 12174 <addressLine>Taipei </addressLine> 12175 </address> 12176 </address><address useType=”Sales office” xml:lang="zh" tModelKey=”uddi:…”> 12177 <addressLine> �� </addressLine> 12178 <addressLine> �� </addressLine> 12179 <addressLine> � </addressLine> 12180 <addressLine> 245 � </addressLine> 12181 <addressLine> 7 � </addressLine> 12182 … 12183 </address> 12184 12185

D.2 Multiple names in the same language 12186

In order to support acronyms or multi-script languages, it is valid to publish multiple names that 12187 have identical language identification. 12188

The following shows an example of use of multiple name elements to support a multi-script 12189 language and also the use of acronym. In the example, the first <name> element is the 12190 primary name of the business (a Japanese flower shop) in Japanese Kanji. The second 12191 <name> element is the business’ name transliterated into Japanese Katakana. The third 12192 <name> element gives the business’ full English name, and the fourth <name> element gives 12193 its English acronym: 12194

<businessEntity . . . > 12195 ........ 12196 <name xml:lang="ja"> �� </name> 12197 <name xml:lang="ja"> �� </name> 12198 <name xml:lang="en">NIPPON FLOWERS </name> 12199 <name xml:lang="en">NF</name> 12200 ..... 12201 </businessEntity> 12202

12203

Where multiple name elements are published, the first name element is treated as the primary 12204 name, which is the name by which a business would be searched and sorted in the case of 12205 multiply-named businesses. Client applications may use this knowledge to assist in optional 12206 rendering of a publisher’s primary name or all alternative names. 12207

D.3 Internationalized address format 12208

The <address> element, contained in the businessEntity structure, contains a simple list of 12209 <addressLine> elements. 12210

To expose an address’ structure and meaning, virtual keyedReference elements are 12211 employed. This is done by adorning the <address> element with a tModelKey attribute and 12212 use of the keyName/keyValue attribute pair for each <addressLine> element. 12213

Additionally, the UDDI Business Registry has a canonical tModel, ubr-uddi-org:postalAddress, 12214 that identifies a canonical postal address structure with common address sub-elements (e.g. 12215 states, cities). This canonical address structure describes address data via name/code pairs, 12216 enabling each common address sub-element to be identified by name or code. 12217

The following example XML fragment shows how the application of tModelKey, keyName and 12218 keyValue attributes to <address>, in conjunction with the use of address sub-element names 12219


353/405

and codes defined by the ubr-uddi-org:postalAddress tModel, allows the structure and 12220 meaning of a contact’s address within a businessEntity to be derivable programmatically: 12221

12222

<address useType=”Sales office” tModelKey=”uddi:uddi.org:ubr:postaladdress”> 12223 <addressLine keyName=”Street” keyValue=”60”>Alexanderplatz</addressLine> 12224 <addressLine keyName=”House number” keyValue=”70”>12</addressLine> 12225 … 12226 <addressLine keyName=”Country” keyValue=”20”>Deutschland</addressLine> 12227 </address> 12228

12229

The following example XML fragment shows an address in two languages where the 12230 sequence of the address lines differ according to the language used. With the use of 12231 keyName/KeyValue pair together with the codes assigned in the ubr-uddi-org:postalAddress 12232 tModel, it is possible to determine the address semantics programmatically in spite of the 12233 difference in address sequence : 12234

<address useType=”Sales office” xml:lang="en" 12235 tModelKey=”uddi:uddi.org:ubr:postaladdress”> 12236 <addressLine keyName=”Floor” keyValue=”100”>7 F</addressLine> 12237 <addressLine keyName=”House Number” keyValue=”70”>No. 245 </addressLine> 12238 <addressLine keyName=”District” keyValue=”50”>Sec. 1</addressLine> 12239 <addressLine keyName=”Street” keyValue=”60”>Tunhua South Road</addressLine> 12240 <addressLine keyName=”City” keyValue=”40”>Taipei </addressLine> 12241 </address> 12242 </address><address useType=”Sales office” xml:lang="zh" 12243 tModelKey=”uddi:uddi.org:ubr:postaladdress”> 12244 <addressLine keyName=”City” keyValue=”40”> �� </addressLine> 12245 <addressLine keyName=”Street” keyValue=”60”> �� </addressLine> 12246 <addressLine keyName=”District” keyValue=”50”> �� </addressLine> 12247 <addressLine keyName=”House Number” keyValue=”70”> 245 </addressLine> 12248 <addressLine keyName=”Floor” keyValue=”100”> 7 � </addressLine> 12249 … 12250 </address> 12251

12252

As there is a large variation in address sub-elements of different countries57, the defined 12253 canonical address structure does not attempt to include all possible address sub-elements of 12254 all countries. Freeform address lines are therefore supported in the <address> element. 12255

The usage of the canonical address structure is optional, but recommended, for both 12256 publishers of business entities and developers of GUIs of UDDI publishing services. 12257

57

For information on other address format standardization efforts, refer to standards bodies, such as the Universal Postal Union and ECCMA, which defines an International Address Element Code (IAEC).

�� ubr.

�� postalAddress

�� ubr.


�� ubr.



354/405

12258

D.4 Language–dependent collation 12259

The UDDI specifications allow the collation sequence of results returned by the Inquiry APIs to 12260 be specified via find qualifiers. The following is an example tModel overviewDoc that illustrates 12261 the specification of a language-specific sort order tModel based on a language-specific 12262 collation standard, in this case, the JIS X 4061 Japanese Collation Sequence. 12263

D.4.1 UDDI JIS X 4061 Japanese Sort Order Qualifier 12264

D.4.1.1 Introduction 12265

The sortOrder type of find qualifier (a subset of find qualifier) represents a collation sequence 12266 applied to the result set. The JIS X 4061 Japanese sortOrder find qualifier directs that a sort be 12267 performed on the result set elements according to the JIS X 4061 - 1996 “Collation of 12268 Japanese Character Strings” standard. 12269

D.4.1.2 Design Goals 12270

The JIS X 4061 Japanese sortOrder tModel is provided to enable inquiry results to be sorted 12271 according to the JIS X 4061 - 1996 “Collation of Japanese Character Strings” standard. 12272

D.4.1.3 tModel Definition 12273

This tModel is a find qualifier that is used to enable sorting of UDDI inquiry results, based on 12274 the JIS X 4061 - 1996 “Collation of Japanese Character Strings” standard, for Hiragana and 12275 Katakana characters. All other characters will be sorted according to the Default Unicode 12276 Collation Element Table. When this tModel is referenced in a find qualifier, a sort is performed 12277 on the field designated by the sortBy* find qualifier (name, by default), normalized using 12278 Unicode Normalization Form C. This qualifier conflicts with any other find qualifier of the 12279 sortOrder type, such as uddi.org:binarySort. 12280

Name: ubr-uddi-org:JIS-X4061 12281

Short name: JIS-X4061 12282

Description: UDDI JIS X 4061 Japanese collation sequence find qualifier 12283

UDDI Key (V3): uddi:ubr-uddi.org:sortorder:jis-x4061 12284

Categorization: sortOrder, findQualifier 12285

Support: Optional 12286

�� sortOrder qual ifier









�� sortOrder:JIS-X4061


355/405

12287

D.4.1.4 tModel Structure 12288


<tModel tModelKey=”uddi:uddi.org:sortorder:jis-x4061”> 12290 <name>uddi-org:JIS-X4061</name> 12291 <description>UDDI JIS X 4061 Japanese 12292 collation sequence find qualifier 12293 </description> 12294 <overviewDoc typeURI=”text”> 12295 <overviewURL> 12296 http://ubr.uddi.org/overviewDocs/UBR_CoreOther_tModels.doc#JIS-X4061Sort 12297 </overviewURL> 12298 </overviewDoc> 12299 <categoryBag> 12300 <keyedReference keyName=”uddi-org:types:categorization” 12301 keyValue="sortOrder" 12302 tModelKey="uddi:uddi.org:categorization:types”/> 12303 <keyedReference keyName=”uddi-org:types:categorization” 12304 keyValue="findQualifier" 12305 tModelKey="uddi:uddi.org:categorization:types”/> 12306 </categoryBag> 12307 </tModel> 12308 12309

D.4.1.5 Example of Use 12310

The following represents a typical inquiry that references the JIS X 4061 Japanese sortOrder 12311 find qualifier tModel. This example finds businesses or their contained businessServices or 12312 bindingTemplates that are categorized with any value using the ‘tempuri-org:CustomerType’ 12313 value set. The businessEntities so found are sorted first by name in ascending order, using 12314 the JIS X 4061 Japanese collation sequence, and for those that share a common name, by 12315 descending order of the date of the most recently updated entity. 12316

<find_business xmlns="urn:uddi-org:api_v3"> 12317 <findQualifiers> 12318 <findQualifier> 12319 uddi:uddi.org:sortorder:jis-4061 12320 </findQualifier> 12321 <findQualifier> 12322 uddi:uddi.org:findqualifier:sortbydatedesc 12323 </findQualifier> 12324 <findQualifier> 12325 uddi:uddi.org:findqualifier:sortbynameasc 12326 </findQualifier> 12327 <findQualifier> 12328 uddi:uddi.org:findqualifier:approximatematch 12329 </findQualifier> 12330 <findQualifier> 12331 uddi:uddi.org:findqualifier:combinecategorybags 12332 </findQualifier> 12333 </findQualifiers> 12334 <categoryBag> 12335 <keyedReference keyValue="%" 12336 keyName="tempuri-org:CustomerType" 12337 tModelKey="uddi:uddi.org:categorization:general_keywords"/> 12338 </categoryBag> 12339 </find_business> 12340

12341

12342

12343

�� sortOrder:JIS-X4061



�� sortOrder:JIS-X

�� findQualifier:sortByD

ateDesc


ameAsc


mateMatch

�� findQualifier:combine

CategoryBags


356/405

12344

E Appendix E: Using Identifiers 12345

One of the design goals associated with the UDDI registration data is the ability to mark 12346 information with identifiers. The purpose of identifiers in the UDDI registration data, namely for 12347 businessEntity and tModel instances, is to allow others to find the published information using 12348 more formal identifier systems. For example, businesses may want to use their D-U-N-S

�

12349 number58, Global Location Number (GLN)59, or tax identifier in their UDDI registration data, 12350 since these identifiers are shared in a public or private community in order to unambiguously 12351 identify businesses. In UDDI registries that are only used in private communities, businesses 12352 may also want to use privately known identifiers. For example, in a UDDI registry that is used 12353 as a service registry in a private exchange, supplier identifiers that are only known in this 12354 community might be used to identify the businesses. 12355

When looking at an identifier, such as a D-U-N-S�

number, it is not always immediately 12356 apparent what the identifier represents. For instance, consider the following identifier: 12357

12-345-6789 12358

Standing alone, it is not possible to figure out what this combination of digits and formatting 12359 characters implies. However, if it is known that this is a D-U-N-S

�

number, it is at least clear 12360 that this string identifies a business. Therefore, all appearances of identifiers in UDDI registries 12361 pair the identifier itself with its identifier system as in the following example. 12362

D-U-N-S�

Number, 12-345-6789 12363

E.1 Using identifiers 12364

Two of the main UDDI data structure types provide a structure to support attaching identifiers 12365 to data. These are the businessEntity and the tModel structures. By providing a placeholder 12366 for attaching identifiers to these data structures, any number of identifiers can be used for a 12367 variety of purposes. 12368

12369

12370

12371

Figure 5 - Using Identifiers 12372

58

D-U-N-S�

Numbers are provided by Dun & Bradstreet. See http://www.dnb.com.

59 The Global Location Number system is defined in the EAN UCC system (http://www.ean-int.org/locations.html).


357/405

In the example shown in Figure 5, the businessEntity with the name “My Company Inc.” 12373 specified three identifiers in its identifierBag. These identifiers can be used, for example, in a 12374 find_business call in order to locate the businessEntity in the UDDI registry. 12375

For instance, it is likely that someone who wants to find the types of technical Web services 12376 that are exposed by a given business would search using a business identifier. In the example 12377 shown in Figure 5 the individual who registered the businessEntity data specified a D-U-N-S

� 12378

number, a Global Location Number, and a US Tax Code identifier60. 12379

The following fragment of an XML document shows an example of how an identifier is added 12380 to a businessEntity in its identifierBag. 12381

<businessEntity businessKey=”uddi:my_company.example”> 12382 … 12383 <identifierBag> 12384 <keyedReference 12385 tModelKey=”uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s” 12386 keyName=”D-U-N-S:My Company” 12387 keyValue=”12-345-6789”/> 12388 … 12389 </identifierBag> 12390 … 12391 </businessEntity> 12392

12393 The businessEntity instance that is technically identified with the businessKey 12394 uddi:my_company.example contains an identifierBag with a D-U-N-S number61. This is 12395 established by the three attributes of the keyedReference: 12396

• tModelKey: uniquely identifies the tModel that represents the identifier system 12397

• keyName: human readable name of the identifier system, and when the identity is 12398 coded, a human readable rendition of the value 12399

• keyValue: the actual identifier within the specified identifier system 12400

If a registry follows the recommended policy for recognizing identifier systems, all identifier 12401 systems that are registered with a specific UDDI registry can be discovered with the 12402 find_tModel call as follows: 12403

<find_tModel> 12404 <categoryBag> 12405 <keyedReference 12406 tModelKey=”uddi:uddi.org:categorization:types” 12407 keyValue=”identifier”/> 12408 </categoryBag> 12409 </find_tModel> 12410

12411

60

In the diagram, the actual name/value properties were abbreviated for the sake of simplicity.

61 The identifier system examples in this section refer to actual tModelKeys that will be used to identify the corresponding tModels

in the UDDI Business Registry, Version 3.

�� ubr.

�� D-U-N-S


358/405

12412

12413

F Appendix F: Using Categorization 12414

Besides the ability to mark UDDI registration data with identifiers, another design goal is the 12415 ability to assign category information. Without categorization, locating data within a UDDI 12416 registry would prove to be very difficult. 12417

Especially for the discovery of previously unknown businesses, services, bindings or service 12418 types, it is indispensable that the corresponding UDDI registration data is marked with a set of 12419 categories that can universally be searched on. For example, the Universal Standard Products 12420 and Services Classification (UNSPSC)62, a set of categorization codes representing product 12421 and service categories, can be used to specify a business’ product and service offering in a 12422 more formalized way. 12423

F.1 Using simple categories 12424

All four main UDDI data structure types provide a structure to support attaching categories to 12425 data. These are the businessEntity, businessService, bindingTemplate and the tModel 12426 structures. By providing a placeholder for attaching categories to these data structures, any 12427 number of categories can be used for a variety of purposes. 12428

The following fragment of an XML document shows an example63 of how categories are 12429 added to a businessEntity using a categoryBag. 12430

<businessEntity businessKey=”uddi:my_company.example”> 12431 … 12432 <categoryBag> 12433 <keyedReference 12434 tModelKey=”uddi:uddi.org:ubr:categorization:unspsc” 12435 keyName=”UNSPSC:Medical Equipment and Accessories and Supplies” 12436 keyValue=”42.00.00.00.00”/> 12437 <keyedReference 12438 tModelKey=”uddi:uddi.org:ubr:categorization:unspsc” 12439 keyName=”UNSPSC:Drugs and Pharmaceutical Products” 12440 keyValue=”51.00.00.00.00”/> 12441 <keyedReference 12442 tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” 12443 keyName=”GEO:Germany” 12444 keyValue=”DE”/> 12445 <keyedReference 12446 tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” 12447 keyName=”GEO:France” 12448 keyValue=”FR”/> 12449 <keyedReference 12450 tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” 12451 keyName=”GEO:United States” 12452 keyValue=”US”/> 12453 </categoryBag> 12454 </businessEntity> 12455

12456

The businessEntity instance that is identified with the businessKey uddi:my_company.example 12457 contains a categoryBag with two UNSPSC product category codes and three ISO 316664 12458

62

See http://eccma.org/unspsc.

63 The category system examples in this section refer to actual tModelKeys that are used to identify the corresponding tModels in

the UDDI Business Registry, Version 3.

�� ubr.

�� ubr.

�� ubr.

�� geo3166-2

�� ubr.

�� geo3166-2

�� ubr.

�� geo3166-2


359/405

country codes. The business that is represented by this businessKey wants to specify that it 12459 sells medical equipment and pharmaceutical products in Germany, France and the United 12460 States. This is technically established by the three attributes of each of the keyedReferences: 12461

• tModelKey: uniquely identifies the tModel that represents the category system 12462

• keyName: human readable name of the category system, and when the actual 12463 category is coded, a human readable rendition of the value 12464

• keyValue: the actual category code within the specified category system 12465

In order to find all category systems that are registered with a specific UDDI registry that 12466 follows the recommended policy for recognizing category systems, the find_tModel call can be 12467 used as follows: 12468

<find_tModel> 12469 <categoryBag> 12470 <keyedReference 12471 tModelKey=”uddi:uddi.org:categorization:types” 12472 keyValue=”categorization”/> 12473 </categoryBag> 12474 </find_tModel> 12475

12476

In order to simply use keywords instead of full-fledged category systems, the UDDI general 12477 keywords taxonomy, as specified in Chapter 11, Utility tModels and Conventions, can be used. 12478

<businessEntity businessKey=”uddi:my_company.example”> 12479 … 12480 <categoryBag> 12481 <keyedReference 12482 tModelKey=”uddi:uddi.org:categorization:general_keywords” 12483 keyName=”example.org:ConsultingTypes:Web service consulting” 12484 keyValue=”Web services”/> 12485 <keyedReference 12486 tModelKey=”uddi:uddi.org:categorization:general_keywords” 12487 keyName=”example.org:ConsultingTypes:UDDI consulting” 12488 keyValue=”UDDI”/> 12489 </categoryBag> 12490 </businessEntity> 12491

12492

The businessEntity instance that is identified with the businessKey uddi:my_company.example 12493 contains a categoryBag with two keywords by using the UDDI general keywords 12494 categorization system. The business that is represented by this businessKey wants to specify 12495 that it offers Web service and UDDI consulting services by using the keywords “Web service” 12496 and “UDDI” as keyValue attributes within the keyedReference elements. 12497

64

See http://www.iso.org/iso/en/prods-services/iso3166ma/index.html.


360/405

12498

F.2 Grouping categories 12499

For many cases, the use of single categories is adequate for describing the characteristics of a 12500 business, a service, a binding, or a tModel so that it can easily be found. 12501

But there are some cases where the relationship between single categories becomes 12502 important. Taking the example from the section above, the business might want to specify that 12503 it actually sells medical equipment only in Germany and France and pharmaceutical products 12504 only in the United States. 12505

For this and similar purposes, categoryBags can contain keyedReferenceGroups that in turn 12506 contain a list of keyedReferences. Since the set of keyedReferences that are grouped within a 12507 keyedReferenceGroup do not themselves provide any meaning why they are grouped 12508 together, the keyedReferenceGroup carries its own tModelKey identifying a tModel that in turn 12509 provides this meaning. 12510

The following XML fragment shows how keyedReferenceGroups are used in order to achieve 12511 the desired behavior. 12512

<businessEntity businessKey=”uddi:my_company.example”> 12513 … 12514 <categoryBag> 12515 <keyedReferenceGroup 12516 tModelKey= 12517 ”uddi:uddi.org:ubr:categorizationgroup:unspsc_geo3166”> 12518 <keyedReference 12519 tModelKey=”uddi:uddi.org:ubr:categorization:unspsc” 12520 keyName=”UNSPSC:Medical Equipment and Accessories and Supplies” 12521 keyValue=”42.00.00.00.00”/> 12522 <keyedReference 12523 tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” 12524 keyName=”GEO:Germany” 12525 keyValue=”DE”/> 12526 </keyedReferenceGroup> 12527 <keyedReferenceGroup 12528 tModelKey= 12529 ”uddi:uddi.org:ubr:categorizationgroup:unspsc_geo3166”> 12530 <keyedReference 12531 tModelKey=”uddi:uddi.org:ubr:categorization:unspsc” 12532 keyName=”UNSPSC:Medical Equipment and Accessories and Supplies” 12533 keyValue=”42.00.00.00.00”/> 12534 <keyedReference 12535 tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” 12536 keyName=”GEO:France” 12537 keyValue=”FR”/> 12538 </keyedReferenceGroup> 12539 <keyedReferenceGroup 12540 tModelKey= 12541 ”uddi:uddi.org:ubr:categorization:unspsc_geo3166”> 12542 <keyedReference 12543 tModelKey=”uddi:uddi.org:ubr:categorization:unspsc” 12544 keyName=”UNSPSC:Drugs and Pharmaceutical Products” 12545 keyValue=”51.00.00.00.00”/> 12546 <keyedReference 12547 tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” 12548 keyName=”GEO:United States” 12549 keyValue=”US”/> 12550 </keyedReferenceGroup> 12551 … 12552 </categoryBag> 12553 </businessEntity> 12554

12555

The tModel that is used in this example, keyed as 12556 “uddi:uddi.org:ubr:categorizationgroup:unspsc_geo3166”, represents the grouping of the 12557

�� ubr.

�� categorizationGroup

�� ubr.

�� ubr.

�� geo3166-2

�� ubr.


�� ubr.

�� ubr.

�� geo3166-2

�� ubr.

�� ubr.

�� ubr.

�� geo3166-2

�� ubr.



361/405

category systems for UNSPSC and ISO 3166. As a consequence, keyedReferenceGroups 12558 that reference this tModel describe countries or regions where a product category is offered. 12559

Another use case that shows the importance of grouping categories is the idea of using 12560 geographical coordinates in order to specify where a specific business or service is physically 12561 located. The following example details how geographical latitudes and longitudes are grouped 12562 together in a keyedReferenceGroup. The geographic reference system used in this example is 12563 the World Geodetic System 1984 (WGS 84). 12564

<businessEntity businessKey=”uddi:my_company.example”> 12565 <categoryBag> 12566 <keyedReferenceGroup 12567 tModelKey=”uddi:uddi.org:ubr:categorizationGroup:wgs84”> 12568 <keyedReference 12569 tModelKey= 12570 ”uddi:uddi.org:ubr:categorization:wgs84:latitude” 12571 keyName=”WGS 84 Latitude” 12572 keyValue=”+49.682700”/> 12573 <keyedReference 12574 tModelKey= 12575 ”uddi:uddi.org:ubr:categorization:wgs84:longitude” 12576 keyName=”WGS 84 Longitude” 12577 keyValue=”+008.295200”/> 12578 <keyedReference 12579 tModelKey= 12580 ”uddi:uddi.org:ubr:categorization:geo_precision” 12581 keyName=”Center of Street” 12582 keyValue=”0900”/> 12583 </keyedReferenceGroup> 12584 </categoryBag> 12585 </businessEntity> 12586

12587

The businessEntity instance that is identified with the businessKey uddi:my_company.example 12588 contains a categoryBag with one keyedReferenceGroup that in turn contains a latitude, a 12589 longitude, and a precision information grouped using the WGS 84 system. The business that is 12590 represented by this businessKey wants to specify that it is physically located at the 12591 latitude/longitude pair 49.6827/8.2952 and that this positioning information was derived for the 12592 center of the street the business is being located in. 12593

In order to find all category group systems that are registered within a UDDI registry that 12594 follows the recommended policy for recognizing category group systems, the find_tModel call 12595 can be used as follows: 12596

<find_tModel> 12597 <categoryBag> 12598 <keyedReference 12599 tModelKey=”uddi:uddi.org:categorization:types” 12600 keyValue=”categorizationGroup”/> 12601 </categoryBag> 12602 </find_tModel> 12603

12604

In order to use category group systems that are not yet registered with a specific UDDI 12605 registry, the publisher of the category group system can register this as a new tModel. 12606

�� ubr.

�� ubr.

�� ubr.

�� ubr.


362/405

12607

F.3 Deriving categories 12608

In order to use value sets, such as geographic taxonomies, for different purposes, value sets 12609 can be derived from the tModels for some other value sets to reuse the sets of values. Each of 12610 these derived value sets represents a specific meaning that is described in its name and 12611 overviewDoc. The following example shows how a business is categorized with the same sets 12612 of values, but for different purposes. The first keyedReference shows the categorization for the 12613 physical location of the business. The second shows the categorization for the service area, 12614 the default meaning of the geo3166-2 value set. 12615

<businessEntity businessKey="uddi:my_company.example"> 12616 … 12617 <categoryBag> 12618 <keyedReference 12619 tModelKey= 12620 "uddi:uddi.org:ubr:categorization:iso3166:location" 12621 keyName="GEOLocation:California" 12622 keyValue="US-CA"/> 12623 <keyedReference 12624 tModelKey="uddi:uddi.org:ubr:categorization:iso3166" 12625 keyName="GEO:United States" 12626 keyValue="US"/> 12627 </categoryBag> 12628 </businessEntity> 12629

12630

In order to find all category systems that are derived from a base category system, taking the 12631 ISO 3166 category system as an example, and registered with a UDDI registry that follows the 12632 recommended policy for identifying derived value sets, the find_tModel call can be used as 12633 follows: 12634

<find_tModel> 12635 <categoryBag> 12636 <keyedReference 12637 tModelKey=”uddi:uddi.org:categorization:derivedfrom” 12638 keyValue=”uddi:uddi.org:ubr:categorization:iso3166”/> 12639 </categoryBag> 12640 </find_tModel> 12641

12642

Note that the result list for an inquiry using the derivedFrom category system consists of all 12643 category systems that are derived from the value set specified in the keyValue. In order to find 12644 all derived category systems, regardless of their base category system, in a registry that 12645 follows to the recommended policy for identifying derived value sets, the following find_tModel 12646 call can be used: 12647

<find_tModel> 12648 <findQualifiers> 12649 <findQualifier> 12650 uddi:uddi.org:findqualifier:approximatematch 12651 </findQualifier> 12652 </findQualifiers> 12653 <categoryBag> 12654 <keyedReference 12655 tModelKey=”uddi:uddi.org:categorization:derivedfrom” 12656 keyValue=”%”/> 12657 </categoryBag> 12658 </find_tModel> 12659

12660

�� ubr.

�� geo3166-2

�� ubr.

�� geo3166-2

�� derivedFrom

�� ubr.

�� geo3166-2


mateMatch

�� derivedFrom


363/405

12661

The root category systems are themselves categorized with the valueSet uddi type. To find all 12662 of the root value sets in a registry that follows the recommended policy for identifying root 12663 value sets, the following find_tModel call can be used: 12664

<find_tModel> 12665 <categoryBag> 12666 <keyedReference 12667 tModelKey=”uddi:uddi.org:categorization:types” 12668 keyValue=”valueSet”/> 12669 </categoryBag> 12670 </find_tModel> 12671

12672


364/405

12673

G Appendix G: Wildcards 12674

This appendix provides examples of how to use wildcards in various search operations using 12675 the find_xx APIs, as described in Section 5.1.6 About Wildcards. 12676

G.1 Find using “starts with” searching 12677

To find all businesses whose name begins with “ABC” – e.g., “ABC Vacuum”, the following 12678 find_business can be used: 12679

<?xml version = "1.0" encoding = "UTF-8"?> 12680 <find_business xmlns = "urn:uddi-org:api_v3" 12681 xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"> 12682 <findQualifiers> 12683 <findQualifier> 12684 uddi:uddi.org:findqualifier:approximatematch 12685 </findQualifier> 12686 </findQualifiers> 12687 <name>ABC%</name> 12688 </find_business> 12689

12690

G.2 Find using “starts and ends with” searching 12691

To find all the businesses whose name begins with “Texas” and ends with “Cafe” the following 12692 find_business can be used: 12693

<?xml version = "1.0" encoding = "UTF-8"?> 12694 <find_business xmlns = "urn:uddi-org:api_v3" 12695 xmlns:xsi = “http://www.w3.org/2001/XMLSchema-instance”> 12696 <findQualifiers> 12697 <findQualifier> 12698 uddi:uddi.org:findqualifier:approximatematch 12699 </findQualifier> 12700 </findQualifiers> 12701 <name>Texas%Cafe</name> 12702 </find_business> 12703

12704

G.3 Find using escaped literals 12705

To find all the businesses whose name contains a literal “_” the following find_business can be 12706 used: 12707

<?xml version = "1.0" encoding = "UTF-8"?> 12708 <find_business xmlns = "urn:uddi-org:api_v3" 12709 xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"> 12710 <findQualifiers> 12711 <findQualifier> 12712 uddi:uddi.org:findqualifier:approximatematch 12713 </findQualifier> 12714 </findQualifiers> 12715 <name>%\_%</name> 12716 </find_business> 12717


mateMatch


mateMatch


mateMatch


365/405

12718

G.4 Find using wildcards with Taxonomies 12719

To find all businesses classified using the D-U-N-S number system the following find_business 12720 can be used: 12721

<?xml version = "1.0" encoding = "UTF-8"?> 12722 <find_business xmlns = "urn:uddi-org:api_v3" 12723 xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"> 12724 <findQualifiers> 12725 <findQualifier> 12726 uddi:uddi.org:findqualifier:approximatematch 12727 </findQualifier> 12728 </findQualifiers> 12729 <identifierBag> 12730 <keyedReference 12731 keyValue = "%" 12732 tModelKey = "uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s"/> 12733 </identifierBag> 12734 </find_business> 12735

12736

To find all businesses classified in any of the UNSPSC categories in the UNSPSC family 12737 “Telephones and personal telecommunications devices and accessories” the following 12738 find_business can be used: 12739

<?xml version = "1.0" encoding = "UTF-8"?> 12740 <find_business xmlns = "urn:uddi-org:api_v3" 12741 xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"> 12742 <findQualifiers> 12743 <findQualifier> 12744 uddi:uddi.org:findqualifier:approximatematch 12745 </findQualifier> 12746 </findQualifiers> 12747 <categoryBag> 12748 <keyedReference 12749 keyValue = "34.10.__.__.00" 12750 tModelKey = "uddi:uddi.org:ubr:categorization:unspsc"/> 12751 </categoryBag> 12752 </find_business> 12753

12754


mateMatch

�� ubr.

�� D-U-N-S


mateMatch

�� ubr.


366/405

12755

H Appendix H: Extensibility 12756

UDDI supports extension through a derivation mechanism provided by XML Schema to enable 12757 access to additional functionality using extended UDDI API and data structures. Using XML 12758 schema derivation to extend UDDI retains compatibility with the core UDDI specification. XML 12759 Schema restrictions are explicitly prohibited to prevent the UDDI core functionalities from being 12760 arbitrarily limited. 12761

Other than allowing extensibility in the XML schema, the UDDI schema extension mechanism 12762 does not affect any other parts of the specification. There are, however, some implied 12763 behaviors worth pointing out: 12764

• If a client sends a request with extension to a UDDI registry that does not support the 12765 extension, the registry MUST return an error. The registry MAY indicate the 12766 namespace of the extension that is not supported in the error text. 12767

• If a UDDI data structure is extended using XML schema extensions in a multi-node 12768 registry, the extended elements MUST be replicated by all nodes. This is implied by 12769 the definition of a registry that requires all nodes to host the same data, subject to 12770 replication latency. See Section 1.5 Base UDDI Architecture for details. 12771

Before introducing an extension, the designer of an extension SHOULD consider the impact of 12772 the extension. The designer SHOULD document the impact so that administrators and users 12773 of the registry can be fully aware of the impact in deciding whether to adopt an extension or 12774 not. 12775

H.1 Using the basic UDDI infrastructure 12776

UDDI provides many levels and dimensions of flexibility such as arbitrary categorization 12777 schemes, open-ended discoveryURLs, etc. Many requirements can be satisfied by some 12778 application of the specification without introducing any extension. UDDI technical notes and 12779 best practices are good sources of information about such applications of the UDDI 12780 specification. 12781

H.2 Establishing an extension 12782

H.2.1 Extension designer 12783

Extensions to UDDI can be accomplished by extending UDDI data structures (see Chapter 3 12784 UDDI Data Structures) and/or extending the UDDI API (See Chapter 5 UDDI Programmers 12785 APIs). Each schema extension is given its own namespace. Furthermore, the XML schema 12786 xsi:type substitutionGroup SHOULD be used to represent the extension elements. 12787

The designer of a UDDI extension SHOULD also register one or more tModel(s) to represent 12788 the extension. Each tModel SHOULD indicate that it is an extension of one or more UDDI 12789 native API set(s) by containing a categorization entry indicating the 12790 uddi:uddi.org:categorization:derivedfrom categorization tModel, with the keyValue being the 12791 tModelKey of a UDDI native API tModel. The categorization allows clients to discover 12792 extensions of a UDDI native API. 12793

�� derivedFrom


367/405

12794

For example, an extension that extends the UDDI v3 inquiry API is represented by the 12795 following keyedReference entry in a categoryBag 12796

<keyedReference 12797 keyName="uddi-org:derivedFrom:v3_inquiry" 12798 keyValue="uddi:uddi.org:v3_inquiry" 12799 tModelKey="uddi:uddi.org:categorization:derivedfrom"/> 12800 12801 12802

H.2.2 Registries that support the extension 12803

Conceptually speaking, a UDDI registry is a Web service. A Web service that supports the 12804 UDDI v3 specification and a Web service that supports UDDI v3 specification with the 12805 extension are two distinct Web services. Hence, a UDDI registry that implements the extension 12806 SHOULD provide two sets of service end points: one set that supports the UDDI v3 12807 specification and one set that supports the UDDI v3 specification with the extension. 12808

To allow clients to establish the functional differences between the two sets of service end 12809 points, the registry SHOULD indicate the differences in the service end point 12810 bindingTemplates. The additional service end point(s) that support the extension SHOULD 12811 reference tModels for the extension. 12812

H.2.2.1 Special considerations in data structure extension 12813

In the case of data structure extension, if the registry chooses to support one set of service end 12814 point(s) instead of two sets, there will be some undesirable consequences. Specifically, if the 12815 registry receives a get_xx request, the registry cannot distinguish whether the client is 12816 prepared to handle the extension or not, because in a data structure extension, the get_xx API 12817 is not extended. With two sets of service end points, the registry can identify whether the client 12818 is prepared to handle the extension based upon the end point which the client uses. 12819

As an alternative, an extension designer can also choose to extend the correspond save_xx 12820 and get_xx API set so that one set of service end point(s) is sufficient to cover both the native 12821 API and the extension. 12822

H.3 Programmers API and UDDI Clients 12823

There are two types of UDDI Clients: UDDI clients that are not prepared to handle the 12824 extension and UDDI clients that are prepared to handle the extension. 12825

H.3.1 UDDI Clients not prepared to handle the extension 12826

A UDDI registry that supports an extension must handle native UDDI clients that have no 12827 knowledge of or interest in the extension. Clients of this type will refer to the UDDI 12828 namespaces contained in Chapter 2 UDDI Schemas in their API calls. The registry must 12829 respond to such client requests by following the specification for the native UDDI namespace, 12830 performing the behavior prescribed in this specification. 12831

If a client follows a save of an extended entity with a subsequent save of the entity without its 12832 extension, extension documentation determines whether to remove the extension information 12833 or leave it untouched. 12834

�� derivedFrom


368/405

12835

H.3.2 UDDI Clients prepared to handle the extension 12836

A UDDI registry that receives a message referring to a namespace for an extension that it 12837 supports should respond with the appropriate extended response structure, if one exists. If the 12838 API itself is extended, the registry should process the message according to the extended 12839 behavior. 12840

H.4 Error Codes 12841

A UDDI extension may introduce additional error conditions. Whenever possible, extensions 12842 SHOULD reuse existing error codes to minimize the impact on client interoperability. See 12843 Chapter 12 Error Codes for more information. 12844

H.5 Digital signatures 12845

Digital signatures are used to provide integrity and authenticity of the data managed in a UDDI 12846 registry. All of the UDDI core entities support adding XML digital signatures. 12847

If an entity extension can be signed, either by carrying its own signature element or by being 12848 covered by the signature of the extended entity, the designer of the extension SHOULD 12849 provide guidance. Signing an extension provides a guarantee of integrity on the data, but it 12850 may introduce difficulties with interoperability between registries in entity promotion scenarios. 12851

It is worth pointing out that a publisher can also choose to provide two signatures, one for the 12852 entity without the extension and one for the entity with the extension. In this case, however, a 12853 publisher then needs additional transforms to exclude all the signature elements from the entity 12854 being signed. A digital signature standard transform can only exclude the enveloped signature 12855 itself, but not its peers. 12856

If the extension affects save_xx API calls, the extension SHOULD NOT alter the entity that a 12857 client sends because altering an entity can create unnecessary difficulties for a client who 12858 digitally signs the entity. 12859

In the case where the extension MAY alter the entity in a save_xx API call, the extension 12860 designer SHOULD document this behavior. 12861

H.6 Entity promotion 12862

If the extension extends UDDI data structures, there can be some complications when an 12863 entity is promoted from one UDDI registry to another UDDI registry, if the two registries do not 12864 support the same set of extensions. The owners of the two registries should agree on the 12865 extensions that will be promoted through some out-of-band communication. Additional tools 12866 may be required to transform or filter out some extensions. 12867

Any transformation or filtering of the entity may invalidate the digital signatures it contains. 12868 Hence, any UDDI data structure extensions should be introduced with great caution. 12869

H.7 Replication 12870

In a multi-node UDDI registry where all nodes support the same data structure extension, 12871 there are no replication issues. Taking advantage of a property of XML schema derivation, 12872 regular change records can contain the extended data structure under the extension 12873 namespace. The other nodes in the registry, upon receiving such change records, will be able 12874 to recognize the data structure extension and save it correctly. 12875

Using a data structure extension may limit the ability to add a new UDDI node from a different 12876 vendor, however, since the extension may not be supported by that vendor. 12877

H.8 Example 12878


369/405

The following example illustrates the above considerations and provides a template for 12879 documenting an extension. We will assume that the document is located at 12880 http://tempuri.org/uddi_extension/specification.html. This URL is needed in the extension 12881 tModel. 12882

H.8.1 Description 12883

A discoveryURLs element is added to the UDDI publisherAssertion structure. This extension 12884 enables a business relationship to reference additional supporting documentation, such as a 12885 business agreement between the two parties. Additional documentation of a business 12886 relationship is particularly useful in a community / marketplace usage scenario. 12887

H.8.2 Data structure (XML schema) 12888

A new schema is created to extend the UDDI Version 3 API schema. In this example, the 12889 normative schema document is located at 12890 http://tempuri.org/schema/uddi_v3PublisherAssertionExt.xsd. 12891

Note the targetNamespace and the egExt namespace definition. This schema imports the 12892 UDDI Version 3 API schema, which allows extension through schema derivation. 12893

A new type named publisherAssertionExt is defined to extend the publisherAssertion element 12894 in the UDDI Version 3 API schema. The extension is indicated by the xsd:extension element. 12895 An optional discoveryURLs element is added to the publisherAssertion element. When a 12896 registry that supports this schema extension receives a publisherAssertion structure that 12897 references this extended namespace, that does not include the optional discoveryURLs 12898 element, it MUST behave just as it does without the extension. 12899

<xsd:schema 12900 targetNamespace="http://tempuri.org/uddi_extension" 12901 xmlns:egExt="http://tempuri.org/uddi_extension" 12902 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 12903 xmlns:uddi="urn:uddi-org:api_v3" 12904 elementFormDefault="qualified" 12905 attributeFormDefault="unqualified"> 12906 <xsd:import namespace="urn:uddi-org:api_v3" 12907 schemaLocation="http://uddi.org/schema/uddi_v3.xsd" /> 12908 <xsd:element name="publisherAssertionExt" 12909 type="egExt:publisherAssertionExt" 12910 substitutionGroup="uddi:publisherAssertion"/> 12911 <xsd:complexType name="publisherAssertionExt"> 12912 <xsd:annotation> 12913 <xsd:documentation>A complex type which is an extension of the 12914 publisherAssertion complex type in UDDI. 12915 </xsd:documentation> 12916 </xsd:annotation> 12917 <xsd:complexContent> 12918 <xsd:extension base="uddi:publisherAssertion"> 12919 <xsd:sequence> 12920 <xsd:element ref="uddi:discoveryURLs" 12921 minOccurs = "0"/> 12922 </xsd:sequence> 12923 </xsd:extension> 12924 </xsd:complexContent> 12925 </xsd:complexType> 12926 </xsd:schema> 12927

12928

H.8.3 tModel of the extension 12929

The extension designer then publishes two tModels to identify Web services that comply with 12930 the UDDI extension, one for the extended inquiry API and one for the extended publication 12931 API. The uddi:uddi.org:categorization:derivedfrom category is used to represent the 12932 derivation. 12933

12934

�� derivedFrom


370/405

tModel name: tempuri-org:v3_inquiry:publisherAssertionExt 12935

tModel Description: An extended UDDIv3 inquiry API, with an extension of UDDI 12936 publisherAssertions to allow discoveryURLs in a publisherAssertion. 12937

tModel key: uddi:tempuri.org:v3_inquiry:publisherassertionext 12938

Categorization: specification, xmlSpec, soapSpec 12939

Derived from (tModelKeys): uddi:uddi.org:v3_inquiry 12940

This tModel is an extension to the UDDI Version 3 inquiry API (defined by tModel uddi-12941 org:inquiry_v3), enabling discoveryURLs to be included in a publisherAssertion. For more 12942 information, see http://tempuri.org/uddi_extension/specification.html. 12943

�� publisherAssertionExt


371/405

12944


<tModel tModelKey=”uddi:tempuri.org:v3_inquiry:publisherassertionext”> 12946 <name>tempuri-org:v3_inquiry:publisherAssertionExt</name> 12947 <description> 12948 Extension of UDDI publisherAssertion to allow 12949 discoveryURLs in a keyedReference. 12950 </description> 12951 <overviewDoc> 12952 <overviewURL useType="text"> 12953 http://tempuri.org/uddi_extension/specification.html 12954 </overviewURL> 12955 </overviewDoc> 12956 <categoryBag> 12957 <keyedReference keyName=”uddi-org:types:soapSpec” 12958 keyValue="soapSpec" 12959 tModelKey="uddi:uddi.org:categorization:types”/> 12960 <keyedReference keyName=”uddi-org:types:xmlSpec” 12961 keyValue="xmlSpec" 12962 tModelKey="uddi:uddi.org:categorization:types”/> 12963 <keyedReference keyName=”uddi-org:types:specification” 12964 keyValue="specification" 12965 tModelKey="uddi:uddi.org:categorization:types”/> 12966 <keyedReference 12967 keyName="uddi-org:derivedFrom:v3_inquiry" 12968 keyValue="uddi:uddi.org:v3_inquiry" 12969 tModelKey="uddi:uddi.org:categorization:derivedfrom"/> 12970 </categoryBag> 12971 </tModel> 12972

12973

tModel name: tempuri-org:v3_publication:publisherAssertionExt 12974

tModel Description: An extended UDDIv3 publication API, with an extension of UDDI 12975 publisherAssertions to allow discoveryURLs in a publisherAssertion. 12976

tModel key: uddi:tempuri.org:v3_publication:publisherassertionext 12977

Categorization: specification, xmlSpec, soapSpec 12978

Derived from (tModelKeys): uddi:uddi.org:v3_publication 12979

This tModel is an extension to the UDDI Version 3 publication API (defined by uddi-12980 org:publication_v3), enabling discoveryURLs to be included in a publisherAssertion. For more 12981 information, see http://tempuri.org/uddi_extension/specification.html. 12982


�� derivedFrom



372/405

12983


<tModel tModelKey=”uddi:tempuri.org:v3_publication:publisherassertionext”> 12985 <name>tempuri-org:v3_publication:publisherAssertionExt</name> 12986 <description> 12987 Extension of UDDI publisherAssertion to allow 12988 discoveryURLs in a keyedReference. 12989 </description> 12990 <overviewDoc> 12991 <overviewURL useType="text"> 12992 http://tempuri.org/uddi_extension/specification.html 12993 </overviewURL> 12994 </overviewDoc> 12995 <categoryBag> 12996 <keyedReference keyName=”uddi-org:types:soapSpec” 12997 keyValue="soapSpec" 12998 tModelKey="uddi:uddi.org:categorization:types”/> 12999 <keyedReference keyName=”uddi-org:types:xmlSpec” 13000 keyValue="xmlSpec" 13001 tModelKey="uddi:uddi.org:categorization:types”/> 13002 <keyedReference keyName=”uddi-org:types:specification” 13003 keyValue="specification" 13004 tModelKey="uddi:uddi.org:categorization:types”/> 13005 <keyedReference 13006 keyName="uddi-org:derivedFrom:v3_publication" 13007 keyValue="uddi:uddi.org:v3_publication" 13008 tModelKey="uddi:uddi.org:categorization:derivedfrom"/> 13009 </categoryBag> 13010 </tModel> 13011 13012

H.8.4 Additional service end points 13013

A registry SHOULD provide a pair of inquiry and publication service end points in 13014 bindingTemplate elements that support the base UDDI v3 specification, along with an 13015 additional pair of inquiry and publication service end points in bindingTemplate elements which 13016 support the extension. 13017

H.8.5 Programmers API Description of the extension 13018

A publisherAssertion can contain discoveryURLs. 13019

For add_publisherAssertions, and set_publisherAssertions, the argument publisherAssertion is 13020 modified as follows: 13021

• publisherAssertion: one or more relationship assertions. Relationship assertions 13022 consist of a reference to two businessEntity key values as designated by the fromKey 13023 and toKey elements, as well as a required statement of the directional relationship 13024 within the contained keyedReference element. See Appendix A Relationships and 13025 Publisher Assertions for more information. The fromKey, the toKey, and all three parts 13026 of the keyedReference – the tModelKey, the keyName, and the keyValue – must be 13027 specified. Empty (zero length) keyNames and keyValues are permitted. Furthermore, 13028 when using publisherAssertionExt elements of type publisherAssertionExt in the 13029 egExt namespace, discoveryURLs can be optionally provided. 13030

For get_publisherAssertions and get_assertionStatusReport, if a request is made to the 13031 publication endpoint that supports the extension, the response message can contain a 13032 publisherAssertion of the type egExt:publisherAssertionExt. If a request is made to the 13033 publication endpoint that does not support extension, the response message must contain 13034 publisherAssertion of the native UDDI v3 type. 13035

For find_relatedBusinesses, there is no change in the request message. The syntax and the 13036 matching rules for the keyedReference remain the same. The response message can contain 13037 a publisherAssertion of the type egExt:publisherAssertionExt when the namespace used on 13038 the API is egExt. 13039


�� derivedFrom

373/405

For normal get_publisherAssertions, get_assertionStatusReport, and find_relatedBusinesses 13040 APIs, a request sent to a native UDDI API service end point MUST return publisherAssertion 13041 elements without the extension. A request sent to an extended service end point MUST return 13042 extended publisherAssertion elements, if available. 13043

H.8.6 Digital signature 13044

publisherAssertion elements may be signed. Depending on the usage scenario, a publisher 13045 may include or exclude the extension element in signing. A publisher may also provide two 13046 signatures, one that includes the extension and one that excludes the extension. 13047

If a publisher chooses to exclude the extension element in signing, the following XSLT 13048 transform can be used: 13049

<dsig:Transform xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 13050 Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116"> 13051 <xsl:stylesheet 13052 xmlns:xsl="http://www.w3.org/TR/1999/REC-xslt-19991116" 13053 xmlns:egExt="http://tempuri.org/uddi_extension" 13054 xmlns:uddi="urn:uddi-org:api_v3" 13055 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 13056 <xsl:output mode="xml" /> 13057  13059 <xsl:template match="egExt:publisherAssertionExt" 13060 priority="1"> 13061 <uddi:publisherAssertion> 13062 <xsl:apply-templates select="uddi:fromKey" /> 13063 <xsl:apply-templates select="uddi:toKey" /> 13064 <xsl:apply-templates select="uddi:keyedReference" /> 13065 </uddi:publisherAssertion> 13066 </xsl:template> 13067 13068  13069 <xsl:template match="@*|node()" priority="0"> 13070 <xsl:copy> 13071 <xsl:apply-templates select="@*|node()"/> 13072 </xsl:copy> 13073 </xsl:template> 13074 13075 </xsl:stylesheet> 13076 </dsig:Transform> 13077

13078

H.8.7 Registry operation: replication 13079

All nodes must support the extension to the extent that the all nodes must replicate the 13080 extended publisherAssertion elements of the type egExt:publisherAssertionExt. 13081

H.8.8 Registry operation: entity promotion 13082

The policy decision makers for the two registries should agree on whether the extension will be 13083 promoted through some out-of-band communication. 13084

If the target registry supports the extension and the extension is promoted, then there is no 13085 issue. 13086

If the target registry does not support the extension, the extension MAY by filtered out by 13087 removing the discoveryURLs element and redefining the publisherAssertionExt element to be 13088 of the UDDI native publisherAssertion type. 13089


374/405

13090

Such filtering, however, may impact digital signatures. There are two scenarios: 13091

• If a publisher signs a publisherAssertion with a transform that excludes the extension, 13092 there is no issue. The manifest used to generate the digital signature does not consist 13093 of the extension. Hence, the digital signature of the publisherAssertion in the target 13094 registry remains valid. 13095

• If a publisher signs a publisherAssertion without any additional transforms, the digital 13096 signature of the publisherAssertion in the target registry will be invalid since the digital 13097 signature covers the extension. 13098

13099

H.8.9 Non-normative example 13100

This example demonstrates the addition of a publisherAssertion with a pointer to the contract 13101 between the two entities contained in the extended publisherAssertion element. The 13102 publisherAssertionExt element is defined to be of the type egExt:publisherAssertionExt (as 13103 opposed to the UDDI native publisherAssertion type uddi:publisherAssertion). 13104

<uddi:add_publisherAssertions 13105 xmlns:egExt="http://tempuri.org/uddi_extension" 13106 xmlns:uddi="urn:uddi-org:api_v3" 13107 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 13108 <uddi:authInfo>someAuthInfo</uddi:authInfo> 13109 <egExt:publisherAssertionExt> 13110 <uddi:fromKey>some business key</uddi:fromKey> 13111 <uddi:toKey>some other business key</uddi:toKey> 13112 <uddi:keyedReference 13113 tModelKey="uddi:uddi.org:relationships" 13114 keyName="some peer to peer relationship" 13115 keyValue="peer-peer" /> 13116 <uddi:discoveryURLs> 13117 <uddi:discoveryURL useType="contract"> 13118 http://www.example.com/contract/p2pcontract.pdf 13119 </uddi:discoveryURL> 13120 </uddi:discoveryURLs> 13121 </egExt:publisherAssertionExt> 13122 </uddi:add_publisherAssertions> 13123

13124

Now we perform an inquiry to obtain all of the publisherAssertions owned by the publisher, 13125 including the extension. In order to obtain the extension, a client must send the request to the 13126 publication service end point that supports the extension. 13127

<get_publisherAssertions 13128 xmlns="urn:uddi-org:api_v3"> 13129 <authInfo>the-authinfo-token</authInfo> 13130 </get_publisherAssertions> 13131

13132

Next we perform an inquiry for all of the publisherAssertions owned by the publisher, without 13133 the extension. A client must send the request to the publication service end point that supports 13134 only the native UDDI publication API set. 13135

<get_publisherAssertions 13136 xmlns="urn:uddi-org:api_v3"> 13137 <authInfo>the-authinfo-token</authInfo> 13138 </get_publisherAssertions 13139

13140

375/405

13141

In entity promotion, if the target registry filters out the extension, the extended 13142 publisherAssertion will be transformed to the UDDI native publisherAssertion. The 13143 discoveryURLs element is removed. 13144

<uddi:add_publisherAssertions 13145 xmlns:uddi="urn:uddi-org:api_v3"> 13146 <uddi:authInfo>someAuthInfo</uddi:authInfo> 13147  13149 <uddi:publisherAssertion> 13150 <uddi:fromKey>some business key</uddi:fromKey> 13151 <uddi:toKey>some other business key</uddi:toKey> 13152 <uddi:keyedReference 13153 tModelKey="uddi:uddi.org:relationships" 13154 keyName="some peer to peer relationship" 13155 keyValue="peer-peer" /> 13156  13157 </uddi:publisherAssertion> 13158 </uddi:add_publisherAssertions> 13159

13160


376/405

13161

I Appendix I: Support For XML Digital Signatures 13162

The UDDI v3 schema supports signing of the following UDDI elements using XML-Signature 13163 Syntax and Processing (see http://www.w3.org/TR/xmldsig-core/). 13164

• businessEntity 13165

• businessService 13166

• bindingTemplate 13167

• tModel 13168

• publisherAssertion 13169

This Appendix describes the process for signing the UDDI elements listed above using XML 13170 Digital Signature and the process for verifying signatures associated with these elements. 13171

13172

I.1 Generation of a Signature 13173

A Signature element SHOULD be generated according to the required steps of “Core 13174 Generation” in XML-Signature Syntax and Processing. 13175

The signature should be calculated on the top level element that will be stored by the registry 13176 as a result of the Publication API call. This element, referred to as the data object in the XML-13177 Signature and Syntax specification, is the businessEntity element for save_business API calls, 13178 the businessService element for save_service API calls, the bindingTemplate for save_binding 13179 API calls, the tModel for save_tModel API calls and the publisherAssertion for 13180 set_publisherAssertions and add_publisherAssertions API calls. The signature should be 13181 generated on the elements before they are added to the body of an API call. Also, according 13182 to the signature generation, all children of the element being signed are included in the 13183 generation of the signature unless first excluded by application of a transform. For 13184 businessService elements, any bindingTemplate elements must be included in the signature 13185 generation unless first excluded by applying a transform. Similarly, for businessEntity 13186 elements, businessService elements must be included in the signature generation unless first 13187 excluded by applying a transform. Due to the containment of service projections as 13188 businessService elements within a businessEntity element, this also means that changes to 13189 the projected service will render a signature of the businessEntity containing the projection 13190 invalid, unless a businessService element representing a service projection is excluded using 13191 a transform. 13192

Because attributes are also included in generation of a signature on an element, unless 13193 excluded by applying a transform, node generated entity keys result in the addition of content 13194 in attribute values. Publication API calls that include data where the keys are not assigned by 13195 the publisher will not be able to generate a signature that will remain valid, unless the node 13196 assigned key attributes are excluded using a transform. It is RECOMMENDED that publishers 13197 generate a signature on elements containing publisher assigned keys. In the event that 13198 publisher assigned keys cannot be used due to the registry or node policy on key generation, it 13199 is RECOMMENDED that publishers generate a signature on elements after all keys in the 13200 element and its contained elements have been generated by the node. The generation of a 13201 signature where node generated keys are included in the signature is, then, only possible on 13202 updates of the data where no new keys are to be generated by the node. 13203

Due to the location of the sequence of Signature elements within an element that is to be 13204 signed, the signature is “enveloped”. As a result of the enveloping of the signature, it is 13205 necessary to apply at least one transformation on the signed entity to exclude the signature or 13206

�� publisherAssertion


377/405

signature(s). The transformation selected by a publisher or the XML Signature tool is specified 13207 in a Transform element inside the Signature element. In the case that a publisher is generating 13208 only one signature per containing element, the “Enveloped Signature Transform” specified in 13209 XML-Signature Syntax and Processing is an appropriate transform to support the enveloping. 13210

After the “Reference Generation” steps are performed according to XML-Signature Syntax and 13211 Processing, the SignedInfo should be generated, requiring the selection of a Canonicalization 13212 Method. It is strongly RECOMMENDED that the Schema Centric Canonicalization algorithm 13213 be used for producing the canonical form of the data object referenced in the SignedInfo. 13214 Other canonicalization algorithms, including the Canonical XML referenced in the XML-13215 Signature Syntax and Processing specification, do not account for the nature of the response 13216 structures in UDDI registries. Due to the re-enveloping, namespace prefix normalization, 13217 Unicode normalization and other schema based alterations to the data objects, signatures 13218 generated using other canonicalization algorithms MAY NOT and likely will not validate 13219 successfully when the entity is retrieved from one or more nodes of a registry. 13220

It is RECOMMENDED that well known key formats be used in the KeyInfo applied during 13221 generation of the signature. As indicated by XML Signature Syntax and Processing, Section 13222 4.4, “questions of trust of such key information (e.g., its authenticity or strength) are out of 13223 scope of this specification and left to the application.” It is then left to the publisher to produce 13224 a signature where the credentials asserted in the KeyInfo MAY be verified by an inquirer. 13225 Without diligent verification of the contents and validity of any published KeyInfo in the 13226 Signature element, XML-Signature Syntax and Processing only provides integrity with respect 13227 to the data supplied by the publisher but provides no assurance of the identity of the publisher. 13228

I.2 Validation of a Signature 13229

A Signature element returned in the get_xxDetails API call SHOULD be validated according to 13230 the required steps of “Core Validation” in XML-Signature Syntax and Processing. 13231

The input to the signature validation should be the top level element that is returned by the 13232 registry as a result of the Inquiry API call. This element, referred to as the data object in the 13233 XML-Signature and Syntax specification, is the businessEntity element for get_businessDetail 13234 API calls, the businessService element for get_serviceDetail API calls, the bindingTemplate for 13235 get_bindingDetail API calls, the tModel for get_tModelDetail API calls and the 13236 publisherAssertion contained in the sharedRelationship structure in find_relatedBusinesses 13237 API calls. 13238

Typically, the nodes will not validate the signature on behalf of a client, so any client that uses 13239 signed data for any form of assurance MUST validate the signatures on the relevant data 13240 objects and MUST perform the necessary diligence on the KeyInfo if the inquirer uses the 13241 KeyInfo element for an assurance of identity of the publisher. 13242

13243


378/405

13244

J Appendix J: UDDI Replication Examples 13245

13246

J.1 Communication Graph 13247

13248

The following diagram is an example of a simple communicationGraph that restricts the 13249 invocation of get_changeRecords messages to a unidirectional-ring amongst a set of four 13250 nodes. In operational practice, it is expected that this get_changeRecords message will 13251 typically be the only UDDI replication message where communication restrictions are imposed. 13252 The introduction of communication restrictions on the notify_changeRecordsAvailable 13253 messages between nodes within a registry is not expected to be commonplace. 13254

13255

13256

13257

Figure 6 - Communication Graph Example 13258

The arrows in Figure 6 depict the direction of flow of datum from one node to another. 13259

The communication graph depicted in the Replication Configuration Structure example in the 13260 next section represents a spanning cycle topology. This is one of many possible topologies 13261 supported within this replication framework. 13262

13263

J.2 Replication Configuration Structure Example 13264

<?xml version="1.0" encoding="UTF-8"?> 13265 <replicationConfiguration xmlns="urn:uddi-org:repl_v3"> 13266 <serialNumber>8</serialNumber> 13267 <timeOfConfigurationUpdate>200203041859Z</timeOfConfigurationUpdate> 13268 <registryContact> 13269 <contact xmlns="urn:uddi-org:api_v3"> 13270 <description>Registry Administrative Contact</description> 13271 <personName>King Kurt</personName> 13272 <phone useType="Voice">425-555-1212</phone> 13273 <email useType="e-mail">[email protected]</email> 13274 </contact> 13275 </registryContact> 13276


379/405

<operator> 13277 <operatorNodeID>uddi:microcute.com:node:uddi1.microcute.com</operatorNodeID> 13278 <operatorStatus>normal</operatorStatus> 13279 <contact useType="Operator Contact" xmlns="urn:uddi-org:api_v3"> 13280 <description>Microcute Customer Contact</description> 13281 <personName>Customer Support</personName> 13282 <phone useType="Voice">444.555.5589</phone> 13283 <email useType="e-mail">[email protected]</email> 13284 </contact> 13285 <operatorCustodyName>www.microcute.com/svcs/uddi</operatorCustodyName> 13286 <soapReplicationURL> 13287 https://www.microcute.com/svcs/uddi/repl.asmx 13288 </soapReplicationURL> 13289 </operator> 13290 <operator> 13291 13292 <operatorNodeID>uddi:microcute.com:node:uddi2.microcute.com</operatorNodeID> 13293 <operatorStatus>normal</operatorStatus> 13294 … 13295 </operator> 13296 <operator> 13297 13298 <operatorNodeID>uddi:microcute.com:node:uddi3.microcute.com</operatorNodeID> 13299 <operatorStatus>normal</operatorStatus> 13300 … 13301 </operator> 13302 <operator> 13303 13304 <operatorNodeID>uddi:microcute.com:node:uddi4.microcute.com</operatorNodeID> 13305 <operatorStatus>normal</operatorStatus> 13306 … 13307 </operator> 13308 <communicationGraph> 13309 <node>uddi:microcute.com:node:uddi1.microcute.com</node> 13310 <node>uddi:microcute.com:node:uddi2.microcute.com</node> 13311 <node>uddi:microcute.com:node:uddi3.microcute.com</node> 13312 <node>uddi:microcute.com:node:uddi4.microcute.com</node> 13313 <controlledMessage>get_changeRecords</controlledMessage> 13314 <edge> 13315 <message>get_changeRecords</message> 13316 <messageSender> 13317 uddi:microcute.com:node:uddi1.microcute.com 13318 </messageSender> 13319 <messageReceiver> 13320 uddi:microcute.com:node:uddi2.microcute.com 13321 </messageReceiver> 13322 </edge> 13323 <edge> 13324 <message>get_changeRecords</message> 13325 <messageSender> 13326 uddi:microcute.com:node:uddi2.microcute.com 13327 </messageSender> 13328 <messageReceiver> 13329 uddi:microcute.com:node:uddi3.microcute.com 13330 </messageReceiver> 13331 </edge> 13332 <edge> 13333 <message>get_changeRecords</message> 13334 <messageSender> 13335 uddi:microcute.com:node:uddi3.microcute.com 13336 </messageSender> 13337 <messageReceiver> 13338 uddi:microcute.com:node:uddi4.microcute.com 13339 </messageReceiver> 13340 </edge> 13341 <edge> 13342 <message>get_changeRecords</message> 13343 <messageReceiver> 13344 uddi:microcute.com:node:uddi4.microcute.com 13345 </messageReceiver> 13346 <messageReceiver> 13347


380/405

uddi:microcute.com:node:uddi1.microcute.com 13348 </messageReceiver> 13349 </edge> 13350 </communicationGraph> 13351 <maximumTimeToGetChanges>12</maximumTimeToGetChanges> 13352 </replicationConfiguration> 13353

13354

J.3 notify_changeRecordsAvailable Example 13355

The following is an example of a notify_changeRecordsAvailable call. 13356

13357

<?xml version="1.0" encoding="UTF-8"?> 13358 <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> 13359 <Body> 13360 <notify_changeRecordsAvailable xmlns="urn:uddi-org:repl_v3"> 13361 <notifyingNode> 13362 uddi:microcute.com:node:uddi2.microcute.com 13363 </notifyingNode> 13364 <changesAvailable> 13365 <highWaterMark> 13366 <nodeID> 13367 uddi:microcute.com:node:uddi2.microcute.com 13368 </nodeID> 13369 <originatingUSN>123</originatingUSN> 13370 </highWaterMark> 13371 <highWaterMark> 13372 <nodeID> 13373 uddi:microcute.com:node:uddi1.microcute.com 13374 </nodeID> 13375 <originatingUSN>241</originatingUSN> 13376 </highWaterMark> 13377 <highWaterMark> 13378 <nodeID> 13379 uddi:microcute.com:node:uddi3.microcute.com 13380 </nodeID> 13381 <originatingUSN>193</originatingUSN> 13382 </highWaterMark> 13383 <highWaterMark> 13384 <nodeID> 13385 uddi:microcute.com:node:uddi4.microcute.com 13386 </nodeID> 13387 <originatingUSN>173</originatingUSN> 13388 </highWaterMark> 13389 </changesAvailable> 13390 </notify_changeRecordsAvailable> 13391 </Body> 13392 </Envelope> 13393

13394


381/405

13395

J.4 get_ChangeRecords Example 13396

The following is an example of a get_changeRecords call. 13397

<?xml version="1.0" encoding="UTF-8"?> 13398 <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> 13399 <Body> 13400 <get_changeRecords 13401 xmlns:xsd=http://www.w3.org/2001/XMLSchema 13402 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 13403 xmlns="urn:uddi-org:repl_v3"> 13404 <requestingNode> 13405 uddi:microcute.com:node:uddi1.microcute.com 13406 </requestingNode> 13407 <changesAlreadySeen> 13408 <highWaterMark> 13409 <nodeID> 13410 uddi:microcute.com:node:uddi1.microcute.com 13411 </nodeID> 13412 <originatingUSN>242</originatingUSN> 13413 </highWaterMark> 13414 <highWaterMark> 13415 <nodeID> 13416 uddi:microcute.com:node:uddi2.microcute.com 13417 </nodeID> 13418 <originatingUSN>120</originatingUSN> 13419 </highWaterMark> 13420 <highWaterMark> 13421 <nodeID> 13422 uddi:microcute.com:node:uddi3.microcute.com 13423 </nodeID> 13424 <originatingUSN>193</originatingUSN> 13425 </highWaterMark> 13426 <highWaterMark> 13427 <nodeID> 13428 uddi:microcute.com:node:uddi4.microcute.com 13429 </nodeID> 13430 <originatingUSN>172</originatingUSN> 13431 </highWaterMark> 13432 </changesAlreadySeen> 13433 </get_changeRecords> 13434 </Body> 13435 </Envelope> 13436


382/405

13437

J.5 Miscellaneous Replication Example 13438

13439

The following XML Instance document describes several replication specific messages. 13440

13441

<?xml version="1.0" encoding="utf-8"?> 13442 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 13443 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 13444 xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 13445 <soap:Body> 13446 <changeRecords xmlns="urn:uddi-org:repl_v3"> 13447 <changeRecord acknowledgementRequested="false"> 13448 <changeID> 13449 <nodeID>uddi:microcute.com:node:uddi2.microcute.com</nodeID> 13450 <originatingUSN>120</originatingUSN> 13451 </changeID> 13452 <changeRecordNewData> 13453 <businessEntity businessKey=" 13454 uddi:microcute.com:uddi2:microcute.com:3f10…" 13455 operator="Microcute UDDI Services" 13456 authorizedName="…" 13457 xmlns="urn:uddi-org:api_v3"> 13458 <discoveryURLs> 13459 <discoveryURL useType="homepage"> 13460 http://...</discoveryURL> 13461 <discoveryURL useType="businessEntity"> 13462 http://....</discoveryURL> 13463 </discoveryURLs> 13464 <name xml:lang="en">Simple Business</name> 13465 <description xml:lang="en">Simple Business</description> 13466 <businessServices> 13467 <businessService serviceKey="…" 13468 businessKey="uddi:microcute.com:3f10…"> 13469 <name xml:lang="en">Off Shore Mining</name> 13470 <description xml:lang="en"> 13471 Off shore drilling 13472 </description> 13473 <bindingTemplates> 13474 <bindingTemplate bindingKey="…." 13475 serviceKey="…"> 13476 <accessPoint URLType="https"> 13477 http://...</accessPoint> 13478 </bindingTemplate> 13479 </bindingTemplates> 13480 <categoryBag> 13481 <keyedReference tModelKey="…" 13482 keyName="Iron Ores" 13483 keyValue="1010"/> 13484 </categoryBag> 13485 </businessService> 13486 </businessServices> 13487 </businessEntity> 13488 </changeRecordNewData> 13489 </changeRecord> 13490 <changeRecord acknowledgementRequested="false"> 13491 <changeID> 13492 <nodeID>uddi:microcute.com:node:uddi2.microcute.com</nodeID> 13493 <originatingUSN>121</originatingUSN> 13494 </changeID> 13495 <changeRecordNewData> 13496 <tModel tModelKey="…" 13497 operator="Microcute UDDI Services" 13498 authorizedName="…" 13499 xmlns="urn:uddi-org:api_v3"> 13500 <name>Simple tModel</name> 13501 <overviewDoc> 13502


383/405

<overviewURL>http://…</overviewURL> 13503 </overviewDoc> 13504 <identifierBag> 13505 <keyedReference tModelKey="…" 13506 keyName="Lab Tested Protocol" 13507 keyValue="protocol"/> 13508 </identifierBag> 13509 <categoryBag> 13510 <keyedReference tModelKey="…" 13511 keyName="Protocol" 13512 keyValue="protocol"/> 13513 </categoryBag> 13514 </tModel> 13515 </changeRecordNewData> 13516 </changeRecord> 13517 <changeRecord acknowledgementRequested="true"> 13518 <changeID> 13519 <nodeID>uddi:microcute.com:node:uddi2.microcute.com</nodeID> 13520 <originatingUSN>122</originatingUSN> 13521 </changeID> 13522 <changeRecordHide> 13523 <tModelKey xmlns="urn:uddi-org:api_v3">….</tModelKey> 13524 </changeRecordHide> 13525 </changeRecord> 13526 <changeRecord acknowledgementRequested="false"> 13527 <changeID> 13528 <nodeID>uddi:microcute.com:node:uddi2.microcute.com</nodeID> 13529 <originatingUSN>123</originatingUSN> 13530 </changeID> 13531 <changeRecordPublisherAssertion> 13532 <publisherAssertion> 13533 <fromKey>….</fromKey> 13534 <toKey>….</toKey> 13535 <keyedReference tModelKey="…" 13536 keyName="Holding Company" 13537 keyValue="parent-child"/> 13538 </publisherAssertion> 13539 <fromBusinessCheck>true</fromBusinessCheck> 13540 <toBusinessCheck>false</toBusinessCheck> 13541 </changeRecordPublisherAssertion> 13542 </changeRecord> 13543 </changeRecords> 13544 </soap:Body> 13545 </soap:Envelope> 13546

13547


384/405

13548

J.6 Non-normative – Cycle of Cycles Topology 13549

This section describes one of many possible topology choices allowed by this Replication 13550 Design. This appendix is an illustrative example only. 13551

13552

Figure 7 - Cycle of Cycles Topology 13553

13554

If the Communications Graph were a cycle of cycles, (e.g., if in addition to the ABCD spine, A0 13555 was also on a cycle with A1, A2, and A3, B0 was on a cycle with B1, B2, and B3, etc.) a 13556 variation of this would be applied. When a spine node such as B0 receives a 13557 get_changeRecords request (or in the case of A, when its timer event is triggered), it handles 13558 propagation through its sub-cycle before answering the get_changeRecords request on the 13559 "spine". B0 continues propagation along the spine only after the first round of propagation 13560 completes on its sub-cycle, which means that B has received all changes from B1, B2, and B3. 13561 It does not continue the second round of propagation on its sub-cycle until it receives the 13562 second round of changes from A, which contains updates from all other spine nodes and their 13563 sub-cycles. 13564

For a cycle, it is suggested that a backup node will be the next node in the cycle, and for 13565 added safety, the node after that as well, allowing propagation to proceed correctly even if 13566 there are node failures. Note that an incorrectly perceived node failure will not affect the 13567 correctness of the algorithm. If additional propagation is done, no unnecessary data will be 13568 replicated, although there may be additional get_changeRecords within the prescribed period 13569


385/405

13570

K Appendix K – Modeling UDDI within UDDI – A 13571

Sample 13572

UDDI itself is a set of Web services. With this in mind, modeling UDDI within UDDI is an 13573 important and illuminating exercise to help understand modeling decisions that need to be 13574 made when using UDDI. Moreover, the modeling of UDDI within UDDI is a required practice 13575 for all operators of UDDI nodes. For a complete explanation of recommended vs. required 13576 modeling decisions for UDDI nodes, see Chapter 9 Policy. 13577

This appendix will walk through the recommended modeling of a multi-versioned instance of 13578 UDDI. Each fragment of the different modeling pieces will be outlined, with an explanation of 13579 the salient modeling decisions and requirements made below. 13580

K.1 The Node’s businessEntity 13581

All nodes must create a Node Business Entity, under which the various services they offer are 13582 modeled. 13583

K.1.1 XML Fragment 13584

<businessEntity 13585 businessKey="uddi:tempuri.org:uddinodebusinessKey" 13586 xmlns="urn:uddi-org:api_v3"> 13587 <name xml:lang="en">A UDDI Node</name> 13588 <description xml:lang="en">This represents a sample model of how a uddi node 13589 might represent itself in UDDI 13590 </description> 13591 <categoryBag> 13592 <keyedReference tModelKey="uddi:uddi.org:categorization:nodes" 13593 keyValue="node" /> 13594 </categoryBag> 13595 13596

K.1.2 Explanation 13597

As explained in Section 6.2.2.1 Normative Modeling of Node Business Entity, a node must 13598 categorize its Node Business Entity with the uddi:uddi.org:categorization:nodes category, 13599 using the keyValue of node. 13600

Also note the creation of a UDDI v3 businessKey with the domainKey of 13601 uddi:tempuri.org:uddinodebusinessentity. 13602

K.2 The Policy Service 13603

With v3, there are a number of policy decision points that a node must document. These 13604 policies should be documented using the Policy schema. Policies placed in the document 13605 should reflect overarching policies for the node. Each specific API set may have an additional 13606 policy statement. Or, the entirety of a node’s policy might be in the XML file denoted by the 13607 Policy service. 13608

�� UDDInodeBusinessKey


�� UDDInodeBusinessEntity


386/405

13609


<businessService 13611 serviceKey="uddi:tempuri.org:policyservicekey" 13612 businessKey="uddi:tempuri.org:nodebusinesskey"> 13613 <name xml:lang="en">UDDI Policy Service</name> 13614 <description xml:lang="en">Web Service supporting UDDI policy 13615 information 13616 </description> 13617 <bindingTemplates> 13618 <bindingTemplate bindingKey="uddi:tempuri.org:uddinodepolicy" 13619 serviceKey="uddi:tempuri.org:policyservicekey"> 13620 <description xml:lang="en">This binding provides an HTTP GET 13621 XML document outlining overall policy decision points for 13622 this node. 13623 </description> 13624 <accessPoint useType="endPoint"> 13625 https://tempuri.org/uddi/overall_policy.xml 13626 </accessPoint> 13627 <tModelInstanceDetails> 13628 <tModelInstanceInfo tModelKey="uddi:uddi.org:v3_policy"> 13629 <description xml:lang="en">This binding supports the 13630 UDDI Version 3.0 policy modeling schema. 13631 </description> 13632 </tModelInstanceInfo> 13633 <tModelInstanceInfo 13634 tModelKey="uddi:uddi.org:protocol:serverauthenticatedssl3"> 13635 <description xml:lang="en">This binding's access point 13636 requires the use of SSL 3.0 with server 13637 authentication. 13638 </description> 13639 </tModelInstanceInfo> 13640 </tModelInstanceDetails> 13641 </bindingTemplate> 13642 </bindingTemplates> 13643 </businessService> 13644

13645


First, notice that there is a Policy businessService with a single bindingTemplate underneath it 13647 as a child. Also, note the keys for the policy businessService and bindingTemplate are based 13648 on the same domainKey. 13649

The accessPoint for the policy file is an XML file called overall_policy.xml. The useType 13650 attribute on the accessPoint has a value of “text”, which denotes that there is no indirection 13651 required to retrieve this data. 13652

There are two tModelInstanceInfos which the Policy bindingTemplate implement. First is the 13653 UDDI v3 Policy tModel. Implementing this tModel signifies that the XML file returned by this 13654 accessPoint conforms to the specification laid out in the uddi:uddi.org:v3_Policy tModel. 13655

The second tModel denotes that there is server authenticated SSL required to access this 13656 resource. One could determine this by parsing the address itself for the https prefix, but by 13657 modeling as such, this information can be determined through queries using the UDDI API. 13658

�� policyServiceKey"

�� nodeBusinessKey

�� UDDInodePolicy"

�� policyServiceKey


L3


387/405

13659

K.2.2.1 Sample Policy Document 13660

The following document is an example of a policy document. Not all policy decision points 13661 have been demonstrated in this sample, but rather, only a subset is represented. As shown in 13662 the example, the policy document for the policy service includes both registry-defined policies 13663 and policies delegated to the node. 13664

13665

<?xml version="1.0" encoding="UTF-8" ?> 13666 <policies xmlns="urn:uddi-org:policy_v3"> 13667 <policy> 13668 <policyName>Registering Nodes in a Registry</policyName> 13669 <policyDescription xml:lang="en"> 13670 This registry contains two nodes, the tempuri.org node and the 13671 example.org node. The configuration 13672 of these nodes is protected by a signed Replication Configuration 13673 Structure. 13674 Access to this configuration file is only available to the operators of 13675 the nodes. Nodes may be added by mutual agreement of both nodes. 13676 In the event that either node is removed from the registry, 13677 publishers will receive notification and all data custody will be 13678 transferred to one the remaining nodes chosen by the publisher. 13679 </policyDescription> 13680 <policyDecisionPoint>registry</policyDecisionPoint> 13681 </policy> 13682 <policy> 13683 <policyName>User Limits</policyName> 13684 <policyDescription xml:lang="en"> 13685 There are two levels of publisher accounts for the tempuri.org node. 13686 Level 1: 13687 A level 1 publisher account is used by individual businesses and 13688 organizations registering at the http://tempuri.org/uddi site. 13689 13690 Current limits are as follows: 13691 13692 1 Business Entity; 13693 4 Business Services per Business Entity; 13694 2 Binding Templates per Business Service; 13695 10 tModels; 13696 13697 In the event that a publisher needs to register additional information, 13698 an account upgrade with increased limits for business entities or 13699 tModels may be requested by sending an email to [email protected]. 13700 Additional information about the publisher will be collected to help 13701 verify requirements to register additional information. 13702 13703 Level 2: 13704 13705 A level 2 publisher account is typically used by large organizations, 13706 marketplaces, or service providers that provide registration services 13707 on behalf of multiple businesses. These accounts have no restrictions 13708 on the amount of information that may be registered within the node. 13709 13710 A publisher account may be upgraded from Level 1 to Level 2 by 13711 contacting the node. To request a publisher account upgrade, send an 13712 email request to [email protected]. 13713 13714 </policyDescription> 13715 <policyDecisionPoint>node</policyDecisionPoint> 13716 </policy> 13717 <policy> 13718 <policyName>Audit</policyName> 13719 <policyDescription xml:lang="en"> 13720 The http://tempuri.org/uddi site will monitor and audit all 13721 publication activity at its site. Any publisher registered at the node 13722 may request the history of its published information by sending an 13723 email request to [email protected]. The history of each registered entry 13724


388/405

published at the node will be provided within one week. 13725 13726 Audit history will be maintained for one year. 13727 </policyDescription> 13728 <policyDecisionPoint>node</policyDecisionPoint> 13729 </policy> 13730 <policy> 13731 <policyName>Data Integrity</policyName> 13732 <policyDescription xml:lang="en"> 13733 This registry will endeavor to maintain the integrity of all 13734 information registered at any node of the registry, either through 13735 the programmatic XML and SOAP interfaces, or any other interface 13736 provided by a node. Limitations imposed by the specification include, 13737 but are not limited to, the following: 13738 13739 Whitespace will be normalized and trimmed according 13740 to the rules defined in the UDDI specification and 13741 schemas. All content will also be normalized according 13742 to the Unicode normalization algorithm referenced in 13743 the specification. 13744 13745 Size limits for individual data elements stored within 13746 the UDDI registry have been established in the 13747 specification. Information registered at any node 13748 exceeding these size limits will be rejected. 13749 13750 The terms of use statement for publication of information at 13751 http://tempuri.org/uddi requires that all information published be 13752 accurate, and that the publisher is authorized to represent their 13753 individual organization(s). Should violations of this policy be 13754 detected, and/or unauthorized publication of information occur, 13755 notification of such violation should be sent via email to 13756 [email protected]. The information in the registry will be tracked 13757 internally as suspect or contested. The registered contact information 13758 for the publisher of the contested information will be provided within 13759 4 business hours. 13760 13761 Final resolution of the conflict is responsibility of the parties 13762 involved, and should follow established legal processes. The 13763 http://tempuri.org/uddi operations team will comply with the resolution 13764 agreed to by the parties involved, or the results of any subsequent 13765 litigation related to the issue. This compliance is limited to 13766 removal of the contested information from the UDDI registry. 13767 </policyDescription> 13768 <policyDecisionPoint>node</policyDecisionPoint> 13769 </policy> 13770 </policies> 13771


389/405

13772

K.3 The Security Service 13773

In UDDI Version 3, the Security API is an optional API that may or may not be supported by a 13774 node. In this sample, the node does support the security API, and has indicated this by 13775 modeling a specific security service, where clients may use the Security API. 13776


<businessService 13778 serviceKey="uddi:tempuri.org:authservicekey" 13779 businessKey="uddi:tempuri.org:nodebusinesskey"> 13780 <name xml:lang="en">UDDI Authentication Service</name> 13781 <description xml:lang="en"> 13782 Web Service supporting UDDI Security API 13783 </description> 13784 <bindingTemplates> 13785 <bindingTemplate 13786 bindingKey="uddi:tempuri.org:authbinding" 13787 serviceKey="uddi:tempuri.org:authservicekey"> 13788 <description xml:lang="en"> 13789 This binding to authenticate with the UDDI services using the UDDI 13790 Security API. 13791 </description> 13792 <accessPoint useType="endPoint"> 13793 https://tempuri.org/uddi/authenticate.asmx 13794 </accessPoint> 13795 <tModelInstanceDetails> 13796 <tModelInstanceInfo tModelKey="uddi:uddi.org:v3_security"> 13797 <description xml:lang="en">This binding's supports the UDDI v3 13798 Security API. 13799 </description> 13800 </tModelInstanceInfo> 13801 <tModelInstanceInfo 13802 tModelKey="uddi:uddi.org:protocol:serverauthenticatedssl3"> 13803 <description xml:lang="en"> 13804 This binding's access point requires the use of SSL 3.0 13805 with server authentication. 13806 </description> 13807 </tModelInstanceInfo> 13808 </tModelInstanceDetails> 13809 </bindingTemplate> 13810 </bindingTemplates> 13811 </businessService> 13812

13813


Similar to the policy businessService, the security businessService has a single 13815 bindingTemplate which contains the accessPoint for the Security API itself. 13816

The accessPoint provides the end point where this API can be invoked. It too is decorated 13817 with a useType attribute of “endPoint”, denoting that there is no indirection involved in the 13818 accessPoint. 13819

The bindingTemplate implements the uddi:uddi.org:v3_security API, and thus complies with 13820 the requirements which are represented by that tModel. 13821

Similar to the Policy tModel, this Security API models its security protocol using the 13822 uddi:uddi.org:protocol:serverauthenticatedssl3 tModel. 13823

�� authServiceKey"


�� authBinding"

�� authServiceKey

�� V3


L3

�� serverAuthenticatedSSL3


390/405

13824

K.4 The Publish Service – Supporting 3 Versions 13825

In this sample, the node supports all three UDDI Publish API sets. This has been modeled as 13826 a single Publish businessService with three different bindingTemplates, one for each version of 13827 the UDDI Publish API it supports. 13828


<businessService 13830 serviceKey="uddi:tempuri.org:publishservicekey" 13831 businessKey="uddi:tempuri.org:nodebusinesskey"> 13832 <name xml:lang="en">UDDI Publish API Services</name> 13833 <description xml:lang="en">Web Service supporting UDDI 13834 specifications</description> 13835 <bindingTemplates> 13836 13837 13838 <bindingTemplate 13839 bindingKey="uddi:tempuri.org:uddinodebindingkey_publish_v1" 13840 serviceKey="uddi:tempuri.org:publishservicekey"> 13841 <description xml:lang="en"> 13842 This binding supports the UDDI Programmer's API Specification for 13843 publication 13844 </description> 13845 <accessPoint useType="endPoint"> 13846 https://tempuri.org/uddi/publish.asmx 13847 </accessPoint> 13848 <tModelInstanceDetails> 13849 <tModelInstanceInfo 13850 tModelKey="uddi:64c756d1-3374-4e00-ae83-ee12e38fae63"> 13851 <description xml:lang="en"> 13852 This binding supports the UDDI Version 1.0 Programmer's API 13853 Specification for publication 13854 </description> 13855 </tModelInstanceInfo> 13856 </tModelInstanceDetails> 13857 </bindingTemplate> 13858 13859 13860 <bindingTemplate 13861 bindingKey="uddi:tempuri.org:uddinodebindingkey_publish_v2" 13862 serviceKey="uddi:tempuri.org:publishservicekey"> 13863 <description xml:lang="en"> 13864 This binding supports the UDDI Programmer's API Specification for 13865 publication 13866 </description> 13867 <accessPoint useType="endPoint"> 13868 https://tempuri.org/uddi/publish_v2.asmx 13869 </accessPoint> 13870 <tModelInstanceDetails> 13871 <tModelInstanceInfo 13872 tModelKey="uddi:a2f36b65-2d66-4088-abc7-914d0e05eb9e"> 13873 <description xml:lang="en"> 13874 This binding supports the UDDI Version 2.0 Programmer's API 13875 Specification for publication 13876 </description> 13877 </tModelInstanceInfo> 13878 </tModelInstanceDetails> 13879 </bindingTemplate> 13880 13881 13882 <bindingTemplate 13883 bindingKey="uddi:tempuri.org:uddinodebindingkey_publish_v3" 13884 serviceKey="uddi:tempuri.org:publishservicekey"> 13885 <description xml:lang="en"> 13886 This binding supports the UDDI Programmer's API Specification for 13887 publication 13888 </description> 13889

�� publishServiceKey"


�� UDDInodeBindingKey_Pu

blish��

publishServiceKey


blish��

publishServiceKey


blish��

publishServiceKey


391/405

<accessPoint useType="endPoint"> 13890 https://tempuri.org/uddi/publish_v3.asmx 13891 </accessPoint> 13892 <tModelInstanceDetails> 13893 <tModelInstanceInfo tModelKey="uddi:uddi.org:v3_publication"> 13894 <description xml:lang="en"> 13895 This binding supports the UDDI Version 3.0 Programmer's API 13896 Specification for publication 13897 </description> 13898 <instanceDetails> 13899 <overviewDoc> 13900 <description xml:lang="en"> 13901 This overviewURL provides policy information about 13902 publication. 13903 </description> 13904 <overviewURL useType="text"> 13905 https://tempuri.org/uddi/publish_policy.xml 13906 </overviewURL> 13907 </overviewDoc> 13908 <instanceParms> 13909 <![CDATA[ 13910 <?xml version="1.0" encoding="utf-8" ?> 13911 <UDDIinstanceParmsContainer 13912 xmlns="urn:uddi-org:policy_v3_instanceParms"> 13913 <authInfoUse>required</authInfoUse> 13914 </UDDIinstanceParmsContainer> 13915 ]]> 13916 </instanceParms> 13917 </instanceDetails> 13918 </tModelInstanceInfo> 13919 <tModelInstanceInfo 13920 tModelKey="uddi:uddi.org:protocol:serverauthenticatedssl3"> 13921 <description xml:lang="en"> 13922 This binding's access point requires the use of SSL 3.0 with server 13923 authentication. 13924 </description> 13925 </tModelInstanceInfo> 13926 </tModelInstanceDetails> 13927 </bindingTemplate> 13928 13929 13930 </bindingTemplates> 13931 </businessService> 13932

13933


First, note the creation of three bindingTemplates with domainKeys for each of the different 13935 API versions: uddi:tempuri.org:uddinodebindingkey_publish_v1, 13936 uddi:tempuri.org:uddinodebindingkey_publish_v2, and 13937 uddi:tempuri.org:uddinodebindingkey_publish_v3. In this sample, there must be three 13938 different bindingTemplates because each accessPoint for the different APIs is different. Were 13939 a node to support multiple versions through the same accessPoint, fewer bindingTemplates 13940 would be required for the purposes of modeling. 13941

The Version 1 and Version 2 bindingTemplates are identical except for two differences: the 13942 accessPoints differ and the tModelInstanceInfo differs, as each bindingTemplate implements a 13943 different version of the API. Note that the Version 1 and Version 2 bindingTemplates 13944 implement their publish API version tModels with a UUID. Because these canonical tModels 13945 do not have a corresponding v3 domainKey, the UUIDs are taken from the earlier version of 13946 the specification and used. 13947

In the Version 3 bindingTemplate, note the instanceDetails of the tModelInstanceInfo for the v3 13948 API set. There is an overviewDoc specified that directs a user to policy information about that 13949 API specifically. For example, this document might discuss publication limits, processes for 13950 gaining a publication account, etc. It is not required that a separate policy document be 13951


L3


blish��

UDDInodeBindingKey_Publish��

UDDInodeBindingKey_Publish


392/405

created for each API, but it is convenient for the user to be able to directly access policy 13952 information about that API. 13953

Also, there is an XML fragment using <![CDATA[ … ]]> within the instanceParms. This XML 13954 fragment models the authInfo use policy for this API, as explained in Chapter 9 Policy. In this 13955 case, an authInfo element is required on all Publish API calls to this node. 13956

The Version 3 bindingTemplate also implements the SSL tModel, as it must be invoked 13957 through SSL. 13958

Note that the Version 1 and 2 APIs are not modeled to say that they implement the SSL 13959 tModel, nor do they have a policy overviewURL. This modeling decision was made because 13960 the use of SSL is specified by the definition of the UDDI Version 1 and 2 Publish API sets and 13961 because the conventions for modeling the use of SSL did not exist until the Version 3 13962 specification. However, a node may choose to model these newer canonical tModels on older 13963 API sets as appropriate. 13964

K.5 The Inquiry Service – Supporting 3 Versions 13965

Lastly, the node has modeled three different versions of the Inquiry API under a single logical 13966 businessService. 13967


<businessService 13969 serviceKey="uddi:tempuri.org:nodeservicekey" 13970 businessKey="uddi:tempuri.org:nodebusinesskey"> 13971 <name xml:lang="en">UDDI Inquiry Services</name> 13972 <description xml:lang="en"> 13973 Web Service supporting UDDI Inquiry APIs 13974 </description> 13975 <bindingTemplates> 13976 13977 13978 <bindingTemplate 13979 bindingKey="uddi:tempuri.org:uddinodebindingkey_inquiry_v1" 13980 serviceKey="uddi:tempuri.org:inquiryservicekey"> 13981 <description xml:lang="en"> 13982 This binding supports the UDDI Programmer's API Specification for inquiry 13983 </description> 13984 <accessPoint useType="endPoint"> 13985 http://tempuri.org/uddi/inquire.asmx 13986 </accessPoint> 13987 <tModelInstanceDetails> 13988 <tModelInstanceInfo 13989 tModelKey="uddi:4cd7e4bc-648b-426d-9936-443eaac8ae23"> 13990 <description xml:lang="en"> 13991 This access point supports the UDDI Version 1.0 Programmer's API 13992 Specification for inquiry 13993 </description> 13994 </tModelInstanceInfo> 13995 </tModelInstanceDetails> 13996 </bindingTemplate> 13997 13998 13999 <bindingTemplate 14000 bindingKey="uddi:tempuri.org:uddinodebindingkey_inquiry_v2" 14001 serviceKey="uddi:tempuri.org:inquiryservicekey"> 14002 <description xml:lang="en"> 14003 This binding supports the UDDI Programmer's API Specification for inquiry 14004 </description> 14005 <accessPoint useType="endPoint"> 14006 http://tempuri.org/uddi/inquire_v2.asmx 14007 </accessPoint> 14008 <tModelInstanceDetails> 14009 <tModelInstanceInfo 14010 tModelKey="uddi:ac104dcc-d623-452f-88a7-f8acd94d9b2b"> 14011 <description xml:lang="en"> 14012

�� nodeServiceKey"


�� UDDInodeBindingKey_In

quiry��

inquiryServiceKey


quiry��

inquiryServiceKey


393/405

This access point supports the UDDI Version 2.0 Programmer's API 14013 Specification for inquiry 14014 </description> 14015 </tModelInstanceInfo> 14016 </tModelInstanceDetails> 14017 </bindingTemplate> 14018 14019 14020 <bindingTemplate 14021 bindingKey="uddi:tempuri.org:uddinodebindingkey_inquiry_v3" 14022 serviceKey="uddi:tempuri.org:inquiryservicekey"> 14023 <description xml:lang="en"> 14024 This binding supports the UDDI Programmer's API Specification for inquiry 14025 </description> 14026 <accessPoint useType="endPoint"> 14027 http://tempuri.org/uddi/inquire_v3.asmx 14028 </accessPoint> 14029 <tModelInstanceDetails> 14030 <tModelInstanceInfo tModelKey="uddi:uddi.org:v3_inquiry"> 14031 <description xml:lang="en"> 14032 This access point supports the UDDI Version 3.0 Programmer's API 14033 Specification for inquiry 14034 </description> 14035 <instanceDetails> 14036 <overviewDoc> 14037 <description xml:lang="en"> 14038 This overviewURL provides policy information about 14039 inquiry. 14040 </description> 14041 <overviewURL useType="text"> 14042 http://tempuri.org/uddi/inquiry_policy.xml 14043 </overviewURL> 14044 <instanceParms> 14045 <![CDATA[ 14046 <?xml version="1.0" encoding="utf-8" ?> 14047 <UDDIinstanceParmsContainer 14048 xmlns="urn:uddi-org:policy_v3_instanceParms"> 14049 <defaultSortOrder>binarySort</defaultSortOrder> 14050 <authInfoUse>ignored</authInfoUse> 14051 </UDDIinstanceParmsContainer> 14052 ]]> 14053 </instanceParms> 14054 </overviewDoc> 14055 </instanceDetails> 14056 </tModelInstanceInfo> 14057 </tModelInstanceDetails> 14058 </bindingTemplate> 14059 14060 14061 </bindingTemplates> 14062 </businessService> 14063


quiry��

inquiryServiceKey


394/405

14064


Similar to the Publish API modeling, the Inquiry API modeling creates three bindingTemplates 14066 with three new bindingKeys. Each bindingTemplate has a different accessPoint. All three 14067 accessPoints are decorated with a useType attribute of “endPoint”, as there is no indirection in 14068 accessing these APIs. Each Version implements the appropriate tModel signifying the 14069 contract necessary to invoke that API. The Version 1 and Version 2 tModels use UUIDs, 14070 whereas the Version 3 tModel, uddi:uddi.org:v3_inquiry, has a domainKey. 14071

Note that the Version 3 tModel has an instanceDetails structure with an overviewDoc that 14072 leads to a policy file. Such a policy file might contain information specific to that API. 14073

Also, there is an XML fragment nested with a “block escape” of the instanceParms. This XML 14074 fragment models the authInfo use policy for this API set as well as the default sort order. 14075

14076


395/405

14077

L Appendix L: Glossary of Terms 14078

14079

ABNF: See Augmented Backus-Naur Form 14080

<adjective> tModel: Any tModel that represents a concept of the type named by <adjective>. 14081 Hence, category system tModel, specification tModel, etc. 14082

Affiliation: A collection of registries whose policies make copying data among the registries 14083 safe and easy to do. 14084

API: Application Programming Interface. (pl.: APIs.) The interface to any of the SOAP-based 14085 Web services defined in the UDDI Specification. Most are offered by UDDI nodes and invoked 14086 by clients, but validate_values, get_allValidValues, and notify_subscriptionListener are offered 14087 by clients of UDDI and invoked by a UDDI node. 14088

API Set: Any of the collections of related UDDI APIs represented by a single specification 14089 tModel. There are 9 API sets in UDDI v3. They are inquiry, publication, subscription, custody 14090 transfer, security, subscription listener, replication, value set validation, and value set data API 14091 sets. 14092

Appendix: Any of the lettered top-level sections of the UDDI v3 Specification. 14093 E.g., Appendix C Supporting Subscribers. 14094

Assert a relationship: To publish a publisherAssertion containing an appropriate 14095 keyedReference, toKey and fromKey, to indicate that one businessEntity is associated with 14096 another in the way indicated by the specified keyedReference. See also, Complete a 14097 relationship. 14098

Augmented Backus-Naur Form: The formal syntax notation defined in RFC 2234. See: 14099 http://www.ietf.org/rfc/rfc2234.txt. 14100

Authentication: the process of verifying an identity claimed by or for a system entity. See 14101 http://www.ietf.org/rfc/rfc2828.txt. 14102

Authorization: a right or a permission that is granted to a system entity to access a system 14103 resource. See http://www.ietf.org/rfc/rfc2828.txt. 14104

Best practice: A non-normative document accompanying a UDDI specification that provides 14105 guidance on how to use UDDI registries. Best Practices not only represent the UDDI Working 14106 Group’s view on some UDDI-related topic but also represent well established practice. Cf., 14107 “Technical note”. 14108

Business: The people or organizations that are described in UDDI with a businessEntity. 14109 While quite often these are, in fact, businesses in the usual sense of the word, they need not 14110 be. For example, the “businesses” in a registry internal to a business might well be internal 14111 organizations. 14112

Canonical: A tModel that is normative with respect to the UDDI specification. Every canonical 14113 tModel is described in Chapter 11 Utility tModels and conventions. 14114

Categorize: To tag an entity with a category by placing an appropriate keyedReference or 14115 keyedReferenceGroup in the categoryBag of the entity. All entities categorized with the same 14116 value in the same category system are said to belong to the category named. E.g., in the 14117 NAICS category system, the category 481212 means “Non-scheduled chartered freight air 14118 transportation”. Every businessEntity categorized with the NAICS value 481212 belongs to the 14119 NAICS Non-scheduled chartered freight air transportation category. 14120

�� registries that follow

�� recommended keying

scheme, including the set of registry policies that makes copying data among ��


396/405

Category: A value representing a defined division of classification from a specified 14121 category system. 14122

Category group system: A tModel that represents a group of category systems intended to 14123 be used to categorize entities in which it is referenced with groups of categories. Category 14124 group systems are referenced in keyedReferenceGroups and its category systems are 14125 referenced in keyedReferences in contained keyedReferences. 14126

Category system: Any value set intended to be used to categorize the entities in which it is 14127 referenced. The documentation for a category system should describe the characteristics that 14128 mark the divisions, or categories, in the system. Each category in a category system typically 14129 represents a means of grouping distinct entities with similar characteristics. 14130

Chapter: Any of the top-level, numbered sections of the UDDI v3 Specification. 14131 E.g., Chapter 6 Node Operation. 14132

Checked: Of or pertaining to a value set whose use is subject to validation before an entity 14133 that refers to it is published. Checked value sets may be internally hosted or externally hosted. 14134 Cf. “Unchecked”. 14135

Client: Any person who invokes one or more of the APIs covered in Chapter 5 UDDI 14136 Programmer APIs. Note that clients are clients of a node, not a registry. If the same person 14137 invokes APIs at two different nodes of a registry, two clients are involved. Identity of persons 14138 when they are established at all are node specific. The relationship of identities, if any, across 14139 the registry is a matter of node and registry policy. 14140

Complete a relationship: To publish the second of two matching publisherAssertion entities. 14141 In the case in which the publisher owns referred-to businessEntity structures, asserting the 14142 relationship also completes it; no second publisherAssertion is required. Completed 14143 relationships are visible to inquirers; relationships that have not been completed are visible 14144 only to the owners of the businessEntity structures involved. See also Assert a relationship. 14145

Container: An element in one of the UDDI API schemas that contains one other single, 14146 recurring child element. The collection of all child elements in a corresponding XML document 14147 is called a list. 14148

Core data structures: Any of the data structures businessEntity, businessService, 14149 bindingTemplate, tModel. The core data structures are all entities. 14150

Custody: Each entity in UDDI is said to be in the custody of the node at which it was 14151 published. That node is said to be the custodial node for the entity. 14152

Data Integrity: the property that data has not been changed, destroyed, or lost in an 14153 unauthorized or accidental manner. See http://www.ietf.org/rfc/rfc2828.txt. 14154

Data Confidentiality: the property that information is not made available or disclosed to 14155 unauthorized individuals, entities, or processes. See http://www.ietf.org/rfc/rfc2828.txt. 14156

Data model: A mapping of the contents of an information model into a form that is specific to a 14157 particular type of data store or repository. UDDI specifies an information model but not a data 14158 model. Implementations are free to choose any data model they find convenient. 14159

Delegated policy: In UDDI, a policy decision that the registry has chosen to allow a node to 14160 make. In the context of RFC 3198, the registry delegates the policy to the node. 14161

Derived key generator: More fully, “derived key generator tModel”. In the UDDI keying 14162 scheme, a key generator with a publisher-assigned key whose value is in the partition of a key 14163 generator owned by the publisher. 14164

Digital signature: Any of the signature elements found in the optional signatures element of 14165 each UDDI entity. 14166

Domain key generator: More fully, “domain key generator tModel”. In the UDDI keying 14167 scheme, any key generator with a key of the form 14168

��

�� A category system is

distinct from an identifier system in that many entities in the same registry can be categorized with the same category

�� recommended

�� recommended


397/405

“uddi:” domain “:keygenerator” 14169

Where domain is a DNS domain – e.g., “example.com”. 14170

Element: An XML element. See http://www.w3.org/TR/REC-xml - elemdecls. 14171

Entity: Any of the data structures that have a corresponding save_xx API. I.e., The core data 14172 structures plus publisherAssertion and subscription 14173

Exporter: The behavior of an inquirer associated with a given registry that publishes copied 14174 (and, perhaps, modified) data into some other registry. 14175

Find qualifier: Any of the modifiers that may be specified in the findQualifiers element of the 14176 find_xx APIs to modify the APIs’ behavior. The find qualifiers are discussed in Section 5.1.4 14177 Find qualifiers of the UDDI v3 Specification 14178

Hosting redirector: An instance of a Web service whose service type is defined by the tModel 14179 uddi-org:hostingRedirector. Hosting redirector services provide a level of indirection in the 14180 retrieval of bindingTemplates. See Section B.1.4 Using the “hostingRedirector” value and 14181 Section 11.5.2 UDDI Hosting Redirector Specification for more information. 14182

HTTP: Hyper Text Transfer Protocol. The protocol used by the World Wide Web as defined in 14183 RFC 2068. See http://www.ietf.org/rfc/rfc2068.txt. 14184

Identifier: A value representing the distinct identity of the entity from a specified identifier 14185 system. 14186

Identifier system: Any value set intended to be used to identify the entities in which it is 14187 referenced. The documentation for an identifier system should describe the distinct 14188 characteristics of an entity for each value, or identifier, in the system. Each identifier in an 14189 identifier system typically represents a unique entity or entities that are considered equivalent. 14190

Identify1: (Concerning UDDI entities) To tag an entity with an identifier by placing an 14191 appropriate keyedReference in the identifierBag of the entity. E.g., Microsoft Business 14192 Solutions Group has the Thomas Register Supplier ID 43038249. Placing a keyedReference 14193 with this keyValue and referring to the Thomas Register Supplier ID identifier system into the 14194 identifierBag of a businessEntity identifies the businessEntity as being that of the Microsoft 14195 Business Solutions Group. 14196

Identify2: (Concerning security) To present an identifier to a system so that the system can 14197 recognize a system entity and distinguish it from other entities. (See 14198 http://www.ietf.org/rfc/rfc2828.txt) 14199

Implementation1: (of a UDDI API set) A running instance of a UDDI API set. 14200

Implementation2: (of a node) The collection consisting of the implementations of all of the API 14201 sets constituting a node. 14202

Implementer: Any person who implements a UDDI node. 14203

Importer: The behavior of a publisher associated with a given registry that copies (and, 14204 perhaps, modifies) data stored in one or more other registries. 14205

Information model: An abstraction and representation of the UDDI entities in a managed 14206 environment, their properties and attributes, and the way they relate to each other. An 14207 information model is independent of any specific data model it may be mapped to. Chapters 1 14208 through 8 of this document define the UDDI v3 information model. This includes the structure 14209 of the data, the behavior of all API sets as well as the recommended means of transport and 14210 encapsulation of the API sets. UDDI does not define a data model. 14211

Inquirer: Any client who uses the inquiry API set. 14212

Internally hosted: Of or pertaining to checked value sets whose use is validated entirely by 14213 the node at which the publish operation takes place. Cf., “Provider-hosted”. 14214

�� keyGenerator

�� An identifier system is

distinct from a category system in that only one entity in a given registry should be associated with a given identifier


398/405

Internally revised: Of or pertaining to internally hosted value sets, the values for which are 14215 refreshed from time to time in some way that is entirely internal to the registry. 14216

Internationalization: The process of generalizing computer systems so that they can handle 14217 a variety of linguistic and cultural conventions65. 14218

Key: Any of the unique tokens used to identify and refer to an entity stored in a registry. Keys 14219 in UDDI v3 are Uniform Resource Identifiers (URIs). See also UDDI keying scheme. 14220

Key generator: More fully, “key generator tModel”. In the UDDI keying scheme, a tModel 14221 whose key ends with “:keygenerator”. Ownership of a key generator tModel represents the 14222 authority to propose keys that, so long as they are of the appropriate form, will meet the 14223 registry’s policy for publisher-assigned keys. The form of the keys that is appropriate depends 14224 on the key of the tModel; the appropriate form for two different key generators is never the 14225 same. 14226

List: The collection of all elements that occur in a container element 14227

Multi-node registry: A registry consisting of more that one node. Typically in a multi-node 14228 registry, each node has its own copy of the entities stored in the registry. In such cases the 14229 copies are typically kept synchronized using an implementation of the replication API set at 14230 each node. 14231

Namespace: A collection of distinct names represented as strings of characters. Usually the 14232 names in a namespace are constructed according to a set of rules given by the definition of the 14233 namespace. URIs of various kinds are commonly used to construct the names in 14234 namespaces. For example, the namespace for UDDI keys in the UDDI keying scheme 14235 consists of the URIs in the “uddi” scheme. 14236

Node: A collection of Web services, each of which implements the APIs in a UDDI API set, 14237 and that are managed according to a common set of policies. Typically, a node consists of at 14238 least an implementation of the Inquiry, the Publication, and the Custody and Ownership 14239 Transfer API sets; often a node will implement additional API sets such as Subscription and 14240 Replication. 14241

Node Business Entity: A businessEntity in a registry that is categorized using the uddi-14242 org:operators category system. At a minimum, each Node Business Entity describes the Web 14243 services that constitute the node. 14244

Non-normative: Information included in the UDDI v3 Specification that is advisory or 14245 explanatory and does not constitute required aspects of the specification. 14246

Normative: Specification information that is intrinsic to the UDDI v3 Specification and must be 14247 adhered to. 14248

Operator: The role of a person who sets node policy and runs a node. There is exactly one 14249 operator for a given node. 14250

Overview document: A document providing the technical definition of the concept a given 14251 tModel represents. The overview documents for a given tModel may be retrieved using the 14252 URLs contained within the overviewDoc structure of the tModel. 14253

Owner: The publisher who has the authority to change a given entity. 14254

Partition: In the UDDI keying scheme, the appropriate form of publisher-assigned keys for a 14255 given tModel. The exact definition for the partition of a key generator is given in Section 5.2.2.1 14256 Key generator keys and their partitions. 14257

65 Martin O’Donnell, Sandra. Programming for the World. Prentice Hall, Englewood Cliffs, NJ. 1994.

�� Recommended

�� recommended

�� keyGenerator”.

�� recommended

�� recommended


399/405

Person: Someone – for example, an actual individual, an organization, or a job role – who 14258 interacts with a UDDI registry in some way. 14259

Policy: Certain behaviors, as identified in Chapter 9 Policy, that are permitted to vary from 14260 registry to registry or even from node to node within a registry. The choice of specific behavior 14261 made by a registry or node is its policy with respect to the variable behavior. As described in 14262 Chapter 9, each registry and node describes the policies it adheres to. 14263

Policy abstractions: Broad definitions of high level information management policies. Policy 14264 can be represented at different levels, ranging from business goals to device specific 14265 configuration parameters. Translation between different levels of "abstraction" may require 14266 information other than policy, such as network and host parameter configuration and 14267 capabilities. In UDDI there are often ways to model the policies as a tModel. In other cases the 14268 policy may be documented. 14269

Policy decision: A process perspective that deals with the evaluation of a policy rule's 14270 conditions. When an instance of UDDI is implemented, choices are made about the support for 14271 the UDDI APIs. There are points at which the implementation is responsible for a 14272 determination about whether or not the request is processed based on the rule’s specified for 14273 that node.. Because UDDI can be implemented in a variety of ways, these actions are 14274 considered policy decisions and the implementation must document how these decisions are 14275 made within this implementation of UDDI. 14276

Policy decision point: A logical entity that makes policy decisions for itself or for other 14277 network elements that request such decisions. See http://www.ietf.org/rfc/rfc2753.txt. The 14278 UDDI registry and its delegates make policy decisions. 14279

Policy enforcement: The execution of a policy decision. 14280

Policy enforcement point: A logical entity that enforces policy decisions. See 14281 http://www.ietf.org/rfc/rfc2753.txt. The UDDI API implementations enforce policy decisions. 14282

Policy goals: The business objectives or desired state intended to be maintained by a policy 14283 system. At the highest level of abstraction of policy, these goals are most directly described in 14284 business rather than technical terms. 14285

Policy rule: A basic building block of a policy-based system. It is the binding of a set of actions 14286 to a set of conditions where the conditions are evaluated to determine whether the actions are 14287 performed. 14288

Postal address system: Any value set intended to be used to define the meaning of 14289 addressLine structures. 14290

Project (verb): To establish the existence of a service projection. E.g., “Business A projects 14291 the View Catalog business service belonging to business B in its businessEntity.” 14292

Protocol tModel: A tModel representing a protocol such as the standard fax protocol. Cf., 14293 “Specification tModel” and “Transport tModel”. 14294

Provider-revised: Of or pertaining to internally hosted value sets, the values for which are 14295 revised from time to time by the value set publisher. Publisher-revised value sets have a 14296 get_allValidValues Web service associated with them from which nodes retrieve the revised 14297 value set values. 14298

Provider-hosted: Of or pertaining to checked value sets whose use is validated using a 14299 validate_values Web service. 14300

Publisher: Any client who uses the publish API set. 14301

Publish: The act of placing one or more entities in a registry by invoking one of the publication 14302 APIs. 14303

Publisher-assigned key: Any key created by a publisher (as opposed to one created by a 14304 node.) A publisher may propose a key for a new entity at the time it is first published. If the 14305


400/405

proposed key meets the registry’s policy for publisher-assigned keys and the publish operation 14306 succeeds, the key proposed by the publisher becomes a publisher-assigned key. 14307

Recommended keying scheme: The URI scheme “uddi” together with the set of registry 14308 policies that makes copying data among registries safe and easy to do. The recommended 14309 keying scheme is described in Chapter 4 of the UDDI v3 Specification 14310

Registry: One or more UDDI nodes may be combined to form a UDDI Registry. The nodes in 14311 a UDDI registry collectively manage a particular set of UDDI data. This data is distinguished by 14312 the visible behavior associated with the entities contained in it. A UDDI Registry has these 14313 defining characteristics: a registry is comprised of one or more UDDI nodes; the nodes of a 14314 registry collectively manage a well-defined set of UDDI data. Typically, this is supported by the 14315 use of UDDI replication between the nodes in the registry which reside on different systems; 14316 and a registry MUST make a policy decision for each policy decision point. It MAY choose to 14317 delegate policy decisions to nodes. See Chapter 9 Policy for details. The physical realization of 14318 a UDDI Registry is not mandated by this specification. 14319

Registry administrator: The role of the person who sets the policies for a registry. There is 14320 exactly one registry administrator for every registry. Typically, a registry administrator is an 14321 organization consisting of the operators of the registry’s nodes. 14322

Registry-assigned key: If no key is proposed for an entity at the time it is first published, the 14323 registry assigns a key. Such keys are called registry-assigned keys. 14324

Relationship: An association between one businessEntity and another established by 14325 completing a relationship. See also Assert a relationship and Complete a relationship 14326

Relationship type: A value from a specified relationship type system. 14327

Relationship type system: Any value set intended to be used to define the relationship types 14328 that are used in relationships between businessEntities. 14329

Romanization: The practice in some cultures of transliterating words, particularly names, from 14330 their usual written form into Roman letters so that people unfamiliar with the usual form can 14331 (make some sort of attempt to) pronounce them. In Japan, for example, it is common practice 14332 to Romanize personal names and place names for the benefit of people who cannot read 14333 Japanese. 14334

Root key generator: More fully, “root key generator tModel”. In the UDDI keying scheme 14335 either a “domain key generator” or a “uuid key generator”. 14336

Section: Any of the titled parts of a chapter or appendix. 14337 E.g., Section C.2 Using subscription. 14338

Service projection: A projected businessService is made a part of a businessEntity by 14339 reference as opposed to by containment. Every businessService is “contained” in exactly one 14340 businessEntity. The businessEntity the businessService is contained in is the one whose 14341 businessKey is specified in the businessKey attribute of the businessService in question. 14342 Therefore, if the businessKey found in a businessService is not the same as the businessKey 14343 of the businessEntity in which it is found, the businessService is a service projection. See also 14344 Project. 14345

Service type: The type of a Web service as defined by its technical fingerprint. 14346

Short name: Any of the abbreviated names for common find qualifiers as defined in Section 14347 5.1.4 Find Qualifiers. 14348

signatureComponent tModel: A tModel representing a component of a Web service 14349 specification. Some specifications, such as the RosettaNet are deliberately broken into pieces 14350 meant to be composed together to form a complete description of a Web service a 14351 signatureComponent tModel is used to represent each of these pieces. 14352

�� .¶

�� recommended


401/405

SMTP: Simple Mail Transport Protocol. The mail transport mechanism commonly used on the 14353 Internet. Defined in RFC 2821. See: http://www.ietf.org/rfc/rfc2821.txt. 14354

SOAP: Simple Object Access Protocol Version 1.1. The most common Web service protocol. 14355 Defined in World Wide Web Consortium Note. See: http://www.w3.org/TR/SOAP/. 14356

soapSpec tModel: An xmlSpec tModel whose specification expresses its data using SOAP 14357 1.1. 14358

Sort order: Any of the find qualifiers that specify the base algorithm to be used to order the 14359 results returned by the find_xx APIs 14360

Specification tModel: A tModel representing the specification for a Web service type. Cf. 14361 “Protocol tModel” and “Transport tModel”. 14362

Structure: Any of the UDDI elements that are permitted by the schemas to have elements 14363 contained within them. 14364

SSL: Secure Sockets Layer Version 3.0. A commonly used network protocol as defined in 14365 http://home.netscape.com/eng/ssl3/index.html. 14366

Subscriber: Any client who uses the subscription API set. 14367

Technical fingerprint: The collection of tModel references found in the tModelInstanceDetails 14368 of a bindingTemplate. This collection, taken without regard to order, defines the type of the 14369 Web service described by the bindingTemplate. 14370

Technical Note: A non-normative document accompanying the UDDI v3 Specification that 14371 provides guidance on how to use UDDI registries. While technical notes represent the UDDI 14372 Working Group’s view on some UDDI-related topic, they are often prospective and need not 14373 document existing practice. Cf. Best Practice. 14374

tModel: The type of entity in UDDI that is used to represent concepts. 14375

Transport tModel: A tModel representing a transport mechanism such as HTTP. Typically 14376 used in a technical fingerprint, if required by the specification tModel, to specify which transport 14377 mechanism a given Web service instance uses. 14378

UDDI: Universal Description, Discovery and Integration. The subject of this specification. 14379

UDDI Business Registry: A publicly available UDDI registry. The Web services offered by the 14380 UDDI Business Registry's nodes can be found at http://uddi.org/register.html (publication) and 14381 http://uddi.org/find.html (inquiry). 14382

UDDI keying scheme: The URI scheme “uddi” together with the set of registry policies that 14383 makes copying data among registries safe and easy to do. The keying scheme is described in 14384 Chapter 4 of the UDDI v3 Specification 14385

UDDI schema: Any of the documents written in the XML Schema Definition Language that 14386 accompany this specification and are a part of it. See Chapter 2 UDDI Schemas. 14387

UDDI v3 Specification, The: The main textual document that specifies UDDI version 3. 14388

UDDI Version 2: The prior version of this specification. See 14389 http://uddi.org/pubs/ProgrammersAPI_v2.pdf. 14390

Unicode: The character set defined by the Unicode Consortium. See www.unicode.org. UDDI 14391 data is express using the Unicode character set. 14392

UTF-16: An encoding scheme used by UDDI to express Unicode characters. See: 14393 http://www.ietf.org/rfc/rfc2781.txt. 14394

UTF-8: An encoding scheme used by UDDI to express Unicode characters. See 14395 http://www.ietf.org/rfc/rfc2279.txt. 14396

�� Not used by UDDI

�� The


402/405

uuid key generator: More fully, “uuid key generator tModel”. In the UDDI keying scheme, a 14397 key generator with a key of the form 14398

“uddi:” uuid “:keygenerator” 14399

Where uuid is a Universally Unique Identifier. 14400

Unchecked: Of or pertaining to value sets whose use in not subject to validation. Cf., 14401 “Checked”. 14402

URI: A Uniform Resource Identifier as represented by the XML Schema data type anyURI. 14403 When, as it occasionally is, the term is used more narrowly, the context makes this clear. 14404

UUID: A really big integer, generated according to certain rules that allow them to be 14405 generated on independent computers in such a way that the same one is never generated 14406 twice. UUIDs are conventionally expressed as specially formatted hexadecimal. 14407

Value set: Any category system, identifier system, relationship system or postal address 14408 system. 14409

Value set provider: Any publisher who publishes a checked value set tModel. Typically a 14410 value set provider also provides a get_allValidValues or a validate_values Web service or 14411 both. 14412

Web service: Any service capable of being described by a UDDI bindingTemplate. Typically 14413 Web services are used for machine-to-machine communication and typically, they share much 14414 of the technology that underlies the World Wide Web, such as TCP/IP, HTTP, and XML. 14415

Web service type: Informally, the type of a Web service instance is defined by the external 14416 behaviors it exhibits. Typically these are defined by the specifications, protocols, and 14417 transports to which it adheres. Formally in UDDI, the type of a Web service is the technical 14418 fingerprint of the bindingTemplate that describes it. 14419

WSDL: Web Services Description Language Version 1.0. An XML vocabulary and set of 14420 conventions used to describe the technical details of a Web service, particularly of a SOAP-14421 based Web service. See: http://www.w3.org/TR/wsdl. 14422

wsdlSpec tModel: An xmlSpec tModel whose description is expressed in WSDL and which 14423 follows the UDDI Best Practice for the combined use of UDDI and WSDL. 14424

XML: eXtensible Mark-up Language. A platform and implementation-neutral way to describe 14425 data. See: http://www.w3c.org/TR/2000/REC-xml-20001006 14426

xmlSpec tModel: A specification tModel whose specification expresses its data using XML. 14427

�� recommended

�� keyGenerator


403/405

14428

M Appendix M: Acknowledgements 14429

This specification was developed as a result of joint work of many individuals from the OASIS 14430 UDDI Specification TC and the former UDDI.org Working Group. We would like to 14431 acknowledge the efforts and contributions of the following individuals: 14432

Former OASIS UDDI Specification TC members: 14433

Toufic Boubez, Layer Seven Technologies 14434 Patrick Felsted, Novell 14435 Karsten Januszewski, Microsoft 14436 Keisuke Kibakura, Fujitsu 14437 Eric Lee, Microsoft 14438 Sam Lee, Oracle 14439

14440

UDDI Working Group members (at the time the UDDI Version 3.0 specification was 14441 published): 14442

Selim Aissi, Intel 14443 David Ehnebuske, IBM (Editor) 14444 Tom Gaskins, HP 14445 Tom Glover, IBM 14446 Christian Hansen, SAP 14447 Thomas Hardjono, VeriSign 14448 Richard Harrah, HP 14449 Maryann Hondo, IBM (Editor) 14450 Yin Leng Husband, HP (Editor) 14451 Karsten Januszewski, Microsoft (Editor) 14452 Keisuke Kibakura, Fujitsu 14453 Sam Lee, Oracle (Editor) 14454 Seán MacRoibeáird, Sun 14455 Barbara McKee, IBM (Editor) 14456 Joel Munter, Intel (Editor) 14457 Ed Mooney, Sun 14458 Andrew Nielsen, HP 14459 Christian R. Thomas, Intel 14460 Johannes Viegener, SAP 14461


404/405

14462

N Appendix N: Notices 14463

Copyright © 2001-2002 by Accenture, Ariba, Inc., Commerce One, Inc., Fujitsu Limited, Hewlett-14464 Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines 14465 Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems, Inc., and 14466 VeriSign, Inc. All Rights Reserved. 14467

These UDDI Specifications (the "Documents") are provided by the companies named above 14468 ("Licensors") under the following license. By using and/or copying this Document, or the Document 14469 from which this statement is linked, you (the licensee) agree that you have read, understood, and will 14470 comply with the following terms and conditions: 14471

Permission to copy, prepare derivative works based on, and distribute the contents of this Document, 14472 or the Document from which this statement is linked, and derivative works thereof, in any medium for 14473 any purpose and without fee or royalty under copyrights is hereby granted, provided that you include 14474 the following on ALL copies of the document, or portions thereof, that you use: 14475

1. A link to the original document posted on uddi.org. 14476

2. An attribution statement : "Copyright © 2000 - 2002 by Accenture, Ariba, Inc., Commerce 14477 One, Inc. Fujitsu Limited, Hewlett-Packard Company, i2 Technologies, Inc., Intel 14478 Corporation, International Business Machines Corporation, Microsoft Corporation, 14479 Oracle Corporation, SAP AG, Sun Microsystems, Inc., and VeriSign, Inc. All Rights 14480 Reserved." 14481

If the Licensors own any patents or patent applications that may be required for implementing and 14482 using the specifications contained in the Document in products that comply with the specifications, 14483 upon written request, a non-exclusive license under such patents shall be granted on reasonable and 14484 non-discriminatory terms. 14485

EXCEPT TO THE EXTENT PROHIBITED BY LOCAL LAW, THIS DOCUMENT (OR THE 14486 DOCUMENT TO WHICH THIS STATEMENT IS LINKED) IS PROVIDED "AS IS," AND LICENSORS 14487 MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT 14488 NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR 14489 PURPOSE, ACCURACY OF THE INFORMATIONAL CONTENT, NON-INFRINGEMENT, OR TITLE; 14490 THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT 14491 THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY OR 14492 (WITH THE EXCEPTION OF THE RELEVANT PATENT LICENSE RIGHTS ACTUALLY GRANTED 14493 UNDER THE PRIOR PARAGRAPH) LICENSOR PATENTS, COPYRIGHTS, TRADEMARKS OR 14494 OTHER RIGHTS. Some jurisdictions do not allow exclusions of implied warranties or conditions, so the 14495 above exclusion may not apply to you to the extent prohibited by local laws. You may have other rights 14496 that vary from country to country, state to state, or province to province. 14497

EXCEPT TO THE EXTENT PROHIBITED BY LOCAL LAW, LICENSORS WILL NOT BE LIABLE 14498 FOR ANY DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL DAMAGES, OR OTHER DAMAGES 14499 (INCLUDING LOST PROFIT, LOST DATA, OR DOWNTIME COSTS), ARISING OUT OF ANY USE, 14500 INABILITY TO USE, OR THE RESULTS OF USE OF THE DOCUMENT OR THE PERFORMANCE 14501 OR IMPLEMENTATION OF THE CONTENTS THEREOF, WHETHER BASED IN WARRANTY, 14502 CONTRACT, TORT, OR OTHER LEGAL THEORY, AND WHETHER OR NOT ANY LICENSOR 14503 WAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Some jurisdictions do not allow the 14504 exclusion or limitation of liability for incidental or consequential damages, so the above limitation may 14505 not apply to you to the extent prohibited by local laws. 14506

Copyright © OASIS Open 2002-2003. All Rights Reserved. 14507

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 14508 might be claimed to pertain to the implementation or use of the technology described in this document 14509 or the extent to which any license under such rights might or might not be available; neither does it 14510


405/405

represent that it has made any effort to identify any such rights. Information on OASIS's procedures 14511 with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of 14512 rights made available for publication and any assurances of licenses to be made available, or the result 14513 of an attempt made to obtain a general license or permission for the use of such proprietary rights by 14514 implementors or users of this specification, can be obtained from the OASIS Executive Director. 14515

OASIS invites any interested party to bring to its attention any copyrights, patents or patent 14516 applications, or other proprietary rights which may cover technology that may be required to implement 14517 this specification. Please address the information to the OASIS Executive Director. 14518

This document and translations of it may be copied and furnished to others, and derivative works that 14519 comment on or otherwise explain it or assist in its implementation may be prepared, copied, published 14520 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright 14521 notice and this paragraph are included on all such copies and derivative works. However, this 14522 document itself may not be modified in any way, such as by removing the copyright notice or 14523 references to OASIS, except as needed for the purpose of developing OASIS specifications, in which 14524 case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be 14525 followed, or as required to translate it into languages other than English. 14526

The limited permissions granted above are perpetual and will not be revoked by OASIS or its 14527 successors or assigns. 14528

This document and the information contained herein is provided on an “AS IS” basis and OASIS 14529 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 14530 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 14531 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 14532 PURPOSE. 14533

14534

�� ! ��"#��$� ��

The following keys all belong to the partition of the key generator key “uddi:tempuri.com:keyGenerator”.

“uddi:tempuri.com” The key on which a <keyGeneratorKey> is based belongs in the partition.

“uddi:tempuri.com:xxx” A key based on the same <uddiKey> as the <keyGeneratorKey belongs in the partition.

“uddi:tempuri.com:xxx:keyGenerator” A <keyGeneratorKey> based on a <derived key> belongs in the partition.

The following keys do not belong in the partition of the key generator key “uddi:tempuri.com:keyGenerator”.

“uddi:tempuri.com:keyGenerator” The initial <keyGeneratorKey> does not belong to the partition it designates.

“uddi:tempuri.com:xxx:yyy” This key belongs to the partition of the <keyGeneratorKey> “uddi:tempuri.com:xxx:keyGenerator”, not this one.

“uddi:tempuri.com:keyGenerator:zzz” This key does not belong in any partition – it is an invalid key.

��# �"�� %�� ! ��"#��$� ��

Let k3 be a UDDI v3 key. In the table below we define an associated UUID uuid(k3). Once this is done, one straightforwardly defines a UUID v2 key for the entity denoted by k3 in the normal UDDI v2 manner as appropriate for the type of that entity.

Let uuid(k3) be the UUID defined as follows:

Let h(k3) be the MD5 hash of the concatenation of

the 16-byte sequence 0f 86 ac ae 5d f4 fc 4c b0 ef 7c 6c 36 f8 0f 53

the bytes of the key k3 &!'!( )#*�+ ),' -

Let u(k3) be the 16-octet endian-sensitive value created as follows (illustrated in both big-endian and little-endian forms of u(k3))

Octet # Big-endian u(k3) Little-endian u(k3)

0 Octet 0 of h(k3) Octet 3 of h(k3)






6 Octet 6 of h(k3) but with the four Octet 7 of h(k3)

most significant bits set to ‘0011’

7 Octet 7 of h(k3) Octet 6 of h(k3) but with the four most significant bits set to ‘0011’

8 Octet 8 of h(k3) but with the two most significant bits set to ‘10’

Octet 8 of h(k3) but with the two most significant bits set to ‘10’








Let uuid(k3) be the value of the byte sequence u(k3) interpreted as a UUID. In making this interpretation, we rely on the specification of UUIDs as found in

�� !�"��!�!��# ��

The owningBusiness category system exists in prior versions of UDDI. keyedReferences that refer to this original owningBusiness category system contain businessKeys for version 1 and 2 businessEntity elements, expressed in the format of these versions of UDDI (as a UUID with no scheme prefix). When accessed using a prior version API in a multi-version registry, the older owningBusiness category system yields valid references to businessEntity elements that are in the format of the prior version, and thus remain valid. When viewed using the version 3 UDDI API these same references to the earlier owningBusiness category system contain invalid version 3 format keys. A new version of this category system is required to be able to reference the set of values defined by version 3 format keys.

��$�!�� !�"��!�!��# ��

Name: uddi-org:owningBusiness_v3

Description: Category system used to point to the businessEntity associated with the publisher of the tModel

UDDI Key (V3): uddi:uddi.org:categorization:owningBusiness

Derived V1,V2 format key: uuid:D08FFB57-3E4C-3F9B-A9F7-022B7BDB7D4E


Checked: Yes

�� %�� !�"��!�!��# ��

owningBusiness”>

�� &�� !�"��!�!��# ��

</categoryBag> </tModel>

��#!% �� '�� !�"��!�!��# ��

Name: uddi-org:approximateMatch:SQL99

Short name: approximateMatch

Description: UDDI SQL99 Approximate Matching findQualifier

UDDI Key (V3): uddi:uddi.org:findQualifier:approximateMatch

Derived V1,V2 format key: uuid:ebddfefd-71e5-3f74-ac95-9671d4aecaba


Support: Mandatory

tModel Structure This tModel is represented with the following structure

<tModel tModelKey=”uddi:uddi.org:findQualifier:approximateMatch”> <name>uddi-org:approximateMatch:SQL99</name> <description>UDDI approximate matching findQualifier </description> <overviewDoc> <overviewURL useType=”text”> http://uddi.org/pubs/uddi_v3.htm#wildcard </overviewURL> </overviewDoc> <categoryBag> <keyedReference keyName=”uddi-org:types:findQualifier” keyValue="findQualifier" tModelKey="uddi:uddi.org:categorization:types”/> </categoryBag> </tModel> ��

Example of Use The following represent a typical inquiry that uses the SQL99 approximateMatch findQualifier. This example shows an inquiry using the SQL99 approximateMatch findQualifier to find all businesses that are either themselves categorized or that have businessService or bindingTemplate structures categorized with any of the categories in the UNSPSC family "Telephones and personal telecommunications devices and accessories". In this example a wildcard character is added to the end of the keyValue specified for a UNSPSC keyedReference because this value set is formatted hierarchically with more detailed nodes represented by additional numeric fragments on the right side of the value.

<find_business xmlns="urn:uddi-org:api_v3"> <findQualifiers> <findQualifier> uddi:uddi.org:findQualifier:approximateMatch </findQualifier> <findQualifier> uddi:uddi.org:findQualifier:combineCategoryBags </findQualifier> </findQualifiers> <categoryBag> <keyedReference keyValue="34.10.%" tModelKey="uddi:ubr.uddi.org:categorization:unspsc"/> </categoryBag> </find_business>

UDDI Exact Match findQualifier

Introduction The Exact Match findQualifier represents the default behavior for matching name, keyValue, and keyName arguments used in UDDI inquiry functions. This qualifier directs inquiry functions to find matches based on exactly what has been provided in the input criteria of the inquiry.

Design Goals The Exact Match findQualifier tModel is provided to explicitly request discovery of UDDI entities with an exact match on the name, keyValue, and where applicable, keyName arguments, after canonicalization.

tModel Definition This tModel is a findQualifier that is used to enable exact matching in UDDI inquiries. When this tModel is referenced in a findQualifier, only entities with names, keyValues, and where applicable, keyNames that exactly match the values passed in the input criteria, after canonicalization, will be returned. This qualifier conflicts with any approximate match qualifier such as uddi-org:approximateMatch and with uddi-org:caseInsensitiveMatch.

Name: uddi-org:exactMatch

Short name: exactMatch

Description: UDDI Exact Matching findQualifier

UDDI Key (V3): uddi:uddi.org:findQualifier:exactMatch

Derived V1,V2 format key: uuid:3964444e-be78-36b0-836d-12799afef14e



�� !�"� ��"#��!!$�!�� !�� !�!

Exact Name Match findQualifier tModel. All businesses with the name ‘My Company Name’ are returned

��%�� &�� !�"� ��"#��!!$�!�� !�� !�!

Short name: caseSensitiveMatch

Description: UDDI Case Sensitive Matching findQualifier

UDDI Key (V3): uddi:uddi.org:findQualifier:caseSensitiveMatch

Derived V1,V2 format key: uuid:48ea42d0-89a5-38ab-950b-5eb37905e1f1


Support: Mandatory, default '#(#)�*�+�, *-(�.

�� / �!�� !�"� ��"#��!!$�!�� !�� !�!

The Diacritics Insensitive Match findQualifier tModel is provided to enable discovery of UDDI entities when diacritics sensitivity is not important.

�� / � �� !�"� ��"#��!!$�!�� !�� !�!

findQualifier, diacritic symbols (e.g. accents, diaeresis, cedilla) are ir

�� !�"��!�!#��

This qualifier uses as diacritics, that set of characters defined to constitute diacritics in the Default Unicode Collation Element Table1.

��$�� #�� !�"��!�!#��

Short name: diacriticsSensitiveMatch

Description: UDDI Diacritics Sensitive Matching findQualifier

UDDI Key (V3): uddi:uddi.org:findQualifier:diacriticsSensitiveMatch

Derived V1,V2 format key: uuid:83fd3f56-9b34-31cf-8e36-af0d66425808


Support: Mandatory, default %"&"'�(�)�* (+&�,

��$�� -!�� !�"��!�!#��

findQualifier:diacriticsSensitiveMatch

��$�� .�� !�"��!�!#��

diacriticsInsensitiveMatch

��$!# �� /�� !�"��!�!#��

collation sequence findQualifier

��#�� 0�� !�"��!�!#��

findQualifier:caseInsensitiveMatch </findQualifier> <findQualifier> uddi:uddi.org:sortOrder:UTS-10

��#�� !�� !�"��!�!#��

default directionality to enable

��#�� $!�� !�"��!�!#��

%"&"'�(�)�* (+&�,

��#��!�� !�"��!�!#��

UDDI core data structure, in an ascending

��#��!�� !�"��!�!#��

When no conflicting sort qualifier is specified, this is the default sort ordering behavior.

��#�� !�"��!�!#��

Name: uddi-org:sortByNameDesc

Short name: sortByNameDesc

Description: UDDI sort qualifier used to sort results by name in descending order

1 http://www.unicode.org/unicode/reports/tr10/allkeys.txt

UDDI Key (V3): uddi:uddi.org:findQualifier:sortByNameDesc

Derived V1,V2 format key: uuid:2f19aa82-cb0f-3d1f-83f7-d398555bc290


Support: Mandatory

�� !�" ��!�!��#� ��

This tModel is referenced by a findQualifier in a UDDI inquiry API to AND the keys in identifierBag, categoryBag, and/or tModelBag prior to performing the actual search for results. Using this findQualifier tModel does not change the treatment of categoryBag or tModelBag contents because ANDing their bag contents is default behavior.

This findQualifier cannot be used with the uddi-org:orAllKeys or uddi-org:orLikeKeys findQualifier. The set of values that would result from use of a wildcard in a keyValue are always implicitly OR'd together independent of and after application of this wildcard. This allows an inquiry of the form ‘find businesses with services in Georgia that relate to transporting goods’, where Georgia would be specified as an explicit keyValue from a geographic value set and transporting goods would be specified using a partial value with a wildcard from a product and services value set.:

Name: uddi-org:andAllKeys

Short name: andAllKeys

Description: UDDI findQualifier used to request that a logical AND be performed on bag contents prior to a search.

UDDI Key (V3): uddi:uddi.org:findQualifier:andAllKeys

Derived V1,V2 format key: uuid:34210649-a605-3143-a33e-07295146575a


Support: Mandatory

�� $!�� !�" ��!�!��#� ��

Node Business Entity elements are discovered that contain one or more descendent bindingTemplate elements that implement the validate_values API. These businesses are then sorted by date in descending sequence.

�� %�� !�" ��!�!��#� ��

findQualifier

Introduction The Or All Keys findQualifier

�� &�� !�" ��!�!��#� ��

categoryBag and tModelBag).

�� '�� !�" ��!�!��#� ��

categoryBags and tModelBags

�� #!�� !�" ��!�!��#� ��

��

�� ! "�#�$&%�� '(�)� ��*��*��+��

Name: uddi-org:orAllKeys

Short name: orAllKeys

Description: UDDI findQualifier used to request that a logical OR be performed on bag contents prior to a search.

UDDI Key (V3): uddi:uddi.org:findQualifier:orAllKeys

Derived V1,V2 format key: uuid:ea6e816e-8918-3b8d-8441-f2210dd4c4ec


Support: Mandatory

Name:

uddi-org:andAllKeys

�� ,�� ! "�#�$&%�� '(�)� ��*��*��+��

Design Goals The design goal of the Combine Category Bags findQualifier is to provide a means for finding entities without regard to placement of the categoryBags in the published entities. This findQualifier enables inquiries involving categorization to be successful independent of the modeling styles of the publishers. Some publishers may place certain categorizations at the business level, such as those related to the industries that their businesses operate in, and place others at the service level (product and service, for example). Inquirers may not care whether the categorization is at the business level or the service level. This findQualifier enables such inquiries.

tModel Definition This tModel is referenced by a findQualifier in a UDDI find_business inquiry API to treat the categoryBag contents of businessEntity structures and contained businessService structures as one. Searching for a category will yield a positive match on a registered business if any of the categoryBag elements contained within the businessEntity element or any of its contained or referenced businessService elements contains the filter criteria.

This findQualifier overrides the default behavior of find_business which performs matching on categoryBags on the businessEntity structures themselves by instead performing matching on categoryBags associated with contained businessService structures as well as the businessEntity structures. The uddi-org:serviceSubset and uddi-org:bindingSubset findQualifiers conflict with this one.

Name: uddi-org:combineCategoryBags

Short name: combineCategoryBags

Description: UDDI findQualifier used to treat all of the categoryBags within a businessEntity as if they were one during an inquiry.

UDDI Key (V3): uddi:uddi.org:findQualifier:combineCategoryBags

Derived V1,V2 format key: uuid:693a8207-3607-3ced-a923-5bc60f21de23


Support: Mandatory ��

tModel Structure This tModel is represented with the following structure

<tModel tModelKey=”uddi:uddi.org:findQualifier:combineCategoryBags”> <name>uddi-org:combineCategoryBags</name> <description>UDDI findQualifier used to treat all of the categoryBags within a businessEntity as if they were one during inquiry</description> <overviewDoc> <overviewURL useType=”text”> http://uddi.org/pubs/uddi_v3.htm#combineCatBags </overviewURL> </overviewDoc> <categoryBag> <keyedReference keyName=”uddi-org:types:findQualifier” keyValue="findQualifier" tModelKey="uddi:uddi.org:categorization:types”/> </categoryBag> </tModel>

Example of Use The following represents a typical inquiry that references the Combine Category Bags find qualifier tModel. This example is used to locate businesses that are categorized as ‘computer facilities management services’ or that have descendents that are so categorized.

<find_business xmlns="urn:uddi-org:api_v3">  <findQualifiers> <findQualifier> uddi:uddi.org:findQualifier:combineCategoryBags </findQualifier> </findQualifiers> <categoryBag> <keyedReference keyValue="541513" tModelKey="uddi:ubr.uddi.org:categorization:naics:1997"/> </categoryBag> </find_business>

UDDI Service Subset findQualifier

Introduction The Service Subset findQualifier, applied to the find_business inquiry, causes only categoryBags on contained businessService structures to be inspected. The categoryBags on businessEntity structures themselves are ignored.

�� !�"$#�� %&�'�� (�)�*�)�*(�(��(�+�� *(�� (�(

Publishers often categorize their business services with the industries, products, service types and geographical service areas that apply specifically to the described services, and categorize the containing businessEntity strictures with supersets of categorizations from the contained businessService structures. The design goal of the Service Subset findQualifier is to provide a means for finding business services using categorization using the find_business inquiry API, omitting those businessEntity structures that may offer the kinds of services, but which have not specifically identified them as meeting the specified needs.

�� ! "��!�!��#��

within the businessEntity element or any of its contained or referenced

�� ! "��!�!��#��

by instead performing matching on categoryBags associated with contained businessService structures as well as the businessEntity structures

�� $!�� ! "��!�!��#��

Name: uddi-org:serviceSubset

Short name: serviceSubset

Description: UDDI findQualifier used to use categoryBags of businessService elements to satisfy the find_business inquiry.

UDDI Key (V3): uddi:uddi.org:findQualifier:serviceSubset

V1,V2 format key: uuid:9dc599f1-1ee2-3736-b4be-da919e6b1063


Support: Mandatory

�� %�� ! "��!�!��#��

findQualifier:serviceSubset

�� ! "��!�!��#��

treat all of the

�� &�� ! "��!�!��#��

of businessService elements to satisfy the find_business

��&�� #!�� ! "��!�!��#��

This inquiry returns businessEntity elements that have descendent businessService elements that are categorized with ‘Customer Computer Programming Services’ or ’Computer Systems Design Services’ and which conform to some technical fingerprint

��&�� '!�� ! "��!�!��#��

!--Find computer facilities management services --> <

��&��($��!�� ! "��!�!��#��

findQualifier:serviceSubset </findQualifier> <findQualifier> uddi:uddi.org:findQualifier:orAllKeys

��&��($�� ! "��!�!��#��

categoryBag> <keyedReference keyValue="541513"

��&��($!�� ! "��!�!��#��

some.specific.example:tModelKey</tModelKey> </tModelBag> <categoryBag> <keyedReference keyValue="541511" tModelKey="

��&��($!�� ! "��!�!��#��

.uddi.org:categorization:naics:1997"/> <keyedReference keyValue="541512" tModelKey="uddi:ubr.uddi.org

�� !"��#�"$#�!�!��!�%�� #�!�� !�!

and find_service inquiries, cause

�� &�� !"��#�"$#�!�!��!�%�� #�!�� !�!

descendent bindingTemplate

�� '�� !"��#�"$#�!�!��!�%�� #�!�� !�!

and/or businessService elements

�� !"��#�"$#�!�!��!�%�� #�!�� !�!

the industries, products, service types and geographical service areas that apply specifically

�� %�� !"��#�"$#�!�!��!�%�� #�!�� !�!

the described services, and categorize the containing businessEntity

�� (�� !"��#�"$#�!�!��!�%�� #�!�� !�!

with supersets of categorizations from the contained businessService

��&�!�� !"��#�"$#�!�!��!�%�� #�!�� !�!

may represent the same Web service but for different audiences or may represent different levels of release, for example

��&�� !"��#�"$#�!�!��!�%�� #�!�� !�!

business services using categorization using the find_business inquiry API, omitting those

��&�#�� !"��#�"$#�!�!��!�%�� #�!�� !�!

elements or businessService elements

��&�� !"��#�"$#�!�!��!�%�� #�!�� !�!

may offer the kinds of services, but which

��&� �� !"��#�"$#�!�!��!�%�� #�!�� !�!

not specifically identified them as meeting the specified needs

��&�&�� !"��#�"$#�!�!��!�%�� #�!�� !�!

and businessService elements

��&�'�� !"��#�"$#�!�!��!�%�� #�!�� !�!

bindingTemplate structures belong to

��&�� !"��#�"$#�!�!��!�%�� #�!�� !�!

)$*$+�,�-�. ,/*�0

��&�%�� !"��#�"$#�!�!��!�%�� #�!�� !�!

, and of find_service which performs matching on categoryBags on the businessService elements themselves

�� !"��#�"$#�!�!��!�%�� #�!�� !�!

Name: uddi-org:bindingSubset

Short name: bindingSubset

Description: UDDI findQualifier for specifying use of categoryBags of bindingTemplate elements to satisfy the find_business or find_service inquiries.

UDDI Key (V3): uddi:uddi.org:findQualifier:bindingSubset

Derived V1,V2 format key: uuid:8bdfa975-19ac-38a2-bdd3-715878beb9ef


Support: Mandatory

Name:

uddi-org:serviceSubset

��&�!�� !"��#�"$#�!�!��!�%�� #�!�� !�!

categoryBags of contained bindingTemplate elements. Searching with a category yields a match on a registered business if any of the categoryBag elements associated with contained bindingTemplate structures belong to the search category.

��&�� !"��#�"$#�!�!��!�%�� #�!�� !�!

When a UDDI inquiry couples this findQualifier with the use of tModelBags or the serviceSubset findQualifier, empty outer elements (businessInfo for find_business; serviceInfo for find_service) are excluded from the result set when the only qualifying entity corresponds to a suppressed projected service.

'$($)�*�+�, *-(�.

This findQualifier overrides the default behavior of find_business and find_service (when a businessKey is provided).

Name:

��#�!��&�#�� !"��#�"$#�!�!��!�%�� #�!�� !�!

The businesses that are the actual providers of a business service that adheres to some technical fingerprint are returned. Other businesses that refer to such businessService elements using services projections are excluded

��#�!��&�� !"��#�"$#�!�!��!�%�� #�!�� !�!



��#�!��&�/�� !"��#�"$#�!�!��!�%�� #�!�� !�!

:suppressProjectedServices </findQualifier>

��#��&� �� !"��#�"$#�!�!��!�%�� #�!�� !�!

This tModel is referenced by a findQualifier in a UDDI inquiry API to only include UDDI entities that have XML Digital Signatures or that are descendents of UDDI entities that have XML

Digital Signatures. To be returned, either the elements themselves must be signed, or at least one of the elements that contain them must be signed. For example when the Signature Present findQualifier is used with the find_business inquiry API, only businessEntity elements that have an XML Digital Signature are returned. Similarly, when Signature Present is used with the find_service inquiry API, only businessService elements that have an XML Digital Signature or whose containing businessEntity elements have an XML Digital Signature are returned.

The UDDI Inquiry API provides no verification associated with use of this findQualifier.

Name: uddi-org:signaturePresent

Short name: signaturePresent

Description: UDDI findQualifier used to return only entities that have or are contained in entities that have XML Digital Signatures.

UDDI Key (V3): uddi:uddi.org:findQualifier:signaturePresent

Derived V1,V2 format key: uuid:2b661025-b4a4-3a3f-b60e-e7d68c21ec85


Support: Mandatory